Re: Fixing the Pen Tablet
Careful: in the evdev driver rpm, I had a kludge to force relative mode no matter what. It should now be taken off. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: permanently changing keyboard layout for forth
C. Scott Ananian wrote: The /home/olpc/.i18n file should provide a lighter-weight mechanism to accomplish what you want; perhaps Michael or Bernie could elaborate? I'm not certain of the details myself. To customize the keyboard, you need to either edit /etc/sysconfig/keyboard, or create /home/olpc/.kbd. The contents in both cases should be: XKB_MODEL=olpc XKB_LAYOUT=2 letter ISO country code XKB_VARIANT=olpc # usually! KEYTABLE=system console keymap See http://wiki.laptop.org/go/Olpc-utils for further details. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: State of the update.1
Walter Bender wrote: Let's you and I take a look at the console problem. I cannot imagine it is difficult to sort out. The problem is just that we do not load our customized keymaps because a clean integration in the kbd package would need a bit of work to detect OLPC at run-time and prepend a new olpc/ directory to the search path in this case. To make it happen in Update.1 quickly, I vote for a quick dirty Pilgrim hack: we'd basically just have to overwrite es.map.gz and pt.map.gz in /lib/kbd/keymaps/i386/qwerty/ with the versions attached to the bug. This will gain us time to find out how to integrate olpc keymaps properly with the package maintainer in the next release cycle. Dennis, how does it sound to you? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: State of the update.1
Dennis Gilmore wrote: On Friday 07 March 2008, Bernardo Innocenti wrote: Walter Bender wrote: Let's you and I take a look at the console problem. I cannot imagine it is difficult to sort out. The problem is just that we do not load our customized keymaps because a clean integration in the kbd package would need a bit of work to detect OLPC at run-time and prepend a new olpc/ directory to the search path in this case. To make it happen in Update.1 quickly, I vote for a quick dirty Pilgrim hack: we'd basically just have to overwrite es.map.gz and pt.map.gz in /lib/kbd/keymaps/i386/qwerty/ with the versions attached to the bug. This will gain us time to find out how to integrate olpc keymaps properly with the package maintainer in the next release cycle. Dennis, how does it sound to you? Id rather do it right the first time. How about a middle-ground solution? If you can branch the kbd package for me (needed anyway until we rebase on latest Fedora), I could replace the keyboard maps in the OLPC specific build of the package. In another universe where days have 48 hours, we could even take the opportunity to drop all the useless keyboards that do not exist for our platform. But if we cant do it right in a reasonable timeframe then it would work. :-( I'm leaving tomorrow morning and I'm not sure when I'll get decent connectivity again. If this becomes the only blocker bug left before then, I guess anybody with a Fedora account could go on and do what's described above. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: libpciaccess patch
Bernardo Innocenti wrote: If you're not in a hurry, I'll try to do this after the FOSDEM. I also need this in order to upgrade to X 1.5 on the OLPC. Yesterday me and aleph completed the pciaccess rework for the amd_drv. But as we rebased on the latest xserver git head, we stumbled into the dev-privates rework. We currently have an unfinished, untested patch which will be hopefully complete by this weekend. Both patches are intended to keep backwards compatibility with older xservers. It would be nice if someone could test it on Xorg 1.4 and let me know. You can pull my working tree from here: http://www.codewiz.org/~bernie/git/xf86-amd-devel.pcirework.git/ -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: libpciaccess patch
Martin-Éric Racine wrote: This needs to be rebased with our upstream AMD driver git. We're already a couple of commits after 2.7.7.6, while this tree is based upon 2.7.7.5. Yes. To begin with, I worked on the old OLPC fork because its my known-good codebase, and I was unsure whether the Xorg tree already contains all the patches needed to work out of the box on the OLPC. Jordan, what do you think? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: libpciaccess patch
Martin-Éric Racine wrote: Actually, no - we're not up to date with OLPC, and nobody has actually tested the vanilla driver on the XO. The status on the wiki is clearly incorrect. The status is correct. It states that the vanilla driver has basic support in place but that it needs to be tested by the OLPC community. Lack of interest on OLPC's part to test this and report on success/failure needs to be resolved ASAP. Rather than lack of interest, there's lack of resources. I'm the only X maintainer left at OLPC, and as you know I've been traveling a lot lately, and I'm planning to travel some more over the next few weeks. This limited time has been used to convert the driver to new interfaces that have been published for a long time. All other drivers have been converted already by their respective maintainers, without bothering downstream distro maintainers like myself. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: libpciaccess patch
Martin-Éric Racine wrote: There's plenty more people that could install and test this vanilla driver at Debian, Fedora, Ubuntu and countless other distros that have decided to create OLPC install targets and yet we never heard from them on this issue. If there are plenty of Xorg distro maintainers interested in porting to the OLPC, why haven't they ever contacted me or dropped a single mail on our development lists? The only efforts I know of are the unofficial Debian port made by two OLPC engineers in their free time, and some work on getting Fedora to boot done by two more OLPC engineers in their free time. In both cases, they just pulled the verbatim source from the OLPC git tree and rolled packages with it. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: libpciaccess patch
Jordan Crouse wrote: I don't know if Jim is ready to move OLPC to a newer X, but I do know that *we* are ready to move, so the logical move would be to base it on our tree, and then merge the rest of the OLPC tree in at our leisure and transition you guys to that. For now, I'm just upstreaming all our changes to reduce the delta. Later, I'm planning to drop the xserver 1.5 in my xtest builds, so people can test, benchmark and comment. This will give Jim some feedback on which to make a decision. From the patch stream I've seen passing by over the 1.5 timeframe, I expect to see EXA performance improvements, the entity of which is still to be seen. I'll pass the question on to Warren, since he'll end up being the maintainer of the final product in Fedora. Are you ready for OLPC to bang on your drum? Fedora 9 already switched on Xorg 1.5. So at this time amd_drv is broken (does not even build). I offered to fix it by upgrading the rpm as soon as we get a working patchset. I don't know when (and if) we're going to rebase OLPC on F-9, but being ready for Xorg 1.5 would make things easier and allow us to unbranch a good number of RPMs. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Community/OLPC Server Support Discussion
ffm wrote: On Wed, Feb 20, 2008 at 9:49 AM, Bernardo Innocenti [EMAIL PROTECTED] wrote: Can we postpone it to a later date? 3:30 PM EST, Thursday, Feb. 21st? Earlier, but one I can make. Oops, I've only noticed your reply now. Has the meeting already been done? If not, how about: 18:00 EST, Tuesday, Feb. 26 in #olpc-meeting on irc.freenode.org http://www.timeanddate.com/worldclock/fixedtime.html?month=2day=26year=2008hour=18min=0sec=0p1=43 -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Proposal: the 'faster' branch.
C. Scott Ananian wrote: [...] So: welcome the 'faster' branch, a repository for all these unsafe ideas. [...] Scott, I think this is a great idea! First thing, I think we need Reinier's script watching it. Can we prevent it from doing spurious runs when stuff gets changed in joyride but not specifically in faster? An easy parameter to watch for would be the boot time, conveniently stored in /home/olpc/.boot_time by the olpc-session script. I know, I know... boot time is not our #1 priority. But: boot time is easy to measure objectively and has a strong correlation with other performance sensitive parts of the system. For example, a kernel with debug enabled is likely to increase it. So I think this is an interesting number to watch for until someone comes up with a comprehensive performance suite. It would be a little better if we made sugar write it just before entering the gtk mainloop, so it would take into account Sugar related optimizations. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: status of startup speedup
Tomeu Vizoso wrote: * Why is it necessary to import gtk twice? Well, we import first in the parent process so the initialization is inherited by all children. The second time is just because we need to reopen the connection to X (and need a gtk name in that scope). Has anybody looked into ways to prevent the gtk bindings from doing this nonsense? I remember somebody (cscott?) saying that Python 2.5 has some way to pass arguments to modules being imported, so that one could explicitly say hey, pygtk, I want the sane init style and be backwards compatible with the old behavior. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Keyboard layout: switching from Amharic US
James wrote: The page at http://wiki.laptop.org/go/Ethiopian_Setup helpfully suggests that: You can toggle between the us and the et layouts by hitting the group switch key, which is mapped to the rightmost key below enter (labeled multiply/divide on US keyboards). In my experience, pressing this key inserts an x character. No combination of modifier keys along with the group switch key seems to have the desired effect. What build are you using? The language key was missing in the Ethiopian keyboard until ~3 weeks ago. It should have been in Update.1 for some time. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Keyboard layout: switching from Amharic US
Walter Bender wrote: olpc-update lives in the /usr/sbin directory, which should be in your path on the root shell on the console. But if not, just use the full pathnames. For convenicence, in recent joyride and update-1 builds I made a change to re-add /sbin and /usr/sbin to the path of unprivileged users too. I always thought this split between bin and sbin was a very bad idea in UNIX! -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Include olpc-audit in olpc-utils?
Michael Stone wrote: olpc-audit is a filesystem-status-verifier written for us by Marcus Leech. I think it would be decent to include in olpc-utils because, analogous to the network and battery status detectors, it's handy for figuring out if people have done funny things to their filesystem. Also, I'd like to be able to run it from inside pilgrim or puritan chroots before releasing builds. Sure! Anyway, I've prepared patches to include it in olpc-utils in the 'master' branch of http://dev.laptop.org/git/users/mstone/olpc-utils (and the other usual urls) Would you consider merging them? The patches look fine, but next time don't manually bump the package revision and edit the spec file log: I have a Makefile rule to automate this. Also, would you mind doing the committing and package rebuilding on your own? I'm still wandering around in Australia and I don't seem to find a decent Internet connection anywhere. (or I can do it later if it's not urgent) -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: huge init footprint
James Cameron wrote: I'm at a conference where anyone with an XO gets urgently questioned about their version management, so I've not got one with me right now ... what does lsof(1) say this init process has open, and what does /proc/1/stat* say about the memory cost? It has no open files, but /proc/1/maps reveals that we're keeping much of the initrd still mapped into memory. And without swap, it's not going to be paged out. I do recall there was a really good reason why our init is in Python ... activation and so forth. Does it deserve recoding just to save 5Mb? Maybe we can save these 5MB by just refactoring it a bit. For example, the python part could be run only in the activation case. This would also reduce boot time by some extent. Alternatively, we could exec() the regular init from the OS as the last thing. C.Scott may have some better ideas. I filed #6246 so we don't forget. BTW: a similar issue is that olpc-hardware-manager costs about 4MB. All it does is being a dbus service for writing a few sysfs files. It could be rewritten in C very quickly and even folded into ohm. So far, reducing the number of Python processes seems to be the easiest way to free up some memory for the activities and reduce startup time. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 1605
Build Announcer v2 wrote: http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1605 Changes in build 1605 from build: 1604 Size delta: -1M -bash 3.2-19.fc7 +bash 3.2-20.fc7 --- Changes for bash 3.2-20.fc7 from 3.2-19.fc7 --- + fix cursor position when prompt has one invisible character (#358231) + dropped examples/loadables/ from docs, since it wasn't possible to build them + fix #286861: Wrong input confuses bash's arithmetic unit permanently + fix #344411: $RANDOM stays the same when job executed in the background + Added bash32-021 upstream official patch + Added bash32-025 upstream official patch + Added bash32-024 upstream official patch + Added bash32-023 upstream official patch + Added bash32-022 upstream official patch + Added bash32-018 upstream official patch + Added bash32-020 upstream official patch + Added bash32-019 upstream official patch + Rebuild + Update to the Improve bash $RANDOM pseudo RNG (bug #234906) + Changed spec file License to GPLv2+ + Improve bash $RANDOM pseudo RNG (bug #234906) + Quote environment variables in the post scriptlet to prevent upgrade + Patchlevel 17 (bug #241647). + Clarification in the ulimit man page (bug #220657). + Rebuild to link with libtinfo instead of libncurses. + Avoid %makeinstall (bug #225609). + Reinstated this change: + Post requires ncurses (bug #224567). + Reverted this change: + Added triggers for install-info (bug #225609). + Reverted this change: + Post requires ncurses (bug #224567). + Added triggers for install-info (bug #225609). + Use full path to utilities in scriptlets (bug #225609). + Fix missing sh-bangs in example scripts (bug #225609). + Post requires ncurses (bug #224567). + Removed Prefix tag (bug #225609). + Fixed BuildRoot tag (bug #225609). + Removed trailing full-stop from summary (bug #225609). + Spec file is now UTF-8 (bug #225609). + Removed obsolete Obsoletes (bug #225609). + Moved 'make check' to new 'check' section (bug #225609). + Removed uses of RPM_SOURCE_DIR (bug #225609). + Fixed macros in changelog (bug #225609). + Changed tabs to spaces (bug #225609). + Slightly better .bash_logout (bug #223960). + Back out rmatch change introduced in 3.2 (bug #220087). Wow! One would never expect so many changes for such an insignificant 3.2-19 - 3.2-20 upgrade :-) -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
splitting djvulibre
Tomeu Vizoso wrote: On Tue, 2008-01-29 at 09:15 +0100, Reinier Heeres wrote: What's dragging in djvulibre, desktop-file-utils and xdg-utils? djvulibre is dragged in by Read, which in the current joyride also supports reading djvu files. Don't know about the other two... xdg-utils is dragged in by djvulibre, I think. This one dependency seems useless to us. It's only used to do the register-djvu-mime and register-djvu-menu in the post-install scriptlet, which we don't need. I guess we could split this package into djvulibre-libs and djvulibre (containing just the apps). Matthias, could you please do that? Or, if you have no time, would you mind if we go on and do it? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: non-Sugar but core software?
Holger Levsen wrote: for Debian I've started http://wiki.debian.org/DebianEdu/OLPC/ToDo yesterday, to document what is working and whats not and what work needs to be done. In general, a document describing how the XO-1-fedora installation differs from a plain fedora would be very much appreciated, also by the OpenWRT developers. A quick (although low-level) way to find out, is going through the Fedora pkgdb to find the complete list of packages we've forked in the OLPC-2 collection: https://admin.fedoraproject.org/pkgdb/collections/ For each one of these, you can checkout the cvs source: cvs -d :pserver:[EMAIL PROTECTED]/cvs/pkgs co PACKAGE Then you can diff between the version in F-7 and the one in OLPC-2. Many changes are not OLPC specific and will hopefully be merged back with our upstreams as soon as the relevant maintainers find the time to clean them up. I've been doing some of this work for my packages, but I'm afraid there's a lot more to be done, especially in Xorg. Feel free to beat me! This list does not include a small number of packages that need to be moved to koji and have not made it yet for various reasons. You can find all these by grepping for olpc-joyride in our build logs: http://xs-dev.laptop.org/cscott/olpc/streams/joyride/latest/devel_jffs2/build.log Finally, while I have no time to do much of this work myself, I'm glad to help integrate our customizations into Debian, OpenWRT, or any other distro willing to support the XO. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
huge init footprint
Hello, I just noticed that our init uses up an unusual amount of memory (5MB!), almost as if it was a Python process. And in fact, it seems to be really a python process spawned by our initrd. And since the initrd cannot possibly use the system libraries from the jffs2 partition, almost all these mappings are unshared. Now, to conserve resources, it would be nice if we could exec() the real init just before passing control to the rc scripts. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Battery charging and display intensity in joyride-1594
Mark Bauer wrote: Second issue.. Not touching the system, the display intensity keeps jumping up and down. This is ohm suspending the laptop after 20 seconds of inactivity, and network traffic waking it up shortly after. I guess we could fix it by not undimming the display if we wake up just because of network activity? I am still on AC, no need to dim the display, it is just a bit annoying. There's no (easy) way to tell whether your AC has an infinite amount of cheap energy or of your grandpa is cranking to keep the laptop going. I also find it annoying, and I guess we could make the idle timeout tunable somehow. For now, you can tune it by killing ohm. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 1591
Build Announcer v2 wrote: http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1591 Changes in build 1591 from build: 1590 Size delta: 1M Could we keep the decimals for this figure? Maybe I'm too being picky :-) -sugar-evince-python 2.20.1.1-1.olpc2 +sugar-evince-python 2.20.1.1-2.olpc2 -bootfw q2d09-3.olpc2.unsigned +bootfw q2d10-1.olpc2.unsigned +desktop-file-utils 0.12-4.fc7 +djvulibre 3.5.18-2.olpc2 -sugar-evince 2.20.1.1-1.olpc2 +sugar-evince 2.20.1.1-2.olpc2 +xdg-utils 1.0.2-3.fc7 What's dragging in djvulibre, desktop-file-utils and xdg-utils? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Splitting boost
Build Announcer v2 wrote: -libicu 3.6-18.fc7 +libicu 3.6-20.fc7 This library set is a whopping 13MB in size. It is only used by boost, which is only used by gnash. To break this nasty dependency chain, observe that only libboost_regex.so links libicudata.so, which gnash does not need. So I think we should split boost in two or more subpackages. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: patch for olpc-session
(I've cc'd devel@)
Alexios Zavras wrote:
However, I saw no way of providing the
Option XkbOptions grp:ctrl_shift_toggle
line.
Could you add support for a XKB_OPTIONS variable,
similar to the other XKB_* ones ?
This would be translated to -option $XKB_OPTIONS string
for the setxkbmap call, of course (careful, no final 's' in -option)
More worringly, we did not specify a manufacturing tag
to specify xkb options, so that olpc-configure could do
the right thing once we have an actual SKU for it.
I propose using KO for this purpose.
I can obviously send you the 2-line patch,
but I thought you might find it insulting... :-)
Oh, not at all! I'm currently traveling to Australia
and I'm unable to test properly. See if the following
code works for you. I've already pushed it to git,
but I've not yet rebuilt the olpc-utils package out of it.
diff --git a/olpc-session b/olpc-session
index 3e7797e..2d3712d 100755
--- a/olpc-session
+++ b/olpc-session
@@ -34,11 +34,14 @@ export LANG
xset m 7/4 0
xset r rate 500 30
+[ -n $XKB_OPTION ] XKB_OPTION=`echo $XKB_OPTION | sed -e 's/\b/-option
/g'`
+
# set keyboard layout
setxkbmap \
${XKB_MODEL:+ -model $XKB_MODEL} \
${XKB_LAYOUT:+ -layout $XKB_LAYOUT} \
- ${XKB_VARIANT:+ -variant $XKB_VARIANT}
+ ${XKB_VARIANT:+ -variant $XKB_VARIANT} \
+ $XKB_OPTION
# disable repeat on several keys
xset -r 9 -r 220 -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 79 -r \
--
\___/
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: compiler / glibc optimization
Rob Savoye wrote: (http://wiki.gnashdev.org/wiki/index.php/Building_OLPC_Tools) Is the geode-patched gcc4.2.1 preferrable for integration with the XO? I think Bernie added this to the gcc builds for the XO. I think he also added the patched glibc as well. As I use my own toolchains, I hadn't checked... :-( Support for a geode arch in the distribution packaging tools was a missing prerequisite to integrate this work cleanly. Dennis thought yum about it a while ago, and the rpm part has recently been upstreamed. Now I guess all that's left to do is adding a geode subarch in koji and use it for some selected packages, such as glibc. We're already planning to do optimization work during the Update.2 timeframe. Here's an experimental rpm based on Rob's work ported forward to glibc-2.7: http://www.codewiz.org/pub/olpc/glibc-geode-2.7/ -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
OLPC promotes terrorism
http://erratasec.blogspot.com/2008/01/why-olpc-promotes-terrorism.html Didn't you know that Python was a communist language? If any chip maker was paying for this bullshit, they'd be really wasting their money! -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC and GLX
Bryan Duff wrote: After compiling in mesa source to get GLX working on the FC7-based builds. Running `glxgears -fullscreen` I get ~25 fps. Compared to Ubuntu which gets 65 fps, this is rather poor. One last thing: I'm very curious about this disparity: could you please provide more details? What versions of Mesa and the X servers have you been using? Was the depth exactly the same? Could you run glxinfo on both systems? How did you build the Fedora X server? What compiler did you use and what optimization flags? There should be no particular reason why Ubuntu would have better *software* GL rendering performance than Fedora, although hardy ships with gcc 4.2, which could make a big difference. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC and GLX
(please forgive minor mistakes as I was in a hurry and I had no time to double-check some of the facts reported below. Feel free to point out corrections, of course). Bryan Duff wrote: After compiling in mesa source to get GLX working on the FC7-based builds. Running `glxgears -fullscreen` I get ~25 fps. Compared to Ubuntu which gets 65 fps, this is rather poor. I think the Ubuntu performance shows that 3D (albeit simple 3D) is very possible and worthwhile. Nobody ever thought 3D was impossible or unfeasible on an full blown x86 CPU at 466MHz, when it very clearly was possible even on the 8bit, 1MHz, C64 with no hardware floating point support. My question is: why are you trying so hard to achieve *unaccelerated*, *indirect*, *GLX* support when it would be much easier and faster to just use OpenGL in-process and then XPutImage the resulting buffer? I've tried the amd and fbdev drivers - they make no performance difference. Neither does i386 versus i586 (w/ mmx and 3dnow! included in cflags). Of course it makes no difference because the server-side software renderer gets used in both cases. And this renderer happens to be exactly the same code of Mesa, only built in a slightly different way. There's no need to run benchmarks to find this out. A simple inspection of the source code would reveal that there are no hardware accelerated paths in Mesa for the Geode. Although, some primitive form of GL acceleration could certainly be implemented for very trivial operations. I haven't tried DRI. I don't understand how it would help if I understand DRI correctly, but perhaps I'm missing something. I have no idea if processes that are re-niced automatically, or have some sort of resource limitation. Uh? DRI is the in-kernel support for DMA, command queue completion interrupts and now TTM and memory management for *direct* rendering clients. On the other hand, the indirect (i.e. server side) rendering path you're using historically happened without DRI's help because it was unaccelerated anyway. The X server still had some interaction with DRI in order to coordinate window management operations with direct rendering clients. Recently, Kristian Høgsberg did a huge architectural shift in order to add 3D acceleration to the server-side Mesa renderer. This is AIGLX. While AIGLX is somewhat slower than direct rendering due to the overhead of the GLX wire protocol, and generally not recommended for 3D intensive games, it is no doubt the way to go to achieve 3D desktop effects, and to redirect 3D clients to off-screen buffers so that their output can be further processed. At this time, the AIGLX effort is halfway finished: the basic features work beautifully and efficiently, but XVideo does not yet play by the rules, and mouse input keeps ignoring the 3D transformations. Another big show stopper for a fully 3D Linux desktop is that it needs aggressive graphics card memory usage in a multitasking environment, which requires a sophisticated memory manager with a smart swap-in policy to keep things fast on a crowded desktop. Although an implementation already exists, the underlying design is still being debated and could possibly undergo further changes before it will find its way into the kernel. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Switch to a sane packaging and upgrade system
C. Scott Ananian wrote: My thoughts are that I would like to write a yum post-install hook which stashed a copy of the RPMs installed to /home/olpc/.rpmcache. A post-upgrade hook (in olpc-configure) would attempt to reinstall all rpms found in /home/olpc/.rpmcache. This would address this common use-case (as well as my own: I keep having to re-install emacs). Yum already downloads all the rpms in /var/lib/yum/dist/packages. I don't think we need to do anything special. Volunteers to write the yum hook welcome; the post-upgrade hook is simple. I don't think it's necessary. If a yum update gets interrupted, there are two possibilities: 1) the system does not boot any more 2) the system boots normally In (1), you need to reflash or boot from an older snapshot. In case (2), you could resume yum normally and it will not even need to download any packages. But you could as well do (1). So my proposal is: let's extract the checkpointing code from olpc-update and use it as a wrapper for invoking yum. safe-yum? It should be much easier and safer. The downsides of using yum remains that it's a real memory hog and it will take additional disk space for all the rpms. Developers can learn to get around these limitations, but automated upgrades would fail very frequently due to these problems. A very effective solution is reducing the number of packages that yum has to deal with. Fedora is around 11 *thousand* packages. OLPC ships with 450. Clearly, we could save a lot of time and memory by disabling the huge Fedora repository. Dennis, what do you think? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC-Devel] Switch to a sane packaging and upgrade system
Iain (XO) Davidson wrote: I definitely discovered the issue, when I installed a bunch of packages via 'yum' (like 'update', and programs mc, vlc, emacs,etc). Then suddenly they were gone after an update. Doing something via 'yum update' and some trickery with the XS server / DNS / creative package naming, might be the solution. Like, having an easy method to 'yum update' via GUI after a 'olpc-update'. While our update scheme would bother me a lot if I had to use it myself, I think our target users would be better served by a simple automated update scheme for the system. Also, think of the support issues for users who have been messed with their systems by adding and removing random packages. At the same time, we have yum for the advanced users which is very flexible, although far from being perfect. I wish we could replace yum with apt4rpm, but I don't see it happening unless someone volunteers to perform all the needed integration work. Just my 2 cents to add to yours, :-) with mine, we have 6 cents already! -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Violent games on the OLPC Activities page
Tom Hannen wrote: I disagree with the idea of censoring games based on violence. I think that a warning at the top of any page should be sufficient. While I agree with your your anti-censure POV, I think the whole thread is moot as it's based on the assumption of Doom II being a *violent* game. People have clearly forgot what Doom II used to look like: http://images.google.com/images?q=doom+II Spooky, maybe? Bah. Compared to modern 3D graphics, it could just be described as pathetic by any non-geek observer. Games are just another form of creativity... Should we also remove any links to violence in books and artwork, within Wikibrowse for example? I suggest we also take off my XaoS activity, because its name could hint at anarchic ideas and corrupt the young minds of our users :-) -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: font size in console
Albert Cahalan wrote: Many people report that that font is also too small. You can try my 15x30 font, which many people love. It's attached to this email. It's already the second time you attach your font. Have you seen my message where I ask you where the glyphs came from and under what license the font could be released? The first step to get it accepted on the OLPC would be to contribute it to the kbd project. The current maintainer also happens to be the Fedora packager, and I'm in contact with him for our console keyboards. Once this is upstreamed, we could consider making your font the default. I liked it and would vote for it. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: disabling root and olpc passwords
Albert Cahalan wrote: Bernardo Innocenti writes: What we're actually doing is just to disable them in the default installation so that malicious activities cannot login as root or olpc and basically own the system. This is NOT needed at all. I wrote and tested an /etc/pam.d/su modification that will prohibit all non-wheel users from getting su to work. What use is it if an application can login, su or sudo as user olpc with no password and _then_ su to root? You can close all the open doors one by one by ruling out logins with empty passwords like ssh does, but then what would be the difference between an empty password and no password at all? Captain Obvious just told me that on any UNIX system, setting an empty password should enable a user to login without typing a password, while disabling the password should instead disable logins by that user. The ssh default of not accepting empty passwords is just a bit too paranoid for some scenarios, and not paranoid enough for others (why not also disallow stupid passwords? :-) Apply both if you wish, but either alone will do nicely. There are other ways too, like SE Linux. While I would certainly consider improvements, what's wrong that we're trying to fix with this simple solution we already adopted? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Marvell
immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views the University of Technology, Sydney. Before opening any attachments, please check them for viruses and defects. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: disabling root and olpc passwords
Mikus Grinbergs wrote: The way I have my G1G1 system set up (I have no wireless) I *need* to ftp in. For that, I have set a password for olpc. It would be ok with me to set up a different user+password for ftp, but would *not* be ok for password support to be disabled. No problem: just set a password with passwd for either root or olpc. You could even create new users if you want to. Only, be careful when running the olpc-update script: it will reset all your changes to the OS. Also, I don't believe in the political correctness of not using root. Me neither. I login as root as much as I like on my computers :-) I do need to install/remove/change things as root, and *strongly* prefer not to use 'sudo' for that -- I log in as root, and am willing to take the risk of committing a disastrous mistake. Here, too, having a password seems natural to me. Sure. To me to. You and me are clearly not the kind of audience for which we had to disable the passwords. Thus, you're free to re-enable them. I agree with the aim of making the OLPC simple to use, but please don't take passwords away entirely. You seem to be under the impression that we compiled-out the ability to set passwords in the system. That is not true. What we're actually doing is just to disable them in the default installation so that malicious activities cannot login as root or olpc and basically own the system. p.s. I presume the existing 'passwd' command was taken from Fedora. It is too paranoid, forbidding too_short passwords, too_homogeneous passwords, too_similar passwords, etc., etc., etc. Such rules may be needed for a datacenter - but for a schoolroom? Here at MIT the XOs have public, globally accessible IPs, and the logs are full of ssh connections trying random passwords. In deployments, we're using primarily IPv6 and I was under the impression we will not need NAT gateways. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: disabling root and olpc passwords
Mikus Grinbergs wrote: The way I have my G1G1 system set up (I have no wireless) I *need* to ftp in. For that, I have set a password for olpc. It would be ok with me to set up a different user+password for ftp, but would *not* be ok for password support to be disabled. No problem: just set a password with passwd for either root or olpc. You could even create new users if you want to. Only, be careful when running the olpc-update script: it will reset all your changes to the OS. Also, I don't believe in the political correctness of not using root. Me neither. I login as root as much as I like on my computers :-) I do need to install/remove/change things as root, and *strongly* prefer not to use 'sudo' for that -- I log in as root, and am willing to take the risk of committing a disastrous mistake. Here, too, having a password seems natural to me. Sure. To me to. You and me are clearly not the kind of audience for which we had to disable the passwords. Thus, you're free to re-enable them. I agree with the aim of making the OLPC simple to use, but please don't take passwords away entirely. You seem to be under the impression that we compiled-out the ability to set passwords in the system. That is not true. What we're actually doing is just to disable them in the default installation so that malicious activities cannot login as root or olpc and basically own the system. p.s. I presume the existing 'passwd' command was taken from Fedora. It is too paranoid, forbidding too_short passwords, too_homogeneous passwords, too_similar passwords, etc., etc., etc. Such rules may be needed for a datacenter - but for a schoolroom? Here at MIT the XOs have public, globally accessible IPs, and the logs are full of ssh connections trying random passwords. In deployments, we're using primarily IPv6 and I was under the impression we will not need NAT gateways. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC devel] su/sudo or not to sudo/su (was PATCH: add --loginpause to mingetty)
Simon Schampijer wrote: does not auto-complete. The bash-completion (141K) package solves this, which I tried on my F8 machine. Maybe worth an inclusion since the completion works as well for other cases like: yum in[tab] (even so in the case of 'yum install b[tab]' it takes a while to list the packages). I love bash-completion and I use it everywhere, but I'd not support adding it to the base OS for the same reason we do not install vim-enhanced, links, lftp and all the other nice console tools. The default console environment should be just good enough to perform system recovery, and special administrative tasks which have no UI yet. Our OS images have grown over 300MB! I think we could get them back to 200MB or so just by dropping useless dependencies and splitting a few packages. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: autologin and Console font (Was: root password)
(cc kbd, alexey, andries) Albert Cahalan wrote: On Jan 3, 2008 4:06 AM, Bernardo Innocenti [EMAIL PROTECTED] wrote: Albert Cahalan wrote: I quite like this Press ESC twice for shell solution. Reminds of the FidoNet era, if you're old enough to know what I'm talking about. Merely switching to the console should do the job. Linux provides an ioctl, VT_WAITACTIVE, to let a program wait for a tty to become activated. With the SAK solution, child death will notify the parent process. The parent can then start getty. For now, we added an option to mingetty to wait for enter before proceeding to the autologin. And I did the same for agetty on ttyS0. These changes landed in joyride yesterday. Check it out and let me know if you like it. If you write a minimal autogetty, I'd be willing to take it for the additional memory saving. But please, also do the packaging and fedora review process. I have about 2000 glyphs, but Linux currently can't handle more than 256 (or 512 w/o bright backgrounds) because the internal representation is still tied to VGA. I thus trim my font to the regular PC character set. If the kernel were fixed though, you could have 2000 glyphs. The 256-glyph file is attached. Looks nice! I'm soon going to branch the kbd package in OLPC-2 to add a couple of console keyboard maps that Walter made. We could use this opportunity to add your font. Please, also send me the full font, and let me know under what license the original glyphs were. I just got in contact with the Fedora and top-level kbd maintainers (reading us on cc) to push our changes back upstream. Is it ok if I contribute your font upstream? The project has failed if it doesn't create new UNIX die hards. These will be the people who drive the future economy. The non-nerd kids are getting toys. We can expect a (small) percentage of the kids to become very good hackers. Didn't we all learn this very same way? :-) -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ 15x30pc.psf.gz Description: GNU Zip compressed data ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #5859 NORM FutureF: Need a way to tactily distinguish keys on top row
Walter Bender wrote: All three bars along the top row of the keyboard act as analog sliders when the FN key is held down. They have four distinct key assignments under normal operation. Yes. And each one of the analog sliders is actually *8* keys rather than just 4. We currently have no mappings in libX11 for these. Me and Jim know about the whole story. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
PATCH: add --loginpause to mingetty
Hello Florian,
the attached patches add an option to pause login until the user hits
a key.
We need something like it on OLPC because:
- we don't want to set an empty password for either user root or olpc
- at the same time, we want to allow users to login as root at the
console
- finally, we do not wish to waste memory on shells the user hasn't
yet used
The security model we are implementing is very different from UNIX: we
ultimately trust the user at the console, but we don't trust applications
and we don't want them to gain root privileges using su or sudo with no
password.
I'm committing these changes to the OLPC-2 branch of mingetty in
Fedora CVS. Please, let me know you'd like to merge them or
something similar.
--
\___/
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/
diff -rup mingetty-1.07.orig/mingetty.8 mingetty-1.07/mingetty.8
--- mingetty-1.07.orig/mingetty.8 2003-05-14 04:55:43.0 -0400
+++ mingetty-1.07/mingetty.8 2008-01-09 18:17:06.0 -0500
@@ -6,6 +6,7 @@ mingetty \- minimal getty for consoles
[\-\-noclear] [\-\-nonewline] [\-\-noissue] [\-\-nohangup] [\-\-nohostname]
[\-\-long\-hostname] [\-\-loginprog=/bin/login] [\-\-nice=10] [\-\-delay=5]
[\-\-chdir=/home] [\-\-chroot=/chroot] [\-\-autologin username]
+[\-\-loginpause]
.I tty
.PP
.SH DESCRIPTION
@@ -62,6 +63,11 @@ Log the specified user automatically in
a login name and password. Check the \-f option from
.B /bin/login
for this.
+.TP
+.B \-\-loginpause
+Wait for any key before dropping to the login prompt.
+Can be combined with \fB\-\-autologin\fR to save memory by lazily spawning
+shells.
.PP
.SH ISSUE ESCAPES
.B mingetty
diff -rup mingetty-1.07.orig/mingetty.c mingetty-1.07/mingetty.c
--- mingetty-1.07.orig/mingetty.c 2004-01-03 08:15:56.0 -0500
+++ mingetty-1.07/mingetty.c 2008-01-09 18:10:15.0 -0500
@@ -74,6 +74,8 @@ static char *ch_dir = NULL;
static int priority = 0;
/* automatic login with this user */
static char *autologin = NULL;
+/* try to read a char before dropping to login prompt */
+static int loginpause = 0;
/* error() - output error messages */
static void error (const char *fmt, ...)
@@ -283,6 +285,10 @@ static void do_prompt (int showlogin)
}
fclose (fd);
}
+if (loginpause) {
+ puts([press ENTER to login]);
+ getc(stdin);
+ }
if (nohostname == 0)
printf (%s , hn);
if (showlogin)
@@ -327,11 +333,13 @@ static void usage (void)
[--nohangup] [--nohostname] [--long-hostname]
[--loginprog=/bin/login] [--nice=10] [--delay=10]
[--chdir=/home] [--chroot=/chroot] [--autologin=user]
+ [--loginpause]
tty' with e.g. tty=tty1, progname);
}
static struct option const long_options[] = {
{ autologin, required_argument, NULL, 'a' },
+ { loginpause, no_argument, loginpause, 'p' },
{ chdir, required_argument, NULL, 'w' },
{ chroot, required_argument, NULL, 'r' },
{ delay, required_argument, NULL, 'd' },
@@ -366,7 +374,7 @@ int main (int argc, char **argv)
putenv (TERM=linux);
#endif
- while ((c = getopt_long (argc, argv, a:d:l:n:w:r:, long_options,
+ while ((c = getopt_long (argc, argv, a:p:d:l:n:w:r:, long_options,
(int *) 0)) != EOF) {
switch (c) {
case 0:
diff -u -p -r1.2 mingetty-1.00-opt.patch
--- mingetty-1.00-opt.patch 9 Sep 2004 08:31:33 - 1.2
+++ mingetty-1.00-opt.patch 10 Jan 2008 00:15:11 -
@@ -1,10 +1,11 @@
--- mingetty-1.00/Makefile.rpm Mon Mar 4 15:27:11 2002
+++ mingetty-1.00/Makefile Mon Mar 4 15:27:34 2002
-@@ -1,6 +1,6 @@
+@@ -1,6 +1,7 @@
DESTDIR=
CC=gcc
-CFLAGS=-O2 -Wall -W -pipe -D_GNU_SOURCE
+CFLAGS=$(RPM_OPTS) -Wall -D_GNU_SOURCE
++LDFLAGS=$(RPM_OPTS)
MANDIR=/usr/share/man/man8
SBINDIR=/sbin
Index: mingetty.spec
===
RCS file: /cvs/pkgs/rpms/mingetty/devel/mingetty.spec,v
retrieving revision 1.19
diff -u -p -r1.19 mingetty.spec
--- mingetty.spec 8 Jan 2008 09:39:25 - 1.19
+++ mingetty.spec 10 Jan 2008 00:15:11 -
@@ -2,11 +2,12 @@ Summary: A compact getty program for vir
Name: mingetty
Version: 1.07
License: GPLv2+
-Release: 8%{?dist}
+Release: 9%{?dist}
Group: System Environment/Base
URL: http://sourceforge.net/projects/mingetty/
Source: mingetty-%{version}.tar.gz
-Patch: mingetty-1.00-opt.patch
+Patch0: mingetty-1.00-opt.patch
+Patch1: mingetty-1.07-loginpause.patch
BuildRoot: %{_tmppath}/%{name}-root
%description
@@ -15,8 +16,10 @@ use only on virtual consoles. Mingetty
lines (you should use the mgetty program in that case).
%prep
+rm -rf $RPM_BUILD_ROOT
%setup -q
-%patch -p1
+%patch0 -p1
+%patch1 -p1
%build
make RPM_OPTS=$RPM_OPT_FLAGS
@@ -38,6 +41,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man8/mingetty.*
%changelog
+* Wed Jan 09 2008 Bernardo Innocenti [EMAIL PROTECTED] - 1.07-9
+- add mingetty-1.07-loginpause.patch
+- improve mingetty-1.00-opt.patch to enable cross building on a 64bit host
+
* Tue
Re: jffs zlib tuning
(cc CP, aleph) David Woodhouse wrote: 1. Did anybody profile the kernel while reading files? Last thing I red on this list is that the profiler does not work on the XO in kernel mode. Did anybody fix that I believe that standard kernel profiling (on timer ticks) has always worked, and even continues to work even though we use a tickless kernel now. I think oprofile also works. oprofile works, but for some reason it cannot generate call graphs. It vaguely remember that the problem was that on the Geode we were using sw timers rather than NMI as a timing source. Without call graphs, benchmarking our rendering stack has been somewhat harder. You'd find lots of time spent in generic functions such as memcpy(), without a clue why. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: jffs zlib tuning
NoiseEHC wrote: It is unfortunate that it was not discussed on this list. Anyway, at least I have learnt writing Linux drivers in the process... What compression can be achieved with LZO? Last time I used it only for real time compression (backup), and not because of the compression ratio. (I suppose that you have tested it.) Note that we compress 4KB blocks in jffs2. With small block sizes, algorithms with better compression tend to loose most of their advantage. We can't say much until we benchmark lzo vs gzip with small files. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: jffs zlib tuning
NoiseEHC wrote: 4. Bernardo, as I imagine you are compiling kernels every day. If I send you a patch (normally a rewritten inffast.c), would you test it on a real XO machine, please? I don't build kernels every day, but I'd be delighted to test such an improvement. And if you make it clean enough, I'm sure it would have an easy way into the mainline kernel. However, I recommend hacking in libz first, making it work with gzip, and staert porting it to the kernel next step. Debugging and benchmarking in userspace is *so* much easier. Also, I'd be very surprised if such an obvious optimization hadn't been tried already in 20+ years of gzip. Try digging around: you may find that it's not worth it. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: GLX available?
Randy Heiland wrote: Can someone tell me if GLX is possible on OLPC? 'glinfo' tells me it's not there. If so, what's the .rpm? Since our GPU cannot support hardware 3D acceleration, and we don't even ship libGL, I've disabled the GLX at build time in the X server. Software based GLX could be made to work, but it would be terribly inefficient. If you have code that renders through the GL API, you'd get better performance by rendering in-process and then transferring the resulting image to the server. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: wiki is being spammed with huge numbers of new pages
ffm wrote: User blocked, all articles created by user deleted. Don't they ever learn that vandalism is pointless with a wiki because it can be undone faster than it was done? Thank you for fixing it. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: root password
Albert Cahalan wrote: I thought so to, but testing seems to show that pam_wheel.so will only protect transitions to the root account. It does not protect olpc, at least not without some undocumented option. Are you thinking that we should disable the password for the olpc user too? Well, we should: if we don't, malicious activities will be able to login as olpc :-) Using just 2 shells was a way to save some memory. Kids will use none. Whoever needs more can easily edit /etc/inittab. Shall I write you a tty-watcher program in assembly code? This really shouldn't cost much memory. Even with glibc, I doubt the dirty memory was all that much. BTW, I'm serious about the assembly code. Well, if it's just for fun... but I think the Python developers would not appreciate it :-) Seriously, before we start coding solutions, let's first reach consensus with the security team on how we should handle login. Otherwise we risk wasting effort. I quite like this Press ESC twice for shell solution. Reminds of the FidoNet era, if you're old enough to know what I'm talking about. Good point, but if we left just that in place, we'd have to ask people to use the ugly text console more often, where the keyboard works partially and there's no cut paste. It's not ugly if you ship the nice 15x30 font I made. Where is it? Does it include a decent amount of unicode glyphs? sun12x22 has too few of these, so it doesn't even support many European languages. Cut-and-paste can be fixed, with the difficulty depending on how perfect you want it. One can run gpm. This can be started when a user logs in on the console. One could even write something to feed that into the X clipboard and back. Yes, theoretically. But we don't ship gpm and we don't want to put much more effort on improving the console environment that only UNIX die hards like me and you enjoy using when we still have a journal that eats files and a mouse cursor that flashes when you render below it. I'm almost going to reiterate my old black text on white bg console patch, which nobody seemed to appreciate :-) -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Is it possible to disable the jingle at boot ?
Mr frÿffe9dÿffe9ric pouchal wrote: I would like to disable the jingle at boot time you can lower the volume while the jingle is playing. OFW will store it and remember it for the next boot. I wish the rest of our software stack was equally refined. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Is joyride broken?
I see no new builds since Dec 29, and the last few builds were not even announced by bert's script. What happened? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Tom Sylla wrote: http://openbios.org/viewvc/cpu/x86/pc/olpc/lxmsrs.fth?view=markuprevision=739root=OpenFirmware has: msr: .1810 fdfff000.fd000111. \ Video (write through), fbsize which is setting the framebuffer as write-combining. (the write through comment is incorrect) This takes care of the physical mapping, but how would userspace be able to mmap the framebuffer into virtual memory without additional MMU programming? I was under the impression that we also need to cover the whole region with small 4KB MMU pages. This degrades performance somewhat due to TLB misses when the CPU accesses the framebuffer. But I must confess I have limited understanding of the Geode architecture, so I may be overlooking something. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Is joyride broken?
Bert Freudenberg wrote: Btw, pilgrim.laptop.org seems to be down ... Again? We had a short (0.5sec) power outage at 1CC a few days ago. Some machines which are not under UPS may have died. Someone please check pilgrim in the server room. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC - Fedora packages (Was: New update.1 build 669)
(cc fedora-devel) Jim Gettys wrote: Yes, these are packages that had landed in joyride from upstream while no one was looking. We need to get the build announcer to give us insight into upstream package updates (on Dennis' shoulders). There are several of these that are worth further investigation: we need to check the diffs and changelogs on python and matchbox, and any other core components; and all the changelogs need vetting. I also see this as an important goal, and not just to catch the security and stability fixes. As dwmw said, the more we drift away from upstream packages, the harder it will be to rebase. After Update.1, I'll refresh all the packages I maintain, and I invite others to do the same. That said, merging our changes in the Fedora development packages makes me a little uncomfortable. I'm not following Fedora development *that* closely, and the true maintainers of those packages certainly know better. So, it may be a better idea to show them our changes and ask them what to do. There are also a few packages, such as initscripts, which I think we don't ever want to merge back. The two systems are just too different and trying to support both in one package is going to be painful and useless. For X, I'm working to rebase on 1.5, of which a pre-release has already been in rawhide for some time. Perhaps we should discuss what to do about the kernel: it's clear that we'll need an OLPC-specific build variant, and for quite some time I think we'll be unwilling to update our kernel consistently with Fedora. But here I'm just guessing. Dilinger and dwmw may have different plans. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
John Richard Moser wrote: YES. You can mix and match your page sizes, have some pages 4MiB and some 4KiB. If a block of i.e. the heap is 4MiB long, the kernel can technically relocate all 1024 involved pages so they're physically contiguous and aligned to a 4MiB boundary, and then remap them as one huge page. It would have to handle an munmap() or brk() (shrinking) call by breaking it back up; but it could be done. There's only partial vm support for 4MB pages in Linux, and only for special cases. On a few systems, I get: trinity:~# cat /proc/meminfo | grep Huge HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 Hugepagesize: 4096 kB bender:~# cat /proc/meminfo | grep Huge HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB [EMAIL PROTECTED] ~]$ cat /proc/meminfo | grep Huge HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 Hugepagesize:16384 kB daneel:~# cat /proc/meminfo | grep Huge (no output) I wonder if huge pages are even used for anything? There's no reason with video memory sizes like 4M, 8M, 16M, 32M, 64M, 256M, and these days even 512M that these kinds of mappings should use 4KiB pages anymore. Unlike the heap or anonymous mmap() segments, video memory doesn't change size and doesn't eat physical memory (*cough*); and unlike file-backed shared mmap() segments, you can't free up space by evicting the contents from memory if nobody's using it. It's probably not being done because of this feature is very recent, and maybe immature. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
root password
I think we should re-enable the empty root password for Update.1. The reason why is that we have plenty of documentation in the wiki and elsewhere suggesting people to login as root or to su as root. There should be at least a transition period so the support people don't get flooded with questions on how to login as root. We could also use pam_wheel to let olpc become root with no password using the friendlier su in addition to sudo. Even better, we could put /sbin/mingetty --noclear --autologin root tty1 in inittab to circumvent the issue altogether. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: root password
Albert Cahalan wrote: I got it to work with a different pam module, and placed that info into trac. http://dev.laptop.org/ticket/5537 #%PAM-1.0 auth sufficient pam_rootok.so auth requiredpam_succeed_if.so use_uid user ingroup wheel auth include system-auth account sufficient pam_succeed_if.so uid = 0 use_uid quiet account include system-auth password include system-auth session include system-auth session optionalpam_xauth.so This seems really equivalent to using pam_wheel.so. I think we should put your change as yet another pilgrim hack (rather than branching coreutils to edit /etc/pam.d/su). This is an excellent idea. Doing tty1 through tty6 would be good. Using just 2 shells was a way to save some memory. Kids will use none. Whoever needs more can easily edit /etc/inittab. I strongly feel that: if sudo works then su must work Thumbs up. Moreover, I strongly feel that /sbin and /usr/sbin are the creation of the devil and serve no other purpose than irritating unprivileged users when they want to call ifconfig or mount. It also interacts especially badly with sudo -s and su. Therefore, I've just added /usr/local/sbin:/usr/sbin:/sbin to the user path. Note that the above does not require sudo to work. It doesn't even require su to work, given that sudo doesn't work. Good point, but if we left just that in place, we'd have to ask people to use the ugly text console more often, where the keyboard works partially and there's no cut paste. Ideally, one would rather try to make the system work so well that there would be no need to use that ever. See MacOSX. I don't believe there is any real need to protect the root account from the olpc account. There is: the Browse activity still runs as olpc because it is hard to containerize. But one could argue that there's not that much of a difference between compromising olpc and compromising root on a single-user machine. If there is, then a root login should require the SAK key. (Alt-Ctrl-SysRq by default) This is the only way to be sure that one is not typing into a trojan. Maybe Fn-Esc makes a good SAK key. I wonder how it plays with setxkbmap and loadkeys. offtopic msbashing On Windows, they tell users that CTRL-ALT-DEL is a proected system sequence that no application can ever intercept, but it's just a gross lie. On Windows 2000, you can edit the registry as a user to remap keys to other keys, including all of CTRL, ALT and DEL. I know because I wanted to remap CAPS-LOCK to CTRL and I did by mistake the other way around, so I couldn't login any more through MSGINA :-) /msbashing /offtopic -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Circumventing kernel signing
John Richard Moser wrote: VECTOR 1: kexec() [...] VECTOR 2: unsigned module [...] Unless we disable things such as /dev/mem, I also see a much wider attack vector, where one can inject arbitrary code in the kernel and recreate the conditions of these. And there are many alternative strategies based on commonly available interfaces. Some people seem to believe that one can give root access to a system and at the same time keep it locked down. While this seems possible in theory, I'm still waiting to see a practical implementation that resists Random J. Hacker while preserving the user's and application's expectations of what root can normally do. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Printing and the XO
Peter Krenesky wrote: While not a primary concern of the project, printing is something that teachers are asking for. [...] Is this nice documentation already in the wiki? If not, please be bold and create a new page! -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Construct Rainbow's spool dir if it doesn't exist - #5033
Applied, thanks. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 672
Build Announcer Script wrote: http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build672/ +AcousticMeasure-11.xo -AcousticMeasure-7.xo --- AcousticMeasure-11 --- * Fix socket placement to work under Rainbow. The diff script only got the latest changelog entry and missed those for interim revisions 8, 9 and 10. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
setolpckeys
I was wondering what this program is useful for. It does not seem to be referenced anywhere, so maybe now we could drop it? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Clock?
C. Scott Ananian wrote: On Dec 23, 2007 4:55 PM, Bernardo Innocenti [EMAIL PROTECTED] wrote: Jerry Van Baren wrote: Hmmm, odd. After setting the hwclock with --utc, my /etc/adjtime has UTC but, when I cycled power, my system clock was off by my timezone. Ahh, my /etc/adjtime has 0 instead of UTC on the second line. This is probably because adjtime is marked writable in /etc/rwtab, but not preserved in /etc/statetab. I'll fix that. Bernie, be sure to open a trac bug so that we can get this into Update.1 if possible. (Just to clarify, it should be *moved* from /etc/rwtab to /etc/statetab, not just added to statetab -- but I'm not 100% confident that this is correct. Please read the man page for hwclock carefully. I think we should really be passing --noadjfile to hwclock, and if /etc/sysconfig/clock actually states UTC=true (trac #5648) then adjtime should not have the UTC offset in it.) After some thought, I'm convinced we should *not* preserve adjtime across reboots. Preserving adjtime would provide a minor accuracy improvement, but it's not strictly needed for correctness, because the --utc flag gets passed both on system boot and on shutdown. The reason why we can't effectively preserve adjtime is that the stateless Linux mounts happen at boot time after hwclock, so there's no easy way to do it right without ugly surgery in the rc.sysinit. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: iwpriv (Was: OLPC News 2007-12-30)
David Woodhouse wrote: So here's an untested patch to make the reboot fixups slightly more generic, so that we can easily add our own 'fixup' for the XO in a fashion which will actually be mergeable upstream. It would be slightly nicer and generic if we had void (*mach_reboot_fixup)(void *arg); void *mach_reboot_fixup_arg; rather than the cs5530a_pci_dev global. But anyway, Untested-but-otherwise-Signed-Off-By: David Woodhouse [EMAIL PROTECTED] Untested-but-otherwise-Acked-By: Bernardo Innocenti [EMAIL PROTECTED] -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: qemu and the file system and development
Steve Lewis wrote: I have gotten sugar running under windows with QEMU - no I have lots of questions 1) If I make changes in the emulated system are those changes remembered between runs? Yes. 2) Can I have the emulator point at a part of the windows file system - allowing my tools to work on data to be used by the system Easiest way is using samba. If you were using Linux as a host, I'd recommend nfs (fast) or sshfs (easier to setup). If you manage to get Samba to work on the laptop, please add a wiki page describing the procedure you followed. 3) How do I move changes I made on the XO to the emultator 4) How can I move changes I make in the emulator to the XO scp and sftp are the easiest way. On windows, try the putty suite of ssh programs. Is there a way to hook an external ide to the image running in QEMU Just share the source (and binary) directory with any network filesystem. You can debug C application remotely with gdbserver. Python has its own debugger. For development, I usually just ssh into the laptop as root from my desktop, so I have fast scrolling, cut paste, etc. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Mitch Bradley wrote: From a security standpoint, there is an advantage to building in everything. The main kernel is verified with a crypto signature before it is executed. Loading a module without first verifying a similarly-strong signature weakens the security. Modules are a good idea for kernels that are intended to run on a wide variety of hardware. I am in favor of treating XO like an appliance and making the kernel as monolithic as possible. Uh-oh... Does our security system really depend on this? Reducing the number of modules is not going to help, because you only need to load a single module to tap into the kernel. Building everything statically and disabling module loading is also not an option if you want half decent support for USB devices. Note that USB also brings in SCSI, DVB, and a lot more. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
John Richard Moser wrote: I'm not sure about some of the kernel configuration options. A few minor things stick out in my mind; I don't know the rationale behind some of these things and am curious about developer decisions and thoughts on how to build the kernel. * CONFIG_NO_HZ + CONFIG_HZ=100? * SLAB vs SLUB * Some debugging stuff * More debugging stuff * Building stuff as modules Please, build a kernel with the changes you consider useful, and make it available somewhere, along with your proposed config patch. Please make sure that the resulting kernel also still works on QEMU and VMware. Extra bonus points if you can give hard numbers on memory saving and performance gains. As a super-quick-and-dirty test, note that /home/olpc/.boot_time records the time it takes to get from kernel startup to the X session. We can expect that time to be slighly influenced by your improvements because booting exercises several kernel subsystems, including vfs, slab, forks and mmaps. First off I noticed CONFIG_NO_HZ=y and CONFIG_HZ=100; is this a quirk of the kernel's general configuration? As I understand, these options should be mutually exclusive because CONFIG_HZ is a parameter of a scheduler using a different methodology than CONFIG_NO_HZ... Probably a (harmless) leftover of editing the .config manually. Another thing is I noticed CONFIG_SLAB=y, but the SLUB allocator is supposed to be a faster generic replacement for SLAB.[1] Is there a reason the XO doesn't use it? Don't expect too much out of it: http://lwn.net/Articles/261868/ But I still think we should try it and maybe use it. I'm also noticing some things like KALLSYMS and BUG(), BSD process accounting, and the like. KALLSYMS, BUG(), and printk() are useful; on a true embedded device I'd say remove 'em but I can't justify it here... BSD process accounting and auditd support though? I'd keep the debug symbols (which shouldn't cost any memory at runtime). In the same line, a lot of debugging options are in use. I'm using Build 653, I guess it may be a developer's build and thus there's a lot of debugging stuff; but in the final should things like CONFIG_PROFILING , CONFIG_KPROBES, CONFIG_DEBUG_FS, CONFIG_UNUSED_SYMBOLS, CONFIG_SCHEDSTATS, CONFIG_TIMER_STATS, CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_SPINLOCK ... be removed? I side with M.Edward on keeping oprofile support, which does not slowdown the system and can be built as a module. Finally, I'm noticing a lot of stuff can be built as modules, but is built in. Go for it! But please note that we're using a weird initrd that doesn't contain modules (or maybe does, but cannot easily be regenerated along with the kernel). Because of this, I think all the modules required for booting off jffs2 and ext3 need to be linked in :-( -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
John Richard Moser wrote: Please, build a kernel with the changes you consider useful, and make it available somewhere, along with your proposed config patch. Please make sure that the resulting kernel also still works on QEMU and VMware. The base hardware drivers built in supports qemu and vmware? Yes, but it doesn't take that much. It's probably just a pci IDE controller and the vesafb. Looks like I gotta read up on the wiki about how to rebuild the kernels (again). It seems I can alter Grub to do what I want afterwards though. (Do I need a developer's key or smth?) Yes, you do need a developer key. What is an smth? Rebuilding the kernel RPM is less than trivial. You may prefer just building the kernel and then copying it on the target with a stupid script like this one: ---8--- dest=18.85.46.119 stagedir=stage #vservers destdir=/versions/boot/current/boot #sane #destdir=/ set -x mkdir -p $stagedir/boot make INSTALL_MOD_PATH=$stagedir modules_install make bzImage cp -a arch/i386/boot/bzImage $stagedir/boot/vmlinuz cp -a System.map $stagedir/boot tar -C $stagedir -czf - . | ssh [EMAIL PROTECTED] tar -C $destdir -xvzf - ---8--- Extra bonus points if you can give hard numbers on memory saving and performance gains. Black art ;) Well, size vmlinux may be a lower bound approximation for the memory saving. Combined with some /proc/slabinfo magic you'd get closer. As you say, performance is hard to measure. Shell scripts tend to be good kernel benchmarks because they create lots of processes, file descriptors, and do a lot of I/O. I'd keep the debug symbols (which shouldn't cost any memory at runtime). Possibly not. The kernel runs inside one giant huge page doesn't it? 4MiB read-write-execute... Not on the Geode: we don't have MTRRs, so I guess the kernel is being mapped by 4KB pages. But anyway, aren't the symbols in a separate ELF section? So probably they end up in the vmlinuz binary too, but I've not checked. Because of this, I think all the modules required for booting off jffs2 and ext3 need to be linked in :-( I think you can omit booting off ext3 for the final product. Hmmm, people may like to boot off USB and SD, wouldn't they? We're talking about a very small saving anyway... There is load-time consideration to be made about loading everything as modules (camera, USB, mouse, all of networking, sound, etc) and leaving the essentials (flash, display, keyboard, jffs2). Even if you leave networking and all the 100%-always-loaded modules compiled in, however, there's no need for things like 30 types of file systems. We still have plenty of places where we could recover several *seconds* of boot time with just minor changes. So I don't think we should worry too much about module load time, which is probably very fast. In my experience, module load time is usually dominated by the work being done in the init function, which sometimes involves sleeping or performing slow I/O (i2c, serial, USB...). This time would also be spent in the monolithic kernel. I'd personally leave out ipv4 and ipv6 and just load them at boot time; I'd rather not have ipv6 loaded right now, and ipv6 infrastructures should run without ipv4 (some apps will probably complain about no 127.0.0.1...); but this is just nitpicking. I agree with you. Really I like a tiny core kernel and a bunch of modules but as I said, increases the time needed to boot. I once again agree with you, except that I don't think the load time increase will be problematic on the XO. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Tom Sylla wrote: Not on the Geode: we don't have MTRRs, so I guess the kernel is being mapped by 4KB pages. 4MB page support is unrelated to MTRR support. (one is related to linear addresses, the other physical addresses; please see the Intel or AMD documentation on paging and caching) Geode LX supports 4MB pages, it is reported as such in CPUID, and should be used by the kernel. Also note that Geode LX has RCONFs instead of MTRRs, which have the same functionality, and they are all programmed properly by the firmware. So I wonder why we couldn't use these to speed up access to the framebuffer in the amd_drv X driver. Jordan, what do you think? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 669
Dennis Gilmore wrote: On Saturday 29 December 2007, Bernardo Innocenti wrote: What happened? We applied F-7 updates as per http://dev.laptop.org/ticket/5650 That's good, but aren't we doing the same in joyride too? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: TurtleArt Mandelbrot
Samuel Klein wrote: Ben, that's neat. Speaking of fractals: Bernie has been working on sugarizing Gnu Xaos, and we were just tweaking an icon. It has a lovely tutorial about what fractals are that could serve as a model for other tutorials. The port somewhat preliminary, but I still think it's pretty cool: http://wiki.laptop.org/go/XaoS The XaoS bundle is just 441K including dozens of examples and tutorials in several languages :-) If I have time, I'd like to port more old skool apps to the laptop. They are blazingly fast on our hardware and they rarely drag in external dependencies. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Tools for creating svg icons
Steve Lewis wrote: I am working in 'sugarizing' some activities, Avtivities take an svg icon. I tried creating a 50 x 50 icon with Inkscape but it has color (samples do not) and does not blink properly - any suggestions for tools or settings After you save the svg, you need to set two entities and use them as stroke and fill values, as explained here: http://wiki.laptop.org/go/Sugar_Icon_Format -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
iwpriv (Was: OLPC News 2007-12-30)
David Woodhouse wrote: As a general rule, that is totally incorrect. Changes should be pushed towards upstream _before_ they're ever committed to our tree, and any change which has been made only in the OLPC tree and not pushed upstream should be considered volatile and likely to disappear... like the private wireless ioctls I removed last week because they weren't upstream for example¹. ¹ I have actually put them back now, temporarily. But they will be going away again. Nothing is stable until it's upstream. btw, we still have code in /etc/init.d/olpc-configure that tries to use one of those private ioctls to remap the leds, and outputs errors if they're missing. Is this still needed? However, you're right about this patch not going upstream -- I thought I'd already told you that the naïve patch to cs5536_warm_reset() as shown in ticket #4397 was not acceptable. It doesn't live in that function, and even if it did, it shouldn't be happening unconditionally based on CONFIG_OLPC. An interesting goal would be cleaning up CONFIG_OLPC so that it could be enabled in stock kernels of standard Linux distros. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New Project: inferno-olpc
Eric Van Hensbergen wrote: 1. Project name : inferno-olpc Great project. Looking forward to see it in action! -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] OLPC emulation
Matt Price wrote: i would definitely advise against trying to use the standard emulation images, as they take some work to get running. I'm interested in helping fix such problems. Please, file bugs for major problems you've experienced and assign them to me. Even better, submit patches. I'll try to allocate a small portion of my time on making our emulation experience better. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 669
What happened? Build Announcer Script wrote: -atlas.i386 0:3.6.0-11.fc6 +atlas.i386 0:3.6.0-11.fc7.1 -coreutils.i386 0:6.9-5.fc7 +coreutils.i386 0:6.9-6.fc7 -cups-libs.i386 1:1.2.12-7.fc7 +cups-libs.i386 1:1.2.12-8.fc7 -cyrus-sasl-lib.i386 0:2.1.22-6 +cyrus-sasl-lib.i386 0:2.1.22-8.fc7 -gnome-vfs2.i386 0:2.18.1-6.olpc2 +gnome-vfs2.i386 0:2.18.1-7.olpc2 -info.i386 0:4.11-1.fc7 +info.i386 0:4.11-2.fc7 -iptables.i386 0:1.3.8-2.1.fc7 +iptables.i386 0:1.3.8-6.fc7 -iptables-ipv6.i386 0:1.3.8-2.1.fc7 +iptables-ipv6.i386 0:1.3.8-6.fc7 -libshout.i386 0:2.2.2-1.fc6 +libshout.i386 0:2.2.2-2.fc7 -libsmbios-libs.i386 0:0.13.10-1.fc7 +libsmbios-libs.i386 0:0.13.13-1.fc7 -libtheora.i386 0:1.0alpha8-0.3.svn13393.fc7 +libtheora.i386 0:1.0beta2-2.fc7 -libvolume_id.i386 0:113-12.fc7 +libvolume_id.i386 0:116-3.fc7 +matchbox-window-manager.i386 0:1.2-1 -matchbox-window-manager.i386 0:1.2-3.20070628svn +olpc-licenses.noarch 0:1-1 -openldap.i386 0:2.3.34-3.fc7 +openldap.i386 0:2.3.34-4.fc7 -pam.i386 0:0.99.7.1-5.1.fc7 +pam.i386 0:0.99.7.1-5.2.fc7 +procps.i386 0:3.2.7-16.1.fc7 -procps.i386 0:3.2.7-16.fc7 -python-devel.i386 0:2.5-14.fc7 +python-devel.i386 0:2.5-15.fc7 -python.i386 0:2.5-14.fc7 +python.i386 0:2.5-15.fc7 -python-libs.i386 0:2.5-14.fc7 +python-libs.i386 0:2.5-15.fc7 +sudo.i386 0:1.6.8p12-14.fc7 -sugar.i386 0:0.75.5-1 +sugar.i386 0:0.75.6-1 -totem.i386 0:2.18.2-10 +totem.i386 0:2.18.2-5.olpc2 -totem-mozplugin.i386 0:2.18.2-10 +totem-mozplugin.i386 0:2.18.2-5.olpc2 -totem-plparser.i386 0:2.18.2-10 +totem-plparser.i386 0:2.18.2-5.olpc2 -tzdata.noarch 0:2007i-1.fc7 +tzdata.noarch 0:2007j-1.fc7 -udev.i386 0:113-12.fc7 +udev.i386 0:116-3.fc7 -xapian-bindings-python.i386 0:1.0.2-1 +xapian-bindings-python.i386 0:1.0.4-2.fc7 -xapian-core-libs.i386 0:1.0.2-2 +xapian-core-libs.i386 0:1.0.4-1.fc7 -xulrunner.i386 0:1.9-0.beta1.7.olpc2 +xulrunner.i386 0:1.9-0.beta1.9.olpc2 -yum.noarch 0:3.2.7-1.fc7 +yum.noarch 0:3.2.8-2.fc7 -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
closed lists
Replying to cross-posts results in this annoying moderation stuff. Are our spam filters good enough to make our lists open for posting by non-members? [EMAIL PROTECTED] wrote: Your mail to 'Localization' with the subject Re: [sugar] Update.1 schedule trac usage... ***Please Read** Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: licensing: GPLv2, v3, and Apache
Ivan Krstić wrote:
Only one or two pieces of software on the laptop are
presently GPLv3-licensed.
Specifically,
# rpm -qa --queryformat '%{name} %{license}\n' | grep GPLv3 | sort
espeak GPLv3+
gnash GPLv3+
gnash-plugin GPLv3+
info GPLv3
The number will increase slightly when/if we refresh our
packages with the latest upstream versions:
binutils GPLv3+
cpio GPLv3+
jwhois GPLv3
rsync GPLv3+
--
\___/
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: 3rd Fedora disk curdle
Gerard J. Cerchio wrote: Does the jhbuild emulator do any exotic direct to disk IO that may be causing this? Not that I know of. Does Fedora aggressively modify its ext3, vfs or SCSI drivers? The Fedora kernel is very close to the upstream. Has anyone else seen this kind of problem? Neither in real systems, nor in QEMU. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Stlye issue with laptopfoundation.org
We should either set the background color to white in the css, or make the backround of the various images transparent (better, imho). In general where should we report problems with our public facing web sites? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Playing with IDEs
(cc sugar@, eben) Jeffrey Kesselman wrote: On Dec 24, 2007 4:57 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Bernie has the details to get a 1200x900 screen in the emulator on the wiki somewhere (right?); All I could find was a qemu cant do this on the emulation page and a very confusing discussion of multiple different drives on the drivers page. Both vmware and qemu (recent CVS snapshot) can do this using the vmware driver: http://dev.laptop.org/ticket/5163 This driver is only available in xtest for now. Scott, please note that #5163 is blocked on a Pilgrim patch. Please apply it and we can close it. I'm willing to bet my VMWare is capable of this if someone could just point me at the right settings to put into my xorg.conf Both xtest and joyride carry the necessary config file: /etc/X11/xorg-vmware.conf. But joyride is missing the vmware driver. That said, I think we should state clearly in our HIG that applications should be resolution independent because the display size will vary in future hardware and in *current* hardware to which Sugar has been ported. What do the Sugar developers think about it? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Clock?
Jerry Van Baren wrote: Hmmm, odd. After setting the hwclock with --utc, my /etc/adjtime has UTC but, when I cycled power, my system clock was off by my timezone. Ahh, my /etc/adjtime has 0 instead of UTC on the second line. This is probably because adjtime is marked writable in /etc/rwtab, but not preserved in /etc/statetab. I'll fix that. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Clock?
Joshua Minor wrote: Is it reasonable to assume that the XO's clock is set correctly? Specifically I'd like to use python's time.time() to determine which participant of an activity has been using it the longest. A NetworkManager callout could set it, but it seems we're not doing it yet. Alternately, is there a simple way to query the network for the current time? Try: ntpdate pool.ntp.org This will also set the system clock, but not save the time in the hardware clock. We're also not setting the TZ correctly at this time, and I'm almost sure that couldn't be done automatically from the manufacturing data. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Clock?
Jerry Van Baren wrote: FWIIW, the hardware clock configuration is set to use localtime by default. This can be reconfigured to use UTC (see /etc/rc.sysinit which includes the config file /etc/sysconfig/clock if it exists), but it probably isn't worth the effort. From hwclock's man page: If you specify neither --utc nor --localtime , the default is whichever was specified the last time hwclock was used to set the clock (i.e. hwclock was successfully run with the --set , --systohc , or --adjust options), as recorded in the adjtime file. If the adjtime file doesn't exist, the default is local time. So the first time you set the hwclock with --utc, it will be kept that way. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 1452
Asheesh Laroia wrote: On Wed, 19 Dec 2007, Build Announcer Script wrote: http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1452/ -Chat-31.xo +Chat-32.xo +libpcap.i386 14:0.9.7-1.fc7 -olpc-utils.i386 0:0.53-1.olpc2 +olpc-utils.i386 0:0.59-1.olpc2 +sudo.i386 0:1.6.8p12-14.fc7 +tcpdump.i386 14:3.9.7-1.fc7 I can just picture the eight year old dissassembling on-wire network protocols by watching the streams in tcpdump. It's a dependency dragged in by olpc-utils, for the sake of the olpc-netcapture. By the time they're twelve, they'll See the Matrix. :-) I also disapprove adding bulky packages to our builds just for sake of debugging. In this case, this is said to be only temporary until we have shaken the most serious networking problems. There is still plenty of opportunity for debloating our images, and I'm willing to pursue it, but it is not clear if this is a valued goal. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
zRe: New joyride build 1452
On 12/20/07 14:56, Marcus Leech wrote: While I'm sympathetic to removing bulk, I'm someone who developed his first networking stack at the age of 16 or 17 around 1980. I think we shouldn't rush too hastily in making assumptions about what 12-year-old budding software genii will actually need. As much as I sympathize with geeky kids, I think we shouldn't penalize everybody by carrying tons of debugging tools. If they are smart enough to use these things, one would expect them to be able to deal with yum. Regarding the specific case of network debugging tools, C.Scott certainly has a point :-) -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[PATCH] Re: DONT USE 1432 Re: New joyride build 1432
C. Scott Ananian wrote:
On Dec 16, 2007 7:14 PM, Bernardo Innocenti [EMAIL PROTECTED] wrote:
The new-kernel-pkg script is part of mkinitrd :-(
Please, allow me some time to come up with a straightforward
fix that doesn't require putting mkinitrd back in the builds.
Can you please do this in your private builds, and not break joyride
for the rest of us?
I apologize, that was of course totally unexpected.
Anyway, both my private builds and joyride are currently broken due
to missing static repos in Fedora's Koji:
Parsing package install arguments
http://koji.fedoraproject.org/static-repos/dist-olpc2-build-current/i386/repodata/repomd.xml:
[Errno 14] HTTP Error 403: Forbidden
Trying other mirror.
Error: Cannot open/read repomd.xml file for repository: olpc_development
Dennis, do you have any idea what happened?
As a stop gap, I'd recommend putting gzip friends as explicit
dependencies of olpc-utils; they can then be removed from there and
added to other packages incrementally (probably post-update.1).
Good idea.
Here follows updated patch for the kernel spec file, tested by
installing and removing the package on a running system with
no mkinitrd.
I wonder if it may be a good idea to also add the commands
to fix /versions/running/boot, so it's one less pitfall people
can fall into when installing custom kernels.
From 2d6964068e7c8abfe2bc138eafe094f94ea8f9d7 Mon Sep 17 00:00:00 2001
From: Bernardo Innocenti [EMAIL PROTECTED]
Date: Mon, 17 Dec 2007 07:41:50 +0100
Subject: [PATCH] Replace use of new-kernel-pkg in post scriptlet with direct
invocation of depmod
Organization: One Laptop Per Child
---
SPECS/olpc-2.6.spec | 16 ++--
1 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/SPECS/olpc-2.6.spec b/SPECS/olpc-2.6.spec
index 2f215ea..b82f396 100644
--- a/SPECS/olpc-2.6.spec
+++ b/SPECS/olpc-2.6.spec
@@ -972,22 +972,10 @@ rm -rf $RPM_BUILD_ROOT
###
%post
-if [ `uname -i` == x86_64 -o `uname -i` == i386 ]; then
- if [ -f /etc/sysconfig/kernel ]; then
-/bin/sed -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/'
/etc/sysconfig/kernel || exit $?
- fi
-fi
-if [ -x /usr/sbin/module_upgrade ]
-then
-/usr/sbin/module_upgrade %{rpmversion}-%{release} || exit $?
-fi
-/sbin/new-kernel-pkg --package kernel --depmod --install %{KVERREL} || exit $?
+/sbin/depmod -ae -F /boot/System.map-%{KVERREL} %{KVERREL}
if [ -f /boot/vmlinuz-%{KVERREL} ]; then
(cd /boot ln -sf vmlinuz-%{KVERREL} vmlinuz)
fi
-if [ -f /boot/initrd-%{KVERREL}.img ]; then
- (cd /boot ln -sf initrd-%{KVERREL}.img initrd.img)
-fi
%post devel
if [ -f /etc/sysconfig/kernel ]
@@ -1105,7 +1093,7 @@ if [ $HARDLINK != no -a -x /usr/sbin/hardlink ] ; then
fi
%preun
-/sbin/new-kernel-pkg --rmmoddep --remove %{KVERREL} || exit $?
+[ -d /lib/modules/%{KVERREL} ] rm -f /lib/modules/%{KVERREL}/modules.*
%preun smp
/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove %{KVERREL}smp || exit $?
--
1.5.3.3
--
\___/
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Joyride 1436 a bust
On 12/17/07 14:06, Marcus Leech wrote: Multitudinous modprobe errors on start. See the thread about 1432. If you need to test this build, just do a depmod -a manually and reboot. The fix is already on its way. Maybe someone could revert to the previous version of the kernel package for the time being? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Recent Joyride builds busted bad
On 12/17/07 19:11, Marcus Leech wrote:
Missing /usr/lib/modules/kernel/*.dep, etc. This is fixed by doing a
depmod -a after upgrading.
This appears to be fixed in 1439, announced just
4mins after your post :-)
But there's also chunks of filesystem missing:
/var/lock/subsys/{a-bunch-of-things}
/var/run/dbus
/security
/var/lib/stateless/{a-bunch-of-things}
Looks like the damn stateless linux thing is failing
to restore files in /etc/rc.sysinit.
We need to add cpio manually to the list of packages
in pilgrim. I don't have write access to the version
that gets used in the joyride builds.
Scott, could you please do it?
A couple of RC scripts failed to find the find command, which perhaps
explains missing chunks of filesystem
(particularly under /var???).
So we also need to add find back.
It's a frooking mess, I'd say :-)
Yes :-(
I'm surprised how much stuff was installed only as a consequence
of mkinitrd. The Fedora people should be informed of this
problem, as it is likely to bite on every embedded distro
based off Fedora.
--
\___/
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: New joyride build 1405
On 12/12/07 10:16, Jim Gettys wrote: On Wed, 2007-12-12 at 01:15 -0500, Build Announcer Script wrote: http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1405/ -libertas-usb8388-firmware.noarch 2:5.110.20.p42-1.olpc2 +libertas-usb8388-firmware.noarch 2:5.110.20.p47-1.olpc2 -xorg-x11-drv-amd.i386 0:0.0-29.20071019.olpc2 +xorg-x11-drv-amd.i386 0:0.0-30.20071019.olpc2 -xorg-x11-drv-cirrus.i386 0:1.1.0-3.fc7 +xorg-x11-drv-cirrus.i386 0:1.1.0-5.olpc2 --- xorg-x11-drv-cirrus.i386 1.1.0-5.olpc2 --- - Rebuild for PPC toolchain bug I do not understand why we'd have a driver for cirrus in our system Can someone enlighten me? QEMU emulates an old Cirrus Logic PCI card, which is quite faster than fbdev because it has a blitter with some hardware acceleration. Recent CVS snapshots of QEMU also support the vmware_drv, so we may want to use it exclusively when this feature becomes sufficiently available. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: multiple MTD partitions
Artem Bityutskiy wrote: but unfortunately have not got feedback, and I suspect one of the reasons is that it is too difficult to boot UBIFS on XO. It would be great to have a demo OS image using UBIFS. I can't help for the partitioning thing, but if you need help with the process of rebuilding OS images, I just wrote this documentation that may be helpful: http://wiki.laptop.org/go/Building_custom_images -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DONT USE 1432 Re: New joyride build 1432
Bernardo Innocenti wrote: Pascal Scheffers wrote: 1432 won't boot X on my B4. Lots of kernel modules not found at boot time. Hmm... I think it's my fault :-( I asked dilinger to remove the dependency on mkinitrd from the kernel because our olpcrd thing does not even use it, and it was dragging lots of useless dependencies with it. It seems depmod is not being run... Something in the kernel posti scriptlet failed? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: updated GStreamer RPMs
On 12/14/07 23:30, Chris Ball wrote: Hi, We're planning to rebase on Fedora 8 for Update 2, but it's good to be able to preview these ahead of time. Has this been proposed somewhere? I don't think I agree with it. I don't disagree strongly, but just enough that I'll stop someone from talking about it as if it's already been decided. ;-) http://lists.laptop.org/pipermail/devel/2007-December/008328.html (My reason for disagreeing is the standard progress vs. support dichotomy. I'd rather we kept the base OS as a known quantity but worked really hard on things like performance.) I'm also not strongly biased. The reason I'm in favor of upgrading is that it would help us cleaning up a number of packages newer than F7 that we were already carrying. Moreover, some experimentation shows that it would be somewhat painless. The only problem I experienced was the one I mentioned with hal. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Make the OLPC build not depend on mkinitrd
Andres Salomon wrote: There's no need to attempt to maintain any sort of compatibility with the fedora kernel spec file. Rather than unsetting variables and keeping tons of crap in the .spec file, I'd just as soon rip out anything that's related to _enable_debug_packages. YES! Please! How does it make the build fail, though? I haven't see that... I got an error No build ID note found that I tracked inside /usr/lib/rpm/find-debuginfo.sh Now I realized it's probably a Fedora 8 specific problem... I just dropped the mkinitrd bit completely; no need for an OLPC test. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Builds and release process
Marco Pesenti Gritti wrote: Care to put quick instructions on the wiki? This is something I wanted to do several times, but never felt to invest the time to learn how. Done: http://wiki.laptop.org/go/Building_custom_images As usual, my questionable English needs some fixing, and I couldn't find the documentation in the internal wiki that mstone was talking about. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Update.1 builds
C. Scott Ananian wrote: Almost the final location. As documented in trac bug #5279, ultimately all builds will be transferred to download.laptop.org after passing an automated test. So pilgrim is the 'final location' until we get the automated test infrastructure running, then everything will move to its real final home on download.laptop.org. Is joyride also moving? Please, remember to update the links in the wiki, especially the template that prints the summary information in the main page: http://wiki.laptop.org/go/Template:Latest_Releases Where are the development builds? has been a FAQ on IRC for some time. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: QActivity
Bernhard Rosenkraenzer wrote: sorry for the delay, net access here is pretty far from reliable (it's pretty common for the entire country's net access to just drop and stay down for a couple of days - nobody but me seems to be bothered by it). Out of curiosity, what country would that be? So in case I need to travel there I'll come prepared with something to read for 2 days :-) We do not support the B2 boxes any more, due to lack of developer time for testing and bugfixing. So the latest builds do not actually even boot on B2s! I know -- but all I have is a B2 (and one of the old ones at that, 128 MB). Making the current joyride images work again would be another interesting open project. It probably takes some kernel work in the Geode GX drivers. Yes, but that isn't done for KDE4 yet, and developing for KDE3 is a dead end -- the kdeedu applications in KDE4 SVN are already much better than their KDE3 counterparts (I have almost all of them running by now btw). You mean running on the XO? As activities? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[PATCH] Make the OLPC build not depend on mkinitrd
---
SPECS/olpc-2.6.spec |8 +++-
buildd.sh |2 +-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/SPECS/olpc-2.6.spec b/SPECS/olpc-2.6.spec
index c823a54..2ead835 100644
--- a/SPECS/olpc-2.6.spec
+++ b/SPECS/olpc-2.6.spec
@@ -15,6 +15,9 @@ Summary: The Linux kernel (the core of the Linux operating
system)
%define buildkdump 0
%define buildheaders 1
+# Disable debuginfo package because it makes the build fail
+%define _enable_debug_packages 0
+
# Versions of various parts
# After branching, please hardcode these values as the
@@ -213,8 +216,11 @@ Summary: The Linux kernel (the core of the Linux operating
system)
#
# Packages that need to be installed before the kernel is, because the %post
# scripts use them.
+# On the OLPC, we use a fancy initrd that doesn't rely on mkinitrd
+# We drop mkinitrd because it also drags in lvm2 and other nasty dependencies
#
-%define kernel_prereq fileutils, module-init-tools, initscripts = 8.11.1-1,
mkinitrd = 4.2.21-1
+%define kernel_prereq fileutils, module-init-tools, initscripts = 8.11.1-1 \
+ %{?!olpc:, mkinitrd = 4.2.21-1}
Name: kernel
Group: System Environment/Kernel
diff --git a/buildd.sh b/buildd.sh
index 24ba127..6e8de51 100755
--- a/buildd.sh
+++ b/buildd.sh
@@ -7,7 +7,7 @@ GITWEB=http://dev.laptop.org/git?p=olpc-2.6;
if [ x$BRANCH = x ]; then
BRANCH=master
fi
-BUILDDIR=/home/dilinger/public_html/builds-${BRANCH}
+BUILDDIR=$HOME/public_html/builds-${BRANCH}
BASE=$BUILDDIR/`date '+%s'`
SUBLEVEL=$(wget -O- ${GITWEB};a=blob_plain;hb=${BRANCH};f=Makefile
2/dev/null | sed -ne
's/^.*SUBLEVEL[[:space:]]*=[[:space:]]*\([0-9]\+\).*$/\1/p')
--
1.5.3.3
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
[Fwd: Re: Regression Problem in Xorg 7.3]
a pixmap over a pixmap 5000 times: 0.217493 cf-18:~/Xorg_Performance/pygtk$ ./image_perf.py Time to flip the blue overlay 500 times: 30.973030 Lenny benchmark using Xorg: cf-18:~/Xorg_Performance/pygtk$ ./pixmap_perf.py Time to draw a pixmap over a pixmap 5000 times: 12.012802 cf-18:~/Xorg_Performance/pygtk$ ./image_perf.py Time to flip the blue overlay 500 times: 25.642715 Lenny benchmark using Xvfb: cf-18:~/Xorg_Performance/pygtk$ ./pixmap_perf.py Time to draw a pixmap over a pixmap 5000 times: 0.336718 cf-18:~/Xorg_Performance/pygtk$ ./image_perf.py Time to flip the blue overlay 500 times: 18.626873 I'm not sure what this means... The image_perf.py on Lenny running Xvfb is much faster than the same code running on Etch running Xvfb. So does the slow Lenny Xorg performance mean it is more likely the Intel driver? Tony ___ xorg mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/xorg -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 656
On 12/13/07 00:58, Build Announcer Script wrote: +compat-libstdc++-33.i386 0:3.2.3-61 Why do we even need this? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Upgrading to Fedora 8
M. Edward (Ed) Borasky wrote: Does the symlink in /boot to the kernel get updated? I've tried smaller-scale updates (just the kernel) and it still reboots into the old kernel. We can not install Fedora's stock kernel package on OLPC. Not until: 1) all the OLPC patches are integrated upstream 2) everything that depend on CONFIG_OLPC also does runtime checks, so that a stock i586 kernel can boot on both the OLPC and on traditional PCs. I believe Andres is working on (1), but as far as I know there are no plans to make (2) happen, although it sounds possible. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity depends on Fedora-packaged binary code
[EMAIL PROTECTED] wrote: This thing obviously doesn't scale and in the long term we may end up reinventing a full blown package manager with dependency tracking, plus tools like apt for downloading and installing them. It seems to me that the ideal thing would be for Sun to go ahead and get around to releasing certain bits of the OpenSolaris tree under dual GPL/CDDL, so that OLPC can merely adopt something like the Image Packaging System (IPS) being developed for the it-might-be-Solaris-11 Indiana distribution. It is even in Python :-) If Sun wanted Linux to rip off Solaris code easily, they would have just released everything under the GPL right away. I will let Linus explain my point in his usual rude, but quite convincing terms: http://lwn.net/Articles/237905/ :-) [and IPS packages (images) have some *distinctly* Activity or bundle-like characteristics... MANIFESTs/(prototype files)... the need for awareness of security contexts... both OLPC and OpenSolaris are definitely of like mind about a few fairly crucial things.] Hmmm... I have an OpenSolaris starter kit DVD right on my desk... maybe it's time for me to give it a try :-) I used to be extremely fond of Solaris 6 (or 2.6), before switching to Linux. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity depends on Fedora-packaged binary code
M. Edward (Ed) Borasky wrote: This thing obviously doesn't scale and in the long term we may end up reinventing a full blown package manager with dependency tracking, plus tools like apt for downloading and installing them. I've spent a fair amount of time with both yum and apt and I fail to see any superiority of apt over yum. Then again, my main distro is Gentoo, and I *know* Portage (and recompiling everything on an XO) isn't going to scale. :) Oh, I wasn't implying we should switch to apt. Wwhen I wrote tools like apt, I really meant to say any package installer. (But if you ask me, I also used both very extensively and find apt+dpkg much faster and more usable than yum+rpm. Flames to private mail, please :-) But seriously, does the XO really need two package managers? What's wrong with Fedora/RPM/yum? Do people really need to spend ergs on supporting Debian? I also think we should settle on just *one*. And I'd certainly prefer yum+rpm over any mixture of incompatible package formats and update tools we could come up with. This is going to bite when people start upgrading the base OS and find that activities break, or the customizations they made get silently undone, etc. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
