Andrew Savchenko posted on Sun, 29 Mar 2015 21:04:52 +0300 as excerpted:
> On Sun, 29 Mar 2015 19:52:38 +0200 Sebastian Pipping wrote:
>> On 29.03.2015 19:39, Andrew Savchenko wrote:
>> > On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote:
>> >> So I would like to propose that
>> >>
>> >>
On Sun, Mar 29, 2015 at 07:49:32PM -0400, Rich Freeman wrote:
> On Sun, Mar 29, 2015 at 7:28 PM, William Hubbs wrote:
> > On Mon, Mar 30, 2015 at 12:11:34AM +0200, Matthias Maier wrote:
> >>
> >> > Thoughts?
> >>
> >> One point in favor of the current practice (installing add-on files
> >> uncondi
On Mon, Mar 30, 2015 at 1:12 AM, Rich Freeman wrote:
> On Sun, Mar 29, 2015 at 5:56 PM, Davide Pesavento wrote:
>> On Sun, Mar 29, 2015 at 8:23 PM, Rich Freeman wrote:
>>
>>> qt is a pretty significant package to have break with multilib, and
>>> trying to run qt-5 on a stable system is already
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2015-03-29 23:59 UTC.
Removals:
dev-python/py-freebsd 2015-03-24 01:24:48 idella4
dev-python/cherryflow 2015-03-24 02:46:31 idella4
dev-python/colub
Next round:
* Recipe for handling "\.(php|php5|phtml|phps)\." manually added
* AddType (with similar problems) mentioned, too
* Typo "momment" fixed
(* Internel revision bump to 3, will be committed as revision 1)
(* Date bumped to today)
(* Links renumbered due to new link [2])
On Sun, Mar 29, 2015 at 7:28 PM, William Hubbs wrote:
> On Mon, Mar 30, 2015 at 12:11:34AM +0200, Matthias Maier wrote:
>>
>> > Thoughts?
>>
>> One point in favor of the current practice (installing add-on files
>> unconditionally) is the fact that you can basically do it for free - you
>> neither
On Mon, Mar 30, 2015 at 12:11:34AM +0200, Matthias Maier wrote:
>
> > Thoughts?
>
> One point in favor of the current practice (installing add-on files
> unconditionally) is the fact that you can basically do it for free - you
> neither have to depend on additional packages, nor is the presence o
On Sun, Mar 29, 2015 at 5:56 PM, Davide Pesavento wrote:
> On Sun, Mar 29, 2015 at 8:23 PM, Rich Freeman wrote:
>
>> qt is a pretty significant package to have break with multilib, and
>> trying to run qt-5 on a stable system is already a nightmare with the
>> qtchooser switch (in my case I ended
> Thoughts?
One point in favor of the current practice (installing add-on files
unconditionally) is the fact that you can basically do it for free - you
neither have to depend on additional packages, nor is the presence of
the add-on files a penalty in download time or storage.
Further, a lot of
On Sun, 29 Mar 2015 17:49:50 +0200
Michał Górny wrote:
> > Michał, as already discussed with Pacho [1], emul-linux-x86-jna can
> > just go away entirely. Nothing requires it and it doesn't make any
> > sense without emul-linux-x86-java though I note that isn't in the
> > list either; I thought it
On Sun, Mar 29, 2015 at 8:23 PM, Rich Freeman wrote:
> I think we really need to either stabilize 4.8.6, or backport
> qtchooser/multilib/etc to the current stable version.
>
Backporting is not an option. The introduction of multilib support in
qt4 required extensive changes to the eclass (substa
All,
I want to start a discussion about our add-on files practice and try to
improve it.
I agree it is reasonable to install bash completions
unconditionally, because bash is part of the base requirement for
Gentoo. However, I do not agree that we should continue installing
add-on files for every
On Sun, Mar 29, 2015 at 9:12 PM, Matthias Schwarzott wrote:
> On 29.03.2015 20:58, Matthias Schwarzott wrote:
>> Hi there!
>>
>> I updated my ~amd64 system recently to new hardware (Intel Core i3-4160).
>> Since then valgrind did no longer work for 32bit programs because
>> "-march=native" did cho
On 03/29/15 15:07, Matt Turner wrote:
On Sun, Mar 29, 2015 at 11:58 AM, Matthias Schwarzott wrote:
Hi there!
I updated my ~amd64 system recently to new hardware (Intel Core i3-4160).
Since then valgrind did no longer work for 32bit programs because
"-march=native" did choose instructions that
On Sun, 29 Mar 2015 23:35:54 +0600
"Vadim A. Misbakh-Soloviov" wrote:
> Despite of all you're talking about is right from paranoid point of
> view, I'd, anyway, say "DO NOT DO THAT", because you propose to
> revoke the right of choice from the users.
A "right of choice" from the user only makes
On 29.03.2015 20:58, Matthias Schwarzott wrote:
> Hi there!
>
> I updated my ~amd64 system recently to new hardware (Intel Core i3-4160).
> Since then valgrind did no longer work for 32bit programs because
> "-march=native" did choose instructions that valgrind does not support
> in 32bit mode (ev
On Sun, Mar 29, 2015 at 11:58 AM, Matthias Schwarzott wrote:
> Hi there!
>
> I updated my ~amd64 system recently to new hardware (Intel Core i3-4160).
> Since then valgrind did no longer work for 32bit programs because
> "-march=native" did choose instructions that valgrind does not support
> in 3
Hi there!
I updated my ~amd64 system recently to new hardware (Intel Core i3-4160).
Since then valgrind did no longer work for 32bit programs because
"-march=native" did choose instructions that valgrind does not support
in 32bit mode (even ld.so was unusable).
After some research I put this into
Dnia 2015-03-29, o godz. 21:31:49
Nikos Chantziaras napisał(a):
> On 29/03/15 21:00, Andrew Savchenko wrote:
> > */* long list of 433 flags
>
> Yeah, just noticed that I can't split the lines.
>
> I then tried to define an array of USE flags in make.conf:
>
>GLOBAL_USE_FLAGS=( ... )
>
> s
On 29/03/15 21:00, Andrew Savchenko wrote:
*/* long list of 433 flags
Yeah, just noticed that I can't split the lines.
I then tried to define an array of USE flags in make.conf:
GLOBAL_USE_FLAGS=( ... )
so that I can then use that array in package.use, but for some reason
make.conf doesn'
(crossposting to -dev since this is fairly high-impact)
On Sun, Mar 29, 2015 at 1:27 PM, Michael Palimaka wrote:
> On 30/03/15 03:43, waben...@gmail.com wrote:
>>
>> I also have dev-qt/qtcore-4.8.5-r2 and some other qt packages installed
>> but I had no problems with that.
>>
>> I'm on gentoo sta
On Sun, Mar 29, 2015 at 1:52 PM, Sebastian Pipping wrote:
> On 29.03.2015 19:39, Andrew Savchenko wrote:
>> On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote:
>>> So I would like to propose that
>>>
>>> * support for Git access through https:// is activated,
>>>
>>> * Git access through h
> GitHub does not support git:// but only secure protocols (HTTPS, SSH),
GitHub DO (!) support git://
$ git clone git://github.com/msva/mva-overlay.git
Cloning into 'mva-overlay'...
remote: Counting objects: 10435, done.
remote: Compressing objects: 100% (41/41), done.
remote: Total 10435 (delta 1
> OpenPGP (GPG is just one implementation), but indeed,
> that is what the gentoo-keys project is about. There is experimental
> support for OpenPGP verification in portage already using gkeys.
> Currently the focus is on getting developer's keys up to GLEP63 specs,
> i currently see 36 good Gentoo
> Doesn't git:// uses SSH wich is secure? I think that was on github.
git+ssh:// — does. git:// — does not. It is just git-daemon listening on
separate port and serving plaintext, readonly (by default) access.
signature.asc
Description: This is a digitally signed message part.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/29/2015 06:41 PM, Sebastian Pipping wrote:
> Hi!
>
...
>
> * Why do we serve Git over git:// and http:// if those are
> vulnerable to man-in-the-middle attacks (before having waterproof
> GPG protection for whole repositories in place)?
Op
>
> They would not do online banking over http, right? Why would they run
> code with root privileges from http?
1) Actually, they will :(
2) Because they can't review what bank received via insecure channel, while
they can review what they're themselves received via http/git.
--
Best regards
On Sun, 29 Mar 2015 19:52:38 +0200 Sebastian Pipping wrote:
> On 29.03.2015 19:39, Andrew Savchenko wrote:
> > On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote:
> >> So I would like to propose that
> >>
> >> * support for Git access through https:// is activated,
> >>
> >> * Git access
On 29.03.2015 19:56, Diamond wrote:
> Doesn't git:// uses SSH wich is secure? I think that was on github.
git:// is "the git protocol" [1] "with absolutely no authentication" and
no encryption.
GitHub does not support git:// but only secure protocols (HTTPS, SSH),
see [2].
Best,
Sebastian
[
On Sun, 29 Mar 2015 19:43:51 +0200 Michał Górny wrote:
> Dnia 2015-03-29, o godz. 20:35:27
> Andrew Savchenko napisał(a):
>
> > On Sun, 29 Mar 2015 19:28:22 +0200 Michał Górny wrote:
> > > > If this is not the case, and "*/* abi_x86_32" in package.use really
> > > > does
> > > > something diffe
On Sun, 29 Mar 2015 18:41:33 +0200
Sebastian Pipping wrote:
> Hi!
>
>
> For the current Gentoo Git setup I found these methods working for
> accessing a repository, betagarden in this case:
>
> git://anongit.gentoo.org/proj/betagarden.git
> (git://git.gentoo.org/proj/betagarden.git)
> (git
On 29.03.2015 19:39, Andrew Savchenko wrote:
> On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote:
>> So I would like to propose that
>>
>> * support for Git access through https:// is activated,
>>
>> * Git access through http:// and git:// is deactivated, and
>
> Some people have https
On 29/03/15 20:28, Michał Górny wrote:
Dnia 2015-03-29, o godz. 19:59:19
Nikos Chantziaras napisał(a):
According to emerge --info, ABI_X86 seems to append, not override. In
make.conf:
ABI_X86="32"
Then:
$ emerge --info | grep -i abi_x86
You get:
ABI_X86="32 64"
"64" seems to
Dnia 2015-03-29, o godz. 20:35:27
Andrew Savchenko napisał(a):
> On Sun, 29 Mar 2015 19:28:22 +0200 Michał Górny wrote:
> > > If this is not the case, and "*/* abi_x86_32" in package.use really does
> > > something different, then this is implemented in a way too confusing for
> > > people and
On Sun, 29 Mar 2015 20:35:27 +0300
Andrew Savchenko wrote:
> The proposal above is an absolute madness, especially for global
> USE flags.
>
> Why users should deal with dozens (if not hundreds useless */*)?
The syntax for package.use allows multiple flags per line, and
comments...
--
Ciaran M
On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote:
> So I would like to propose that
>
> * support for Git access through https:// is activated,
>
> * Git access through http:// and git:// is deactivated, and
Some people have https blocked. http:// and git:// must be
available read-on
Despite of all you're talking about is right from paranoid point of view, I'd,
anyway, say "DO NOT DO THAT", because you propose to revoke the right of
choice from the users.
It is user's decision, which protocol to use to fetch the sources. Although,
you're, of course, free to make layman to f
On Sun, 29 Mar 2015 19:28:22 +0200 Michał Górny wrote:
> > If this is not the case, and "*/* abi_x86_32" in package.use really does
> > something different, then this is implemented in a way too confusing for
> > people and should be considered a bug :-/
>
> Yes, USE support in make.conf is a bi
On Sun, 29 Mar 2015 19:23:51 +0200
Michał Górny wrote:
> Xperia X10 Mini, with ancient Android 2.1.
>
> bugs.gentoo.org works, though it complains about hostname mismatch (I
> guess it doesn't handle wildcard certs or sth).
Not exactly, it can't handle servers with more than one SSL certificate
Dnia 2015-03-29, o godz. 19:59:19
Nikos Chantziaras napisał(a):
> On 29/03/15 19:24, Michał Górny wrote:
> > Dnia 2015-03-29, o godz. 19:14:43
> > Nikos Chantziaras napisał(a):
> >
> >> On 17/03/15 18:29, Michał Górny wrote:
> >>> Dnia 2015-03-17, o godz. 16:55:32
> >>> René Neumann napisał(a):
Dnia 2015-03-29, o godz. 18:50:17
Hanno Böck napisał(a):
> On Sun, 29 Mar 2015 16:46:05 +0200
> Michał Górny wrote:
>
> > While I don't mind this entirely, we need to make sure to get things
> > right. For example, I'm quite unhappy being unable to use Forums or
> > sources.g.o from my phone be
Ben de Groot wrote:
> Title: FFmpeg default
> Posted: 2015-04-01
Bad date for such news.
//Peter
On 29/03/15 19:24, Michał Górny wrote:
Dnia 2015-03-29, o godz. 19:14:43
Nikos Chantziaras napisał(a):
On 17/03/15 18:29, Michał Górny wrote:
Dnia 2015-03-17, o godz. 16:55:32
René Neumann napisał(a):
Am 17.03.2015 um 16:33 schrieb Michał Górny:
However, some
users may prefer setting A
On Sun, 29 Mar 2015 16:46:05 +0200
Michał Górny wrote:
> While I don't mind this entirely, we need to make sure to get things
> right. For example, I'm quite unhappy being unable to use Forums or
> sources.g.o from my phone because of some SSL issues…
Can you be more specific on that? Of course
Hi!
For the current Gentoo Git setup I found these methods working for
accessing a repository, betagarden in this case:
git://anongit.gentoo.org/proj/betagarden.git
(git://git.gentoo.org/proj/betagarden.git)
(git://git.overlays.gentoo.org/proj/betagarden.git)
http://anongit.gentoo.org/git
Dnia 2015-03-29, o godz. 19:14:43
Nikos Chantziaras napisał(a):
> On 17/03/15 18:29, Michał Górny wrote:
> > Dnia 2015-03-17, o godz. 16:55:32
> > René Neumann napisał(a):
> >
> >> Am 17.03.2015 um 16:33 schrieb Michał Górny:
> >>> However, some
> >>> users may prefer setting ABI_X86 globally
Dnia 2015-03-30, o godz. 00:07:16
Ben de Groot napisał(a):
> Title: FFmpeg default
> Author: Ben de Groot
> Content-Type: text/plain
> Posted: 2015-04-01
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: virtual/ffmpeg
>
> Since the choice between ffmpeg and libav has been made more
On 17/03/15 18:29, Michał Górny wrote:
Dnia 2015-03-17, o godz. 16:55:32
René Neumann napisał(a):
Am 17.03.2015 um 16:33 schrieb Michał Górny:
However, some
users may prefer setting ABI_X86 globally to enable 32-bit libraries
in all packages that support building them. This can be done usin
Title: FFmpeg default
Author: Ben de Groot
Content-Type: text/plain
Posted: 2015-04-01
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: virtual/ffmpeg
Since the choice between ffmpeg and libav has been made more
explicit, there has been a lot of discussion about what the
default implementa
Dnia 2015-03-29, o godz. 11:57:12
James Le Cuirot napisał(a):
> On Sun, 29 Mar 2015 12:13:32 +0200
> Pacho Ramos wrote:
>
> > > >
> > Why do we need to keep app-emulation/emul-linux-x86-jna-20140508-r1 to
> > simply end up rdepending on
> > >=virtual/libffi-3.0.13-r1[abi_x86_32(-)] ? Also, no
Dnia 2015-03-27, o godz. 15:33:15
Hanno Böck napisał(a):
> I think defaulting the net to HTTPS is a big step for more security and
> I think Gentoo should join the trend here.
While I don't mind this entirely, we need to make sure to get things
right. For example, I'm quite unhappy being unable
Dnia 2015-03-29, o godz. 14:22:56
"Andreas K. Huettel" napisał(a):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Am Donnerstag, 26. März 2015, 17:51:04 schrieb William Hubbs:
>
> > I'm seeing at least two ways of handling zsh completion files in the
> > tree.
> >
> [...]
>
> > The o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Donnerstag, 26. März 2015, 17:51:04 schrieb William Hubbs:
> I'm seeing at least two ways of handling zsh completion files in the
> tree.
>
[...]
> The other method is shown by dev-vcs/hub at least, and maybe several
> other packages -- e.g. un
On Sun, 29 Mar 2015 12:13:32 +0200
Pacho Ramos wrote:
> >
> Why do we need to keep app-emulation/emul-linux-x86-jna-20140508-r1 to
> simply end up rdepending on
> >=virtual/libffi-3.0.13-r1[abi_x86_32(-)] ? Also, no package in the
> >tree rdepends on this emul set and, then,
> packages outside
El sáb, 28-03-2015 a las 23:03 +0100, Michał Górny escribió:
> # Michał Górny (14 Sep 2014)
> # on behalf of gx86-multilib project
> # Mask emul-linux-x86 packages along with unported old versions
> # of reverse dependencies for removal in 60 days, bug #544876.
> # Please use multilib ebuilds wit
El sáb, 28-03-2015 a las 17:20 +0100, Magnus Granberg escribió:
> Hi
>
> As some of you may know, I have been working on code for a tinderbox with
> frontend support. I think its time to move it to a offcial project.
> The Proof-Of-Concept (poc) is almost ready, but it still have alot of the
> f
56 matches
Mail list logo
