Re: [gentoo-dev] Re: Packages up for grabs

[Kent Fredric]

On Sat, 6 Aug 2016 19:28:19 +
Peter Stuge  wrote:

> Michał Górny wrote:
> > Or file a pull request @ https://github.com/gentoo/gentoo/pulls.
> > That's the most convenient solution for most of proxy-maint team
> > members.  
> 
> How can I help improve that problematic situation?
> 
> It's not cool to gravitate the project towards GitHub Inc.

I kinda think this missed the point.  ( Though I did entirely expect a
complaint when he suggested it )

One avenue for contribution without Github: Patches by bugzilla, was
stated.

That will work, and is not restricting anyones freedom. It may however,
restrict convenience. But not freedom.

As far as I'm concerned, the statement about Github was a "oh, yeah,
and if you want, Github works too, so if you find that more convenient,
so do we, go right ahead, but you ain't gotta".

Everyone is free to, and encouraged to, create better solutions.

But there's no force to use Github.

If Github dies tomorrow, Gentoo will not drop dead. The convenience
will be lost, but people will still be completely able to send queues
of patches via bugzilla, or email, in the event that web browsers all
spontaneously die and cease to be free by some dark voodoo magic.

`git format-patch` is after all optimised for that latter case somewhat.

Maybe we should look into an Email Based submission service, create a
gentoo mailing list exclusively for 3rd party (proxy-maint) mail patch
queues, optimised for receiving and vetting patch sequences.

You don't need some fancy Java wank for that.

Then all we'd need is some alternative implementation of
dev-perl/Gentoo-App-Pram that can read a local mbox, and select
emails/email threads containing patch series, apply them, push them,
and then auto-reply to the email with a confirmation.

And then people could continue to use Github for their
easy-fast-non-free-workflow, and they could use some email submission
thing for the slightly-less-easy-but-free-as-hell workflow.

And for extra fun, we could support non-patch-queue emails that
contained references to public arbitrary git repositories and
automatically configured itself to pick a patch series from it, like
this example [1]: 

1: https://groups.google.com/forum/#!topic/linux.kernel/w957vpu3PPU

I mean, What do the Linux Kernel use? It would be a shame if they were
happening to use the email based workflow like I suggested([2,3,4]), and
if only there was a Gentoo Staffer who knew how Linux Contributions
worked and had documented it (sarcasm: [5])

2: https://groups.google.com/forum/#!topic/linux.kernel/w957vpu3PPU
3: https://news.ycombinator.com/item?id=3960876
4: https://github.com/torvalds/linux/pull/17#issuecomment-5663780
5:
https://github.com/gregkh/kernel-tutorial/blob/master/walkthrough#L47-L52





pgpXCz1SbaYHQ.pgp
Description: OpenPGP digital signature

[gentoo-dev] Last rites: app-admin/mate-system-tools, mate-extra/mate-calc, mate-extra/mate-dialogs

[NP-Hardass]

# NP-Hardass  (6 Aug 2016)
# Masked for removal in 14 days.
# Upstream migrated from mate-calc to gnome's
# calculator (gnome-extra/gnome-calculator)
mate-extra/mate-calc

# NP-Hardass  (6 Aug 2016)
# Masked for removal in 14 days.
# Upstream migrated from mate-dialogs to gnome's
# zenity (gnome-extra/zenity)
mate-extra/mate-dialogs

# NP-Hardass  (6 Aug 2016)
# Masked for removal in 14 days.
# Upstream dropped support for this package, in part due
# to gnome dropping support for gnome-system-tools.
app-admin/mate-system-tools


-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Packages up for grabs

[Rich Freeman]

On Sat, Aug 6, 2016 at 4:55 PM, Michał Górny  wrote:
>
> GitHub works for us. GitHub works for our contributors. GitHub boosts
> our productivity, unlike those vain discussions. We don't have time for
> all this tin foil hat nonsense.
>

Then just ignore it.  If somebody wants to work on an alternative,
nobody can stop them.  Nobody is suggesting putting the github
solution on hold in the interim.

-- 
Rich

Re: [gentoo-dev] Re: Packages up for grabs

[Peter Stuge]

Peter Stuge wrote:
> How can I help improve ..?

