[gentoo-dev] JavaScript packages?
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] JavaScript packages?
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. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] JavaScript packages?
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. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [gentoo-dev-announce] Last rites: dev-util/{...}
On Sun, 5 Jun 2016 23:53:02 +0300 Andrew Savchenko wrote: > On Sun, 5 Jun 2016 13:47:48 +0200 Patrice Clement wrote: > > # Patrice Clement (5 Jun 2016) > > # Unmaintained ebuilds. Upstream is either dead or AWOL. Also, most of these > > # ebuilds are still sitting in ~arch after years in the tree. > > Excuse me, but since when and based on what authority dead HOME or > the fact that ebuilds are ~arch only is sufficient basis for tree > cleaning?! > > If package is badly broken (e.g. doesn't build or have serious > security issues unfixed for a long time), then yes — they can be > removed. > > I suggest you to remove that ridiculous commit. > > I'm using or have used some time ago the following sublist of now > masked packages: > > - dev-util/ccmalloc Builds, but during profiling segfaults with modern gcc because it uses unsafe builtin. Serious code rework is needed, so its sad, but package should be ditched. > - dev-util/dissembler Taken and updated. > - dev-util/duma > - dev-util/lsuio > - dev-util/pretrace > - dev-util/tinlink > - dev-util/usb-robot Taken, will update or fix issues later; as well as this package: dev-util/ald Best regards, Andrew Savchenko pgpnQfL1pCWNV.pgp Description: PGP signature
Re: [gentoo-dev] why is the security team running around p.masking packages
On Thu, 30 Jun 2016 22:51:51 -0400 Anthony G. Basile wrote: > I'm going to ask the security team to please stop running around > p.masking packages without acknowledgement from the maintainers. I'm > referring in particular to commit > 135b94c85950254f559f290f4865bce8b349a917 regarding monkeyd. Both of the > cited "security bugs" were long fixed, and even if the were not, they do > not merit masking because they were at best some information leakage > with minor impact. I have reverted that commit and would ask that > security stop this practice. Seconded here, the same applies to commit 61de68f69fdf7dd0aaa53303517c0e59738034c3, since security issues doesn't affect most popular use cases, and at least first security bug is fixed in [1]. Haven't tested the other bug, though. The same applies for the tree-cleaners team. While their job is very important, sometimes they are too hasty, like in commit 34181a1045d13142d959b9c894a46ddcebf3c512. If package builds and works fine, have no critical bugs opened, the sheer fact that upstream as inactive and package has no maintainer is no valid to remove package. The reason "are still sitting in ~arch" is even less valid, since it is absolutely fine that package never mades it into stable (some people do not use stable at all). [1] https://github.com/Mr-Dave/motion Best regards, Andrew Savchenko pgp0tJifYcOSA.pgp Description: PGP signature
[gentoo-dev] [warning] the bug queue has 89 bugs
Our bug queue has 89 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!
Re: [gentoo-dev] why is the security team running around p.masking packages
On Mon, Jul 4, 2016 at 4:40 PM, Andrew Savchenko wrote: > > The same applies for the tree-cleaners team. While their job is > very important, sometimes they are too hasty, like in commit > 34181a1045d13142d959b9c894a46ddcebf3c512. If package builds and > works fine, have no critical bugs opened, the sheer fact that > upstream as inactive and package has no maintainer is no valid to > remove package. The reason "are still sitting in ~arch" is even > less valid, since it is absolutely fine that package never mades it > into stable (some people do not use stable at all). > ++ To treeclean a package it should be both unmaintained and have a significant QA issue of some kind. Simply having open bugs shouldn't be sufficient, and of course if it works fine there is no reason to boot it. Now, if the package is a blocker on some EAPI retirement or other tree-wide operation, that would be a great reason to treeclean it if it is unmaintained. Security issues should warrant masking fairly easily, but only if the maintainer is unresponsive or the package is unmaintained (or we're talking an end-of-the-world security issue). If the maintainer is about to commit a fix or disputes that the issue applies in the package, it is best to just work with them. Otherwise users will just end up putting entries in package.unmask that could cause them issues later. -- Rich
Re: [gentoo-dev] [PATCH 2/2] eclass/toolchain-funcs: add clang version functions
On 07/01/2016 03:02 PM, Michał Górny wrote:
> On Mon, 27 Jun 2016 17:04:41 -0500
> Austin English wrote:
>
>> From ec0be3d1a808ea0c5bdd081a4bb935f86bf78d44 Mon Sep 17 00:00:00 2001
>> From: Austin English
>> Date: Mon, 27 Jun 2016 16:58:07 -0500
>> Subject: [PATCH 2/2] eclass/toolchain-funcs: add clang version functions
>
> Why do you even ask for review if you can't wait till the weekend
> before committing?
There's no set time limit that I could find anywhere. I checked with my
mentor first, who said a few days was enough (as there were no comments
by anyone).
> I've already told you twice that I'm opposed to adding version querying
> functions for clang, especially for the use case you proposed. You
> should check for features, and not keep a huge list of supported gcc,
> clang, pathcc, icc... versions. With every random compiler pretending
> to be a random version of every other compiler.
I did not use in the original intended case, however I think that these
helpers are still useful. Why do we allow gcc version checks then?
There's no deprecated comment for these functions. By that logic, you
should not have added tc-is-{gcc,clang}, 2 weeks ago in
6984a5b149a215dd96a9759d3d1f251354faf38f. You should be testing for
compiler features directly, not keep a list of what compilers are
supported in the code...
The point of eclasses is to share code and make ebuild maintenance
easier. I don't see how allowing version checks for GCC only, when clang
is supported by a lot of ebuilds, makes that easier. Again, if you're so
opposed to compiler specific checks, then please remove them from
ebuilds using them and from toolchains-funcs.eclass (or at least mark
them as deprecated).
--
-Austin
GPG: 00B3 2957 B94B F3E1
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] why is the security team running around p.masking packages
On Tuesday, July 5, 2016 6:09:38 AM JST, Rich Freeman wrote: On Mon, Jul 4, 2016 at 4:40 PM, Andrew Savchenko wrote: The same applies for the tree-cleaners team. While their job is very important, sometimes they are too hasty, like in commit 34181a1045d13142d959b9c894a46ddcebf3c512. If package builds and works fine, have no critical bugs opened, the sheer fact that upstream as inactive and package has no maintainer is no valid to ... ++ To treeclean a package it should be both unmaintained and have a significant QA issue of some kind. Simply having open bugs shouldn't be sufficient, and of course if it works fine there is no reason to boot it. Now, if the package is a blocker on some EAPI retirement or other tree-wide operation, that would be a great reason to treeclean it if it is unmaintained. Security issues should warrant masking fairly easily, but only if the maintainer is unresponsive or the package is unmaintained (or we're talking an end-of-the-world security issue). If the maintainer is about to commit a fix or disputes that the issue applies in the package, it is best to just work with them. Otherwise users will just end up putting entries in package.unmask that could cause them issues later. That is exactly what happened here. We worked with Anthony following the p.mask, and we have always done so with all packages that resulted in a mask. Often, it simply highlights to the maintainer that a security issue is outstanding and needs attention. It also protects the user regardless of the vulnerabilities severity. Sometimes this a failure on upstream, which also raises additional concerns if multiple vulnerabilities exist. In this particular case the issues were outstanding for years. Most developers coordinate very well with us regarding their packages. Sometimes that involves relocation of sources upstream, reversioning upstream, etc. While we try to resolve it on our own, the expertise of the developer on that package is a tremendous asset in ensuring the package is no longer vulnerable. We even patch or verify source code changes ourselves to resolve bugs. In regards to the media-video/motion mask, you can follow up with the bug and see the continued efforts. Users have responded with relocated sources that have a fix for the package. Something that only familiarity or endless digging would bear fruit on. We are actively working to mitigate the vulnerability and get the package unmasked for the community. We are not just trying to kill things to kill them. The subject of this particular mailing list post is a little alarming and over reactive. We are not running around p.masking everyone's packages, but issues that have been outstanding for years often result in such courses of action. I personally told Anthony I should have requested his assistance initially on the matter, and I do apologize for that. He is an active developer who would respond in a timely manner. So once again, I do apologize. Finally, that does not dissolve the developer of providing usable, substantiated, and verifiable information regarding the vulnerabilities. The idea that a developer gets to choose whether or not they do so should not be considered. Anthony's verbiage on Freenode was very frank, in that if he chose to do so he would. We ask for all developers to assist and work together with us to fix these issues. You can see the fruits of such information from the developer following Alex Legler's comments on the bug and my follow up actions. -Aaron
Re: [gentoo-dev] [PATCH 2/2] eclass/toolchain-funcs: add clang version functions
On Mon, 4 Jul 2016 19:16:55 -0500
Austin English wrote:
> On 07/01/2016 03:02 PM, Michał Górny wrote:
> > On Mon, 27 Jun 2016 17:04:41 -0500
> > Austin English wrote:
> >
> >> From ec0be3d1a808ea0c5bdd081a4bb935f86bf78d44 Mon Sep 17 00:00:00 2001
> >> From: Austin English
> >> Date: Mon, 27 Jun 2016 16:58:07 -0500
> >> Subject: [PATCH 2/2] eclass/toolchain-funcs: add clang version functions
> >
> > Why do you even ask for review if you can't wait till the weekend
> > before committing?
>
> There's no set time limit that I could find anywhere. I checked with my
> mentor first, who said a few days was enough (as there were no comments
> by anyone).
>
> > I've already told you twice that I'm opposed to adding version querying
> > functions for clang, especially for the use case you proposed. You
> > should check for features, and not keep a huge list of supported gcc,
> > clang, pathcc, icc... versions. With every random compiler pretending
> > to be a random version of every other compiler.
>
> I did not use in the original intended case, however I think that these
> helpers are still useful. Why do we allow gcc version checks then?
Because the ebuilds are full of that nonsense, and developers using
them don't help you remove it.
If we committed every single thing someone thought someone else might
find useful one day, the eclass would be huge hogs full of useless code
that is only used because someone noticed the function and suddenly
came to conclusion it's a good idea to use it because someone added it.
Now let's add 4 additional functions for every single compiler that
someone may decide to support one day. I'm even strongly opposed to
adding functions that are used only theoretically.
> There's no deprecated comment for these functions. By that logic, you
> should not have added tc-is-{gcc,clang}, 2 weeks ago in
> 6984a5b149a215dd96a9759d3d1f251354faf38f. You should be testing for
> compiler features directly, not keep a list of what compilers are
> supported in the code...
Yes, I can revert this if you insist. And don't mind that all those
horribly broken ebuilds checking gcc versions will suddenly fail with
clang.
> The point of eclasses is to share code and make ebuild maintenance
> easier. I don't see how allowing version checks for GCC only, when clang
> is supported by a lot of ebuilds, makes that easier. Again, if you're so
> opposed to compiler specific checks, then please remove them from
> ebuilds using them and from toolchains-funcs.eclass (or at least mark
> them as deprecated).
How does ebuild maintenance become easier when you have to test a dozen
of versions of different compilers to figure out which one is
supported?
--
Best regards,
Michał Górny
Re: [gentoo-dev] [PATCH 2/2] eclass/toolchain-funcs: add clang version functions
On 07/05/2016 12:00 AM, Michał Górny wrote:
> On Mon, 4 Jul 2016 19:16:55 -0500
> Austin English wrote:
>
>> On 07/01/2016 03:02 PM, Michał Górny wrote:
>>> On Mon, 27 Jun 2016 17:04:41 -0500
>>> Austin English wrote:
>>>
From ec0be3d1a808ea0c5bdd081a4bb935f86bf78d44 Mon Sep 17 00:00:00 2001
From: Austin English
Date: Mon, 27 Jun 2016 16:58:07 -0500
Subject: [PATCH 2/2] eclass/toolchain-funcs: add clang version functions
>>>
>>> Why do you even ask for review if you can't wait till the weekend
>>> before committing?
>>
>> There's no set time limit that I could find anywhere. I checked with my
>> mentor first, who said a few days was enough (as there were no comments
>> by anyone).
>>
>>> I've already told you twice that I'm opposed to adding version querying
>>> functions for clang, especially for the use case you proposed. You
>>> should check for features, and not keep a huge list of supported gcc,
>>> clang, pathcc, icc... versions. With every random compiler pretending
>>> to be a random version of every other compiler.
>>
>> I did not use in the original intended case, however I think that these
>> helpers are still useful. Why do we allow gcc version checks then?
>
> Because the ebuilds are full of that nonsense, and developers using
> them don't help you remove it.
Ack.
> If we committed every single thing someone thought someone else might
> find useful one day, the eclass would be huge hogs full of useless code
> that is only used because someone noticed the function and suddenly
> came to conclusion it's a good idea to use it because someone added it.
>
> Now let's add 4 additional functions for every single compiler that
> someone may decide to support one day. I'm even strongly opposed to
> adding functions that are used only theoretically.
>
>> There's no deprecated comment for these functions. By that logic, you
>> should not have added tc-is-{gcc,clang}, 2 weeks ago in
>> 6984a5b149a215dd96a9759d3d1f251354faf38f. You should be testing for
>> compiler features directly, not keep a list of what compilers are
>> supported in the code...
>
> Yes, I can revert this if you insist. And don't mind that all those
> horribly broken ebuilds checking gcc versions will suddenly fail with
> clang.
So fix them properly, by detecting compiler features, not compiler name ;)
>> The point of eclasses is to share code and make ebuild maintenance
>> easier. I don't see how allowing version checks for GCC only, when clang
>> is supported by a lot of ebuilds, makes that easier. Again, if you're so
>> opposed to compiler specific checks, then please remove them from
>> ebuilds using them and from toolchains-funcs.eclass (or at least mark
>> them as deprecated).
>
> How does ebuild maintenance become easier when you have to test a dozen
> of versions of different compilers to figure out which one is
> supported?
My goal is clang support parity with gcc. If you are opposed to these
sort of checks, then why don't we deprecate and remove those functions?
I want to know why gcc deserves special treatment, either all compilers
should have easy way to check major/minor/full versions, or none should.
Obviously I'm not saying gcc should be removed now, but it could
certainly be marked deprecated so the usage doesn't spread (hopefully)
further.
--
-Austin
GPG: 00B3 2957 B94B F3E1
signature.asc
Description: OpenPGP digital signature
