Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver

2020-12-17 Thread Aaron W. Swenson

On Thu, Dec 17, 2020 at 01:12:16PM -0500, Mike Gilbert wrote:

Signed-off-by: Mike Gilbert 
---

v2: Added "This upload is required in addition to uploading the SKS pool."

glep-0063.rst | 24 
1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index 82541bd..ec465db 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -7,10 +7,10 @@ Author: Robin H. Johnson ,
Michał Górny 
Type: Standards Track
Status: Final
-Version: 2.1
+Version: 2.2
Created: 2013-02-18
-Last-Modified: 2019-11-07
-Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24
+Last-Modified: 2020-12-17
+Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24, 2020-12-17
Content-Type: text/x-rst
---

@@ -28,6 +28,9 @@ OpenPGP key management policies for the Gentoo Linux 
distribution.
Changes
===

+v2.2
+  Added "Gentoo Keyserver" section under "Gentoo Infrastructure" chapter.
+
v2.1
  A requirement for an encryption key has been added, in order to extend
  the GLEP beyond commit signing and into use of OpenPGP for dev-to-dev
@@ -135,8 +138,11 @@ their primary key).

5. Encrypted backup of your secret keys.

+Gentoo Infrstructure
+
+
Gentoo LDAP
-===
+---

All Gentoo developers must list the complete fingerprint for their primary
keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex digits,
@@ -147,6 +153,16 @@ of the fingerprint field. In any place that presently 
displays
the "``gpgkey``" field, the last 16 hex digits of the fingerprint should
be displayed instead.

+Gentoo Keyserver
+
+
+Gentoo infrastructure uses a keyserver that is isolated from the SKS pool.
+This keyserver is restricted to accepting uploads from authorized Gentoo hosts.
+A script is provided on dev.gentoo.org to allow developers to upload their
+keys. This upload is required in addition to uploading to the SKS pool.
+
+``gpg --export KEYID | ssh dev.gentoo.org /usr/local/bin/openpgp-key-upload``
+
Backwards Compatibility
===

--
2.30.0.rc0




Thanks for doing this! You beat me to the punch. I was going to try getting to
it tomorrow.

It may be good to also change step 7 under "Bare minimum requirements" to read:

7. Upload your key to the Gentoo Keyserver before usage!

It'd give skimmers a trigger to look for the Gentoo keyserver info.

We might want to add "Upload to the SKS or some other public PGP pool" under
"Recommendations", but that's probably beyond the scope of the document now.

Lastly, should we have a link to the step-by-step guide? [1]

[1]: 
https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys


signature.asc
Description: PGP signature


Re: [gentoo-dev] GPG key refresh

2020-12-15 Thread Aaron W. Swenson

On 2020-12-15 11:16, Michael Orlitzky wrote:

On 12/15/20 11:11 AM, Thomas Deutschmann wrote:


What do you mean exactly?

For Gentoo tooling, only Gentoo keyservers are important and Gentoo no longer 
synchronizes with any other pool.


"The Gentoo developer tooling explicitly checks the Gentoo keyserver
pool with a much higher frequency" strongly implies that we check the
non-Gentoo pools with a non-zero frequency.




I'm with Michael on this. I've recently experienced this issue myself as the
instruction to upload the key to the Gentoo keyserver is separate from the
GLEP63[1] document. It doesn't matter that the step is documented if the Holy
Tome GLEP63 doesn't mention it. What hint would I have to look for a
supplemental document to provide that specific step?

According to GLEP 63, uploading to the SKS keyserver is a requirement.
However, it fails to specify which SKS keyserver. In fact, neither "SKS" nor
"keyserver" are defined in GLEP63. Ergo, the natural interpretation is 
*anything*
that's called an SKS keyserver will satisfy the requirement. As long as the
developer can submit the key, the requirement is met.

Additionally, the supplemental document[2] doesn't say developers must upload
via an internal host, but that devs should upload to both SKS and the Gentoo
keyserver. Yes, it says the Gentoo keyserver is currently restricted to syncing
with "authorized Gentoo hosts", but that's a nonsense phrase and unhelpful. It
assumes I know what the authorized Gentoo hosts are. It doesn't clearly state
what they are. It kind of hints that it will pull from SKS eventually, but it
could take a long time.

I understand we temporarily stopped syncing with the public keyserver out of an
overabundance of caution. However, that shouldn't have been done without
updating every official Gentoo resource regarding how devs should handle their
keys, which as far as I know is only two documents[1,2]. A whopping 2 documents.

This new (I know it's been around for a year but that doesn't make it any less
new), stricter requirement, should be **explicitly** stated in GLEP63, properly
referencing the justification[3], and linking to the infra supplemental
document. The infra supplemental document needs to then use the phrase "must" in
place of "should" when informing readers to upload to two different locations.


Footnotes:
[1]  https://www.gentoo.org/glep/glep-0063.html

[2]  
https://wiki.gentoo.org/index.php?title=Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys=813494#Submit_your_new_key_to_the_keyserver

[3]  https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html



signature.asc
Description: PGP signature


Re: [gentoo-dev] Packages up for grabs: dev-db/plr, media-gfx/freewrl, net-analyzer/check_mk_agent, net-misc/wakeonlan, sys-fs/dmraid, x11-misc/slim

2020-12-09 Thread Aaron W. Swenson

On Wed, Dec 09, 2020 at 12:41:32PM +0100, Michał Górny wrote:

Hello,

The following packages are looking for a new maintainer now:

dev-db/plr
 R language extension for postgresql database
 [has test failures]


PostgreSQL project will take this one.


signature.asc
Description: PGP signature


Re: [gentoo-dev] New acct-user/pgbouncer

2020-10-05 Thread Aaron W. Swenson
On 2020-10-05 10:51, Aaron W. Swenson wrote:
> Currently we're just using -1 for pgbouncer. The user does own a couple 
> things,
> but that's managed by checkpath in the init script.
> 
> So, given that any UID will do, I'm proposing either 383  (I think someone 
> else
> is asking for 384) or 463.
> 
> Pgbouncer only needs a UID. It uses the postgres GID.
> 
> Which UID should we use: 383 or 463?


And, I'm seeing my list was slightly out of date as 383 is now taken. So, which
UID should we use: 379 or 463?


signature.asc
Description: PGP signature


[gentoo-dev] New acct-user/pgbouncer

2020-10-05 Thread Aaron W. Swenson
Currently we're just using -1 for pgbouncer. The user does own a couple things,
but that's managed by checkpath in the init script.

So, given that any UID will do, I'm proposing either 383  (I think someone else
is asking for 384) or 463.

Pgbouncer only needs a UID. It uses the postgres GID.

Which UID should we use: 383 or 463?


signature.asc
Description: PGP signature


Re: [gentoo-dev] Last rites: dev-db/pgadmin3 [CORRECTION]

2018-10-26 Thread Aaron W. Swenson
On 2018-10-25 19:37, Aaron W. Swenson wrote:
> # Aaron W. Swenson  (25 Oct 2018)
> # Fails to build against up to date OpenSSL library (Bug 663966). No longer
> # supported upstream. Use dev-db/pgadmin4.
> # Masked for removal on 2018-11-24, bug #669650.
> dev-db/pgadmin3


I had a typo in the subject. I definitely mean dev-db/pgadmin3.


signature.asc
Description: PGP signature


Re: [gentoo-dev] Last rites: dev-db/pgadmin4

2018-10-26 Thread Aaron W. Swenson
On 2018-10-26 10:13, Bernd Waibel wrote:
> The subject seems to be wrong. It says pgadmin4, but the mask says pgadmin3.

Bah! Yeah, definitely pgadmin3 is getting it’s last rites. pgadmin4 will stick
around for a while.


signature.asc
Description: PGP signature


[gentoo-dev] Last rites: dev-db/pgadmin4

2018-10-25 Thread Aaron W. Swenson
# Aaron W. Swenson  (25 Oct 2018)
# Fails to build against up to date OpenSSL library (Bug 663966). No longer
# supported upstream. Use dev-db/pgadmin4.
# Masked for removal on 2018-11-24, bug #669650.
dev-db/pgadmin3


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 62/98] postgres-multi.eclass: add @SUPPORTED_EAPIS

2018-08-13 Thread Aaron W. Swenson
On 2018-08-12 09:23, Michał Górny wrote:
> ---
>  eclass/postgres-multi.eclass | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/eclass/postgres-multi.eclass b/eclass/postgres-multi.eclass
> index 39f0837a8686..48ef79dc2925 100644
> --- a/eclass/postgres-multi.eclass
> +++ b/eclass/postgres-multi.eclass
> @@ -9,6 +9,7 @@ EXPORT_FUNCTIONS pkg_setup src_prepare src_compile 
> src_install src_test
>  # @MAINTAINER:
>  # PostgreSQL 
>  # @AUTHOR: Aaron W. Swenson 
> +# @SUPPORTED_EAPIS: 5 6
>  # @BLURB: An eclass to build PostgreSQL-related packages against multiple 
> slots
>  # @DESCRIPTION:
>  # postgres-multi enables ebuilds, particularly PostgreSQL extensions, to
> -- 
> 2.18.0

Fine by me.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 63/98] postgres.eclass: add @SUPPORTED_EAPIS

2018-08-13 Thread Aaron W. Swenson
On 2018-08-12 09:23, Michał Górny wrote:
> ---
>  eclass/postgres.eclass | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/eclass/postgres.eclass b/eclass/postgres.eclass
> index 221b53dea4d7..b76604b1af24 100644
> --- a/eclass/postgres.eclass
> +++ b/eclass/postgres.eclass
> @@ -8,6 +8,7 @@ EXPORT_FUNCTIONS pkg_setup
>  # @MAINTAINER:
>  # PostgreSQL 
>  # @AUTHOR: Aaron W. Swenson 
> +# @SUPPORTED_EAPIS: 5 6
>  # @BLURB: An eclass for PostgreSQL-related packages
>  # @DESCRIPTION:
>  # This eclass provides common utility functions that many
> -- 
> 2.18.0

Fine by me.


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: dev-python/pgasync

2018-07-09 Thread Aaron W. Swenson
# Aaron W. Swenson  (9 Jul 2018)
# Hasn’t been updated in years, upstream’s download source is blank, and depends
# on an outdated twisted-core (Bug 660668). Removal after 2018-08-08.
dev-python/pgasync


signature.asc
Description: Digital signature


Re: [gentoo-dev] News Item: Portage rsync hardlink support

2018-07-08 Thread Aaron W. Swenson
On July 8, 2018 5:38:48 PM EDT, Zac Medico  wrote:
>On 07/08/2018 02:18 PM, Michał Górny wrote:
>> W dniu nie, 08.07.2018 o godzinie 14∶11 -0700, użytkownik Zac Medico
>> napisał:
>>> On 07/08/2018 01:18 PM, Zac Medico wrote:
 On 07/08/2018 01:08 PM, Michał Górny wrote:
> W dniu nie, 08.07.2018 o godzinie 11∶57 -0700, użytkownik Zac
>Medico
> napisał:
>> On 07/08/2018 11:42 AM, Michał Górny wrote:
>>> W dniu nie, 08.07.2018 o godzinie 11∶04 -0700, użytkownik Zac
>Medico
>>> napisał:
 On 07/08/2018 06:56 AM, Michał Górny wrote:
> W dniu nie, 08.07.2018 o godzinie 15∶02 +0200, użytkownik
>Kristian
> Fiskerstrand napisał:
>> On 07/08/2018 08:53 AM, Michał Górny wrote:
>>> Is safe git syncing implemented already? If not, maybe
>finish it first and cover both with a single news item. Git is going to
>be more efficient here, so people may want to learn they have an
>alternative.
>>
>> Why complicate things, and increase wait for something that
>benefits
>> most users, just to give alternatives to a few using
>non-default sync
>> mechanism. Securing git distribution is a whole different
>ballpark.
>>
>
> Let me rephrase.  Let's say I'm using rsync.  This new feature
>is
> something positive but it breaks my use case (for one of the
>listed
> reasons -- overlayfs, inode use, small fs cache).  After
>reading this
> news item, I learn that my only option is to disable the new
>feature.
>
> Now, I would appreciate being told that there's an alternate
>sync method
> that handles secure updates without having all those
>drawbacks.

 The thing is, the normal git tree doesn't even provide
>pre-generated
 metadata, and I see then gentoo-mirror repo that provides
>metadata does
 not have commits signed with an release key:

 https://github.com/gentoo-mirror/gentoo/commits/stable

 So I'm really not comfortable recommending git to anyone at
>this point.
>>>
>>> Wrong twice.
>>>
>>> Firstly, the canonical URL is:
>>>
>>>   https://anongit.gentoo.org/git/repo/sync/gentoo.git
>>>   (https://gitweb.gentoo.org/repo/sync/gentoo.git)
>>>
>>> Secondly, the merge commits (i.e. top commits that are verified
>>> by Portage) are signed by dedicated key that is part of the
>infra key
>>> set.  In other words, it works out of the box.
>>
>> Is there any documentation that shows users how to migrate to
>git, and
>> what the pros and cons might be? Maybe its worthy of its own news
>item.
>
> Maybe.  I don't really know, and don't think it's a good idea to
>show 30
> news item of things users might like on every new Gentoo install.

 Well if instructions for setting up git sync and associated
>pros/cons
 are not documented anywhere then I won't advise anyone to use it.
>>>
>>> I've attempted to configure it for myself, and this is what it does:
>>>
>>>  * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
>>>  * Refreshing keys from keyserver ...
>>>[ ok ]
>>>  * No valid signature found: unable to verify signature (missing
>key?)
>>>
>> 
>> Please report a bug and attach your configuration along with keyring
>> version.
>
>It works after upgrading to openpgp-keys-gentoo-release-20180706 from
>openpgp-keys-gentoo-release-20180323.
>-- 
>Thanks,
>Zac

Does Portage not call attention to critical updates?

It used to make a special statement for a new stable Portage and strongly 
recommended that it be emerged first. It should probably do the same for 
openpgp-keys-gentoo-release.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

signature.asc
Description: PGP signature


Re: [gentoo-dev] Packages up for grabs

2018-05-13 Thread Aaron W. Swenson
On 2018-05-05 04:49, Robin H. Johnson wrote:
> On Fri, May 04, 2018 at 10:52:11PM +0200, Patrice Clement wrote:
> > The following packages are up for grabs:
> ...
> > net-misc/s3cmd
> I'll take s3cmd, since my dayjob uses it heavily.

I know I’m listed on the metadata, but I’ve never done anything more
than compile it at some point in the past.

You’re welcome to be the sole maintainer.


signature.asc
Description: Digital signature


Re: [gentoo-dev] [News item review] Portage rsync tree verification (v2)

2018-01-25 Thread Aaron W. Swenson
On 2018-01-25 13:35, Michał Górny wrote:
> Display-If-Installed: =2.3.22 this same information?

I know we don’t have expires, yet. How about making it


signature.asc
Description: Digital signature


Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

2018-01-16 Thread Aaron W. Swenson
On 2018-01-16 15:07, Róbert Čerňanský wrote:
> On Wed, 10 Jan 2018 22:46:04 +0200
> Mart Raudsepp  wrote:
> > 2.6 is insecure by 400+ ancient webkit-gtk security vulnerabilities,
> > we can't responsibly wait anymore. 2.7.3 was tested by Aaron (who
> > uses it daily) to work quite nicely.
> > I want to last rite gnucash-2.6 used webkit-gtk before the month is
> > over, as the maintainer of webkit-gtk, and if 2.7 isn't there, 2.6
> > will simply be fully masked as well along it.
> 
> I assume that the motivation to get 2.7 stabilized early it to protect
> users from potentional damages caused via webkit-gtk security
> vulnerabilities.  However, provided that I use GnuCash to display only
> local web data (generated reports) I feel much more comfortable
> to entrust my data to the stable 2.6 version rather than unstable 2.7
> about which the upstream says:
> 
> "Unstable (development) releases are for testing purposes only. They
> contain the newest features and improvements, but may also contain
> serious bugs still. Don't install these releases for everyday use." [1]
> 
> "Due to the possibility of data corruption, unstable releases should
> only be used on a copy of live GnuCash data." [2]
> 
> I think generated reports are typical use of webkit in GnuCash.  Are
> attack vectors so severe also in this case?
> 
> Thank you.
> 
> 1. http://gnucash.org/download.phtml
> 2. https://wiki.gnucash.org/wiki/Development_Process
> 
> Robert

You are welcome to keep the insecure/outdated packages on your
machine. You do not have to update. We’re just working towards the long
overdue removal of a security risk from the tree.

Really, it isn’t so much that gnucash is at risk because it uses the old
insecure net-libs/webkit-gtk:2 (it may very well be, but there haven’t
been any reports that I’ve seen), but it is all the other packages that
use webkit-gtk to render HTML from untrusted sources that are at risk.

If we could have, we would have removed net-libs/webkit-gtk:{2,3} long
ago. This is nearly two years overdue. [1]

