[gentoo-dev] masking and removing *coin packages

[Anthony G. Basile]

Hi everyone,

I emailed the list some time ago about giving away a bunch of bitcoin
forks to see if anyone was interested in taking them.  I didn't get any
feedback so as of tomorrow I'll be masking the following for removal in
30 days.

net-dns/namecoind
net-dns/namecoin-qt

net-p2p/bitcoinxtd
net-p2p/bitcoinxt-qt

net-p2p/litecoind
net-p2p/litecoin-qt

net-p2p/ppcoind
net-p2p/ppcoin-qt

net-p2p/primecoind
net-p2p/primecoin-qt

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] JavaScript packages?

[Zac Medico]

On Mon, Jul 4, 2016 at 1:20 AM, Nicolas Bock  wrote:
> On 07/04/2016 10:15 AM, Daniel Campbell wrote:
>> On 07/04/2016 12:57 AM, Nicolas Bock wrote:
>>> Hi,
>>>
>>> I would like to package a code that depends on JavaScript packages. The
>>> suggested installation procedure from upstream involves running `npm
>>> install ...`. How do we (or do we?) deal with JavaScript packages?
>>>
>>> Best,
>>>
>>> Nick
>>>
>> The better question to ask is "what does this program need in order to
>> function?" If it installed through 'npm', that's going to point to Node.
>> Whatever format Node uses for its packages, you should read it and find
>> out if it requires anything else besides Node. If other Node packages
>> are needed, they may be in the tree already.
>>
> The program runs without JS. However, it can also run a server that
> provides a UI through a browser. That's the part that requires the JS.
>

I've seen some packages provide a "pre-built" javascript bundle, which
is great because then you don't need a bunch of nodejs modules just to
minify some javascript and whatnot.

Alternatively, you could have a pre-made tarball of nodejs modules
that's downloaded via SRC_URI and used only at build time.

[gentoo-dev] [warning] the bug queue has 82 bugs

[Alex Alexander]

Our bug queue has 82 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] Last rites: kde-misc/katelatexplugin, kde-misc/kosd

[Michael Palimaka]

# Michael Palimaka 

[gentoo-dev] Remove FCDSL_CARDS and FRITZCAPI_CARDS from USE_EXPAND

[Ulrich Mueller]

USE_EXPAND in base/make.defaults and embedded/make.defaults lists the
FCDSL_CARDS and FRITZCAPI_CARDS variables, which appear to be unused.

Unless there are objections, I am going to remove both in two days
from now.

Ulrich


pgpM4fLQeGLtx.pgp
Description: PGP signature

[gentoo-dev] Last rites: kde-apps/kdebindings-meta, kde-base/kimono, kde-base/korundum, kde-base/krossjava, kde-base/krossruby, kde-base/perlkde, kde-base/perlqt, kde-base/qtruby, kde-base/qyoto, kde-

[Michael Palimaka]

# Michael Palimaka  (7 Jul 2016)
# Dead upstream and unsupported. Bug 586276.
# Masked for removal in 30 days.
kde-apps/kdebindings-meta
kde-base/kimono
kde-base/korundum
kde-base/krossjava
kde-base/krossruby
kde-base/perlkde
kde-base/perlqt
kde-base/qtruby
kde-base/qyoto
kde-base/smokegen
kde-base/smokekde
kde-base/smokeqt

Re: [gentoo-dev] Re: Last rites: www-apps/egroupware

[Tomas Mozes]

On Thu, Jul 7, 2016 at 8:50 AM, J. Roeleveld  wrote:

