Re: [gentoo-dev] New schema language for metadata validation?

On 01/26/2016 02:52 PM, Dirkjan Ochtman wrote: > All, > > TL;DR: I think we should switch from DTD to RELAX NG (compact syntax, > ideally) for our XML validation needs. It is more expressive and more > readable. > A great idea. > What other stuff would need to be updated? > I would

Re: [gentoo-dev] Re: [PATCH v2 17/19] ebuild-writing/misc-files: remove ChangeLog section #485314

On 01/24/2016 07:43 PM, Ulrich Mueller wrote: >>>>>> On Sun, 24 Jan 2016, Gokturk Yuksek wrote: > >> From: Michael Orlitzky <m...@gentoo.org> > >> The ChangeLog section under misc-files is misleading now that our main >> repository has been swit

Re: [gentoo-dev] New USE_EXPAND: POSTGRES

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

Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

On 01/21/2016 05:41 PM, waltd...@waltdnes.org wrote: > > Maybe we should start a "gentoo-ebuilds" mailing list to help regular > users learn the ins and outs of making ebuilds. Try gentoo-devhelp@lists.g.o, or the associated #gentoo-dev-help on IRC. We should be trying to get these things

Re: [gentoo-dev] [PATCH 00/16] devmanual: update the docs for post git-migration #558642

On 01/17/2016 02:55 AM, Gokturk Yuksek wrote: > Hi, > > The following patch series attempt to update devmanual to replace the > instances > of CVS with their git equivalents. Thank you! > - I am not sure about what to do with the subsection > Ebuild Functions/Miscellaneous Files/ChangeLog.

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

On 01/07/2016 07:52 PM, Marc Schiffbauer wrote: >> >> 3. I could try to hack some magic into eselect-php to detect whether or >>not you have -DPHP5 set. Something simple, like grepping /etc/conf.d >>/apache2 for "PHP5". In that case we could omit a notice. >>This one simultaneously

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

On 01/06/2016 02:36 PM, Sebastian Pipping wrote: > On 05.01.2016 20:35, Michael Orlitzky wrote: >> I just pushed a new revision with this fix. In eselect-php-0.8.2-r1, >> we ship both the new 70_mod_php.conf and the old 70_mod_php5.conf. The >> latter comes with a b

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

On 01/04/2016 02:27 PM, Michael Orlitzky wrote: > > I may be able to fix that by simply including the old 70_mod_php5.conf > for backwards compatibility. > I just pushed a new revision with this fix. In eselect-php-0.8.2-r1, we ship both the new 70_mod_php.conf and the old 70_m

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

On 01/04/2016 12:49 PM, Rich Freeman wrote: > > My understanding (which could be wrong) is that this update will break > things even if the user never runs eselect php afterwards. I can't > tell you the last time I touched the php eselect module, because major > updates to php are rare. > I

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

On 01/04/2016 08:40 AM, Michał Górny wrote: > > Therefore, I think you should really work on some kind of backwards > compatibility for people using '-D PHP5' that would prevent those kind > of issues at least for some migration period. With big fat warnings for > people who run it. > I wasn't

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

On 01/04/2016 11:11 AM, Peter Stuge wrote: > > So pkg_postinst for >=eselect-php-0.8.1 should say something, but > ideally also the invocation - but I don't know if eselect-php is also > code or only data managed by eselect? The pkg_postinst is already there. The eselect-php routines are bash

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

On 01/04/2016 12:11 AM, Jeroen Roovers wrote: > >> Without updating APACHE2_OPTS, websites could end up serving >> PHP code (include configuration files with passwords) >> unprocessed to website visitors! > > That would mean there is an additional (local) security problem. > All PHP

Re: [gentoo-dev] Re: [PATCH 01/15] scons-utils.eclass: Modernize the example not to rely on myescons...

On 01/01/2016 12:42 PM, Michael Palimaka wrote: > I don't see the absurdity. Two formally independent statements that are actually dependent because of some implicit shared state: >> >> src_configure() { >> local mycmakeargs=( >> ... >> ) >> cmake-utils_src_configure >> }

Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: python_export_utf8_locale(), ensure sane locale

