Re: [gentoo-dev] [RFC] new eselect module: compiler

[Fabian Groffen]

On 08-08-2016 13:45:07 -0500, R0b0t1 wrote:
> On Mon, Aug 8, 2016 at 11:23 AM, Lei Zhang  wrote:
> > "cc" is the standard C compiler name defined in POSIX, so ideally any
> > gcc-agnostic programs should use "cc" instead of "gcc". Practically,
> > build tools like GNU Make and CMake would be affected as they use "cc"
> > implicitly.
> 
> It is not just programs which rely on GNU extensions, but poorly
> created scripts that rely on a compiler directly or otherwise break
> portability.

I'd agree and say "gcc" is hardcoded in many places, that's why I
believe Apple includes a gcc which is clang on their systems, same for
cc.

As a question to Lei, I'm wondering why you chose eselect compiler, and
not gcc-config to manage the links.  In a way, gcc-config is tailored
towards gcc, but it does a lot of things also for the environment.  With
clang, from my experience, you just want it as drop-in replacement for
gcc as it doesn't give you too much issues (on Darwin at least).

Fabian


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] Empty project: Desktop

[Jason Zaman]

On Sun, Aug 07, 2016 at 04:37:23PM +0200, Pacho Ramos wrote:
> El dom, 07-08-2016 a las 09:07 -0400, NP-Hardass escribió:
> > [...]
> > Well, that's easily remedied with an alias for the project that
> > contains
> > all the subprojects, no?
> > 
> 
> But I don't know if the projects will like to behave in that way...
> because freedesktop-bugs was behaving exactly in that way and, during
> the transition, it was agreed to stop using that and simply CC the
> right projects when needed :/
> 
> From my point of view we should simply kill that "Desktop" project as
> it serves no purpose and CC the relevant projects when needed, as I
> don't recall many cases of the old freedesktop-bugs behaving in the way
> you are suggesting (involving *all* desktop related projects in the bug
> reports). On the other hand it was ending up with most people under the
> subprojects simply ignoring the bug reports assigned to freedesktop-
> bugs

Removing it is fine. I'm in the freedesktop and Xfce projects and I had
no idea this Desktop project even existed.
Pretty sure everyone would just ignore anything from/to it anyway.
Problems with eg KDE and Xfce are mostly not really related. And the few
things that are related are more core components that are under
freedesktop (polkit/consolekit etc). In which case, that component is
fixed without needing to bother every single other project or we just CC
them all if need be.

-- Jason

Re: [gentoo-dev] Empty project: Desktop

[NP-Hardass]

On 08/07/2016 10:37 AM, Pacho Ramos wrote:
> El dom, 07-08-2016 a las 09:07 -0400, NP-Hardass escribió:
>>  [...]
>> Well, that's easily remedied with an alias for the project that
>> contains
>> all the subprojects, no?
>>
> 
> But I don't know if the projects will like to behave in that way...
> because freedesktop-bugs was behaving exactly in that way and, during
> the transition, it was agreed to stop using that and simply CC the
> right projects when needed :/
> 
> From my point of view we should simply kill that "Desktop" project as
> it serves no purpose and CC the relevant projects when needed, as I
> don't recall many cases of the old freedesktop-bugs behaving in the way
> you are suggesting (involving *all* desktop related projects in the bug
> reports). On the other hand it was ending up with most people under the
> subprojects simply ignoring the bug reports assigned to freedesktop-
> bugs
> 

Well, if no other DEs want it, I say go for it.  Your description of the
old way was before my time working on MATE, I think.  Where does that
place the DEs going forward? Subprojects of The root node, or something
else?

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] new eselect module: compiler

[R0b0t1]

On Mon, Aug 8, 2016 at 11:23 AM, Lei Zhang  wrote:
> "cc" is the standard C compiler name defined in POSIX, so ideally any
> gcc-agnostic programs should use "cc" instead of "gcc". Practically,
> build tools like GNU Make and CMake would be affected as they use "cc"
> implicitly.

It is not just programs which rely on GNU extensions, but poorly
created scripts that rely on a compiler directly or otherwise break
portability.

Re: [gentoo-dev] news item: grub2 multislot use flag is being disabled

[Brian Dolbec]

On Mon, 8 Aug 2016 09:12:32 -0500
William Hubbs  wrote:

> 

typo:  anyonewho 

missed a space

