Re: [Sugar-devel] karma repo is huge!
On Tue, Jan 5, 2010 at 03:26, Bryan Berry br...@olenepal.org wrote: alright, I saved 30 MB by putting the temporary build/ directory into .gitignore $ git repack -a -d -f --window=100 --depth=100 shrinks it from 109 MB to 82MB, that's a nice change I have added and removed huge sets of files Is there a way to remove select files from the index that are no longer in the working tree? http://progit.org/book/ch9-7.html See the paragraph « Removing objects » -- Mathieu Bridon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] resource for understanding git
On Fri, Dec 11, 2009 at 17:32, Tomeu Vizoso to...@sugarlabs.org wrote: Unfortunately, for learning git you need to have some knowledge of its architecture. This link has helped me understand quite a bit of things: http://www.newartisans.com/2008/04/git-from-the-bottom-up.html If you have some time, this book is excellent : http://progit.org/book/ -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] moving some more configuration to gconf (was Re: some efforts that would be really useful for deployments)
On Mon, Dec 7, 2009 at 10:11, Simon Schampijer si...@schampijer.de wrote: Yes, I think it makes sense to control settings via gconf - this should be our standard way. Isn't Gnome thinking about dropping GConf ? (in favor of DCconf as far as I understood) I'd be worried about using a technology that upstream is not certain to go on maintaining :-/ -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Roadmap to 0.88 --- Proposal
- Testing: I hope to see much much more testing in this release cycle. Two things should help here: a) I encourage the creation of a testing team. b) The 0.88 release will be packaged early. For testing purposes 0.88 will be packaged for F12. Other distributions are encouraged to do similar. Do you really want to package an unstable release (for testing purpose) into a stable distribution? Some people might actually be using the stable distribution, and they might not be really pleased by having some work-in-progress-please-test release forced upon them. :-/ Unless you're talking about packaging 0.88 for F12 but not actually pushing it to the stable repository? -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] rawhide report: 20091010 changes
On Sat, Oct 10, 2009 at 14:59, Rawhide Report rawh...@fedoraproject.org wrote: Compose started at Sat Oct 10 06:15:04 UTC 2009 Broken deps for i386 -- konversation-1.2-1.fc12.i686 requires kdelibs4 = 0:4.3.2 sugar-toolkit-0.86.0-1.fc12.i686 requires python-json [snip, same for x86_64, ppc and ppc64] Removed package gai Removed package gai-pal Removed package gai-temp Removed package python-json Do we have a problem Houston ? -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A Virtual Box solution that works with Sticks
Can anyone think of way to use Virtual Box that would allow students to use the info on their sticks so they can at another point in time use a classroom computer and not always need to use the same MacBook? I don't quite understand your question. If the students boot the system on their sticks and write their data on them, then the data are on the sticks, not on the MacBook. What's the problem here ? -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugaronastick.com (was Re: Beta Test of Sugar on a Stick Backup Service.)
The only problem I see is that the same name is used to denominate a community project and a private initiative. These are two different things but not different enough to avoid confusion. I'm not talking right now about name ownership, that's why I listed as a possible solution that the community project drops the sugar on a stick name and chooses something else. Each possible solution has its own upsides and downsides but I'm not there yet, I'm only exposing the problem for now. Do we agree we are now in a confusing situation that unless we solve it will have bad consequences for all? How about sugaronastick.com for the private initiative and sugaronastick.org for the upstream community project ? Lot's of FOSS projects do that. And I guess that Caroline and her crew from sugaronastick.com will participate actively in the community SoaS. If this is not a far-away derivative, couldn't that work ? -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] SLOBs Position on SoaS
On Wed, Sep 16, 2009 at 16:24, Daniel Drake wrote: 2009/9/16 Sebastian Dziallas: Let me rephrase again, to make things clear. I'd love to hear an official answer on this. Soon. Is the current SoaS going to be the primary way Sugar Labs distributes a Sugar-centric GNU/Linux distribution? Isn't there a wider question first? the one that asks if Sugar Labs is actually interested in being a distributor rather than just an upstream. I raised that question in my recent discussion and my feeling is that the responses basically said well we should really just focus on being an upstream since we already are overworked there, but actually Sugar Labs is just a platform where everyone interested in Sugar can get together and run Sugar-related projects Based on that, I'd say that SoaS is a fine project to sit under Sugar Labs but there shouldn't be a primary way of getting Sugar. Like other upstream projects, Sugar Labs should work with multiple downstreams (treating them equally) in order to achieve wide adoption of the software. That's what I think as well. Sugar should be yet another DE in its relationship to distribution. That doesn't prevent SL to distribute some kind of a demo image (like Gnome does with Farsight Linux, for marketing purpose mainly), but the primary way of getting Sugar should be ask your OS-vendor IMHO. And no, I'm not saying that SoaS should be nothing more than a discardable demo. I see SoaS more as a downstream OS-vendor, distributing Sugar. -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] SLOBs Position on SoaS
I admit to having some difficulties understanding why you would want to keep Sugar as an upstream only. Perhaps the arguments have already been made. I'm a late comer to the list so I am certainly unaware of what's been discussed prior to my joining in July. If so could someone please give me a pointer? Or a recap? Creating and maintaining a full distro is hard and time consuming. SL has limited resources. If SL was an upstream-only project, SL could thus focus on doing what only them can do (developing Sugar) while letting the distributors do what they know best and are already doing anyway (integrating the developers' work into a product and distributing it). Of course, distributors can include people from SL (helps on integrating the developments properly into the distribution), and distributors can help SL doing development (fixing issues that only appear when building RPMs for example). The issue is not about the individuals doing work, rather about the projects defining their own responsibilities. And remember, we (in Fedora and other distributions) are *already* integrating Sugar in our product (the distribution). SL really doesn't *need* to do this once again. Best regards, -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fedora's RPM format changes break mock in Debian/Ubuntu
I suppose the question is better stated as 'since when has Fedora supported/enabled Lua support in RPM packages, and where was this change posted?' Quick google searching didn't seem to turn up anything relevant, nor does the rpm changelog [1] (suggesting its been supported for a while?). That I can't tell you. I guess your question would be better answered on fedora-devel: http://www.redhat.com/mailman/listinfo/fedora-devel-list However, is the since when really that important? I guess rebuilding mock in Debian with Lua enabled would fix the issue right? -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Call for volunteers to implement Bug Report feature
On Mon, Aug 17, 2009 at 18:29, Luke Faraonel...@faraone.cc wrote: On Mon, Aug 17, 2009 at 11:53, Aleksey Lim alsr...@member.fsf.org wrote: One of sugar lacks is an easy way to send bugreports(especially for non-tech users), so if someone interested in please pick [1] up. From what I've seen on IRC, Sebastian Dziallas is currently working on a solution, either by porting Apport to Sugar, using GNOME's bug-buddy, or the Fedora bug reporter. (still in the investigative stage) That's what I was going to suggest. There are already way to much of those tools, don't bother creating a new one only for Sugar :) Bug Buddy might be too tied to GNOME to be useful for Sugar. However, here are some informations on the one Fedora is developping: https://fedorahosted.org/abrt/wiki http://fedoraproject.org/wiki/Features/ABRTF12 Hope that helps -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bundling libraries, RPMs? (was Re: WatchMe-1, a VNC activity)
I assume you know that when users are installing Sugar 'activities' they don't have root access, and that the install is completely in ~ ... If we get on the do the right thing horse, then we have to ensure user-installable RPMs (relocatable I think is the feature name) are working. AFAIK they aren't And as I've already explained on the fedora-olpc list (I wasn't on sugar-devel at that time), they are. Just don't use yum. Use PackageKit. PackageKit uses PolicyKit for the authentication framework, which means you can very easily define the following permissions: 1. user A can install signed RPMs from the repositories without root password 2. user B can update his system, providing the root password for the first time but then without password 3. user C can install signed RPMs from the repositories as well as unsigned RPMs entering his own password. PackageKit comes with a second benefit: it is cross-distros. This means Sugar could have its own Install/Remove/Update interface, which would work on Fedora, Debian, OpenSuse,... -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bundling libraries, RPMs? (was Re: WatchMe-1, a VNC activity)
On Mon, Aug 17, 2009 at 21:52, Luke Faraonel...@faraone.cc wrote: On Mon, Aug 17, 2009 at 15:48, Mathieu Bridon (bochecha) boche...@fedoraproject.org wrote: PackageKit uses PolicyKit for the authentication framework, which means you can very easily define the following permissions: 1. user A can install signed RPMs from the repositories without root password 2. user B can update his system, providing the root password for the first time but then without password 3. user C can install signed RPMs from the repositories as well as unsigned RPMs entering his own password. So PackageKit allows me to install the RPM for me, and only me, without affecting other users? No. RPMs are installed for the whole system (or in a chroot, but that kinda replicates another system). I didn't really see the need for installing activities in ~/, I really can't imagine why you'd want to install all their dependencies in ~/ as well :-/ (and « because we can't ask the user the root password » is not a valid excuse, see PolicyKit) -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bundling libraries, RPMs? (was Re: WatchMe-1, a VNC activity)
The whole point is a learner/teacher can modify any activity at any time and then share that modification in a safe, sandboxed way, to other Sugar users (and perhaps back to us). No existing packaging systems seem to have any concept of this basic Sugar feature/goal :-( Don't the .xo packages provide this ? :) They all shout root, root, root You never used PackageKit right ? As I said, PackageKit uses PolicyKit and can then be configured to *not* ask for any password in order to let the user install new applications. Actually, here is how I setup my mom's computer: - don't ask for password for updates (I want my mom to have bug fixes and security updates quickly, and I don't want to bother her with passwords) - ask for root password for installing or removing applications (I don't want her to install/remove an application that could break her computer as I'm too far to help her fix it quicly and efficiently) That's an example, PolicyKit enables much more. and have install dependancies splattered across the OS like some midnight software massacre :-(( How is that a problem ? Dependencies are not « splattered », they are « shared » ;) Apple I think are the closest I've seen, if you app needs some zany dependancies then it includes them in it's bundle (just like Sugar bundles). And you get tenth of copies of each and every library (sometimes in different versions) on your disk, loaded in memory,... Bundling dependencies is definitely a bad idea. For the Mac users, it's just Drag this application to your application folder. Done, end of story. I read something about this for Linux as well. Now that we have a cross-distro package manager front-end, someone was talking about having a FUSE mounted pseudo-filesystem where a user would simply drag and drop a « something representing the application » and in the background, it would invoke the package manager to install the application and all its dependencies. Kinda cool as it takes the easiness of Mac and brings to it the flexibility of package managers from Linux :) However, I don't see this as a good solution for Sugar, or if it is, I still have to find the file explorer ^^' Now, let's talk about activities.sugarlabs.org. Basically, it's a web interface where the user browses for activities and installs them by clicking on pretty links. Reminds me of this: https://fedoraproject.org/wiki/Features/PackageKitBrowserPlugin With this, a user can click on a link, and it will launch his package manager to install the application *from the configured, known and safe repositories* (rather than by downloading them on an obscure web site that could be providing malware). And if you had configured it to not ask for root password, what you have is basically the functionality of a.sl.o :) Oh, and did I mention that PackageKit can use several backends, and thus a backend fetching from a.sl.o rather than from the distros repositories (like the yum backend for example) could be envisioned ? (thus installing in ~/ if you so desire) I know I mentioned this already (at least on fedora-olpc, not sure if I did here as well) but it looks to me like PackageKit can really provide most of what you're trying to do. All I can see missing is the possibility to install several versions of the same activity in parallel, but that depends more on the packaging system (.xo bundles) and the actual package manager than on PackageKit. -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] Ad-hoc networks - New Icons
Also, I believe NetworkManager still has no concept of AP mode Do you mean that with NM you can't become an AP ? Something like that: http://magazine.redhat.com/2008/10/16/video-fedora-10-connection-sharing/ ? Or did I misunderstand what you meant ? -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Call for Help: SoaS Display Manager (Auto-Login)
Sorry, I was once again victim of GMail's interface and answered only to Sebastian instead of to the list. -- Forwarded message -- From: Mathieu Bridon (bochecha) boche...@fedoraproject.org Date: Sun, Aug 9, 2009 at 19:05 Subject: Re: [Sugar-devel] Call for Help: SoaS Display Manager (Auto-Login) To: Sebastian Dziallas s...@sugarlabs.org Hi, On Sun, Aug 9, 2009 at 19:00, Sebastian Dziallas wrote: Ton van Overbeek wrote: Regarding getting auto-login to work after restarting X. Yesterday I looked at the slim sources and it seems at first sight easy to add auto login of the default user after the first login. Any interest in me trying to implement this? If we use an extra option to slim we could push this change upstream to Fedora and then we do not have to maintain our own manager (olpc-dm). But maybe Sebastian is already happy with a working olpc-dm. Ton van Overbeek Ahhh! Sorry, I missed this entirely and just noticed it in another folder when going through my e-mail today. Well, I certainly wouldn't mind if you went ahead and gave it a try, but I'm not sure how likely it is that this change would be accepted, pushed into a release and then packaged for Fedora. One thing to keep in mind: it would have to be actually accepted *upstream* before it can go in Fedora. Also, Rawhide is now frozen for F12Alpha, so even if that's accepted upstream, if you want this change in Fedora 12, you'll have to ask a freeze break to Rel-Eng. [1] Better do it quick :) Best regards, [1] http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] How big might a full install of Fedora Sugar be?
What about doing a F11 GNOME install to a large USB drive, yum installing Sugar stuff, removing the unwanted bits, resizing the partitions to desirable size, and then dd ing that to a desirable USB stick (marked bootable) as a master img? And do that process again each time you want to release an updated image ? Use a kickstart file, create the master image with pungi, then let it install itself automatically on the USB sticks. That's exactly what Sebastian has been doing with SoaS, except he created live images when you want installed systems. For the non-fedora people A kickstart file is a list of packages which you want to install. You first create the kickstart file using a tool called pungi. Then you put the kickstart file on your install DVD. So, whenever you do an install with that dvd you get the package set defined in the kickstart file. Just to be the boring pedantic guy who loves correcting people: you actually first write the kickstart file (manually, or using system-config-kickstart) and then feed it to pungi who will take all the infos in the kickstart file and generate the isos. But the rest of your message still holds true :) This is how the xs image is create. The xs team takes a few standard rpm files and modify them to meet the usecases intended for the xs and stick those file in a xs repo. Then they create a kickstart file listing the files that want to install. To save space they really limit the required packages. Then they tell kickstart to first in the xs repo and second in standard fedora repo for packages packages. There is a step of creating a special package to run post install configure scripts. But don't think too hard about that it is enough to make your head explode. So there is no 'set' size for an install hope that helps -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar on a Stick File Structure - Summary of problems and potential solutions
My original response went only to you (it seems like I'm having more and more of this, sorry about that) so you in turn only replied to me. Here it is for all the list to benefit :) On Sun, Aug 2, 2009 at 01:12, Caroline Meekscarol...@solutiongrove.com wrote: All, This was my attempt to put together a list from the brainstorming we have been doing so we can all look at it, generate more ideas and decide which ones we can eliminate. Hi Mathieu, Thanks, I didn't know that a full install still wouldn't be readable on a windows machine. I;d be interested if anyone has any ideas. Its not unusual for things you want to optimize to be correlated negatively or positively. Also the things to be optimized are not necessarily things that are wrong with the current system for instance it excels at size. Mathieu, can you tell me more or point me to documentation about the Overlay? Jeremy Katz, one of the Fedora devs that worked on the liveCD/USB technology we use in Fedora already answered and shared some light in the other thread where you were asking for more information (I had put him in CC). You should definitely bounce on his answer if you still need more, I think he's one of the people with the most knowledge on this matter :) Walter, We are clearly mis understanding each other somewhere. Would it help if I changed Solutions currently being considered: to Potential Solutions we are currently considering testing to see if they work and how they compare on the things we want to optimize for: I'll start another thread about failures and what we know about them within the next 48 hours. Walter, can your OpenSuse USB can be read by Windows? Except if the OpenSUSE key uses FAT32 (or NTFS) as a filesystem, I doubt it will (and I really doubt those are used on a Linux live system :) On Sat, Aug 1, 2009 at 6:46 PM, Mathieu Bridon (bochecha) boche...@fedoraproject.org wrote: Hi, To be acceptable a solution should solve all of these problems. 2. Allow a VM system to read user files and thus allow us to create a VM that can switch users 3. Allow a user to put the stick into a windows/mac/linux machine and find their files This is always going to be a problem. For exemple, the default Linux filesystem (at least on Fedora) is ext3 or ext4. Windows can't read those filesystems (without adding some experimental software), so even a full install will not solve this issue. Things we wish to optimized 1. Ability to work with poor quality sticks 3. Amount of abuse the stick can take and still work Those 2 seem rather contradictory, and I'm not sure there's a lot that can be done in software, at least in Sugar world :) 2. Size of stick needed 4. Size of download to create the stick 5. Time it takes to create the stick Those three are intimately related. If we can make the image as small as possible, it should be faster to create it. 6. Easy user experience creating the stick What exactly are the problems ? Speaking only for myself, I never had a problem creating a SoaS USB (but I might not be representative of your target population :). Were all usability issues reported upstream ? https://fedorahosted.org/liveusb-creator/ Live USB Creator works great! Its been a tremendous boon in getting people to try Sugar. I did report a bug, I think it was fixed. I don't know if you are behind the LiveUSB creator for windows but please tell whoever did it thank you! However, our Sugar on a Stick in a classroom use case will require us to create our own. We need something that lets a teacher pick what activities and language the kids should have and probably preload some content then clone sticks with all those settings but without the name and the key we use for collaboration. We'll want something that works from within Sugar. We'd love help with this project! A teacher will need to make 20-30 sticks or if they are the computer teacher for the whole school (this is common in the US) 100-300 sticks. We would thus like something that can use a standard cheap 4-8 USB port and create multiple USB sticks without user intervention between sticks. Do you know of any existing solutions for that? Solutions currently being considered: 2. Full install of Fedora As I said, this will not fix the issue of accessing files from Windows (no idea from Mac OS X). Darn! -- Mathieu Bridon (bochecha) -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax Best regards, -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] How big might a full install of Fedora Sugar be?
What about doing a F11 GNOME install to a large USB drive, yum installing Sugar stuff, removing the unwanted bits, resizing the partitions to desirable size, and then dd ing that to a desirable USB stick (marked bootable) as a master img? And do that process again each time you want to release an updated image ? Use a kickstart file, create the master image with pungi, then let it install itself automatically on the USB sticks. That's exactly what Sebastian has been doing with SoaS, except he created live images when you want installed systems. -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Documenting the SoaS file system
From what I understand, the squashfs is *never* rewritten once created. All changes are stored in a LVM Snapshot, which is just another file on the underlying FAT filesystem. As far as I know, what happens is this: * At build time, all packages are installed (and so is the base system) and end up in an image, which gets compressed using squashfs. * Once you boot your disk / device, any change you make gets saved into this spurious file (either for the overlay or home), which contains only the changes made since you booted for the first time. Those changes get - again afaik - mapped with some magic (don't ask me how, maybe some Fedora folks or the wiki know) on the fly into the usual filesystem. That's also what I understood. And if I'm not mistaken, the magic involved is a pinch of UnionFS (a read-write partition that is mounted as an overlay on top of the root filesystem). Maybe the livecd-tools guys could confirm this. Jeremy, IIRC you worked on this, could you enlighten us ? -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