On 12/17/2015 08:23 PM, Tyler Pohl wrote: > Please reomove tylerap...@gmail.com from > the mailing list. Or please let me know how to get this done. > You are doing too much work, Michał. To unsubscribe, send a message to the address contained in the

Re: [gentoo-dev] Re: rfc: openrc c api (librc) usage

On 12/16/2015 01:44 AM, Duncan wrote: >> >> look at the RDEPEND in ebuilds. if a package uses the libs, it should >> be listed there. > > Even with openrc still in @system? Doesn't look like that bug has been > fixed yet.[1] > No one agrees on which @system packages can be omitted from

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-emulation/runc/

On 12/07/2015 01:26 PM, Matt Turner wrote: >> >> I fixed it now. > > This is happening with some frequency. Could we install a server-side > git hook that prevents pushes if an ebuild is added without a Manifest > change? It wouldn't have to verify anything more than that to catch > nearly all of

Re: [gentoo-dev] RFC: automatically mailing people on pkgcheck problems with their packages

On 12/06/2015 11:49 AM, Michał Górny wrote: >> >> Is the testing performed per-push rather than per-commit? Either way, I >> would like to get a notification that something broke, even if it wasn't >> my commit at fault. Just change the word "blame" to "alert" so no one >> feels slandered. > > It

Re: [gentoo-dev] RFC: automatically mailing people on pkgcheck problems with their packages

On 12/06/2015 09:36 AM, Michał Górny wrote: > > So what do you think? Would it be fine to mail the package maintainers > whenever their packages break? Would it be a problem if I just CC-ed > all the maintainers on the gentoo-automated-testing mails? Of course. Add the commit author, too: I

Re: [gentoo-dev] RFC: automatically mailing people on pkgcheck problems with their packages

On 12/06/2015 11:00 AM, Michał Górny wrote: >> >> Of course. Add the commit author, too: I want to know if I break someone >> else's package. > > So far, can't do that since we don't know which commit exactly broke. I > don't want to do any heuristics that could blame the wrong person. > Is the

Re: [gentoo-dev] rfc: OpenRC public API definition

On 12/03/2015 12:36 PM, William Hubbs wrote: > All, > > I would like opinions on what is considered the public api of librc. > > 1) All definitions in rc.h, even though they are not formally documented > in man pages. > > 2) the definitions in rc.h which are documented in section 3 man pages. >

Re: [gentoo-dev] rfc: adding sbin directories to PATH for all users

On 11/25/2015 12:10 PM, William Hubbs wrote: > All, > > I would like for us to discuss adding the sbin directories to PATH for > all users. > > The only thing that procps installs in /sbin is sysctl. Why? It works when run as a normal user, as long as you don't try to change something sacred.

[gentoo-dev] (e)changelog pages in the devmanual

Do we need to keep these around? 1. https://devmanual.gentoo.org/tools-reference/echangelog/ 2. https://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/ If not, I'll get rid of them and close bug #485314.

Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle

On 11/18/2015 12:55 PM, Michael Orlitzky wrote: > > That's taking about half a second if I run it from the command-line. > ...and this takes even longer: cinfo = self.grab(['git', self._work_tree, 'diff-tree', '--name-status', '--n

Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle

On 11/18/2015 09:48 AM, Peter Stuge wrote: > Peter Stuge wrote: >> Robin H. Johnson wrote: >>> However, the largest sticking point, even with parallel threads, is that >>> it seems the base ChangeLog generation is incredibly slow. It averages >>> above 350ms per package right now (at 19k packages

Re: [gentoo-dev] EAPI 6 portage is out!

On 11/17/2015 05:09 PM, Michał Górny wrote: > Fellow Developers! > > I have the pleasure to announce that portage-2.2.25 has just been > committed and it comes with complete EAPI 6 support. This effectively > means that from this moment forward Gentoo developers are permitted to > commit EAPI 6

Re: [gentoo-dev] EAPI 6 portage is out!

On 11/17/2015 08:04 PM, Ian Stakenvicius wrote: > > If your PM doesn't support EAPI6, then those ebuilds will be ignored > just as if they do not exist. It is plenty safe. There can be > issues if EAPI5 or older ~arch packages start -needing- EAPI6-only > ~arch dependencies, but so long as

[gentoo-dev] Executable location changes

We just got a bug, https://bugs.gentoo.org/show_bug.cgi?id=565500 due to the `uptime` binary changing locations in sys-process/procps-3.3.11-r2. The nagios-plugins package picks up the location of `uptime` while it's installing, so when users upgrade procps, some plugins stop working. Is

Re: [gentoo-dev] pre-GLEP review: Maintainership structure

On 11/08/2015 10:53 AM, Michał Górny wrote: > > No. This is going to be PITA to parse, and indefinite recursion is just > wrong. Like you suddenly have to traverse the whole crazy structure to > find a particular project. > That's already true if you want the last project in the file =P You're

Re: [gentoo-dev] pre-GLEP review: Maintainership structure

On 11/08/2015 11:07 AM, Michał Górny wrote: >> >> >> Foo >> f...@gentoo.org >> >> > > I meant finding project by e-mail. You don't have to care about > subprojects at all to do this. Subprojects are a side info. > What exactly gets harder? Finding an email address is same in

Re: [gentoo-dev] pre-GLEP review: Maintainership structure

On 11/08/2015 02:41 AM, Michał Górny wrote: >> >> If everyone likes and wants to keep the name _sub_project, I think >> _inherit_ is the wrong word to use, since children inherit from parents. > > What do you suggest instead? > Can a project be a subproject of more than one superproject? If

Re: [gentoo-dev] pre-GLEP review: Maintainership structure

On 11/03/2015 05:15 PM, Michał Górny wrote: > > Please review, comment and answer the questions in TODOs ;-). > > [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Maintainership_structure > Much more sane than what we have now, thank you. My only question is about the name of the

[gentoo-dev] Revision diffs

These days, if I'm careful to revbump when necessary AND limit my commits to one logical change, can I wind up going from (say) -r1 all the way to -r4 before pushing my changes. That looks a little weird to users, but whatever, I can explain it. The real annoyance is that I don't get decent diffs

Re: [gentoo-dev] Revision diffs

On 11/06/2015 08:34 AM, Kent Fredric wrote: > On 7 November 2015 at 02:16, Michael Orlitzky <m...@gentoo.org> wrote: >> These days, if I'm careful to revbump when necessary AND limit my >> commits to one logical change, can I wind up going from (say) -r1 all >> the w

Re: [gentoo-dev] Re: ChangeLog

On 11/02/2015 01:27 AM, Patrick Lauer wrote: >>> >> I wonder what would happen if we just... dropped a full clone of >> gentoo.git onto the rsync mirrors? >> >> > You find out how many users have limited bandwidth (again) > > Why on earth would you do the most wasteful hybrid strategy when people

[gentoo-dev] Depending on a range of slots

In the dev-lang/php ebuilds, we currently have: DEPEND="... berkdb? ( =sys-libs/db-4* ) ..." PHP will actually accept any 4.x or 5.x version of db; the ./configure flag is poorly-named: https://bugs.gentoo.org/show_bug.cgi?id=521222 Now, we also get repoman warnings for not specifying a

Re: [gentoo-dev] Depending on a range of slots

On 11/02/2015 01:00 PM, Kristian Fiskerstrand wrote: > On 11/02/2015 06:48 PM, Michael Orlitzky wrote: >> In the dev-lang/php ebuilds, we currently have: >> >> Is there a way to say "give me any 4.x or 5.x slot"? >> > > Is that necessarily a

Re: [gentoo-dev] Depending on a range of slots

On 11/02/2015 02:21 PM, Ciaran McCreesh wrote: > On Mon, 2 Nov 2015 12:48:29 -0500 > Michael Orlitzky <m...@gentoo.org> wrote: >> Is there a way to say "give me any 4.x or 5.x slot"? > > No. Slots are meaningless strings and do not support any comparison > e

Re: [gentoo-dev] Depending on a range of slots

On 11/02/2015 02:48 PM, Ciaran McCreesh wrote: > On Mon, 2 Nov 2015 14:33:57 -0500 > Michael Orlitzky <m...@gentoo.org> wrote: >> Followup question, which of these is less dumb? >> >> Option 1: berkdb? ( >=sys-libs/db-4:* > This doesn't mean what you think it

Re: [gentoo-dev] Re: ChangeLog

On 11/01/2015 08:22 PM, Duncan wrote: > > Personally, I'd love the primary sync method to be git, and the primary > change logs conveyed via native git log methods, but in ordered to do > that, all those rsync mirrors need to switch to git mirrors. > I wonder what would happen if we just...

Re: [gentoo-dev] Gentoo-hosted code review

On 11/01/2015 04:18 PM, William Hubbs wrote: > > My question is this. > > Does it offer interfaces other than the web -- such as an API or command > line client? > > If not, I wouldn't use it. There's Arcanist, but there are no releases. You're supposed to clone the git repo. Arcanist requires

Re: [gentoo-dev] ChangeLog

On 11/01/2015 07: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,

Re: [gentoo-dev] Gentoo-hosted code review

On 11/01/2015 12:44 PM, Michael Palimaka wrote: > There's been a lot of discussion about relying on GitHub for pull > requests and code review and such, so I have set up a Phabricator > instance against gentoo.git to see how a free alternative might work. > > ... > > What do you think? >

Re: [gentoo-dev] [rfc] drop iputils from @system (i.e. ping)

On 10/14/2015 11:39 PM, Mike Frysinger wrote: > iputils is currently in @system for everyone. by default, it only > installs `ping`. do we feel strongly enough about this to require > all systems include it ? or should this wait for the long idea of > releasing stage4's instead of stage3's ? >

Re: [gentoo-dev] unnecessary revbump

On 10/06/2015 09:33 AM, William Hubbs wrote: > I don't think the revbump of net-misc/openconnect-7.06-r1 to -r2 was > necessary. When the change purely affects use flags, that is picked up > by the pm and there is no need to force everyone to rebuild the package. > -r1 is stable.

Re: [gentoo-dev] Dynamic dependencies

On 10/01/2015 02:34 PM, Rich Freeman wrote: > > RDEPEND changes directly in ebuilds > Proposal 1: Anytime an RDEPEND in a non-virtual ebuild is changed, the > ebuild must be revisioned. This includes adding/removing inherited > eclasses which set RDEPENDs. > This gets conflated with dynamic

Re: [gentoo-dev] RFI: A better workflow for github pull requests

On 09/23/2015 04:40 AM, Todd Goodman wrote: > > We haven't had too many problems with it. Most of our problems seem to > be with people having issues with git itself (it was new to almost > everyone on the team) and not embracing a good workflow with it (or > trying to only use git via Eclipse.)

[gentoo-dev] last rites: dev-php/smarty-docs

# Michael Orlitzky <m...@gentoo.org> (21 Sep 2015) # Mask for removal in 30 days. Obsolete. Bug #561040. dev-php/smarty-docs

Re: [gentoo-dev] RFI: A better workflow for github pull requests

On 09/19/2015 05:16 PM, Daniel Campbell wrote: > > We'd just need a developer who's experienced in maintaining and > setting them up. > Has anyone ever set up Gitlab or Gerrit, managed by a package manager, in a way that a small bug won't grant anonymous write access to every single repository?

Re: [gentoo-dev] Inconsistent and messy layout of team maintainership in Gentoo

Replying somewhere randomly with an idea. Since projects are now on the wiki, why don't we use that as the canonical source of project members? It's machine readable, although not so nice to have it located outside the repo/ldap. The email alias would then be auto-generated from the project

Re: [gentoo-dev] www-client/chromium gtk3 support

On 09/10/2015 08:33 AM, hasufell wrote: > > So you are saying for the unlikely case that someone runs gentoo on a > desktop system where he cannot even compile gcc, llvm and others without > waiting for 2 weeks or setting up his on binhost, we have to provide a > backup-path for him, so that gtk3

Re: [gentoo-dev] Summary line

On 08/31/2015 01:33 PM, Rich Freeman wrote: > On Mon, Aug 31, 2015 at 10:53 AM, Alec Warner wrote: >>> >>> Mostly, because when I see "A version is bumped" I immediately expect >>> to know which version the bump is to, but have to dig out the diff to >>> find out. >>> >> >> So

[gentoo-dev] [PATCH 1/2] php-ext-pecl-r2.eclass: fix eclass/function name comments.

While investigating bug #371985, I took a look at the php-ext-pecl-r2 eclass. There's nothing to be done there for prefix support, but there are a few places where the old revision -r1 shows up in some comments. This commit fixes them to -r2. Bug: 371985 Bug: 558612 ---

[gentoo-dev] [PATCH 2/2] php-ext-source-r2.eclass: add prefix support.

The php-ext-source-r2 eclass sets a bunch of environment variables of the form, PHPIZE=/usr/${libdir}/${1}/bin/phpize and also tests for the existence of an INI file using absolute paths. To accomodate a prefix environment, all of these paths need to be prefixed with $EPREFIX. This commit adds

[gentoo-dev] [PATCH 0/2] Add prefix support to php-ext-source-r2.eclass.

Add prefix support to php-ext-source-r2.eclass by prepending $EPREFIX in a few places. The second patch does that, and the first patch fixes some typos in php-ext-pecl-r2.eclass that were found in the process. Michael Orlitzky (2): php-ext-pecl-r2.eclass: fix eclass/function name comments

Re: [gentoo-dev] Re: useflag policies

On 08/12/2015 12:21 AM, Ciaran McCreesh wrote: On Tue, 11 Aug 2015 23:30:31 +1000 Michael Palimaka kensing...@gentoo.org wrote: I invite you to reproduce the problem yourself then make the judgement. Using REQUIRED_USE like this makes the affected packages unusable. Can't we all (except

Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)

On 08/09/2015 10:43 AM, Dirkjan Ochtman wrote: On Sun, Aug 9, 2015 at 4:38 PM, hasufell hasuf...@gentoo.org wrote: I don't really see why it has to be so verbose. Can we just make it bug 557022, or even #557022? That would also make it fit better if you have a single-line commit message only.

[gentoo-portage-dev] [PATCH 0/2] Document globbing for INSTALL_MASK.

This documents shell globs in INSTALL_MASK and warns about filenames containing spaces. I also added a few more comments to the code after I figured out what it was going. Michael Orlitzky (2): bin/misc-functions.sh: Elaborate on some comments in install_mask(). man/make.conf.5: Document

[gentoo-portage-dev] [PATCH 1/2] bin/misc-functions.sh: Elaborate on some comments in install_mask().

--- bin/misc-functions.sh | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/bin/misc-functions.sh b/bin/misc-functions.sh index 9b79351..c2ff70a 100755 --- a/bin/misc-functions.sh +++ b/bin/misc-functions.sh @@ -261,20 +261,30 @@ install_mask() { shift

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule

On 07/06/2015 12:42 PM, Peter Stuge wrote: Alec Warner wrote: Its difficult to make a large change like all commits require review, particularly for long-time contributors who are expecting to move quickly. I think it's a character flaw (maybe hubris due to lack of experience and/or

Re: [gentoo-dev] signatures in git work flow

On 07/05/2015 04:01 PM, William Hubbs wrote: All, I've been hearing lately that the newest versions of git allow you to sign pushes. Once we have a version of git stable that allows this, can someone fill me in on why we would need to sign commits if we sign pushes? If we have a

[gentoo-dev] Last rites: sci-biology/flower

# Michael Orlitzky m...@gentoo.org (3 Jul 2015) # Mask for removal in 30 days. Superseded by dev-haskell/biosff; # use that instead. Bug #553636. sci-biology/flower

Re: [gentoo-dev] NPM / NodeJS project

On 06/28/2015 11:09 PM, Andrew Udvare wrote: I would still find it useful to install CoffeeScript (among others like PhantomJS) via Portage for global use. Right now I hack on ~/node_modules/.bin to PATH in my shell (luckily that works). It doesn't look like anyone wants to get involved with

Re: [gentoo-dev] Git Migration: launch plan schedule (2015/Aug/08-09)

On 07/03/2015 05:19 PM, Andrew Savchenko wrote: As I see from git docs only commits and tags may be signed. There is no way to sign a push. This was new to me, but check out the --signed flag of git-push (1). Moreover there is no need to sign each commit, see what Linux says on that:

Re: [gentoo-dev] NPM / NodeJS project

On 06/30/2015 03:56 AM, Ian Delaney wrote: Is this what I prompted about a year or more ago, and drew no interest in pursuing the npm path? I cited an eclass called npm.eclass in a dev's overlay. The conclusion was that using npm to install anything competed with portage at a level that

Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources

On 06/29/2015 11:25 PM, Zac Medico wrote: Considering that Go binaries are statically linked, you'll end up with a bunch of Go libraries installed that you don't need during run-time. They'll eventually give this up, because everyone does when their language starts seeing serious use. I

Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources

On 06/30/2015 02:12 PM, Zac Medico wrote: Suppose ten years from now everything is written in Go. I have 500 statically linked Go packages on my system, all of whose dependencies were built and compiled-in at install time. Now someone finds a remote root vulnerability in the go-openssl

Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources

On 06/29/2015 07:44 PM, Zac Medico wrote: While it would certainly be possible to split out a number of separate ebuilds for Go libraries that are used *exclusively* by consul, what advantages would it have? Even in this limiting case, 1. You avoid pointless rebuilds. You rebuild the

[gentoo-dev] NPM / NodeJS project

I recently found a need for the CoffeeScript compiler[0] that runs on top of NodeJS. Its test suite requires a bunch of other javascript packages, and I wound up packaging enough of them to test CoffeeScript. In the process I wrote an eclass to handle packages hosted on the npm registry[1] and

Re: [gentoo-dev] Re: RFC: Indention in metadata.xml

On 06/06/2015 08:22 AM, Justin Lecher (jlec) wrote: * linewidth 80 (why do we have this short limit still in 2015) It's ancient typographic wisdom that the optimal measure (number of characters in column of text) is somewhere between 45 and 75. It varies somewhat depending on the typeface

Re: [gentoo-dev] News item review: SquashDelta syncing support

On 05/16/2015 11:47 PM, Michał Górny wrote: This one: https://archives.gentoo.org/gentoo-announce/ First time I hear about it. Looks to be used primarily for GLSAs. I wonder if anyone actually uses it. For what it's worth, it's one of the three lists mentioned specifically on our new

Re: [gentoo-dev] News item review: SquashDelta syncing support

On 05/15/2015 10:51 AM, Michał Górny wrote: Title: SquashDelta syncing support Do we need a news item for this at all? Everything is backward compatible and most people don't need to do anything at all in response to the news.

Re: [gentoo-dev] News item review: SquashDelta syncing support

On 05/16/2015 03:18 PM, Pacho Ramos wrote: Maybe this could be announced in planet.gentoo.org or even main gentoo.org news ;) We have gentoo-announce@g.o and gentoo-user@g.o too!

Re: [gentoo-dev] News item review: SquashDelta syncing support

On 05/16/2015 06:01 PM, Michał Górny wrote: We have gentoo-announce@g.o and gentoo-user@g.o too! That's gentoo-dev-announce. 'dev' is the key part. And gentoo-user@ is doubtedly used by sysadmins. This one: https://archives.gentoo.org/gentoo-announce/

Re: [gentoo-dev] Anti-spam changes: proposal to drop spammy mail

On 05/11/2015 03:29 AM, Eray Aslan wrote: On Mon, May 11, 2015 at 04:26:01AM +, Robin H. Johnson wrote: TL;DR: As of May 17, @gentoo.org will drop incoming spammy mail instead of delivering it. Speak now or hold your peace. Believe me I understand your pain. Been there done that.

Re: [gentoo-dev] Anti-spam changes: proposal to drop spammy mail

On 05/11/2015 03:35 PM, Kristian Fiskerstrand wrote: Could it be an alternative to move the messages flagged as spam into an own folder that isn't forwarded? at least that means it doesn't impact operations for those using it locally and the mail is still around, if a webmail interface or

Re: [gentoo-dev] Anti-spam changes: proposal to drop spammy mail

On 05/11/2015 04:08 PM, Robin H. Johnson wrote: By drop, I will clarify that they should ideally be rejected at SMTP time, not silently dropped. I believe those logs show a rejection after the message has been accepted initially (if I'm wrong, you can ignore the rest of this). This is better

Re: [gentoo-portage-dev] Re: [PATCHv3 1/2] MEDIUM: misc-functions: Be more quiet when removing non existing INSTALL_MASK

On 04/21/2015 01:28 PM, Zac Medico wrote: The docs for INSTALL_MASK (man 5 make.conf) don't mention that globs will work. It's expecting a space delimited list of file names. Does it really take a space-delimited list of globs instead? If so, how does that reconcile with the fact that * could

Re: [gentoo-portage-dev] Re: [PATCHv3 1/2] MEDIUM: misc-functions: Be more quiet when removing non existing INSTALL_MASK

On 04/21/2015 05:48 AM, Duncan wrote: Well, I don't use INSTALL_MASK myself, so I don't have a real-world use-case for you. However, it's clear that the code will expand shell globs, so I preserved that behavior for compatibility. I do, with shell globs, tho I didn't bother checking the

Re: [gentoo-dev] shouldn't eselect be in app-eselect ?

On 04/04/2015 02:41 PM, Philip Webb wrote: I read the recent thread re the new app-eselect. Doing my weekly system update, it strikes me that 'eselect' itself sb there too. Time to paint the bikesheds again ... (smile) This is consistent with a lot of other stuff. For example, emacs is

Re: [gentoo-dev] Review: Apache AddHandler news item

On 03/26/2015 12:56 PM, Sebastian Pipping wrote: Why this news entry? The most important reason is missing =) If you are relying on the AddHandler behavior to execute secret_database_stuff.php.inc, then once the change is made, Apache will begin serving up your database credentials in plain

Re: [gentoo-dev] collab herd for cooperative pkg maintenance

On 03/23/2015 01:22 PM, Tim Harder wrote: Hey all, Having been around for a few years I've inherited or added quite a few pkgs to the tree that I wouldn't mind other people fixing/bumping/etc that don't fall into any current herds. With that in mind, I think it would be an interesting

Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted

On 03/15/2015 02:07 AM, Michał Górny wrote: The name simply must be 'gentoo'. Agreed: it should match repo_name. As for the namespace, proj/ makes most sense of the current namespaces. I agree with this too, but I don't care if we namespace it or make it top-level.

Re: [gentoo-dev] what's the correct format for bugs containing package name and version?

On 03/05/2015 02:01 PM, Paweł Hajdan, Jr. wrote: I'm trying to find the best fix for https://bugs.gentoo.org/show_bug.cgi?id=535814 Currently file-stabilization-bugs.py uses the '%s: stabilization request' % cpv format. Here are some options I see: a) keep '%s:' as is b) change to

Re: [gentoo-dev] what's the correct format for bugs containing package name and version?

On 03/05/2015 03:03 PM, Michael Orlitzky wrote: I've settled on using a colon i.e. jer format. If the bug references a specific version (range), then I use =, =, etc. appropriately. In the case of stabilization bugs, I'd throw in the =. So, (c). Crap, I flipped a bit. I remembered

Re: [gentoo-dev] Re: Fonts project meeting and elections

On 02/28/2015 01:47 AM, Ben de Groot wrote: Since this is mostly used for web developers, I recommend to leave it off for desktop users, but possibly on for servers, for example. If we do the use expand, we should leave it up for users to set. I suggest we default to only otf, if there is a

Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps

On 02/21/2015 04:05 PM, Michał Górny wrote: https://bugs.gentoo.org/show_bug.cgi?id=401237 because Nagios needs libltdl to build. Is that still a problem? Yes, it is. Because dev-libs/libltdl. Thanks, it looks like I investigated the bug on the same day that package was committed. I

Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps

On 02/21/2015 03:18 AM, Michał Górny wrote: DEPEND=${RDEPEND} sys-devel/libtool Using system-wide libtool is horrendously broken. This is something for upstream to fix (like they should start using a sane build system) but if you really want to commit it like this, already open a bug

Re: [gentoo-dev] Mailing list for ebuild review

On 02/19/2015 03:43 PM, Rich Freeman wrote: I believe the proposal was for this to be purely optional. As such I completely support it (though I think we should consider just using the -dev-help list if it is still functional). Purely optional. To correct my original email, the mailing

[gentoo-dev] Mailing list for ebuild review

The topic of a review workflow comes up frequently, but Gitlab, Gerrit, etc. are blocked on a host of other problems that may never be resolved. It would still be nice to be able to request reviews somewhere, and for ebuilds, a mailing list combined with a threaded MUA works fine. Would anyone

Re: [gentoo-dev] Re: vmware team needs help

On 02/14/2015 10:00 AM, Kristian Fiskerstrand wrote: Does anyone have experience with solutions such as [PHABRICATOR]? other similar systems? References: [PHABRICATOR] http://phabricator.org (Has everyone forgotten that you don't need Github if you want to send a `git request-pull` ?)

Re: [gentoo-dev] Re: vmware team needs help

On 02/14/2015 06:38 PM, Christopher Head wrote: On Sat, 14 Feb 2015 21:49:56 +0200 Markos Chandras hwoar...@gentoo.org wrote: You don't have to participate to the discussions in the mailing lists :) You can just contribute code! Even a single patch a month or so is better than nothing

Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

On 02/02/2015 05:47 PM, Michał Górny wrote: For feature flag, name is the only issue. Currently USE=ffmpeg serves that purpose and I think changing that would have a very high cost (and cause a lot of bikeshed), esp. if we would end up reusing the flag for another purpose. So most likely

Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

On 02/02/2015 09:12 AM, Ulrich Mueller wrote: What are your thoughts? In a nutshell, you have a binary choice here, namely ffmpeg or libav as implementation, and instead of one USE flag you want to introduce two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of the 4 possible

Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

On 02/02/2015 10:50 AM, Michał Górny wrote: Maybe. Though it still will keep the confusion of !libav meaning ffmpeg. We could remove USE=libav from the tree, leaving only USE=ffmpeg. Then ffmpeg_impl_libav would switch the implementation if USE=ffmpeg is enabled. Maybe a little cleaner

Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86

On 01/23/2015 02:13 PM, Michał Górny wrote: To help you enable the correct USE flags, we are providing a Python script which generates the correct value from your /proc/cpuinfo [1]. The Python script can be downloaded and executed using the following command: $ wget -O -

Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86

On 01/23/2015 05:07 PM, Michał Górny wrote: Even `wget --no-check-certificate` would be a big improvement. ...because? You rule out some 13-year-olds in coffee shops as attackers. I overstated -- since the user isn't replying with any data, it's not a big improvement, but it's still a

Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86

On 01/23/2015 03:22 PM, Michał Górny wrote: But that's not the biggest problem with the wget thing: the first time someone runs this it's going to fail. $ wget -O - dev.gentoo.org/~mgorny/cpuinfo2cpuflags-x86.py | python ... Unable to determine PORTDIR, please set it before calling

Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86

On 01/23/2015 06:12 PM, Michał Górny wrote: To help you enable the correct USE flags, we are providing a Python script tool generates the correct value using your /proc/cpuinfo. It can be found in app-portage/cpuinfo2cpuflags package: I think you accidentally a word here, but otherwise it

Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86

On 01/23/2015 05:38 PM, Michał Górny wrote: 3. Put it in an ebuild, after all. This will add a lot of complexity but GPG comes for free, plus some people will actually test and stabilize it. I do. It seems like a lot of work, but we can test and quick-stable it. Thank you. If what you

Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86

On 01/23/2015 03:22 PM, Michał Górny wrote: Dnia 2015-01-23, o godz. 14:26:48 Michael Orlitzky m...@gentoo.org napisał(a): On 01/23/2015 02:13 PM, Michał Górny wrote: To help you enable the correct USE flags, we are providing a Python script which generates the correct value from your /proc

<    3   4   5   6   7   8   9   10   >