Re: jhbuild failure: evince-olpc -- evince
Reinier Heeres wrote: Thanks! Pushed the patch. Cheers, Reinier Hi Reinier, are the Sugar changes suitable for upstream inclusion? thanks Jani ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: jhbuild failure: evince-olpc -- evince
Thanks! Pushed the patch. Cheers, Reinier Dan Krejsa wrote: Hi, I just got an error sugar-jhbuild update: dependent module evince-olpc not found from ./sugar-jhbuild. The following change seems to fix it: $ git diff diff --git a/build-scripts/sugar-platform.modules b/build-scripts/sugar-platform index 0c36b2f..da2cd79 100644 --- a/build-scripts/sugar-platform.modules +++ b/build-scripts/sugar-platform.modules @@ -275,7 +275,7 @@ dep package=pyabiword/ dep package=libabiword-plugins/ dep package=squeak/ - dep package=evince-olpc/ + dep package=evince/ dep package=hulahop/ dep package=telepathy-stream-engine/ /dependencies Also, I found I needed to install gnome-common (on Fedora 7). I've added that module to the http://wiki.laptop.org/go/Sugar_on_Fedora page. - Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: jhbuild failure: evince-olpc -- evince
Jani, Which upstream are you referring to? The newer evince version is already in joyride, and Read is updated there to use it. When it's nicely tested there it will probably go in the update.1 build. The Read modifications necessary (a few lines) to work with the newer evince are already in git, and are incompatible with the old evince. Therefore it makes sense to update evince in jhbuild, and besides I think the jhbuild version should reflect joyride. Cheers, Reinier Jani Monoses wrote: Reinier Heeres wrote: Thanks! Pushed the patch. Cheers, Reinier Hi Reinier, are the Sugar changes suitable for upstream inclusion? thanks Jani ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Someone didn't get the memo...;-)
Message: 2 Date: Tue, 18 Dec 2007 18:27:54 -0500 From: John Richard Moser [EMAIL PROTECTED] Subject: Re: Oprofile, swap To: Ivan Krsti? [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=utf-8 (Note: most of this message isn't very useful probably; it's about theoretical software architecture, that nobody's going to implement, that I can't prove, that I'm not really 100% sure about. Still, if you WANT to read it, hey... remember, bad ideas sometimes get corrected by people who are smart enough to turn them into GOOD ideas) You are absolutely correct...this message isn't very useful, period. When you can post or link to complete open source code, please do so. Otherwise, you are wasting bandwidth on this list. I don't speak for anyone other than myself, of course, but I am not remotely interested in anything that is NOT open source. Perhaps you could start a closed source list of some sort to post your theories, and other like minded souls can pontificate on the wonders of closed source software. Good luck. This is an open education project, not a closed, secret, keep people ignorant project. Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Someone didn't get the memo...;-)
On Dec 19, 2007, at 7:12 AM, Ed Montgomery wrote: Otherwise, you are wasting bandwidth on this list. I don't speak for anyone other than myself, of course, but I am not remotely interested in anything that is NOT open source. Perhaps you could start a closed source list of some sort to post your theories, and other like minded souls can pontificate on the wonders of closed source software. Good luck. This is an open education project, not a closed, secret, keep people ignorant project. It has taken you significantly more time to compose this response than to have simply read the disclaimer to John's message, decided it didn't fit your criteria for interesting and skipped it. As long as they're not off-topic or disruptive to the list, I'm happy to see various ideas posted, even if somewhat crackpot; I suspect we won't hear about most of them after replying with please let us know when there's code ready, but perhaps at least parts will be useful or point us to things we haven't yet considered. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: jhbuild failure: evince-olpc -- evince
Reinier Heeres wrote: Jani, That would be awesome, and in fact we were hoping that something like this was possible. I made only minor adjustments to the latest source. The biggest changes are in configure.ac and Makefile.am: there are new options --disable-binary and --enable-embed to just build things relevant for an embedded version. You can check out the modifications in my git repo: http://dev.laptop.org/git?p=users/rwh/evince;a=summary sure, I noticed the git changes that's why I was wondering if there's a plan of pushing them upstream :). If as Marco says, after update.1 these may be sent upstream then it answers my question. thanks Jani ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: jhbuild failure: evince-olpc -- evince
We need to submit patches upstream at some point after Update.1. Marco On Dec 19, 2007 3:44 PM, Reinier Heeres [EMAIL PROTECTED] wrote: Jani, That would be awesome, and in fact we were hoping that something like this was possible. I made only minor adjustments to the latest source. The biggest changes are in configure.ac and Makefile.am: there are new options --disable-binary and --enable-embed to just build things relevant for an embedded version. You can check out the modifications in my git repo: http://dev.laptop.org/git?p=users/rwh/evince;a=summary Maybe we can discuss this on IRC? I'm rwh there in #olpc and #sugar. Cheers, Reinier Jani Monoses wrote: Reinier Heeres wrote: Jani, Which upstream are you referring to? The newer evince version is already I was referring to the GNOME svn upstream, and whether plain evince tarballs will be usable for wrapping in sugar if built with certain configure options. I'd like to reuse as many of the existing system packages for ubuntu debs and I suppose most distros which will include sugar would will as little duplication of upstream packages as well. Jani ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: jhbuild failure: evince-olpc -- evince
Jani, That would be awesome, and in fact we were hoping that something like this was possible. I made only minor adjustments to the latest source. The biggest changes are in configure.ac and Makefile.am: there are new options --disable-binary and --enable-embed to just build things relevant for an embedded version. You can check out the modifications in my git repo: http://dev.laptop.org/git?p=users/rwh/evince;a=summary Maybe we can discuss this on IRC? I'm rwh there in #olpc and #sugar. Cheers, Reinier Jani Monoses wrote: Reinier Heeres wrote: Jani, Which upstream are you referring to? The newer evince version is already I was referring to the GNOME svn upstream, and whether plain evince tarballs will be usable for wrapping in sugar if built with certain configure options. I'd like to reuse as many of the existing system packages for ubuntu debs and I suppose most distros which will include sugar would will as little duplication of upstream packages as well. Jani ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DCON improvements...
On Mon, 2007-12-17 at 13:22 -0500, David Woodhouse wrote: If we should design a next generation of DCON chip, are there any improvements we should make to it? Adam, do I recall correctly that you had problems hooking it up to X for idle detection? Anything we could do to make that better? I filed a bug about this with some observations: http://dev.laptop.org/ticket/1671 It's not so much that detecting idle is hard in X, that's fairly easy. The way DCON1 works, once I notice that I'm idle, I have to keep doing stuff for another 1+e frame times to load a frame into the DCON and then switch to it. Worse, I can't abort that operation midway through, once you tell DCON to load a frame it's going to do it or die trying. Coming back out from DCON to GPU control is a timing disaster because the DCON silicon is _broken_, or was last time I looked at it anyway and I doubt it's changed. The spec says the DCON should signal when it's in the vertical blank period by raising a line from the start of vertical front porch to the end of vertical sync; this is kind of odd, but works. But the silicon instead asserts the line during vertical back porch, which means you're already past the vsync pulse and you can't switch back to GPU control once you get that signal because the panel is strobing back up to the top of scanout. I don't remember what we ended up implementing to work around this, but I'm fairly sure it involved a) the cli instruction, b) waiting at least another 1+e frames before finishing the switch. 50Hz refresh rate means 20ms frames, so the ping-pong latency is 40ms to get into the DCON and then back out. Don't give up latency like that, you never get it back. All of this timing dance made some sort of sense at the time because we were designing for the GX, which can't accept an external timing source for the graphics block. LX, however, can genlock, so the right thing to do there would have been to slave it to the DCON's timing source. If you only have one clock domain you can't drift, and you don't need to play stupid games trying to figure out when vsync really is. Also, if you're genlocked, you can use the GPU's interrupts to handle transition timing, which saves you some GPIO pins. ISTR access to DCON registers being really slow anyway, so anything I can do to talk to it less is a win. In a spherical world, the way this would work is DCON would be continuously loading frames, would notice when idle has happened by snooping on the GPU cache or the framebuffer compression logic, and would handle the flip transparently. To do that right you also need the DCON to be the thing that draws the cursor. In other words, you really need this to be a GPU feature, not something you bolt on externally. But failing that, please, demand a genlockable GPU, slave it to the DCON's timing, and separate the DCON's load frame and enter/leave scanout control operations into two separate commands. - ajax ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DCON improvements...
Thanks for the feedback, Adam. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 1449
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1449/ -Calculate-14.xo +Calculate-15.xo --- Calculate-15 --- * Fixed parsing of fraction separators, #5319 -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/joyride-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: sudo, not su.
On Dec 19, 2007, at 1:50 AM, M. Edward (Ed) Borasky wrote: Yeah ... sudo is more secure than su. In fact, some systems, for example, the Gentoo LiveCD, scrambles the root password. So you have to do $ sudo su - and then set a password to ssh in as root. +1 This is the same thing as in OS X. I've been able to do everything I need to from the command-line in OS X using sudo without ever having to set the root password. If there's a way to make this fit in with the security model and the concerns on the trac entry, then I'm all for it. nick ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 1450
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1450/ -Journal-81.xo +Journal-82.xo -Web-80.xo +Web-81.xo -sugar-datastore.noarch 0:0.7.1-1 +sugar-datastore.noarch 0:0.7.2-1 --- Journal-82 --- * #2545 Correctly unmount the device from the DS when it is removed. (tomeu) * Implement ShowObject, #4909 (rwh) --- Web-81 --- * Use the new show_object_in_journal API of the base activity class to show a downladed object or the view source one in the journal #4909 (cscott) -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/joyride-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: sudo, not su.
On a simmilar vein, would it be much of a perfomance hit to be running denyhosts on these machines? What would it do with the mesh network interface? --e ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: sudo, not su.
On 12/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On a simmilar vein, would it be much of a perfomance hit to be running denyhosts on these machines? What would it do with the mesh network interface? IIRC, each member of the mesh is assigned an IPv6 IP address in the reserved range, so an attacker would have to disconnect and reconnect from mesh network to resume his attacks. Given the large number of IPs, it is unlikely that one will be reused. -ffm ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: sudo, not su.
*IPv4 On 12/19/07, ffm [EMAIL PROTECTED] wrote: On 12/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On a simmilar vein, would it be much of a perfomance hit to be running denyhosts on these machines? What would it do with the mesh network interface? IIRC, each member of the mesh is assigned an IPv6 IP address in the reserved range, so an attacker would have to disconnect and reconnect from mesh network to resume his attacks. Given the large number of IPs, it is unlikely that one will be reused. -ffm ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 1450
On Dec 20, 2007 1:05 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Dec 19, 2007 4:00 PM, Build Announcer Script [EMAIL PROTECTED] wrote: http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1450/ --- Journal-82 --- * #2545 Correctly unmount the device from the DS when it is removed. (tomeu) * Implement ShowObject, #4909 (rwh) --- Web-81 --- * Use the new show_object_in_journal API of the base activity class to show a downladed object or the view source one in the journal #4909 (cscott) This build doesn't (yet?) have http://dev.laptop.org/git?p=sugar;a=commit;h=c14abfb022e505607e8882f3203b02b69d14b135 in it, which is needed to actually make Pippy/Web/Chat's view source functional. --scott The rpm is built, I assume it will go in the next joyride: http://koji.fedoraproject.org/koji/buildinfo?buildID=28656 Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 1452
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 --- Chat-32 --- * Pippy-ize Chat, so that 'view source' lets you edit and regenerate the Chat activity in Pippy. -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/joyride-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 1452
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. By the time they're twelve, they'll See the Matrix. -- Asheesh. -- Only those who leisurely approach that which the masses are busy about can be busy about that which the masses take leisurely. -- Lao Tsu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
