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
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
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 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
-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
+1 for banning symlinks
-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
-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
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
> 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
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
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
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
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
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
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 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 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
-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
-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
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
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 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
-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
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
25 matches
Mail list logo