> On Thursday, July 07, 2016 06:37:09 AM Duncan wrote:
> > J. Roeleveld posted on Wed, 06 Jul 2016 20:22:57 +0200 as excerpted:
> > > On Thursday, June 30, 2016 10:30:07 PM Aaron Bauman wrote:
> > >> # Aaron Bauman  (30 Jun 2016)
> > >> # Unpatched security vulnerability per bug #509920.
> > >> # Removal in 30 days www-apps/egroupware
> > >
> > > Why is this bug being used to treeclean egroupware?
> > >
> > > Why is bug  461212 not being used to actually resolve the issue?
> > > If I would actually be confident that it would actually be used, I
> would
> > > have no issue on trying to get my latest ebuild ( version 14.3.20160525
> > > ) converted to the latest standards.
> >
> > According to equery meta, egroupware has no individual developer
> > maintainer and no proxied maintainer, only the webapps project as
> > maintainer.  And apparently there, nobody has been specifically
> > interested in egroupware, so it has fallen thru the cracks to some
> > degree, tho newer versions /may/ be in the webapps-experimental overlay.
>
> I tried contacting the web-apps project directly, but never received a
> reply.
>
> > Here's the webapps project wiki page:
> >
> > https://wiki.gentoo.org/wiki/Project:Webapps
> >
> > That has this to say when discussing the overlay, quote:
> >
> 
> >
> > The overlay can be found here:
> > https://cgit.gentoo.org/proj/webapps-experimental.git/
>
> Last commit in 2011.
>
> > Warning
> > Please remember that the applications available through the overlay might
> > compromise the security of your server!
> >
> > The overlay is an ideal playground for new developers wishing to join our
> > team. Once we see that you are capable of writing ebuilds of reasonable
> > quality, we can provide you with commit rights to the overlay.
> >
> > End quote.
> >
> >
> > So it's possible newer versions are in the overlay, and they simply
> > decided it was too much of a load to keep a version in the tree as well.
> >
> > If there /aren't/ newer versions in the overlay, presumably it's because
> > nobody that has access has been interested in maintaining it in the
> > overlay either.
> >
> > Either way, given your obvious interest, I'd suggest contacting them
> > about overlay commit rights, and/or volunteering to be the proxied
> > maintainer for this particular package.
>
> Is there a way of finding out who are actually in the web-app project and
> which
> of them would be able and willing to work with me on this and other web
> applications that I actively use?
>
> From the lack of response to the email and lack of updates on the overlay,
> the
> project seems dead to me.
>
> --
> Joost
>
>
>

It's really sad to see a user wanting to keep up the ebuild and with no
response from the webapps team. I can understand being busy, but by
checking https://bugs.gentoo.org/show_bug.cgi?id=461212 it seems it's a
long-term issue. Joost, please try to contact the proxy maintainers team
and open a pull-request on github for the bump, that may be a way.

Good luck.

Re: [gentoo-dev] why is the security team running around p.masking packages

[J. Roeleveld]

On Wednesday, July 06, 2016 11:13:55 PM Andrew Savchenko wrote:
> On Wed, 06 Jul 2016 20:23:46 +0900 Aaron Bauman wrote:
.

> Please understand me correctly: I'm not blaming you or security
> team for this or that issue. But it looks like security team indeed
> needs to review some policies and approaches to suit needs of
> Gentoo users better in both of terms of security and usability, to
> find some reasonable compromise between them, which will satisfy
> most users. For these very issues it looks like canceling "removal
> in 30 days" clause from p.mask action will do the job.

+1 on this. Please don't simply tree-clean packages because of security 
issues. Masking them with a reference to the security issues should be 
sufficient.

Some applications can easily be used safely even with gaping security holes. 
(A heavily firewalled box or air-gap comes to mind).

--
Joost


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

Re: [gentoo-dev] Re: Last rites: www-apps/egroupware

[J. Roeleveld]

On Thursday, July 07, 2016 06:37:09 AM Duncan wrote:
> J. Roeleveld posted on Wed, 06 Jul 2016 20:22:57 +0200 as excerpted:
> > On Thursday, June 30, 2016 10:30:07 PM Aaron Bauman wrote:
> >> # Aaron Bauman  (30 Jun 2016)
> >> # Unpatched security vulnerability per bug #509920.
> >> # Removal in 30 days www-apps/egroupware
> > 
> > Why is this bug being used to treeclean egroupware?
> > 
> > Why is bug  461212 not being used to actually resolve the issue?
> > If I would actually be confident that it would actually be used, I would
> > have no issue on trying to get my latest ebuild ( version 14.3.20160525
> > ) converted to the latest standards.
> 
> According to equery meta, egroupware has no individual developer
> maintainer and no proxied maintainer, only the webapps project as
> maintainer.  And apparently there, nobody has been specifically
> interested in egroupware, so it has fallen thru the cracks to some
> degree, tho newer versions /may/ be in the webapps-experimental overlay.