-- 
Brian Dolbec 



pgphFxTuJI75_.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs

[Brian Dolbec]

On Sun, 07 Aug 2016 10:24:08 +0200
Pacho Ramos  wrote:

> This packages are now up for grabs:
> app-portage/g-sorcery
> app-portage/gs-elpa
> app-portage/gs-pypi

I'll sign layman project up for these


-- 
Brian Dolbec 

Re: [gentoo-dev] Packages up for grabs

[Johannes Huber]

Am Samstag 06 August 2016, 14:44:15 schrieb Pacho Ramos:
> This packages are now up for grabs:
> app-editors/nvi
> dev-cpp/yaml-cpp

I take this one.

Greetings,
Johannes

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [RFC] new eselect module: compiler

[Lei Zhang]

2016-08-06 21:45 GMT+08:00 James Le Cuirot :
> On Thu, 28 Jul 2016 13:16:45 +0800
> Lei Zhang  wrote:
>
>> I'm proposing to offer a new eselect module "compiler". Briefly
>> speaking, it manages /usr/bin/{cc,c++} as symlinks to C/C++ compilers
>> specified by the user.
>
> I'm not on the toolchain team so I cannot comment much but be aware
> that there was previously an eselect module called "compiler". It was
> removed in 2007 because it did silly things. See this bug.
>
> https://bugs.gentoo.org/show_bug.cgi?id=199914
>
> I'm not suggesting that your version does silly things. :) I don't know
> how practical is it to swap "cc" with something other than gcc as I've
> never tried clang.

"cc" is the standard C compiler name defined in POSIX, so ideally any
gcc-agnostic programs should use "cc" instead of "gcc". Practically,
build tools like GNU Make and CMake would be affected as they use "cc"
implicitly.

OTOH, POSIX doesn't require the presence of C++ compiler on a
conformant system; "c++' is just a de facto standard.


Lei

Re: [gentoo-dev] news item: grub2 multislot use flag is being disabled

[Ian Stakenvicius]

On 08/08/16 10:12 AM, William Hubbs wrote:
> The multislot use flag in sys-boot/grub-2.x, which has been enabled by
> default, is being switched to disabled by default.
> 
> This means that, for all new systems, and for anyone who doesn't take
> action, all of the binaries and documentation in grub-2 that have grub2
> at the start of their names will be renamed to just grub to match
> upstream defaults. For example, grub2-mkconfig will become
> grub-mkconfig, grub2-install will become grub-install, etc.
> 
> If you do not want this to happen on your system, add the following line
> to /etc/portage/package.use.
> 
> sys-boot/grub multislot
> 


The following wording might be a little more neutral; i found when
reading the original version (until i reached the end that is) it
seemed as if the flag was being removed rather than just not being
default-enabled anymore.

-

The multislot use flag in sys-boot/grub-2.x, which had been enabled by
default, is now off by default.

When the flag is enabled, all upstream binaries and documentation are
renamed to "grub2" so as not to collide with grub-0.  Now that the use
flag is no longer default-enabled, these names will revert back to
their upstream defaults.  For example, grub2-mkconfig will become
grub-mkconfig, grub2-install will become grub-install, etc.

If you wish to retain the previous naming scheme please make sure to
explicitly enable USE="multislot" on sys-boot/grub in the usual manner.

-




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] emerge: add --fuzzy-search and --search-similarity (bug 65566)

[Zac Medico]

On 08/08/2016 02:22 AM, Alexander Berntsen wrote:
> LGTM. Thanks for addressing my previous concerns.

Thanks, pushed:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=b7f0937a811ef4859333ccc45f8076dca109dc2f
-- 
Thanks,
Zac

Re: [gentoo-dev] news item: grub2 multislot use flag is being disabled

[waltdnes]

On Mon, Aug 08, 2016 at 09:12:32AM -0500, William Hubbs wrote

> Title: Grub2 multislot use flag is being disabled
> Author: William Hubbs 
> Content-Type: text/plain
> Posted: 2086-01-09

  ?!?!?!?!

> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: >=sys-boot/grub-2
> 
> The multislot use flag in sys-boot/grub-2.x, which has been enabled by
> default, is being disabled.
> 
> This means that, for all new systems, and for anyonewho doesn't take

  Minor typo...
s/anyonewho/anyone who/

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Farewell Gentoo.

[Brian Dolbec]

On Mon, 8 Aug 2016 08:24:16 -0400
"Jesus Rivero (Neurogeek)"  wrote:

> After so many years of being a proud Gentoo dev, it comes that time
> when I have to say bye (at least for now).
> 
> There are no words to describe what Gentoo and being a Gentoo dev
> meant for me.
> I've made really good friends, learned a ton of skills in many facets
> of computing from incredibly amazing and knowledgable people, and was
> a big part of me getting great job opportunities.
> 
> I didn't want to part without first saying thanks to all the devs
> that have and continue to make Gentoo such an amazing project. Keep
> making Gentoo better!
> 
> Keep in touch.
> Farewell, and thanks!
> 

Sad to see you go, but, also glad you were a dev for so many years :)

I hope to see you around in the future too, even if it is only for
visit :)

Take care, have fun,... don't be a stranger ;)

-- 
Brian Dolbec 

[gentoo-dev] news item: grub2 multislot use flag is being disabled

[William Hubbs]

Title: Grub2 multislot use flag is being disabled
Author: William Hubbs 
Content-Type: text/plain
Posted: 2086-01-09
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: >=sys-boot/grub-2

The multislot use flag in sys-boot/grub-2.x, which has been enabled by
default, is being disabled.

This means that, for all new systems, and for anyonewho doesn't take
action, all of the binaries and documentation in grub-2 that have grub2
at the start of their names will be renamed to just grub to match
upstream defaults. For example, grub2-mkconfig will become
grub-mkconfig, grub2-install will become grub-install, etc.

If you do not want this to happen on your system, add the following line
to /etc/portage/package.use.

sys-boot/grub multislot



signature.asc
Description: Digital signature

[gentoo-dev] Farewell Gentoo.

[Jesus Rivero (Neurogeek)]

After so many years of being a proud Gentoo dev, it comes that time when I
have to say bye (at least for now).

There are no words to describe what Gentoo and being a Gentoo dev meant for
me.
I've made really good friends, learned a ton of skills in many facets of
computing from incredibly amazing and knowledgable people, and was a big
part of me getting great job opportunities.

I didn't want to part without first saying thanks to all the devs that have
and continue to make Gentoo such an amazing project. Keep making Gentoo
better!

Keep in touch.
Farewell, and thanks!

-- 
Jesus Rivero (Neurogeek)
(former-)Gentoo Developer

Re: [gentoo-portage-dev] [PATCH] emerge: add --fuzzy-search and --search-similarity (bug 65566)

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

LGTM. Thanks for addressing my previous concerns.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXqE9jAAoJENQqWdRUGk8B4m8QAJyQ7AicdYPGvF8pnIsGafKf
uOXfVRh+jN87y8flu96+6a+SguwwjI1NW2mZdOTheXWW9nBzMDLdeMfUuuuwx0EW
syZpGxeQRFXJBIzuMLlyDRX01yLNMRhyzpaI+pxqz2T2yuCh4SqQ2a2qabzkhn7h
l13OAhhNHBJuoDWXAc5tdHMZvW02/KQr6ims8RhZL83Kdx4789gtfWQgkaZrEDy6
3rUt35h56UDoVSlvN0MDMIAEsozPvdbhAzz85/PtEAP0oeYRTRMRS6ppGqRtspQY
OEu/LcP5nQH9f+LiAg+F0XUiw9Bm1gVLQy+ZFQijFp5HUCNR3xYx7SpkQauiMDsf
1nJiagHJOz4vHH3yvzCRHnqLz2RnjdGEacQLNI7j36NpfsofIgUKwQefKraYIOgq
PUfEInIha1wv+cPIQx3CdzT7O8LKBdt5G3GsqkvKrSkgOWSReO33C8U14VNsYvjr
8c/9nenIyZSWTbDzZ4vq505j393bsHjOn63yCR9ILcPLXS0x0mkK3E8pQTG67p4o
JFdPGiX80SsrYN3hLbDNsnlWObfTL4Hc7iLuyZxrS+5NLbO1e9qBNFoD2DhTAuK5
gwE+li5uKduI8VAkdjGe72CnR6vPWTAHWkCjrX3FZDW6kE9YtkOUAjEpeMTMu706
IzvSyZiEBv9+nnmNjPw0
=fZcj
-END PGP SIGNATURE-

Re: [gentoo-dev] Patch for nvidia-drivers 367.35-r1 for kernels > 4.7.0

