Re: [gentoo-dev] New project: Antivirus
I know only eset, kaspersky and old and unsupported clamav. On 01/12/2016 12:20 PM, Michael Palimaka wrote: I am announcing the antivirus project[1], to replace the old herd in preparation for the implementation of GLEP 67. 1: https://wiki.gentoo.org/wiki/Project:Antivirus
Re: [gentoo-dev] RFD: News item format 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I don't see why backwards compatibility would be a problem. The older news format spec supports fewer features, so the new spec should be much like newer EAPIs and 'just work'. I'm in favor of all the changes you laid out. A good number of us are already familiar with git-style limitations, and they're rather sane to begin with. I could see issues with bigger changes fitting into 50 characters, but I guess that's what creative wording is for. :) It's odd that news items even have the Content-Type attribute. Before removing it, are there any other formats we could feasibly want in the future? I can't think of any formats we'd want to use, but maybe someone else has an idea. In general, though, I'm in favor of the changes if it makes life easier for those writing news. I don't write news items right now, but I may end up doing it in the future. Sorry for top-posting. I didn't see a way to do proper replies in K-9. On January 12, 2016 10:13:39 AM PST, Ulrich Mueller wrote: >In its last meeting the council has accepted an extension of the >news item format which allows EAPI=5 style package dependency >specifications. This has triggered a discussion if this change is >backwards or forwards compatible, and what should be the new format's >version number [1]. Also it is not entirely clear if the term >"backwards-compatible" used in GLEP 42 correctly describes what was >originally intended [2]. > >In any case, both portage [3] and paludis [4] will have to be updated >for the new format because the change is not forwards-compatible. > >Therefore, we could use the opportunity to add some other features. >So far, this includes: > >1. Display-If-Installed: Allow EAPI=5 style package dependency > specifications (see above). > >2. Display-If-Profile: Allow wildcards like default-linux/* [5]. > >3. Title: Increase maximum length. In the past, devs repeatedly > struggled with the current 44 character limit. (Can anyone > enlighten me where this originates from? I cannot find anything in > the discussions around the time when GLEP 42 was submitted.) > The eselect news reader could still display a 51 character title > in one line for the "list" and "read" commands, on an 80 character > wide terminal. > I suggest we round this down to a maximum length of 50 characters, > which (together with the 72 character limit for the body) would > nicely agree with the limits recommended for git commit messages. > >4. Content-Type: Only one value is allowed for this header, namely > text/plain. We might as well drop it, because any changes there > will require an increment of the News-Item-Format. > >If these changes find agreement, I would prepare a new GLEP for news >item format 2.0. > >Ulrich > > >[1] https://bugs.gentoo.org/show_bug.cgi?id=568068#c4 >[2] >https://archives.gentoo.org/gentoo-dev/message/d30de011db9067ae3cc298de2b4ee1b2 >[3] >https://gitweb.gentoo.org/proj/portage.git/tree/pym/portage/news.py?id=7c94014a32d173ae61919b762140ac1c32d3b522#n273 >[4] >http://git.exherbo.org/paludis/paludis.git/tree/paludis/repositories/e/e_repository_news.cc?id=1684b446715907515359cd310c1e7bd93bad5a2e#n326 >[5] https://bugs.gentoo.org/show_bug.cgi?id=290038 - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -BEGIN PGP SIGNATURE- iQJRBAEBCgA7NBxEYW5pZWwgQ2FtcGJlbGwgKEdlbnRvbyBEZXZlbG9wZXIpIDx6 bGdAZ2VudG9vLm9yZz4FAlaVkQkACgkQASQOlFA54XAYuQ/9F0qt4BaPTan+rMBd MkbjA1A4EeaLgGT0BAlv5oKhfR5VC4fNoWcfCB+Z11Bkyi+8DRGLWoEqF1KvFKsb CLu8a8Q/+T34JuvKznCJrHfnkFYwARVXpOVX70t3Sr50BSpe5lvmQ4PQ8PpOFTnJ O4bo9GjxKTujVvu1LxYSv3CLJ6AV9HANsl5rkBQ+TKi4qrwqBTWK4VGNTCon/DFt EUTRuz7TXlpE6quMTTk7Wx8yldRgC7mL2SwYsH0KosrBaMTv5yVWipZMdEP6oPRp ovYhPNgPYPrct8DuiOOXvNJms8Ll5oS/m07w5MUr7KzWAoWjFluQAVR+HOACfXuk 7YiSk9FbH+a3t6aEGNrEX7VRcG8A2UG6nDsc5GNXLc+ObPvfsykXZs6vchfC8J+j wJp8R/dXecAyw9HmjQ6cx3N3lw65YG+3I1cK883GuvGGb7P9BOeWuloouhqEfOc5 OaptMrWWJM9T8FNzgZVXc8tJmrCexw1HFKUfjhcJinIffHfRoeIjmSJcTtKliW/k 0VHtmhjr4OkBr+wcjf5uZEAstq/4/Jp1ArS3URaXtDEBuY0xKaR/WLMPtcuu4X1K fFkah8qS/jR8qqE9KecULE25c8C47im6EJGk6Wgzb/8MNx3J4iZ8P0PHS+kLEZFq uyrSyEwwvx2ES92sDb+EaXW0B08= =7A0/ -END PGP SIGNATURE-
Re: [gentoo-dev] New Eclasses: postgres and postgres-multi
On 2016-01-12 21:57, Manuel Rüger wrote:
> On 12.01.2016 20:22, Aaron W. Swenson wrote:
> > 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.
> >
>
> You might wanna add some quotes around the variables in that line:
> enewuser $1 $2 $3 $4 ${groups}
>
> Cheers,
>
> Manuel
>
Done.
https://github.com/titanofold/titanofold-gentoo-x86/commit/976455582c95d62ed7ee5c102e58948a4afb037c
signature.asc
Description: Digital signature
Re: [gentoo-dev] New Eclasses: postgres and postgres-multi
On 12.01.2016 20:22, Aaron W. Swenson wrote:
> 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.
>
You might wanna add some quotes around the variables in that line:
enewuser $1 $2 $3 $4 ${groups}
Cheers,
Manuel
signature.asc
Description: OpenPGP 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
# @AUTHOR: Aaron W. Swenson
# @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 Public License v2
# $Id$
inherit user
# @ECLASS: postgres
# @MAINTAINER:
# PostgreSQL
# @AUTHOR: Aaron W. Swenson
# @BLURB: An eclass for PostgreSQL-related packages
# @DESCRIPTION:
# This ecla
[gentoo-dev] RFD: News item format 2.0
In its last meeting the council has accepted an extension of the news item format which allows EAPI=5 style package dependency specifications. This has triggered a discussion if this change is backwards or forwards compatible, and what should be the new format's version number [1]. Also it is not entirely clear if the term "backwards-compatible" used in GLEP 42 correctly describes what was originally intended [2]. In any case, both portage [3] and paludis [4] will have to be updated for the new format because the change is not forwards-compatible. Therefore, we could use the opportunity to add some other features. So far, this includes: 1. Display-If-Installed: Allow EAPI=5 style package dependency specifications (see above). 2. Display-If-Profile: Allow wildcards like default-linux/* [5]. 3. Title: Increase maximum length. In the past, devs repeatedly struggled with the current 44 character limit. (Can anyone enlighten me where this originates from? I cannot find anything in the discussions around the time when GLEP 42 was submitted.) The eselect news reader could still display a 51 character title in one line for the "list" and "read" commands, on an 80 character wide terminal. I suggest we round this down to a maximum length of 50 characters, which (together with the 72 character limit for the body) would nicely agree with the limits recommended for git commit messages. 4. Content-Type: Only one value is allowed for this header, namely text/plain. We might as well drop it, because any changes there will require an increment of the News-Item-Format. If these changes find agreement, I would prepare a new GLEP for news item format 2.0. Ulrich [1] https://bugs.gentoo.org/show_bug.cgi?id=568068#c4 [2] https://archives.gentoo.org/gentoo-dev/message/d30de011db9067ae3cc298de2b4ee1b2 [3] https://gitweb.gentoo.org/proj/portage.git/tree/pym/portage/news.py?id=7c94014a32d173ae61919b762140ac1c32d3b522#n273 [4] http://git.exherbo.org/paludis/paludis.git/tree/paludis/repositories/e/e_repository_news.cc?id=1684b446715907515359cd310c1e7bd93bad5a2e#n326 [5] https://bugs.gentoo.org/show_bug.cgi?id=290038 pgpqBYNMNGPoL.pgp Description: PGP signature
[gentoo-dev] GLEP67 officially approved with 2-week deadline
Hello, everyone. With a little delay, I'd like to announce that the 2016-01-10 Council meeting (log [1], no summary yet) has resulted in the current wording of GLEP67 being approved ([2], not yet moved to [3]). Considering the progress so far (tracked in [4]), the Council has set the deadline for herd status updates to 2 weeks from the meeting (2016-01-24). At this point, all metadata.xml files will be updated automatically and their conformance to GLEP67 will become obligatory. I will be explaining GLEP67 in detail sometime this week. For now, I'd like to focus on necessary transition notes. Implementation progress === I. Most of herds have been handled already (thanks, kensington!). II. I've opened bugs for all offending projects and herds (list may be outdated, I'd be doing a second check soon). III. projects.xml should already be generated from wiki and distributed via rsync & git mirror. IV. willikins was given new !proj command to expand projects. I'm going to start working on !meta today. V. I've got necessary metadata.dtd updates on a branch. After merging it to master, the new version will start being distributed and enforced by repoman. VI. I've sent small Portage update to the ml. However, it would be nice if someone wrote full set of checks for repoman, including checking if type="project" maintainers are in projects.xml. VII. All migration scripts are ready, and test conversions are available for review [5]. I'm updating them every few days. Required action from Gentoo developers == In the following two weeks, developers have to ensure that: 1. all project pages list unique, dedicated e-mail addresses for the projects, or no addresses at all. Sharing the same address between multiple projects is forbidden, as is reusing developer's e-mail address for a project. If necessary, ask Infra to create an alias for you. 2. If a project wishes to maintain any packages, its e-mail address needs to be registered on Bugzilla. Only Infra can create Bugzilla accounts for @gentoo.org, so ask Infra for it. 3. The fate of the remaining herds needs to be decided by their maintainers and listed on the mapping page [6]. We will be using this page when doing the automated metadata updates. 4. There can not be any 'rogue' maintainers left. In other words, all packages need to be maintained by explicit people (developers or proxied maintainers), or explicit projects. No 'dumb' aliases are allowed. Now, my automated conversion script gives three possibilities for each herd: a. mapping to a single project -- in this case all occurrences will be replaced by the matching project. Multiple herds can be mapped into one project but we don't support splitting herd into more projects. b. Disbanding and replacing with maintainers -- in this case all current herd maintainers (taken from herds.xml) will be put into metadata.xml directly. c. Disbanding with no replacement -- in this case, will be removed with no replacement. Some packages will become maintainer-needed. Whenever this is not sufficient for your herd, please update the metadata beforehand, if possible. Don't create new herds, though. If you need a new project, use plain element -- my script will automatically add correct type="" to it afterwards. I will be announcing new maintainer-needed packages after the switch, so in case of disbanding a herd completely, you need to add yourself to the maintainers of packages you'd like to keep manually before I do that. Required action from tool developers GLEP67 is mostly backwards compatible, so software shouldn't need being updating. However, if you don't use the official DTD source and validate metadata.xml files with some kind of schema, you will need to update it. Getting maintainers from metadata.xml will work pretty much the same. After the transition, you will be able to remove the code handling herds. You may also want to add some getter for the new type="" attribute on . If you'd like to be able to expand projects into project members, you will need to implement support for projects.xml and use it to map type="project" maintainers. Mapping from to is done on matching . Please note that (unlike herds.xml) projects.xml is well-defined in multi-repository environment, with inheritance via masters=. In other words, if you're working on metadata.xml files, don't hardcode projects.xml path/URI but instead use -- in order -- the one from the repository, followed by its masters. Thank you for your attention. If you have any questions, please don't hesitate to reply to this mail. [1]:https://projects.gentoo.org/council/meeting-logs/20160110-log.txt [2]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:67 [3]:https://wiki.gentoo.org/wiki/GLEP:67 [4]:https://bugs.gentoo.org/show_bug.cgi?id=glep67-tracker [5]:https://github.com/gentoo/gentoo/pull/559 [6]:https://wiki.gentoo.org/wiki/Project:Metas
Re: [gentoo-dev] Goodbye Java on ppc32?
On Sat, 9 Jan 2016 23:10:43 + James Le Cuirot wrote: > I'm mulling over the idea of dropping Java on 32-bit ppc. Having > personally used Gentoo on this hardware myself in the past, I've > resisted the temptation to drop it sooner but I think it's time to > throw in the towel now. Since there hasn't been an outcry against this announcement so far, it's likely that I will proceed with it at the weekend. > There are probably some packages that aren't typically associated with > Java that will be affected by this. I haven't made a list but I > suspect it doesn't contain anything majorly important. Thankfully > LibreOffice no longer has a hard dependency on Java. The list of casualties can now be seen in: https://github.com/gentoo/gentoo/pull/638 Other than some fairly obvious ones like Vuze and Tomcat, there aren't really any packages that I would consider majorly important being dropped. mysql-workbench is in the list but the latest ebuild has been adjusted to not depend on Java. -- James Le Cuirot (chewi) Gentoo Linux Developer
[gentoo-dev] New project: Antivirus
I am announcing the antivirus project[1], to replace the old herd in preparation for the implementation of GLEP 67. 1: https://wiki.gentoo.org/wiki/Project:Antivirus