I tried contacting the web-apps project directly, but never received a reply.

> Here's the webapps project wiki page:
> 
> https://wiki.gentoo.org/wiki/Project:Webapps
> 
> That has this to say when discussing the overlay, quote:
> 

> 
> The overlay can be found here:
> https://cgit.gentoo.org/proj/webapps-experimental.git/

Last commit in 2011.

> Warning
> Please remember that the applications available through the overlay might
> compromise the security of your server!
> 
> The overlay is an ideal playground for new developers wishing to join our
> team. Once we see that you are capable of writing ebuilds of reasonable
> quality, we can provide you with commit rights to the overlay.
> 
> End quote.
> 
> 
> So it's possible newer versions are in the overlay, and they simply
> decided it was too much of a load to keep a version in the tree as well.
> 
> If there /aren't/ newer versions in the overlay, presumably it's because
> nobody that has access has been interested in maintaining it in the
> overlay either.
> 
> Either way, given your obvious interest, I'd suggest contacting them
> about overlay commit rights, and/or volunteering to be the proxied
> maintainer for this particular package.

Is there a way of finding out who are actually in the web-app project and which 
of them would be able and willing to work with me on this and other web 
applications that I actively use?

>From the lack of response to the email and lack of updates on the overlay, the 
project seems dead to me.

--
Joost

[gentoo-dev] Re: Last rites: www-apps/egroupware

[Duncan]

J. Roeleveld posted on Wed, 06 Jul 2016 20:22:57 +0200 as excerpted:

> On Thursday, June 30, 2016 10:30:07 PM Aaron Bauman wrote:
>> # Aaron Bauman  (30 Jun 2016)
>> # Unpatched security vulnerability per bug #509920.
>> # Removal in 30 days www-apps/egroupware
> 
> Why is this bug being used to treeclean egroupware?
> 
> Why is bug  461212 not being used to actually resolve the issue?
> If I would actually be confident that it would actually be used, I would
> have no issue on trying to get my latest ebuild ( version 14.3.20160525
> ) converted to the latest standards.

According to equery meta, egroupware has no individual developer 
maintainer and no proxied maintainer, only the webapps project as 
maintainer.  And apparently there, nobody has been specifically 
interested in egroupware, so it has fallen thru the cracks to some 
degree, tho newer versions /may/ be in the webapps-experimental overlay.

Here's the webapps project wiki page:

https://wiki.gentoo.org/wiki/Project:Webapps

That has this to say when discussing the overlay, quote:

Web applications in general tend to be a severe security liability. They 
are designed to communicate with the outside world and need to deal with 
a range of input from the Internet. Since it is often hard for developers 
to foresee all types of malicious input, security flaws are being 
detected rather frequently in the apps we maintain.

To reduce the impact of such incidents while still offering a wide range 
of different web applications, we created a Portage overlay that contains 
ebuilds for applications that we do not want to maintain in the main 
tree. Such applications either lack a developer willing to maintain it in 
Portage or have not been reviewed for security.

The overlay can be found here:
https://cgit.gentoo.org/proj/webapps-experimental.git/

Warning
Please remember that the applications available through the overlay might 
compromise the security of your server!

The overlay is an ideal playground for new developers wishing to join our 
team. Once we see that you are capable of writing ebuilds of reasonable 
quality, we can provide you with commit rights to the overlay.

End quote.


So it's possible newer versions are in the overlay, and they simply 
decided it was too much of a load to keep a version in the tree as well.

If there /aren't/ newer versions in the overlay, presumably it's because 
nobody that has access has been interested in maintaining it in the 
overlay either.


Either way, given your obvious interest, I'd suggest contacting them 
about overlay commit rights, and/or volunteering to be the proxied 
maintainer for this particular package.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman