Re: Debian based GNU/Solaris: pilot program
* Henning Makholm: > Scripsit Florian Weimer <[EMAIL PROTECTED]> > >> The GPL does fail the Dissident test because it does not permit >> anonymous changes. > > Your copy of the GPL must have been garbled in transmission. > Please fetch a fresh copy from a trusted source. What is a trusted source? The copy shipped by Debian contains the following requirement: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. (We should move this discussion to -legal, or stop it right here. It's not very productive.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing-watch emails
On Sat, 2005-11-05 at 00:17 +0100, Henning Makholm wrote:
> Scripsit Steve Langasek <[EMAIL PROTECTED]>
>
> > If you're interested in making this happen I'll be happy to give
> > you any info I can;
>
> OK, here are some questions.
>
> 1) The copy of britney in merkel:/org/ftp.debian.org/ does not seem
> to be synced regularly. Is there a place where one can see the
> current code? It's not in the dak cvs (which appears to be
> out-of-date wrt the merkel mirror anyway), and I tried poking
> around on {cvs,svn,arch}.debian.org to no avail.
http://ftp-master.debian.org/testing/update_out_code/ is the "official"
current code, afaik. From time to time, there may be other versions
floating around - there's a least one in ~ajt on ftp-master currently.
> 3) Do you (or somebody in QA who reads this) happen to know how the
> 'keyword' under which the PTS forwards emails is transmitted? I
> cannot find any code in katie that sets this. Does the PTS analyse
> subject lines for fixed patterns?
[EMAIL PROTECTED] is subscribed to -devel-changes and processes
the mails in real-time.
http://cvs.debian.org/pts/?cvsroot=qa is useful here.
http://wiki.debian.org/qa.debian.org/pts is linked from the front page
of p.qa.d.o, and contains a link to a presentation Raphael Hertzog
(buxy) made about the PTS.
> (Currently I'm extrapolating from the documented
> [EMAIL PROTECTED] syntax, but I'm not sure
> that is the Right Thing to do).
>
> I'm not sure this is the right list to ask on, what with this being
> technical matters rather than a flamewar. :-) Feel free to move to
> somewhere appropriate, cc'ing me.
In terms of the PTS, either asking buxy directly or [EMAIL PROTECTED] usually
works. britney and other ftp-master related topics are probably most
appropriate on [EMAIL PROTECTED], imho.
Adam
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: [Mass bug filing] Native vs. non-native packages consistency
Hi Steve, >> Feel free to point me to false positives, as I haven't checked every >> single one of them. I know that some of them already have respective >> bugs filed against them. > > Indeed, at least some of these *are* false positives; there is nothing > that prohibits the use of dashes in native version numbers [...] Right, thanks for pointing that out. The Debian native package state and Debian revisions are currently not directly connected. However, there were discussions[1] in the past about enforcing that. Some DDs backed it while one (major;) other described his personal packaging style as not suitable for that. However, his argument that katie already detects when packages are alternately uploaded "native" and "non-native" is not valid, since it doesn't/didn't work, see rscheme and queue (just 2 random packages from "the list"). > [...] so I don't really think it's appropriate to mass-file bugs > against packages which appear to be missing .diff.gz's until they've > been verified individually. Of course, I wouldn't just script 300+ bug openings automatically but work on them individually. A general criterion for opening a bug would be that there is a suitable upstream package/tarball available that would be suitable as for the general orig.tar.gz case, and/or that the package was non-native before and one of the last uploads turned it to native by missing the orig.tar.gz. Right? > However, noting that you've managed to tag large > numbers of core kernel packages as false-positives I was well aware that the list includes some holy cows. ;-) Therefore, I asked first. (Well, would have done that anyway.) However, I consider most kernel packages you listed as legacy Debian kernel packaging style. bye, Roland [1] http://lists.debian.org/debian-policy/2001/02/msg00140.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian based GNU/Solaris: pilot program
Scripsit Florian Weimer <[EMAIL PROTECTED]> > * Henning Makholm: >> Scripsit Florian Weimer <[EMAIL PROTECTED]> >>> The GPL does fail the Dissident test because it does not permit >>> anonymous changes. >> Your copy of the GPL must have been garbled in transmission. >> Please fetch a fresh copy from a trusted source. > The copy shipped by Debian contains the following requirement: > a) You must cause the modified files to carry prominent notices > stating that you changed the files and the date of any change. You can satisfy this by adding a comment at the top: /* SEE HERE > I changed this file on November 5th, 2005 */ There is no requirement at all that you divulge who "I" is. The meaning of the clause is simply that the recipient must be alerted that the file _has_ been changed. > (We should move this discussion to -legal, or stop it right here. > It's not very productive.) Feel free to move it; I subscribe to -legal too. The discussion is highly relevant, because licenses that do require that a contributor identifies himself posivtively are _not_ free. -- Henning Makholm "Larry wants to replicate all the time ... ah, no, all I meant was that he likes to have a bang everywhere." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: [Mass bug filing] Native vs. non-native packages consistency
On Sat, Nov 05, 2005 at 12:32:18PM +0100, Roland Stigge wrote: > >> Feel free to point me to false positives, as I haven't checked every > >> single one of them. I know that some of them already have respective > >> bugs filed against them. > > Indeed, at least some of these *are* false positives; there is nothing > > that prohibits the use of dashes in native version numbers [...] > Right, thanks for pointing that out. The Debian native package state and > Debian revisions are currently not directly connected. However, there > were discussions[1] in the past about enforcing that. Right, well, see the other thread (somewhere? here?) about NMU version numbers for native packages for why I think that would be a bad idea. :) > > [...] so I don't really think it's appropriate to mass-file bugs > > against packages which appear to be missing .diff.gz's until they've > > been verified individually. > Of course, I wouldn't just script 300+ bug openings automatically but > work on them individually. > A general criterion for opening a bug would be that there is a suitable > upstream package/tarball available that would be suitable as for the > general orig.tar.gz case, and/or that the package was non-native before > and one of the last uploads turned it to native by missing the orig.tar.gz. > Right? Yes, that sounds like an appropriate filter. > > However, noting that you've managed to tag large > > numbers of core kernel packages as false-positives > I was well aware that the list includes some holy cows. ;-) Therefore, I > asked first. (Well, would have done that anyway.) > However, I consider most kernel packages you listed as legacy Debian > kernel packaging style. That's fine, but there's nothing "legacy" about the principle that a native package's version number may need dashes. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Debian based GNU/Solaris: pilot program
Henning Makholm <[EMAIL PROTECTED]> wrote: > Feel free to move it; I subscribe to -legal too. The discussion is > highly relevant, because licenses that do require that a contributor > identifies himself posivtively are _not_ free. This is, of course, a definition of "free" that's specific to some sections of Debian. It doesn't match the FSF's definition of "free" terribly well. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337646: ITP: cl-arnesi -- small Common Lisp utilities
Package: wnpp Severity: wishlist * Package name: cl-arnesi Version : 1:20051105-1 Upstream Author : Edward Marco Baringer <[EMAIL PROTECTED]> * URL or Web page : http://common-lisp.net/project/bese/arnesi.html * License : BSD Description : small Common Lisp utilities arnesi is a Common Lisp utility suite. It contains various "bits 'n pieces" of code. . Features: * Flow control macros - while, whichever, if-bind, etc. * A simple logging facility - kind-of/sort-of/maybe like log4j. * HTTP/HTML utilities - URL and HTML escaping * Pattern matching - fare-matcher style pattern matcher and "regular" list matcher * Accumulation - collecting and reducing macros * Cps transformer - an ad-hoc, bug ridden implementation of half of call/cc. * Decimal arithmetic - convert floats to exact rationals and vice versa with a given precision; standard rounding functions. * MOP compatibility package - The MOPP package provides the MOP's symbols on various implementations. Currently OpenMCL, CMUCL, SBCL, Lispworks and CLISP are supported. . The recommended packages add extra features: documentation via cl-qbook, test suite with cl-fiveam and add-ons for cl-ppcre. . This is the development version. = This is the first of a series of ITPs for Common Lisp software that is necessary as dependency for UCW [1]. As soon as this bug will get a number by the BTS, I'll add the package to the CL-Debian repository [2]. The package is linda and lintian free and it follows the "Common Lisp in Debian Manual" [3]. Thx, bye, Gismo / Luca [1] http://common-lisp.net/project/ucw/ [2] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi [3] http://cl-debian.alioth.debian.org/clid/clid.html/ pgpNpXzGK1ASa.pgp Description: PGP signature
Re: Debian based GNU/Solaris: pilot program
On Sat, Nov 05, 2005 at 01:17:18PM +0100, Henning Makholm wrote: > > (We should move this discussion to -legal, or stop it right here. > > It's not very productive.) You can start CC'ing the conversation to -legal. Moving threads, in my experience, generally doesn't work; besides, -devel can handle the noise. > Feel free to move it; I subscribe to -legal too. The discussion is > highly relevant, because licenses that do require that a contributor > identifies himself posivtively are _not_ free. It may be more productive to simply point him at one of the other seven or ten times someone has claimed this, and received the same response, and not waste time rehashing this again unless there's something new to add. :) http://lists.debian.org/debian-legal/2005/01/msg00826.html http://lists.debian.org/debian-legal/2005/06/msg00242.html were easy to find, at least. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337652: ITP: libzorpll3.0.6 -- Low level library functions for Zorp
Package: wnpp Severity: wishlist Owner: SZALAY Attila <[EMAIL PROTECTED]> * Package name: libzorpll3.0.6 Version : 3.0.6.2 Upstream Author : Scheidler Balázs <[EMAIL PROTECTED]> * URL : http://www.balabit.hu/downloads/zorp/libzorpll-src/ * License : GNU/GPL + permission to use OpenSSL Description : Low level library functions for Zorp Zorp is a new generation firewall. It is essentially a transparent proxy firewall, with strict protocol analyzing proxies, a modular architecture, and fine-grained control over the mediated traffic. Configuration decisions are scriptable with the Python based configuration language. . This package contains low level library functions needed by Zorp and associated programs. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.18 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Bug#337654: ITP: libevt0 -- Syslog event logger library
Package: wnpp Severity: wishlist Owner: SZALAY Attila <[EMAIL PROTECTED]> * Package name: libevtlog0 Version : 0.2.3+20051031 Upstream Author : Scheidler Balazs <[EMAIL PROTECTED]> * URL : http://www.balabit.hu/downloads/syslog-ng/1.9/src/ * License : BSD Description : Syslog event logger library The EventLog library aims to be a replacement of the simple syslog() API provided on UNIX systems. The major difference between EventLog and syslog is that EventLog tries to add structure to messages. . EventLog provides an interface to build, format and output an event record. The exact format and output method can be customized by the administrator via a configuration file. . This package is the runtime part of the library. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.18 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337657: ITP: cl-fiveam -- simple regression testing framework
Package: wnpp Severity: wishlist * Package name: cl-fiveam Version : 1:20051105-1 Upstream Author : Edward Marco Baringer <[EMAIL PROTECTED]> * URL or Web page : http://common-lisp.net/project/bese/FiveAM.html * License : BSD Description : simple regression testing framework FiveAM is a simple (as far as writing and running tests goes) regression testing framework. It has been designed with Common Lisp's interactive development model in mind. . Features: * Test and test suite hierarchies allow test to be organized into hierarchies to ease running * Functions for re-running recently run tests. * Inter-test dependencies. . The documentation is provided via the cl-qbook package. = Continuation of the series of CL software started with bug #337646. As soon as this bug will get a number by the BTS, I'll add the package to the CL-Debian repository [1]. The package is linda and lintian free and it follows the "Common Lisp in Debian Manual" [2]. Thx, bye, Gismo / Luca [1] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi [2] http://cl-debian.alioth.debian.org/clid/clid.html/ pgphOxf3h7t0f.pgp Description: PGP signature
Bug#337662: ITP: cl-yaclml -- Yet Another Common Lisp Markup Language
Package: wnpp Severity: wishlist * Package name: cl-yaclml Version : 1:20051105-1 Upstream Author : Edward Marco Baringer <[EMAIL PROTECTED]> * URL or Web page : http://common-lisp.net/project/bese/yaclml.html * License : BSD Description : Yet Another Common Lisp Markup Language YACLML is a collection of macros and utilities for generating XML/HTML like markup from lisp code. . Features: * Constant folds as much as possible. * Macros for generating HTML from within lisp code. * Templating system for generating HTML from designer templates. . The recommended packages add documentation via cl-qbook or a test suite with cl-fiveam. = Continuation of the series of CL software started with bug #337646. As soon as this bug will get a number by the BTS, I'll add the package to the CL-Debian repository [1]. The package is linda and lintian free and it follows the "Common Lisp in Debian Manual" [2]. Thx, bye, Gismo / Luca [1] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi [2] http://cl-debian.alioth.debian.org/clid/clid.html/ pgperXExUzCx8.pgp Description: PGP signature
Bug#337666: ITP: cl-qbook -- create HTML/LaTeX versions of Common Lisp source code
Package: wnpp Severity: wishlist * Package name: cl-qbook Version : 1:20051105-1 Upstream Author : Edward Marco Baringer <[EMAIL PROTECTED]> * URL or Web page : http://common-lisp.net/project/bese/qbook.html * License : BSD Description : create HTML/LaTeX versions of Common Lisp source code qbook is a Common Lisp tool to create HTML/LaTeX versions of source code. . Features: * Very simple (easy to learn and use). * It can produce HTML or LaTeX. = Continuation of the series of CL software started with bug #337646. As soon as this bug will get a number by the BTS, I'll add the package to the CL-Debian repository [1]. The package is linda and lintian free and it follows the "Common Lisp in Debian Manual" [2]. Thx, bye, Gismo / Luca [1] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi [2] http://cl-debian.alioth.debian.org/clid/clid.html/ pgpQSiwLB9YMT.pgp Description: PGP signature
Help: molphy testing migration (fwd)
Hi, is anybody out there who is able to help compiling molphy for the architectures mentioned below. Thank you very much Andreas. -- http://fam-tille.de -- Forwarded message -- Date: Sat, 05 Nov 2005 18:36:43 +0100 From: Luk Claes <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: molphy testing migration Hi Can you (ask for) upload molphy for ia64, m68k and s390 or ask for removal of the old binaries so molphy can migrate to testing? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Are pure virtual Depends/Recommends entries bugs?
On Mon, Oct 31, 2005 at 10:55:18PM -0500, Daniel Burrows <[EMAIL PROTECTED]> was heard to say: > As I'm sure everyone knows, pure virtual entries in a Depends line are > strongly deprecated, due to the fact that frontends have a tendency to pick > a random provider of the package. What I'm not sure is if this is just "ugly" > or actually considered a bug. In particular, I can't remember and would like > to know: > > (a) Is a pure virtual entry with no prior alternative in a Depends line an > actual bug? i.e., do we have a consensus on this? > > (b) If the answer to (a) is "yes", is a pure virtual *Recommendation* a bug? > > Rationale: Recommendations are intended to be installed by default, so > their fields should be just as friendly to automatic tools as Depends > is. So can I take it that the answer to my question is "there is no such policy"? Daniel signature.asc Description: Digital signature
Re: Are pure virtual Depends/Recommends entries bugs?
On Mon, Oct 31, 2005 at 10:55:18PM -0500, Daniel Burrows wrote: > (a) Is a pure virtual entry with no prior alternative in a Depends line an > actual bug? i.e., do we have a consensus on this? This will prevent the package from autobuilding, which is a bug. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing-watch emails
Scripsit "Adam D. Barratt" <[EMAIL PROTECTED]> > On Sat, 2005-11-05 at 00:17 +0100, Henning Makholm wrote: [Context for debian-dak readers who are not following the thread in -devel: I am trying to get up to speed on how to contribute some code to ftp-master that mails out testing migration notices.] >> 1) The copy of britney in merkel:/org/ftp.debian.org/ does not seem >> to be synced regularly. Is there a place where one can see the >> current code? > http://ftp-master.debian.org/testing/update_out_code/ is the "official" > current code, afaik. I didn't know that URL; thanks. Unfortunately it not exactly what I looked for; it corresponds to merkel:/org/ftp.debian.org/testing/update_out/*, whereas I think that the place I need to hook in is the shell script merkel:/org/ftp.debian.org/testing/britney in the parent directory. The sarge-is-frozen announcement [1] seemed to imply that these things were all under version control, but I may read that wrongly. Upon further investigation it looks like the freezing would actually be effeceted by adding a hint rather than commiting a change to the code. [1] http://lists.debian.org/debian-devel-announce/2005/05/msg1.html >> 2) Any advice on how to test patches to ftp-master code before >> submitting them? My own scripts I can dry-run by substituting a >> dummy command for sendmail and run them in the very place where >> they will eventually function. In contrast, construcing a test >> mock-up of the ftp-master environment to do test runs of a patched >> britney appears to be highly nontrivial. Does some automation for >> this purpose exist? Or what do ftpmaster/release gurus do when you >> change code? >> 3) Do you (or somebody in QA who reads this) happen to know how the >> 'keyword' under which the PTS forwards emails is transmitted? I >> cannot find any code in katie that sets this. Does the PTS analyse >> subject lines for fixed patterns? > http://cvs.debian.org/pts/?cvsroot=qa is useful here. Thanks. Now I can se what happens. It does indeed use ad-hoc analysis of subject lines. > [EMAIL PROTECTED] is subscribed to -devel-changes and processes > the mails in real-time. Not quite, afaict; katie sends email directly to @p.qa.d.o (config setting Dinstall::TrackingServer). Then the PTS's dispatch.pl script recognizes the X-Katie header and then pattern-matches the subject to decide on a keyword. > britney and other ftp-master related topics are probably most > appropriate on [EMAIL PROTECTED], imho. I assume you mean [EMAIL PROTECTED] - yes, that looks relevant. Cc:ing and setting M-F-T. -- Henning Makholm"There is a danger that curious users may occasionally unplug their fiber connector and look directly into it to watch the bits go by at 100 Mbps." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Are pure virtual Depends/Recommends entries bugs?
* Steinar H. Gunderson [Sat, 05 Nov 2005 19:46:21 +0100]: > On Mon, Oct 31, 2005 at 10:55:18PM -0500, Daniel Burrows wrote: > > (a) Is a pure virtual entry with no prior alternative in a Depends line an > > actual bug? i.e., do we have a consensus on this? > This will prevent the package from autobuilding, which is a bug. That would be for Build-Depends, though it could cause failures for rev-build-depending packages. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Listening to: Matthew Kimball - I don't want to fall in love You've come to the right place. At debian-devel we are always willing to argue over the meanings of words. -- seen on [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337705: ITP: libzorpll3.0.6-dbg -- Low level library functions for Zorp, debug version
Package: wnpp Severity: wishlist Owner: SZALAY Attila <[EMAIL PROTECTED]> * Package name: libzorpll3.0.6-dbg Version : 3.0.6.4 Upstream Author : Scheidler Balázs <[EMAIL PROTECTED]> * URL : http://www.balabit.hu/downloads/zorp/ * License : GNU/GPL + permission to use OpenSSL Description : Low level library functions for Zorp, debug version Zorp is a new generation firewall. It is essentially a transparent proxy firewall, with strict protocol analyzing proxies, a modular architecture, and fine-grained control over the mediated traffic. Configuration decisions are scriptable with the Python based configuration language. . This package contains the same library as libzorpll but with debugging code enabled. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.18 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Bug#337710: ITP: libfile-modified-perl -- checks intelligently if files have changed
Package: wnpp Severity: wishlist Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]> * Package name: libfile-modified-perl Version : 0.07 Upstream Author : Max Maischein, <[EMAIL PROTECTED]> * URL : http://www.cpan.org/modules/by-module/File/File-Modified-0.07.tar.gz * License : (Perl: GPL, Artistic) Description : checks intelligently if files have changed The Modified module is intended as a simple method for programs to detect whether configuration files (or modules they rely on) have changed. There are currently two methods of change detection implemented, mtime and MD5. . The MD5 method will fall back to use timestamps if the Digest::MD5 module cannot be loaded. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: per-user temp directories by default?
> "Noah" == Noah Meyerhans <[EMAIL PROTECTED]> writes: Noah> Within the security team, there has recently been some talk Noah> of pushing for per-user temp directories by default in etch. Noah> I'd like to see what people's reaction to such a proposal Noah> would be. I have something similar (and probably not as good...) in my zshenv file, I seem to recall the PAM solution is better and more secure (possible because it runs as root), but I can't remember the details. My solution will not work if an attacker has already created the directory as another user... if [[ ! -a "/tmp/$USERNAME" ]] then mkdir /tmp/$USERNAME fi if [[ -d "/tmp/$USERNAME" && ! -h "/tmp/$USERNAME" && -O "/tmp/$USERNAME" ]] then export TMP=/tmp/$USERNAME else export TMP=/tmp fi export TMPDIR="$TMP" export TEMP="$TMP" export TMPPREFIX="$TMP/zsh" --- The only problem I have had is chroots (including pbuilder). If you access the chroot in such a way that preserves the environment, you either have to change the chroot somehow ensure /tmp/$USERNAME exists, or change both TMP, TMPDIR and TEMP to /tmp inside the chroot. For pbuilder this can be done by adding: export TMP="/tmp" export TMPDIR="/tmp" export TEMP="/tmp" to pbuilderrc. For dchroot, the only solution I can think of right now is to bind mount /tmp inside the chroot. This will also allow access to X sockets, gdm sockets, ssh-agent sockets, Kerberos tickets, etc. Could be considered good or bad depending on the reason for the chroot... --- On this subject, I find it irritating that we need so many environment variables to indicate where "/tmp" is. Not only that, but some programs don't even give a clear understandable error if the directory doesn't exist. So if you miss one, beware, you might get unpredictable errors. Can't we just pick one standard name for the environment variable and stick to it? -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: real-i386 (was Re: i386 requalification for etch)
Bastian Venthur wrote: > Nick Jacobs wrote: > > >>In-Reply-To=<[EMAIL PROTECTED]> >> >>You mean, it's seriously been proposed that a >>significant amount of work should be done to restore >>support for a processor that has not been manufactured >>for 10 years? While slightly degrading performance for >>the 99.9% of x86 users who have Pentium/Athlon/or >>better? > > > Maybe renaming Debians "i386" into something more accurate like "x86" or > even "IA32" (in consistency with IA64) would suppress discussions like this > in the future? We should either rename i386, or resupport i386, or both. We know what steps it takes ot resupport i386. What kind of work would be needed to rename i386 to x86 or ia32? --Ken Bloom -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Are pure virtual Depends/Recommends entries bugs?
On Mon, Oct 31, 2005 at 10:55:18PM -0500, Daniel Burrows wrote: > As I'm sure everyone knows, pure virtual entries in a Depends line are > strongly deprecated, due to the fact that frontends have a tendency to pick > a random provider of the package. What I'm not sure is if this is just "ugly" > or actually considered a bug. In particular, I can't remember and would like > to know: > > (a) Is a pure virtual entry with no prior alternative in a Depends line an > actual bug? i.e., do we have a consensus on this? > > (b) If the answer to (a) is "yes", is a pure virtual *Recommendation* a bug? > > Rationale: Recommendations are intended to be installed by default, so > their fields should be just as friendly to automatic tools as Depends > is. I don't think a pure virtual dependency (or recommendation) should be a bug. If there is really no reason to choose one provider or another, why choose one artificially? I expect a tool like aptitude might pick the candidate with highest priority, or else one at random (or the first one in some sort order). A package maintainer could pick one this way too, but then it's one more thing to maintain. Steinar mentioned problems with pure virtual build-deps. Those should work too. In the past bugs have been filed about those, but I think those are a problem because of bugs in the auto-build tools, rather than being an intrinsic problems with the deps. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian based GNU/Solaris: pilot program
On Wed, Nov 02, 2005 at 06:21:41PM +0100, Gabor Gombas wrote: > On Thu, Nov 03, 2005 at 12:11:32AM +1100, Hamish Moffatt wrote: > > > I read all of your points as criticisms of Linux. That is disappointing. > > Why is criticism disappointing? The goals of Linux and the Linux Perhaps he meant that *reading them as criticisms of Linux* was disappointing. -- Chris. == Reproduction if desired may be handled locally. -- rfc3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian based GNU/Solaris: pilot program
Hubert Chan wrote: > On Thu, 03 Nov 2005 12:48:53 -0800, Erast Benson <[EMAIL PROTECTED]> said: > > >>On Thu, 2005-11-03 at 12:18 -0800, Thomas Bushnell BSG wrote: >> >>>The GPL does not force developers to "contribute their changes back". >>>That's exactly the *point*. > > >>Explain please. > > >>Lets assume you have GPL-ed project dpkg. Any change to foo.c must be >>contributed back to the community. ... > > > Only if you distribute a binary based on the changed foo.c. And only if > someone asks you for the sources. > > If you keep the binary to yourself, you don't have to release anything. And you don't have to tell the original developers about your improvements either, even if you are distributing the code. You can let them search the *whole* internet to find the improvements if you want. --Ken Bloom -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
