OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/17/2015 03:13 AM, NP-Hardass wrote: > Additionally, I feel that a signature is a means of acknowledging > that a package has been looked over, and that developer has stated > that they approve of the existing state. I'm not sure if others > agree with that sentiment, I appreciate that you bring up this point. I would expect that part of that state is for the developer to verify the source distfile from upstream using OpenPGP / GnuPG as well, i.e not just rely on TOFU (trust on first use). This also means keeping a (locally) certified copy of the upstream distribution key that is reasonably verified by the developer. - -- Kristian Fiskerstrand Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJVqLpCAAoJECULev7WN52FtmYH/3ySS/fM62KcRyxHrfDswNzA sL0lj43JxWAwCcPI46X8ag7nUBYwuo/x9E6IDQotAe1MoiV3vPGLIDugrCHIE0Ai AxVKhPwCXFDxtNwSKDIxiaupssLSt9uLB5rCMP+eJoFl3wiQb7rI4ly/qXE2DI6O U6sLABiq/7nmRSsCzakyNionknSU60HLo3V1o8/KdoyBfaup9FsHdFYMZmbn+w0T 0Rv2FJV6z0BsjmaOJQ4qCrOqtcNLnrUaXGdRm153LfAWoWiBMhM/mlOsDk73j4zw NtMSJpKbfIHsNrF8d9c6xrni5zlmaEjGoeQKSVJILEwO4ROnUKh2M1LwOiTkhzo= =bVWz -END PGP SIGNATURE-
Re: OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests)
On 07/17/2015 10:18 AM, Kristian Fiskerstrand wrote: > On 07/17/2015 03:13 AM, NP-Hardass wrote: > >> Additionally, I feel that a signature is a means of acknowledging >> that a package has been looked over, and that developer has stated >> that they approve of the existing state. I'm not sure if others >> agree with that sentiment, > > I appreciate that you bring up this point. I would expect that part of > that state is for the developer to verify the source distfile from > upstream using OpenPGP / GnuPG as well, i.e not just rely on TOFU > (trust on first use). This also means keeping a (locally) certified > copy of the upstream distribution key that is reasonably verified by > the developer. > This really depends. In general, a signed commit can and should only say that the _patch_ comes from or was approved by a particular person. If it's a version bump on a single package, you can probably assume that he had a rough lookover. But you can't expect the same when e.g. the python herd has to do mass commits because of USE flag changes. That "approve of existing state" thing is rather implicit in a review workflow, where the package maintainer does the merge. We currently don't have any plans to enforce this globally, so signatures just say "this patch comes from...".
Re: OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/17/2015 11:48 AM, hasufell wrote: > On 07/17/2015 10:18 AM, Kristian Fiskerstrand wrote: >> On 07/17/2015 03:13 AM, NP-Hardass wrote: >> >>> Additionally, I feel that a signature is a means of >>> acknowledging that a package has been looked over, and that >>> developer has stated that they approve of the existing state. >>> I'm not sure if others agree with that sentiment, >> >> I appreciate that you bring up this point. I would expect that >> part of that state is for the developer to verify the source >> distfile from upstream using OpenPGP / GnuPG as well, i.e not >> just rely on TOFU (trust on first use). This also means keeping a >> (locally) certified copy of the upstream distribution key that is >> reasonably verified by the developer. >> > > This really depends. In general, a signed commit can and should > only say that the _patch_ comes from or was approved by a > particular person. If it's a version bump on a single package, you > can probably assume that he had a rough lookover. But you can't > expect the same when e.g. the python herd has to do mass commits > because of USE flag changes. > I was referring to process during a version bump, the manifest entry for the distfile shouldn't be changed during a USE flag change, so in this case that verification would be brought along from the developer doing the bump. > That "approve of existing state" thing is rather implicit in a > review workflow, where the package maintainer does the merge. We > currently don't have any plans to enforce this globally, so > signatures just say "this patch comes from...". Not all do, as mentioned the push can be signed, e.g while an individual commit is signed by another (potentially a non-gentoo-dev). All I'm trying to say is really (and this isn't specific to the git workflow); Please take it as a reminder to verify upstream OpenPGP signatures when bumping packages, and please make an effort to maintain proper key management practices while doing so so you can do it properly. If we don't we have a case of purgamentum init, exit purgamentum (garbagin in, garbage out) - -- Kristian Fiskerstrand Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJVqNEnAAoJECULev7WN52FohUIAIQrKGb7urSmzWFyIfF00FSr i+arpIMbClzyUf6fwulf22fkE0UjBykoodA6p67dxakgWOEpHkpoUW7Z3v8eyPu8 +UHzV67sNgoEnJW4PASyrOABMkpi5oHr2nGSq6oHwHG5oXnw9askEH8srThBTwNx Kflo4mzxSpbgIrbfawFERWPBTtwU1P1WLAVSKRz6GkPAKuY/ypjMeFJ2TSdPeapR TYLhgSUa/3gUOZx7OBJpYxqU2j7WOnGwxMsReJVnMykB4LOv7SRXzXSM+6r0Q+os bWv2wKUfOPwoOCMD+F0nIFZ/85T7wSiZxemM5T85+FFL6xl4hXgZr8GUwJU9iB4= =NylE -END PGP SIGNATURE-
[gentoo-dev] Any deptree stabilization/keywording path finder?
Hello, TL;DR Is there any tool to build dependency tree for all packages needed to be stabilized (or keyworded) in order stabilize (keyword) foo/bar? Sometimes in order to stabilize a single version bump a whole lot of packages needs to be stabilized as dependencies. A good example is [1]. What I really need here is to stabilize dev-haskell/pandoc-siteproc (I don't even care about exact version, since any version looks ok for app-doc/root-docs), but this triggers a whole lot of haskell packages to be stabilized. There are several issues here: 1. There are many solutions for this issue, since version requirements usually allow some range of versions. Looks like this is a classical graph path finding task. It would be great to have a tool for best effort solution: e.g. for a tree with minimal number of dependencies of with most recent packages possible (for those which are in the tree for at least 30 days). 2. It is very tedious to build such dependency tree manually (this is how it was done in [1]). To make it worse such work is error-prone, because it is near to impossible to check that each stabilization in the dependency tree will not trigger any blocker in the whole portage tree. Actually at least one such error was made [2]. The best that can be done by hand is to verify that the stabilization dependency tree is self-consistent, but even this check requires a lot of time and effort. All these problems should be solvable with an appropriate tool, but I can't find such tool. Apparently it should inherit some of emerge and repoman functionality for deptree building and checking respectively. Any ideas? I suppose arch teams should have something similar for their goals. P.S. Note for the record: I filed a lot of stabilization request for dev-haskell/* packaged I do not maintain, because haskell team had not responded in a reasonable amount of time for my stable request [3]. I'm not blaming anyone here, just explaining why such action was taken. [1] https://bugs.gentoo.org/showdependencytree.cgi?id=529538&hide_resolved=0 [2] https://bugs.gentoo.org/show_bug.cgi?id=552388 [3] https://bugs.gentoo.org/show_bug.cgi?id=546260 Best regards, Andrew Savchenko pgpC9sdzKQcPH.pgp Description: PGP signature
Re: [gentoo-dev] Any deptree stabilization/keywording path finder?
On Fri, Jul 17, 2015 at 01:15:53PM +0300, Andrew Savchenko wrote: > Hello, > > TL;DR Is there any tool to build dependency tree for all packages > needed to be stabilized (or keyworded) in order stabilize (keyword) > foo/bar? gnome team has this, its pretty good and has a --check-dependencies too. Gilles has done a bunch of cleanups on it but not merged back in yet. https://gitweb.gentoo.org/proj/gnome.git/tree/scripts/gen_archlist.py?h=gen_archlist_cleanup > > Sometimes in order to stabilize a single version bump a whole lot > of packages needs to be stabilized as dependencies. A good example > is [1]. What I really need here is to stabilize > dev-haskell/pandoc-siteproc (I don't even care about exact version, > since any version looks ok for app-doc/root-docs), but this > triggers a whole lot of haskell packages to be stabilized. There > are several issues here: > > 1. There are many solutions for this issue, since version > requirements usually allow some range of versions. Looks like this > is a classical graph path finding task. It would be great to have a > tool for best effort solution: e.g. for a tree with minimal number > of dependencies of with most recent packages possible (for those > which are in the tree for at least 30 days). it does not check this yet tho, but thats not too bad i suppose. > > 2. It is very tedious to build such dependency tree manually (this > is how it was done in [1]). To make it worse such work is > error-prone, because it is near to impossible to check that each > stabilization in the dependency tree will not trigger any blocker > in the whole portage tree. Actually at least one such error was made > [2]. The best that can be done by hand is to verify that the > stabilization dependency tree is self-consistent, but even this > check requires a lot of time and effort. > > All these problems should be solvable with an appropriate tool, but > I can't find such tool. Apparently it should inherit some of emerge > and repoman functionality for deptree building and checking > respectively. > > Any ideas? I suppose arch teams should have something similar for > their goals. > > P.S. Note for the record: I filed a lot of stabilization request > for dev-haskell/* packaged I do not maintain, because haskell team > had not responded in a reasonable amount of time for my stable > request [3]. I'm not blaming anyone here, just explaining why such > action was taken. > > [1] https://bugs.gentoo.org/showdependencytree.cgi?id=529538&hide_resolved=0 > [2] https://bugs.gentoo.org/show_bug.cgi?id=552388 > [3] https://bugs.gentoo.org/show_bug.cgi?id=546260 > > Best regards, > Andrew Savchenko
Verification of installed packages (was Re: OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests))
Hi, On Fri, 17 Jul 2015 10:18:14 +0200 Kristian Fiskerstrand wrote: > > Additionally, I feel that a signature is a means of acknowledging > > that a package has been looked over, and that developer has stated > > that they approve of the existing state. I'm not sure if others > > agree with that sentiment, > > I appreciate that you bring up this point. I would expect that part of > that state is for the developer to verify the source distfile from > upstream using OpenPGP / GnuPG as well, i.e not just rely on TOFU > (trust on first use). This also means keeping a (locally) certified > copy of the upstream distribution key that is reasonably verified by > the developer. Let me point another issue related to discussion above. It would be nice to have cryptographic verification of already installed packages. This will help in forensics and security audit of the systems, so that even without external snapshot of the system it will be possible to check for malicious changes of installed packages. Right now we have /var/db/pkg/$cat/$name/CONTENTS file with such data, but: 1. It uses md5 for file checksums. 2. It is not signed. So my proposal is: 1. Switch to more cryptographically secure hash (e.g. sha512 or whirlpool). 2. Add an optional feature to emerge (or even to PMS?) allowing user to provide a usable GPG key for signing packages CONTENTS files after its generation. In order for such key to be usable during emerge run, gpg-agent should be used; alternatively it may be allowed to sign already installed packages on a trusted system. 3. Of course backward compatibility with old CONTENTS format should be kept. This proposal is not my own whim: I have requests from users for such functionality which is quite wanted on production setups. Best regards, Andrew Savchenko pgp4K_suNHEWK.pgp Description: PGP signature
Re: Verification of installed packages (was Re: OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests))
On 17 July 2015 at 22:34, Andrew Savchenko wrote: > 2. Add an optional feature to emerge (or even to PMS?) allowing user > to provide a usable GPG key for signing packages CONTENTS files > after its generation. In order for such key to be usable during > emerge run, gpg-agent should be used; alternatively it may be > allowed to sign already installed packages on a trusted system. > 3. Of course backward compatibility with old CONTENTS format should > be kept. To keep things simple, I'd suggest storing the signature externally to the CONTENTS file. This would be more convenient for any tools that are trying to scrape the CONTENTS files with regex/grep not needing to first unwrap them. ( Not to mention trivial to determine which packages have signatures without needing to actually read the files ) Though, seeing we're going down this road, you could sign the whole vdb dir. -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Any deptree stabilization/keywording path finder?
Hi, On Fri, 17 Jul 2015 14:22:23 +0400 Jason Zaman wrote: > On Fri, Jul 17, 2015 at 01:15:53PM +0300, Andrew Savchenko wrote: > > Hello, > > > > TL;DR Is there any tool to build dependency tree for all packages > > needed to be stabilized (or keyworded) in order stabilize (keyword) > > foo/bar? > > gnome team has this, its pretty good and has a --check-dependencies too. > Gilles has done a bunch of cleanups on it but not merged back in yet. > https://gitweb.gentoo.org/proj/gnome.git/tree/scripts/gen_archlist.py?h=gen_archlist_cleanup Thanks, it helps a lot. Any way to get output in form of tree and not a list? Now I have a list of packages to be stabilized, but still have to figure out dependencies between them in order to file stabilization requests properly. In the ideal world I'd like to write some script to submit this bunch of stabilization request bugs using www-cient/pybugz. Any way to have this tool somewhere in app-portage/gentoolkit-dev (or other package) so that all devs may benefit from it? Best regards, Andrew Savchenko pgpNodf8OBdz4.pgp Description: PGP signature
Re: [gentoo-dev] Git, GPG Signing, and Manifests
On Fri, Jul 17, 2015 at 12:42 AM, Brian Dolbec wrote:
>
> I don't know tbh, most are already signed, with the git migration, the
> strongly recommended commit signing will become MANDATORY.
>
> So, we are at 50 devs with valid gpg keys now, with 200 more gpg keys
> listed in LDAP that fail to meet the new spec. PLEASE fix them or
> create new keys...
How does somebody know whether their key meets the spec or not? I
looked at the gentoo-keys website and didn't see any simple way to
check.
There was documentation on the gkeys utility for checking keys, but I
ran into a few issues with this. First, it can't be installed on a
stable system with mirrorselect.
On a clean ~arch stage3 when trying to run "gkeys fetch-seed -C
gentoo-devs" it outputs:
Connector.connect_url(); Failed to retrieve the content from:
https://api.gentoo.org/gentoo-keys/seeds/gentoo-devs.seeds
Error was: Invalid header value 'Wed, 15 Jul 2015 17:50:17 GMT\n'
After removing the files in /var/lib/gentoo/gkeys/seeds the fetch
works. However, attempting to run "gkeys install-key -C gentoo-devs"
results in:
Found GKEY seeds:
Traceback (most recent call last):
File "/usr/lib/python-exec/python2.7/gkeys", line 50, in
success = main()
File "/usr/lib64/python2.7/site-packages/gkeys/cli.py", line 63, in __call__
return self.run(args)
File "/usr/lib64/python2.7/site-packages/gkeys/base.py", line 303, in run
success, results = func(args)
File "/usr/lib64/python2.7/site-packages/gkeys/actions.py", line
264, in installkey
self.output(['', gkey], "\n Found GKEY seeds:")
File "/usr/lib64/python2.7/site-packages/gkeys/base.py", line 323,
in output_results
print("\n".join([x.pretty_print for x in msg]))
UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in
position 1233: ordinal not in range(128)
It might not hurt to publish the list of keys that fail checks. If
that list is going to be used to block commits then obviously it needs
to be updated very frequently. I do not know if there are any plans
to block commits with signatures that do not conform to the GLEP.
--
Rich
Re: [gentoo-dev] Git, GPG Signing, and Manifests
On 17 July 2015 at 15:36, Rich Freeman wrote: > On Fri, Jul 17, 2015 at 12:42 AM, Brian Dolbec wrote: >> >> I don't know tbh, most are already signed, with the git migration, the >> strongly recommended commit signing will become MANDATORY. >> >> So, we are at 50 devs with valid gpg keys now, with 200 more gpg keys >> listed in LDAP that fail to meet the new spec. PLEASE fix them or >> create new keys... > > How does somebody know whether their key meets the spec or not? I > looked at the gentoo-keys website and didn't see any simple way to > check. > > There was documentation on the gkeys utility for checking keys, but I > ran into a few issues with this. First, it can't be installed on a > stable system with mirrorselect. The use of keys should be by counter signature, when pushing the counter signature service should check if signature is valid and dev key is valid using the internal ldap for example, and counter sign with its own key and add timestamp. Users should trust only the counter signature service key which is formal and should be valid for long time. This is yet another reason why it is best to not use signature within git but remain the signed manifest. When commit one can sign the manifest, send the manifest to the counter signature service and obtain a formal signed manifest to be committed into tree. Using signed manifest also reduce the merge conflict, survive rebase, enable code review without loosing original signer and will enable future migration to other technology. Regards, Alon
Re: [gentoo-dev] Git, GPG Signing, and Manifests
On Fri, Jul 17, 2015 at 8:36 AM, Rich Freeman wrote: > On Fri, Jul 17, 2015 at 12:42 AM, Brian Dolbec wrote: >> >> I don't know tbh, most are already signed, with the git migration, the >> strongly recommended commit signing will become MANDATORY. >> >> So, we are at 50 devs with valid gpg keys now, with 200 more gpg keys >> listed in LDAP that fail to meet the new spec. PLEASE fix them or >> create new keys... > > How does somebody know whether their key meets the spec or not? I > looked at the gentoo-keys website and didn't see any simple way to > check. > > There was documentation on the gkeys utility for checking keys, but I > ran into a few issues with this. > After waking up a bit more I configured a utf8 locale in my "clean stage3" and the errors went away, and I was able to verify that my key passed, with no encryption subkey (I don't intend to use this key for anything but gentoo main repository signing). Even so, it might not hurt to have a one-line way to check an arbitrary gpg key for conformity by ID. Otherwise we invite trial and error with devs uploading what they hope are compliant keys, fixing LDAP, waiting for seeds to be repopulated, then checking them. -- Rich
Re: [gentoo-dev] Git, GPG Signing, and Manifests
On Fri, 17 Jul 2015 08:36:25 -0400
Rich Freeman wrote:
> On Fri, Jul 17, 2015 at 12:42 AM, Brian Dolbec
> wrote:
> >
> > I don't know tbh, most are already signed, with the git migration,
> > the strongly recommended commit signing will become MANDATORY.
> >
> > So, we are at 50 devs with valid gpg keys now, with 200 more gpg
> > keys listed in LDAP that fail to meet the new spec. PLEASE fix
> > them or create new keys...
>
> How does somebody know whether their key meets the spec or not? I
> looked at the gentoo-keys website and didn't see any simple way to
> check.
>
> There was documentation on the gkeys utility for checking keys, but I
> ran into a few issues with this. First, it can't be installed on a
> stable system with mirrorselect.
>
> On a clean ~arch stage3 when trying to run "gkeys fetch-seed -C
> gentoo-devs" it outputs:
> Connector.connect_url(); Failed to retrieve the content from:
> https://api.gentoo.org/gentoo-keys/seeds/gentoo-devs.seeds
> Error was: Invalid header value 'Wed, 15 Jul 2015 17:50:17 GMT\n'
>
>
> After removing the files in /var/lib/gentoo/gkeys/seeds the fetch
> works. However, attempting to run "gkeys install-key -C gentoo-devs"
> results in:
> Found GKEY seeds:
> Traceback (most recent call last):
> File "/usr/lib/python-exec/python2.7/gkeys", line 50, in
> success = main()
> File "/usr/lib64/python2.7/site-packages/gkeys/cli.py", line 63, in
> __call__ return self.run(args)
> File "/usr/lib64/python2.7/site-packages/gkeys/base.py", line 303,
> in run success, results = func(args)
> File "/usr/lib64/python2.7/site-packages/gkeys/actions.py", line
> 264, in installkey
> self.output(['', gkey], "\n Found GKEY seeds:")
> File "/usr/lib64/python2.7/site-packages/gkeys/base.py", line 323,
> in output_results
> print("\n".join([x.pretty_print for x in msg]))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in
> position 1233: ordinal not in range(128)
>
>
Yes, the ssl-fetch issue is fixed with ssl-fetch-0.3 and it is now
stabilized. So that conflict is fixed.
> It might not hurt to publish the list of keys that fail checks. If
> that list is going to be used to block commits then obviously it needs
> to be updated very frequently. I do not know if there are any plans
> to block commits with signatures that do not conform to the GLEP.
>
Yeah, I was thinking of putting up a gkeys spec-check report, but we
were (unsuccessfully) trying to get more wiki pages help done on how to
fix those issues reported. Before we did such a report. Also I need
to make another release, currently gkeys- and gkeys-gen-999 is the
best option with the most fixes, best functionality. Hopefully I'll
get those release this weekend.
--
Brian Dolbec
Re: [gentoo-dev] Git, GPG Signing, and Manifests
On Fri, 17 Jul 2015 08:50:43 -0400 Rich Freeman wrote: > On Fri, Jul 17, 2015 at 8:36 AM, Rich Freeman > wrote: > > On Fri, Jul 17, 2015 at 12:42 AM, Brian Dolbec > > wrote: > >> > >> I don't know tbh, most are already signed, with the git migration, > >> the strongly recommended commit signing will become MANDATORY. > >> > >> So, we are at 50 devs with valid gpg keys now, with 200 more gpg > >> keys listed in LDAP that fail to meet the new spec. PLEASE fix > >> them or create new keys... > > > > How does somebody know whether their key meets the spec or not? I > > looked at the gentoo-keys website and didn't see any simple way to > > check. > > > > There was documentation on the gkeys utility for checking keys, but > > I ran into a few issues with this. > > > > After waking up a bit more I configured a utf8 locale in my "clean > stage3" and the errors went away, and I was able to verify that my key > passed, with no encryption subkey (I don't intend to use this key for > anything but gentoo main repository signing). > > Even so, it might not hurt to have a one-line way to check an > arbitrary gpg key for conformity by ID. Otherwise we invite trial and > error with devs uploading what they hope are compliant keys, fixing > LDAP, waiting for seeds to be repopulated, then checking them. > One of the things I really wanted to get into gkeys is a way to add a users ~/.gnupg dir imported into the gkeys system, that will help in that reagrds and make it more of a one stop shop for common gpg tasks. Also, I will try to get at least the gkeys-gen target keydir added to gkeys visibility in the next release. Oh, forgot to mention. I will send the gkeys spec-check report to the gentoo-core list for a start. Perhaps some of the devs can help us get the wiki help pages completed when they fix their keys and know the steps. I'm sure both Kristian and myself would appreciate a little help with that while we are explaining how to fix the failures. One of the slowdowns in completing those pages is creating anomymous gpg keys output for the wiki examples. I do not want to use devs real keys as examples (which of course would be easiest). -- Brian Dolbec
[gentoo-dev] [RFC] News item about mysql client and server packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Title: MySQL client libraries and server packaging changes Author: Brian Evans Content-Type: text/plain Posted: 2015-07-17 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: virtual/mysql The future of the mysql packages is changing. First off, a new virtual is being introduced, virtual/libmysqlclient. virtual/mysql will represent the server and tools while virtual/libmysqlclient will represent the shared and static libraries. Developers and ebuild writers should reference virtual/libmysqlclient when linking against the libraries as the package will keep the subslot the same as the soversion for easy rebuilds. This is getting more difficult in the current virtual situation as MySQL and MariaDB start to diverge versions and features. The old method could force users to mask new versions or delay the posting of one server package which advances the soversion until the others catch up. As for the server packages themselves, the minimal USE is being replaced. The new USE flags are client-libs, +server, and +tools. The server and tools flags are on by default to signify the primary purpose of those builds. The primary provider for libraries will be a new package dev-db/mysql-connector-c. A tinderbox run did not turn up any issues, but packagers are permitted to block any provider of virtual/libmysqlclient that does not work correctly. A comment in the ebuild would be helpful to track this. The server packages can still provide libraries if the client-libs USE is enabled. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQIcBAEBAgAGBQJVqUGzAAoJENH3ge/59KO22R4P/0ejDl6NQ6+ZP7RjbA23yjcb +R0GVSL6ibO42di3dcjIGBgsehlzIqFqk+bcRocvX8wk8k5aZgc+pjjYkPQ3mXc6 x/CFE8q3JkUVZOUK25rtO6jnats4zwQ1o6KpvgXfdwRTvY0nN7EU6Ee01QveSKc4 ZGZA7t4cFrAhfNdhUb6rt8iaI/PddbEXKErbfdAklGYHnDLs9+LR0aANIW5TJNWR fUtpgbqbZe/TjOQQMrbKHeZxQ38NJANqVNX2K/yVc0wH3WKsZUmFH7Pz3M9wtBOi 06GVk7vx+/7pXA/rK/H0jxTObH7UFdO6/2Y5j8DdViQVLSYEAv2/N1gtyfoRWeBo brX2OSwxKkGpnuA/5Vf0vKyf9wJ0VLL76jqzbmxEzHzOsN3GKGpudSIFASTsv4uz jZMLCdVXy3/VDVhLojMJGvA2exGjiuq9MY8eJsgZzy69aG658YZMtEvW6v++QWW1 JWKCszypy3OXJzkLP0OsvcYvQzpp4QAxCS4WmI0rBDasjrfB371MPtqprd7EgRn9 xIpYHQ8b6MZ+dQbLtHKf7jROgsc115sBMKbiZtBW8dbUgMRqM3EtV2kMDUNl9b3V GgirafjP/1z4AYM9M0W6q9d2rnI8jMXLZY3ySQ7HSamXunJAjGHqXKOoaZLQUiWR 1UsLxiGWSXuTWPAcmSjw =orFZ -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] News item about mysql client and server packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/17/2015 01:56 PM, Brian Evans wrote: > Title: MySQL client libraries and server packaging changes Author: > Brian Evans Content-Type: text/plain Posted: > 2015-07-17 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: > virtual/mysql > > The future of the mysql packages is changing. > > First off, a new virtual is being introduced, > virtual/libmysqlclient. virtual/mysql will represent the server and > tools while virtual/libmysqlclient will represent the shared and > static libraries. > > Developers and ebuild writers should reference > virtual/libmysqlclient when linking against the libraries as the > package will keep the subslot the same as the soversion for easy > rebuilds. This is getting more difficult in the current virtual > situation as MySQL and MariaDB start to diverge versions and > features. The old method could force users to mask new versions or > delay the posting of one server package which advances the > soversion until the others catch up. > > As for the server packages themselves, the minimal USE is being > replaced. The new USE flags are client-libs, +server, and +tools. > The server and tools flags are on by default to signify the > primary purpose of those builds. > > The primary provider for libraries will be a new package > dev-db/mysql-connector-c. A tinderbox run did not turn up any > issues, but packagers are permitted to block any provider of > virtual/libmysqlclient that does not work correctly. A comment in > the ebuild would be helpful to track this. The server packages can > still provide libraries if the client-libs USE is enabled. > It's my understanding that news items are geared to end users, however, this may be incorrect. Assuming that is the case, apart from notifying the users about the USE flag changes, the bulk of this news item is geared toward devs and package maintainers. As such, I feel like the user relevant content might go unnoticed as they skim and see it is primarily maintainer related. Apologies for the weird mail issue. I got rid of the cron plugin, but it is still acting up, so I'm switching back to claws mail from thunderbird. - -- NP-Hardass -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJVqUO4AAoJEBzZQR2yrxj7KxEP/jJgo0HPs3t3cTaThswt8/eV gJGWyaelKeQNQ34QrI4YxnLsZgQHNdAqo0qsbvpxKMNW1wZUHIhfZH4g562h8sJi 7eUilmn1TZdbQu/gOqV3Z3AECpyxc/SVZMTkOdfbBrDkoAmZpNYp1Jmr+rx01THs ZqmXcD+JkO3p6KOAXbnU2v5Gv74AKLXCwaKslUf9ewMH2iYcDnSivo4nmfNZCAsi t7bYYpEjb0Y2pjUDwAYyELsGABRN2nSircYiXVeGxpnuYJF3/0xLySrPAWEySPHE ucMaCB5fnz/vpSVzRciAQhFb0w/y1zHBlGa82aYPRl++cmaw53HvF88TfmAzRdJ6 iD9BdER1KpM1wERUhypstENmAxvLYxHdT7P/+vId+D5cFmIiN1N9JM61yg/4A2+Q ScGeQuCZkme+qqvvybD4KjVsP9fN+Oj2kMhKpLsVbnmLbxbM+rnAkgChxbEy3wzf Z0HM0HviwKSWqjN7E9Eanc2UKYpuujODd8/++cvnVRkrGJqjfDO39Pgi4nSVoCis +QzsFhr5Mi0k96naBNY5fFgDoSvFy/qJyN62NJEL0dFo4UxhJ4j7ul72+viQsGD9 eIuopVZVHSm4qnwkUwrwUdln9HRMSKI4t5iWOZZBxbTjBEyzc98Kv3fLFmN394SZ mmqkBb2xkQPtS6cnU/eR =xZEh -END PGP SIGNATURE-
[gentoo-dev] Re: [RFC] News item about mysql client and server packages
On Fri, Jul 17, 2015 at 1:56 PM, Brian Evans wrote: > > Developers and ebuild writers should reference virtual/libmysqlclient > when linking against the libraries as the package will keep the > subslot the same as the soversion for easy rebuilds. This isn't super-relevant to the news item itself, but is relevant for the developer community. Do you plan to make these changes to ebuilds yourself in a mass-update at the appropriate time, or do you expect maintainers to clean up their own ebuilds. If the latter, please provide instructions as to when/etc. -- Rich
Re: [gentoo-dev] Re: [RFC] News item about mysql client and server packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/17/2015 2:19 PM, Rich Freeman wrote: > On Fri, Jul 17, 2015 at 1:56 PM, Brian Evans wrote: >> >> Developers and ebuild writers should reference >> virtual/libmysqlclient when linking against the libraries as the >> package will keep the subslot the same as the soversion for easy >> rebuilds. > > This isn't super-relevant to the news item itself, but is relevant > for the developer community. > > Do you plan to make these changes to ebuilds yourself in a > mass-update at the appropriate time, or do you expect maintainers > to clean up their own ebuilds. If the latter, please provide > instructions as to when/etc. > The virtual/mysql will pull in virtual/libmysqlclient so current packages will be unaffected and can easily transition to the new virtual . Brian -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQIcBAEBAgAGBQJVqUkLAAoJENH3ge/59KO2zPwQAKiXCSVnbLd+3m4AuVFMGzoo 8GlnM3fvAtjnCp/Xr0oYqQjHobj043EsHtd9pk11wqt2+J2bIx+3eh54bu5LXsgp VdQEgBQVdVtqMSzYhROeELpjtGcgnqmMsAnlni0lp+DpKKiQ/ELDyN8X1dS0j3KZ cESoBpvMebEtejfSF/rkYjBAaGrXK6nuZGXe09kdcymNJfnZ1L72Jl3rH2h2weri Hlvw80+WkGYBywZ/CuwSQsxPTY2Aek9mUaQ31uiCkYPALhiufCx9yCt4Fhejlhsw 4oQZYS88WEwV4nUWKbvo4HJC011TrjFqDtUy+v6qAvEijyVf44lmSy0TtjDuaRmu YRbUZzssKHeah0N9cER4vPnOXhFdz+MtUG0sc5EAzWTUwARuVAm+th4Ua7/LjqLL ttDL8PfLvMtlegDkWoVjBgU3Mb5rWpeJ3Z9QIgIryYEwG1bWzg6JhZKzTvajxeFG 7d5fSPcODk12L+Y3JvepYSGvzTCZJeMMh3EKglHmXHdNcNF+ZbSV2Q4nzqCukqjh AEFpcwvydodfJBBsMO28i3c9d5EU5A3GTmaHKe5vosEf42JniX3fbrqC8gI27N/r F/avUFJC0MV7E1PEy11F2YY75EOH6n3Kd05Q+bvYuU2+QfzrD4jB218XeZTjr4rR U6KUpR5CArpEz0hlXdss =+EPw -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] News item about mysql client and server packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/17/2015 2:04 PM, NP-Hardass wrote: > On 07/17/2015 01:56 PM, Brian Evans wrote: >> Title: MySQL client libraries and server packaging changes >> Author: Brian Evans Content-Type: >> text/plain Posted: 2015-07-17 Revision: 1 News-Item-Format: 1.0 >> Display-If-Installed: virtual/mysql > >> The future of the mysql packages is changing. > >> First off, a new virtual is being introduced, >> virtual/libmysqlclient. virtual/mysql will represent the server >> and tools while virtual/libmysqlclient will represent the shared >> and static libraries. > >> Developers and ebuild writers should reference >> virtual/libmysqlclient when linking against the libraries as the >> package will keep the subslot the same as the soversion for easy >> rebuilds. This is getting more difficult in the current virtual >> situation as MySQL and MariaDB start to diverge versions and >> features. The old method could force users to mask new versions >> or delay the posting of one server package which advances the >> soversion until the others catch up. > >> As for the server packages themselves, the minimal USE is being >> replaced. The new USE flags are client-libs, +server, and +tools. >> The server and tools flags are on by default to signify the >> primary purpose of those builds. > >> The primary provider for libraries will be a new package >> dev-db/mysql-connector-c. A tinderbox run did not turn up any >> issues, but packagers are permitted to block any provider of >> virtual/libmysqlclient that does not work correctly. A comment >> in the ebuild would be helpful to track this. The server >> packages can still provide libraries if the client-libs USE is >> enabled. > > > It's my understanding that news items are geared to end users, > however, this may be incorrect. Assuming that is the case, apart > from notifying the users about the USE flag changes, the bulk of > this news item is geared toward devs and package maintainers. As > such, I feel like the user relevant content might go unnoticed as > they skim and see it is primarily maintainer related. Unfortunately, I am a terrible writer and just spill thoughts out. The users might still have to know about setting client-libs or using the new virtual if they set the minimal flags in the past. Will have to think on that. Brian -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQIcBAEBAgAGBQJVqUw2AAoJENH3ge/59KO2LYEQANdHnvjYBTTB5NLmvoFUBmF+ ekZEeoEsfIcSSQ9JISlNoZy05AKFqK1C+zd4+OnS+uVcaSId/MdEAXDD5ahtE8Je F9EuTaT3xAFaR2RG/OxiW8iyqV+2iX2126h3YrkHC+4zRQyf8S7dYaQqUzYtsv/H GAkyFD+F5f3MOXYsEsFVPvSn5BKQ5AmTnAGUpsr/RwEE9YaXVc1lyldPtPPMk527 Pc4wiZWRUBRxAe0NKuzFr0DM/7nOqBDVbsdsD9YtSMsLlvNu0qQtfActY0mgl4FU CZSfRhyvhzwKD4i9Bf/BODbOc8RgThVV0Vcpl/XxHzyPNxCCALDYAoNFEvfnV251 Fj8oGrmheVrM/DGqV0uKL+1jS2zrYQiTk5GlQut8KN7FGIz3//DOCnXt3BepdrIr AdgUdThc3Tz09PrGipya8C3T89tGQ7Q1H/8bI2v9ZvLjF5f81TG+s1KtSk2TRobd GXaplNHSjzLU98SPXshXddG0e7fWbjDXZP0J0k+PdRX0gDokN+YjWGiDAjHPj5n7 aLpWLRw3qdb/895Cgw1J5LyWSQ0W8dwa2/7c1N+ZP6eignPy/1b2p+yNORkjE5Y4 tmoJZYLbHihjoHPr6EFIB5UCxPvy7NqFQeU+iKTr5YNVblkhZqX1XrlR8JijiiRk KReddKPprFtanFiUmkFQ =EuG2 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] News item about mysql client and server packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 17.07.2015 19:56, Brian Evans wrote: > Title: MySQL client libraries and server packaging changes Be more specific, call it "split" instead of changing. > Author: Brian Evans Content-Type: text/plain > Posted: 2015-07-17 Revision: 1 News-Item-Format: 1.0 > Display-If-Installed: virtual/mysql > > The future of the mysql packages is changing. > That is probably the reason, write you write that news. I'd drop it, as it is kind of redundant. > First off, a new virtual is being introduced, > virtual/libmysqlclient. virtual/mysql will represent the server and > tools while virtual/libmysqlclient will represent the shared and > static libraries. > Explain first what virtual/libmysqlclient is and then what virtual/mysql does. Makes it better to read. > Developers and ebuild writers should reference > virtual/libmysqlclient when linking against the libraries as the > package will keep the subslot the same as the soversion for easy > rebuilds. This is getting more difficult in the current virtual > situation as MySQL and MariaDB start to diverge versions and > features. The old method could force users to mask new versions or > delay the posting of one server package which advances the > soversion until the others catch up. > I'm not sure if this is necessary to know for a user. > As for the server packages themselves, the minimal USE is being > replaced. The new USE flags are client-libs, +server, and +tools. > The server and tools flags are on by default to signify the > primary purpose of those builds. This is probably one of the most important things (plus maybe the following sentence in the next paragraph), when targeting users. If you don't drop the part directed at ebuild writers, you should move that paragraph up to the beginning (plus the following sentence). Otherwise users might skip reading the news if they have to read "unrelated" notes first. > > The primary provider for libraries will be a new package > dev-db/mysql-connector-c. A tinderbox run did not turn up any > issues, but packagers are permitted to block any provider of > virtual/libmysqlclient that does not work correctly. A comment in > the ebuild would be helpful to track this. The server packages can > still provide libraries if the client-libs USE is enabled. > Probably many users don't know what a tinderbox is, so drop that or rephrase it, e.g., "We tested the new packaging style thoroughly.". Cheers, Manuel. -BEGIN PGP SIGNATURE- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJVqVIlXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1 OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNc0wQP/2rSN7tb03yPZUh5UNK1xk21 kj8ihGo9RgccE+iMTpTz3Yo/Bd4WMWgSdrkiPwTay3MoS55V8DfHbmDfxoPEJgWC w7IUR02VLxyrFXOqOmEFYCbzwtglFXq5yXPX+QWALJMU0nNckpHMjW9LxqySbu2b 2oMyT2clPWUtcNi0tSsTmRdFCfCvmHCS1xsGBJ6ziTwVfrJIzKWAB/tlbz8E1kzs vAIjOaODNRz67XVebu2RAjqIebd1iF6EgPUvMIITBjBuR3dzc3ojEtOFpNnvGLWB RTX2xmekY6sUvN1IuH1lp/o5+E3ODfdUaTOX+BMcyvSYVKQUfe9yXSEmUErZJjME 7hDLd0Ts8PloXkuCK14AI2QqfCyuLRmIfEhC6ZyFPEIfsriK+pzHt/UN7DgBMoXn t0kiYSAH6oAGLg7J0tbKJCIF/X8TFYs/HIRRdEHwJagcbZpzmrJjqpjl1bxwgwUM i/LqHZLY/FnmHjvIZriB5k3aI8vlzdhZ40JxC73lPK+8pHbNUOUe4SQVUN8EcBQo Ueeqf1sNJXGTny94cfUfcz11jTkewBBBLItmaWNUaAjmjacPth6STlcmZQA/FvpN sjcDvrJdoUJ34VWzYyb/09G6x1/BT6xRD5SoH3ALI1tOusjUa75IMjmtr1lcQFbf 6uZAg4x9COvGPjluyh/J =hCUC -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] News item about mysql client and server packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here is a second Draft based on comments Title: MySQL client libraries and server packaging changes Author: Brian Evans Content-Type: text/plain Posted: 2015-07-17 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: virtual/mysql First off, a new virtual is being introduced, virtual/libmysqlclient. virtual/mysql will represent the server (mysqld) and tools (mysqldump, mysql, mysqladmin, etc) while virtual/libmysqlclient will represent the mysql client shared and static libraries, libmysqlclient.so for example. Ebuilds that only link the libraries may not pull in the server packages with this change in the future. Because of this, you may have to add a virtual/mysql or one of the providers; i.e. dev-db/mysql, dev-db/mariadb, or dev-db/percona-server; to your world file if you require a server to be installed locally. This will be phased in slowly as other packages are updated. As for the server packages themselves, the minimal USE is being replaced. The new USE flags are client-libs, server, and tools. The server and tools flags are on by default to signify the primary purpose of those builds. The primary provider for libraries will be a new package dev-db/mysql-connector-c. Thorough testing did not turn up any issues, but packagers are permitted to block any provider of virtual/libmysqlclient that does not work correctly. Enabling the client-libs USE on a server package may be the necessary solution for the rare case of a block on an incompatible provider. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQIcBAEBAgAGBQJVqWLCAAoJENH3ge/59KO2/JkP+QGpz+M93Mn2C1EopzTG01WZ 66ELrIle/bkvVCtEdfhJXERUqMsyPr5sH6bn2aRC8x7XI7zZWgXBlVrvG4swO7Ul /2BBArnO0lv/ck5P8QHZTkZuT4W5zZzQP9ORjKel7p/1Cc96kAlgyFd33ACgtjuV O2zc1mjpKSFhRhybP7FdFsVCpo3PkSYyhmACMkXlbsBmeo8I2u94bzGzuEe5olpM DOhbwjkeyPix2EacP5pLWmUOIwy/mv+1i+a7sqmkIk54EPuDqDV4dBWQWqyccUl/ puKhnCMsqwzVVRRni5DKK2q4vXC6DdSsuRT0E6/9EVUfSwPyLijYZTI4TNvpB+bn iz8UWkMcuovOBubycxhvDnx2c5+dmMgh1ykIu7Uq04hCFscP2bHmeON8EJLl3YvA RoDbc2AvDZnAo9Jbln5YfopNvZGKG5Ya9GFA9Wi1tbR/TxaxQ5w+ussKCEKsIrVT fqqyQyqALH84G00+PKAf1fbvG0COCl+vjrXnWNnl6j2302VnF6c1esfM5BdCkML0 5BN1jisy8bcjD2b3q/iFFpS5y530y8w46pb8Ad2EOja72GsuzUxRlfWtxDSp35o1 xP7fH7FYMEuxraEM4Ej4nQU2YCUX/n5xA9DEmMebwA069QDHKaJvalR8lBi4O0lP VAJLLUEs4uITSjMveDvv =DC98 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] News item about mysql client and server packages
> On Fri, 17 Jul 2015, Brian Evans wrote: > Here is a second Draft based on comments > Title: MySQL client libraries and server packaging changes Title is too long (51 chars). Maximum is 44 chars by GLEP 42. Ulrich pgptu4Duj5yI5.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] News item about mysql client and server packages
On Fri, 17 Jul 2015 23:32:10 +0200 Ulrich Mueller wrote: > > On Fri, 17 Jul 2015, Brian Evans wrote: > > > Here is a second Draft based on comments > > > Title: MySQL client libraries and server packaging changes > > Title is too long (51 chars). Maximum is 44 chars by GLEP 42. Every other news item seems to hit this. Maybe eselect news needs to be made to render news item titles over two lines if necessary. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] News item about mysql client and server packages
On 17/07/2015 22:17, Brian Evans wrote: > Here is a second Draft based on comments > > > Title: MySQL client libraries and server packaging changes > Author: Brian Evans > Content-Type: text/plain > Posted: 2015-07-17 > Revision: 1 > News-Item-Format: 1.0 > Display-If-Installed: virtual/mysql > > First off, a new virtual is being introduced, virtual/libmysqlclient. > virtual/mysql will represent the server (mysqld) and tools (mysqldump, > mysql, mysqladmin, etc) while virtual/libmysqlclient will represent > the mysql client shared and static libraries, libmysqlclient.so for > example. This reads oddly. There's a "first" but I'm left wondering what the "second" is, and I have to re-read "mysql client shared and static" several times to figure out what is probably the noun and the adjective. If I were writing the news, I'd probably do this: Ebuild packaging for the various mysql packages is changing; including the addition of a new virtual virtual/libmysqlclient. The existing virtual/mysql will represent the server (mysqld) and tools (mysqldump, mysql, mysqladmin, etc), while virtual/libmysqlclient will represent the shared and static libraries for mysql clients, e.g. libmysqlclient.so > Ebuilds that only link the libraries may not pull in the server > packages with this change in the future. Because of this, you may have > to add a virtual/mysql or one of the providers; i.e. dev-db/mysql, > dev-db/mariadb, or dev-db/percona-server; to your world file if you > require a server to be installed locally. This will be phased in > slowly as other packages are updated. > > As for the server packages themselves, the minimal USE is being > replaced. The new USE flags are client-libs, server, and tools. > The server and tools flags are on by default to signify the primary > purpose of those builds. It's not obvious that "minimal" is a USE flag, I first thought you meant USE is short :-). I suggest: The USE flag "minimal" > The primary provider for libraries will be a new package > dev-db/mysql-connector-c. Thorough testing did not turn up any > issues, but packagers are permitted to block any provider of > virtual/libmysqlclient that does not work correctly. Enabling the > client-libs USE on a server package may be the necessary solution for > the rare case of a block on an incompatible provider. Finally, I'd flesh this out a little more so that users know what *they* need to with this change. You've done a good job of explaining what you have done. It's not completely clear what the user must do to retain their existing mysql clients, and many of them will think mysql-connector-c provides it. I'd suggest a wording myself, but I'm still not 100% clear how it will really work. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] [RFC] News item about mysql client and server packages
> On Fri, 17 Jul 2015, Ciaran McCreesh wrote: >> Title is too long (51 chars). Maximum is 44 chars by GLEP 42. > Every other news item seems to hit this. Maybe eselect news needs to > be made to render news item titles over two lines if necessary. It already does this for the "read" action. For the "list" action, behaviour is modeled on mail readers, most of which truncate titles when necessary. Actually, we could loosen the requirements for news items in the gentoo repository (since the repository name is not displayed for these) and allow up to 56 characters in the title. On the other hand, shortening the title to be within the 44 char limit made them more concise and therefore was an improvement in most cases. Ulrich pgp2WmsCJm7OX.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] News item about mysql client and server packages
Alan McKinnon posted on Fri, 17 Jul 2015 23:38:44 +0200 as excerpted: >> First off, a new virtual is being introduced, virtual/libmysqlclient. >> virtual/mysql will represent the server (mysqld) and tools (mysqldump, >> mysql, mysqladmin, etc) while virtual/libmysqlclient will represent the >> mysql client shared and static libraries, libmysqlclient.so for >> example. > > This reads oddly. There's a "first" but I'm left wondering what the > "second" is, Was just going to point this out myself. 1) "First off,", specifically the "off" sounds informal (I checked myself on wiktionary, which lists "first off" as "idiomatic). It's fine, indeed great, for informal conversations, but news items are more formal announcements and should be worded as such. So strike the "off". That leaves simply "First,". 2) As Alan mentions, "first" is sequential. Don't use "first" unless your intent is to enumerate a sequential list. That implies you need at least a "second" or "last/finally", if not more than two sequential/ numbered points. That isn't to say you must strike "first" here, if you add further sequence keywords, because such sequential numbering indicates moving on to the next main point, separate from paragraph structure, with such points commonly being found both within a single paragraph if small enough, or with multiple paragraphs per point, as I'm doing here. In fact, such transitional keywords tend to be extremely helpful to the reader, since they do identify the author's intended key points, thus being very helpful when overview- or fast-scanning. (As you see here, I used digit numbering demarced by closing parenthesis, as opposed to the words. That's simply personal preference, tho I believe a convincing argument can be made that it's easier to pick out. Some may argue using the words is more formal, however, and could thus make the same point I made about "first off" above, for the digit choice. YMMV in that regard, but I personally still prefer the digits. Then of course there's the question of whether a ")" or "." demarc is better. As a reader I've absolutely no preference there, but I believe I favor the ")" in my own writing.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