However, this removal will result in it being impossible for anyone to
build gnucash-2.6, so that must be removed as well.

Given the situation, we have a choice: Remove GnuCash altogether, or
press ahead with recommending a version upstream considers unstable.

[1]: https://bugs.gentoo.org/577068


signature.asc
Description: Digital signature


Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

2018-01-14 Thread Aaron W. Swenson
Pushed via commit ed16527710bcde367ba3a4c7604c5aa6b2650034.


signature.asc
Description: Digital signature


[gentoo-dev] Last Rites: app-office/odeskteam

2018-01-14 Thread Aaron W. Swenson
Upstream is now Upwork. Use app-office/upwork instead. Masked for
removal in 30 days.


signature.asc
Description: Digital signature


Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change (v4)

2018-01-12 Thread Aaron W. Swenson
On 2018-01-11 23:30, Ulrich Mueller wrote:
> >>>>> On Thu, 11 Jan 2018, Aaron W Swenson wrote:
> 
> > 2018-01-11-GnuCash-Breaking-Change.en.txt
> 
> Since its last update, GLEP 42 strongly recommends using a very short
> name, with at most 20 characters for the short-name identifier [1]
> (whose main purpose is to keep the name unique if more than one news
> item is posted on the same day). Also, the git hook will reject names
> containing uppercase chars. So, could you use something like
> 2018-01-11-gnucash.en.txt for the name?
> 
> Ulrich
> 
> [1] https://www.gentoo.org/glep/glep-0042.html#news-item-identities

I forgot about the lowercase bit, and I will shorten it up further.

Thanks!


signature.asc
Description: Digital signature


Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change (v4)

2018-01-11 Thread Aaron W. Swenson
Revision number 4.

Title: GnuCash 2.7+ Breaking Change
Author: Aaron W. Swenson <titanof...@gentoo.org>
Posted: 2018-01-11
Revision: 1
News-Item-Format: 2.0
Display-If-Installed:  gnucash-2.6.sql.xz

For PostgreSQL:
$ pg_dump -U gnucash_user -Z 5 gnucash_db > gnucash-2.6.sql.gz

For SQLite:
$ cp /path/to/sqlite.file.gnucash /path/to/sqlite.file.gnucash.bak

[1] https://github.com/Gnucash/gnucash/releases/tag/2.7.0a
Title: GnuCash 2.7+ Breaking Change
Author: Aaron W. Swenson <titanof...@gentoo.org>
Posted: 2018-01-11
Revision: 1
News-Item-Format: 2.0
Display-If-Installed:  gnucash-2.6.sql.xz

For PostgreSQL:
$ pg_dump -U gnucash_user -Z 5 gnucash_db > gnucash-2.6.sql.gz

For SQLite:
$ cp /path/to/sqlite.file.gnucash /path/to/sqlite.file.gnucash.bak

[1] https://github.com/Gnucash/gnucash/releases/tag/2.7.0a


signature.asc
Description: Digital signature


Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change (v3)

2018-01-11 Thread Aaron W. Swenson
On 2018-01-11 19:02, Francesco Riosa wrote:
> It could be wise to close GnuCash before backup

Good point. Added a line.

> also the choice of creating a copy of the database is a bit unusual,
> an offline backup may be more appropriated, example for mysql:
> mysqldump gnucash_db | xz > gnucash-2.6.sql.xz

I thought it’d be nice to have the backup online, but this is probably
better. I’ve change the PostgreSQL command as well.

> It's ok to leave restore instruction out, since those are usually easy to
> find and spending more time with it does not hurt

I’m glad we agree.

Thanks!


signature.asc
Description: Digital signature


Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change (v3)

2018-01-11 Thread Aaron W. Swenson
This time with a version constrain that should allow this to expire at
some point in the future.

Title: GnuCash 2.7+ Breaking Change
Author: Aaron W. Swenson <titanof...@gentoo.org>
Posted: 2018-01-11
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: https://github.com/Gnucash/gnucash/releases/tag/2.7.0a
Title: GnuCash 2.7+ Breaking Change
Author: Aaron W. Swenson <titanof...@gentoo.org>
Posted: 2018-01-11
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: https://github.com/Gnucash/gnucash/releases/tag/2.7.0a


signature.asc
Description: Digital signature


Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

2018-01-10 Thread Aaron W. Swenson
On 2018-01-10 22:53, Ciaran McCreesh wrote:
> On Wed, 10 Jan 2018 17:48:32 -0500
> "Aaron W. Swenson" <titanof...@gentoo.org> wrote:
> > Modified a bit. This should show for anyone who has GnuCash installed.
> 
> For anyone who has any version of GnuCash installed, either now or at
> any point in the future. (See the recent thread on expiring news
> items...) Are you sure you don't just want to target this at people who
> have the old version installed, instead?

As mentioned, the concern is that someone will try to use a new version
and old version simultaneously.

How about “

signature.asc
Description: Digital signature


Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

2018-01-10 Thread Aaron W. Swenson
Modified a bit. This should show for anyone who has GnuCash installed.

The 2.7.3 ebuild I have in my overlay does have a postinst note about
this as well, but I think this is important enough to tell them as soon
as possible and on systems that may never have had GnuCash installed but
will be working with files/databases that are made by GnuCash 2.6.

Title: GnuCash 2.7+ Breaking Change
Author: Aaron W. Swenson <titanof...@gentoo.org>
Posted: 2018-01-10
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: app-office/gnucash

Along with changes to updates to use modern libraries, GnuCash 2.7+ has
changed the schema [1] it uses for both databases and files. GnuCash
will automatically modify the file or database in place upon open.

Therefore, it is imperative that you back up any files or databases
before using GnuCash 2.7 in case you run into an issue and want or need
to revert back to 2.6.

Instructions for backing up are as follows:

For XML (plain files):
$ cp /path/to/file.gnucash /path/to/file.gnucash.bak

For MySQL:
$ mysqldump gnucash_db | mysql gnucash_db_bak

For PostgreSQL:
$ createdb -U dbadmin -T gnucash_db -O gnucash_user gnucash_db_bak

For SQLite:
$ cp /path/to/gnucash/sqlite.file.gnucash 
/path/to/gnucash/sqlite.file.gnucash.bak

[1] https://github.com/Gnucash/gnucash/releases/tag/2.7.0a
Title: GnuCash 2.7+ Breaking Change
Author: Aaron W. Swenson <titanof...@gentoo.org>
Posted: 2018-01-10
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: app-office/gnucash

Along with changes to updates to use modern libraries, GnuCash 2.7+ has
changed the schema [1] it uses for both databases and files. GnuCash
will automatically modify the file or database in place upon open.

Therefore, it is imperative that you back up any files or databases
before using GnuCash 2.7 in case you run into an issue and want or need
to revert back to 2.6.

Instructions for backing up are as follows:

For XML (plain files):
$ cp /path/to/file.gnucash /path/to/file.gnucash.bak

For MySQL:
$ mysqldump gnucash_db | mysql gnucash_db_bak

For PostgreSQL:
$ createdb -U dbadmin -T gnucash_db -O gnucash_user gnucash_db_bak

For SQLite:
$ cp /path/to/gnucash/sqlite.file.gnucash 
/path/to/gnucash/sqlite.file.gnucash.bak

[1] https://github.com/Gnucash/gnucash/releases/tag/2.7.0a


signature.asc
Description: Digital signature


Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

2018-01-10 Thread Aaron W. Swenson
On 2018-01-10 19:33, Kristian Fiskerstrand wrote:
> On 01/10/2018 07:31 PM, Aaron W. Swenson wrote:
> > It is imperative that you back up any files or databases that GnuCash
> > uses in case you run into an issue with 2.7+ and want or need to revert
> > back to 2.6.
> 
> This seems to imply that upgrading from 2.6 to 2.7+ does not require any
> changes / auto-upgrades schema, maybe it should be stated explicitly
> early on?

Good point. Added explicit statement.


signature.asc
Description: Digital signature


Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

2018-01-10 Thread Aaron W. Swenson
On 2018-01-10 19:07, Ciaran McCreesh wrote:
> On Wed, 10 Jan 2018 19:35:52 +0100
> Kristian Fiskerstrand <k...@gentoo.org> wrote:
> > On 01/10/2018 07:31 PM, Aaron W. Swenson wrote:
> > > Display-If-Installed: >=app-office/gnucash-2.7.0  
> > 
> > And we might want to display it before users actually upgrades if it
> > is for backing up an auto migrated change?
> 
> Yes, this header is backwards. It's a message to be displayed to users
> who have the old version, not a message to be displayed to users who
> install the new version for the first time ever and who have never used
> the old version.

Perhaps the version restriction should be removed.

People could install GnuCash for the first time ever, then use it to
open files previously handled by 2.6.

If we’re not terribly concerned about that, I can flip the comparison.


signature.asc
Description: Digital signature


Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

2018-01-10 Thread Aaron W. Swenson
On 2018-01-10 22:38, Peter Volkov wrote:
> On Wed, Jan 10, 2018 at 9:31 PM, Aaron W. Swenson <titanof...@gentoo.org>
> wrote:
> 
> > Title: GnuCash 2.7+ Breaking Change
> >
> 
> Aaron, but why do we need this news item? 2.7 version is a development
> version that is not supposed to be used by end users. As far as I
> understand this backup is a temporary measure until stable release will be
> out. It's much better to have this version package masked. Then in package
> mask comment we could note the need for backup.

GnuCash 2.6 relies on net-libs/webkit-gtk:2 which will be removed from
the tree soon. If GnuCash doesn’t make the jump to 2.7, then it’ll be
removed from the tree as well. [1]

We’re going to try to introduce it a bit sooner.

[1]: https://bugs.gentoo.org/629114


signature.asc
Description: Digital signature


[gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

2018-01-10 Thread Aaron W. Swenson
Please review.

Title: GnuCash 2.7+ Breaking Change
Author: Aaron W. Swenson <titanof...@gentoo.org>
Posted: 2018-01-11
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: >=app-office/gnucash-2.7.0

Along with changes to updates to use modern libraries, GnuCash 2.7+ has
changed the schema [1] it uses for both databases and files.

It is imperative that you back up any files or databases that GnuCash
uses in case you run into an issue with 2.7+ and want or need to revert
back to 2.6.

Instructions for backing up are as follows:

For XML (plain files):
$ cp /path/to/file.gnucash /path/to/file.gnucash.bak

For MySQL:
$ mysqldump gnucash_db | mysql gnucash_db_bak

For PostgreSQL:
$ createdb -U dbadmin -T gnucash_db -O gnucash_user gnucash_db_bak

For SQLite:
cp /path/to/gnucash/sqlite.file.gnucash /path/to/gnucash/sqlite.file.gnucash.bak

[1] https://github.com/Gnucash/gnucash/releases/tag/2.7.0a
Title: GnuCash 2.7+ Breaking Change
Author: Aaron W. Swenson <titanof...@gentoo.org>
Posted: 2018-01-11
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: >=app-office/gnucash-2.7.0

Along with changes to updates to use modern libraries, GnuCash 2.7+ has
changed the schema [1] it uses for both databases and files.

It is imperative that you back up any files or databases that GnuCash
uses in case you run into an issue with 2.7+ and want or need to revert
back to 2.6.

Instructions for backing up are as follows:

For XML (plain files):
$ cp /path/to/file.gnucash /path/to/file.gnucash.bak

For MySQL:
$ mysqldump gnucash_db | mysql gnucash_db_bak

For PostgreSQL:
$ createdb -U dbadmin -T gnucash_db -O gnucash_user gnucash_db_bak

For SQLite:
cp /path/to/gnucash/sqlite.file.gnucash /path/to/gnucash/sqlite.file.gnucash.bak

[1] https://github.com/Gnucash/gnucash/releases/tag/2.7.0a


signature.asc
Description: Digital signature


Re: [gentoo-dev] Deleting old news items

2018-01-05 Thread Aaron W. Swenson
On 2018-01-05 15:16, William Hubbs wrote:
> If we have a default expiration, it should be one year after the date
> posted to go along with our current policy of not supporting things that
> are older than a year.
> 
> William

I thought it was three years.

At any rate, I think a year is too short.

How about 18 months?


signature.asc
Description: Digital signature


Re: [gentoo-dev] Deleting old news items

2018-01-02 Thread Aaron W. Swenson
+1


signature.asc
Description: Digital signature


Re: [gentoo-dev] [QA] New policy: 'files' directory must not be larger than 32 KiB

2017-12-19 Thread Aaron W. Swenson
On 2017-12-17 14:21, Michał Górny wrote:
>   Total size of 'files' subdirectory of a package should not be larger
>   than 32 KiB. If the package needs more auxiliary files, they should
>   be put into SRC_URI e.g. via tarballs.

I don’t have any strong opinions about this either way.

However, what alternative do we have to throwing the patches up in a
devspace?

Having previously done so with dev-db/postgresql, it was annoying having
to fix the SRC_URI because I wasn’t the one who did a slot bump.


signature.asc
Description: Digital signature


Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org

2017-12-16 Thread Aaron W. Swenson
On 2017-12-15 16:37, R0b0t1 wrote:
> Hello,
> 
> On Tue, Dec 5, 2017 at 4:18 PM, Nils Freydank  wrote:
> > Hello everyone,
> >
> > with regards to the current mailing list (ML) split discussion, and one
> > specific message deep down there by mgorny asked for someone providing
> > moderator rules, I would like to propose the following ruleset for 
> > gentoo-dev
> >
> > Right now the situation escalated in a way that forces to actually do
> > something and I hope we can recreate an atmosphere where technical
> > improvements can happen.
> >
> 
> To me, at least, this isn't self-evident. What specific actions make
> you think an immediate response is necessary?
> 
> self-evident
>   adj. Evident to one’s self and to nobody else.
> 
> Cheers,
>  R0b0t1
> 

According to Merriam-Webster:

self-evident
 adjective | self-ev·i·dent | ˌself-ˈe-və-dənt , -ˌdent
 evident without proof or reasoning

You have been a part of the conversations that devolved into the
non-technical, and even started your own decidedly non-technical
discussion on this list[1] where you’ve seen that rules for moderation,
or at least defining the expectations of moderators and participants,
would have been beneficial.

[1]: 


signature.asc
Description: Digital signature


Re: [gentoo-dev] AMD64 Arch Testers needed urgently

2017-12-14 Thread Aaron W. Swenson
On 2017-12-14 13:58, Kent Fredric wrote:
> On Wed, 13 Dec 2017 21:58:05 +0100
> Slightly modified suggestion:
> 
> Add a flag called "autostabilize" with [unset], [y], [n]
> 
> Default is 'unset', and if found unset after a given time, it flips to
> y and the stable bot gets queued up.
> 
> If its set to 'n', then stable bot never does anything.
> 
> This way maintainers who want to rush the stablebot on things they
> consider "safe" can get ahead of the queue.

Well, we kind of have that already with “Runtime testing required” (RTR).

RTR=no stablereqs are good candidates for automation.

If everything has been properly handled in the ebuild, then an emerge
should succeed. And, RTR being set to “No” indicates that there aren’t any
tests to perform other than those defined and handled within the ebuild.

Restricting the set to RTR=no would eliminate special cases needing to
be taken into consideration.

Of course, RTR being unset or set to yes should be skipped.

We could initially start with stablebot only adding a comment to a bug
that it thinks it’s safe to stabilize the subject. This would give us
some time to gain confidence in it and/or weed out the bugs.


signature.asc
Description: Digital signature


Re: [gentoo-dev] AMD64 Arch Testers needed urgently

2017-12-13 Thread Aaron W. Swenson
On 2017-12-13 13:20, Lucas Ramage wrote:
> > In  my discussions with other developers, I've found that this is the
> ​> ​
> biggest concern. Most devs are runnning ~amd64, so they don't feel that
> ​> ​
> they can mark things stable.
> 
> W
> ​hat about running a stable chroot?​ Are there any tools that can be used
> to automate this process?

Yes, a stable chroot is okay, and there is app-portage/tatt that can run
through the various USE flag combinations for you.

It’s output isn’t terribly helpful, so it takes a little while to
understand what it’s trying to tell you.


signature.asc
Description: Digital signature


Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists

2017-12-05 Thread Aaron W. Swenson
On 2017-12-03 00:18, Michał Górny wrote:
> …snip…

I understand, and sympathize with, the motivation to create another list
and restrict gentoo-dev. And, I agree with most of the points,
especially given some of the more recent events.

I still vote no.

gentoo-dev is supposed to be for open discussions on the development of
Gentoo. I’ve come to expect to have some not so pleasant or diplomatic
replies.

Yes, there are a couple individuals that are being awfully noisy, but
the vaster majority are not. By splitting the list, we’re just moving that
noise elsewhere so we can ignore them.

This proposal avoids rather than addresses the problem.


signature.asc
Description: Digital signature


Re: Accidental spoofing -> Re: [gentoo-dev] We Are All wltjr On This Blessed Day

2017-12-05 Thread Aaron W. Swenson
On 2017-12-05 10:51, Georg Rudoy wrote:
> From and Reply-To are two separate fields.

Yes, but that wasn’t what was being discussed. I was giving an example
as to why the From field should be editable in an email client.

I’ll set the Reply-To for emails to be directed to the proper contact
point, but it’s nonsensical to say it’s coming from a human point of
contact when it’s an “automated” message.

The Reply-To still wouldn’t be m...@example.com either. Rather, it’d be set to
customer-serv...@example.com, or whatever it needs to be. donotreply is
a succinct way of communicating that the recipient doesn’t or shouldn’t
have to reply to the email and that it’s an automated email.


signature.asc
Description: Digital signature


Re: Accidental spoofing -> Re: [gentoo-dev] We Are All wltjr On This Blessed Day

2017-12-05 Thread Aaron W. Swenson
On 2017-12-04 18:08, William L. Thomson Jr. wrote:
> On Mon, 4 Dec 2017 18:01:39 -0500
> "William L. Thomson Jr."  wrote:
> 
> > On Mon, 4 Dec 2017 14:43:15 -0800
> > Matt Turner  wrote:
> > >
> > > Sorry. I think I was confusing a number of irritating things you've
> > > done: email spoofing,  
> > 
> > That was a complete accident due to a new version of Kmail that had
> > the from field editable by default. It was NOT intentional. Not the
> > 1st time. The 2nd time was for confirmation. I was in disbelieve such
> > abuse was even possible with @gentoo.org addresses. That was a
> > shocking discovery given I have administrated mail severs for quite
> > some time. In part why I use ASSP.
> 
> I filed a bug with KDE on that but of course went WONTFIX. I think its
> horrible as it allows people to spoof, spam and do bad things...
> 
> Make From field in the composer read only
> https://bugs.kde.org/show_bug.cgi?id=373313
> 
> Me personally I would never make software or change it to allow people
> to make such a mistake. Others felt differently. I stopped using
> Kmail2. I use Claws-mail now, but it also has editable from field :(
> 
> Email clients should only allow email address that are in configured
> accounts. But that is my opinion. Others seem to feel differently. I
> cannot see any good reasons for such really.

One reason is to send from a nonexistent account to avoid getting
replies in the first place.

Like donotre...@example.com for order updates, confirmation emails, and
so on. A person doesn’t actually exist behind the email, but emails have
to say they’re coming from somewhere. And, a properly setup SMTP server
will need an credentials to send those email. If donotreply doesn’t
exist, then the account setup will (probably) have an email address that
differs from the one that’s used to compose the email.

I use it myself when I need to inform our customers about a change. I
don’t want to field hundreds of email personally, so I change the from
address.

So, email clients most definitely should allow an individual to change
the from field. It’s a good thing. But, like any other tool, it can be
used improperly.


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: [RFC, PATCH] user.eclass: gracefully return when unprivileged

2017-11-27 Thread Aaron W. Swenson
On 2017-11-26 10:02, Benda Xu wrote:
> Hi Patrick,
> 
> Patrick McLean  writes:
> 
> > I use portage as non-root all the time when developing and testing
> > ebuilds, via the "ebuild" command.
> 
> The enewgroup and enewuser are used in pkg_* functions, as documented in
> user.eclass _assert_pkg_ebuild_phase() function.  They require root to
> execute.
> 
> So no worries, your workflow will not be affected.

Actually, it will probably be better.

You should now be able to do compilation and tests without having the
user/group created. For example, dev-db/postgresql doesn’t need the
postgres system user and group in order to successfully run through
src_test and src_install. It just needs the user/group at run time.


signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH 1/2] glep-0042: Drop requirement for detached signatures.

2017-11-27 Thread Aaron W. Swenson
On 2017-11-27 00:13, Ulrich Müller wrote:
> …
> +.. Note:: A previous version of this GLEP had required that news items must
> +   be signed with a detached OpenPGP signature. This was no longer deemed
> +   necessary after moving news items to a Git repository with commit signing,
> +   and deployment of full-tree verification per GLEP 74 [#glep-74]_.

This was deemed no longer necessary…


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: [PATCH 2/2] glep-0042: Update and clarify naming rules.

2017-11-27 Thread Aaron W. Swenson
On 2017-11-27 10:54, Duncan wrote:
> Ulrich Müller posted on Mon, 27 Nov 2017 00:30:49 +0100 as excerpted:
> 
> > diff --git a/glep-0042.rst b/glep-0042.rst
> > index 7726ea4..90ae0b2 100644
> > --- a/glep-0042.rst
> > +++ b/glep-0042.rst
> > @@ -179,7 +179,9 @@ form ``-mm-dd-short-name``, where ```` is the 
> > year (e.g. ``2005``),
> >  ``mm`` is the month (``01`` through ``12``) and dd is the day of the month
> >  (``01`` through ``31``). The ``short-name`` is a very short name 
> > describing the
> >  news item (e.g. ``yoursql-updates``), consisting only of the characters 
> > ``a-z``,
> > -``0-9``, ``+`` (plus), ``-`` (hyphen) and ``_`` (underscore).
> > +``0-9``, ``+`` (plus), ``-`` (hyphen) and ``_`` (underscore). While there
> > +is no hard restriction for the length of ``short-name``, it is strongly
> > +recommended to limit it to at most 20 characters.
> 
> Arguably bikeshedding but changing up the last sentence to read a bit smoother
> (I skipped formatting)...
> 
> While there is no hard restriction on the length of short-name,
> limiting it to 20 characters is strongly recommended.
> 
> (s/for/on/, reversing order of the limit and strongly recommended.)

I agree. This one reads a bit better.

Does it matter if people notice the recommendation? Should it be its own
paragraph for emphasis?


signature.asc
Description: Digital signature


Re: [gentoo-dev] Packages up for grabs: app-misc/goobook

2017-10-13 Thread Aaron W. Swenson
On 2017-10-13 17:20, Jonas Stein wrote:
> Dear all,
> 
> The following packages are up for grabs:
> 
> app-misc/goobook
> 
> after retirement of the proxied maintainer.
> 
> https://packages.gentoo.org/packages/app-misc/goobook
> 
> The package is available on many large distributions:
> https://repology.org/metapackage/goobook/versions

Yes, but is goobook still active? Last I looked, upstream development
had stalled.


signature.asc
Description: Digital signature


Re: [gentoo-dev] RFC v2: news item for the 17.0 profiles

2017-10-11 Thread Aaron W. Swenson
On 2017-10-10 21:16, Andreas K. Huettel wrote:
> …
> Switching involves the following steps:
> If not already done,
> * Use gcc-config to select gcc-6.4.0 (or later) as system compiler
> * Re-source /etc/profile:
> . /etc/profile
> * Re-emerge libtool

Should probably instruct users to upgrade all packages first because it
can be, as I’ve experienced, nearly impossible to upgrade GCC if the
world isn’t up to the latest stable.

An ‘emerge -avuDN world’ should do the trick as a first step.

> Then,
> * Select the new profile with eselect
> * Re-emerge, in this sequence, the selected gcc, binutils, and glibc
> emerge -1 sys-devel/gcc:6.4.0
> emerge -1 sys-devel/binutils
> emerge -1 sys-libs/glibc

Some of these can take a while. Maybe we want to spell it out:

for p in sys-devel/gcc:6.4.0 sys-devel/binutils sys-libs/glibc; do
emerge -1 $p || break
done


signature.asc
Description: Digital signature


Re: [gentoo-dev] Packages up for grabs net-im/pyaim-t

2017-10-09 Thread Aaron W. Swenson
On 2017-10-09 16:03, Brian Evans wrote:
> On 10/9/2017 3:49 PM, Jonas Stein wrote:
> > Dear all,
> > 
> > The following packages are up for grabs:
> > 
> > net-im/pyaim-t
> > 
> > after retirement of the proxied maintainer.
> > 
> 
> AOL Instant Messenger will be retired on Dec 15, 2017.  Last rite this
> and any other package that is the sole consumer of that service.
> 
> Brian
> 

+1 for last rite. Not worth the effort, if any, at this point.


signature.asc
Description: Digital signature


Re: [gentoo-dev] RFC v2: News item: Perl 5.26 update

2017-10-08 Thread Aaron W. Swenson
On 2017-10-08 14:01, Andreas K. Huettel wrote:
> OK so here's the updated version:
> …
> Typical errors are 

Needs a colon.

Typical errors are:

But the rest looks good to me.

I don’t know how to write “good job” without it sounding
patronizing. But here it is anyway: Good job!


signature.asc
Description: Digital signature


Re: [gentoo-dev] RFC: News item: Perl 5.26 update

2017-10-07 Thread Aaron W. Swenson
On 2017-10-07 17:03, Andreas K. Huettel wrote:
> …
> This release brings several incompatible changes, also as a
> consequence of fixing a security problem [1].

This reads kind of awkwardly. Maybe something along this lines of:

This release brings several incompatible changes as a result of
deprecations coming to term [#] and mitigating a potential security
issue [#].

I wouldn’t really consider the security risk eliminated, but
mitigated as the vector of attack remains if program or module adds the
current working directory to @INC on its own. The interpreter just isn’t
adding it to @INC.

> Typical errors are 
>"Can't locate inc/... in @INC (you may need to install the inc::... 
> module)"
>"error: ... has no member named ‘op_sibling’"
>"Unescaped left brace in regex is illegal in ..."

I would make this look more like a proper list.

Typical errors are:
  * Can't locate inc/... in @INC (you may need to install the
inc::... module)
  * error: ... has no member named ‘op_sibling’
  * Unescaped left brace in regex is illegal in ...


signature.asc
Description: Digital signature


Re: [gentoo-dev] [RFC] News item: app-portage/gentoolkit-dev deprecation/removal

2017-09-18 Thread Aaron W. Swenson
On 2017-09-18 15:09, Paul Varner wrote:
> Please provide any feedback on the upcoming deprecation and removal of 
> app-portage/gentoolkit-dev with the upcoming stabilization of 
> app-portage/gentoolkit-0.4.0 (Bug 627350)
> 
> Regards,
> Paul

> Title: app-portage/gentoolkit-dev deprecation/removal
> Author: Paul Varner 
> Posted: 2017-09-19
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: app-portage/gentoolkit-dev
> 
> The app-portage/gentoolkit-dev package has been deprecated and the ebump,
> ekeyword and imlate have been moved to the app-portage/gentoolkit-0.4.0
> package. With the upcoming marking of >=app-portage/gentoolkit-0.4.0 stable,
> users will need to take action since gentoolkit-dev and those versions of
> gentoolkit block each other.
> 
> In order to upgrade to the new version of gentoolkit, you will need to resolve
> the blocks. In many cases, removing app-portage/gentoolkit-dev from the world
> set will allow Portage to automatically resolve the blockers and remove 
> gentoolkit-dev. You can remove it from world using the following command.
> 
> emerge --deselect app-portage/gentoolkit-dev
> 
> If that fails to work, then unmerge the gentoolkit-dev package with
> 
> emerge --unmerge app-portage/gentoolkit-dev
> 

Why not just instruct users to unmerge rather than attempt something
that may or may not work as a first step?

The instructions would the be simplified to:
In order to upgrade to the new version of app-portage/gentoolkit, first
unmerge app-portage/gentoolkit-dev then emerge app-portage/gentoolkit:

   # emerge --unmerge app-portage/gentoolkit-dev
   # emerge --ask app-portage/gentoolkit


signature.asc
Description: Digital signature


Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal

2017-08-19 Thread Aaron W. Swenson
On 2017-08-19 13:01, Francisco Blas Izquierdo Riera (klondike) wrote:
> El 19/08/17 a las 12:37, Aaron W. Swenson escribió:
> > On 2017-08-15 17:01, Francisco Blas Izquierdo Riera (klondike) wrote:
> >> Hi!
> >>
> >> I'd like to get this one up by Saturday so that we can proceed with
> >> masking and removing of the hardened-sources after upstream stopped
> >> releasing new patches.
> > I hope I’m not too late.
> >
> >> We'd like to note that all the userspace hardening and MAC support
> >> for SELinux provided by Gentoo Hardened will still remain there and
> >> is unaffected by this removal.
> > Where is there? I think you’re talking about the packages, but the news
> > item is about the kernels. It would help to be more specific here.
> >
> > That’s all I had that the others hadn’t touched on.
> 
> Do you think something like that is better then?
> 
> We'd like to note that all the userspace hardening and MAC support
> for SELinux provided by Gentoo Hardened will still remain available
> on the portage. Keep in mind though that the security provided by
> these features will be weakened a bit when using
> sys-kernel/gentoo-sources. Also, all PaX related packages other than
> the hardened-sources will remain available for the time being.
> 
> 

Much better. We should mention that we’re specifically discussing
packages and not portage itself. At least, that’s my understanding from
your edit.

Here’s my take on it:

We'd like to note that all the userspace hardening and MAC support for
SELinux provided by Gentoo Hardened will still remain in the packages
found in portage. Keep in mind, though, that the security provided by
these features will be weakened a bit when using
sys-kernel/gentoo-sources. Also, all PaX related packages, except
sys-kernel/hardened-sources, will remain available for the time being.


signature.asc
Description: Digital signature


Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal

2017-08-19 Thread Aaron W. Swenson
On 2017-08-15 17:01, Francisco Blas Izquierdo Riera (klondike) wrote:
> Hi!
> 
> I'd like to get this one up by Saturday so that we can proceed with
> masking and removing of the hardened-sources after upstream stopped
> releasing new patches.

I hope I’m not too late.

> We'd like to note that all the userspace hardening and MAC support
> for SELinux provided by Gentoo Hardened will still remain there and
> is unaffected by this removal.

Where is there? I think you’re talking about the packages, but the news
item is about the kernels. It would help to be more specific here.

That’s all I had that the others hadn’t touched on.


signature.asc
Description: Digital signature


Re: [gentoo-dev] New eclass: opam.eclass

2017-07-24 Thread Aaron W. Swenson
On 2017-07-24 17:20, Alexis Ballier wrote:
> Hey,
> 
> Here is an eclass that would allow me to factor quite a bit of
> redundant code.
> 
> …
>   if [ -d "${ED}/usr/share/doc/${PF}/${PN}" ] ; then

It’s always been recommended to me that we should use the [[ … ]] form.

Otherwise, looks good to me.


signature.asc
Description: Digital signature


Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

2017-07-16 Thread Aaron W. Swenson
On 2017-07-15 01:34, Raymond Jennings wrote:
> On Wed, Jul 12, 2017 at 9:07 AM, Gordon Pettey  wrote:
> 
> > On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr. <
> > wlt...@o-sinc.com> wrote:
> >
> >> On Thu, 13 Jul 2017 01:03:00 +1000
> >> Sam Jorna  wrote:
> >>
> >> > $ emerge -C apg
> >> >  * This action can remove important packages! In order to be safer,
> >> > use
> >> >  * `emerge -pv --depclean ` to check for reverse dependencies
> >> > before
> >> >  * removing packages.
> >>
> >> That is my point. That message is always there. The chance that it is
> >> ignored is very high.
> >>
> >>
> > Stop signs on the road are also always there. If you get arrested for
> > ignoring it, it is not because the stop signs are always there, it is
> > because you ignored it. Don't ignore the warning.
> >
> 
> Just to be pedantic:
> 
> You can usually only be arrested for felonies and misdemeanors.
> 
> Ignoring a stop sign and most traffic related offenses in general are
> infractions or violations.  For those, you just get cited with a nasty
> ticket and an annoying fine.

Well, that depends. One stop sign and no other vehicles involved? Just a
ticket.

Run a stop sign and while swerving around the road risking the lives of
others because you can’t be bother to pay attention to the signs? That’s
an arrest.


signature.asc
Description: Digital signature


Re: [gentoo-dev] New eclasses and USE_EXPAND: postgres{,-multi}.eclass

2017-04-22 Thread Aaron W. Swenson
On 2017-04-22 22:38, Mart Raudsepp wrote:
> I do not believe that DESCRIPTION should have a dot in the end, because
> that takes away from this precious nonsensical 80 characters limit,
> making it 79 instead. On that note, I believe the limit should be
> raised to at least 100 characters.
> 
> Oh wait, weren't you going to title this about period mark at the end
> of DESCRIPTION...?
> 
> 
> Mart
> 

I was, but I was afraid I might be tarred and feathered.

And, I’m not cool enough to rock feathers.


signature.asc
Description: Digital signature


[gentoo-dev] New eclasses and USE_EXPAND: postgres{,-multi}.eclass

2017-04-21 Thread Aaron W. Swenson
I’ve email previously on this, but the eclasses have been through a bit
of a change since then.

postgres.eclass has some common functions and initializes some variables
that are used in many of the PostgreSQL-related packages.

postgres-multi.eclass makes it possible to install one package (e.g.,
dev-db/postgis) to all dev-db/postgresql slots. This will eliminate one
pain point of migrating PostgreSQL (e.g., from 9.6 to 10).

A lot of the packages in my overlay[1] have been modified to use this
eclass, notably dev-db/postgis and dev-db/pgpool2.

Naturally, I’ll want to add a USE_EXPAND for POSTGRES_TARGETS as the
eclasses use postgres_targets* use flags to control which slots to build
for.

1: https://github.com/titanofold/titanofold-gentoo-x86/tree/pgsql-eclass
# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

inherit multibuild postgres
EXPORT_FUNCTIONS pkg_setup src_prepare src_compile src_install src_test


# @ECLASS: postgres-multi
# @MAINTAINER:
# PostgreSQL <pgsql-b...@gentoo.org>
# @AUTHOR: Aaron W. Swenson <titanof...@gentoo.org>
# @BLURB: An eclass to build PostgreSQL-related packages against multiple slots
# @DESCRIPTION:
# postgres-multi enables ebuilds, particularly PostgreSQL extensions, to
# build and install for one or more PostgreSQL slots as specified by
# POSTGRES_TARGETS use flags.


case ${EAPI:-0} in
5|6) ;;
*) die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}" ;;
esac


# @ECLASS-VARIABLE: POSTGRES_COMPAT
# @REQUIRED
# @DESCRIPTION:
# A Bash array containing a list of compatible PostgreSQL slots as
# defined by the developer. Must be declared before inheriting this
# eclass. Example: POSTGRES_COMPAT=( 9.4 9.{5,6} )
if ! declare -p POSTGRES_COMPAT &>/dev/null; then
die 'Required variable POSTGRES_COMPAT not declared.'
fi

# @ECLASS-VARIABLE: _POSTGRES_INTERSECT_SLOTS
# @INTERNAL
# @DESCRIPTION:
# A Bash array containing the intersect of POSTGRES_TARGETS and
# POSTGRES_COMPAT.
export _POSTGRES_INTERSECT_SLOTS=( )

# @FUNCTION _postgres-multi_multibuild_wrapper
# @INTERNAL
# @USAGE: _postgres-multi_multibuild_wrapper  [ ...]
# @DESCRIPTION:
# For the given variant, set the values of the PG_SLOT, PG_CONFIG, and
# PKG_CONFIG_PATH environment variables accordingly and replace any
# appearance of @PG_SLOT@ in the command and arguments with value of
# ${PG_SLOT}.
_postgres-multi_multibuild_wrapper() {
debug-print-function ${FUNCNAME} "${@}"
export PG_SLOT=${MULTIBUILD_VARIANT}
export PG_CONFIG=$(which pg_config${MULTIBUILD_VARIANT//./})
if [[ -n ${PKG_CONFIG_PATH} ]] ; then
PKG_CONFIG_PATH="$(${PG_CONFIG} 
--libdir)/pkgconfig:${PKG_CONFIG_PATH}"
else
PKG_CONFIG_PATH="$(${PG_CONFIG} --libdir)/pkgconfig"
fi
export PKG_CONFIG_PATH

$(echo "${@}" | sed "s/@PG_SLOT@/${PG_SLOT}/g")
}

# @FUNCTION: postgres-multi_foreach
# @USAGE: postgres-multi_foreach   [ ...]
# @DESCRIPTION:
# Run the given command in the package's build directory for each
# PostgreSQL slot in the intersect of POSTGRES_TARGETS and
# POSTGRES_COMPAT and user-enabled slots. The PG_CONFIG and
# PKG_CONFIG_PATH environment variables are updated on each iteration to
# point to the matching pg_config command and pkg-config metadata files,
# respectively, for the current slot. Any appearance of @PG_SLOT@ in the
# command or arguments will be substituted with the slot (e.g., 9.5) of
# the current iteration.
postgres-multi_foreach() {
local MULTIBUILD_VARIANTS=("${_POSTGRES_INTERSECT_SLOTS[@]}")

multibuild_foreach_variant \
_postgres-multi_multibuild_wrapper run_in_build_dir ${@}
}

# @FUNCTION: postgres-multi_forbest
# @USAGE: postgres-multi_forbest   [ ...]
# @DESCRIPTION:
# Run the given command in the package's build directory for the highest
# slot in the intersect of POSTGRES_COMPAT and POSTGRES_TARGETS. The
# PG_CONFIG and PKG_CONFIG_PATH environment variables are set to the
# matching pg_config command and pkg-config metadata files,
# respectively. Any appearance of @PG_SLOT@ in the command or arguments
# will be substituted with the matching slot (e.g., 9.5).
postgres-multi_forbest() {
# POSTGRES_COMPAT is reverse sorted once in postgres.eclass so
# element 0 has the highest slot version.
local MULTIBUILD_VARIANTS=("${_POSTGRES_INTERSECT_SLOTS[0]}")

multibuild_foreach_variant \
_postgres-multi_multibuild_wrapper run_in_build_dir ${@}
}

# @FUNCTION: postgres-multi_pkg_setup
# @REQUIRED
# @USAGE: postgres-multi_pkg_setup
# @DESCRIPTION:
# Initialize internal environment variable(s). This is required if
# pkg_setup() is declared in the ebuild.
postgres-multi_pkg_setup() {
local user_slot

for

Re: [gentoo-dev] Re: Re: stable gcc 5.4.0 ??

2017-04-18 Thread Aaron W. Swenson
On 2017-04-18 14:27, James Le Cuirot wrote:
> On Tue, 18 Apr 2017 15:12:13 +0200
> Jörg Schaible  wrote:
> 
> > As said, I synced the tree twice this morning (4 hours ago) and the
> > KEYWORDS in the ebuild do not declare amd64 as stable although it was
> > committed to GIT already yesterday. And this is no wonder, because
> > the stable branch of the GIT mirror is still not up-to-date:
> > https://github.com/gentoo-mirror/gentoo/tree/stable/sys-devel/gcc
> 
> It's been held up by this outstanding issue:
> https://qa-reports.gentoo.org/output/gentoo-ci/58d678e2a/output.html#dev-db/psqlodbc

Oh, that’s ridiculous.

I’ve just dropped the particular ebuild that used pgsql-9.1 now.


signature.asc
Description: Digital signature


Re: [gentoo-dev] New Eclasses: postgres and postgres-multi

2016-01-26 Thread Aaron W. Swenson
On 2016-01-25 10:31, Ian Stakenvicius wrote:
> On 23/01/16 10:51 AM, Ian Stakenvicius wrote:
> >> On Jan 22, 2016, at 3:11 PM, Aaron W. Swenson
> >> <titanof...@gentoo.org> wrote:
> >> 
> >> I would like some feedback on the documentation/comments in
> >> the eclass. I'm certain it could be improved. Though, if you
> >> were able to follow them (not a slight, just you were the first
> >> to follow them), I might have done good enough.
> >> 
> > 
> > I'll have another look; i don't think I read any of the docs,
> > just looked to see that PG_CONFIG was set for me and confirmed
> > things looked to work the same as multilib-minimal.
> 
> OK here's my full review (with docs and all):
> 
> postgres.eclass:
> 
> postgres_check_slot() <-- #1, not seeing a need for this as
> dependencies should be forced now due to USE flag provisions.  #2,
> though, the documentation says it should be used in pkg_pretend but
> then in the code there's an exclusion to make it a no-op when it's
> run in pkg_pretend.  Perhaps it's supposed to be run in pkg_setup??

I'm a bit uncertain what to do with this. There are a few ebuilds that
check that the slot is set properly, and they do so as early as possible
so the user doesn't start the emerge and walk away thinking everything
will be okay. So, it tries to run the check, but won't die if the
PostgreSQL eselect module hasn't been emerged yet.

I could probably replace it with a pkg_setup that sets the PG_CONFIG
variable globally.

But, this would probably require another USE_EXPAND to do a single
target. I'm not against this, I just don't want to go use flag crazy.

> postgres_new_user() <-- the documentation seems a little bit unclear
> on this one..  It looks like it creates the 'postgres' user/group
> and optionally it also creates an additional specified user/group..
>  But i'm not sure how creating new users/groups here instead of with
> calling enewuser/enewgroup directly in the ebuild is helpful per
> se...?  It also seems a bit redundant if you wanted to create say, 2
> or 3 extra users/groups, to repeatedly call enewuser postgres 

You're right about how it works. I could scratch the rest of the
function and have it just create the postgres system group and
user. It's intended to make it so that a developer doesn't have to look
up the postgres system user and group parameters in another ebuild, or
dig around for nonexistent documentation, which will be rectified but
that'll still be difficult to search.

> postgres-multi.eclass:
> 
> #1 - main description could perhaps be changed from:
> 
> # build against any and all compatible PostgreSQL slots that are also
> # enabled by the user.
> 
> to:
> 
> # build and install for one or more PostgreSQL slots as specified by
> # POSTGRES_TARGETS use flags.

Done.

> #2 - POSTGRES_COMPAT , needs an example and/or text to describe the
> syntax of the slot specification.

Done.

> #3 - _POSTGRES_UNION_SLOTS -- you actually mean here the
> intersection between the two sets, rather than the union, right?
> Var can likely stay as-is but the description should probably be
> updated.

Well, that's a bit embarrassing. You'd think I'd know the difference by
now. Renamed it _POSTGRES_INTERSECT_SLOTS and corrected other
appearances of union.

> #4 - postgres-multi_foreach() -- this actually runs in the builddir,
> not the source dir as mentioned in the text.

Done.

> #5 - postgres-multi_forbest() -- maybe expand on what the "best"
> slot is here, ie that it's the lexicographically biggest slot rather
> than something else (like, say, the slot that's currently eselected)

Done.

> #6 - need docs for postgres-multi_src_prepare() and so forth -- just
> simple stuff will suffice I think:  postgres-multi_src_prepare()
> copies ${S} into a build directory for each target PG_SLOT and
> should be specified; the others are default functions that are
> provided for convenience, but postgres-multi_foreach should be used
> instead of these when customization is necessary.

Done.

> ...and I think that's it..

Thanks!


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: New Eclasses: postgres and postgres-multi

2016-01-26 Thread Aaron W. Swenson
On 2016-01-25 22:34, Jonathan Callen wrote:
> On 01/25/2016 07:29 AM, Aaron W. Swenson wrote:
> > On 2016-01-24 18:44, Michael Orlitzky wrote:
> >> On 01/24/2016 06:29 PM, Aaron W. Swenson wrote:
> >>> Okay, provided that the new USE_EXPAND is okay for
> >>> POSTGRES_TARGETS, attached are the eclasses that I'll commit to
> >>> the tree.
> >>> 
> >> 
> >>> case ${EAPI:-0} in 0|1|2|3|4) die "postgres-multi.eclass
> >>> requires EAPI 5 or higher" ;; *) ;; esac
> >> 
> >> Does this really work with EAPI=6? I didn't try, but it looks
> >> like it would need an eapply_user somewhere in src_prepare. And,
> >> pedantry warning, there's no such thing as "EAPI 5 or higher."
> >> The lawyers will tell you to do something like this instead
> >> (stolen from git-r3):
> >> 
> >> case "${EAPI:-0}" in 5|6) ;; *) die "Unsupported EAPI=${EAPI}
> >> (unknown) for ${ECLASS}" ;; esac
> >> 
> >> That will require an edit for every new EAPI, but prevents weird
> >> crashes from things like a missing eapply_user.
> >> 
> >> 
> > 
> > Thank you.
> > 
> > I've added the eapply_user to postgres-multi and modified the case 
> > condition to match the hot goods you're selling on the sly.
> > 
> 
> You missed the fix for EAPI in postgres-multi.eclass (it looks okay in
> the other eclass, though).

Fixed. Thanks!


signature.asc
Description: Digital signature


Re: [gentoo-dev] New USE_EXPAND: POSTGRES_TARGETS

2016-01-25 Thread Aaron W. Swenson
On 2016-01-24 18:33, Michael Orlitzky wrote:
> On 01/24/2016 06:21 PM, Aaron W. Swenson wrote:
> > Attached are the changes I'm looking to make. I've never play with
> > global use flags, so I'd like for somebody to make sure I've done them
> > right.
> > 
> 
> Tiny typo "postges.eclass".

Thank you. Untypoed.


signature.asc
Description: Digital signature


Re: [gentoo-dev] New Eclasses: postgres and postgres-multi

2016-01-25 Thread Aaron W. Swenson
On 2016-01-24 18:44, Michael Orlitzky wrote:
> On 01/24/2016 06:29 PM, Aaron W. Swenson wrote:
> > Okay, provided that the new USE_EXPAND is okay for POSTGRES_TARGETS,
> > attached are the eclasses that I'll commit to the tree.
> > 
> 
> > case ${EAPI:-0} in
> >   0|1|2|3|4) die "postgres-multi.eclass requires EAPI 5 or higher" ;;
> >   *) ;;
> > esac
> 
> Does this really work with EAPI=6? I didn't try, but it looks like it
> would need an eapply_user somewhere in src_prepare. And, pedantry
> warning, there's no such thing as "EAPI 5 or higher." The lawyers will
> tell you to do something like this instead (stolen from git-r3):
> 
>   case "${EAPI:-0}" in
> 5|6)
> ;;
> *)
> die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
> ;;
>   esac
> 
> That will require an edit for every new EAPI, but prevents weird crashes
> from things like a missing eapply_user.
> 
> 

Thank you.

I've added the eapply_user to postgres-multi and modified the case
condition to match the hot goods you're selling on the sly.
# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

inherit multibuild postgres
EXPORT_FUNCTIONS pkg_setup src_prepare src_compile src_install src_test


# @ECLASS: postgres-multi
# @MAINTAINER:
# PostgreSQL <pgsql-b...@gentoo.org>
# @AUTHOR: Aaron W. Swenson <titanof...@gentoo.org>
# @BLURB: An eclass to build PostgreSQL-related packages against multiple slots
# @DESCRIPTION:
# postgres-multi enables ebuilds, particularly PostgreSQL extensions, to
# build against any and all compatible PostgreSQL slots that are also
# enabled by the user. Additionally makes a developer's life easier with
# exported default functions to do the right thing.


case ${EAPI:-0} in
  0|1|2|3|4) die "postgres-multi.eclass requires EAPI 5 or higher" ;;
  *) ;;
esac


# @ECLASS-VARIABLE: POSTGRES_COMPAT
# @REQUIRED
# @DESCRIPTION:
# A Bash array containing a list of compatible PostgreSQL slots as
# defined by the developer. Must be declared before inheriting this eclass.
if ! declare -p POSTGRES_COMPAT &>/dev/null; then
die 'Required variable POSTGRES_COMPAT not declared.'
fi

# @ECLASS-VARIABLE: _POSTGRES_UNION_SLOTS
# @INTERNAL
# @DESCRIPTION:
# A Bash array containing the union set of user-enabled slots that are
# also in POSTGRES_COMPAT.
export _POSTGRES_UNION_SLOTS=( )

