Re: More advanced home directory creation in Debian?
On 2010-09-10, Jerome Warnier wrote: > On Sun, 2010-08-22 at 19:00 -0300, Fernando Lemos wrote: >> On Sun, Aug 22, 2010 at 6:40 PM, Christoph Anton Mitterer >> wrote: >> > You're aware that not only .bash_* and .profile can be distributed >> > by /etc/skel,... but any other config file (e.g. .vimrc) a specific site >> > or organisation may found useful for their users? >> > Or a predefined directory structure,... ssh config perhaps specific for >> > each user? >> /etc/skel is used to populate user home directories on user creation, >> nothing more. For system-wide settings , use /etc (e.g. >> /etc/vim/vimrc.local). Use site-specific scripts for any more >> convoluted needs you might have. There's nothing to be discussed about >> this, really. > Think about places where the home is on a server, while /etc is on local > workstations. > You need to extend your vision. I don't think it's sensible to rely on changes in /etc/skel to be propagated somewhen to /home at user creation time for any sane organization-wide configuration setting. One tries to distribute configuration files to /etc on all machines organization-wide to get a similar configuration. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrni8n0bb.8ni.tr...@kelgar.0x539.de
Re: License of a patch
Christian Kastner writes: > On 08/30/2010 09:06 PM, D M German wrote: >> >> After my presentation at DebConf this year I was pointed to your efforts >> on the Patch Tagging Guidelines. >> >> One thing I believe would be useful is if the patch included a >> license. The simplest license would be "Same as patched code" but it >> will clarify it. > > Wouldn't this be redundant to debian/copyright, where the licensing > terms should be present anyway? > > Also, if debian/copyright were in DEP5 format (and properly maintained), > one should be able to deduce the full licensing terms for any given > patch from it automatically. > > Regards, > Christian I think the most benefit of having it IN the patch is for sending said patch upstream or when others use the patch outside the debian package. Esspecially if the patch isn't written by the maintainer but forwarded by him. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq2curr8@frosties.localdomain
Re: Valid-Until and snapshot or archives
Klaus Ethgen writes:
> Hi,
>
> I recently found myself with the problem that I have tu use one source
> from snapshot.debian.org (fuse as it is broken in sid) and the
> Valid-Until time setting in the release file and apt revoking to use
> that one.
>
> Generally I think the Valid-Until is a good think so I do not want to
> switch it of globally (Acquire::Check-Valid-Until) but for this
> particular source only. However, this might be a solution for me (well
> there is no way at the moment if I see correct), this shows a more
> general problem.
>
> So the question is how to handle that Valid-Until header in archive
> release files? Should Archives remove them (then that is a bug of
> snapshot.debian.org) or should there be a switch in apt config to
> disable it for one particular source URL?
>
> Regards
>Klaus Ethgen
If an archive puts a Valid-Until header in then it better update that
frequently.
Aside from that there now (since 0.8) is a general way to add support
for enabling/disabling this on a per source basis. The sources.list file
now has an option field. What was previously called Vendor field and has
been supported but unused for many years.
deb [key1=value key2=value1,value2 ...] url suite component
deb [key1=value key2=value1,value2 ...] url path/
deb-src [key1=value key2=value1,value2 ...] url suite component
deb-src [key1=value key2=value1,value2 ...] url path/
Currently there is only one key that is supported: arch. E.g.:
deb [arch=armel] http://ftp.de.debian.org/debian sid main
and Apt::Architectures={"amd64";"armel"; }; results in apt-get update
fetching:
Hit http://ftp.de.debian.org sid/main armel Packages
The support for the key/value option is kept general and will parse
anything you put in there and attach it as dictionary to the source. So
all you need to do is pick a "key" and "value"s for it and then look at
the code that does the Valid-Until check and add a little code there
that checks if the source has your "key" and then behave according to
the "value" assigned. That should not be too hard to patch in.
It might be nice to allow more than just disabling the feature for a
source. You could support that one can also set the time limit for a
source even if the source has no entry or to override it. E.g.:
valid-until=always - Ignore the valid-until entry
valid-until=active - Honor the valid-until entry
valid-until=24h - Assume Release file is valid for 24h (from
Date entry or timestamp in signature)
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87eid0uqqi@frosties.localdomain
Re: Is a bug RC relevant if it has an influence on the health of a person
Karsten Hilbert writes: > On Thu, Sep 09, 2010 at 12:38:05PM +0200, Michael Tautschnig wrote: > >> >Here comes the bug: GNUmed will, given appropriate >> >circumstances, OVERWRITE the first allergy against Sugar. > > ... > >> > You die in hospital because of a second anaphylactic >> > reaction to Sugar. > >> [...] >> >> Although I do see the point of "harms people" missing in the description of >> severities, *all* RC-level severities already seem to apply, given the above >> description (quoting [1]): >> >> - critical: "... or causes serious data loss, ..." (although internal to >> GNUmed, >> it does cause loss of a patient's data) >> - grave: "makes the package in question unusable or mostly so, ..." (given >> the >> above description, it shall better not be used by any medic) >> - serious: "... or, in the package maintainer's or release manager's >> opinion, makes >> the package unsuitable for release." (the easiest one: paste Karsten's >> description into a bug report and you're done) > > Filed a bug: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596219 > > but reportbug did not let me specify either of RC / critical > / grave / serious / security ... > > Karsten Because you are a reportbug novice. Novices are not allowed to play with severity of bugs. :) You can reconfigure reportbug (reportbug --configure) and tell it you are now more experienced with reporting bugs and Debian so it enables some of the more advanced options. Or, for a one time thing, reportbug --mode=standard, advanced or expert. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aanouq9x@frosties.localdomain
Bug#596458: ITP: pd-arraysize -- a Pd object to report the size of an array
Package: wnpp Severity: wishlist Owner: "Hans-Christoph Steiner" * Package name: pd-arraysize Version : 0.1 Upstream Author : Juha Vehvilainen * URL : http://puredata.info/ * License : "This code is too trivial to have a license or copyright" Programming Lang: C Description : a Pd object to report the size of an array This provides a simple object for Pure Data that reports the size of an array by name. For historical reasons, it is packaged as a standalone object. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100911175357.31731.55323.report...@blinky.at.or.at
Bug#596460: ITP: pd-beatpipe -- a realtime scheduler/event-delay/quantizer object for Pd
Package: wnpp Severity: wishlist Owner: "Hans-Christoph Steiner" * Package name: pd-beatpipe Version : 0.1 Upstream Author : Gerard van Dongen * URL : http://puredata.info * License : GPL-2+ Programming Lang: C Description : a realtime scheduler/event-delay/quantizer object for Pd This object is a realtime scheduler, event-delay, and quantizer object for Pure Data. It is used for making beats and other rhythmic sequences. Any list starting with a number T sent to the left inlet, will be sent to the output after T beats, quantized with tpq (tick per quarter) and stripped of the leading beat number. The tempo can be changed dynamically on the right inlet The quantification can be set at any time with a set-tpq message. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100911175657.31836.80511.report...@blinky.at.or.at
Bug#596461: ITP: pd-plugin -- LADSPA and VST plug-in hosting for Pd
Package: wnpp Severity: wishlist Owner: "Hans-Christoph Steiner" * Package name: pd-plugin Version : 0.2.1 Upstream Author : Jarno Seppanen * URL : http://puredata.info * License : GPL-2+ Programming Lang: C Description : LADSPA and VST plug-in hosting for Pd This is a Pd tilde object for hosting LADSPA audio plug-ins. The LADSPA plug-in interface is supported completely. The object will search your LADSPA path for plugins, which are loadable by name as an argument to the plugin~ object. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100911180254.31924.55453.report...@blinky.at.or.at
