Dnia 2015-09-18, o godz. 20:09:16
Fernando Rodriguez napisał(a):
> Github allows editting of comments in pull requests. Is there a policy
> regarding that? I've noticed a comment disappear which makes the rest of the
> conversation seem out of place.
We can't really do anything about that. How
Gentoo is a distribution that incorporates heterogeneous software packages,
each of which may have their own versioning scheme.
We kinda have to treat the upstream version as an opaque blob because of
this.
Maybe I'm missing something but I don't think it's ok to screw with
upstream supplied vers
On 19 September 2015 at 10:09, konsolebox wrote:
> As for A6FGHKE and TRIAL, it's impossible to tell their actual level
> values so even if we choose to map them lexicographically, we would
> still not be able to use a universal algorithm that could tell how it
> affects the base version (just lik
Github allows editting of comments in pull requests. Is there a policy
regarding that? I've noticed a comment disappear which makes the rest of the
conversation seem out of place.
--
Fernando Rodriguez
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Freitag, 18. September 2015, 07:10:56 schrieb Michał Górny:
>
> 1. You can't list developers who are not subscribed on the wiki.
- -EDEVELOPER, or PEBKAC
I suspect this problem will go away very quickly once the aliases are
generated from the w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Freitag, 18. September 2015, 06:49:07 schrieb Robin H. Johnson:
> On Wed, Sep 16, 2015 at 11:43:02PM +0200, Andreas K. Huettel wrote:
>
> > a) Disallow the term "herd". Noone uses it correctly anyway.
> >
> > b) package is "in herd" -> package is
On Sat, Sep 19, 2015 at 4:11 AM, Vladimir Smirnov wrote:
> On Fri, 18 Sep 2015 23:16:43 +0800
> konsolebox wrote:
>
>> If you avoid trying to adopt versioning practices which are far from
>> practical and very far from common it is (as proven by the example
>> code). The workaround for such rare
Dnia 2015-09-19, o godz. 03:50:52
konsolebox napisał(a):
> On Sat, Sep 19, 2015 at 2:23 AM, Michał Górny wrote:
> >
> >
> > Dnia 18 września 2015 11:32:15 CEST, konsolebox
> > napisał(a):
> >>This is what an ideal and simple versioning spec should look like to
> >>me. (Not the form, but the c
On Sat, Sep 19, 2015 at 2:58 AM, Matthew Thode
wrote:
> On 09/18/2015 01:24 PM, konsolebox wrote:
>> On Fri, Sep 18, 2015 at 11:38 PM, Matthew Thode
>> wrote:
>>> Are you stating this is for package epochs?
>>
>> I'm sorry but I'm not familiar with the term. If you mean package
>> versions, yes.
On Fri, 18 Sep 2015 23:16:43 +0800
konsolebox wrote:
> If you avoid trying to adopt versioning practices which are far from
> practical and very far from common it is (as proven by the example
> code). The workaround for such rare cases should be done on the
> ebuild's version.
>
Just have a l
On 09/18/2015 01:24 PM, konsolebox wrote:
> On Fri, Sep 18, 2015 at 11:38 PM, Matthew Thode
> wrote:
>> Are you stating this is for package epochs?
>
> I'm sorry but I'm not familiar with the term. If you mean package
> versions, yes.
>
> The current specification I also mentioned is this:
> ht
On Fri, Sep 18, 2015 at 11:38 PM, Matthew Thode
wrote:
> Are you stating this is for package epochs?
I'm sorry but I'm not familiar with the term. If you mean package
versions, yes.
The current specification I also mentioned is this:
https://projects.gentoo.org/pms/5/pms.html#x1-280003.2
Dnia 18 września 2015 11:32:15 CEST, konsolebox
napisał(a):
>This is what an ideal and simple versioning spec should look like to
>me. (Not the form, but the concept). I'm posting this here so it
>could be used as an added reference to anyone that would consider
>revising the current specific
On Fri, 18 Sep 2015 18:28:09 +0200
hasufell wrote:
> On 09/17/2015 06:36 PM, Alexis Ballier wrote:
> >
> > # @ECLASS-VARIABLE: PYTHON_COMPAT
> > # @DESCRIPTION:
> > # Tells the eclass the package has python code and forwards it to
> > python-r1.eclass. PYTHON_ECLASS=""
> > CATKIN_PYTHON_USEDEP="
On 09/17/2015 06:36 PM, Alexis Ballier wrote:
>
> # @ECLASS-VARIABLE: PYTHON_COMPAT
> # @DESCRIPTION:
> # Tells the eclass the package has python code and forwards it to
> python-r1.eclass.
> PYTHON_ECLASS=""
> CATKIN_PYTHON_USEDEP=""
> if [ -n "${PYTHON_COMPAT}" ] ; then
> PYTHON_ECLASS="python-
On 09/18/2015 04:32 AM, konsolebox wrote:
> This is what an ideal and simple versioning spec should look like to
> me. (Not the form, but the concept). I'm posting this here so it
> could be used as an added reference to anyone that would consider
> revising the current specification.
>
> Note:
On Fri, Sep 18, 2015 at 10:01 PM, Ciaran McCreesh
wrote:
> On Fri, 18 Sep 2015 17:32:15 +0800
> konsolebox wrote:
>> This is what an ideal and simple versioning spec should look like to
>> me.
>
> Versioning isn't ideal and simple.
If you avoid trying to adopt versioning practices which are far
On Fri, 18 Sep 2015 17:32:15 +0800
konsolebox wrote:
> This is what an ideal and simple versioning spec should look like to
> me.
Versioning isn't ideal and simple.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, Sep 18, 2015 at 5:16 AM, Kristian Fiskerstrand wrote:
> I do sincerely hope package maintainers
> have a well thought out setup for key management locally and in fact
> verify the OpenPGP signatures vs known good keys, and that appropriate
> measures are being taken in the case of non-main
On Fri, 18 Sep 2015 13:33:08 +0200
hasufell wrote:
> On 09/18/2015 01:32 PM, hasufell wrote:
> > On 09/18/2015 01:14 PM, Alexis Ballier wrote:
> >> On Fri, 18 Sep 2015 13:04:45 +0200
> >> hasufell wrote:
> >>
> >>> On 09/18/2015 12:56 PM, Alexis Ballier wrote:
> On Fri, 18 Sep 2015 11:58:09
On Fri, Sep 18, 2015 at 1:10 AM, Michał Górny wrote:
> Dnia 2015-09-17, o godz. 17:19:17
> Michael Orlitzky napisał(a):
>
>> Replying somewhere randomly with an idea.
>>
>> Since projects are now on the wiki, why don't we use that as the
>> canonical source of project members? It's machine readab
On 09/18/2015 01:32 PM, hasufell wrote:
> On 09/18/2015 01:14 PM, Alexis Ballier wrote:
>> On Fri, 18 Sep 2015 13:04:45 +0200
>> hasufell wrote:
>>
>>> On 09/18/2015 12:56 PM, Alexis Ballier wrote:
On Fri, 18 Sep 2015 11:58:09 +0200
hasufell wrote:
> On 09/18/2015 11:55 AM, Dun
On 09/18/2015 01:14 PM, Alexis Ballier wrote:
> On Fri, 18 Sep 2015 13:04:45 +0200
> hasufell wrote:
>
>> On 09/18/2015 12:56 PM, Alexis Ballier wrote:
>>> On Fri, 18 Sep 2015 11:58:09 +0200
>>> hasufell wrote:
>>>
On 09/18/2015 11:55 AM, Duncan wrote:
> Alexis Ballier posted on Fri, 18
On Fri, 18 Sep 2015 13:04:45 +0200
hasufell wrote:
> On 09/18/2015 12:56 PM, Alexis Ballier wrote:
> > On Fri, 18 Sep 2015 11:58:09 +0200
> > hasufell wrote:
> >
> >> On 09/18/2015 11:55 AM, Duncan wrote:
> >>> Alexis Ballier posted on Fri, 18 Sep 2015 11:04:19 +0200 as
> >>> excerpted:
> >>>
>
On Fri, 18 Sep 2015 13:04:45 +0200
hasufell wrote:
> On 09/18/2015 12:56 PM, Alexis Ballier wrote:
> > On Fri, 18 Sep 2015 11:58:09 +0200
> > hasufell wrote:
> >
> >> On 09/18/2015 11:55 AM, Duncan wrote:
> >>> Alexis Ballier posted on Fri, 18 Sep 2015 11:04:19 +0200 as
> >>> excerpted:
> >>>
>
On 09/18/2015 12:56 PM, Alexis Ballier wrote:
> On Fri, 18 Sep 2015 11:58:09 +0200
> hasufell wrote:
>
>> On 09/18/2015 11:55 AM, Duncan wrote:
>>> Alexis Ballier posted on Fri, 18 Sep 2015 11:04:19 +0200 as
>>> excerpted:
>>>
> Keep in mind what this implies when you change these dependencie
On Fri, 18 Sep 2015 11:58:09 +0200
hasufell wrote:
> On 09/18/2015 11:55 AM, Duncan wrote:
> > Alexis Ballier posted on Fri, 18 Sep 2015 11:04:19 +0200 as
> > excerpted:
> >
> >>> Keep in mind what this implies when you change these dependencies
> >>> without bumping the ebuilds that use them.
>
On 09/18/2015 11:55 AM, Duncan wrote:
> Alexis Ballier posted on Fri, 18 Sep 2015 11:04:19 +0200 as excerpted:
>
>>> Keep in mind what this implies when you change these dependencies
>>> without bumping the ebuilds that use them.
>>
>> only way i see these changing is with a new ros_messages_*** u
Alexis Ballier posted on Fri, 18 Sep 2015 11:04:19 +0200 as excerpted:
>> Keep in mind what this implies when you change these dependencies
>> without bumping the ebuilds that use them.
>
> only way i see these changing is with a new ros_messages_*** useflag,
> which will cause a rebuild anyway
This is what an ideal and simple versioning spec should look like to
me. (Not the form, but the concept). I'm posting this here so it
could be used as an added reference to anyone that would consider
revising the current specification.
Note: Assigning default values can be bypassed depending on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 09/18/2015 10:58 AM, Justin (jlec) wrote:
> Hello,
>
> there are quite a number of Manifest still not containing one or
> more of the three hashes. I would like to update them as far as we
> can download the sources.
>
> Procedure would be: 1. D
On 09/18/2015 11:10 AM, hasufell wrote:
> On 09/18/2015 11:06 AM, Alexis Ballier wrote:
>>>
>>> eclasses (and ebuilds) are always bash in gentoo and I'd vote for
>>> writing "true" bash code, to stay consistent
>>>
>>
>> it is "true" bash :)
>>
>
> No, it's compatibility mode. See bash manpage und
On 09/18/2015 11:06 AM, Alexis Ballier wrote:
>>
>> eclasses (and ebuilds) are always bash in gentoo and I'd vote for
>> writing "true" bash code, to stay consistent
>>
>
> it is "true" bash :)
>
No, it's compatibility mode. See bash manpage under "Compound Commands".
On Fri, 18 Sep 2015 10:37:04 +0200
hasufell wrote:
> On 09/18/2015 10:30 AM, Alexis Ballier wrote:
> > On Thu, 17 Sep 2015 23:17:11 + (UTC)
> > Duncan <1i5t5.dun...@cox.net> wrote:
> >
> >> Alexis Ballier posted on Thu, 17 Sep 2015 18:36:06 +0200 as
> >> excerpted:
> >>
> >>> if [ "${PV#
On Fri, 18 Sep 2015 10:36:02 +0200
hasufell wrote:
> How about something like
>
> case ${EAPI} in
> 5) : ;;
> *) die "EAPI=${EAPI:-0} is not supported" ;;
> esac
>
> to force people to stay up2date... then you can also drop most of
> those redunant "|| die"s for EAPI functions
>
On 09/18/2015 10:58 AM, Justin (jlec) wrote:
>
> 4.
> What do you think is the best commit mode? PKG based, Cat based or repo based?
>
Repo based, don't bother with hundreds of commit messages. It's all
about the same problem.
Hello,
there are quite a number of Manifest still not containing one or more of the
three hashes. I would like to update them as far as we can download the sources.
Procedure would be:
1. Download package
2. verify current hashes match
3. Calculate new
4. commit
Following question need to be ans
On 09/18/2015 10:30 AM, Alexis Ballier wrote:
> On Thu, 17 Sep 2015 23:17:11 + (UTC)
> Duncan <1i5t5.dun...@cox.net> wrote:
>
>> Alexis Ballier posted on Thu, 17 Sep 2015 18:36:06 +0200 as excerpted:
>>
>>> if [ "${PV#}" != "${PV}" ] ; then
>>> SCM="git-r3"
>>> fi
>>
>> [and elsewhere]
How about something like
case ${EAPI} in
5) : ;;
*) die "EAPI=${EAPI:-0} is not supported" ;;
esac
to force people to stay up2date... then you can also drop most of those
redunant "|| die"s for EAPI functions
>
> IUSE="test"
> RDEPEND="
> dev-util/catkin${CATKIN_PYTHON_US
On Thu, 17 Sep 2015 23:17:11 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> Alexis Ballier posted on Thu, 17 Sep 2015 18:36:06 +0200 as excerpted:
>
> > if [ "${PV#}" != "${PV}" ] ; then
> > SCM="git-r3"
> > fi
>
> [and elsewhere]
>
> I've seen this asked in other eclass review cont
> On Thu, 17 Sep 2015, Michał Górny wrote:
>> Let's please first decide on the greater scheme of projects, teams,
>> and herds. Starting to change files before we have any plan doesn't
>> make sense.
> We already decided we move projects to Wiki. I don't think we're
> going to decide to move
41 matches
Mail list logo
