How to identify distro, lsb-release is broken
Hi I need to find a way of identifying the name of an installed distrobution. This mechanism should be able to differentiate woody sarge etch sid hoary breezy dapper Prior to etch I was using lsb-release but it seems /etc/lsb-release is no longer installed by 'apt-get install lsb-release'. The README.Debian file provides the following background information: > Distribution-specific information should be *separately provided* in > /etc/lsb-release; it is no longer provided in this package. It is my > hope that in Debian, this will be managed by the base-files > maintainer (who already maintains the debian_version file). I don't pretend to understand the reason for this change but I do know that my identification mechanism is now broken on etch. Can anyone suggest a more reliable mechanism? Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to identify distro, lsb-release is broken
Stephen Birch <[EMAIL PROTECTED]> writes: > I need to find a way of identifying the name of an installed > distrobution. This mechanism should be able to differentiate To what end? Many people do not run "pure" releases, so the concept of a distro version is rather shaky at best (especially in debian which emphasizes fine-grained upgrades). -Miles -- Is it true that nothing can be known? If so how do we know this? -Woody Allen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to identify distro, lsb-release is broken
Miles Bader([EMAIL PROTECTED])@2006-02-23 17:41: > Stephen Birch <[EMAIL PROTECTED]> writes: > > I need to find a way of identifying the name of an installed > > distrobution. This mechanism should be able to differentiate > > To what end? Many people do not run "pure" releases, so the concept of > a distro version is rather shaky at best (especially in debian which > emphasizes fine-grained upgrades). We use apt to distribute internal software used in our organization. The build dependancies vary slightly for each distro so we simply use the distro ident when compiling to arrange for the correct tools to be installed. Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems found by piuparts
Peter Samuelson <[EMAIL PROTECTED]> wrote: > [Frank Küster] >> That's not sufficient, because /usr/local may be mounted ro, and >> therefore the command may fail even if the directory is empty. > > U. > > There are lots of things dpkg can do which fail if filesystems are > mounted read-only. Correct, but dpkg should never touch anything below /usr/local. > I don't think this is something worth worrying > about. The Debian Policy instructs you to worry about it, though (9.1.2) > I mean, consider the case that the dir in /usr/local is > contained in the package itself, rather than handled by scripts. That would be a release critical bug. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: How to identify distro, lsb-release is broken
On Thu, Feb 23, 2006 at 12:34:00AM -0800, Stephen Birch wrote: > I don't pretend to understand the reason for this change but I do know > that my identification mechanism is now broken on etch. > > Can anyone suggest a more reliable mechanism? I think that the most reliable will be checking libc version. regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: How to identify distro, lsb-release is broken
Am Donnerstag, 23. Februar 2006 10:16 schrieb Stephen Birch: > Miles Bader([EMAIL PROTECTED])@2006-02-23 17:41: > > Stephen Birch <[EMAIL PROTECTED]> writes: > > > I need to find a way of identifying the name of an installed > > > distrobution. This mechanism should be able to differentiate > > > > To what end? Many people do not run "pure" releases, so the concept of > > a distro version is rather shaky at best (especially in debian which > > emphasizes fine-grained upgrades). > > We use apt to distribute internal software used in our organization. > > The build dependancies vary slightly for each distro so we simply use > the distro ident when compiling to arrange for the correct tools to be > installed. If you depend on specific versions of libs or tools, why not test those versions directly? Software like autoconf exists for exactly this purpose. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to identify origin [Was: How to identify distro, lsb-release is broken]
Stephen Birch <[EMAIL PROTECTED]> writes: > Hi > > I need to find a way of identifying the name of an installed > distrobution. This mechanism should be able to differentiate > > woody > sarge > etch > sid > hoary > breezy > dapper Even worse is when people mix up those releases and even distributions. How do I detect the origin of an install package? Could we patch apt-ftparchive to include the origin, maybe including the release, of a package in the Packages files and make apt/aptitude/... pass this along to dpkgs available file (and subsequently status file)? Alternatively apt/aptitude could add an origin line generated from the sources.list entry automatically but that would be les usefull for something like reportbug. Thoughts? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sysklogd -17.1 NMU build broken in mips/mipsel
On Wed, Feb 22, 2006 at 08:47:31PM -0800, Steve Langasek wrote: > On Thu, Feb 23, 2006 at 12:22:27AM -0300, Henrique de Moraes Holschuh wrote: > > On Wed, 22 Feb 2006, Chris Stromsoe wrote: > > > for the entire lifetime of the current stable release. Will -17.1 be > > > making its way into stable any time soon? > > > I seriously doubt so. Changing the stable sysklogd requires an upload to > > stable (which did not happen), and that the stable release manager approves > > it. > > > Also, mips and mipsel have failed to build sysklogd -17.1, probably due to > > toolchain borkage: > > > In file included from /usr/include/asm/atomic.h:26, > > from module.h:31, > > from ksym_mod.c:97: > > /usr/include/asm/cpu-features.h:15:35: error: cpu-feature-overrides.h: No > > such file or directory > > > Maybe that crap is fixed already in mips/mipsel, and a rebuild > > request/binNMU request for sysklogd should be done to address that? > > $ dpkg -c l/linux-kernel-headers/linux-kernel-headers_2.6.13+0rc3-2_mips.deb > |grep cpu-feature > -rw-r--r-- root/root 4858 2005-07-12 21:46:46 > ./usr/include/asm/cpu-features.h > -rw-r--r-- root/root 414 2005-07-12 21:46:46 > ./usr/include/asm/mach-generic/cpu-feature-overrides.h > -rw-r--r-- root/root 836 2005-07-12 21:46:46 > ./usr/include/asm/mach-ip22/cpu-feature-overrides.h > -rw-r--r-- root/root 1039 2005-07-12 21:46:46 > ./usr/include/asm/mach-ip27/cpu-feature-overrides.h > -rw-r--r-- root/root 1215 2005-07-12 21:46:46 > ./usr/include/asm/mach-ip32/cpu-feature-overrides.h > -rw-r--r-- root/root 1200 2005-07-12 21:46:46 > ./usr/include/asm/mach-ja/cpu-feature-overrides.h > -rw-r--r-- root/root 1909 2005-07-12 21:46:46 > ./usr/include/asm/mach-mips/cpu-feature-overrides.h > -rw-r--r-- root/root 1321 2005-07-12 21:46:46 > ./usr/include/asm/mach-ocelot3/cpu-feature-overrides.h > -rw-r--r-- root/root 1284 2005-07-12 21:46:46 > ./usr/include/asm/mach-rm200/cpu-feature-overrides.h > -rw-r--r-- root/root 1042 2005-07-12 21:46:46 > ./usr/include/asm/mach-sibyte/cpu-feature-overrides.h > -rw-r--r-- root/root 1218 2005-07-12 21:46:46 > ./usr/include/asm/mach-yosemite/cpu-feature-overrides.h > $ > > It looks to me like this is still broken on mips. A bug on l-k-h is > probably in order. It is probably (also?) a sysklogd bug, userland code isn't supposed to use the kernel's atomic operations. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to identify origin [Was: How to identify distro, lsb-release is broken]
Goswin von Brederlow wrote: >> I need to find a way of identifying the name of an installed >> distrobution. This mechanism should be able to differentiate >> >> woody >> sarge >> etch >> sid >> hoary >> breezy >> dapper > > Even worse is when people mix up those releases and even > distributions. mixed distribtions do not matter in this case. The question was how to identify the distribution that was installed! (counting a distribution upgrade as new install for sake of simplicicity). I also run a pool auf auto installed machines, and found that lsb_release utility very handy for this use case. I would find it unconvinient if I had to reintroduce lsb_release in a self grown package if future releases of debian do not ship a suitable lsb_release command anymore. > How do I detect the origin of an install package? This is a completly different use-case and problem to what the original poster asked. Greetings, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sysklogd -17.1 NMU build broken in mips/mipsel
On Thu, Feb 23, 2006 at 11:55:12AM +, Thiemo Seufer wrote: > It is probably (also?) a sysklogd bug, userland code isn't supposed to > use the kernel's atomic operations. It is only a sysklogd bug. Userland code is not allowed to use kernel headers directly. Bastian -- We do not colonize. We conquer. We rule. There is no other way for us. -- Rojan, "By Any Other Name", stardate 4657.5 signature.asc Description: Digital signature
Re: Bug#353917: ITP: lanmap -- lanmap sits quietly on a network and builds a picture of what it sees.
On Tue, Feb 21, 2006 at 04:11:40PM -0800, Sebastien Delafond wrote: > > Should the similarities between PADS and lanmap prevent the latter > from being packaged for Debian ? I understand they both rely on Of course not! > passive network monitoring to produce info, but I still don't see that > as an obstacle to packaging lanmap in Debian. Maybe commenting on what features you feel "make a difference" on this package vs. others will help users decide which one to install. Regards Javier signature.asc Description: Digital signature
ITP: root -- An object oriented data analysis framework
Followup-For: Bug #325306 Package: wnpp Owner: Christian Holm Christensen <[EMAIL PROTECTED]> I intent to package this software for Debian. The license of ROOT has recently been changed from a DFSG non-free license, to the GNU LGPL. An apt-get repository exists at deb http://mirror.phy.bnl.gov/debian-root unstable root deb-src http://mirror.phy.bnl.gov/debian-root unstable root The packages have been built on i386, powerpc, and amd64. A bit of rudimentary tests have been done on ppc64 and sparc, but with no success. The packages have previously been built on hurd-i386, but that's a long time ago. The packages could really do with some independent testing, especially on more exotic platforms, like arm, ia64, and so on. A lot of discussion about these packages is talking place at the debian-science mailing list. There's also a Wiki page at http://wiki.debian.org/DebianScienceROOT. On http://mirror.phy.bnl.gov/debian-root/ there's also a bit. ROOT has a fairly large user base in High Energy Physics, which however mostly use Red Hat, Fedora, or SL. None of these distributions ship ROOT though. The Debian packages are developed concurently with the RPM packages. In fact, the same data is used by both packaging systems to make the DEB's and RPM's. Hence, there's very little difference between the Debian packages and the RPM's. Please note, I'm not on debian-devel (as I'm not a maintainer - yet :-), so please Cc replies to me. Thanks. Yours, -- ___ | Christian Holm Christensen |_| | - | | Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 _| DK-2200 Copenhagen N Cell: (+45) 24 61 85 91 _|DenmarkOffice: (+45) 353 25 404 | Email: [EMAIL PROTECTED] Web:www.nbi.dk/~cholm | | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: root -- An object oriented data analysis framework
also sprach Christian Holm Christensen <[EMAIL PROTECTED]> [2006.02.23.1555 +0100]: > I intent to package this software for Debian. I think the package name is a little too broad. We already have three roots on Unix: / and the UID/GID 0. But it's an established software name. Maybe consider cern-root? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver! "all language designers are arrogant. goes with the territory..." -- larry wall signature.asc Description: Digital signature (GPG/PGP)
May a package assume that builds are performed with root-like rights? (was: jadetex: FTBFS: mktexdir failed)
reassing 354113 tex-common thanks I think this problem is of general interest, or at least I don't feel we (the TeX Task Force) cannot decide this on our own. In short: May a package assume that package builds are performed with root-like rights, and thus use non-world-writable directories for caching purposes? Daniel Schepler <[EMAIL PROTECTED]> wrote: >> > From my pbuilder build log: >> > >> > ... >> > mkdir: cannot create directory `././var/cache/fonts/tfm/jknappen': >> > Permission denied mktextfm: mktexdir /var/cache/fonts/tfm/jknappen/ec [...] >> I cannot reproduce this here. [...] >> >> I'm using a normal pbuilder setup with sudo - do you somehow chroot >> without being root? And if that is the case, is the respective user >> member of the "users" group in the chroot? Probably not, and that will >> be the problem. > > I ran pbuilder as root, but I have pbuilder set up to su to a normal user for > the build. > > So are you saying it's a bug for pbuilder not to put that user in the users > group? I thought the users group was pretty much obsolete anyway, replaced > by per-user groups -- at least on my system, where I did nothing special, > running "groups" from my normal account gives > daniel dialout cdrom floppy audio video No, I don't think that it's a bug in pbuilder. But on the other hand, I think that it was a security risk that TeX's font cache directory was world-writable in previous versions. Changing that to allow write access only for a specific group seemed a good compromise (until some new clever font caching mechanism, probably with a client/server architecture, is implemented. But that's only a dream). So the current state is: If pbuilder runs all commands inside the chroot, everything is fine, and AFAIK the same is true for the buildds. But if you su to some user in the chroot, near to every package that Build-depends on tetex-bin will FTBFS, unless you specifically arrange for that user to be in group "users" (or anything else we switch to, I don't care much). Is this a bug in tex-common, or should package builders just be more careful with their setup? What do others think? TIA, Frank P.S. Making the change is easy, it's just changing a debconf default -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: May a package assume that builds are performed with root-like rights? (was: jadetex: FTBFS: mktexdir failed)
Le Jeudi 23 Février 2006 16:37, Frank Küster a écrit : > So the current state is: If pbuilder runs all commands inside the > chroot, everything is fine, and AFAIK the same is true for the buildds. > But if you su to some user in the chroot, near to every package that > Build-depends on tetex-bin will FTBFS, unless you specifically arrange > for that user to be in group "users" (or anything else we switch to, I > don't care much). FWIW, jadetex is the only TeX-using package to actually FTBFS so far for me because of this -- including some that use docbook-utils and thus jadetex indirectly. For example, I just tried running pbuilder on make_3.80+3.81.b4-1.dsc again, which does create some fonts during the build, and the build completes fine, except that I get error messages like kpathsea: Running mktexpk --mfmode ljfour --bdpi 600 --mag 1+264/600 --dpi 864 cmbx12 mkdir: cannot create directory `././var/cache/fonts/pk/ljfour': Permission denied mktexpk: mktexdir /var/cache/fonts/pk/ljfour/public/cm failed. kpathsea: Appending font creation commands to missfont.log. dvips: Font cmbx12 not found, characters will be left blank. (BTW, I think you forgot to send that message to [EMAIL PROTECTED] -- just as well, since you misspelled reassign. :) -- Daniel Schepler
Re: May a package assume that builds are performed with root-like rights?
Hi, Frank Küster wrote: In short: May a package assume that package builds are performed with root-like rights, and thus use non-world-writable directories for caching purposes? Absolutely not. The only assumption you may make is that the binary* targets are called in a way that allows chown and chmod to work and be persistent enough to remain in effect until the target exits. Simon signature.asc Description: OpenPGP digital signature
Re: May a package assume that builds are performed with root-like rights?
Daniel Schepler <[EMAIL PROTECTED]> wrote: > Le Jeudi 23 Février 2006 16:37, Frank Küster a écrit : >> So the current state is: If pbuilder runs all commands inside the >> chroot, everything is fine, and AFAIK the same is true for the buildds. >> But if you su to some user in the chroot, near to every package that >> Build-depends on tetex-bin will FTBFS, unless you specifically arrange >> for that user to be in group "users" (or anything else we switch to, I >> don't care much). > > FWIW, jadetex is the only TeX-using package to actually FTBFS so far for me > because of this -- including some that use docbook-utils and thus jadetex > indirectly. If they use PostScript Base fonts, everything is already included. Therefore I was wrong with the prediction "near to every" package, because many use Times/Palatino/whatever. > For example, I just tried running pbuilder on > make_3.80+3.81.b4-1.dsc again, which does create some fonts during the build, > and the build completes fine, except that I get error messages like > kpathsea: Running mktexpk --mfmode ljfour --bdpi 600 --mag 1+264/600 --dpi > 864 > cmbx12 > mkdir: cannot create directory `././var/cache/fonts/pk/ljfour': Permission > denied > mktexpk: mktexdir /var/cache/fonts/pk/ljfour/public/cm failed. > kpathsea: Appending font creation commands to missfont.log. > dvips: Font cmbx12 not found, characters will be left blank. Well, that's a problem and a bug, too. > (BTW, I think you forgot to send that message to [EMAIL PROTECTED] -- just as > well, since you misspelled reassign. :) Blind Cc. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: May a package assume that builds are performed with root-like rights?
Simon Richter <[EMAIL PROTECTED]> wrote: > Hi, > > Frank Küster wrote: > >> In short: May a package assume that package builds are performed with >> root-like rights, and thus use non-world-writable directories for >> caching purposes? > > Absolutely not. ...because? Because: , Policy 4.8 | The build target must not do anything that might require root privilege. ` Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: May a package assume that builds are performed with root-like rights?
Le Jeudi 23 Février 2006 17:20, Frank Küster a écrit :
> > For example, I just tried running pbuilder on
> > make_3.80+3.81.b4-1.dsc again, which does create some fonts during the
> > build, and the build completes fine, except that I get error messages
> > like kpathsea: Running mktexpk --mfmode ljfour --bdpi 600 --mag 1+264/600
> > --dpi 864 cmbx12
> > mkdir: cannot create directory `././var/cache/fonts/pk/ljfour':
> > Permission denied
> > mktexpk: mktexdir /var/cache/fonts/pk/ljfour/public/cm failed.
> > kpathsea: Appending font creation commands to missfont.log.
> > dvips: Font cmbx12 not found, characters will be left blank.
>
> Well, that's a problem and a bug, too.
Indeed. I hadn't even noticed this was happening until I tried that and
looked closely at the build log.
Here's a thought: how hard would it be to make TeX fall back to caching in a
directory under the user's home directory (maybe $HOME/.fonts/texmf or so) if
it can't write to /var/cache/fonts? pbuilder does have $HOME set up to work
all right with BUILDUSER{ID,NAME}.
--
Daniel Schepler
Re: Bug#325306: ITP: root -- An object oriented data analysis framework
Hi Martin, On Thu, 2006-02-23 at 16:37 +0100, martin f krafft wrote: > also sprach Christian Holm Christensen <[EMAIL PROTECTED]> [2006.02.23.1555 > +0100]: What happened to Zaratustra? > > I intent to package this software for Debian. > > I think the package name is a little too broad. I'm well-aware that the package name is unfortunate. However, the main executable is called `root', with utility programs `rootcint', `root-config', `rootd', `xrootd', and so on. These names, can not be changed, or the user wouldn't get the expected behaviour. > We already have three roots on Unix: / and the UID/GID 0. So there's 1. `root' the path, 2. `root' the user, 3. `root' the group, and now 4. `root' the application. Kidding aside. I think, perhaps the package names could change, but the executable, etc. can not. It would conflict with the general use of the application. Note, that the executable `root' is just one aspect of the whole thing.To make a user class persistent/`scriptable', ROOT uses a dictionary generated by the program `rootcint' - hence users expect to be able to do rootcint -f MyDictionary.cxx -c $(CPPFLAGS) MyHeader.h That is, a lot of third party software does exactly something like the above in the build-system. > But it's an established software name. Maybe consider cern-root? For the meta-package, yes, but does it really matter? Also, although the main development takes place at CERN, it would be unfair to the large number of contributors from all over the world to call it `cern-root'. Yours, -- ___ | Christian Holm Christensen |_| | - | | Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 _| DK-2200 Copenhagen N Cell: (+45) 24 61 85 91 _|DenmarkOffice: (+45) 353 25 404 | Email: [EMAIL PROTECTED] Web:www.nbi.dk/~cholm | | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems found by piuparts
On Wed, 22 Feb 2006, Frank Küster wrote: > Adeodato Simó <[EMAIL PROTECTED]> wrote: > > Correct, so one would put in foo.postrm: > > > > rmdir --ignore-fail-on-non-empty /usr/local/lib/foo > > That's not sufficient, because /usr/local may be mounted ro, and > therefore the command may fail even if the directory is empty. > > rmdir --ignore-fail-on-non-empty /usr/local/lib/foo || true So you're suggesting that it's better to fail silently instead of failing loudly? Don Armstrong -- "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." -- Jeremy S. Anderson http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Bug#325306: ITP: root -- An object oriented data analysis framework
also sprach Christian Holm Christensen <[EMAIL PROTECTED]> [2006.02.23.1721 +0100]: > > also sprach Christian Holm Christensen <[EMAIL PROTECTED]> [2006.02.23.1555 > > +0100]: > > What happened to Zaratustra? He's sitting up on the pole still. > > But it's an established software name. Maybe consider cern-root? > > For the meta-package, yes, but does it really matter? Also, > although the main development takes place at CERN, it would be > unfair to the large number of contributors from all over the world > to call it `cern-root'. Okay. I just wanted the issue thought over. I have no objections really. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver! "i wish i hadn't slept all day, it's really lowered my productivity" -- robert mcqueen signature.asc Description: Digital signature (GPG/PGP)
Re: Problems found by piuparts
Don Armstrong <[EMAIL PROTECTED]> wrote: > On Wed, 22 Feb 2006, Frank Küster wrote: >> Adeodato Simó <[EMAIL PROTECTED]> wrote: >> > Correct, so one would put in foo.postrm: >> > >> > rmdir --ignore-fail-on-non-empty /usr/local/lib/foo >> >> That's not sufficient, because /usr/local may be mounted ro, and >> therefore the command may fail even if the directory is empty. >> >> rmdir --ignore-fail-on-non-empty /usr/local/lib/foo || true > > So you're suggesting that it's better to fail silently instead of > failing loudly? Yes, please read Policy 9.1.2. The reason is that we cannot assume that there are any write permissions on /usr/local. See e.g. http://bugs.debian.org/338638: The reporter has mounted /usr/local from a server at his site, and the admin on the individual machines don't have write permissions on that share. Therefore it's not possible to create any directories, but on the other hand it's equally impossible to remove any directories created by the share's admin. Even if they are empty. There's no problem with that, unless a maintainer script tries to do it *and* fails if it can't. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: May a package assume that builds are performed with root-like rights?
Daniel Schepler wrote:
> Here's a thought: how hard would it be to make TeX fall back to caching in a
> directory under the user's home directory (maybe $HOME/.fonts/texmf or so) if
> it can't write to /var/cache/fonts? pbuilder does have $HOME set up to work
> all right with BUILDUSER{ID,NAME}.
Well, some people think that writing outside the build-dir is a FTBFS
bug as well[1].
Kind regards
T.
1. http://bugs.debian.org/336014
--
Thomas Viehmann, http://thomas.viehmann.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: May a package assume that builds are performed with root-like rights?
Daniel Schepler <[EMAIL PROTECTED]> wrote: > Here's a thought: how hard would it be to make TeX fall back to caching in a > directory under the user's home directory (maybe $HOME/.fonts/texmf or so) if > it can't write to /var/cache/fonts? It would be extremely hard (at least 5 different shell scripts access it, interact with each other, etc.), and difficult to handle when upstream changes the scripts. We can suggest it to upstream, but I guess they should rather use the coding time to implement a sane caching mechanism. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Problems found by piuparts
On Thu, 23 Feb 2006, Frank Küster wrote: > Don Armstrong <[EMAIL PROTECTED]> wrote: > > On Wed, 22 Feb 2006, Frank Küster wrote: > >> Adeodato Simó <[EMAIL PROTECTED]> wrote: > >> > Correct, so one would put in foo.postrm: > >> > > >> > rmdir --ignore-fail-on-non-empty /usr/local/lib/foo > >> > >> That's not sufficient, because /usr/local may be mounted ro, and > >> therefore the command may fail even if the directory is empty. > >> > >> rmdir --ignore-fail-on-non-empty /usr/local/lib/foo || true > > > > So you're suggesting that it's better to fail silently instead of > > failing loudly? > > Yes, please read Policy 9.1.2. Hrm, right... it just seems totally wrong to me for the package to create the directories and then not fail if removing them fails, since presumably the removal could fail for reasons unrelated to /usr/local being r/o. [Perhaps the ideal solution to resolve both of these issues is to have the script complain bitterly if it can't remove the directories and they exist, but not fail.] Don Armstrong -- If you wish to strive for peace of soul, then believe; if you wish to be a devotee of truth, then inquire. -- Friedrich Nietzsche http://www.donarmstrong.com http://rzlab.ucr.edu
Re: May a package assume that builds are performed with root-like rights?
Thomas Viehmann <[EMAIL PROTECTED]> wrote:
> Daniel Schepler wrote:
>> Here's a thought: how hard would it be to make TeX fall back to caching in a
>> directory under the user's home directory (maybe $HOME/.fonts/texmf or so)
>> if
>> it can't write to /var/cache/fonts? pbuilder does have $HOME set up to work
>> all right with BUILDUSER{ID,NAME}.
> Well, some people think that writing outside the build-dir is a FTBFS
> bug as well[1].
[...]
> 1. http://bugs.debian.org/336014
Well, yes, but I think things are different here. I think nobody would
object if a package writes into /var/ or /tmp, and ours is just another
case of /var usage.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Re: sysklogd -17.1 NMU build broken in mips/mipsel
On Thu, 23 Feb 2006, Bastian Blank wrote: > On Thu, Feb 23, 2006 at 11:55:12AM +, Thiemo Seufer wrote: > > It is probably (also?) a sysklogd bug, userland code isn't supposed to > > use the kernel's atomic operations. > > It is only a sysklogd bug. Userland code is not allowed to use kernel > headers directly. So far so good, but why is it allowed for a kernel header to include a file that does not exist? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sysklogd -17.1 NMU build broken in mips/mipsel
On Thu, Feb 23, 2006 at 03:00:19PM -0300, Henrique de Moraes Holschuh wrote: > So far so good, but why is it allowed for a kernel header to include a file > that does not exist? mips is not managed in the tree of linus. So it is likely that it regulary breaks. Bastian -- I'm a soldier, not a diplomat. I can only tell the truth. -- Kirk, "Errand of Mercy", stardate 3198.9
Re: sysklogd -17.1 NMU build broken in mips/mipsel
On Thu, 23 Feb 2006, Bastian Blank wrote: > On Thu, Feb 23, 2006 at 03:00:19PM -0300, Henrique de Moraes Holschuh wrote: > > So far so good, but why is it allowed for a kernel header to include a file > > that does not exist? > > mips is not managed in the tree of linus. So it is likely that it > regulary breaks. Then it is not "only a sysklogd bug", but rather two bugs, one in sysklogd, one in the kernel headers. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sysklogd -17.1 NMU build broken in mips/mipsel
* Bastian Blank <[EMAIL PROTECTED]> [2006-02-23 19:13]: > > So far so good, but why is it allowed for a kernel header to > > include a file that does not exist? > mips is not managed in the tree of linus. So it is likely that it > regulary breaks. Actually, there has been lots of syncing going on recently. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354156: ITP: libsmart-comments-perl -- comments that do more than just sit there
Package: wnpp Severity: wishlist Owner: Niko Tyni <[EMAIL PROTECTED]> * Package name: libsmart-comments-perl Version : 1.0.2 Upstream Author : Damian Conway <[EMAIL PROTECTED]> * URL : http://mirrors.kernel.org/CPAN/modules/by-authors/id/DCONWAY/Smart-Comments-v1.0.2.tar.gz * License : GPL/Artistic Description : comments that do more than just sit there Smart comments provide an easy way to insert debugging and tracking code into a program. They can report the value of a variable, track the progress of a loop, and verify that particular assertions are true. . Best of all, when you're finished debugging, you don't have to remove them. Simply commenting out the "use Smart::Comments" line turns them back into regular comments. Leaving smart comments in your code is smart because if you needed them once, you'll almost certainly need them again later. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sysklogd -17.1 NMU build broken in mips/mipsel
On Thu, Feb 23, 2006 at 11:55:12AM +, Thiemo Seufer wrote: > > $ dpkg -c > > l/linux-kernel-headers/linux-kernel-headers_2.6.13+0rc3-2_mips.deb |grep > > cpu-feature > > -rw-r--r-- root/root 4858 2005-07-12 21:46:46 > > ./usr/include/asm/cpu-features.h > > -rw-r--r-- root/root 414 2005-07-12 21:46:46 > > ./usr/include/asm/mach-generic/cpu-feature-overrides.h > > -rw-r--r-- root/root 836 2005-07-12 21:46:46 > > ./usr/include/asm/mach-ip22/cpu-feature-overrides.h > > -rw-r--r-- root/root 1039 2005-07-12 21:46:46 > > ./usr/include/asm/mach-ip27/cpu-feature-overrides.h > > -rw-r--r-- root/root 1215 2005-07-12 21:46:46 > > ./usr/include/asm/mach-ip32/cpu-feature-overrides.h > > -rw-r--r-- root/root 1200 2005-07-12 21:46:46 > > ./usr/include/asm/mach-ja/cpu-feature-overrides.h > > -rw-r--r-- root/root 1909 2005-07-12 21:46:46 > > ./usr/include/asm/mach-mips/cpu-feature-overrides.h > > -rw-r--r-- root/root 1321 2005-07-12 21:46:46 > > ./usr/include/asm/mach-ocelot3/cpu-feature-overrides.h > > -rw-r--r-- root/root 1284 2005-07-12 21:46:46 > > ./usr/include/asm/mach-rm200/cpu-feature-overrides.h > > -rw-r--r-- root/root 1042 2005-07-12 21:46:46 > > ./usr/include/asm/mach-sibyte/cpu-feature-overrides.h > > -rw-r--r-- root/root 1218 2005-07-12 21:46:46 > > ./usr/include/asm/mach-yosemite/cpu-feature-overrides.h > > $ > > It looks to me like this is still broken on mips. A bug on l-k-h is > > probably in order. > It is probably (also?) a sysklogd bug, userland code isn't supposed to > use the kernel's atomic operations. Definitely "also", then, since l-k-h shouldn't be installing broken headers :) -- 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
Your Television website
Hi, I manage a website called televisionsmart.com and I think your site would be of interest to the visitors that regularly browse my site. I have gone ahead and given you a link plus a description of your site from my page at http://televisionsmart.com/internettv and I'm just contacting you to check it is ok to have done this for you? I would greatly appreciate a link back to my site and if you are happy to do this then to make it easy for you I have included the following code http://televisionsmart.comTelevisions Mart Everything Television, from 19 Television to Wide Screen Television. Feel free to change the suggested code if you would like to. I look forward to a mutually beneficial link partnership and I wish you all the best with your site for the future. Please let me know if there is anything else I can do for you. Kind regards Marta P.S. Keep up the good work! Disclaimer: If this email has reached you in error or if you would not like to be contacted again then please accept my sincere apologies. Let me know by sending an email to [EMAIL PROTECTED] if this is the case and I will make sure televisionsmart.com never contacts you again. //
Bug#354159: ITP: libgetopt-euclid-perl -- Executable Uniform Command-Line Interface Descriptions
Package: wnpp Severity: wishlist Owner: Niko Tyni <[EMAIL PROTECTED]> * Package name: libgetopt-euclid-perl Version : 0.0.5 Upstream Author : Damian Conway <[EMAIL PROTECTED]> * URL : http://mirrors.kernel.org/CPAN/modules/by-module/Getopt/Getopt-Euclid-v0.0.5.tar.gz * License : GPL/Artistic Description : Executable Uniform Command-Line Interface Descriptions Getopt::Euclid uses your program's own documentation to create a command-line argument parser. This ensures that your program's documented interface and its actual interface always agree. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna <[EMAIL PROTECTED]> writes: > On Wed, Feb 22, 2006 at 05:55:01PM -0800, Thomas Bushnell BSG wrote: >> Adam McKenna <[EMAIL PROTECTED]> writes: >> >> > As far as the second statement being the reason that most of us want >> > ndiswrapper in main, that may be true, but it is no excuse to ignore rules >> > that are very clearly laid out in the SC and DFSG. >> >> I'm a little confused here. > > Not surprising. > >> How does putting ndiswrapper in contrib violate the SC or the DFSG? > > Who said that it did? Help me out then. You seemed to suggest that not putting ndiswrapper in main would be to "ignore rules that are very clearly laid out in the SC and DFSG." Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Prelimary Debian Packages
Hi, As promised, I worked on packaging XaraLX for debian. I have put a simple package for debian unstable on http://people.debian.org/~nomeata/xaralx/xaralx_0.svn20060223-1_i386.deb Please not that the source package is not yet available, as the source is not yet released. Please report non-packaging bugs to the xaralx mailing list, other bugs to me. See also http://www.joachim-breitner.de/blog/archives/128-First-Prelimary-XaraLX-debian-package.html Greetings, Joachim PS: I'll be offline the next week, so if it doesn't work for you, I guess you'll have to wait. :-) -- Joachim "nomeata" Breitner Debian Developer [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354174: RFH: nas -- The Network Audio System
Package: wnpp Version: N/A; reported 2006-02-23 Severity: normal I've not used nas in quite a while, and due to other commitments I'm not going to have too much time for it in the near future. More background: * the nas source package builds several binary packages * currently 5 open bugs * upstream are a delight to work with, and are especially responsive to accepting Debian patches; the current diff from upstream is _tiny_ Hence, I feel this package would be ideal for a new maintainer to help out with - I'd be happy to do some mentoring, work through some bugs with another person and sponsor uploads where necessary. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich signature.asc Description: Digital signature
Bug#354176: RFH: cvs -- Concurrent Versions System
Package: wnpp Version: N/A; reported 2002-01-30 Severity: wishlist cvs is a commonly-used (still) source control system. It has a large number of users and quite a large number of bugs to match. I've not had enough time to adequately work on cvs lately, and if anything that's only going to get worse. However, as cvs is quite an important package to its regular users (like me!) I'd rather not simply orphan it. Instead, I'd like to volunteer it as a package suitable for co-maintenance with one or more new maintainers. I'd be quite happy to mentor such NMs and/or sponsor uploads where necessary. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll signature.asc Description: Digital signature
Re: May a package assume that builds are performed with root-like rights?
[Frank Küster] > Because: > > , Policy 4.8 > | The build target must not do anything that might require root privilege. > ` Right, but the 'binary' target is run as root. , Policy 4.8 | The `fakeroot' package often allows one to build a package correctly | even without being root. ` Here, Policy implies that fakeroot may not *always* work. Perhaps Policy should be updated to stipulate that the only root privileges you can actually rely on relate to the metadata stored in data.tar.gz. signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
On Thu, Feb 23, 2006 at 01:30:25PM -0800, Thomas Bushnell BSG wrote: > Help me out then. You seemed to suggest that not putting ndiswrapper > in main would be to "ignore rules that are very clearly laid out in > the SC and DFSG." I suggested that the CTTE overriding the developer's judgement in this instance would be an abuse of power, since the DFSG and SC (not to mention policy) clearly spell out the requirements for main, and ndiswrapper clearly meets them. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On binary compatibility
I've read a lot about the binary incompatibility concern between Debian and Ubuntu. I have an idea, but I don't have the skill to implement it myself. I figured it would be useful to throw it out there for you all to scrutinize, determine the implementation feasibility, and perhaps run with. First of all, I think it is useful to analyze Ubuntu's motivation -- releasing well-integrated bleeding-edge software. The easiest way to accomplish this goal is by branching from sid. This means that Ubuntu libraries differ from the stable Debian release. Hence, Debian stable (and sid/testing) packages are incompatible with the Ubuntu libraries; thus creating the need for duplicate packaging work by both the Ubuntu and Debian communities. I think that Ubuntu's motivation to provide the latest software is reasonable; however, I think that Debian may be able to help to support that goal while making it possible to maintain binary compatibility. The solution would be to convince Ubuntu to branch from stable instead of sid. The problem is that this creates a lot of work for Ubuntu because they have to backport all of the desired bleeding-edge stuff. However, Debian developers could work with and contribute more to backports.org making it easier for Ubuntu. The most problematic software will be GNOME because it depends on the latest GTK which depends on newer low level libs, which would mean all of the above would need to be backported -- probably quite a significant undertaking. Maybe a solution would be to force the sid GNOME release (and hence the upstream GNOME) to use the Debian stable GTK. Obviously this would have some major political issues. How can we tell upstream what libraries they can and cannot use? Hardware support would be another issue. There would need to be a way to backport support for newer hardware, which may involve backporting newer kernels or backporting support for newer hardware into the stable kernel. The problem is that this solution is hard work for Debian, and I don't think that Ubuntu would take on the backporting challenge itself. It also means making backports.org an official Debian archive. The only way that this would work is if there are Debian folks willing to spend the time to work on backports of their packages. And there would need to be coordination with Ubuntu to determine which packages require backporting, and which can be kept as is. Well, anyway, these are my thoughts. I'm not a developer, and thus cannot see the issues beyond those described, and cannot take on this work myself, but I think that compatibility is a very desirable goal -- not only for Debian and Ubuntu, but for providing a stable platform for external software development on GNU/Linux. All too often I hear about "we don't support Linux because it's a moving platform," and "we can only support one version, so we choose red hat enterprise 3". I think thats rediculous. I think we can make it possible for software developers to create one release that will run on all distributions. One final open-ended question is: which consumes more resources? Duplicate packaging or backporting? I look forward to any insight and contributions. Mike Gilbert
Re: How to identify distro, lsb-release is broken
Stephen Birch wrote: Hi I need to find a way of identifying the name of an installed distrobution. This mechanism should be able to differentiate woody sarge etch sid hoary breezy dapper How about to check/grep/process /etc/debian_version installed by base-files? $ cat /etc/debian_version testing/unstable Does ubuntu has a /etc/ubuntu_version ? $ apt-file search debian_version base-files: etc/debian_version This is only one idea... Carlos C Soto :: eclipxe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Work-needing packages report for Feb 24, 2006
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 234 (new: 21) Total number of packages offered up for adoption: 90 (new: 2) Total number of packages requested help for: 19 (new: 2) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: c-sig (#353621), orphaned 4 days ago Description: A signature tool for GNU Emacs Installations reported by Popcon: 20 edb (#353629), orphaned 4 days ago Description: A database program for GNU Emacs Installations reported by Popcon: 24 elisp-manual-ja (#353625), orphaned 4 days ago Description: Japanese version of Emacs Lisp Reference Manual Installations reported by Popcon: 11 emacs-lisp-intro-ja (#353628), orphaned 4 days ago Description: Japanese version of "Programming in Emacs Lisp: An Introduction" Installations reported by Popcon: 16 emacs-manual-ja (#353624), orphaned 4 days ago Description: Japanese version of the GNU Emacs Manual Installations reported by Popcon: 16 ftpmirror (#353635), orphaned 4 days ago Description: Mirroring directory hierarchy with FTP Installations reported by Popcon: 65 gnome-ppp (#353397), orphaned 6 days ago Description: modem internet connection tool for GNOME Installations reported by Popcon: 42 goobox (#353398), orphaned 6 days ago Description: CD player and ripper for GNOME Installations reported by Popcon: 140 libsufary-ruby (#353632), orphaned 4 days ago Description: SUFARY module for Ruby 1.6 Reverse Depends: libsufary-ruby Installations reported by Popcon: 8 manued-el (#353620), orphaned 4 days ago Description: Minor mode for manued proofreading method Installations reported by Popcon: 5 mimedecode (#354177), orphaned today Description: Decodes transfer encoded text type mime messages Installations reported by Popcon: 571 rig (#353394), orphaned 6 days ago Description: Random identity generator Installations reported by Popcon: 85 skk (#353627), orphaned 4 days ago Description: SKK Dictionary server Reverse Depends: scim-skk uim-skk Installations reported by Popcon: 24 skktools (#353633), orphaned 4 days ago Description: SKK dictionary maintenance tools Installations reported by Popcon: 13 src2tex (#353619), orphaned 4 days ago Description: A converter from source program files to TeX format files Installations reported by Popcon: 223 sufary (#353626), orphaned 4 days ago Description: Perl module for SUFARY Reverse Depends: sufary sufary-dev libsufary-perl libsufary-ruby1.6 sufary-tcltk libsufary-ruby1.8 Installations reported by Popcon: 41 trr19 (#353623), orphaned 4 days ago Description: A type training software on GNU Emacs Installations reported by Popcon: 26 windows-el (#353634), orphaned 4 days ago Description: Window manager for GNU Emacs Installations reported by Popcon: 47 xbatt (#353622), orphaned 4 days ago Description: Display battery status Installations reported by Popcon: 34 xdaliclock (#353390), orphaned 6 days ago Description: Melting digital clock Installations reported by Popcon: 629 xevil (#353389), orphaned 6 days ago Description: A violent side-scrolling game for X Installations reported by Popcon: 110 213 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: gsasl (#354182), offered today Reverse Depends: mailutils-pop3d gsasl mailutils-mh libvmime0 libgsasl7-dev msmtp libvmime-dev mailutils mailutils-imap4d Installations reported by Popcon: 556 python-xml (#354012), offered yesterday Description: XML tools for Python [dummy package] Reverse Depends: python2.4-schoolbell python2.4-schooltool python-logilab-common fonttools python-reportlab rubrica qm zope2.7 qmtest python2.4-soappy python2.3-soappy gdeskcal tinyerp-server imgseek lodju python-zsi python-4suite python-davlib python2.3-reportlab memaid-pyqt revelation xbel-utils gcompris python2.4-reportlab python2.3-xmldiff pyslide gdesklets python2.3-4suite zope2.8 python-xml Installations reported by Popcon: 2616 88 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: [NEW] cvs (#354176), requeste
Re: How to identify distro, lsb-release is broken
Carlos C Soto wrote: > Does ubuntu has a /etc/ubuntu_version ? yes, it reads 'testing/unstable' for all past releases. Greetings, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
