Re: [gentoo-dev] Common Lisp project is empty
Michael Orlitzky writes: On Wed, 2021-11-03 at 16:25 +0100, Max Zettlmeißl wrote: On Wed, 3 Nov 2021 at 14:15, Michael Orlitzky wrote: > If no one intends to join, we should drop the following to > maintainer- > needed: I use some of those packets daily. Is there a way to join the Common Lisp project without currently having maintainer status or is that not intended? I don't think you can join the project, but you could still be added as an additional proxy maintainer for those packages you care about. That would let you take care of them using pull requests once everyone is made aware that common-lisp@ isn't going to respond to RFCs. At the risk of over-committing myself (I'm stretched a bit thin myself), I'm willing to be in the Common Lisp project as long as Max does the heavy lifting. I've recently taken interest in getting Nyxt in tree and it depends on SBCL and a few other in-tree Lisp packages. However, I'm not strong on Lisp environment, and will gladly yield to anyone better suited. WKR, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] 2021-10-08-openssh-rsa-sha1: add news item
I think it may be helpful to include the specific file(s) those options need to be added and to clarify whether they need to be added to the server host or the clients. Perhaps like so: hashes may be re-enabled on the server by adding the following config options to the end of /etc/ssh/sshd_confg: WKR, Aaron Mike Gilbert writes: Signed-off-by: Mike Gilbert --- .../2021-10-08-openssh-rsa-sha1.en.txt| 26 +++ 1 file changed, 26 insertions(+) create mode 100644 2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt diff --git a/2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt b/2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt new file mode 100644 index 000..cfdcc4a --- /dev/null +++ b/2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt @@ -0,0 +1,26 @@ +Title: OpenSSH RSA SHA-1 signatures +Author: Mike Gilbert +Posted: 2021-10-08 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: net-misc/openssh + +As of version 8.8, OpenSSH disables RSA signatures using the SHA-1 +hash algorithm by default. This change affects both the client and +server components. + +After upgrading to this version, you may have trouble connecting to +older SSH servers that do not support the newer RSA/SHA-256/SHA-512 +signatures. Support for these signatures was added in OpenSSH 7.2. + +As well, you may have trouble using older SSH clients to connect to a +server running OpenSSH 8.8 or higher. Some older clients do not +automatically utilize the newer hashes. For example, PuTTY before +version 0.75 is affected. + +To resolve these problems, please upgrade your SSH client/server +whereever possible. If this is not feasible, support for the SHA-1 +hashes may be re-enabled using the following config options: + +HostkeyAlgorithms +ssh-rsa +PubkeyAcceptedAlgorithms +ssh-rsa -- Reservations and Reporting Technologist Great Smoky Mountains Railroad PO Box 1490 Bryson City, NC 28713 D: 828-488-7013 M: 800-872-4681 x 214 F: 828-488-0427 P: 9B32 F2A4 8C1F F4E0 1E23 CEEA 2153 C852 F779 174F signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver
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
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
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
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
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]
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
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
# 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
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
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
# 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
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
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)
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
On 2018-01-16 15:07, Róbert Čerňanský wrote: > On Wed, 10 Jan 2018 22:46:04 +0200 > Mart Raudseppwrote: > > 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
Pushed via commit ed16527710bcde367ba3a4c7604c5aa6b2650034. signature.asc Description: Digital signature
[gentoo-dev] Last Rites: app-office/odeskteam
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)
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)
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)
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)
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
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
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
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
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
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
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
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
+1 signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org
On 2017-12-15 16:37, R0b0t1 wrote: > Hello, > > On Tue, Dec 5, 2017 at 4:18 PM, Nils Freydankwrote: > > 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
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
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
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
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
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
On 2017-11-26 10:02, Benda Xu wrote: > Hi Patrick, > > Patrick McLeanwrites: > > > 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.
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.
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
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
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
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
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
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
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
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
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
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
On 2017-07-15 01:34, Raymond Jennings wrote: > On Wed, Jul 12, 2017 at 9:07 AM, Gordon Petteywrote: > > > 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
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
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 ??
On 2017-04-18 14:27, James Le Cuirot wrote: > On Tue, 18 Apr 2017 15:12:13 +0200 > Jörg Schaiblewrote: > > > 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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!
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
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
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
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
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
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
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
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
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)
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
-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-