# @FUNCTION _postgres-multi_multibuild_wrapper
# @INTERNAL
# @USAGE: _postgres-multi_multibuild_wrapper  [ ...]
# @DESCRIPTION:
# For the given variant, set the values of the PG_SLOT and PG_CONFIG
# environment variables accordingly and replace any appearance of
# @PG_SLOT@ in the command and arguments with value of ${PG_SLOT}.
_postgres-multi_multibuild_wrapper() {
debug-print-function ${FUNCNAME} "${@}"
export PG_SLOT=${MULTIBUILD_VARIANT}
export PG_CONFIG=$(which pg_config${MULTIBUILD_VARIANT//./})
$(echo "${@}" | sed "s/@PG_SLOT@/${PG_SLOT}/g")
}

# @FUNCTION: postgres-multi_foreach
# @USAGE: postgres-multi_foreach   [ ...]
# @DESCRIPTION:
# Run the given command in the package's source directory for each
# PostgreSQL slot in the union set of the developer defined
# POSTGRES_COMPAT and user-enabled slots. The PG_CONFIG environment
# variable is updated on each iteration to point to the matching
# pg_config command for the current slot. Any appearance of @PG_SLOT@ in
# the command or arguments will be substituted with the slot (e.g., 9.5)
# of the current iteration.
postgres-multi_foreach() {
local MULTIBUILD_VARIANTS=("${_POSTGRES_UNION_SLOTS[@]}")

multibuild_foreach_variant \
_postgres-multi_multibuild_wrapper run_in_build_dir ${@}
}

# @FUNCTION: postgres-multi_forbest
# @USAGE: postgres-multi_forbest   [ ...]
# @DESCRIPTION:
# Run the given command in the package's source directory for the best,
# compatible PostgreSQL slot. The PG_CONFIG environment variable is set
# to the matching pg_config command. Any appearance of @PG_SLOT@ in the
# command or arguments will be substituted with the matching slot (e.g., 9.5).
postgres-multi_forbest() {
# POSTGRES_COMPAT is reverse sorted once in postgres.eclass so
# element 0 has the highest slot version.
local MULTIBUILD_VARIANTS=("${_POSTGRES_UNION_SLOTS[0]}")

multibuild_foreach_variant \
_postgres-multi_multibuild_wrapper run_in_build_dir ${@}
}

# @FUNCTION: postgres-multi_pkg_setup
# @USAGE: postgres-multi_pkg_setup
# @DESCRIPTION:
# Initialize internal environment variable(s). This is required if
# pkg_setup() is declared in the ebuild.
postgres-multi_pkg_setup() {
local user_slot

for user_slot in "${

Re: [gentoo-dev] New USE_EXPAND: POSTGRES_TARGETS

2016-01-24 Thread Aaron W. Swenson
Attached are the changes I'm looking to make. I've never play with
global use flags, so I'd like for somebody to make sure I've done them
right.
# Copyright 1999-2016 Gentoo Foundation.
# Distributed under the terms of the GNU General Public License v2
# $Id$

# This file contains descriptions of POSTGRES_TARGETS USE_EXPAND flags.

postgres9_0 - Build against PostgreSQL 9.0
postgres9_1 - Build against PostgreSQL 9.1
postgres9_2 - Build against PostgreSQL 9.2
postgres9_3 - Build against PostgreSQL 9.3
postgres9_4 - Build against PostgreSQL 9.4
postgres9_5 - Build against PostgreSQL 9.5
postgres9_6 - Build against PostgreSQL 9.6
diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults
index 8775ecf..a0902bb 100644
--- a/profiles/base/make.defaults
+++ b/profiles/base/make.defaults
@@ -16,7 +16,7 @@ USE_EXPAND_VALUES_USERLAND="BSD GNU"
 
 # Env vars to expand into USE vars.  Modifying this requires prior
 # discussion on gentoo-dev@lists.gentoo.org.
-USE_EXPAND="ABI_MIPS ABI_PPC ABI_S390 ABI_X86 ALSA_CARDS APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS CPU_FLAGS_X86 CROSSCOMPILE_OPTS CURL_SSL DRACUT_MODULES DVB_CARDS ELIBC ENLIGHTENMENT_MODULES FCDSL_CARDS FFTOOLS FOO2ZJS_DEVICES FRITZCAPI_CARDS GPSD_PROTOCOLS GRUB_PLATFORMS INPUT_DEVICES KERNEL LCD_DEVICES LIBREOFFICE_EXTENSIONS LINGUAS LIRC_DEVICES MONKEYD_PLUGINS NETBEANS_MODULES NGINX_MODULES_HTTP NGINX_MODULES_MAIL OFED_DRIVERS OFFICE_IMPLEMENTATION OPENMPI_FABRICS OPENMPI_OFED_FEATURES OPENMPI_RM PHP_TARGETS PYTHON_SINGLE_TARGET PYTHON_TARGETS QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS RUBY_TARGETS SANE_BACKENDS USERLAND UWSGI_PLUGINS VIDEO_CARDS VOICEMAIL_STORAGE XFCE_PLUGINS XTABLES_ADDONS ROS_MESSAGES"
+USE_EXPAND="ABI_MIPS ABI_PPC ABI_S390 ABI_X86 ALSA_CARDS APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS CPU_FLAGS_X86 CROSSCOMPILE_OPTS CURL_SSL DRACUT_MODULES DVB_CARDS ELIBC ENLIGHTENMENT_MODULES FCDSL_CARDS FFTOOLS FOO2ZJS_DEVICES FRITZCAPI_CARDS GPSD_PROTOCOLS GRUB_PLATFORMS INPUT_DEVICES KERNEL LCD_DEVICES LIBREOFFICE_EXTENSIONS LINGUAS LIRC_DEVICES MONKEYD_PLUGINS NETBEANS_MODULES NGINX_MODULES_HTTP NGINX_MODULES_MAIL OFED_DRIVERS OFFICE_IMPLEMENTATION OPENMPI_FABRICS OPENMPI_OFED_FEATURES OPENMPI_RM PHP_TARGETS POSTGRES_TARGETS PYTHON_SINGLE_TARGET PYTHON_TARGETS QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS RUBY_TARGETS SANE_BACKENDS USERLAND UWSGI_PLUGINS VIDEO_CARDS VOICEMAIL_STORAGE XFCE_PLUGINS XTABLES_ADDONS ROS_MESSAGES"
 
 # USE_EXPAND variables whose contents are not shown in package manager
 # output. Changes need discussion on gentoo-dev.
@@ -35,6 +35,10 @@ KERNEL="linux"
 USERLAND="GNU"
 INPUT_DEVICES="keyboard mouse"
 
+# Aaron W. Swenson <titanof...@gentoo.org> (23 Jan 2016)
+# Default slot for postges.eclass and postgres-multi.eclass
+POSTGRES_TARGETS="postgres9_4"
+
 # Tomáš Chvátal <scarab...@gentoo.org> (23 Mar 2013)
 # By default enable libreoffice implementation only.
 OFFICE_IMPLEMENTATION="libreoffice"


signature.asc
Description: Digital signature


Re: [gentoo-dev] New Eclasses: postgres and postgres-multi

2016-01-24 Thread Aaron W. Swenson
Okay, provided that the new USE_EXPAND is okay for POSTGRES_TARGETS,
attached are the eclasses that I'll commit to the tree.
# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

inherit multibuild postgres
EXPORT_FUNCTIONS pkg_setup src_prepare src_compile src_install src_test


# @ECLASS: postgres-multi
# @MAINTAINER:
# PostgreSQL <pgsql-b...@gentoo.org>
# @AUTHOR: Aaron W. Swenson <titanof...@gentoo.org>
# @BLURB: An eclass to build PostgreSQL-related packages against multiple slots
# @DESCRIPTION:
# postgres-multi enables ebuilds, particularly PostgreSQL extensions, to
# build against any and all compatible PostgreSQL slots that are also
# enabled by the user. Additionally makes a developer's life easier with
# exported default functions to do the right thing.


case ${EAPI:-0} in
  0|1|2|3|4) die "postgres-multi.eclass requires EAPI 5 or higher" ;;
  *) ;;
esac


# @ECLASS-VARIABLE: POSTGRES_COMPAT
# @REQUIRED
# @DESCRIPTION:
# A Bash array containing a list of compatible PostgreSQL slots as
# defined by the developer. Must be declared before inheriting this eclass.
if ! declare -p POSTGRES_COMPAT &>/dev/null; then
die 'Required variable POSTGRES_COMPAT not declared.'
fi

# @ECLASS-VARIABLE: _POSTGRES_UNION_SLOTS
# @INTERNAL
# @DESCRIPTION:
# A Bash array containing the union set of user-enabled slots that are
# also in POSTGRES_COMPAT.
export _POSTGRES_UNION_SLOTS=( )

# @FUNCTION _postgres-multi_multibuild_wrapper
# @INTERNAL
# @USAGE: _postgres-multi_multibuild_wrapper  [ ...]
# @DESCRIPTION:
# For the given variant, set the values of the PG_SLOT and PG_CONFIG
# environment variables accordingly and replace any appearance of
# @PG_SLOT@ in the command and arguments with value of ${PG_SLOT}.
_postgres-multi_multibuild_wrapper() {
debug-print-function ${FUNCNAME} "${@}"
export PG_SLOT=${MULTIBUILD_VARIANT}
export PG_CONFIG=$(which pg_config${MULTIBUILD_VARIANT//./})
$(echo "${@}" | sed "s/@PG_SLOT@/${PG_SLOT}/g")
}

# @FUNCTION: postgres-multi_foreach
# @USAGE: postgres-multi_foreach   [ ...]
# @DESCRIPTION:
# Run the given command in the package's source directory for each
# PostgreSQL slot in the union set of the developer defined
# POSTGRES_COMPAT and user-enabled slots. The PG_CONFIG environment
# variable is updated on each iteration to point to the matching
# pg_config command for the current slot. Any appearance of @PG_SLOT@ in
# the command or arguments will be substituted with the slot (e.g., 9.5)
# of the current iteration.
postgres-multi_foreach() {
local MULTIBUILD_VARIANTS=("${_POSTGRES_UNION_SLOTS[@]}")

multibuild_foreach_variant \
_postgres-multi_multibuild_wrapper run_in_build_dir ${@}
}

# @FUNCTION: postgres-multi_forbest
# @USAGE: postgres-multi_forbest   [ ...]
# @DESCRIPTION:
# Run the given command in the package's source directory for the best,
# compatible PostgreSQL slot. The PG_CONFIG environment variable is set
# to the matching pg_config command. Any appearance of @PG_SLOT@ in the
# command or arguments will be substituted with the matching slot (e.g., 9.5).
postgres-multi_forbest() {
# POSTGRES_COMPAT is reverse sorted once in postgres.eclass so
# element 0 has the highest slot version.
local MULTIBUILD_VARIANTS=("${_POSTGRES_UNION_SLOTS[0]}")

multibuild_foreach_variant \
_postgres-multi_multibuild_wrapper run_in_build_dir ${@}
}

# @FUNCTION: postgres-multi_pkg_setup
# @USAGE: postgres-multi_pkg_setup
# @DESCRIPTION:
# Initialize internal environment variable(s). This is required if
# pkg_setup() is declared in the ebuild.
postgres-multi_pkg_setup() {
local user_slot

for user_slot in "${POSTGRES_COMPAT[@]}"; do
use "postgres_targets_postgres${user_slot/\./_}" && \
_POSTGRES_UNION_SLOTS+=( "${user_slot}" )
done

if [[ "${#_POSTGRES_UNION_SLOTS[@]}" -eq "0" ]]; then
die "One of the postgres_targets_postgresSL_OT use flags must 
be enabled"
fi

elog "Multibuild variants: ${_POSTGRES_UNION_SLOTS[@]}"
}

postgres-multi_src_prepare() {
if [[ "${#_POSTGRES_UNION_SLOTS[@]}" -eq "0" ]]; then
eerror "Internal array _POSTGRES_UNION_SLOTS is empty."
die "Did you forget to call postgres-multi_pkg_setup?"
fi

local MULTIBUILD_VARIANT
local MULTIBUILD_VARIANTS=("${_POSTGRES_UNION_SLOTS[@]}")
multibuild_copy_sources
}

postgres-multi_src_compile() {
postgres-multi_foreach emake
}

postgres-multi_src_install() {
postgres-multi_foreach emake install DESTDIR="${D}"
}

postgres-multi_src_test() {
pos

[gentoo-dev] New USE_EXPAND: POSTGRES

2016-01-23 Thread Aaron W. Swenson
In regards to:
https://archives.gentoo.org/gentoo-dev/message/877bee2af740e50e88f65cfe76126c0f

I'm planning on introducing a new eclass to the tree and am also
considering adding a new USE_EXPAND as well that would control the
specific slots the user would like to build PostgreSQL-related
extensions against.

Any objections?


signature.asc
Description: Digital signature


Re: [gentoo-dev] New USE_EXPAND: POSTGRES

2016-01-23 Thread Aaron W. Swenson
On 2016-01-23 09:48, Michael Orlitzky wrote:
> On 01/23/2016 07:26 AM, Aaron W. Swenson wrote:
> > In regards to:
> > https://archives.gentoo.org/gentoo-dev/message/877bee2af740e50e88f65cfe76126c0f
> > 
> > I'm planning on introducing a new eclass to the tree and am also
> > considering adding a new USE_EXPAND as well that would control the
> > specific slots the user would like to build PostgreSQL-related
> > extensions against.
> > 
> > Any objections?
> > 
> 
> There are three other USE_EXPAND with a similar aim:
> 
>   * PHP_TARGETS
>   * PYTHON_TARGETS
>   * RUBY_TARGETS
> 
> And the related,
> 
>   * QEMU_SOFTMMU_TARGETS
>   * QEMU_USER_TARGETS
> 
> If the "_TARGETS" suffix isn't somehow wrong in this context, having it
> might act as a little bit of documentation for users who are used to the
> variables above.

Good point.

POSTGRES_TARGETS it is.

Any objections or comments to that?


signature.asc
Description: Digital signature


Re: [gentoo-dev] New Eclasses: postgres and postgres-multi

2016-01-22 Thread Aaron W. Swenson
On 2016-01-22 11:51, Ian Stakenvicius wrote:
> The eclasses look good to go for me -- i've built an ebuild for pl/R
> using them and it works as expected (and it's nice to not have to
> define PG_CONFIG et. al. myself too).
> 
> Can the eclasses be migrated to the tree soon?

I wanted to test the eclass against pgTAP as well with the default
functions, but have been struggling the past couple days with getting my
machine up to date.

I would like some feedback on the documentation/comments in the
eclass. I'm certain it could be improved. Though, if you were able to
follow them (not a slight, just you were the first to follow them), I
might have done good enough.

> Also of note, it will be important to stabilize soon the ~arch
> versions of postgresql that have the install_bin path patched;
> otherwise if portage is, say, reinstalled with a different python
> selection between when postgres is emerged and one of these new
> postgres-multi packages are emerged, installation fails.

Oh, yes, I think we can move towards stabilization as soon as my
Internet is back up.


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

2016-01-18 Thread Aaron W. Swenson
On 2016-01-17 19:18, Dirkjan Ochtman wrote:
> Second attempt!
> 
> ===
> 
> Title: Upgrading Apache from 2.2 to 2.4
> Author: Dirkjan Ochtman 
> Content-Type: text/plain
> Posted: 2016-01-17
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: www-servers/apache
> 
> With the 2.4 branch released by upstream almost 4 years ago, stable
> Gentoo systems will soon be upgraded from apache 2.2 to apache 2.4.
> When upgrading, chances are some configuration changes have to be
> made. Upstream has a handy guide:
> 
> https://httpd.apache.org/docs/2.4/upgrading.html
> 
> For more information on all the new features, start here:
> 
> https://httpd.apache.org/docs/trunk/new_features_2_4.html
> 
> ===
> 
> A bit more concise and less personal. Better?
> 
> Cheers,
> 
> Dirkjan
> 

I think the use of "chances" here depresses the importance of
configuration changes.

This is debatable, but I think it should be "there are some
configuration changes that must be made."

Primarily in regards to the Order directive being (re)moved to an
optional module.


signature.asc
Description: Digital signature


Re: [gentoo-dev] New Eclasses: postgres and postgres-multi

2016-01-15 Thread Aaron W. Swenson
On 2016-01-13 11:11, Ian Stakenvicius wrote:
> The work looks really good, but I noticed that postgres-multi
> determins the variants to build against based on what's installed on
> disk via checking eselect..  I think it'd likely be better to
> instead have proper dependencies based on USE, much like how the
> python and ABI_* multibuilds work.  That would make the
> installations as well as the dependencies be determinstic rather
> than dynamic, which should support binpkgs -much- better (among
> other things).
> 
> The "|| ( postgresql:${SLOT1}= postgresql:${SLOT2}= ...)" RDEPEND
> that postgres.eclass works out is a little sketchy IMO,
> unfortunately, as the behaviour that occurs when more than one of
> those slots are installed is afaik a little unstable -- in theory,
> changes (including removal) of any of the options should trigger a
> rebuild but I don't know if it does, and I'm fairly certain that a
> simple --unmerge doesn't trigger a rebuild.  All of that goes away
> if you perform non-OR dependency via use flags.
> 
> The drawback of course is yet another USE_EXPAND, or at least a
> bunch of rather long use flags, that will need setting by the user.

What if I made a small adjustment to the DEPEND building like so:

-   POSTGRES_DEP="|| ("
+   POSTGRES_REQ_USE=" || ("
for slot in "${POSTGRES_COMPAT[@]}" ; do
+   IUSE+=" postgres_${slot}"
+   POSTGRES_REQ_USE+=" postgres_${slot}"
+
+   ! use "postgres_${slot/_/.}" && continue
POSTGRES_DEP+=" dev-db/postgresql:${slot}="
declare -p POSTGRES_USEDEP &>/dev/null && \
POSTGRES_DEP+="[${POSTGRES_USEDEP}]"
done
-   POSTGRES_DEP+=" )"
+   POSTGRES_REQ_USE=" )"

I'll have to change from listing the slots in POSTGRES_COMPAT from N.N
to N_N, but that's not terribly difficult given the one ebuild I have it
in.

Is this a change that would require a USE_EXPAND? I know I'll have to
document the USE flags globally.


signature.asc
Description: Digital signature


Re: [gentoo-dev] New Eclasses: postgres and postgres-multi

2016-01-15 Thread Aaron W. Swenson
On 2016-01-15 12:43, Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 15/01/16 11:43 AM, Aaron W. Swenson wrote:
> > On 2016-01-13 11:11, Ian Stakenvicius wrote:
> >> The work looks really good, but I noticed that postgres-multi 
> >> determins the variants to build against based on what's
> >> installed on disk via checking eselect..  I think it'd likely
> >> be better to instead have proper dependencies based on USE,
> >> much like how the python and ABI_* multibuilds work.  That
> >> would make the installations as well as the dependencies be
> >> determinstic rather than dynamic, which should support binpkgs
> >> -much- better (among other things).
> >> 
> >> The "|| ( postgresql:${SLOT1}= postgresql:${SLOT2}= ...)"
> >> RDEPEND that postgres.eclass works out is a little sketchy
> >> IMO, unfortunately, as the behaviour that occurs when more than
> >> one of those slots are installed is afaik a little unstable --
> >> in theory, changes (including removal) of any of the options
> >> should trigger a rebuild but I don't know if it does, and I'm
> >> fairly certain that a simple --unmerge doesn't trigger a
> >> rebuild.  All of that goes away if you perform non-OR
> >> dependency via use flags.
> >> 
> >> The drawback of course is yet another USE_EXPAND, or at least
> >> a bunch of rather long use flags, that will need setting by the
> >> user.
> > 
> > What if I made a small adjustment to the DEPEND building like
> > so:
> > 
> > -   POSTGRES_DEP="|| (" +   POSTGRES_REQ_USE=" || (" for slot in
> > "${POSTGRES_COMPAT[@]}" ; do +  IUSE+=" postgres_${slot}" +
> > POSTGRES_REQ_USE+=" postgres_${slot}" + +   ! use
> > "postgres_${slot/_/.}" && continue POSTGRES_DEP+="
> > dev-db/postgresql:${slot}=" declare -p POSTGRES_USEDEP
> > &>/dev/null && \ POSTGRES_DEP+="[${POSTGRES_USEDEP}]" done -
> > POSTGRES_DEP+=" )" +POSTGRES_REQ_USE=" )"
> > 
> > I'll have to change from listing the slots in POSTGRES_COMPAT
> > from N.N to N_N, but that's not terribly difficult given the one
> > ebuild I have it in.
> > 
> > Is this a change that would require a USE_EXPAND? I know I'll
> > have to document the USE flags globally.
> > 
> 
> 
> A USE_EXPAND isn't necessary, all that provides is a way to group a
> set of use flags with a prefix and hide the prefix from end-users
> for cosmetic purposes.
> 
> As for the patch, you can't determine RDEPEND (ie POSTGRES_DEP)
> dynamically like that based on what use flags are being set, in
> global scope -- its a runtime vs metadata-generation-time issue.
> Changing it to this would work though:
> 
> > POSTGRES_DEP+=" postgres_${slot}? ("
> > POSTGRES_DEP+=" dev-db/postgresql:${slot}=" 
> > declare -p POSTGRES_USEDEP &>/dev/null && \ 
> > POSTGRES_DEP+="[${POSTGRES_USEDEP}]" +  POSTGRES_DEP+=" )"


I only briefly looked at the Python eclasses and was having a bit of a
hard time following.

I see the conditional use now.

> The main issue I still saw though was this, in postgres-multi.eclass:
> 
> > # @FUNCTION: postgres-multi_pkg_setup
> >  ...
> 
> ..which, if i'm interpreting correctly, is what causes the postgres
> extension to only be installed against what's on disk.  Likely that
> should be changed to build the list off of whatever postgres_[SLOT]
> use flags are enabled.

Oh, yes, I'll change that, too. I was just focusing on the depend bit.


signature.asc
Description: Digital signature


[gentoo-dev] New Eclasses: postgres and postgres-multi

2016-01-12 Thread Aaron W. Swenson
There are several ebuilds that repeat the same checks and need to
perform the same duties when it comes to working with PostgreSQL. For
example, making sure the users' currently slot is compatible with the
ebuild requirements. postgres.eclass addresses this and has
additional conveniences to build a dependency string and add a new user
into the postgres system group.

Additionally, as most of you are aware, we have a slot capable
dev-db/postgresql. There is some difficulty that needed to be resolved
so that extensions could also be installed into multiple slots, which is
addressed by postgres-multi.eclass.

I've an overlay at:
https://github.com/titanofold/titanofold-gentoo-x86

With the pgsql-eclass branch containing the eclass and a postgres-multi
enabled PostGIS.

Naturally, the eclasses work for me, so far.

For your convenience, I've also attached the eclasses.
# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

inherit multibuild postgres
EXPORT_FUNCTIONS pkg_setup src_prepare src_compile src_install src_test


# @ECLASS: postgres-multi
# @MAINTAINER:
# PostgreSQL <pgsql-b...@gentoo.org>
# @AUTHOR: Aaron W. Swenson <titanof...@gentoo.org>
# @BLURB: An eclass for PostgreSQL-related packages with default functions
# @DESCRIPTION:
# postgres-multi enables ebuilds, particularly PostgreSQL extensions, to
# build against any and all compatible, installed PostgreSQL
# slots. Additionally exports default functions.


case ${EAPI:-0} in
  0|1|2|3|4) die "postgres-multi.eclass requires EAPI 5 or higher" ;;
  *) ;;
esac


# @ECLASS-VARIABLE: POSTGRES_COMPAT
# @REQUIRED
# @DESCRIPTION:
# A Bash array containing a list of compatible PostgreSQL slots as
# defined by the developer.
if ! declare -p POSTGRES_COMPAT &>/dev/null; then
die 'Required variable POSTGRES_COMPAT not declared.'
fi

# @ECLASS-VARIABLE: _POSTGRES_UNION_SLOTS
# @INTERNAL
# @DESCRIPTION:
# A Bash array containing the union set of available slots installed on the
# system that are also in POSTGRES_COMPAT.
export _POSTGRES_UNION_SLOTS=( )

# @FUNCTION _postgres-multi_multibuild_wrapper
# @INTERNAL
# @USAGE: _postgres-multi_multibuild_wrapper  [ ...]
# @DESCRIPTION:
# For the given variant, set the values of the PG_SLOT and PG_CONFIG
# environment variables accordingly and replace any appearance of
# @PG_SLOT@ in the command and arguments with value of ${PG_SLOT}.
_postgres-multi_multibuild_wrapper() {
debug-print-function ${FUNCNAME} "${@}"
export PG_SLOT=${MULTIBUILD_VARIANT}
export PG_CONFIG=$(which pg_config${MULTIBUILD_VARIANT//./})
$(echo "${@}" | sed "s/@PG_SLOT@/${PG_SLOT}/g")
}

# @FUNCTION: postgres-multi_foreach
# @USAGE: postgres-multi_foreach   [ ...]
# @DESCRIPTION:
# Run the given command in the package's source directory for each
# installed PostgreSQL slot. Any appearance of @PG_SLOT@ in the command
# or arguments will be substituted with the slot of the current
# iteration.
postgres-multi_foreach() {
local MULTIBUILD_VARIANTS=("${_POSTGRES_UNION_SLOTS[@]}")

multibuild_foreach_variant \
_postgres-multi_multibuild_wrapper run_in_build_dir ${@}
}

# @FUNCTION: postgres-multi_forbest
# @USAGE: postgres-multi_forbest   [ ...]
# @DESCRIPTION:
# Run the given command in the package's source directory for the best
# installed, compatible PostgreSQL slot. Any appearance of @PG_SLOT@ in
# the command or arguments will be substituted with the matching slot.
postgres-multi_forbest() {
# POSTGRES_COMPAT is reverse sorted once in postgres.eclass so
# element 0 has the highest slot version.
local MULTIBUILD_VARIANTS=("${_POSTGRES_UNION_SLOTS[0]}")

multibuild_foreach_variant \
_postgres-multi_multibuild_wrapper run_in_build_dir ${@}
}

# @FUNCTION: postgres-multi_pkg_setup
# @USAGE: postgres-multi_pkg_setup
# @DESCRIPTION:
# Initialize internal environment variable(s).
postgres-multi_pkg_setup() {
local all_slots=$(eselect --brief postgresql list)
local user_slot

for user_slot in "${POSTGRES_COMPAT[@]}"; do
has "${user_slot}" ${all_slots} && \
_POSTGRES_UNION_SLOTS+=( "${user_slot}" )
done

elog "Multibuild variants: ${_POSTGRES_UNION_SLOTS[@]}"
}

postgres-multi_src_prepare() {
local MULTIBUILD_VARIANT
local MULTIBUILD_VARIANTS=("${_POSTGRES_UNION_SLOTS[@]}")
multibuild_copy_sources
}

postgres-multi_src_compile() {
postgres-multi_foreach emake
}

postgres-multi_src_install() {
postgres-multi_foreach emake install DESTDIR="${D}"
}

postgres-multi_src_test() {
postgres-multi_foreach emake installcheck
}
# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General P

[gentoo-dev] Last Rites: www-apache/mod_auth_pgsql

2016-01-11 Thread Aaron W. Swenson
Masked for removal after 2016-03-11. Package hasn't been updated in some
time and doesn't work with Apache 2.4 without patching by Gentoo. (Bug
548974) Use Apache Module mod_authn_dbd instead.


signature.asc
Description: Digital signature


Re: [gentoo-dev] ChangeLog

2015-11-03 Thread Aaron W. Swenson
On 2015-11-03 05:24, Jeroen Roovers wrote:
> On Mon, 2 Nov 2015 16:17:18 -0500
> "Aaron W. Swenson" <titanof...@gentoo.org> wrote:
> 
> > Vadim, please don't top post.
> 
> But do quote some forty lines from the message you reply to. It
> really helps in case someone lost the original, right? :-)
> 
> 
>  jer

Exactly! I'm glad somebody shares my views. (^_^)


signature.asc
Description: Digital signature


Re: [gentoo-dev] ChangeLog

2015-11-02 Thread Aaron W. Swenson
On 2015-11-03 02:22, Vadim A. Misbakh-Soloviov wrote:
> Actually, git log understands if you specify path for it (especially
> after --)...
> 
> 
> 03.11.2015 02:05, Daniel Campbell пишет:
> > On 11/01/2015 04:22 AM, Anthony G. Basile wrote:
> > > On 11/1/15 7:16 AM, Patrick Lauer wrote:
> > >> Ahoi,
> > >>
> > >> I'm getting mildly very irritated with the lack of easily
> > >> accessible ChangeLogs for our packages.
> > >>
> > >> Apparently updating them stopped some time in August, so now
> > >> there are some outdated ChangeLogs that don't really serve any
> > >> purpose, and the easiest way for users to figure out why
> > >> something changed is to yell at the clumsy gitweb.g.o interface.
> > >> So instead of grep we now need lots of patience.
> > >>
> > >> This does not look reasonable to me.
> > >>
> > >> Can we please either properly remove ChangeLogs and tell people
> > >> to not be curious about changes, or make them useful again?
> > >>
> > >> Thanks,
> > >>
> > >> A Gentoo User.
> > >>
> > > I don't have strong feelings about this, but I'm happy with `git
> > > log` to tell me what's going on with packages.  I would be okay
> > > with the ChangeLog files just being archived and removed.
> >
> >
> > Is there a way for us (devs and users both) to only get `git log`
> > results from a specific directory or package? I'm aware we could pipe
> > git log to grep, but that seems hackish, like git has a better way to
> > isolate log entries.
> >
> >
> 
> 

Vadim, please don't top post.

Daniel, yes, you just do:

git log cat/pkg

Or:
git log .

`git log' understands path arguments within the repo.

But, that doesn't really give you the full picture. You will be better
served by:

git log --grep=


signature.asc
Description: Digital signature


Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-08-30 23:59 UTC

2015-09-04 Thread Aaron W. Swenson
On 2015-09-04 09:53, malc wrote:
> James - you're right - I hadn't paid attention to MTA wrapping...
> Patrice - even though it's counter to what James asked, I added short
> sha-1s [ i.e. the output of git rev-parse --short
> f1cb2b98f62fa9cbf1ef5a0f149dd47fee6964be ]
> Now the output looks like below (or attached txt file)
> 
> Removals:
> dev-java/antenna   2015-09-03 13:45:07 +  monsieurp  
> b4215f4

Would you consider dropping the TZ offset? If the script were to translate
the DT to UTC, that'd remove some noise and shorten the line by 5.

dev-java/antenna   2015-09-03 13:45:07Z  monsieurp  b4215f4

And I know what my offset is from UTC so I know the above example
happened at 11:45am my time, but having to do more math on the others
before figuring out my time is a little annoying. I can live with it,
but I'm lazy.

- Aaron


signature.asc
Description: Digital signature


Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

2015-08-10 Thread Aaron W. Swenson
On 2015-08-10 23:49, Andrew Savchenko wrote:
 Another issue: we will have to setup git mirrors as well (probably
 reusing hosts providing rsync mirrors). I really doubt current
 infrastructure will survive if all users will sync from its git.

Users can fetch/pull from Github.

https://github.com/gentoo/gentoo


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: Git Migration: go-live!

2015-08-09 Thread Aaron W. Swenson
On 2015-08-09 13:22, hasufell wrote:
 On 08/09/2015 12:16 PM, Ryan Hill wrote:
  On Sun, 9 Aug 2015 05:36:16 +
  Robin H. Johnson robb...@gentoo.org wrote:
  
  On Sat, Aug 08, 2015 at 05:47:14PM +, Robin H. Johnson wrote:
  On Thu, Jul 02, 2015 at 09:39:52PM +, Robin H. Johnson wrote:
  2015/08/08 15:00 UTC - Freeze
  2015/08/08 19:00 UTC - Git commits open for developers
  This is going live in a few minutes. There was a lot of delays and snags
  that were hit. QA has a lot of reviewing to do of in-tree patches with
  long-standing CVS keyword damage. gkeys is also not sufficiently baked,
  so we're using some scripting for now instead [1].
 
  The new setup DOES enforce that commits AND pushes are signed.
 
  I'm only 90% sure that everything works, but I've spent almost the
  entire day on it, and there's more to go tomorrow.
 
  Other old CVS repos are still closed for the moment, they will re-open
  tomorrow.
  
  So for someone who hasn't been following any of this, is there an idiot's 
  guide
  on how make the Gentoo?
  
  
 
 https://wiki.gentoo.org/wiki/Gentoo_git_workflow
 

That page is missing the first step in working with our new Git
Overlord: cloning the repository.


signature.asc
Description: Digital signature


Re: [gentoo-dev] Git workflow, commit messages

2015-08-09 Thread Aaron W. Swenson
On 2015-08-09 09:31, Gordon Pettey wrote:
 On Sun, Aug 9, 2015 at 7:06 AM, Anthony G. Basile bluen...@gentoo.org
 wrote:
 
 
  Particularly, we should prepend CATEGORY/PN:  to the first line so we
  can easily search git log for what happened to a package.
 
 
 Good format to help reading unfiltered logs, but invalid reasoning. 'git
 log portage/cat/pn' or 'git log portage/cat-old/pn-old
 portage/cat-moved/pn-moved' gets every commit affecting files in said
 package's directory.

That's true, but some changes are made outside of the directory, like
when removing/adding package masks.


signature.asc
Description: Digital signature


Re: [gentoo-dev] more packages up for grabs

2015-05-19 Thread Aaron W. Swenson
On 2015-05-18 17:13, Tim Harder wrote:
 * app-misc/solaar

I can do this one. I've used it to handle my peripherals.

- Aaron


signature.asc
Description: Digital signature


[gentoo-dev] Last Rites: dev-db/pgtune

2015-01-07 Thread Aaron W. Swenson
pgtune is masked for removal 2015-03-08. It's dead upstream, has a
critical bug 530868, and doesn't use a real distribution model. Adopt
the package upstream to save it.

An online alternative lives at:
http://pgtune.leopard.in.ua/

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
Herds/Projects: Perl, PostgreSQL, Proxy Maintainers
GitHub/BitBucket: titanofold | PAUSE: AWSWENSON | Twitter: @AaronWSwenson
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


signature.asc
Description: Digital signature


Re: [gentoo-dev] metadata.xml unherd/-ization, v2

2014-12-12 Thread Aaron W. Swenson
On 2014-12-10 10:41, Sergey Popov wrote:
 09.12.2014 14:59, Ulrich Mueller пишет:
  proxy-maintainer is very confusing because you won't put the proxy
  maintainer there, but the user who is being proxied. Please rename
  to something like proxied (assuming that this exists as a word in
  English) or by-proxy.
 
 +1 for that.
 
 Proxy maintainer is a Gentoo developer, that commits changes, authored
 by proxied maintainer, who does not have commit access to main tree

The Gentoo Dev that's committing the work isn't a maintainer, in
relation to the package. S/he is a committer. So...:

  Gentoo Dev doing the commit: Proxy Committer (or just Proxy)
  Person doing the work: Maintainer-By-Proxy.

Sure, the dev may do a bit of maintenance or cleanup before committing,
but the bulk of the work is done by the maintainer-by-proxy. However, we
can clear up a lot of confusion if we just change our terms slightly to
more strongly indicate the dev's relationship to a package.

And, proxied is a word, but it does not mean what we need it to mean. We
could make it mean what we want it to mean, but I think that's kind of
mean. You know what I mean?

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
PostgreSQL Herd Bull
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


signature.asc
Description: Digital signature


Re: [gentoo-dev] Unifying the PostgreSQL Ebuilds

2014-11-03 Thread Aaron W. Swenson
On 2014-11-02 10:52, Aaron W. Swenson wrote:
 On 2014-10-11 18:02, Aaron W. Swenson wrote:
  On 2014-09-19 10:11, Aaron W. Swenson wrote:
   I'm hoping to press forward with this change in the next week or so.
   
   Thank you in advance!
   
   [1] https://bugs.gentoo.org/show_bug.cgi?id=505540
   [2] https://bugs.gentoo.org/show_bug.cgi?id=456876
   [3] https://github.com/titanofold/titanofold-gentoo-x86
  
  Anyone opposed to my fixing the dependencies of the above packages?
 
 I'm currently running repoman full on the affected packages. I'll be
 committing the changes within the next few hours.

Finished.

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
PostgreSQL Herd Bull
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


signature.asc
Description: Digital signature


Re: [gentoo-dev] Unifying the PostgreSQL Ebuilds

2014-11-02 Thread Aaron W. Swenson
On 2014-10-11 18:02, Aaron W. Swenson wrote:
 On 2014-09-19 10:11, Aaron W. Swenson wrote:
  I'm hoping to press forward with this change in the next week or so.
  
  Thank you in advance!
  
  [1] https://bugs.gentoo.org/show_bug.cgi?id=505540
  [2] https://bugs.gentoo.org/show_bug.cgi?id=456876
  [3] https://github.com/titanofold/titanofold-gentoo-x86
 
 Anyone opposed to my fixing the dependencies of the above packages?

I'm currently running repoman full on the affected packages. I'll be
committing the changes within the next few hours.

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
PostgreSQL Herd Bull
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


signature.asc
Description: Digital signature


Re: [gentoo-dev] Unifying the PostgreSQL Ebuilds

2014-10-11 Thread Aaron W. Swenson
On 2014-09-19 10:11, Aaron W. Swenson wrote:
 I've been working on unifying the PostgreSQL ebuilds for a while now.
 
 Besides just being cleaner and taking a bit less time to compile, it
 will inherently resolve a couple issues that are difficult to
 workaround, such as cross compilation [1] and CFLAGS changes [2].
 
 I'm including a list of affected packages, but I think I have everything
 prepared in my overlay [3] for commit to gentoo-x86.
 
 I'm aiming to do a package move instead of the virtual/postgresql mess
 we had last time. Before I do that, I'd like some feedback as there may
 be some issue I've overlooked or haven't run into. I don't really think
 there should be as the installation model is the same as the split
 ebuilds; it's still slotted, and installation paths are the same.
 
 I'm hoping to press forward with this change in the next week or so.
 
 Thank you in advance!
 
 [1] https://bugs.gentoo.org/show_bug.cgi?id=505540
 [2] https://bugs.gentoo.org/show_bug.cgi?id=456876
 [3] https://github.com/titanofold/titanofold-gentoo-x86
 
 Affected Packages
 
 app-admin/collectd
 app-admin/rsyslog
 app-admin/sagan
 app-admin/ulogd
 app-backup/bacula
 app-backup/bareos
 app-crypt/onak
 app-editors/xemacs
 app-forensics/aide
 app-misc/sphinx
 app-mobilephone/gammu
 app-mobilephone/gnokii
 app-mobilephone/kannel
 app-office/akonadi-server
 app-office/calligra
 app-office/libreoffice
 app-office/openerp
 app-office/openerp-server
 dev-cpp/pficommon
 dev-db/barman
 dev-db/cppdb
 dev-db/libdbi-drivers
 dev-db/libzdb
 dev-db/mysql-super-smack
 dev-db/opendbx
 dev-db/pgadmin3
 dev-db/pgagent
 dev-db/pgmemcache
 dev-db/pgpool2
 dev-db/pgtap
 dev-db/pg_top
 dev-db/pgxnclient
 dev-db/postgis
 dev-db/psqlodbc
 dev-db/pygresql
 dev-db/slony1
 dev-db/soci
 dev-db/textsearch_ja
 dev-db/tora
 dev-haskell/hdbc-postgresql
 dev-haskell/hsql-postgresql
 dev-java/jdbc-postgresql
 dev-lang/io
 dev-lang/php
 dev-libs/apr-util
 dev-libs/cyrus-sasl
 dev-libs/libhome
 dev-libs/libpqxx
 dev-libs/radlib
 dev-libs/redland
 dev-lisp/clisp
 dev-lua/luadbi
 dev-ml/postgresql-ocaml
 dev-perl/DBD-Pg
 dev-perl/pgperl
 dev-python/psycopg
 dev-python/pypgsql
 dev-qt/qtsql
 dev-ruby/pg
 games-server/cyphesis
 games-server/pvpgn
 games-strategy/freeciv
 gnome-extra/libgda
 gnustep-libs/sqlclient
 mail-filter/anubis
 mail-filter/dspam
 mail-filter/gld
 mail-mta/courier
 mail-mta/exim
 mail-mta/postfix
 media-video/motion
 net-analyzer/barnyard
 net-analyzer/barnyard2
 net-analyzer/echoping
 net-analyzer/flow-tools
 net-analyzer/hydra
 net-analyzer/icinga2
 net-analyzer/metasploit
 net-analyzer/munin
 net-analyzer/nagios-plugins
 net-analyzer/pmacct
 net-analyzer/zabbix
 net-dialup/accel-ppp
 net-dialup/freeradius
 net-dialup/gnuradius
 net-dns/bind
 net-dns/mydns
 net-dns/pdns
 net-firewall/nufw
 net-ftp/proftpd
 net-ftp/pure-ftpd
 net-im/jabberd2
 net-irc/eggdrop
 net-irc/inspircd
 net-libs/courier-authlib
 net-libs/cvm
 net-libs/wt
 net-mail/cyrus-imapd
 net-mail/dovecot
 net-mail/ezmlm-idx
 net-mail/mailutils
 net-mail/perdition
 net-mail/tpop3d
 net-mail/vpopmail
 net-misc/asterisk
 net-misc/cfengine
 net-misc/mico
 net-misc/ser
 net-misc/stargazer
 net-print/pykota
 net-voip/gnugk
 net-voip/yate
 sci-biology/emboss
 sci-geosciences/grass
 sci-geosciences/mapnik
 sci-geosciences/osm2pgsql
 sci-geosciences/qgis
 sci-libs/gdal
 sci-libs/vtk
 sci-mathematics/pspp
 sci-physics/root
 sys-auth/libnss-pgsql
 sys-auth/pam-pgsql
 sys-cluster/gearmand
 sys-cluster/slurm
 www-apache/mod_auth_nufw
 www-apache/mod_auth_pgsql
 www-apps/liquid_feedback_core
 www-apps/webmcp
 www-servers/uwsgi
 

Well, since I've heavily modified the PostgreSQL ebuilds I've decided to
use virtual packages to do the transition.

Anyone opposed to my fixing the dependencies of the above packages?

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
PostgreSQL Herd Bull
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


signature.asc
Description: Digital signature


[gentoo-dev] Unifying the PostgreSQL Ebuilds

2014-09-19 Thread Aaron W. Swenson
I've been working on unifying the PostgreSQL ebuilds for a while now.

Besides just being cleaner and taking a bit less time to compile, it
will inherently resolve a couple issues that are difficult to
workaround, such as cross compilation [1] and CFLAGS changes [2].

I'm including a list of affected packages, but I think I have everything
prepared in my overlay [3] for commit to gentoo-x86.

I'm aiming to do a package move instead of the virtual/postgresql mess
we had last time. Before I do that, I'd like some feedback as there may
be some issue I've overlooked or haven't run into. I don't really think
there should be as the installation model is the same as the split
ebuilds; it's still slotted, and installation paths are the same.

I'm hoping to press forward with this change in the next week or so.

Thank you in advance!

[1] https://bugs.gentoo.org/show_bug.cgi?id=505540
[2] https://bugs.gentoo.org/show_bug.cgi?id=456876
[3] https://github.com/titanofold/titanofold-gentoo-x86

Affected Packages

app-admin/collectd
app-admin/rsyslog
app-admin/sagan
app-admin/ulogd
app-backup/bacula
app-backup/bareos
app-crypt/onak
app-editors/xemacs
app-forensics/aide
app-misc/sphinx
app-mobilephone/gammu
app-mobilephone/gnokii
app-mobilephone/kannel
app-office/akonadi-server
app-office/calligra
app-office/libreoffice
app-office/openerp
app-office/openerp-server
dev-cpp/pficommon
dev-db/barman
dev-db/cppdb
dev-db/libdbi-drivers
dev-db/libzdb
dev-db/mysql-super-smack
dev-db/opendbx
dev-db/pgadmin3
dev-db/pgagent
dev-db/pgmemcache
dev-db/pgpool2
dev-db/pgtap
dev-db/pg_top
dev-db/pgxnclient
dev-db/postgis
dev-db/psqlodbc
dev-db/pygresql
dev-db/slony1
dev-db/soci
dev-db/textsearch_ja
dev-db/tora
dev-haskell/hdbc-postgresql
dev-haskell/hsql-postgresql
dev-java/jdbc-postgresql
dev-lang/io
dev-lang/php
dev-libs/apr-util
dev-libs/cyrus-sasl
dev-libs/libhome
dev-libs/libpqxx
dev-libs/radlib
dev-libs/redland
dev-lisp/clisp
dev-lua/luadbi
dev-ml/postgresql-ocaml
dev-perl/DBD-Pg
dev-perl/pgperl
dev-python/psycopg
dev-python/pypgsql
dev-qt/qtsql
dev-ruby/pg
games-server/cyphesis
games-server/pvpgn
games-strategy/freeciv
gnome-extra/libgda
gnustep-libs/sqlclient
mail-filter/anubis
mail-filter/dspam
mail-filter/gld
mail-mta/courier
mail-mta/exim
mail-mta/postfix
media-video/motion
net-analyzer/barnyard
net-analyzer/barnyard2
net-analyzer/echoping
net-analyzer/flow-tools
net-analyzer/hydra
net-analyzer/icinga2
net-analyzer/metasploit
net-analyzer/munin
net-analyzer/nagios-plugins
net-analyzer/pmacct
net-analyzer/zabbix
net-dialup/accel-ppp
net-dialup/freeradius
net-dialup/gnuradius
net-dns/bind
net-dns/mydns
net-dns/pdns
net-firewall/nufw
net-ftp/proftpd
net-ftp/pure-ftpd
net-im/jabberd2
net-irc/eggdrop
net-irc/inspircd
net-libs/courier-authlib
net-libs/cvm
net-libs/wt
net-mail/cyrus-imapd
net-mail/dovecot
net-mail/ezmlm-idx
net-mail/mailutils
net-mail/perdition
net-mail/tpop3d
net-mail/vpopmail
net-misc/asterisk
net-misc/cfengine
net-misc/mico
net-misc/ser
net-misc/stargazer
net-print/pykota
net-voip/gnugk
net-voip/yate
sci-biology/emboss
sci-geosciences/grass
sci-geosciences/mapnik
sci-geosciences/osm2pgsql
sci-geosciences/qgis
sci-libs/gdal
sci-libs/vtk
sci-mathematics/pspp
sci-physics/root
sys-auth/libnss-pgsql
sys-auth/pam-pgsql
sys-cluster/gearmand
sys-cluster/slurm
www-apache/mod_auth_nufw
www-apache/mod_auth_pgsql
www-apps/liquid_feedback_core
www-apps/webmcp
www-servers/uwsgi


-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
PostgreSQL Herd Bull
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


signature.asc
Description: Digital signature


Re: [gentoo-dev] git security (SHA-1)

2014-09-17 Thread Aaron W. Swenson
On 2014-09-16 14:40, hasufell wrote:
 Michael Orlitzky:
  To put things in perspective, all I had to do was ask for commit access
  and somebody eventually gave it to me. We should worry about this when
  breaking SHA1 becomes less expensive than the ebuild quizzes.
 
 Yep, that's what I'd try to do actually if I was working for NSA
 (uh-oh). Try to get collaborators into every possible opensource project.
 
 There are so many thing you can do... e.g. fix a security bug, but
 reference a self-packaged tarball from your dev space (which still
 contains the exploit) in the ebuild. No one will know.
 And that's a pretty low hanging fruit.
 

This is what's been driving me batty. None of you verified my identity
before letting me be an official Gentoo Developer. Yet I have access to
the repo. All I had to do was complete the quizzes.

The real concern is restricting access to the master repository. If the
attacker has gained access, either by becoming a developer or some other
means, then we're only kind inconvenienced a little. We have to take the
system down for a bit, fix the problem, and replace the repo with a
trusted source or just roll it back to the last known good commit before
the good commit was made.

When Linus has talked about Git using SHA-1, the impression I got was
that it isn't a means of preventing attacks, but ensuring corruption
hasn't happened. When he talked about an attack to the kernel
repository, it was with BitKeeper, which used a much weaker hash, and
still thwarted an attack.

I also like what Pro Git has to say:
http://git-scm.com/book/ch6-1.html#A-SHORT-NOTE-ABOUT-SHA-1

It doesn't mention SHA-1 as a security feature, but that collissions are
effectively not a concern. Instead, we should be more concerned about us
all being dragged off into the night by wolves. Simultaneously.

Git hasn't promised to be secure against attacks. Just secure against
corruption. Two different things.

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
PostgreSQL Herd Bull
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


signature.asc
Description: Digital signature


Re: [gentoo-dev] git security (SHA-1)

2014-09-17 Thread Aaron W. Swenson
On 2014-09-17 12:08, Ciaran McCreesh wrote:
 On Wed, 17 Sep 2014 07:04:08 -0400
 Aaron W. Swenson titanof...@gentoo.org wrote:
  This is what's been driving me batty. None of you verified my identity
  before letting me be an official Gentoo Developer.
 
 Why does that matter?

My argument is Git using SHA-1 for checksumming is not the weakest
part of our security model.

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
PostgreSQL Herd Bull
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0

signature.asc
Description: Digital signature


Re: [gentoo-dev] Add bc back to the stage3

2014-09-17 Thread Aaron W. Swenson
On 2014-09-17 14:20, viv...@gmail.com wrote:
 Il 17/09/2014 14:09, Jorge Manuel B. S. Vicetto ha scritto:
  On Wed, 17 Sep 2014, Luca Barbato wrote:
 
  The bc utility is part of the posix tools and it might be used to build
  linux among the other stuff.
 
  Luca,
 
  bc is not in the system set and is a dependency of the kernel or any
  other package that needs it, so why do we need to include a package
  that takes ~20 seconds to build?
 
 Most people don't use the ebuild for the kernel

That's a rather outrageous and difficult to substantiate claim. Given
what I've seen in the forums and on IRC, it would appear the reverse
is true; most people use the ebuild for the kernel.

I wouldn't consider people who deviate from the supported methods as
our concern. If you're smart enough to do that and want to make your
own path, you're smart enough to emerge bc.

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
PostgreSQL Herd Bull
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0

signature.asc
Description: Digital signature


Re: [gentoo-dev] systemd + postgresql is non-obvious to me

2014-09-01 Thread Aaron W. Swenson
On 2014-08-22 14:07, Rich Freeman wrote:
 On Fri, Aug 22, 2014 at 1:23 PM, Aaron W. Swenson titanof...@gentoo.org 
 wrote:
  On the whole, I'm displeased with the systemd alternative for
  controlling PostgreSQL. It's significantly hampered and doesn't allow
  as much flexibility as the initscript. The major issue being trying to
  nicely shut down the server instead of jumping straight to murder.
 
 
 It looks like the package installs a service file provided by
 upstream, so you might want to direct your complaint there unless it
 really is a systemd limitation.

Delayed response, I've been looking into this as I've been working on
unifying the ebuilds, but I can't find where upstream is providing the
systemd unit. The only one I have is the one we've made.

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
PostgreSQL Herd Bull
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


signature.asc
Description: Digital signature


Re: [gentoo-dev] systemd + postgresql is non-obvious to me

2014-09-01 Thread Aaron W. Swenson
On 2014-09-01 11:09, Canek Peláez Valdés wrote:
 On Mon, Sep 1, 2014 at 10:46 AM, Aaron W. Swenson titanof...@gentoo.org 
 wrote:
  On 2014-08-22 14:07, Rich Freeman wrote:
  On Fri, Aug 22, 2014 at 1:23 PM, Aaron W. Swenson titanof...@gentoo.org 
  wrote:
   On the whole, I'm displeased with the systemd alternative for
   controlling PostgreSQL. It's significantly hampered and doesn't allow
   as much flexibility as the initscript. The major issue being trying to
   nicely shut down the server instead of jumping straight to murder.
  
 
  It looks like the package installs a service file provided by
  upstream, so you might want to direct your complaint there unless it
  really is a systemd limitation.
 
  Delayed response, I've been looking into this as I've been working on
  unifying the ebuilds, but I can't find where upstream is providing the
  systemd unit. The only one I have is the one we've made.
 
 It is included in:
 
 http://dev.gentoo.org/~titanofold/postgresql-initscript-2.6.tbz2
 
 It doesn't says who the author is; but he or she was the one deciding
 to wait five minutes (TimeoutSec=300) for the server to stop (and also
 to disable the OOM killer: OOMScoreAdjust=-1000).

Well, I'm the one who committed it to the pgsql-patches repo and
Patrick committed it to gentoo-x86, but neither of us wrote it. There was
some collaboration on the bug [1].

You can also read through the comments to see my other complaints. I
don't know if they're addressed or not.

[1] https://bugs.gentoo.org/show_bug.cgi?id=468868

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
PostgreSQL Herd Bull
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0

signature.asc
Description: Digital signature


Re: [gentoo-dev] systemd + postgresql is non-obvious to me

2014-08-22 Thread Aaron W. Swenson
On 2014-07-15 08:52, Ian Stakenvicius wrote:
 On 15/07/14 07:36 AM, Pacho Ramos wrote:
  El mar, 15-07-2014 a las 13:31 +0200, Alexander Berntsen escribió: 
  [...]
  To alleviate this I needed to run systemd-tmpfiles --create.
  This was non-obvious to me. Sounds like a packaging issue that I
  need to do it in the first place?
  
  It's: https://bugs.gentoo.org/show_bug.cgi?id=462118
  
  The problem is that it's not clear to us how to make it
  automatically without needing to call it manually from every ebuild
  installing a tmpfiles.d file :(
  
  
 
 Wasn't there a plan to make an eclass helper to process tmpfiles.d
 files that get installed, during pkg_postinst ?
 
 ...and now that I think about it, did I say that I was going to write it?
 

There's a bit more to it, as well.

On the whole, I'm displeased with the systemd alternative for
controlling PostgreSQL. It's significantly hampered and doesn't allow
as much flexibility as the initscript. The major issue being trying to
nicely shut down the server instead of jumping straight to murder.

I really don't want to get into an OpenRC versus systemd flame-war,
but I really hate the systemd offering we have for PostgreSQL. It's
dumb and I recommend against using it.

I haven't used systemd and do not plan on using it until it actually
fixes a problem that's non-trivial, which is most likely never for me.

So, if any of you would like to improve our systemd offering, it'd be
welcomed enthusiastically.

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
PostgreSQL Herd Bull
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0

signature.asc
Description: Digital signature


[gentoo-dev] Last Rite: x11-misc/slimlock

2014-02-03 Thread Aaron W. Swenson
The screen lock program x11-misc/slimlock has been masked for removal.

slimlock has been merged into its inspirator, x11-misc/slim, as of
2013-10-01. Install =x11-misc/slim-1.3.6 to get the most recent
improvements/enhancements of slimlock.

--
Mr. Aaron W. Swenson
Gentoo Linux Developer
PostgreSQL Herd Bull
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


signature.asc
Description: Digital signature


Re: [gentoo-dev] News item: m68k, s390, and sh are dropping stable keywords

2013-09-19 Thread Aaron W. Swenson
On 2013-09-19 21:29, Andreas K. Huettel wrote:

 For general review and improvement, to be committed 2013-09-25...
 [The summary link [3] will work soon... :) ]

 ##

 Title: m68k, s390, and sh are dropping stable keywords

To stay within 42 characters, perhaps rewrite the title as:
   Drop Stable Keyword for m68k, s390, and sh

Or:
m68k, s390, and sh Move to Unstable

 ...

 Following discussion [1] and a vote by the Gentoo Council [2,3],
 m68k, s390, and sh will drop all stable keywords and become
 unstable/testing only arches. The main reason for this is that
 these arch teams visibly lack manpower, leading to overall delays.
 Stable may well be synonymous with outdated here.

I would remove the last sentence. It read a bit as
editorializing. However, I'd change leading to overall delays to
which resulted in undesirable delays.

 ...

 No steps are required from users, however you should be aware
 of the upcoming changes.

I'd bottom line this as:
No action is required to prepare for this change.

Of course, just my 2¢.

--
Mr. Aaron W. Swenson
Gentoo Linux Developer
PostgreSQL Herd Bull
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests

2013-02-13 Thread Aaron W. Swenson
On Wed, Feb 13, 2013 at 01:20:39PM +0100, Michael Weber wrote:
 On 02/13/2013 11:55 AM, Markos Chandras wrote:
  http://www.gentoo.org/doc/en/gnupg-user.xml
  
 still no hint what to do on expiration (as every single other gpg howto).
 

It depends. What do you want to do when it expires?

If you don't believe that the key has been compromised -- nobody is
going around using your key falsely -- then you should just renew
your key, i.e change the expiry date.

Some that are a bit more paranoid will generate a new key, sign it
with the about-to-expire key  -- not the already expired key because
they would never allow that to happen -- revoke the about-to-expire
key, then sync with the key server(s).

This information, by the way, has been blogged about thousands of
times.

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests

2013-02-13 Thread Aaron W. Swenson
On Wed, Feb 13, 2013 at 09:35:56AM -0700, Denis Dupeyron wrote:
 On Wed, Feb 13, 2013 at 8:31 AM, Aaron W. Swenson titanof...@gentoo.org 
 wrote:
  This information, by the way, has been blogged about thousands of
  times.
 
 There is a reason people write documentation. Contrary to blog posts,
 documentation is thought out, reviewed, maintained and corrected when
 necessary.

I agree. This is officially documented by GnuPG. [1] That would be the
best source to use. It details everything one needs to do to manage a
key pair.

PGP keys are daunting, but once one uses them for a while it becomes a
bit easier to grok.

There's nothing Gentoo specific about it. I don't see why we would
need to officially document an official document. The most we should
do is point people to the resource.

[1] http://www.gnupg.org/gph/en/manual.html#AEN329

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests

2013-02-13 Thread Aaron W. Swenson
On Wed, Feb 13, 2013 at 07:58:30PM +0200, Eray Aslan wrote:
 On Wed, Feb 13, 2013 at 05:22:14PM +, Aaron W. Swenson wrote:
  I agree. This is officially documented by GnuPG. [1] That would be the
  best source to use. It details everything one needs to do to manage a
  key pair.
 
 Good luck having people find and read it.  Similar to (or perhaps
 linking to) something along the lines of
 
 http://keyring.debian.org/creating-key.html
 
 might be appropriate (by adding an expiry date section perhaps).
 
 This is not about expiry dates or even gnupg in particular.  Our
 documentation is not up to par anymore.  We need to spend more effort in
 documentation in general.  Please do so if you can.
 

I do agree that we need to state some minimum requirements that aren't
so antiquated. And, we need to make it a bit more conspicuous.

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


signature.asc
Description: Digital signature


[gentoo-dev] Add test to IUSE_IMPLICIT

2013-02-02 Thread Aaron W. Swenson
After years of if use test ; then ... just working when
FEATURES=test is declared, it isn't working with EAPI5. I think we
could save some bytes and headaches if we just add test to
IUSE_IMPLICIT.

Portage's emerge's --newuse option won't be affected by this. From
`man emerge`:
 NOTE: This option ignores the state of the test USE flag, since
 that flag has a special binding to FEATURES=test (see make.conf(5)
 for more information about FEATURES settings).

What say you?

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


signature.asc
Description: Digital signature


Re: [gentoo-dev] Add test to IUSE_IMPLICIT

2013-02-02 Thread Aaron W. Swenson
On Sun, Feb 03, 2013 at 12:50:02AM +0100, Michał Górny wrote:
 On Sat, 2 Feb 2013 23:33:26 +
 Aaron W. Swenson titanof...@gentoo.org wrote:
 
  After years of if use test ; then ... just working when
  FEATURES=test is declared, it isn't working with EAPI5.
 
 You shouldn't admit that for years you didn't knew that this was
 incorrect and you should have been using IUSE=test.

Let me rephrase that: Experience led me to 'FEATURE=test' implies
'USE=test' regardless of whether test is in IUSE or not.

Further, if I'm adding FEATURE=test, why wouldn't I also want
USE=test.

  I think we could save some bytes and headaches if we just add test
  to IUSE_IMPLICIT.
 
 First of all, you should note that you will still need to add IUSE=test
 to pre-EAPI 5 ebuilds.

Not need. Apparently supposed to have done that, though. As I said, it
has been working without it for years and only stopped when I used EAPI5.

 Secondly, what about all the ebuilds which declare IUSE=test in EAPI 5?
 Shall we remove that value from IUSE? Keep it?
 

test being in IUSE becomes moot. It wouldn't much matter whether
it's there or it isn't.

 What will be the impact on metadata? It seems that the PMS allows
 dependencies on IUSE_EFFECTIVE, so we can basically have dependencies
 with flags which are valid only on some of the profiles...

IUSE_EFFECTIVE is probably better.

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


signature.asc
Description: Digital signature


Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-01-20 23h59 UTC

2013-01-22 Thread Aaron W. Swenson
On Mon, Jan 21, 2013 at 12:10:12PM +0100, Theo Chatzimichos wrote:
 On Mon, Jan 21, 2013 at 1:25 AM, Robin H. Johnson robb...@gentoo.org wrote:
  The attached list notes all of the packages that were added or removed
  from the tree, for the week ending 2013-01-20 23h59 UTC.
 
 How about sending those mails to gentoo-dev-announce only?
 
 Theo
 

+1 from me.

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


pgpZsK2vDnZ_5.pgp
Description: PGP signature


Re: [gentoo-dev] USE flags dri, cups, pppd

2013-01-19 Thread Aaron W. Swenson
On Sat, Jan 19, 2013 at 03:53:25PM -0500, Philip Webb wrote:
 On Sat, Jan 19, 2013 at 3:18 AM, Ben de Groot yng...@gentoo.org wrote:
  I'm not sure whether we need to keep cups at all.
  I haven't printed anything from my personal PC or laptop in years.
 
 As a user, I'ld say this wb a very unpopular move with some of us.
 I rarely use my 2nd-hand 1995 printer, but sometimes it is essential :
 eg I now need to print letters to  2  friends abroad who don't have e-mail
  occasionally I need to print forms downloaded from the Internet
 for tax purposes or to get mail-in refunds on things I bought.
 I don't have access to an office printer
  when last asked, my neighbour reported his printer broken.
 
 Please continue to support Cups.
 

We're only discussing whether or not to have the `cups' USE flag in
the base profile, not the package itself.

I don't believe we need it in the base profile. The only people who
would enable it are those that are setting up a print server or those
who are setting up a desktop, in which case they would want to use the
desktop profile.

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


pgpTyPWXAp7fI.pgp
Description: PGP signature


Re: [gentoo-dev] USE flags dri, cups, pppd

2013-01-19 Thread Aaron W. Swenson
On Sat, Jan 19, 2013 at 07:40:56PM -0500, James Cloos wrote:
  This question only matters if you expect there to be non-desktops where
  there are packages installed that IUSE dri.
 
 I'd note that there is no correlation between the use of the desktop
 profiles and the use of an X11 or wayland server on any given box.
 
 The (gui) world is much more than gnome+kde.
 
 -JimC

That's why there's a base desktop profile and desktop/{gnome,kde}
profiles.

Moving `dri' to the base desktop profile is sensible in that we
recommend any user who will be running a GUI use the desktop
profile. Those who aim for a minimalist profile will enable the flag
themselves.

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


pgp7VmQZopbDI.pgp
Description: PGP signature


Re: [gentoo-dev] USE flags dri, cups, pppd

2013-01-18 Thread Aaron W. Swenson
On Fri, Jan 18, 2013 at 11:55:07PM +, Markos Chandras wrote:
 On 18 January 2013 23:29, Chí-Thanh Christopher Nguyễn
 chith...@gentoo.org wrote:
  Patrick McLean schrieb:
   I would prefer to keep USE=dri in the default profile. If you
   want to move VIDEO_CARDS that would be fine with me though.
  
   USE=dri is usually only relevant on desktops, why enable it on
   all profiles?
 
  Because it should be enabled when the respective packages are
  installed, and not depending on the profile the user has selected.
 
 
  Best regards,
  Chí-Thanh Christopher Nguyễn
 
 
 
 Hell, as discussed, the base profile should contain the absolute
 minimal flags, and dri does not appear to be one of these.
 Having graphics support on such a profile is not expected. IMHO it
 should be moved to the desktop profile
 

++ If the base profile is to become our server profile, it should not
have graphics related USE flags enabled.

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


pgpJrpEK6gSzG.pgp
Description: PGP signature


Re: [gentoo-dev] USE flags dri, cups, pppd

2013-01-18 Thread Aaron W. Swenson
On Sat, Jan 19, 2013 at 01:02:04AM +0100, Chí-Thanh Christopher Nguyễn wrote:
 Markos Chandras schrieb:
  On 18 January 2013 23:29, Chí-Thanh Christopher Nguyễn
  chith...@gentoo.org wrote:
  Because it should be enabled when the respective packages are
  installed, and not depending on the profile the user has selected.
  Hell, as discussed, the base profile should contain the absolute
  minimal flags, and dri does not appear to be one of these.
  Having graphics support on such a profile is not expected. IMHO it
  should be moved to the desktop profile
 
 
 If you have an absolute minimal system, then none of your packages will
 have the dri flag. So it won't hurt. If you remove the dri flag from the
 default profile, this will break users' setups for no good reason.
 
 Moving to EAPI=1 USE defaults would be an alternative if the dri flag is
 deemed unacceptable for the default profile, but in my opinion a
 pointless exercise as it would change precisely zero systems.
 
 
 Best regards,
 Chí-Thanh Christopher Nguyễn
 
 

And now I'm going to reverse my original vote. The only packages that
have the `dri' USE flag are in the x11-{drivers,libs} categories. As
such, it doesn't matter very much whether or not `dri' is in the base
profile. Better to leave it than remove it seeing as Chí-Thanh says,
it will have less of an impact on the users.

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0


pgp0ClIZVb_p5.pgp
Description: PGP signature


Re: [gentoo-dev] News item 1: changes to stages (make.conf and make.profile)

2012-09-09 Thread Aaron W. Swenson
On 9/8/2012 2:05 PM, Jorge Manuel B. S. Vicetto wrote:
 Here is the second draft for this news item.
 ...
 Starting next week, new stages will have make.conf and make.profile
 moved from /etc to /etc/portage. This is a change in the installation
 defaults, that will only affect new installs so it doesn't affect
 current systems.

I'd be specific on the date as I could read that news item after this
actually happens but be under the impression that it hasn't happened yet.

- Aaron



[gentoo-dev] Last Rites: dev-db/pgpool

2012-08-14 Thread Aaron W. Swenson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

# Aaron W. Swenson titanof...@gentoo.org (14 Aug 2012)
# Obsolete. Superseded by dev-db/pgpool2. Removal 14 Sep 2012.
# (Bug #431414)
dev-db/pgpool
- -- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
Email: titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C  0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAlAqkzkACgkQVxOqA9G7/aD5RQD/RkpA8KRbcOAYi0ixUdcjEZub
y9iJ1OuKvqGnnzK/1YEA/1a8NDv9ylA4ioiIDRiE13l1P3RglhqCs994+x7UcZg9
=eSu+
-END PGP SIGNATURE-



Re: [gentoo-dev] UTF-8 locale by default

2012-07-30 Thread Aaron W. Swenson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/30/2012 11:04 AM, Michael Mol wrote:
 On Mon, Jul 30, 2012 at 10:41 AM, Michał Górny mgo...@gentoo.org
 wrote:
 On Mon, 30 Jul 2012 10:35:36 -0400 Michael Orlitzky
 mich...@orlitzky.com wrote:
 
 On 07/27/12 16:16, Aaron W. Swenson wrote:
 
 No user will be happy with whatever we decide to use as a
 default.
 
 The defaults should be what's best for the most people, with a
 bias towards safety. Why don't we just take a survey and choose
 the most common utf8 response?
 
 How can you take a survey like that? How will you ensure it
 actually hits the majority? How will you define the majority?
 
 Serverside script on gentoo.org. Push out a news item with the URL
 and a last-call date. Tabulate the results, using browser
 fingerprints to weed out the bulk of duplicates.
 

I still advocate continuing how we have been.

However, the survey should be one question: What is the output of
`locale' on your workstation/desktop/laptop?

The less painful we make the survey, the more respondents we'll get,
and the less biased the results will be. Additionally, it makes the
responses easy to parse with a script.

Servers are excluded because special things take place there that may
not actually line up with what the user prefers.

If it turns out that C or POSIX is the most common response, we should
then default the locale to en_US.UTF-8 if we really want to default to
a UTF-8 setting. The reason being it makes sense to have the default
locale set to the country of origin, which in our case is the United
States.

Yes, it may irk those whose native locale is not en_US.UTF-8, but like
I said, no one will be happy. Except for those whose native locale
happens to be the default.

Start at a default, doesn't really matter which as long as the default
is the lingua franca of international business, and instruct the user,
as we already do, how to change it during the setup.

- -- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
Email: titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C  0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAlAWrXAACgkQVxOqA9G7/aCmowD6A8+9giw1BhhxvAag7Cmeom7o
mHVW49AfEDSo6ReknZkBAIa09FZ62SU66BCCi6m3Qisk5SW7P3YDLNbkMDS38/CZ
=lFc0
-END PGP SIGNATURE-



  1   2   >