Michał Górny wrote:
> people focused on preaching and/or implementing random crap-based
> solutions without even stopping for a few minutes to consider what
> we exactly need.

You could interpret my question as "what exactly do we need" ?


> GitHub works for us. GitHub works for our contributors. GitHub
> boosts our productivity, unlike those vain discussions.

Windows works for me. Windows works for my customers. Windows
boosts my business, unlike vain discussions about open source
and free software. ;) Maybe you get my point?


> We don't have time for all this tin foil hat nonsense.

I think we have all the time in the world, and I think it's important
for us to innovate also in this field if neccessary, as we have and
continue to do in other distro-development-related fields.


Thanks

//Peter

Re: [gentoo-dev] Re: Packages up for grabs

[Michał Górny]

On Sat, 6 Aug 2016 16:47:09 -0400
Rich Freeman  wrote:

> On Sat, Aug 6, 2016 at 3:28 PM, Peter Stuge  wrote:
> > Michał Górny wrote:  
> >> Or file a pull request @ https://github.com/gentoo/gentoo/pulls.
> >> That's the most convenient solution for most of proxy-maint team members.  
> >
> > How can I help improve that problematic situation?
> >
> > It's not cool to gravitate the project towards GitHub Inc.
> 
> I'm sure everybody would love to have a non-github alternative.  The
> problem is that they all tend to be Java-based and infra doesn't want
> to go near them (that isn't intended to imply anything other than the
> state of things).
> 
> So, it sounds like we either need a non-Java-based alternative, or a
> way to host Java applications.

No. The problem is that alternatives suggested so far have been crap,
and people focused on preaching and/or implementing random crap-based
solutions without even stopping for a few minutes to consider what we
exactly need.

GitHub works for us. GitHub works for our contributors. GitHub boosts
our productivity, unlike those vain discussions. We don't have time for
all this tin foil hat nonsense.

-- 
Best regards,
Michał Górny



pgpoGSVyIg2Qc.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Packages up for grabs

[Rich Freeman]

On Sat, Aug 6, 2016 at 3:28 PM, Peter Stuge  wrote:
> Michał Górny wrote:
>> Or file a pull request @ https://github.com/gentoo/gentoo/pulls.
>> That's the most convenient solution for most of proxy-maint team members.
>
> How can I help improve that problematic situation?
>
> It's not cool to gravitate the project towards GitHub Inc.
>

I'm sure everybody would love to have a non-github alternative.  The
problem is that they all tend to be Java-based and infra doesn't want
to go near them (that isn't intended to imply anything other than the
state of things).

So, it sounds like we either need a non-Java-based alternative, or a
way to host Java applications.

-- 
Rich

Re: [gentoo-dev] Packages up for grabs

[William Hubbs]

On Sat, Aug 06, 2016 at 12:47:41PM +0200, Pacho Ramos wrote:
> This packages are now up for grabs:
> app-eselect/eselect-lua

I'm taking this one, we use lua at work so I have an interest in it.

William


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: Packages up for grabs

[Peter Stuge]

Michał Górny wrote:
> Or file a pull request @ https://github.com/gentoo/gentoo/pulls.
> That's the most convenient solution for most of proxy-maint team members.

How can I help improve that problematic situation?

It's not cool to gravitate the project towards GitHub Inc.


//Peter

Re: [gentoo-dev] Looking for a new mentor...

[Jack Morgan]

Alex,

On 07/21/16 09:09, alexmcwhir...@triadic.us wrote:
> On 2016-07-20 21:55, Brian Dolbec wrote:
>> On Wed, 20 Jul 2016 15:13:56 -0400
>> alexmcwhir...@triadic.us wrote:
>>
>>> I've been working towards becomming a gentoo developer for while now
>>> in order to bring the sparc port up to speed with the rest of the
>>> gentoo project. In short there appear to be no active gentoo
>>> developers working on sparc.
>>>
>>> I had a mentor earlier this year, but i can no longer get in touch
>>> with him.
>>>
>>> I have both quizzes nearly complete, i just need someone to look over
>>> them and answer a question or two. Any help would be greatly
>>> appreciated.
>>>
>>
>> Alex, it would be helpful to list your timezone and normal availability
>> times. That will help potential mentors know if they match up
>> availability times.
>>
>> Aside from sparc related updates, is there any other areas of the ebuild
>> tree your more interested in like desktop environments, gnome, kde,
>> *box, networking, tools...
> 
> My timezone is EDT, pretty much available 10AM to 2AM EDT
> 
> Most of my interests will be related to server and / or networking type
> issues. I also have some interest in fixing up things like genkernel on
> other archs.

I can help with mentoring as a sparc developer. Please ping me off list
or in #gentoo-sparc (jmorgan).


Thanks,
-- 
Jack Morgan
Pub 4096R/761D8E0A 2010-09-13 Jack Morgan 
Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A

Re: [gentoo-dev] Re: Packages up for grabs

[Michał Górny]

On Sat, 6 Aug 2016 16:04:08 +
Peter Stuge  wrote:

> Felix Janda wrote:
> > I'd like become a proxy-maintainer for app-editors/nvi.  
> 
> Sweet! If there are some open bugs then please upload patched ebuilds
> and other neccessary files to the bugtracker, ideally as output by
> git format-patch, and then talk e.g. to #gentoo-proxy-maint on freenode
> to get someone to proxy them into the tree for you.
> 
> https://anongit.gentoo.org/git/repo/gentoo.git

Or file a pull request @ https://github.com/gentoo/gentoo/pulls. That's
the most convenient solution for most of proxy-maint team members.

-- 
Best regards,
Michał Górny



pgpiwbluX7Nnk.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Packages up for grabs

[Peter Stuge]

Felix Janda wrote:
> I'd like become a proxy-maintainer for app-editors/nvi.

Sweet! If there are some open bugs then please upload patched ebuilds
and other neccessary files to the bugtracker, ideally as output by
git format-patch, and then talk e.g. to #gentoo-proxy-maint on freenode
to get someone to proxy them into the tree for you.

https://anongit.gentoo.org/git/repo/gentoo.git


//Peter

Re: [gentoo-dev] Packages up for grabs

[Peter Stuge]

Andrew Savchenko wrote:
> On Sat, 6 Aug 2016 13:37:19 + Peter Stuge wrote:
> > Hi Pacho, many thanks for your work, but..
..
> > ..do you think you can arrange to post everything in one mail,
> > instead of 14 different ones in a single day?
> 
> I suppose these posts are automated (at least partially), since
> each of them is linked to a different retirement bug.

That would explain the many emails - then it will probably be halfway
straightforward to also bundle the bugs and send one email at say 2:00 am
or whenever is a likely time that Pacho is not doing retiring. :)


> So you shouldn't blame Pacho for his work.

I don't think I was - I wanted to nudge to improve the output of his work.

I like to follow what gets retired, in case I want to pick something up,
but I don't like to read 14 emails in one day with a few packages in each.


Another, maybe simpler, approach would be to have a stateless cronjob
instead of a queue, the job would just look at what retirement bugs
were changed (opened?) in the last while (day?), and send one email
listing all packages. Maybe it could also set some status in the bug,
to avoid duplicates because of DST or whatever.


Thanks a lot

//Peter

Re: [gentoo-dev] Empty project: Desktop

[Raymond Jennings]

If an empty project has subprojects, I think that violates the definition
of empty.

On Sat, Aug 6, 2016 at 8:46 AM, james  wrote:

> On 08/06/2016 09:29 AM, NP-Hardass wrote:
>
>> On 08/06/2016 04:31 AM, Pacho Ramos wrote:
>>
>>> Now https://wiki.gentoo.org/wiki/Project:Desktop
>>>
>>> Well, it seems that it's only "containing" other subprojects... but I
>>> am unsure if we really need it. Anyway, he is now empty
>>>
>>>
>>>
>>>
>> I think it makes sense to keep desktop environments in a logical
>> grouping.  There isn't a need for an overarching control structure right
>> now, but if there needs to be coordination of efforts, I think keeping
>> it in its current structure allows that to happen more easily than if we
>> didn't have all the DEs in a project together.
>>
>>
> +1
> James
>
>

Re: [gentoo-dev] Empty project: Desktop

[james]

On 08/06/2016 09:29 AM, NP-Hardass wrote:

On 08/06/2016 04:31 AM, Pacho Ramos wrote:

Now https://wiki.gentoo.org/wiki/Project:Desktop

Well, it seems that it's only "containing" other subprojects... but I
am unsure if we really need it. Anyway, he is now empty





I think it makes sense to keep desktop environments in a logical
grouping.  There isn't a need for an overarching control structure right
now, but if there needs to be coordination of efforts, I think keeping
it in its current structure allows that to happen more easily than if we
didn't have all the DEs in a project together.



+1
James

[gentoo-dev] Re: Packages up for grabs

[Felix Janda]

I'd like become a proxy-maintainer for app-editors/nvi.

--Felix

Re: [gentoo-dev] Empty project: Desktop

[NP-Hardass]

On 08/06/2016 04:31 AM, Pacho Ramos wrote:
> Now https://wiki.gentoo.org/wiki/Project:Desktop
> 
> Well, it seems that it's only "containing" other subprojects... but I
> am unsure if we really need it. Anyway, he is now empty
> 
> 
> 

I think it makes sense to keep desktop environments in a logical
grouping.  There isn't a need for an overarching control structure right
now, but if there needs to be coordination of efforts, I think keeping
it in its current structure allows that to happen more easily than if we
didn't have all the DEs in a project together.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

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

[David Haller]

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] Packages up for grabs

[Lars Wendler]

On Sat, 06 Aug 2016 13:36:54 +0200 Pacho Ramos wrote:

>This packages are now up for grabs:
>app-admin/keepassx
>media-sound/mumble
>media-sound/murmur
>
>

I gonna take all three packages.

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpy1KQr1by5T.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Packages up for grabs

[Peter Stuge]

Hi Pacho, many thanks for your work, but..

Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
> Date: Sat, 06 Aug 2016 15:22:22 +0200

..do you think you can arrange to post everything in one mail,
instead of 14 different ones in a single day?


Thank you

//Peter

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

[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.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgprP067hVCkX.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs

[Andrew Savchenko]

On Thu, 4 Aug 2016 14:53:07 -0700 Daniel Campbell wrote:
> app-cdr/bashburn
> media-sound/apulse
> 
> I no longer own an optical drive, and eventually had to get PA working
> in order to use OBS (they have limited ALSA functionality for the time
> being), so I'm unable to test them. Any takers?
> 
> I'll be dropping them to maintainer-needed in 30 days if nobody steps
> up. There are currently no open bugs for them; fairly easy to babysit.
> Would be good for proxy-maint.

I'll take apulse, sometimes I use it for steam and skype.

Best regards,
Andrew Savchenko


pgpwNUwhRIv_h.pgp
Description: PGP signature

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
dev-libs/libmongo-client

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:

app-admin/apachetop
app-editors/nvi
dev-cpp/yaml-cpp
dev-db/mysql-proxy
dev-db/unixODBC
dev-libs/hiredis
net-misc/tn5250
net-proxy/nutcracker
www-apache/mod_fastcgi
www-apache/mod_fastcgi_handler

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
app-admin/keepassx
media-sound/mumble
media-sound/murmur

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
app-arch/bsdsfv
app-misc/tdfsb
app-text/pastebinit
dev-cpp/libassa
dev-libs/argtable
dev-libs/libdbh
dev-libs/libtubo
dev-util/stubgen
media-sound/ario
media-sound/scmpc
net-misc/gtkvncviewer
net-misc/oidentd
net-wireless/ndiswrapper
sys-apps/audio-entropyd
sys-fs/gt5
x11-libs/libdesktop-agnostic
x11-libs/librfm
x11-misc/dockmanager
x11-misc/launchy

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
dev-python/cached-property
dev-python/python-stdnum
dev-python/simpleeval

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
sci-biology/ApE
sci-libs/naga

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
app-office/taskcoach
net-misc/omniORB

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

[Natanael Olaiz]

s/you are commented/you commented/

:)

On 6 August 2016 at 12:25, Natanael Olaiz  wrote:

