Rich Freeman posted on Sat, 12 Sep 2015 06:48:13 -0400 as excerpted:
> On Sat, Sep 12, 2015 at 6:00 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>>
>> Just bite the bullet and create entire USE flag families such that an
>> ebuild can choose the flag appropriate to how it actually uses it.
>> AFAIK t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
In my wine-a-holics overlay, I used symlinks. I found that
occassionally, git would act up and replace the symlink with the linked
file when committing. I never found out how or why, but for this
reason alone, I highly recommend against it.
Regard
On Sun, Sep 13, 2015 at 01:30:44PM +1200, Kent Fredric wrote:
> If the patch is automatedly filed against bugzilla, people will
> assume viewing that patch tells them all they need to know.
>
> But the reality is somebody may rebase/amend/repush to the
> publicised branch location before any devel
On 13 September 2015 at 09:15, hasufell wrote:
> Because that is not a valid bug report. Patches must be attached to
> bugzilla.
I would recommend against attaching the pull in patch form against
bugzilla. It might lead to unintentionally misleading consequences.
If the patch is automatedly fil
On Sat, 12 Sep 2015 21:12:25 +0200
Michał Górny wrote:
> 1. Many of the Gentoo developers have different nicknames on GitHub.
> Some developers don't even set their real names which makes them even
> harder to find.
This isn't directly related to your proposal, but may I jump in here:
Wouldn't i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Samstag, 12. September 2015, 21:12:25 schrieb Michał Górny:
> Potential solution: bi-dir github <=> bugzilla integration
> ==
The general idea is nice and neat.
> - handling comment edits
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Samstag, 12. September 2015, 23:31:11 schrieb W. Trevor King:
> Right, thanks. In that case, I think you'll need a hook to push a new
> patch whenever the GitHub branch is updated, rebased, etc. That could
> make for a lot of Bugzilla spam, bec
On Sat, Sep 12, 2015 at 11:15:14PM +0200, hasufell wrote:
> Because that is not a valid bug report. Patches must be attached to
> bugzilla.
Right, thanks. In that case, I think you'll need a hook to push a new
patch whenever the GitHub branch is updated, rebased, etc. That could
make for a lot o
On 09/12/2015 11:07 PM, W. Trevor King wrote:
> On Sat, Sep 12, 2015 at 10:11:27PM +0200, hasufell wrote:
>> We should probably auto-attach the patch from the pull request. This
>> can easily be done with link-rewriting, e.g.:
>> https://github.com/gentoo/gentoo/pull/83 to
>> https://github.com/gen
On Sat, Sep 12, 2015 at 10:11:27PM +0200, hasufell wrote:
> We should probably auto-attach the patch from the pull request. This
> can easily be done with link-rewriting, e.g.:
> https://github.com/gentoo/gentoo/pull/83 to
> https://github.com/gentoo/gentoo/pull/83.patch
> yields a nice downloadabl
On 09/12/2015 09:12 PM, Michał Górny wrote:
>
> Potential solution: bi-dir github <=> bugzilla integration
> ==
>
> My current idea would be pretty much that:
>
> 1. a new dedicated Gentoo bug would be automatically created for every
> pull
Hello, everyone.
The current workflow for handling github pull requests is at least
suboptimal. Handling pull requests takes a fair effort from the few
developers contributing there, and the progress is often stalled by
package maintainers which are either unresponsive or not registered on
github
Dnia 2015-09-12, o godz. 15:30:45
"Justin Lecher (jlec)" napisał(a):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 12/09/15 15:19, hasufell wrote:
> > +1 for banning symlinks
> >
>
> mrueg just mentioned a very crucial point. There are filesystem which
> don't support symlinks and
Am Samstag, 12. September 2015, 15:12:08 schrieb Justin Lecher (jlec):
> Hi,
>
> I would like to discuss the pro and cons of usage of symlinks in the
> tree, which are possible now as we aren't bound to CVS anymore
>
Please please just ban them completely.
--
Andreas K. Huettel
Gentoo Linux
I asked in #gentoo-embedded on freenode, but I would like to pose this question
to a wider auidence through the list.
What is the status of phone/tablet support? In specific, I am curious about:
* Modern hardware options (especially those without a hardware keyboard)
* Status of F/OSS drivers
* X
> On Sat, 12 Sep 2015, Justin Lecher (jlec) wrote:
> I would like to discuss the pro and cons of usage of symlinks in the
> tree, which are possible now as we aren't bound to CVS anymore
> We have quite a number of ebuilds already in the tree defining
> functionality for both, regular version
Saturday 12 Sep 2015 15:30:45, Justin Lecher (jlec) wrote :
> On 12/09/15 15:19, hasufell wrote:
> > +1 for banning symlinks
> >
>
> mrueg just mentioned a very crucial point. There are filesystem which
> don't support symlinks and would break everything.
>
>
+1 too
A functionality that causes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 09/12/2015 03:12 PM, Justin Lecher (jlec) wrote:
> Hi,
>
> I would like to discuss the pro and cons of usage of symlinks in
> the tree, which are possible now as we aren't bound to CVS anymore
>
> We have quite a number of ebuilds already in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/09/15 15:19, hasufell wrote:
> +1 for banning symlinks
>
mrueg just mentioned a very crucial point. There are filesystem which
don't support symlinks and would break everything.
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0
iQJ
+1 for banning symlinks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
I would like to discuss the pro and cons of usage of symlinks in the
tree, which are possible now as we aren't bound to CVS anymore
We have quite a number of ebuilds already in the tree defining
functionality for both, regular version and live
On 09/12/2015 01:52 AM, Daniel Campbell wrote:
> On 09/11/2015 01:34 PM, hasufell wrote:
>> I already use IUSE=gui and will keep doing that.
>
>> USE flags in gentoo are the best and the worst thing at the same
>> time. They are also mostly the main reason people don't like
>> gentoo, because USE
On Sat, Sep 12, 2015 at 6:00 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> Just bite the bullet and create entire USE flag families such that an
> ebuild can choose the flag appropriate to how it actually uses it. AFAIK
> this would need EAPI help, for reasons given below, but it should be
> doable
On Sat, Sep 12, 2015 at 12:55 AM, Raymond Jennings wrote:
> On Fri, Sep 11, 2015 at 5:13 AM, Rich Freeman wrote:
>>
>> On Fri, Sep 11, 2015 at 5:03 AM, Daniel Campbell wrote:
>> >
>> > I like the general 'gtk' flag we generally use to choose *which*
>> > toolkit, and local USE flags for specific
Raymond Jennings posted on Fri, 11 Sep 2015 21:55:46 -0700 as excerpted:
> On Fri, Sep 11, 2015 at 5:13 AM, Rich Freeman wrote:
>
>> USE=gui or something like that if the main effect is to have a gui or
>> not. That is the sort of thing that SHOULD go in make.conf or in a
>> profile. If disabl
25 matches
Mail list logo