Re: RFA: The Debian Jr. project
On Tue, 30 Sep 2008 16:30:40 +0200 Holger Levsen <[EMAIL PROTECTED]> wrote: > Yup. Has something happened on this in the last month? Miriam Ruiz has some ideas, but since our initial contact on the matter, I have not seen any action on them. > Sounds good and compatible :) OK ... > That said, I dont see much of a problem here, or maybe rather, an easy way > out: Debian Edu provides two key features: customisation of the desktop for > pupils/schools and providing a network infrastructure for schools. Debian Jr. > doesnt need the latter at all (or? kindergarten network seems a bit far out > to me atm, maybe its not), but thats no issue, as Debian Edu also already has > standalone installs. > > And we even have different desktop profiles for standalone installs now: kde, > gnome and sugar. And I would love to extend this to "kde for primary school, > kde for middle classes, kde for high school and university" and the same with > gnome. And then also kde & gnome for kids. > > I'd think this would boil down to provide a different installer image or > installation type with the existing image. So basically, a Debian Edu install > with "less overhead", which is not needed for a single^wstandalone kids > machine. Well, technically, it appears things would work out. > > How > > do you think children would view Jr if it were an arm of the Edu > > project? In Debian Jr, our focus is the child and the fun of > > discovery. While some progressive educationists claim to hold to these > > values, I worry about how kids would view the Jr project if it were > > absorbed into Edu. > > Hm. Honestly, I have no idea how kids see Debian Jr. now, maybe I wonder if > they can see it, as currently afaik its "only" a packaging effort within > Debian, so I dont think it's visible to them. Do you agree? ;) Probably. But it doesn't stop me from wishing this were not so. I didn't want Debian Jr. to be *only* a packaging effort. I wanted a living, breathing relationship between children, their caretakers and developers. We've fallen far short of this lofty ideal, but that doesn't mean it can't or shouldn't be kept alive. That's the distinctiveness that is at risk to be lost if we're just absorbed by Debian Edu. > Basically, to keep Debian Jr. distinct, I would suggest branding :) Not a bad technical solution, as I said. Let's just see what comes of the alternate proposal by Miriam to have youth lead this project as a group before going down that road, though. Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFA: The Debian Jr. project
2008/10/1 Ben Armstrong <[EMAIL PROTECTED]>: > On Tue, 30 Sep 2008 16:30:40 +0200 > Holger Levsen <[EMAIL PROTECTED]> wrote: >> Yup. Has something happened on this in the last month? > > Miriam Ruiz has some ideas, but since our initial contact on the > matter, I have not seen any action on them. I have some ideas and I plan to do work on this. I just didn't have time until now because this weeks have been really exahusting at work, and also due to some personal matters involving someone in my close family and the hospital. I might be a bit away these days, but I'm definitely not giving up the project :) >> Hm. Honestly, I have no idea how kids see Debian Jr. now, maybe I wonder if >> they can see it, as currently afaik its "only" a packaging effort within >> Debian, so I dont think it's visible to them. Do you agree? ;) > > Probably. But it doesn't stop me from wishing this were not so. I > didn't want Debian Jr. to be *only* a packaging effort. I wanted a > living, breathing relationship between children, their caretakers and > developers. We've fallen far short of this lofty ideal, but that > doesn't mean it can't or shouldn't be kept alive. That's the > distinctiveness that is at risk to be lost if we're just absorbed by > Debian Edu. I don't have the time nor the mood to fully explain my ideas right now, but I will. I want to have children and teenagers somehow involved in the development of what would be their distribution too, and I think I know how to achieve that. >> Basically, to keep Debian Jr. distinct, I would suggest branding :) > > Not a bad technical solution, as I said. Let's just see what comes of > the alternate proposal by Miriam to have youth lead this project as a > group before going down that road, though. Whatever I do, I don't plan to have separate repositories of any kind, but to use Debian's, so my plan would lead to effectively create a Debian branding targeted to kids. Greetings, Miry PS: I'm sorry for not beint more verbose right now. I'm a bit overloaded due to some things outside Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFA: The Debian Jr. project
On Wed, 1 Oct 2008, Ben Armstrong wrote: Probably. But it doesn't stop me from wishing this were not so. I didn't want Debian Jr. to be *only* a packaging effort. I wanted a living, breathing relationship between children, their caretakers and developers. We've fallen far short of this lofty ideal, but that doesn't mean it can't or shouldn't be kept alive. That's the distinctiveness that is at risk to be lost if we're just absorbed by Debian Edu. I absolutely subscribe to this statement. I've nothing against Debian Edu (rather the contrary) but I think Debian Jr. could do more for the original target audience if it would keep a team alive. Not a bad technical solution, as I said. Let's just see what comes of the alternate proposal by Miriam to have youth lead this project as a group before going down that road, though. That would be ideal. Miriam? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFA: The Debian Jr. project
2008/10/1 Andreas Tille <[EMAIL PROTECTED]>: > On Wed, 1 Oct 2008, Ben Armstrong wrote: >> Not a bad technical solution, as I said. Let's just see what comes of >> the alternate proposal by Miriam to have youth lead this project as a >> group before going down that road, though. > > That would be ideal. Miriam? That has been my plan since I said I was going to take care of the project. I want us to make a distro for children and teens made by youth themselves (of course, with the necessary technical assistance from our side), in which they can get involved, they can control its evolution and that they can feel it as their own (and not as externally imposed to them). I seriously think the best way of making it work is by having the kids themselves giving feedback and taking as much decisions as possible and my roadplan goes along those lines. The first step will be to design and develop the infrastructure needed for kids to get involved, and that's the point where I'm currently at. I plan to write more extensively on this when I have some time, but if anyone who likes kids or is a kid her/himself has time and is willing to get involved in helping push a project like this and wants to contact me, I'll be willing to get some time out of nowhere to explain my vision, to listen to alternative proposals to things I might be considering, and to coordinate. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#500481: RFP: python-webkit -- python bindings for webkit
Le dimanche 28 septembre 2008 à 19:32 +0200, Thomas Viehmann a écrit : > Package: wnpp > Severity: wishlist > X-Debbugs-Cc: debian-devel@lists.debian.org, > [EMAIL PROTECTED] > > * Package name: python-webkit > * URL : http://live.gnome.org/PyWebKitGtk > * License : LGPL (according to their webpage) > Programming Lang: C (it is a Python extension module) > Description : python bindings for webkit > > The prospective maintainer would most likely want to join/work closely > with the pkg-webkit group on alioth. > > Kind regards and thanks to the packager to be! Since it is probably going to be more widely used in GNOME 2.26, I’d like to maintain it in the pkg-gnome repository. Christophe, since you already proposed to maintain it, would you agree to co-maintain this package there? Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFA: The Debian Jr. project
Hi, On Wednesday 01 October 2008 11:37, Ben Armstrong wrote: > Probably. But it doesn't stop me from wishing this were not so. I > didn't want Debian Jr. to be *only* a packaging effort. I wanted a > living, breathing relationship between children, their caretakers and > developers. We've fallen far short of this lofty ideal, but that > doesn't mean it can't or shouldn't be kept alive. That's the > distinctiveness that is at risk to be lost if we're just absorbed by > Debian Edu. That living, breathing relationship stuff sounds good and like a worthwhile reason to keep Jr and Edu distinct. But then, it's also something I'd very much like to see for Debian Edu and Debian :) (Though then probably with slightly different players...) regards, Holger, who is also curious to read more about Miriams ideas... pgpFqCpl1q5ac.pgp Description: PGP signature
Re: Bug#500671: ITP: pgtap -- Unit testing framework for PostgreSQL
Ben Pfaff dijo [Tue, Sep 30, 2008 at 08:51:40AM -0700]: > Pierre Chifflier <[EMAIL PROTECTED]> writes: > > > pgTAP is a suite of database functions that make it easy to write > > TAP-emitting unit tests in psql scripts suitable for harvesting, > > analysis, and reporting by a TAP harness, such as those used in Perl > > and PHP applications. > > Please state briefly what a TAP is somewhere in the description. > (To me, a TAP is a virtual Ethernet device, but I think that that > is not what is meant here.) FWIW, it looks it refers to the Test Anything Protocol. Some pointers for it: http://testanything.org/ http://en.wikipedia.org/wiki/Test_Anything_Protocol http://www.szabgab.com/blog/2008/09/1220345643.html -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#500841: ITP: slicer -- software package for visualization and image analysis
Package: wnpp Severity: wishlist Owner: Dominique Belhachemi <[EMAIL PROTECTED]> Package name: slicer Version : 3.2.0 Upstream Author : Steve Pieper et al. URL : http://www.slicer.org/ License : BSD style license, with extensions Programming Lang: C++ Description : software package for visualization and image analysis Slicer, or 3D Slicer, is a software package for visualization and image analysis. .. Features include: .. Sophisticated complex visualization capabilities Scene snapshots allow capture of all visualization parameters of a scene Extensive support for IGT and diffusion tensor imaging Advanced registration / data fusion capabilities Comprehensive I/O capabilities -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#500786: on upgrade crash, udev installation may remain in an inconsistent state
This looks like an interesting issue. Does it have a solution? - Forwarded message from Ole Marggraf <[EMAIL PROTECTED]> - Subject: Bug#500786: on upgrade crash, udev installation may remain in an inconsistent state From: Ole Marggraf <[EMAIL PROTECTED]> Package: udev Version: 0.125-6 Severity: normal Hi, I am just about to upgrade a number of machines from an older lenny installation (about 6-8 weeks old) to the recentmost (lenny) packages. This includes upgrading udev from 0.114-2 to 0.125-6, plus some 700 other packages. On at least two machines, I encountered the following: The upgrade has crashed the machine (somewhere in the pam upgrade, I think, when restarting services, but this is of no importance here). The point is, udev is unpacked, and /sbin/udevtrigger is already removed. However, when the system crashes, the udev init script is still the old one, referring to the non-existent udevtrigger. On rebooting, this leaves the system in a very ugly state if the user does not know that all he needs to do is to move the new /etc/init.d/udev.dkpg-new to /etc/init.d/udev and reboot again (this just for the record in case anybody may need it). So, you know the packaging a lot better than I do, I suppose. Is it not possible to upgrade the udev init script at an earlier time in the installation process (maybe immediately after unpacking) instead of waiting for the general package setup phase? This would greatly reduce the chances that a crash in any of the other packages' upgrades leaves the udev installation in such an inconsistent state... I do not know whether this is just relevant for lenny-to-lenny updates, or whether it may also occur on upgrading from etch to lenny. Cheers, Ole - End forwarded message - -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
WARNING ! Violation detected in a document you authored.
Please contact your system administrator as you have violated system rules. The scanned document was QUARANTINED. Violation Information: The filename extension of attachment instruction.scr violated the content filtering rule Prohibit movies and music. No attempt was made to repair. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