> David,
>
> 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...
>
>
> Best regards,
> Natanael
>
>
> On 6 August 2016 at 04:50, David Haller  wrote:
>
>> Hello,
>>
>> On Fri, 05 Aug 2016, Mike Gilbert wrote:
>> >On Fri, Aug 5, 2016 at 3:10 PM, Natanael Olaiz  wrote:
>> >> I know that. But the patch should be applied *only* for versions of
>> kernels
>> >> 4.7+. So, I'm asking how is the policy for that.
>> >
>> >If you're asking for policy: The Gentoo packaging policy is not to do
>> >conditional patching. Instead, modify the patch so that the resulting
>> >code works for both cases. This can generally be accomplished via
>> >pre-processor macros.
>>
>> My patch does it like that. See
>>  https://archives.gentoo.org/gentoo-user/message/baa36d14d8c
>> dbf58404267ee2ffd34ea
>> Just dumping the attached patch into
>> /etc/portage/patches/x11-drivers/nvidia-drivers-367.35/
>> (and making it readable for the portage user) is sufficient.
>>
>> HTH,
>> -dnh
>>
>> --
>> Every feature is a bug, unless it can be turned off.  -- Karl Heuer
>
>
>

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

[Natanael Olaiz]

David,

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...


Best regards,
Natanael


On 6 August 2016 at 04:50, David Haller  wrote:

> Hello,
>
> On Fri, 05 Aug 2016, Mike Gilbert wrote:
> >On Fri, Aug 5, 2016 at 3:10 PM, Natanael Olaiz  wrote:
> >> I know that. But the patch should be applied *only* for versions of
> kernels
> >> 4.7+. So, I'm asking how is the policy for that.
> >
> >If you're asking for policy: The Gentoo packaging policy is not to do
> >conditional patching. Instead, modify the patch so that the resulting
> >code works for both cases. This can generally be accomplished via
> >pre-processor macros.
>
> My patch does it like that. See
>  https://archives.gentoo.org/gentoo-user/message/
> baa36d14d8cdbf58404267ee2ffd34ea
> Just dumping the attached patch into
> /etc/portage/patches/x11-drivers/nvidia-drivers-367.35/
> (and making it readable for the portage user) is sufficient.
>
> HTH,
> -dnh
>
> --
> Every feature is a bug, unless it can be turned off.  -- Karl Heuer

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
app-arch/pet2tgz
app-arch/unshield
app-misc/datefudge
app-misc/ddate
app-pda/dynamite
dev-libs/granite
dev-libs/keybinder
dev-util/pkgconfig-openbsd
media-libs/hal-flash
media-libs/libextractor
media-tv/gtk-v4l
net-analyzer/synscan
sys-apps/hotplug2stdout
sys-libs/libacpi
sys-power/yacpi

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

[Natanael Olaiz]

Thank you for your explanations! :)

Best regards,
Natanael.

On 6 August 2016 at 04:50, David Haller  wrote:

> Hello,
>
> On Fri, 05 Aug 2016, Mike Gilbert wrote:
> >On Fri, Aug 5, 2016 at 3:10 PM, Natanael Olaiz  wrote:
> >> I know that. But the patch should be applied *only* for versions of
> kernels
> >> 4.7+. So, I'm asking how is the policy for that.
> >
> >If you're asking for policy: The Gentoo packaging policy is not to do
> >conditional patching. Instead, modify the patch so that the resulting
> >code works for both cases. This can generally be accomplished via
> >pre-processor macros.
>
> My patch does it like that. See
>  https://archives.gentoo.org/gentoo-user/message/
> baa36d14d8cdbf58404267ee2ffd34ea
> Just dumping the attached patch into
> /etc/portage/patches/x11-drivers/nvidia-drivers-367.35/
> (and making it readable for the portage user) is sufficient.
>
> HTH,
> -dnh
>
> --
> Every feature is a bug, unless it can be turned off.  -- Karl Heuer

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
dev-python/sphinxcontrib-plantuml
media-gfx/transfig
media-gfx/xfig
sys-devel/qconf
sys-fs/vzquota
www-apps/redmine

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
media-gfx/cutycapt
media-gfx/opencsg
media-gfx/openscad
media-gfx/replicatorg
net-analyzer/zabbix
net-libs/wt
net-misc/hylafaxplus
net-misc/yajhfc
x11-misc/rednotebook

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
x11-misc/xac

[gentoo-dev] Empty project: Desktop

[Pacho Ramos]

Now https://wiki.gentoo.org/wiki/Project:Desktop

Well, it seems that it's only "containing" other subprojects... but I
am unsure if we really need it. Anyway, he is now empty

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
dev-util/shunit2

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
app-dicts/myspell-el
dev-python/pyringe
dev-python/pyroma
sys-apps/inxi