Custom Search
|
Date: October 29, 2004
From: Andreas Tille <tillea@xxxxxx>
Hi,
as you might have read in DWN there will be a Asian Mini-Debconf:
http://debian.org.cn/events/admc2005
which has a call for papers at
http://debian.org.cn/events/admc2005/cfp
I'd love if someone of the CDD projects would take part. I guess it would
be quite suboptimal regarding to travel costs if someone from Europe would
join this event. Thus I'd like to check whether we have some people who are
able to apply there and are living nearer to Beijing.
Kind regards
Andreas.
Date: October 28, 2004
From: Free Ekanayaka <free78@xxxxxx>
In-reply-to:
<20041028072047.GC7569@xxxxx> (Sergio Talens-Oliag's message of "Thu, 28 Oct 2004 09:20:47 +0200")
References:
<20041028072047.GC7569@xxxxx>
|--==> Sergio Talens-Oliag writes: ST> [1 <text/plain; us-ascii (quoted-printable)>] ST> FYI, an interesting message from Joey Hess to debian-security@xxxxx that can ST> be very important for all the people interested in Custom Distributions: ST> http://lists.debian.org/debian-security/2004/10/msg00166.html Is it the case of asking to copy testing to a not-yet-existing suite called freeze, when it comes to release? (see previous discussions on the topic) Cheers, Free
Date: October 28, 2004
From: Sergio Talens-Oliag <sto@xxxxxxxxxx>
FYI, an interesting message from Joey Hess to debian-security@xxxxx that can
be very important for all the people interested in Custom Distributions:
http://lists.debian.org/debian-security/2004/10/msg00166.html
Greetings,
Sergio.
--
Sergio Talens-Oliag <sto@xxxxxxxxxx> <http://people.debian.org/~sto/>
Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69
signature.asc
Description: Digital signature
Date: October 26, 2004
From: "cobaco (aka Bart Cornelis)" <cobaco@xxxxxxxx>
In-reply-to:
<417E38A6.3020204@xxxxxxxx>
References:
<200410252046.09107.cobaco@xxxxxxxxxxxxx> <200410252215.08989.cobaco@xxxxxxxxxxxxx> <417E38A6.3020204@xxxxxxxx>
On Tuesday 26 October 2004 13:44, Jonas Smedegaard wrote:
> On 25-10-2004 22:14, cobaco (aka Bart Cornelis) wrote:
> | 1) In order for gconf (and thus gnome) to make use of the method
>
> proposed by
>
> | this package the system-wide gconf path file needs to be replaced by
> | the one I have in doc/examples. This means that ideally at some point
> | you'd have gconf depend on desktop-profiles and include the changed
> | path
>
> file (it
>
> | doesn't change default behaviour, and it's more flexible).
> | -> having gconf depend on cdd-common seems weird to me
>
> Sound to me like convincing the maintainer of gconf to adopt your
> changes is the best aproach.
yes, but that'll have to wait till after the package enters the archive
> That is, off course, only if your hacked
> file works without your package installed.
as my package would need to be installed (thus it needs a depend)
detailed explanation:
by default the system-wide path file contains the following directives:
xml:readonly:/etc/gconf/gconf.xml.mandatory
include /etc/gconf/2/local-mandatory.path
include $(HOME)/.gconf.path
xml:readwrite:$(HOME)/.gconf
include /etc/gconf/2/local-defaults.path
xml:readonly:/etc/gconf/gconf.xml.mandatory
Note: include directives point to files that contain extra "configuration
sources", and get expended where they are.
Note: Directories and files pointed to don't need to exist (in fact a
just-installed gconf/gnome situation the 3 files pointed to by the include
directives don't exist)
Order is important, as gconf will use the first source that defines a value
-> anything mandatory must be in a source loaded before the user source(s)
-> all defaults need to be in a source loaded after the the user source(s)
To specify an additional config source for a group of users you have include
a userspecific path file ($(user) in the path file will get replaced by the
username) for each user -> pain in the ass if you have to do it manually
What my package does is:
a) generate at startup a path file with the configuration sources
applicable to the user which by default will contain the 5 directives given
above (will start to differ if additional profiles are installed).
Note: generation of this file is only actually done if it will be
included by the system-wide path file
b) to avoid having to set up the order/precedence of profiles (including the
default ones) in two places (stuff in /etc/desktop-profiles and system-wide
path file) the system wide path file should then only include 1 directive:
include <generated-path-file>
You could conceivily just add the include directive at the top of the
current system-wide path file, leaving it as is otherwise, this mostly
works:
+ works even withouth desktop-profiles installed
+ as long as the default profiles aren't disabled this works as expected
using desktop-profiles (stuff after our include is redundant, as it will
already be included somewhere by the generated path file)
- if the sysadmin wants to disable the default profiles he needs to do so in
2 places: desktop-profiles and system-wide path file (as the stuff after
our include is no-longer redundant)
-> not optimal (but workable in most cases, it's an option if I can't
convince the gconf maintainers to go wholy with desktop-profiles, once
desktop-profiles in the archives)
--
Cheers, cobaco (aka Bart Cornelis)
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
pgpSKH3kyp2XP.pgp
Description: PGP signature
Date: October 26, 2004
From: Andreas Tille <tillea@xxxxxx>
In-reply-to:
<200410252215.08989.cobaco@xxxxxxxxxxxxx>
References:
<200410252046.09107.cobaco@xxxxxxxxxxxxx> <Pine.LNX.4.61.0410252117010.10099@wr-linux02
> <200410252215.08989.cobaco@xxxxxxxxxxxxx>
On Mon, 25 Oct 2004, cobaco (aka Bart Cornelis) wrote:
1) In order for gconf (and thus gnome) to make use of the method proposed by this package the system-wide gconf path file needs to be replaced by the one I have in doc/examples. This means that ideally at some point you'd have gconf depend on desktop-profiles and include the changed path file (it doesn't change default behaviour, and it's more flexible). -> having gconf depend on cdd-common seems weird to me
This is true.
2) it's basically a mechanism for admins to easily find and control whatever desktop customizations get installed by CDD's/other packages/themselves. While hopefully CDD's will all use this to install their (desktop) customizations, I don't hink this is a something strictly for CDD's, so I think it is more logical to have it in it's own package what do others think?
You are right here - it was perhaps a to quick thoght from my side. Making cdd-common depend from your package seems appropriate.
This falls into the scope of user roles, IMHO.definately, you'll mostly have one profile specific to each role
So we probably have to adjust the user role tools ...
Kind regards
Andreas.
Date: October 26, 2004
From: Jonas Smedegaard <dr@xxxxxxxx>
In-reply-to:
<200410252215.08989.cobaco@xxxxxxxxxxxxx>
References:
<200410252046.09107.cobaco@xxxxxxxxxxxxx> <Pine.LNX.4.61.0410252117010.10099@wr-linux02
> <200410252215.08989.cobaco@xxxxxxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25-10-2004 22:14, cobaco (aka Bart Cornelis) wrote: | 1) In order for gconf (and thus gnome) to make use of the method proposed by | this package the system-wide gconf path file needs to be replaced by the | one I have in doc/examples. This means that ideally at some point you'd | have gconf depend on desktop-profiles and include the changed path file (it | doesn't change default behaviour, and it's more flexible). | -> having gconf depend on cdd-common seems weird to me Sound to me like convincing the maintainer of gconf to adopt your changes is the best aproach. That is, off course, only if your hacked file works without your package installed. ~ - 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.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBfjimn7DbMsAkQLgRAoocAJ92ls4+86tY8iYnUCXE+df3dxJEsQCeK/oh UizBf7fNq2XjAT52jirGtyA= =yGsc -----END PGP SIGNATURE-----
Date: October 25, 2004
From: "cobaco (aka Bart Cornelis)" <cobaco@xxxxxxxx>
In-reply-to:
<200410252215.08989.cobaco@xxxxxxxxxxxxx>
References:
<200410252046.09107.cobaco@xxxxxxxxxxxxx> <Pine.LNX.4.61.0410252117010.10099@wr-linux02
> <200410252215.08989.cobaco@xxxxxxxxxxxxx>
On Monday 25 October 2004 22:14, cobaco (aka Bart Cornelis) wrote:
> 1) In order for gconf (and thus gnome) to make use of the method proposed
> by this package the system-wide gconf path file needs to be replaced by
> the one I have in doc/examples. This means that ideally at some point
> you'd have gconf depend on desktop-profiles and include the changed path
> file (it doesn't change default behaviour, and it's more flexible).
> -> having gconf depend on cdd-common seems weird to me
s%doc/examples%/usr/share/doc/desktop-profiles/examples%
--
Cheers, cobaco (aka Bart Cornelis)
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
pgpajjGqy3A87.pgp
Description: PGP signature
Date: October 25, 2004
From: Free Ekanayaka <free78@xxxxxx>
In-reply-to:
<Pine.LNX.4.61.0410252117010.10099@wr-linux02
> (Andreas Tille's message of "Mon, 25 Oct 2004 21:24:38 +0200 (CEST)")
References:
<200410252046.09107.cobaco@xxxxxxxxxxxxx> <Pine.LNX.4.61.0410252117010.10099@wr-linux02
>
|--==> Andreas Tille writes: AT> On Mon, 25 Oct 2004, cobaco (aka Bart Cornelis) wrote: >>[1] it's located in debian-edu cvs an alioth src/desktop-profiles module, >>current build of the package is available at >>http://developer.skolelinux.no/~cobaco/desktop-profiles AT> While I'm far from beeing a desktop configuration expert the stuff you AT> described seems absolutely interesting for all CDDs. Keeping this in mind AT> I wonder if we might include the stuff you mentioned completely into AT> the cdd package. Good initiative! As this package might be of general interest (e.g. sysadmin, not cdd only), I'd rather keep it a separate package. Cheers, Free >>Further steps needed at this point: >>1) Get the package into Debian: -> packaging is done, but I need a sponser, as I'm not a DD AT> My suggestion would solve the problem of finding a sponsor. Just add AT> your stuff to cdd svn and patch the packaging method. The uploaders AT> of the cdd package will care for the upload. (Note: It is of course AT> just a recommendation and you are free to decide. But I see no real AT> need to have a lot of tiny little packages if they can be collected in AT> one package for all CDDs.) >>2) Once package gets into Debian change debian-edu-config to use it (add >>depends, remove custom xsession.d script, add debian-edu-config.listing >>file) AT> I hope that debian-edu will switch to cdd which (in case you accept my AT> suggestion) will implicitely solves this. >>3) Start discussing additional profiles/ current setup. What desktop >>customizations would you like to see (do speak up here ,we _need_ feedback, >>but drop debian-custom from CC when replying on this point :-) AT> I do not think that it would be too boring for people here. >>I think we should have (at least): >>- debian-edu-network -> proxy settings, .. anything common to desktops >>inside a debian-edu network >>- debian-edu-student -> settings for students (background, desktop icons, >>panel setup, maybe some things locked down with kiosk framework, ...) >>- debian-edu-admin -> settings for admins (links to admin-tools and >>documentation on desktop, ....) >>- .... AT> This falls into the scope of user roles, IMHO. AT> Kind regards AT> Andreas.
Date: October 25, 2004
From: "cobaco (aka Bart Cornelis)" <cobaco@xxxxxxxxxxxxx>
In-reply-to:
<Pine.LNX.4.61.0410252117010.10099@wr-linux02
>
References:
<200410252046.09107.cobaco@xxxxxxxxxxxxx> <Pine.LNX.4.61.0410252117010.10099@wr-linux02
>
On Monday 25 October 2004 21:24, Andreas Tille wrote: > On Mon, 25 Oct 2004, cobaco (aka Bart Cornelis) wrote: > > [1] it's located in debian-edu cvs an alioth src/desktop-profiles > > module, current build of the package is available at > > http://developer.skolelinux.no/~cobaco/desktop-profiles > > While I'm far from beeing a desktop configuration expert the stuff you > described seems absolutely interesting for all CDDs. hence the CC to debian-custom :-) > Keeping this in > mind I wonder if we might include the stuff you mentioned completely into > the cdd package. I thought about this, but (and this is open for discussion) : 1) In order for gconf (and thus gnome) to make use of the method proposed by this package the system-wide gconf path file needs to be replaced by the one I have in doc/examples. This means that ideally at some point you'd have gconf depend on desktop-profiles and include the changed path file (it doesn't change default behaviour, and it's more flexible). -> having gconf depend on cdd-common seems weird to me 2) it's basically a mechanism for admins to easily find and control whatever desktop customizations get installed by CDD's/other packages/themselves. While hopefully CDD's will all use this to install their (desktop) customizations, I don't hink this is a something strictly for CDD's, so I think it is more logical to have it in it's own package what do others think? > > 3) Start discussing additional profiles/ current setup. What desktop > > customizations would you like to see (do speak up here ,we _need_ > > feedback, but drop debian-custom from CC when replying on this point > > :-) > > I do not think that it would be too boring for people here. :-) it's debian-edu specific, so I'm guessing the people interested are on the debian-edu list already > > I think we should have (at least): > > - debian-edu-network -> proxy settings, .. anything common to desktops > > inside a debian-edu network > > - debian-edu-student -> settings for students (background, desktop > > icons, panel setup, maybe some things locked down with kiosk framework, > > ...) - debian-edu-admin -> settings for admins (links to admin-tools > > and documentation on desktop, ....) > > - .... > > This falls into the scope of user roles, IMHO. definately, you'll mostly have one profile specific to each role P.S. I'm on the list so no need to CC me :) -- cobaco (aka Bart Cornelis): Coördinator Belgisch Skolelinux team Coördinator Nederlandse Skolelinux vertaling Skolelinux België- http://i18n.skolelinux.no/belgium
pgpceunLurava.pgp
Description: PGP signature
Date: October 25, 2004
From: Andreas Tille <tillea@xxxxxx>
In-reply-to:
<200410252046.09107.cobaco@xxxxxxxxxxxxx>
References:
<200410252046.09107.cobaco@xxxxxxxxxxxxx>
On Mon, 25 Oct 2004, cobaco (aka Bart Cornelis) wrote:
[1] it's located in debian-edu cvs an alioth src/desktop-profiles module, current build of the package is available at http://developer.skolelinux.no/~cobaco/desktop-profiles
While I'm far from beeing a desktop configuration expert the stuff you described seems absolutely interesting for all CDDs. Keeping this in mind I wonder if we might include the stuff you mentioned completely into the cdd package.
Further steps needed at this point: 1) Get the package into Debian: -> packaging is done, but I need a sponser, as I'm not a DD
My suggestion would solve the problem of finding a sponsor. Just add your stuff to cdd svn and patch the packaging method. The uploaders of the cdd package will care for the upload. (Note: It is of course just a recommendation and you are free to decide. But I see no real need to have a lot of tiny little packages if they can be collected in one package for all CDDs.)
2) Once package gets into Debian change debian-edu-config to use it (add depends, remove custom xsession.d script, add debian-edu-config.listing file)
I hope that debian-edu will switch to cdd which (in case you accept my suggestion) will implicitely solves this.
3) Start discussing additional profiles/ current setup. What desktop customizations would you like to see (do speak up here ,we _need_ feedback, but drop debian-custom from CC when replying on this point :-)
I do not think that it would be too boring for people here.
I think we should have (at least): - debian-edu-network -> proxy settings, .. anything common to desktops inside a debian-edu network - debian-edu-student -> settings for students (background, desktop icons, panel setup, maybe some things locked down with kiosk framework, ...) - debian-edu-admin -> settings for admins (links to admin-tools and documentation on desktop, ....) - ....
This falls into the scope of user roles, IMHO.
Kind regards
Andreas.
Date: October 25, 2004
From: "cobaco (aka Bart Cornelis)" <cobaco@xxxxxxxxxxxxx>
Hi all,
the last while i've been working on a new package called desktop-profiles
[1]. As this is now in a state where I think it's ready to be used, it's
time to introduce this to the list and request some feedback :-), here
goes:
First some background:
KDE, and (most) other desktop environments allow you to use multi-level
configuration. Basically you have a number of different profiles
(config-sets) that you order by some mechanism (differs between desktops),
when looking for a config setting each of these config-sets will be looked
through, with the first set (remember they were ordered) that contains the
value providing it.
This of course is usefull for CDD's (and local admins) to provide
customizations to the desktop setup.
Currently there's no standard way of adding profiles and ordering them. This
will provide problems when, for instance, two CDD's installed on the same
PC both add profiles (say debian-edu-workstation + some debian-jr desktop
setup package on a kindergarten computer), as now you don't know what the
outcome will be.
This package provides a standard way to add profiles to desktop environments
(currently supported are KDE, GNOME [2], XFCE >=4.2, ROX, UDE, and
Freedesktop profiles). It works as follows:
- as in debian-edu there's a Xsession.d script that activates the profiles
(by setting KDEDIRS, CHOISEPATH, XDG_CONFIG_DIRS, ... whatever is
applicable for the respective profile-sort)
- the xsession.d script does this based on files dropped
into /etc/desktop-profiles.
- each of the (.listing) files dropped in /etc/desktop-profiles describes
one or more profiles (name, location, precedence-value, requirements for
activation, profile-kind, description).
- requirements that need to be met can take 1 of 3 forms:
1) <group> -> activated for members of <group>
2) !<group> -> activated for everybody not a member of <group>
3) $(command) -> the given shell command needs to exit succesfully
4) Each profile defines a list of requirements that need to be met for
activation (all given requirements need to be met)
- for further details (such as the format of files to-be-dropped
in /etc/desktop-profiles) see the manpage in the package
Anything I forgot in the approach described above?
[1] it's located in debian-edu cvs an alioth src/desktop-profiles module,
current build of the package is available at
http://developer.skolelinux.no/~cobaco/desktop-profiles
[2] GNOME needs a change to the system-wide path file to activate the
approach of this package, example path file is included, and installations
pops up a medium-priority question (defaulting to no) about wether to
replace the gconf path file if it's present.
NOTE: rest of this mail is stuff mostly applicable to debian-edu
Further steps needed at this point:
1) Get the package into Debian:
-> packaging is done, but I need a sponser, as I'm not a DD
2) Once package gets into Debian change debian-edu-config to use it (add
depends, remove custom xsession.d script, add debian-edu-config.listing
file)
3) Start discussing additional profiles/ current setup. What desktop
customizations would you like to see (do speak up here ,we _need_ feedback,
but drop debian-custom from CC when replying on this point :-)
I think we should have (at least):
- debian-edu-network -> proxy settings, .. anything common to desktops
inside a debian-edu network
- debian-edu-student -> settings for students (background, desktop icons,
panel setup, maybe some things locked down with kiosk framework, ...)
- debian-edu-admin -> settings for admins (links to admin-tools and
documentation on desktop, ....)
- ....
--
cobaco (aka Bart Cornelis):
Coördinator Belgisch Skolelinux team
Coördinator Nederlandse Skolelinux vertaling
Skolelinux België- http://i18n.skolelinux.no/belgium
pgpaoC3jeUeP3.pgp
Description: PGP signature
Date: October 25, 2004
From: Andreas Tille <tillea@xxxxxx>
In-reply-to:
<877jpmrcpk.fsf@xxxxxxxxx>
References:
<Pine.LNX.4.61.0410190708340.21423@wr-linux02
> <877jpmrcpk.fsf@xxxxxxxxx>
On Tue, 19 Oct 2004, Otavio Salvador wrote:
I think it is fixed now. Please, do a commit to test.
I did several commits yesterday, but got no mails ...
Kind regards
Andreas.
Date: October 24, 2004
From: Jose Carlos Garcia Sogo <jsogo@xxxxxxxxxx>
Sometimes you only need to ask for proper thing in the right moment :-) Original mail is: http://lists.debian.org/debian-gtk-gnome/2004/10/msg00159.html --------- Mensaje reenviado -------- > De: Gustavo Noronha Silva <kov@xxxxxxxxxx> > Para: debian-gtk-gnome@xxxxxxxxxxxxxxxx > Asunto: Re: Debblue, desktop-base and gnome-session changes > Fecha: Sun, 24 Oct 2004 11:44:57 -0300 > > Could you use a generic name in the conf (like gnome-debian-wallpaper > > or omething like that) and create a link to the real file using > > alternatives? This way any CCD could ship a package for configuring his > > own defaults which would only need to contain the images and use > > alternatives to set it, no need to poke with the configurations files. > > It already uses a generic name (/usr/share/desktop-base/default), but > I think the alternatives idea is very cool. > > Will do. > > Thanks, > > -- > kov@xxxxxxxxxx: Gustavo Noronha <http://people.debian.org/~kov> > Debian: <http://www.debian.org> * <http://www.debian-br.org> > > > -- Jose Carlos Garcia Sogo jsogo@xxxxxxxxxx
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Date: October 23, 2004
From: Enrico Zini <enrico@xxxxxxxxxxxxxx>
Hello, Debian based, I've read in the Debian-NP mailing list someone that said that it's directly apt-get upgradable into Debian proper. http://www.mepis.org/ Someone knows more? Is that people to make aware of CDD? Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@xxxxxxxxxx>
signature.asc
Description: Digital signature
Date: October 19, 2004
From: Andreas Tille <tillea@xxxxxx>
In-reply-to:
<20041019152028.GH2721@xxxxxxxxxxxx>
References:
<E1CCCm2-0002MW-00@xxxxxxxxxxxxxxxxxx> <2flhdpchyc0.fsf@xxxxxxxxxxxxxx> <2flmzyj4322.fsf@xxxxxxxxxxxxxx> <20041019152028.GH2721@xxxxxxxxxxxx>
On Tue, 19 Oct 2004, Alexander Schmehl wrote:
But if you decide to come to Frankfurt, you should't come between 10th to 16th of March, since I'll be busy these days with the Debian booth at the CeBIT.
BTW, if the choice will be Germany a date exactly before or after
CeBIT might make sense because some people would perhaps like to
drop in into this event.
Kind regards
Andreas.
Date: October 19, 2004
From: Alexander Schmehl <alexander@xxxxxxxxxxxx>
In-reply-to:
<2flmzyj4322.fsf@xxxxxxxxxxxxxx>
References:
<E1CCCm2-0002MW-00@xxxxxxxxxxxxxxxxxx> <2flhdpchyc0.fsf@xxxxxxxxxxxxxx> <2flmzyj4322.fsf@xxxxxxxxxxxxxx>
Moin! * Petter Reinholdtsen <pere@xxxxxxxxxx> [041019 08:47]: > I suspect we need to plan this well ahead, and propose March as the > gathering month. (January will probably have a debian-edu devcamp, so > I want to stay away from that month. :) [..] > University close to Frankfurt, Germany (contact Alexander Schmehl) March is a good choice, since there won't be any lectures in this month, this should make it a lot easier to get rooms in the University (which is BTW in Frankfurt, not close to). But if you decide to come to Frankfurt, you should't come between 10th to 16th of March, since I'll be busy these days with the Debian booth at the CeBIT. Yours sincerely, Alexander
signature.asc
Description: Digital signature
Date: October 19, 2004
From: Otavio Salvador <otavio@xxxxxxxxxx>
In-reply-to:
<Pine.LNX.4.61.0410190708340.21423@wr-linux02
> (Andreas Tille's message of "Tue, 19 Oct 2004 07:09:36 +0200 (CEST)")
References:
<Pine.LNX.4.61.0410190708340.21423@wr-linux02
>
|| On Tue, 19 Oct 2004 07:09:36 +0200 (CEST)
|| Andreas Tille <tillea@xxxxxx> wrote:
at> Hi,
at> does anybody know something about the status of svn on Alioth. The mails
at> for commits do not work until now.
I think it is fixed now. Please, do a commit to test.
--
O T A V I O S A L V A D O R
---------------------------------------------
E-mail: otavio@xxxxxxxxxx UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://www.freedom.ind.br/otavio
---------------------------------------------
"Microsoft gives you Windows ... Linux gives
you the whole house."
Date: October 19, 2004
From: "C. Gatzemeier" <c.gatzemeier@xxxxxxxx>
In-reply-to:
<20041019010752.GA2908@xxxxxxxxxxxxxx>
References:
<1097782647.26620.25.camel@xxxxxxxxxxxxxxxxxxxxx> <200410181901.53402.c.gatzemeier@xxxxxxxx> <20041019010752.GA2908@xxxxxxxxxxxxxx>
Am Tuesday 19 October 2004 03:07 schrieb Lluis: > Ok, first of all, sorry if my ideas are not correct, as i'm not sure how > exactly CFG or all the other config system tools work, but as i see it, the > problem resides on two main points, i think: > > - Programs must be modified to use the config system > - Users can't directly access config files without breaking config system's > coherence While this seems to be true for many config tools the discontent with this was part of why Config4Gnu (CFG) was started. The config files as used by the app can be accessed in any way and are the only authoritative source for settings. So there is not even a chance to misuse some different representation as a separate registry or so. Specificaly it is never assumed CFG has any authority to modify a confguration, only a user or admin (or scipt/installer run in behalf of them) can have it. CFG does have some information about the configuration a user or admin may like to use and benefit from, though. CFG knows about available options, defaults etc. in a config file from their meta-config definitions. If a config file is accessed directly nothing is broken. Next time the settings are queried from CFG settings might have changed to something other than the default, that was probably the intension though. If the setting isn't known by CFG (for example new CVS version of the app installed) the value is treated transparently as a string. Regards, Christian
Date: October 19, 2004
From: "Francesco P. Lovergine" <frankie@xxxxxxxxxx>
In-reply-to:
<Pine.LNX.4.61.0410190708340.21423@wr-linux02
>
References:
<Pine.LNX.4.61.0410190708340.21423@wr-linux02
>
On Tue, Oct 19, 2004 at 07:09:36AM +0200, Andreas Tille wrote: > Hi, > > does anybody know something about the status of svn on Alioth. The mails > for commits do not work until now. > Ask on #alioth on OFTC. Unfortunately alioth is periodically broken these days, until wiggy will upgrade to a definitive new box. -- Francesco P. Lovergine
Date: October 19, 2004
From: Andreas Tille <tillea@xxxxxx>
In-reply-to:
<2flmzyj4322.fsf@xxxxxxxxxxxxxx>
References:
<E1CCCm2-0002MW-00@xxxxxxxxxxxxxxxxxx> <2flhdpchyc0.fsf@xxxxxxxxxxxxxx> <2flmzyj4322.fsf@xxxxxxxxxxxxxx>
On Tue, 19 Oct 2004, Petter Reinholdtsen wrote:
We also need a statement on what we should work on at the devcamp.
I'd like to present the current cdd-dev tools and would love to discuss
this in detail.
I would also be willing to give a short introduction in how Debian-Web
pages are builded and internationalized. This would include a very quick
overview about the stuff Tobias Toedter has done for Debian-Med (for instance
easily viewable at
http://www.debian.org/devel/debian-med/microbio
where we have kind of a "traffic-light" symbolic of included packages,
packages in prepearation and not yet included software.
Kind regards
Andreas.
Date: October 19, 2004
From: Petter Reinholdtsen <pere@xxxxxxxxxx>
In-reply-to:
<2flhdpchyc0.fsf@xxxxxxxxxxxxxx> (Petter Reinholdtsen's message of "Sun, 03 Oct 2004 12:48:15 +0200")
References:
<E1CCCm2-0002MW-00@xxxxxxxxxxxxxxxxxx> <2flhdpchyc0.fsf@xxxxxxxxxxxxxx>
[Petter Reinholdtsen] > At the moment, 12 people reported their interest. At the deadline, 15 people had reported their interest. Can anyone calculate the center of mass for this group of people? Looking at the locations, I suspect Andreas is right that somewhere in UK close to Heathrow/Stansted is a good place to hold it, but have not ruled out the other locations. On the other hand, if we meet on the main land, more people can use train/car/bus to get there. Unless someone got good contacts in these areas, I'll try to contact the unix/linux user groups when I know the center of mass for the group. I suspect we need to plan this well ahead, and propose March as the gathering month. (January will probably have a debian-edu devcamp, so I want to stay away from that month. :) So, how do we proceed from here? We need a more detailed budget, estimating travel cost, accommodation and food. We also need a statement on what we should work on at the devcamp. This might make it easier to convince sponsors to fund it. Any volunteers for this? We need to find a location, and book it for the meeting, and everyone need to book holidays and tickets when the sponsoring is in place. Custom Debian Distro devcamp ============================ Interested in joining CDD devcamp. Petter Reinholdtsen Debian-Edu Oslo, Norway Otavio Salvador (will need assistant because of weelchair) Debian-NP, Debian-BR-CDD Porto Alegre, Brazil Andreas Tille Debian-Med Wernigerode (near Braunschweig/Hannover/Magdeburg), Germany Benjamin Mako Hill Debian-NP / Ubuntu New York City, USA Ben Armstrong Debian Jr. Halifax, NS, Canada Enrico Zini Debian-NP, Debtags (which is not a CDD) Bologna, Italy Alex de Landgraaf Morphix, Debian-NP (way back), Ubuntu, UserLinux (kind of) Amsterdam, the Netherlands Sergio Talens-Oliag LliureX Valencia, Spain Bart Cornelis Debian-Edu Sittard (near Maastricht), Belgia Goedson Paixao Debian-BR-CDD, Debian-NP, Debian-Jr Belo Horizonte, Brazil Micah Anderson Debian-NP Chicago, USA Marco Presi (Zufus) @d.o Debian-NP Pisa, Italy David Moreno Garza Debian Desktop Distribution Mexico City, Mexico Rob Taylor Debian Desktop Distribution London, England Blaine Cook Project: Debian-NP Vancouver, BC, Canada Proposed locations: Testzentrum in Gütersloh, Germany (contact Andreas Tille) ?, Italy (contact Marco Presi) University close to Frankfurt, Germany (contact Alexander Schmehl) Somewhere near camebridge (aka ryanair`s stansted airport) Possible sponsors: SLX Debian Labs (contact Petter Reinholdtsen) ? (contact Marco Presio) Mark Shuttleworth (contact Benjamin Mako Hill)
Date: October 19, 2004
From: Andreas Tille <tillea@xxxxxx>
Hi,
does anybody know something about the status of svn on Alioth. The mails
for commits do not work until now.
Kind regards
Andreas.
Date: October 19, 2004
From: Lluis <xscript@xxxxxxx>
In-reply-to:
<200410181901.53402.c.gatzemeier@xxxxxxxx>
References:
<1097782647.26620.25.camel@xxxxxxxxxxxxxxxxxxxxx> <20041017203806.GB878@xxxxxxxxxxxxxx> <20041018000153.GA23038@xxxxxxxxxxx> <200410181901.53402.c.gatzemeier@xxxxxxxx>
El 18/10/04, a les 19:01:53, C. Gatzemeier ens deleità amb les següents paraules: [...] > Multilevel config files would sure be nice, where the apps don't support them > it might be sufficient to provide only multilevel *defaults*. Multilevel as > application defaults, package defaults, system defaults (CDDs) and possibly > admin defaults. That should be possible with any type of app configuration. > Eeach level of authority could optionally provide a description of their > defaults that are processed by a configuration helper as CFG that is designed > to never interfere with user settings as described at > http://freedesktop.org/Software/CFG [...] Ok, first of all, sorry if my ideas are not correct, as i'm not sure how exactly CFG or all the other config system tools work, but as i see it, the problem resides on two main points, i think: - Programs must be modified to use the config system - Users can't directly access config files without breaking config system's coherence So looking at this two points, i see the need of a top level transparent interface... And here's my half of a cent: What if we build a new file system (in the idea of transparent external access from hurd translators: http://www.debian.org/ports/hurd/hurd-doc-translator) starting on /etc that "catches" all file operations and acts as a frontend to many possible config system backends? That is, if the package installs a new config file, we (the file system) catch that operation and instead take that new file and "translate" it to, for example, CFG (or a database system, or whatever)'s input. In that way, we catch any addition or manual edition, so there's no need on the program to change it's behaviour (and as reading can also be supervised by the fs, we give the program the data that the backend config system is storing). How to differentiate the package diversions from manual editions? As a concrete process is initiating the modifying operation, we can traverse the process hierarchy until we get a dpkg process (so we know it's a new file installation, and the package it belongs to), a dh_ script (on a possible debhelper modification operation, if any available - I don't know if there's such a thing) or init, bash, editor, or wathever we choose (so it's a manual edition then, with the possibility of knowing some data as the date, user, etc). I presented CFG as one of the possible backend options as it stores a hierarchized bunch of data, and we can deduce that hierarchy from the current system status (diversions, system/package "tunnings", manual editions), but I don't really know if, for example, it can work without the meta-config definition that the web page talks about. Well, I don't know if that's like killing flyies with cannons (sorry for my literal traduction ;)), or product from my own sick half-slept mind... it probably is the last option XD Sleep well! -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth -- To UNSUBSCRIBE, email to debian-custom-REQUEST@xxxxxxxxxxxxxxxx with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
Date: October 18, 2004
From: "C. Gatzemeier" <c.gatzemeier@xxxxxxxx>
In-reply-to:
<20041018000153.GA23038@xxxxxxxxxxx>
References:
<1097782647.26620.25.camel@xxxxxxxxxxxxxxxxxxxxx> <20041017203806.GB878@xxxxxxxxxxxxxx> <20041018000153.GA23038@xxxxxxxxxxx>
Am Monday 18 October 2004 02:01 schrieb Enrico Zini: > One problem with diversion could also be that the original package's > scripts won't probably edit the diverted conffile, but would probably > edit the file in the traditional place instead. Same would be the case for admins and users, and their scripts, tools and utilities, right? Having only one authoritative config place is probably less prone to confusion. > > I suspect the only sensible way to do this is to implement multilevel > > configuration files in all applications we want to configure at > > install time. Multilevel config files would sure be nice, where the apps don't support them it might be sufficient to provide only multilevel *defaults*. Multilevel as application defaults, package defaults, system defaults (CDDs) and possibly admin defaults. That should be possible with any type of app configuration. Eeach level of authority could optionally provide a description of their defaults that are processed by a configuration helper as CFG that is designed to never interfere with user settings as described at http://freedesktop.org/Software/CFG Quickly brainstorming this, customizing a running system to a template (a CDD) could be a two step process of copying in the meta info and then interactively or not "resetting" to the new defaults. In new installations the settings could automatically default to the customization if the meta data is present early enogh. Kind Regards, Christian
Date: October 18, 2004
From: Enrico Zini <enrico@xxxxxxxxxxxxxx>
In-reply-to:
<20041017203806.GB878@xxxxxxxxxxxxxx>
References:
<1097782647.26620.25.camel@xxxxxxxxxxxxxxxxxxxxx> <1097785958.4651.1.camel@localhost
> <20041016153852.GA5968@mitac
> <20041017203806.GB878@xxxxxxxxxxxxxx>
On Sun, Oct 17, 2004 at 10:38:06PM +0200, Petter Reinholdtsen wrote:
> [Enrico Zini]
> > One of the suggestions that came out is using dpkg diversions.
> > I remember diversions came out in the past, and I don't remember how
> > come they didn't come out again. Was there something wrong with them?
> I believe they are forbidden or don't work for conffiles. And we need
> to do this with conffiles.
From the dpkg-divert manpage:
"[...] System administrators can also use it to override some
package’s configuration file [...]"
In the policy, I find:
3.10. Maintainer Scripts
[...]
You should not use `dpkg-divert' on a file belonging to another
package without consulting the maintainer of that package first.
10.7.4. Sharing configuration files
[...]
Packages which specify the same file as a `conffile' must be tagged as
_conflicting_ with each other. (This is an instance of the general
rule about not sharing files. Note that neither alternatives nor
diversions are likely to be appropriate in this case; in particular,
`dpkg' does not handle diverted `conffile's well.)
[it also goes on about other ways of sharing configuration files]
One problem with diversion could also be that the original package's
scripts won't probably edit the diverted conffile, but would probably
edit the file in the traditional place instead. This may not be a
problem with many packages, though.
My dear debian-devel public: is this an unsolvable problem in Debian,
not even in the medium-long term?
> I suspect the only sensible way to do this is to implement multilevel
> configuration files in all applications we want to configure at
> install time.
Is that applicable to all the various kinds of conffiles we have, and
all possible customizations?
I'll make a recap of configuration customization techniques (to be
quoted and extended with pros, cons, dos, donts and gotchas):
- debconf preseeding
(can't de-install the customization)
- cfengine
(can't de-install the customization, problems during upgrades)
- dpkg-divert
(may not work for all packages)
(may be good for packages which don't automatically edit their
configuration)
- multilevel configuration files
(not all customizations are supported)
(may be good for packages with complex and useful updated
configuration)
The last two could complement each other and cover a wide range of
cases, allowing also upgrade and changing from one cdd to the other.
Ciao,
Enrico
--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@xxxxxxxxxx>
signature.asc
Description: Digital signature
Date: October 17, 2004
From: Petter Reinholdtsen <pere@xxxxxxxxxx>
In-reply-to:
<20041016153852.GA5968@mitac
>
References:
<1097782647.26620.25.camel@xxxxxxxxxxxxxxxxxxxxx> <1097785958.4651.1.camel@localhost
> <20041016153852.GA5968@mitac
>
[Enrico Zini] > One of the suggestions that came out is using dpkg diversions. > > I remember diversions came out in the past, and I don't remember how > come they didn't come out again. Was there something wrong with them? I believe they are forbidden or don't work for conffiles. And we need to do this with conffiles. I suspect the only sensible way to do this is to implement multilevel configuration files in all applications we want to configure at install time.
Date: October 17, 2004
From: Enrico Zini <enrico@xxxxxxxxxxxxxx>
In-reply-to:
<1097785958.4651.1.camel@localhost
>
References:
<1097782647.26620.25.camel@xxxxxxxxxxxxxxxxxxxxx> <1097785958.4651.1.camel@localhost
>
On Thu, Oct 14, 2004 at 10:32:38PM +0200, Jose Carlos Garcia Sogo wrote: > > I am working on creating a package for UserLinux which will configure > > several packages with sensible defaults for an authentication server. At > > the moment, that means samba, slapd, pam and nss, but will also include > > heimdal later on. > > My naive question is: is there currently any mechanism for forcing the > > user to configure package x from within package y, and/or for > > reconfiguring one package based on reconfiguring another? Current trends are centered on debconf preseeding and on installing cfengine scripts. I'm at the moment at a mini italian mini debconf, discussing with Marco d'Itri about this topic. One of the suggestions that came out is using dpkg diversions. I remember diversions came out in the past, and I don't remember how come they didn't come out again. Was there something wrong with them? Thinking about them now, they will allow a package to "take responsibility" for the configuratin of another, and give the other package back its configuration when the former one is deinstalled. This would allow to do things like removing a CDD and having back the original behaviour, it would allow sane upgrades, switching from one CDD to the other... The only problem I can see is if I install A, then B[diverts cfg of A], then I change by hand that configuration, then deinstall B: in that case, my changes won't be fed back in A's configuration. However, that problem is not even addressed by the other approaches, and I may not be a problem at all (that is, I don't know how sane would he having this feature at all). Another possibility would be to make a small change to dpkg to ask what it should do when undiverting configuration files that have been changed by the user. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@xxxxxxxxxx>
signature.asc
Description: Digital signature
Date: October 14, 2004
From: Jose Carlos Garcia Sogo <jsogo@xxxxxxxxxx>
In-reply-to:
<1097782647.26620.25.camel@xxxxxxxxxxxxxxxxxxxxx>
References:
<1097782647.26620.25.camel@xxxxxxxxxxxxxxxxxxxxx>
I think that you will find answers in debian-custom list. Adding it to CC field. El jue, 14-10-2004 a las 15:37 -0400, Mark Roach escribió: > I am working on creating a package for UserLinux which will configure > several packages with sensible defaults for an authentication server. At > the moment, that means samba, slapd, pam and nss, but will also include > heimdal later on. > > My naive question is: is there currently any mechanism for forcing the > user to configure package x from within package y, and/or for > reconfiguring one package based on reconfiguring another? > > > ## warning, verbosity follows ## > > Perhaps I'm just approaching this the wrong way, so here is what I am > doing (and where the problem comes in), and if anyone has a suggestion > for a better approach, I would be happy to hear it. > > userlinux-auth-server depends on slapd, samba, libpam-ldap, and libnss- > ldap. > > In the postinst, it gets the samba domain name, the dns domain name, and > the ldap master password out of debconf, and populates the necessary > entries. > > One problem is that the user may not necessarily have ever configured > samba or slapd through debconf. This package needs that info, but it's > not possible to dpkg-reconfigure a package from within the postinst of > another package. So we would have to tell them to manually dpkg- > reconfigure the dependancies and then reinstall, or gather the > information ourselves, but then there is potentially conflicting info in > debconf... > > Another similar problem is that the user may reconfigure samba-common or > slapd at any point and obviously my package wouldn't know about it. > > So, my conclusion is that debconf is not particularly well suited to > integrating several otherwise-unrelated packages and I am unsure whether > working around the problem, or helping to improve debconf, or doing it > some other way entirely is the better approach... thoughts? > > Thanks, > > Mark Roach > > -- Jose Carlos Garcia Sogo jsogo@xxxxxxxxxx
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Date: October 14, 2004
From: Andreas Tille <tillea@xxxxxx>
In-reply-to:
<5420.1097680184@xxxxxxxxxxxxx>
References:
<5420.1097680184@xxxxxxxxxxxxx>
On Wed, 13 Oct 2004, Lluis wrote:
Why cdd-dev does not create such files for? Is this a design decision or just... well, it's just not used :)
It's absolutely no decision - just a lack of knowledge from my side.
I don't really know how this works, but i've just thrown this advice to ask everybody if this is an interesting feature to use.
I think it would be useful.
Another option would be to create it and use it manually on the rules if you decide to use it ;)
Any reasonable patches are welcome
Andreas.
Date: October 14, 2004
From: Robert Millan <rmh@xxxxxxxxxx>
In-reply-to:
<20041008071435.GH5515@xxxxxxxxxxxxxxxx>
References:
<87u0tb4k69.fsf@xxxxxxxxxx> <20041004184328.GA37213@xxxxxxxxxxxxxxxxx> <20041008071435.GH5515@xxxxxxxxxxxxxxxx>
tags 261936 confirmed thanks On Fri, Oct 08, 2004 at 05:14:35PM +1000, Jason Thomas wrote: > this patch works for me! > > On Mon, Oct 04, 2004 at 08:43:28PM +0200, Robert Millan wrote: > > On Sun, Oct 03, 2004 at 10:32:30PM +0200, Free Ekanayaka wrote: > > > Hi, > > > > > > please would you accept the simple patch posted by Nathaniel. It would > > > be very useful for the Custom Debian Distributions, as it lets to set > > > the splash image in a very easy way. > > > > Jason: Free makes a good point, but you know update-grub much better than > > me. > > Any opinion on this? (bug #261936) -- .''`. Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S) : :' : `. `' http://www.debian.org/ports/kfreebsd-gnu `-
Date: October 13, 2004
From: "Lluis" <xscript@xxxxxxx>
I've been having a look on the New Maintainer's Guide and i've seen something about the doc-base for external help file formats (mainly HTML, PS and PDF). Why cdd-dev does not create such files for? Is this a design decision or just... well, it's just not used :) I don't really know how this works, but i've just thrown this advice to ask everybody if this is an interesting feature to use. Another option would be to create it and use it manually on the rules if you decide to use it ;) Read you, Lluis -- GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail +++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++
Date: October 11, 2004
From: Free Ekanayaka <free@xxxxxxxxxx>
In-reply-to:
<2flzn2t9hmz.fsf@xxxxxxxxxxxxxx> (Petter Reinholdtsen's message of "Mon, 11 Oct 2004 21:31:00 +0200")
References:
<878yadqzf9.fsf@xxxxxxxxxx> <20041011115342.GB24547@xxxxxxxxxxxxxx> <873c0lqvxr.fsf_-_@xxxxxxxxxx> <2flzn2t9hmz.fsf@xxxxxxxxxxxxxx>
|--==> Petter Reinholdtsen writes: PR> [Free Ekanayaka] >>Probably the right number would be 90, but it is currently used by >>localization-config. Actually I think that also localization-config >>should change its number, as the the keyboard layout should be >>injected in the debconf database *before* running xdebconfigurator, >>which runs dexconf. PR> I agree that xdebconfigurator should be executed after both pkgsel and PR> the debconf preloading part of localization-config. We could use '91' PR> to make sure it is after both. Any objections? PR> An alternative is to move localization-config earlier in the process. PR> Not sure how early it can be moved and still work. 91 it's fine for me. Cheers, Free
Date: October 11, 2004
From: Petter Reinholdtsen <pere@xxxxxxxxxx>
In-reply-to:
<873c0lqvxr.fsf_-_@xxxxxxxxxx> (Free Ekanayaka's message of "Mon, 11 Oct 2004 14:30:08 +0200")
References:
<878yadqzf9.fsf@xxxxxxxxxx> <20041011115342.GB24547@xxxxxxxxxxxxxx> <873c0lqvxr.fsf_-_@xxxxxxxxxx>
[Free Ekanayaka] > Probably the right number would be 90, but it is currently used by > localization-config. Actually I think that also localization-config > should change its number, as the the keyboard layout should be > injected in the debconf database *before* running xdebconfigurator, > which runs dexconf. I agree that xdebconfigurator should be executed after both pkgsel and the debconf preloading part of localization-config. We could use '91' to make sure it is after both. Any objections? An alternative is to move localization-config earlier in the process. Not sure how early it can be moved and still work.
Date: October 11, 2004
From: Free Ekanayaka <free@xxxxxxxxxx>
In-reply-to:
<20041011115342.GB24547@xxxxxxxxxxxxxx> (Petter Reinholdtsen's message of "Mon, 11 Oct 2004 13:53:42 +0200")
References:
<878yadqzf9.fsf@xxxxxxxxxx> <20041011115342.GB24547@xxxxxxxxxxxxxx>
Package: xdebconfigurator Version: 1.10 Severity: normal I think xdebconfigurator should be run *after* pkgsel. This way xdebconfigurator triggers itself if the xserver-common package (which contains dexconf) was installed, and does nothing otherwise. Probably the right number would be 90, but it is currently used by localization-config. Actually I think that also localization-config should change its number, as the the keyboard layout should be injected in the debconf database *before* running xdebconfigurator, which runs dexconf. Cheers, Free
Date: October 11, 2004
From: Petter Reinholdtsen <pere@xxxxxxxxxx>
In-reply-to:
<878yadqzf9.fsf@xxxxxxxxxx>
References:
<878yadqzf9.fsf@xxxxxxxxxx>
[Free Ekanayaka] > currently xdebconfigurator base-config menu item has number 76, while > pkgsel has 80. Is there any particular reason for running > xdebconfigurator *before* tasksel? Nope. The number was selected for woody, and just copied to sarge. Should we change it to another number? > Running it running it *after* would make it trigger itself basing on > the user choice (with or without X). Fine with me. Submit a bug request to BTS asking for the number to be changed, and include a proposal for a new number. This should make sure we don't forget it. -- To UNSUBSCRIBE, email to debian-edu-REQUEST@xxxxxxxxxxxxxxxx with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
Date: October 11, 2004
From: Free Ekanayaka <free@xxxxxxxxxx>
Hi, currently xdebconfigurator base-config menu item has number 76, while pkgsel has 80. Is there any particular reason for running xdebconfigurator *before* tasksel? Running it running it *after* would make it trigger itself basing on the user choice (with or without X). Cheers, Free
Date: October 11, 2004
From: Free Ekanayaka <free78@xxxxxx>
In-reply-to:
<Pine.LNX.4.61.0410110729450.15793@wr-linux02
> (Andreas Tille's message of "Mon, 11 Oct 2004 07:38:59 +0200 (CEST)")
References:
<87wty27num.fsf@xxxxxx> <Pine.LNX.4.61.0410071410410.10082@wr-linux02
> <87sm8on8it.fsf@xxxxxx> <Pine.LNX.4.61.0410090748150.18603@wr-linux02
> <1097352946.17143.32.camel@xxxxxxxxxxxxxxxxx> <Pine.LNX.4.61.0410101647370.4395@wr-linux02
> <87hdp2b8y7.fsf@xxxxxx> <Pine.LNX.4.61.0410110729450.15793@wr-linux02
>
|--==> Andreas Tille writes:
AT> On Sun, 10 Oct 2004, Free Ekanayaka wrote:
AT> I do not want to force anybody who is maintaining free software and I do
AT> not want to. But I obviousely did a wrong statement in the docs (which
AT> (... please read here ...
AT> I do not want to force anybody who is maintaining free software and I'm
not
AT> able to do so.)
>>Well, when I wrote about those 30 derivative distros, I did mean that
^^^^^^^^^^^
Errata corrige: I did *not* mean! (Freudian lapsus?)
>>I expect all of them to put their sources on Alioth or integrate with
>>Debian.
AT> Ben clarified this to me...
>>It was just an example to show that keeping all present and
>>future CDDs in the same project can eventually be problematic, given
>>the number.
AT> ... and I think that most of them are not really potential CDDs
Maybe not *them* as they are *now*, but similar projects which are
starting to bloom inside the Debian community on in the neighbourhood.
>>I was just wandering if we should have some guidelines for at least
>>*our* projects, as CDD mailing list members and Debian insiders.
AT> Yes, guidelines was definitely the thing I was wondering about.
>>Yes, having a common place *does* help, but I think this can be
>>accomplished by having different Alioth projects rooted in the same
>>directory. This assures both visibility and independence.
AT> May be it is just a lack of knowledge on my side about alioth projects.
AT> If it is possible to root different projects in one tree this is exactly
AT> what I intended. If it is not possible to build such projects under the
AT> cdd/projects root (which was originally the idea of Otavio and me when we
AT> created this tree) but it is possible in an other way I would move
AT> Debian-Med (and I guess Ben would do so with Debian-Junior as well) to
AT> the other common place.
By "rooted in the same directory" I mean a new directory in the
Project Tree [0].. Imagine the entry "Customising" just below
"Packaging" in this page:
http://alioth.debian.org/softwaremap/trove_list.php?form_cat=273
and CDD that need their own Alioth project listed in this directory.
>>IMO the great challenge for Debian is how to let even commercial
>>derived distribution to be as much as possible regular CDD. That would
>>be great source of man power and quality assurance, and everybody
>>would benefit it. My understanding is that this what the UserLinux [0]
>>project is all about.
AT> Sure. But IMHO they (which means UserLinux and others) have to declare
AT> their interest to do so and their requirements (like creating projects
AT> on alioth or whatever) first before we can do anything for them.
I think that once tools are in place and we as CDD pioneers exit the
experimental phase, then more will join.
Cheers,
Free
[0] http://alioth.debian.org/softwaremap/trove_list.php
Date: October 11, 2004
From: Andreas Tille <tillea@xxxxxx>
In-reply-to:
<1097459375.10825.64.camel@xxxxxxxxxxxxxxxxxxxx>
References:
<87wty27num.fsf@xxxxxx> <Pine.LNX.4.61.0410071410410.10082@wr-linux02
> <87sm8on8it.fsf@xxxxxx> <Pine.LNX.4.61.0410090748150.18603@wr-linux02
> <1097352946.17143.32.camel@xxxxxxxxxxxxxxxxx> <Pine.LNX.4.61.0410101647370.4395@wr-linux02
> <87hdp2b8y7.fsf@xxxxxx> <1097459375.10825.64.camel@xxxxxxxxxxxxxxxxxxxx>
On Sun, 10 Oct 2004, Matthew P McGuire wrote:
Finally, we solve the single point of reference by using a site name like cdd.debian.org or www.debian.org/cdd/.
I think the later one would be great and I have proposed this several times
(and thought I would have documented this in the docs, but obviousely forgot
this in chapter
http://people.debian.org/~tille/cdd/ch-todo.en.html#s-webpages
which at least asks for common layout for the pages and the wml templates.)
This site could contain a brief description of the CDD concept, the current goals, a link to Andreas' paper, and an official list of CDD projects. This list can also contain a link to the current website of a given CDD.
Definitely. Any volunteer?
Who does the work? I wouldn't mind it, and I am sure there are already numerous others who would help maintain the site. However I think they would all need to debian maintainers, so list-lurkers like me are probably not an option. (Hell I'm not even in the NM queue.)
It is not necessary to be a developer to work on the web pages. There are many people with CVS acces to the wml pages who do not even think about becoming a maintainer. (http://www.debian.org/devel/website/)
By the way, Andreas, Ben, Free, and everyone else involved is making great progress in this project. So much so that I find it very hard to follow at times. But thanks for working so hard on it. I have learned volumes from these dialogs and I really appreciate it.
Thanks for your good summary
Andreas.
Date: October 11, 2004
From: Andreas Tille <tillea@xxxxxx>
In-reply-to:
<87hdp2b8y7.fsf@xxxxxx>
References:
<87wty27num.fsf@xxxxxx> <Pine.LNX.4.61.0410071410410.10082@wr-linux02
> <87sm8on8it.fsf@xxxxxx> <Pine.LNX.4.61.0410090748150.18603@wr-linux02
> <1097352946.17143.32.camel@xxxxxxxxxxxxxxxxx> <Pine.LNX.4.61.0410101647370.4395@wr-linux02
> <87hdp2b8y7.fsf@xxxxxx>
On Sun, 10 Oct 2004, Free Ekanayaka wrote:
AT> I do not want to force anybody who is maintaining free software and I do AT> not want to. But I obviousely did a wrong statement in the docs (which
(... please read here ... I do not want to force anybody who is maintaining free software and I'm not able to do so.)
Well, when I wrote about those 30 derivative distros, I did mean that I expect all of them to put their sources on Alioth or integrate with Debian.
Ben clarified this to me...
It was just an example to show that keeping all present and future CDDs in the same project can eventually be problematic, given the number.
..