[Natanael Olaiz]

Hi,

Thanks for the detailed explanation of your testing procedure! It is good
to know what is behind a local patched driver, just in case.. :)


Best regards,
Natanael.

On 6 August 2016 at 16:20, David Haller  wrote:

> Hello,
>
> On Sat, 06 Aug 2016, Natanael Olaiz wrote:
> >Thank you for your patch. It was a good example to answer my question.
> >
> >But about the patch itself, I see that you are commented the code for
> >radix_tree_empty(...). In my patch I renamed it and it only usage instead,
> >so I'm sure it's calling the same code. I don't know the expected
> >compatibility with the kernel function implementation... But without
> >knowing the specific code for neither the nvidia driver nor the kernel, I
> >think the rename is safer...
>
> If you're in doubt or hit any trouble, yes, definitely change/adapt
> the patch to only rename that function and use the renamed function in
> the nvidia-driver as in your original patch. Keep/adapt the stuff
> about kernel-versions though. That's the "safe" approach.
>
> That "just put it in /etc/portage/patches/..." should work tough :)
>
>
> I've looked quite sharp at the code, i.e. in the nvidia code
>
> static bool radix_tree_empty(struct radix_tree_root *tree)
>  {
>  void *dummy;
>  return radix_tree_gang_lookup(tree, , 0, 1) == 0;
>  }
>
> vs. the kernel function
>
> static inline bool radix_tree_empty(struct radix_tree_root *root)
> {
> return root->rnode == NULL;
> }
>
> *oik* I miss a check for root != NULL there ;)
>
> Anyway, it was quite clear, that the driver calls kernel-stuff at this
> point anyway, radix_tree_gang_lookup() is a kernel function. (I love
> to use mc for digging for stuff like this!)
>
> So, digging into the kernel-source I came to the conclusion that
> calling the _kernel code_(!)
>
> radix_tree_gang_lookup(tree, , 0, 1);
>
> actually _is_ (or SHOULD BE) equivalent to the kernel code for
> the new
>
> radix_tree_empty(tree);
>
> and the latter should be faster (unless the compiler optimizes the
> 'radix_tree_gang_lookup(root, , 0, 1)' call away).
>
> All this applies if and only if the last two arguments of
> radix_tree_gang_lookup() are 0 and 1! And yes, I did go through the
> code of radix_tree_gang_lookup() step by step (repeatedly) until I was
> sure enough that the code is equivalent). But I'm not a C guru. I
> might have missed something even important. So, if more guys firm in C
> can check this ...
>
> As I'm a guy generally trusting the kernel guys _a lot_ and that
> nvidia assumedly got it right implementing 'radix_tree_empty(tree)'
> via 'radix_tree_gang_lookup(tree, , 0, 1);' and I think those
> two equivalent (with 0, 1 being the 3rd and 4th parameters!), I tried
> it, and it worked.
>
> And Meino has not yet complained. AFAIR he's around long enough to
> have complained by now (and circumvented problems with the patch).
> I'll ping him on the -user ML though in a parallel mail.
>
> Recap: calling the kernel function in this way (via the nvidia function)
>
> radix_tree_gang_lookup(tree, , 0, 1);
>
> is IMHO equivalent to calling the kernel function
>
> radix_tree_empty(tree);
>
> and on this I based my patch on. I'm rather sure from looking at the
> code. It worked in a short test. Meino has not complained yet. If you
> want a "sure"/"safe" approach, go with renaming the function in the
> nvidia-code, or wait a bit if Meino pipes up, he should've been
> running the driver with my patch for a week by now. Or until an
> official patch crops up.
>
> Or, take precautions, some other way to boot+chroot, and keep the
> "old" driver handy or to disable it, build a binary package of the
> previous driver, have an older kernel ready etc. pp., you know the
> drill, don't you?
>
> -dnh
>
> --
> MCSE: "Microsoft Certified Stupidity enclosed"-- A. Spengler
>
>

Re: [gentoo-dev] [RFC] New global USE flag: sctp

[Andrew Savchenko]

