Re: [Sugar-devel] Sugar with a virtual (onscreen) keyboard
On Wed, Jun 23, 2010 at 02:01:52AM +0530, Sayamindu Dasgupta wrote: On Fri, Jun 18, 2010 at 12:35 PM, Jonas Smedegaard jo...@jones.dk wrote: Hi Sayamindu (and others), On Thu, Jun 17, 2010 at 05:46:43PM +0530, Sayamindu Dasgupta wrote: [Apologies for the cross-posting] Thanks to the pointers provided by Peter Robinson, I got the Meego FVKBD (Free Virtual Keyboard)¹ running along with Sugar. Thoughts, feedback, etc would be appreciated :-). I am not familiar with these details, so just shooting in the dark here: Perhaps looking at (i.e. get interface inspiration or steal code from) the alternative virtual keyboard implementation Literki, which seems to have happy followers among Debian OpenMoko users: http://git.senfdax.de/?p=literki Thanks for the pointer to this. It seems however that it's written directly using Xlib, and hence would be unusable for complex scripts like Arabic, Indic, etc. Ah, ok. Too bad. Personally I never succeeded getting those script engines to work on my laptop (and have only esoteric use for them - i.e. suspect them to not even be used for cyrillic which is the only non-latin script I grasp), so wasn't aware of this important issue. Kind regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Sugar with a virtual (onscreen) keyboard
Hi Sayamindu (and others), On Thu, Jun 17, 2010 at 05:46:43PM +0530, Sayamindu Dasgupta wrote: [Apologies for the cross-posting] Thanks to the pointers provided by Peter Robinson, I got the Meego FVKBD (Free Virtual Keyboard)¹ running along with Sugar. Thoughts, feedback, etc would be appreciated :-). I am not familiar with these details, so just shooting in the dark here: Perhaps looking at (i.e. get interface inspiration or steal code from) the alternative virtual keyboard implementation Literki, which seems to have happy followers among Debian OpenMoko users: http://git.senfdax.de/?p=literki Kind regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Notes on service discovery XS/XO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Apr 20, 2009 at 04:08:30PM +0200, Martin Langhoff wrote: On Mon, Apr 20, 2009 at 3:53 PM, Jonas Smedegaard d...@jones.dk wrote: DNS-SD using unicast DNS seems reasonable to me too. If we can do without the avahi gunk, and use it in a way that is not optimised for user driven browsing but for automated selection of services, then it might work. Looking closer at the RFC, the initial service queries do have an added overhead in that a layer of indirection is used (not SRV - A, but instead PTR - SRV + TXT - A). But standard DNS optimizations apply, so SOA record should allow clients to preserve bandwidth through caching. Can we teach dnsmasq to push all the relevant records with the SOA record? I don't understand your question. Sounds like prefetching that isn't part of dns (id you perhaps think of DHCP here?) As I understand dns, if you request a SOA record, then you get a SOA record and only that. You can request the whole domain, but that does not seem bandwidth saving to me. The main bandwidth saver, I believe, is that of sane query caching and knowledge of the segments of the domain structure. In other words: Install dnsmasq on the XOs, use plain standard DNS internally and on the wire, setup DNS-SD entries in a standard nameserver on the XS, and extend Sugar to support DNS-SD. I'd be happy to help compose standard BIND9 files, if that is what will be used on the XS. If we have a dnsmasq resident expert, I rather use your help transitioning to dnsmasq (note - with several bits of weird dhcp rules). There is no upside to BIND and plenty of downsides, starting with the 25MB memory footprint. If that's me you titulate so nicely, then you are way too kind: I have only little experience with dnsmasq used as a caching-only name server, i.e. zero experience with dnsmasq as a real name server containing local data. You are right that BIND9 is a bastard with memory consumption, and it makes sense to use dnsmasq on the XS. I just didn't think of that - I suggested it as a caching-only on the XOs. ISC DHCPd has a complex macro language, however, which might be the upsight you cannot live without. Beware that it is DHCP, not DNS ;-) It seems from its changelog that dnsmasq supports DNS-SD since version 2.36. Tell me more specifically what you fear can be tricky to handle in dnsmasq, either DHCP or DNS parts, and I shall have a look if I am any good at helping out. - Jonas [1] http://twistedmatrix.com/pipermail/twisted-python/2003-July/004909.html - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknsqTwACgkQn7DbMsAkQLjpwwCfSEhWMNOv6gyo9cGaBb3YTyGU OTYAni/jIMqj2nunJlwUwTNBDQc9t6E9 =ePu7 -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Notes on service discovery XS/XO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Apr 20, 2009 at 09:45:28AM -0400, p...@laptop.org wrote: benjamin m. schwartz wrote: Martin Langhoff wrote: The short of it is that mdns/dns-sd make sense for a small, underutilised network of peers. They assume that the network is a cheap resource, that broadcast messages are cheap, and that there is no coordinating server. mDNS assumes all of the above things. DNS-SD does not. DNS-SD is perfectly happy to work on a standard DNS server. From the spec This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. This document simply specifies a convention for how existing resource record types can be named and structured to facilitate service discovery. (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) the last i looked at (and actually used) dns-sd to solve the discovery problem, it seemed that dns-sd development had stalled. (and i haven't had a reason to look since.) i believe we used code from Sun, which was all i could find at the time, and it wasn't what you'd call production ready. on the other hand, we were using it in a somewhat non-standard way -- in fact, we switched to mdns soon after because it fit our deployment model better, since we didn't really have a central server. the XS model may be a better fit. (this was all 3 or 4 years ago, btw.) Here's my understanding: * DNS-SD is a formalized use of DNS records to store services (rather than hosts, the most popular use of DNS records). * mDNS is DNS over multicast (using DNS-SD to resolve services). So it seems to me that if you've switched from DNS-SD to mDNS, then in fact you are still relying on DNS-SD, just using an additional layer on top of it. A good introduction (assumably more reliable than Wikipedia) is http://www.dns-sd.org/ - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkns0S8ACgkQn7DbMsAkQLipkACfW9CWHqtdtytFZuNrCzm0Jmrd jIkAn3zqgu6B6Ic7sFeINPjVGpmjmKCA =J4B8 -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [Sugar-devel] Notes on service discovery XS/XO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Apr 20, 2009 at 07:26:30AM -0400, Benjamin M. Schwartz wrote: Martin Langhoff wrote: The short of it is that mdns/dns-sd make sense for a small, underutilised network of peers. They assume that the network is a cheap resource, that broadcast messages are cheap, and that there is no coordinating server. mDNS assumes all of the above things. DNS-SD does not. DNS-SD is perfectly happy to work on a standard DNS server. From the spec This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. This document simply specifies a convention for how existing resource record types can be named and structured to facilitate service discovery. (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) I'm not particularly knowledgeable about the XS service discovery requirements, nor about DNS, so I can't reasonably tell you to use DNS-SD. What I can say is that it seems like it should be workable. DNS-SD using unicast DNS seems reasonable to me too. Looking closer at the RFC, the initial service queries do have an added overhead in that a layer of indirection is used (not SRV - A, but instead PTR - SRV + TXT - A). But standard DNS optimizations apply, so SOA record should allow clients to preserve bandwidth through caching. In other words: Install dnsmasq on the XOs, use plain standard DNS internally and on the wire, setup DNS-SD entries in a standard nameserver on the XS, and extend Sugar to support DNS-SD. I'd be happy to help compose standard BIND9 files, if that is what will be used on the XS. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknsflUACgkQn7DbMsAkQLiL2wCfV/HuaLPQ0kv/mvYH4fdImsIs ookAnAu5ir3uxxKNjCdTwu4gfNxdE4hZ =7Jde -END PGP SIGNATURE- ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] [Sugar-devel] Notes on service discovery XS/XO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Apr 20, 2009 at 09:45:28AM -0400, p...@laptop.org wrote: benjamin m. schwartz wrote: Martin Langhoff wrote: The short of it is that mdns/dns-sd make sense for a small, underutilised network of peers. They assume that the network is a cheap resource, that broadcast messages are cheap, and that there is no coordinating server. mDNS assumes all of the above things. DNS-SD does not. DNS-SD is perfectly happy to work on a standard DNS server. From the spec This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. This document simply specifies a convention for how existing resource record types can be named and structured to facilitate service discovery. (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) the last i looked at (and actually used) dns-sd to solve the discovery problem, it seemed that dns-sd development had stalled. (and i haven't had a reason to look since.) i believe we used code from Sun, which was all i could find at the time, and it wasn't what you'd call production ready. on the other hand, we were using it in a somewhat non-standard way -- in fact, we switched to mdns soon after because it fit our deployment model better, since we didn't really have a central server. the XS model may be a better fit. (this was all 3 or 4 years ago, btw.) Here's my understanding: * DNS-SD is a formalized use of DNS records to store services (rather than hosts, the most popular use of DNS records). * mDNS is DNS over multicast (using DNS-SD to resolve services). So it seems to me that if you've switched from DNS-SD to mDNS, then in fact you are still relying on DNS-SD, just using an additional layer on top of it. A good introduction (assumably more reliable than Wikipedia) is http://www.dns-sd.org/ - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkns0S8ACgkQn7DbMsAkQLipkACfW9CWHqtdtytFZuNrCzm0Jmrd jIkAn3zqgu6B6Ic7sFeINPjVGpmjmKCA =J4B8 -END PGP SIGNATURE- ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Apr 08, 2009 at 01:40:57PM +0100, Peter Robinson wrote: There are two separate issues I encountered with TA (and Measure). One is the need for patches to the alsa audio to accommodate the special OLPC hardware modifications. That would need to be accepted upstream by the alsa project, and then distros will automatically get the changes when they are part of a release. Or (less effective but sometimes possible if in a hurry): Convince distributions to accept patches, even if upstream rejects it (or temporarily while upstream procedures might be slow). For Debian, the package this would probably land in would be alsa-firmware-loaders (if I understand it correctly), and the people to contact about it are reachabel on this email address: pkg-alsa-de...@lists.alioth.debian.org Sometimes it might even ease upstream adoption if first working with distributions on shaping/polishing patches. Kind regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknfJwUACgkQn7DbMsAkQLiJKACglphhhquwpqVytDJe1nPYRd5a 5OYAnRmVeYSjoluVH4OqbWv4cUxukrae =Ve+F -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [Sugar-devel] Gadget on XS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Apr 01, 2009 at 10:18:37AM -0500, David Farning wrote: On Wed, Apr 1, 2009 at 9:47 AM, Jonas Smedegaard d...@jones.dk wrote: On Wed, Apr 01, 2009 at 03:22:12PM +0100, Guillaume Desmottes wrote: Le mercredi 01 avril 2009 à 14:14 +0200, Jonas Smedegaard a écrit : On Wed, Apr 01, 2009 at 11:50:52AM +0100, Guillaume Desmottes wrote: The Debian package write logs to /var/log/gadget.log iirc; What Debian package? Gadget does not seem to be in Debian Sid. I'd be happy to help maintain it officially for Debian if there is already a Gadget package floating around unofficially. See http://dev.laptop.org/git/projects/gadget/log/?h=debian Above URL does not clarify if it is in Debian officially. If my questions are too silly to respond to with human words (as opposed to just URLs), then I shall not bother you anymore with them. Please try to stay polite. Hi Guillaume (and everyone else), Sorry for being rude. You mention a Debian package, and I wonder: 1. Is it a Debian package of Gadget, ejabberd or something else? 2. If it is a Gadget package, is it targeted for Debian officially? 3. If yes, are you interested in help maintaining such package? 4. If no, are you interested in helping maintain it officially? Your brief response above seems to indicate that indeed it is a Gadget package. I am still interested in clarification about questions 2, 3 and 4. If you answer with a URL, then I would appreciate that you also write some human words too, as I believe (contrary to David, possibly) that it can help avoid misunderstandings. Kind regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknTikYACgkQn7DbMsAkQLiXQQCeIq5D8lwGeCTwC7vhHZaEFSiE HwgAnAuQW10B4V6gas5U9gS5X3l/INUU =hpQl -END PGP SIGNATURE- ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] [Sugar-devel] Gadget on XS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Apr 01, 2009 at 04:49:33PM +0100, Guillaume Desmottes wrote: Le mercredi 01 avril 2009 à 17:37 +0200, Jonas Smedegaard a écrit : 1. Is it a Debian package of Gadget, ejabberd or something else? The link I pasted you is a git branch of Gadget containing a 'debian' directory used for the packaging. These files are http://dev.laptop.org/git/projects/gadget/tree/debian?h=debian 2. If it is a Gadget package, is it targeted for Debian officially? It could but has not been proposed to Debian yet. 3. If yes, are you interested in help maintaining such package? 4. If no, are you interested in helping maintain it officially? Sure. Any help is welcome. Ah, I see now that Dafydd is participating in that packaging, and that he is an active Debian maintainer already maintaining Telepathy and Farsight officially for Debian. I suspect you have no need for my help here. I would personally use a different packaging style (Wrap debhelper with CDBS and extend with more CDBS wrappers, host the packaging Git at Alioth collab-maint area to ease collaboration with other Debian developers, etc.). But all that is really just nice to have, not need to have. And such changes could demotivate Dafydd or others from collaborating - not everyone fancy same packaging styles. If you are still interested in my help, then tell me! I will then happily repackage using CDBS at Alioth and release officially for Debian. And I will help provide write access to that new Git to you and other non-Debian folks possibly interested in participating directly (Dafydd have write access already). Else I will just lean back and wait for Dafydd to eventually release the package himself in his own pace officially to Debian. (actually no, I will not just lean back: I will move on to other packages needing help - e.g. Abiword which I am working on at the moment, to get the Write activity to Debian) Sorry, I was quite busy when I replied to your mail. Ah, makes sense. Hope it's clearer now. I understand it now, yes. Thanks :-) - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknT0LQACgkQn7DbMsAkQLhB2wCfYop1fPWWaVzIOrwsErscZ7hI htAAn0p+XqwdcRjB1JHu2GvA3jIF7qkF =h2Mm -END PGP SIGNATURE- ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] [Sugar-devel] Gadget on XS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Apr 01, 2009 at 09:11:46PM +0200, Martin Langhoff wrote: On Wed, Apr 1, 2009 at 5:49 PM, Guillaume Desmottes guillaume.desmot...@collabora.co.uk wrote: (CCing Daf who is the author of this Debian package). I suspect it's a small misunderstanding. It's a 'deb' package, (the collabora team is very good in making sure their software is available as .deb. and rpm) but not a 'Debian' package in the sense that it's not in the Debian archive. That's all. Jonas, I am sure you've seen this situation before :-) No misunderstanding there: I understood Debian package as Debian-compatible package - which technically means a DPKG package that in its binary form has a .deb extension. My questions was (partly) about whether or not that Debian package was targeted Debian officially or not. - Jonas P.S. It seems Dafydd was _not_ cc'ed this thread, despite the note about it. - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknT0sAACgkQn7DbMsAkQLjGogCgmmEL7PFDxq/u4x56bpNkjjpC DeIAmQHU6tTzLcotvmAm4sdT9Z8InNZZ =LJBP -END PGP SIGNATURE- ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Sugar-devel] Journal empty in Soas-200902231225 and what is Soas-200902241809.iso in snapshots/2/ ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 25, 2009 at 07:41:43PM -0800, Edward Cherlin wrote: On Wed, Feb 25, 2009 at 6:50 PM, Ton van Overbeek tvoverb...@gmail.com wrote: When trying out Soas-200902231225 the journal stays empty. Anybody else seen this ? Please look at the logfiles below ~.sugar/default/logs (or wherever they are stored on your installation), and post info on any indications on crashes found there. This is true in several versions of Sugar, including Ubuntu packages. Jonas Smedegård has made a patch for it, available from http://debian.jones.dk/ sid sugar Above is not usable for Soas - and my website contains more than 2000 Debian packages, so above is little use even for Sugarlabs developers. The actual patch is patch 0001 that I have now posted here: http://debian.jones.dk/pkg/sugar/sugar-datastore/sid/auryn/patches/ The patch was grabbed from Sugarlabs development tree, so should be already applied in recent releases of sugar-datastore, which I believe is in the Soas release mentioned above. In other words: Even if the symptom is the same, this most likely is *not* the same problem that used to be in Debian and Ubuntu. Kind regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmmG2gACgkQn7DbMsAkQLiCBQCgnkNN4rsJVqdiCL4iK8akj8KJ Ez4An3zQtxYQ9nrx0VWaZobLb9Jm2AKj =hs2Y -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Jan 23, 2009 at 10:45:15AM +0100, Bernie Innocenti wrote: Jonas Smedegaard wrote: Use the recommended style as mentioned in Git documentation somewhere: First line a summary of at most 40 chars, then empty line, then optional detailed commit message (which is stripped by git-shortlog). Also, I'd suggest mentioning ticket numbers at end instead, in the style used by Debian. Example: Fix foobar - barbaz. Closes: SL#1234, OLPC#1235. The logic is to always prepend Closes: and then either SL# or # for each comma-separated ticket closed, or prepend OLPC# for tickets closed at the laptop.org bugtracker. Some thoughts: - Because the commit message summary appears in the shortlog, it should be kept below 74 characters to avoid ugly wrapping. Git prepends commit hashes, which is the reason for keeping it even shorter. I do not remember where I read it but am pretty sure their recommendation is to keep first line at most 40 chars. - Given the above, the word Closes: steals precious characters, and is rather easy to deduce, therefore I'd opt it out. It really makes better sense to me to not squeeze bug hints into that first line at all, but instead include them in a later line of the commit. Dropping the leading Closes: makes it harder to rely on for automated bug closing. You might not care about that, but I must say that I find that mechanism pretty cool on Debian. - To reduce clutter, I'd make the SL prefix implied, and leave other prefixes such as OLPC#123 and RH#456 explicit. You mean that you agree with my proposal of having SL _optional_ or you mean that it must never be there? Imagine a future fork of Sugarlabs. Let's call it Suguntu to hint at where I am going with this. Suguntu has their own bug tracking system, and some Sugarlabs developers gets hired to work on both systems in parallel. In the beginning Suguntu acts as downstram to Sugarlabs, but over time some parts of Sugar then gets primarily maintained at Suguntu so some changelog entries close Suguntu bugreports and not Sugarlabs ones. I'd say it makes sense to allow SL as a hint, but just have it be optional so that for packages only maintained upstream at Sugarlabs there is no need to add it to eah and eery bug hint. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkl6DCsACgkQn7DbMsAkQLgoMQCfdkb5ic6AZh0qcgWwKW6uJscy rtgAmQFGsA8+aqVq/NARmOj1LrMd0dN0 =51oi -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Jan 22, 2009 at 09:54:36AM +0100, Simon Schampijer wrote: So the command for sugar for this release would be [...]: git log v0.83.4..v0.83.5 --no-merges | git-shortlog That will encourage people to write nice commit messages :) I would suggest to put up some guidelines (no rules), so a reader can more easily parse them. For example: - ticket number always at the beginning of the commit message - Start message with a capital letter - For typo fixes use: _Typo - For pylint fixes use: _Pylint Use the recommended style as mentioned in Git documentation somewhere: First line a summary of at most 40 chars, then empty line, then optional detailed commit message (which is stripped by git-shortlog). Also, I'd suggest mentioning ticket numbers at end instead, in the style used by Debian. Example: Fix foobar - barbaz. Closes: SL#1234, OLPC#1235. The logic is to always prepend Closes: and then either SL# or # for each comma-separated ticket closed, or prepend OLPC# for tickets closed at the laptop.org bugtracker. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkl4irQACgkQn7DbMsAkQLgCDQCbBObD5vCNDLrGX3HNLNK1RvFg vokAniZd0hz/KXxZ2JhUf1Fr8s6me++e =4VCG -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
samurai-x2: Python-based window manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Recently it was discussed here why no Python library existed that interacted directly with core X11. Today I saw mentioned at lwn.net the Python-based window manager samurai-x2 which might be interesting in relation to that, and perhaps even more concretely as a default Window manager for Sugar? More info here: http://samurai-x.org/ And here: http://lwn.net/Articles/312681/ If there is interest, I would be happy to attempt packaging samurai-x2 for Debian. I have plenty of other interesting tasks too, so will only do if if someone finds it relevant. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklVhX4ACgkQn7DbMsAkQLio4ACffJsJrVjZZogvOCMY7RIPkWcV yIgAnRMjG2yETGwdq8Q8+mITAjVyksAc =RpFZ -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Jun 27, 2008 at 10:17:54AM +0200, Antoine van Gelder wrote: The analogy doesn't work. If I have C, I'll send the C. I have friends who used to write APL and ship Ada as source, and their military customers never complained. If the generated C is well-structured and has the comments from the Smalltalk embedded, so that people can understand it, what's the problem? What happens if I make my changes to that generated C and then try to submit those changes to the generated code back to the Squeak project? I think this is what Yoshiki means when he says: if you send them C that's generated and call that your source, it's the same thing as writing your code in C and sending assembler as your 'source' (assuming there was a cpu independant assembler) Free software is also the freedom to develop code with the source you are supposed to have access to. ...and the deroute through C does not conflict with that freedom. The freedom to develop based on the provided source is what we call forking. You are talking about the ability to give back to the original community, which is a different thing. If I develop based on the source provided by Linus Torvalds (the Linux kernel) and want to give back to the original community my changes, then they will get rejected if I do not follow their coding style and their way of commiting patches. If I understand correctly, the Squeak community accepts patches generated from their binary images. So the real question is, if images built from C sources can generate patches acceptable by the Squeak community. I honestly do expect Debian to approve Squeak if such C decompiler is invented. And I imagine the Squeak community will support it too, if recompiled code generates images workable with them (rather than working as a slight fork). Hope I made sense here - I am _very_ new to the Squeak concepts, following these discussions as part of my packaging Sugar software officially for Debian. Kind regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkhkq4MACgkQn7DbMsAkQLjptQCgns8VuwXTa4hqrICtcUA2gPGU r/AAn1iAK9KwAy9i+WmMumfawwUNfzQ3 =eFlz -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
