Re: enforcing an UTF8 locale while building a package
On Thu, 11 Jan 2018 at 11:36:57 +0530, Chris Lamb wrote: > > > Just as one example, a timezone library that did not work properly > > > in timezones beyond UTC+0800, etc. > > > > That's a bug, sure, but is it necessarily a release-critical bug? > > I'm not sure I see the value in discussing > the severity level of a hypothetical bug? :) The reason I brought it up is that you mentioned detecting such bugs as a reason to prefer not to force TZ=UTC for related packages' builds; but if that makes a package's build fail, then it becomes "artificially" RC, whether it would have been RC on its own merits or not. smcv
Re: Storing build profiles in binary packages
On 2018-01-11 01:46, Guillem Jover wrote: [ Just few comments to complement josch's veyr nice reply, with which I completely agree with. ] On Thu, 2018-01-11 at 00:47:28 +0100, Johannes Schauer wrote: Quoting Steve Langasek (2018-01-10 21:49:02) > As a policy, I think it's clear that packages built with non-default profiles > should never be included in the Debian archive; Why? By enforcing (via a policy and checkable via reproducible builds) that the binary packages that are being built with one (possibly empty) set of build profiles active are bit-by-bit identical to those built with a different set of build profiles active, it doesn't matter whether a given binary package was built with either set. Yes, and in addition this information is recorded in both .changes and .buildinfo files. I was initially among the ones wanting this information in the .debs to be able to trace it, but the need disappeared when we introduced .buildinfo files, because then we've got the upload specific recording for the archive processor (.changes), and the supposedly public facing record of what was done during the build (.buildinfo), although the later can never be fully trusted anyway. :) Fair enough. I guess at which point it boils down to archive deficiencies within dak in particular that buildinfo and changes content are not easily accessible, because they are not kept as part of archive metadata that can be synced. Kind regards and thanks Philipp Kern
Re: ITP: debos -- Debian OS builder
Am Dienstag, den 09.01.2018, 19:34 +0100 schrieb Hector Oron: > Package: wnpp > Severity: wishlist > Owner: Héctor Orón Martínez > > * Package name: debos > Version : 1.0.0+git20171222.87b0d5e-1 > Upstream Author : > * URL : https://github.com/go-debos/debos > * License : Apache-2.0 > Programming Lang: Go > Description : Debian OS builder > > debos Debian OS builder. debos is a tool to make creation of various > debian based os "images" simpler. While most other tools focus on > specific use-case, debos is more meant as a toolchain to make comon > actions trivial while providing enough rope to do whatever tweaking > that might be required behind the scene. > . > debos expects a yaml file as input, syntax description can be found > at: >https://godoc.org/github.com/go-debos/debos/actions > . > and examples are to be found at: >https://github.com/go-debos/debos-recipes Looking at the example, this tool look much like vmdb2. Compare https://github.com/go-debos/debos-recipes/blob/master/debian/arm64/imag e-rpi3/debimage-rpi3.yaml with https://github.com/larswirzenius/vmdb2/blob/master/simple.vmdb Both tools create a Debian OS and use a Jinja config which allows specifying individual steps. Can the forces be joined? -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 D - 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: https://www.profitbricks.de Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg
Re: ITP: debos -- Debian OS builder
On Thu, 2018-01-11 at 11:00 +0100, Benjamin Drung wrote: > Both tools create a Debian OS and use a Jinja config which allows > specifying individual steps. Can the forces be joined? One is in Go, one in Python. There's nothing similar in the code bases. I see no chance of "joining forces", nor much point.
Re: ITP: debos -- Debian OS builder
On Thu, Jan 11, 2018 at 12:33:31PM +0200, Lars Wirzenius wrote: > On Thu, 2018-01-11 at 11:00 +0100, Benjamin Drung wrote: > > Both tools create a Debian OS and use a Jinja config which allows > > specifying individual steps. Can the forces be joined? > > One is in Go, one in Python. There's nothing similar in the code bases. For 'debos' there is ITP #886772. For 'vmdb2' currently no ITP at https://bugs.debian.org/wnpp a.k.a. https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=wnpp;dist=unstable Groeten Geert Stappers -- Leven en laten leven
Re: enforcing an UTF8 locale while building a package
Simon McVittie wrote: > The reason I brought it up is that you mentioned detecting such bugs as > a reason to prefer not to force TZ=UTC for related packages' builds; > but if that makes a package's build fail, then it becomes "artificially" > RC, whether it would have been RC on its own merits or not. Just to be clear about the double-negatives here; setting TZ=UTC did not make the timezone library's testsuite to fail, but being on "Tokyo time" did. Release critical or not it's still a bug that surely needs fixing and playing severity wars in the BTS is, at best, just getting in the way of fixing it. I don't file issues automatically and exercise some judgement on their severity level depending on how tortured the required environment is and what the package actually is meant to do, etc. I'm not even certain I filed this one as RC which makes this conversation even more academic… :) Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Re: ITP: debos -- Debian OS builder
Am Donnerstag, den 11.01.2018, 12:33 +0200 schrieb Lars Wirzenius: > On Thu, 2018-01-11 at 11:00 +0100, Benjamin Drung wrote: > > Both tools create a Debian OS and use a Jinja config which allows > > specifying individual steps. Can the forces be joined? > > One is in Go, one in Python. There's nothing similar in the code > bases. > I see no chance of "joining forces", nor much point. >From the code base, you are right. But from the user perspective, they look the same. -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 D - 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: https://www.profitbricks.de Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg
Bug#886927: ITP: tlog -- Terminal I/O recording and playback package.
Package: wnpp Severity: wishlist Owner: Will Rouesnel * Package name: tlog Version : 3 Upstream Author : Nikolai Kondrashov * URL : http://scribery.github.io/tlog/ * License : GPL Programming Lang: C Description : Terminal I/O recording and playback package. tlog is a terminal I/O recording and playback package suitable for implementing centralized user session recording. At the moment it is not ready for production and is to be considered development preview quality. Whereas most other similar packages write the recorded data to a file in their own format, or upload it to a custom server, tlog sends it to a logging service. The standard syslog interface is supported already, with journald possibly to come. The recorded data is encoded in JSON in a way which keeps it human-readable and searchable as much as possible. - why is this package useful/relevant? Fulfills an enormous missing niche in practical systems monitoring and observation on Linux for modern systems. - how do you plan to maintain it? Packaging is intended to follow upstream closely while the software is in its pre-release state. Releases will be automated around CI builds.
alioth -> salsa: closing alioth services and redirecting
Hi, Moving repo to salsa and starting an alternative ML have been done. I am now wondering what is the best practice for closing alioth service when occasional diverse committers are involved. * How can I easily set up redirection service for incoming mails to an aioth ML forwarded to a new l.d.o address? * How to disable alioth ML sending out message to subscribers. (I have already informed subscribers about changes) * How can I make alioth git service as read only? My thought: 1. Remove all files and leave one README file explaining migration 2. Shell access to alioth and do something like "chmod -R ugo-w ." safe? (Or is there any clean and simple redirection service method?) * What to do with the weblate translation service? Pointer to an pertinent wiki page is appreciated. Osamu
[no subject]
Format: 1.8 Date: Fri, 01 Dec 2017 23:32:58 +0100 Source: tor Binary: tor tor-geoipdb Architecture: source Version: 0.3.1.9-1 Distribution: unstable Urgency: high Maintainer: Peter Palfrader Changed-By: Peter Palfrader Description: tor - anonymizing overlay network for TCP tor-geoipdb - GeoIP database for Tor Closes: 700179 882281 Changes: tor (0.3.1.9-1) unstable; urgency=high . * New upstream version, including among others: - Fix a denial of service bug where an attacker could use a malformed directory object to cause a Tor instance to pause while OpenSSL would try to read a passphrase from the terminal. (Tor instances run without a terminal, which is the case for most Tor packages, are not impacted.) Fixes bug 24246; bugfix on every version of Tor. Also tracked as TROVE-2017-011 and CVE-2017-8821. Found by OSS-Fuzz as testcase 6360145429790720. - Fix a denial of service issue where an attacker could crash a directory authority using a malformed router descriptor. Fixes bug 24245; bugfix on 0.2.9.4-alpha. Also tracked as TROVE-2017-010 and CVE-2017-8820. - When checking for replays in the INTRODUCE1 cell data for a (legacy) onion service, correctly detect replays in the RSA- encrypted part of the cell. We were previously checking for replays on the entire cell, but those can be circumvented due to the malleability of Tor's legacy hybrid encryption. This fix helps prevent a traffic confirmation attack. Fixes bug 24244; bugfix on 0.2.4.1-alpha. This issue is also tracked as TROVE-2017-009 and CVE-2017-8819. - Fix a use-after-free error that could crash v2 Tor onion services when they failed to open circuits while expiring introduction points. Fixes bug 24313; bugfix on 0.2.7.2-alpha. This issue is also tracked as TROVE-2017-013 and CVE-2017-8823. - When running as a relay, make sure that we never build a path through ourselves, even in the case where we have somehow lost the version of our descriptor appearing in the consensus. Fixes part of bug 21534; bugfix on 0.2.0.1-alpha. This issue is also tracked as TROVE-2017-012 and CVE-2017-8822. - When running as a relay, make sure that we never choose ourselves as a guard. Fixes part of bug 21534; bugfix on 0.3.0.1-alpha. This issue is also tracked as TROVE-2017-012 and CVE-2017-8822. * Build-depend on libcap-dev on linux-any so we can build tor with capabilities support to retain the capability to bind to low ports; closes: #882281, #700179. Checksums-Sha1: 8c132af553721ba81f0d2a297f5141f5b455435d 1824 tor_0.3.1.9-1.dsc 5d6d5f00691d35c782f9126b7ad70a678343a832 6092702 tor_0.3.1.9.orig.tar.gz 7b33ff16dfe470cc5bd3af53960a7ebc7204f415 48881 tor_0.3.1.9-1.diff.gz Checksums-Sha256: d767ca3b900a839b03083a0492c0e2d08ddf0bb15bf9323fd1280d1f115714d2 1824 tor_0.3.1.9-1.dsc 6e1b04f7890e782fd56014a0de5075e4ab29b52a35d8bca1f6b80c93f58f3d26 6092702 tor_0.3.1.9.orig.tar.gz dde9f4b63e0ec28d4d649988a494b0bb0e10897df2cb22268c9b2042f080d59f 48881 tor_0.3.1.9-1.diff.gz Files: 893c1b5715d321f859707836b2d00e61 1824 net optional tor_0.3.1.9-1.dsc 585e62d086ae7df7cd873f735d726118 6092702 net optional tor_0.3.1.9.orig.tar.gz 02e347d9a5e3bf1b8871dfd75eaa3d19 48881 net optional tor_0.3.1.9-1.diff.gz
Re: Bug#886927: ITP: tlog -- Terminal I/O recording and playback package.
On Thu, Jan 11, 2018 at 11:26:23PM +1100, Will Rouesnel wrote: > * Package name: tlog > Upstream Author : Nikolai Kondrashov > * URL : http://scribery.github.io/tlog/ > Description : Terminal I/O recording and playback package. > > tlog is a terminal I/O recording and playback package suitable for > implementing centralized user session recording. At the moment it is not > ready > for production and is to be considered development preview quality. > > Whereas most other similar packages write the recorded data to a file in > their > own format, or upload it to a custom server, tlog sends it to a logging > service. The standard syslog interface is supported already, with journald > possibly to come. The recorded data is encoded in JSON in a way which keeps > it > human-readable and searchable as much as possible. Yay, yet another incompatible format. For example, my termrec can convert between ttyrec, nh-recorder, dosrecorder, RealLogs -- and I bothered to implement only formats that see some use in the wild (which excludes eg. script -t, whose two-file unhandiness means no one uses it despite coming in an essential package). I haven't looked if Asciinema grown a local format when I wasn't looking, either. For example Nethack and Crawl communities have long since standardized on .ttyrec.bz2 (which means a convenient player must handle compression transparently). There's also a bunch of players which can handle ttyrecs: "ttyrec", termrec, three Perl thingies, ttyplayer, ipbt. As for remote services, there's termcast, Asciinema and others. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out, ⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the ⠈⠳⣄ sky. Your cat demands food. The priority should be obvious...
Effect of build profiles
On Jan 11 2018, Johannes Schauer wrote: > We can check whether two binary packages built with a different set of > build profiles active are actually the same by using the tools from > the reproducible builds project. Now I'm mightily confused. What's the point of build profiles if they result in identical binary packages? It seems to me in that case we could just always use the "simplest" build profile. I guess with "the same" you must mean something other than "bitwise identical" - but it's not clear to me what. Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: Effect of build profiles
Quoting Nikolaus Rath (2018-01-11 22:15:44) > On Jan 11 2018, Johannes Schauer wrote: > > We can check whether two binary packages built with a different set of > > build profiles active are actually the same by using the tools from > > the reproducible builds project. > Now I'm mightily confused. What's the point of build profiles if they result > in identical binary packages? It seems to me in that case we could just > always use the "simplest" build profile. > > I guess with "the same" you must mean something other than "bitwise > identical" - but it's not clear to me what. I must admit that I indeed have a hard time to formulate this in precise language. So let me instead use more simple words to explain this paragraph in a more verbose fashion. A source package can be built with zero or more build profiles active. Each binary package in debian/control can have a Build-Profiles field. The content of the field is a condition which must be fulfilled for the respective binary package to be built with a certain set (including the empty set) of build profiles active. For example: Package: python-foo Build-Profiles: This annotation means, that the python-foo package is generated all the time except when the "nopython" build profile is active during the source package build. What I meant to say above is: Independent with which set of build profiles we build this source package, every time python-foo ends up being generated, it has to be the exact same. So if we build this source package with "nodoc", then we generate python-foo and that binary package has to be the same as when we build the source package with "nocheck". So I did not mean to say that the set of binary packages that is built must be the same independent of which set of profiles is active. But if a binary package is built under two different sets of build profiles (including the empty set) then its contents must be the same. I hope this clears things up! Thanks! cheers, josch signature.asc Description: signature
Work-needing packages report for Jan 12, 2018
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: 1163 (new: 3) Total number of packages offered up for adoption: 148 (new: 2) Total number of packages requested help for: 50 (new: 2) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: arno-iptables-firewall (#886951), orphaned today Description: single- and multi-homed firewall script with DSL/ADSL support Installations reported by Popcon: 468 Bug Report URL: http://bugs.debian.org/886951 cadvisor (#886740), orphaned 2 days ago Description: analyze resource usage and performance characteristics of running containers Installations reported by Popcon: 14 Bug Report URL: http://bugs.debian.org/886740 kubernetes (#886739), orphaned 2 days ago Description: Container Cluster Manager Installations reported by Popcon: 44 Bug Report URL: http://bugs.debian.org/886739 1160 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: coccinelle (#886679), offered 3 days ago Description: semantic patching tool for C Installations reported by Popcon: 116 Bug Report URL: http://bugs.debian.org/886679 jcommander (#886553), offered 4 days ago Reverse Depends: procyon-decompiler testng Installations reported by Popcon: 5541 Bug Report URL: http://bugs.debian.org/886553 146 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] broadcom-sta (#886599), requested 3 days ago (non-free) Description: Broadcom STA Wireless driver (non-free) Installations reported by Popcon: 1954 Bug Report URL: http://bugs.debian.org/886599 [NEW] ed (#886643), requested 3 days ago Description: classic UNIX line editor Reverse Depends: apt-cacher debbugs opensmtpd sn Installations reported by Popcon: 23625 Bug Report URL: http://bugs.debian.org/886643 autopkgtest (#846328), requested 407 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker openstack-pkg-tools Installations reported by Popcon: 1064 Bug Report URL: http://bugs.debian.org/846328 balsa (#642906), requested 2300 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 651 Bug Report URL: http://bugs.debian.org/642906 cargo (#860116), requested 275 days ago Description: Rust package manager Reverse Depends: dh-cargo Installations reported by Popcon: 561 Bug Report URL: http://bugs.debian.org/860116 cups (#532097), requested 3141 days ago Description: Common UNIX Printing System Reverse Depends: ayatana-indicator-printers bluez-cups boomaga chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd (69 more omitted) Installations reported by Popcon: 174599 Bug Report URL: http://bugs.debian.org/532097 cyrus-sasl2 (#799864), requested 841 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli autofs-ldap cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier claws-mail-address-keeper claws-mail-archiver-plugin (124 more omitted) Installations reported by Popcon: 196022 Bug Report URL: http://bugs.debian.org/799864 dee (#831388), requested 545 days ago Description: model to synchronize mutiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-1.0-4-dbg libdee-dev zeitgeist-core Installations reported by Popcon: 62182 Bug Report URL: http://bugs.debian.org/831388 developers-reference (#759995), requested 1230 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 14155 Bug Report URL: http://bugs.debian.org/759995 devscripts (#800413), requested 835 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero brz-debian bzr-builddeb customdeb debci debian-builder debmake (27 more omitted) Installations reported by Popcon: 12907 Bug Report URL: http://bugs.debian.org/800413 ejabberd (#767874), requested 1165 days ago Description: distribute
Question about dpkg-maintscript-helper dir_to_symlink, prior-version, and backports
Hi, I have a question. Let's say I have a package performing a dir_to_symlink conversion from version 2.0, so I specify "prior-version" as 2.0~. Now let's say that I backport version 3 to Wheezy, whose version of dpkg-maintscript-helper doesn't support dir_to_symlink, so I remove the call to dpkg-mainscript-helper. So now my Wheezy has version 3.0~bpo7+1 of the package, and the directory is still a directory and not a symbolic link. That's okay. Now, let's say I upgrade this system to Jessie. Since the package will be upgraded from 3.0~bpo7+1 to 3.0, and the call to dpkg-maintscript-helper specifies 2.0~ as the prior-version, what will happen ? I guess the conversion won't be performed, but what happens after that ? I fear the directory would be left in a inconsistent state. Is there a method to make this package upgrade cleanly ? I guess, don't specify a prior-version at all ? But in that case, the conversion would be tried on every upgrade, which is discouraged by the manual page. Any advice about this ? Thanks. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Re: Why do we list individual copyright holders?
On Wed, 2018-01-10 at 00:11 +0200, Adrian Bunk wrote: [...] > src:linux, where complete authorship information is often not easily > available [1] and copyright ownership information is in many cases not > available at all [2], would actually be a good litmus test for what > requirements are workable in practice. With the Linux Foundation behind > the kernel and lawsuits around kernel copyright already taken place, > there should also be plenty of lawyer opinion available and implemented > regarding what copyright information is actually required in the real > world for (corporate) users worldwide. It's worth noting that Linux recently gained SPDX tags indicating the licence of (almost) every source file in Linux. But I'm not aware of any work to list all the copyright holders. (The only times I've heard people talk about tracing all the copyright holders, is in the context of proposed relicensing.) > A new debian/copyright for src:linux could also be a good example > to be published together with the documentation of this policy to > make it clear what copyright information the ftp team requires > from non-trivial packages. [...] I have been meaning to look at regenerating debian/copyright based on the SPDX tags, and possibly sending corrections upstream based on the current content. But that's all. Ben. -- Ben Hutchings If you seem to know what you are doing, you'll be given more to do. signature.asc Description: This is a digitally signed message part
Bug#886981: ITP: tcl8.7 -- Tcl (the Tool Command Language) v8.7
Package: wnpp Severity: wishlist Owner: Sergei Golovan * Package name: tcl8.7 Version : 8.7a1 Upstream Author : Tcl Core Team * URL : http://www.tcl.tk/ * License : BSD Programming Lang: C, Tcl Description : Tcl (the Tool Command Language) v8.7 Tcl is a powerful, easy-to-use, embeddable, cross-platform interpreted scripting language. It's a new upstream release with some incompatibilities with the earlier ones (8.6, 8.5), so it's traditionally packaged separately. The package will be maintained under the Debian Tcl/Tk team. Version 8.7 is in alpha stage yet, so I intend to upload it to experimental at the moment.
Bug#886982: ITP: tk8.7 -- Tk toolkit for Tcl and X11, v8.7
Package: wnpp Severity: wishlist Owner: Sergei Golovan * Package name: tk8.7 Version : 8.7a1 Upstream Author : Tcl Core Team * URL : http://www.tcl.tk/ * License : BSD Programming Lang: C, Tcl Description : Tk toolkit for Tcl and X11, v8.7 Tk is a cross-platform graphical toolkit which provides the Motif look-and-feel and is implemented using the Tcl scripting language. This is a new upstream release with some potential incompatibilities with the older ones, so it's as usual packaged separately. The package will be maintained under Debian Tcl/Tk team. Version 8.7 is in alpha stage yet, so I'm planning to upload this package to experimental.
Re: Bug#886927: ITP: tlog -- Terminal I/O recording and playback package.
On 11 January 2018 at 21:41, Adam Borowski wrote:
> On Thu, Jan 11, 2018 at 11:26:23PM +1100, Will Rouesnel wrote:
>> * Package name: tlog
>> Upstream Author : Nikolai Kondrashov
>> * URL : http://scribery.github.io/tlog/
>> Description : Terminal I/O recording and playback package.
>>
>> tlog is a terminal I/O recording and playback package suitable for
>> implementing centralized user session recording. At the moment it is not
>> ready
>> for production and is to be considered development preview quality.
>>
>> Whereas most other similar packages write the recorded data to a file in
>> their
>> own format, or upload it to a custom server, tlog sends it to a logging
>> service. The standard syslog interface is supported already, with journald
>> possibly to come. The recorded data is encoded in JSON in a way which keeps
>> it
>> human-readable and searchable as much as possible.
>
> Yay, yet another incompatible format.
>
> For example, my termrec can convert between ttyrec, nh-recorder,
> dosrecorder, RealLogs -- and I bothered to implement only formats that see
> some use in the wild (which excludes eg. script -t, whose two-file
> unhandiness means no one uses it despite coming in an essential package).
> I haven't looked if Asciinema grown a local format when I wasn't looking,
> either.
Asciinema does, indeed, have a local format, JSON-based:
{
"command": null,
"height": 22,
"title": "demo",
"duration": 37.608602,
"stdout": [
[
0.061412,
"\u001b]0;\u0007$ "
],
…
]
],
"version": 1,
"width": 80,
"env": {
"SHELL": "/bin/bash",
"TERM": "xterm-256color"
}
}
--
Cheers,
Andrew