On Sun, 31 Jul 2016 18:26:30 +0300 Andrew Savchenko wrote:
> Hello,
> 
> there are 8 packages in the tree using USE="sctp". Since meaning is
> the same I propose to add the following global USE flag:
> 
> sctp - Support for Stream Control Transmission Protocol
> 
> Here is the list:
> 
> dev-java/icedtea:sctp - Build the SCTP NIO channel implementation against 
> lksctp
> dev-lang/erlang:sctp - Support for Stream Control Transmission Protocol
> dev-libs/openssl:sctp - Support for Stream Control Transmission Protocol
> net-analyzer/netperf:sctp - Include tests to measure SCTP performance
> net-libs/netembryo:sctp - Support for Stream Control Transmission Protocol
> net-misc/iperf:sctp - Support for Stream Control Transmission Protocol
> net-misc/openssh:sctp - Support for Stream Control Transmission Protocol
> net-voip/yate:sctp - Enable SCTP sockets

No objections of 8 days => change is in the tree now.

Best regards,
Andrew Savchenko


pgp_YYaCN2aFp.pgp
Description: PGP signature

[gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andrew Savchenko]

On Mon, 1 Aug 2016 14:08:57 +0300 Andrew Savchenko wrote:
> Hi,
> 
> On Wed, 20 Jul 2016 13:13:49 -0400 NP-Hardass wrote:
> > This is the first draft of a news item describing a packaging change for
> > OpenAFS so that we no longer require the DEBUG_RODATA be turned off.
> 
> This is a second try with rewording of the first paragraph, since
> it was suggested that it is a bit awkward.
> 
> Title: OpenAFS no longer needs kernel option DEBUG_RODATA
> Author: NP-Hardass 
> Author: Andrew Savchenko 
> Content-Type: text/plain
> Posted: 2016-07-23
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2
> Display-If-Keyword: amd64
> Display-If-Keyword: ~amd64-linux
> Display-If-Keyword: ~sparc
> Display-If-Keyword: x86
> Display-If-Keyword: ~x86-linux
> 
> As a result of bug #127084 [1], it was determined that OpenAFS's
> kernel module required that the kernel's data structures be
> read-write (CONFIG_DEBUG_RODATA=n). With recent OpenAFS versions
> this limitation is no longer required. We tested the latest version
> of OpenAFS with Linux kernels from 3.4 till 4.6, and determined that
> OpenAFS kernel module works fine with CONFIG_DEBUG_RODATA=y.
> 
> Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no
> longer forced in the ebuild. Considering the security implications
> of having CONFIG_DEBUG_RODATA turned off, it is highly advised that
> you adjust your kernel config accordingly.  Please note that the
> default setting for CONFIG_DEBUG_RODATA is "y" and unless you have
> another reason for keeping it disabled, we highly recommend that
> you re-enable CONFIG_DEBUG_RODATA.
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=127084

No comments for a week => submitted.

Best regards,
Andrew Savchenko


pgpZO8cqeP0uo.pgp
Description: PGP signature

Re: [gentoo-dev] Call for help: python3.5 testing

[Jason Zaman]

On Sun, Aug 07, 2016 at 03:46:40PM -0500, R0b0t1 wrote:
> On Sun, Aug 7, 2016 at 12:27 PM, Mike Gilbert  wrote:
> > Hi all,
> >
> > I would like to make a push to get python3.5 stable in the next few
> > months. There are a couple things that need to happen first.
> >
> > 1. Add python3_5 to PYTHON_COMPAT for current ~arch packages. A list
> > of packages that need to be tested and marked compatible with
> > python3.5 is producted daily.
> >
> > https://qa-reports.gentoo.org/output/gpyutils/34-to-35.txt
> >
> > 2. Stabilize any packages necessary to support python3.5. A list is
> > also produced daily. For this step, I imagine we will create one giant
> > stablereq bug for the sake of arch testing efficiency, but feel free
> > to stabilize them ahead of that.
> >
> > https://qa-reports.gentoo.org/output/gpyutils/34-to-35-stablereq.txt
> >
> > If you have some time, please do some testing on packages from the
> > first list. For packages that have a working test phase, don't
> > necessarily expect all tests to pass; just look for regressions from
> > python3.4. For packages that have no test phase, a compile and basic
> > import test (python3.5 -c "import foo") is generally the best we can
> > do.
> >
> 
> I have been using in VMs since near it came out. Main incompatibility
> is with SELinux markings.

I just sent a whole bunch of patches upstream to fix all the outstanding
issues for selinux on python3. If you want to help test, that'd be
awesome. ping me on IRC and i'll give you the stuff.

-- Jason