On Sun, Feb 9, 2014 at 1:23 PM, Richard Yao wrote:
> as the long as the few interested in it do not interfere with existing
> things, they are free to package it as they see fit.
Can we kindly refrain from starting another systemd flamewar in a
thread whose initial topic was thanking us for not l
On Mon, Feb 10, 2014 at 7:43 AM, Patrick Lauer wrote:
> Adding EAPI 1 and 2 ebuilds is forbidden. (repoman-fatal)
Does "adding" in this case include revbumps?
> More than two supported EAPIs is an unneeded burden on developers.
Is this really a generally held belief? I don't find it a burden t
On Mon, Feb 10, 2014 at 8:46 AM, Patrick Lauer wrote:
> I think it's safe to deprecate the antepenultimate EAPI, and then do the
> banning on a more delayed and controlled basis.
Yeah, I don't think we need to overly debate deprecation, other than
in corner cases like the toolchain (just that min
On Mon, Feb 10, 2014 at 9:23 AM, Tom Wijsman wrote:
> Well, that package maintainers are called developers on Gentoo isn't
> helping the interpretation here; regardless of how one defines those,
> both maintainers and PM implementers have to be taken into account here.
>
> From quick thoughts the
On Mon, Feb 10, 2014 at 10:31 AM, Ulrich Mueller wrote:
> I'd rather argue in terms of time instead of version numbers, because
> of the upgrade path for old systems. We guarantee one year for stable
> systems, but IMHO we should be more conservative for EAPI deprecation
> and go for two or three
On Mon, Feb 10, 2014 at 12:20 PM, Tom Wijsman wrote:
> On Mon, 10 Feb 2014 17:05:22 +0100
> Ulrich Mueller wrote:
>> The package manager must be able to uninstall old packages, which
>> essentially means that support for old EAPIs cannot be removed.
>
> That's only a subset of the entire EAPI, wh
On Mon, Feb 10, 2014 at 7:00 PM, yac wrote:
> While you are it, it would be great if you could get some stats on
> frequency of commits. Especially with reagrd to the planned cvs -> git
> migration since this might cause some issues/inconvenience if the whole
> portage will be one git repo.
Oh, c
On Tue, Feb 11, 2014 at 1:56 AM, Michael Palimaka wrote:
>
> Looks interesting. It reminds me somewhat of autodep[1].
>
Interesting - does this work? I don't see it in portage.
One of those ideas I've always wanted to implement is to create a
portage hook/patch that looks at the dependencies fo
On Tue, Feb 11, 2014 at 7:39 AM, Michael Palimaka wrote:
> On 02/11/2014 11:34 PM, Rich Freeman wrote:
>
>> One of those ideas I've always wanted to implement is to create a
>> portage hook/patch that looks at the dependencies for the package
>> being built and con
On Thu, Feb 13, 2014 at 10:30 AM, Kent Fredric wrote:
>
> On 14 February 2014 04:28, Anthony G. Basile wrote:
>>
>> 2) You want your vcs to show the diff in that file and you can make sense
>> of that diff.
>
>
> Though how many of them are "well formatted" SVGs, and how many of them are
> singl
On Thu, Feb 13, 2014 at 11:07 AM, Brian Dolbec wrote:
> Yes, if you can please work on updating it. Please contact us on the
> gentoo-portage-dev mail list or irc #gentoo-portage for changes to
> portage that will help keep it working in the future. I started
> development of a public_api branch
On Sat, Feb 15, 2014 at 8:30 AM, Jeroen Roovers wrote:
> On Sat, 15 Feb 2014 11:41:57 +0100
> Tom Wijsman wrote:
>
>> While it was not explained here, the idea can also move the actual
>> maintenance of the ebuild to the arch team; such that it becomes the
>> arch team's responsibility to deal wi
On Sun, Feb 16, 2014 at 3:41 AM, Pacho Ramos wrote:
> Also, keeping the bugs assigned to package maintainers will still allow
> them to try to get that pending bugs fixed (or resolved in some way) as
> they will take care more about that specific package status. If we get
> that bugs assigned to a
On Sun, Feb 16, 2014 at 8:48 AM, Jeroen Roovers wrote:
> The (slightly rhetorical) question was how an understaffed team could
> be realistically expected to start maintaining ebuilds. Your entire
> reply missed that point.
>
> The answer to the question is that you can't. A package maintainer
> c
On Sun, Feb 16, 2014 at 9:31 AM, Jeroen Roovers wrote:
> On Sun, 16 Feb 2014 09:22:49 -0500
> Rich Freeman wrote:
>
>> Well, they can assign the burden to an understaffed team if the team
>> wants them to.
>
> Achieving nothing in the process, even if the understaff
On Tue, Feb 25, 2014 at 6:39 AM, Thomas D. wrote:
> Also, I cannot belief that I cannot overwrite
> "/lib/udev/rules.d/80-net-setup-link.rules" via "/etc/udev/rules.d"...
I don't see why not - from the news item:
So, to clarify, you can override the new .rules file or the .link file in /etc
but u
On Tue, Feb 25, 2014 at 8:26 AM, Thomas D. wrote:
> Rich Freeman wrote:
>> On Tue, Feb 25, 2014 at 6:39 AM, Thomas D. wrote:
>>> Also, I cannot belief that I cannot overwrite
>>> "/lib/udev/rules.d/80-net-setup-link.rules" via "/etc/udev/rules.d"...
On Wed, Feb 26, 2014 at 5:49 AM, Thomas D. wrote:
>
> I don't see a need for mentioning that the actual configuration is
> located in "/lib/systemd/network/..." in the NEWS item.
I think it makes sense to keep this in. If somebody doesn't like the
default persistent naming conventions then they'
On Fri, Feb 28, 2014 at 9:44 AM, Samuli Suominen wrote:
> I completely agree using INSTALL_MASK is 100% responsibility of the user
> setting it, it's like blind 'rm -f', but some people
> don't agree and keep attacking me.
> I'm using the word attacking because it's constant, relentless,
> repeati
On Fri, Feb 28, 2014 at 10:59 AM, hasufell wrote:
> Despite that... the answer is already here:
> http://devmanual.gentoo.org/general-concepts/filesystem/index.html
>
>> Gentoo does not consider the Filesystem Hierarchy Standard to be an
>> authoritative standard, although much of our policy coinc
On Fri, Feb 28, 2014 at 8:09 PM, Steev Klimaszewski wrote:
> Please keep in mind that not every device that runs Gentoo has the
> ability to just pop new storage in with more space. The Beaglebone
> Black has 2GB eMMC.
Hence the reason I suggested that embedded systems are a perfect case
where I
On Fri, Feb 28, 2014 at 8:57 PM, Steev Klimaszewski wrote:
> The way that it's been presented throughout this thread made it seem
> like the network configurations when using e.g. networkd were being
> stored in there.
So, with the new udev what I gather is:
1. Config settings (the stuff you're
On Sat, Mar 1, 2014 at 1:31 PM, Alec Warner wrote:
>
> gconf, dconf, polkit, dbus, all do stuff like this. I actually find the
> solution somewhat elegant from my side as a sysadmin.
>
I think the "right approach" depends on the degree to which the file
requires tweaking.
For 99% of users, udev
On Sun, Mar 2, 2014 at 1:09 PM, Jeroen Roovers wrote:
> Honestly, setting up a tracker and blocking it with bugs about packages
> which someones-sub-SLOT-checking-script has vetted to be involved could
> be done in less than a day (for the hundred or so packages that depend
> on dev-libs/libgcrypt
On Sun, Mar 2, 2014 at 2:44 PM, Mike Gilbert wrote:
> On Sun, Mar 2, 2014 at 1:09 PM, Jeroen Roovers wrote:
>> Honestly, setting up a tracker and blocking it with bugs about packages
>> which someones-sub-SLOT-checking-script has vetted to be involved could
>> be done in less than a day (for the
On Mon, Mar 3, 2014 at 3:16 PM, Wyatt Epp wrote:
> If the _only_ way to get the config for something is ever to run a
> specific command specifically tailored for that purpose, then it's
> evidence of a truly shocking and advanced sadism (not to mention a
> complete and utter failure of software e
On Tue, Mar 11, 2014 at 1:54 PM, Michał Górny wrote:
> Dnia 2014-03-10, o godz. 18:30:29
> William Hubbs napisał(a):
>
>> Also, do not add hard dependencies to your packages on gentoo-functions.
>> The goal is to add gentoo-functions to @system once it is stable.
>
> Why? I'm pretty sure we were
On Wed, Mar 12, 2014 at 12:52 PM, William Hubbs wrote:
> On Wed, Mar 12, 2014 at 09:14:58AM -0400, Ian Stakenvicius wrote:
>> ...why not? As you've said yourself, nothing related to openrc uses
>> /etc/init.d/functions.sh; if everything else in the tree is going to
>> use the new gentoo-functions
On Wed, Mar 12, 2014 at 9:30 AM, Richard Yao wrote:
> Things that provide us with improvements over what we have are
> definitely worth consideration as GSoC projects. However, what is
> accepted ultimately depends on not only feedback from a potential
> mentor, but also a vote of Gentoo developer
On Wed, Mar 12, 2014 at 11:16 AM, Alexandre Rostovtsev
wrote:
> On Wed, 2014-03-12 at 14:24 +0100, Peter Stuge wrote:
>> Gilles Dartiguelongue wrote:
>> > Making udev dependency always on is a deliberate choice here
>>
>> I thought Gentoo was about users having choice? Sad face.
>
> Gentoo is usua
On Sat, Mar 22, 2014 at 7:48 PM, hasufell wrote:
>> https://wiki.gentoo.org/wiki/Package_Tags
> Sounds good, but how do we get consistency in there? I mean... this
> only works if we have some sort of consensus about tag names, at least
> more common ones.
The alternative to consistency/etc is cr
On Fri, Mar 28, 2014 at 5:48 PM, Rick "Zero_Chaos" Farina
wrote:
> All in all, this isn't a bad idea on the surface, but the first
> arguement shows immediately when this is scaled up. How many other
> packages have multiple libs with different sonames? Off hand, I can
> think of poplar, but I'm
On Fri, Mar 28, 2014 at 2:57 PM, Kent Fredric wrote:
>
> On 29 March 2014 06:12, Ciaran McCreesh
> wrote:
>>
>> These look a lot like they're just parameters to an eclass... An
>> alternative approach is to make this explicit, rather than having
>> zillions of environment variables:
>
> inherit p
On Sat, Mar 29, 2014 at 4:34 AM, Michał Górny wrote:
> I have already suggested separate category for perl virtuals but been
> quieted down at the time. I doubt people really want another category
> for virtuals since some of their poor tools rely on 'virtual/'.
So, first the obvious - the "poor
On Tue, Apr 1, 2014 at 9:58 AM, Alexandre Rostovtsev
wrote:
> On Tue, 2014-04-01 at 13:13 +0800, Ben de Groot wrote:
>>
>> In my opinion your multilib approach introduces an unnecessary degree
>> of complexity, which --as has been shown here again-- is prone to
>> breakage.
>>
>> It would be best
On Tue, Apr 1, 2014 at 11:28 AM, Tom Wijsman wrote:
> There is a strong structure present; for policy enforcement and
> breakage prevention, we have the ability to 1) act until there is
> disagreement, 2) vote by majority, 3) elevate to deputy and/or lead.
So, rather than making statements of bla
On Tue, Apr 1, 2014 at 8:13 PM, Patrick Lauer wrote:
> Now let's just continue to ignore the existing multilib-portage work so
> we can claim it's irrelevant, while shifting the conditions for
> accepting it whenever it is convenient, while silently adding the
> competing method in-tree so it's al
On Wed, Apr 2, 2014 at 3:55 PM, Mike Gilbert wrote:
> On the packages I maintain, I tend to use the latest unstable version
> of the software. Stabilizing them rarely crosses my mind.
>
> I rather like the semi-automated reminders. They come in handy for my
> own packages, as well as the large, un
(picking this email to reply to, but it isn't mean to single anybody out)
On Wed, Apr 2, 2014 at 4:07 PM, Rick "Zero_Chaos" Farina
wrote:
> Wow, now that I can see it your way I agree, I'm a horrible person.
> I'll stick to randomly changing the tree as I see fit with no discussion
> since forced
On Wed, Apr 2, 2014 at 4:23 PM, Alex Xu wrote:
> On 02/04/14 04:02 PM, Rich Freeman wrote:
>> Another option might be to have a tag in metadata.xml that flags
>> packages as never-stable
>
> Arguments have been made that such packages do not belong in g-x86.
>
Why
On Wed, Apr 2, 2014 at 4:27 PM, Rick "Zero_Chaos" Farina
wrote:
> Honestly I'd rather see this split up into libbluetooth and bluez than
> make it possible to build a nearly entirely crippled bluez with no udev
> support.
I think the right approach really depends on usefulness. Splitting
package
On Fri, Apr 4, 2014 at 1:50 AM, Michał Górny wrote:
> It also tries to use '--reflink=auto' if available to make use of
> btrfs CoW support.
++
Rich
On Tue, Apr 8, 2014 at 11:03 PM, Rick "Zero_Chaos" Farina
wrote:
> Gentoo typically tries to keep patching to a minimum in general. To be
> enabling something like this by default seems bad, the fact that it is
> openssh compounds that. +1 for removing the + and leaving this optional
> (default
On Wed, Apr 23, 2014 at 12:26 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> Yes, but... I think stable keywords on such archs must be used
> differently, and by virtue of necessity, mean something else than they
> mean on more mainstream archs.
This was basically the gist of the Council meeting that
On Sat, Apr 26, 2014 at 6:23 AM, Michał Górny wrote:
>
> As far as I understand, the LTO concept is suited well for most
> programs, though the results can vary. I agree that in the early stage
> many packages may be unhappy about it but as far as I understand, once
> it is more widespread only a
On Sat, Apr 26, 2014 at 11:00 AM, Martin Vaeth wrote:
> Rich Freeman wrote:
>> It does make sense to filter the flag when it is known to
>> not work.
>
> This would be the best solution of course: Recommend LTO and
> filter every occassion which breaks. But currently
On Sat, Apr 26, 2014 at 3:58 PM, Martin Vaeth wrote:
> I have not always tested whether filtering -fwhole-program
> alone would be sufficient, but in many cases I did, and
> usually it was not sufficient.
Well, there is certainly something going on here, because...
> app-arch/bzip2 +flto*
This
On Sat, Apr 26, 2014 at 10:37 PM, "C. Bergström"
wrote:
> #2 The only reference to anything which the compiler could impact is
> "Use Boyer-Moore (and unroll its inner loop a few times)." Finding out which
> flag controls that for ${CC} would have some importance. It's almost
> certainly combined
On Sun, Apr 27, 2014 at 7:41 AM, "C. Bergström"
wrote:
> On 04/27/14 06:23 PM, Rich Freeman wrote:
>> And yet, in the same paragraph you mention -O3, which is tantamount to
>> just setting a flag and walking away. That turns on 14 things you
>> probably don
On Sun, Apr 27, 2014 at 6:56 PM, Joshua Kinard wrote:
>
> My curiosity, as I have not attempted LTO yet on any machine, is what are
> the RAM requirements? Is it a hard limit, wherein the compiler simply fails
> if there isn't enough RAM, or does it just start hitting swap real hard?
It just all
On Mon, Apr 28, 2014 at 5:46 PM, Andrew Savchenko wrote:
> Hello,
>
> On Sun, 27 Apr 2014 07:23:11 -0400 Rich Freeman wrote:
>> And yet, in the same paragraph you mention -O3, which is
>> tantamount to just setting a flag and walking away. That turns
>> on 14 thing
On Fri, May 9, 2014 at 4:08 PM, Tom Wijsman wrote:
> On Fri, 09 May 2014 20:57:29 +0100
> Markos Chandras wrote:
>
>> I was wondering, is there a good reason we keep our own pkgconfig
>> files instead of communicating that to upstream and resolve that
>> properly?
>
> Yes, when your "instead of .
On Sat, May 10, 2014 at 9:00 AM, hasufell wrote:
>
> Our philosophy states that our tools "should be a joy to use". If we add
> random hackery on stuff that affects portability across distros, then
> this doesn't hold true anymore.
>
Which one of our tools is at risk of not being a joy to use? A
On Sat, May 10, 2014 at 9:36 AM, hasufell wrote:
> Longterm, this makes it year after year more difficult to develop
> software for "Linux". Instead (like valve), people start to develop for
> certain distros only (like Ubuntu), because it's just too much work to
> bother with all this hackery-her
On Mon, May 12, 2014 at 12:07 PM, Rick "Zero_Chaos" Farina
wrote:
> What about talking to local network resources? In my metasploit ebuild
> it has tests available which talk to a local database and are perfectly
> safe, however, if postgresql is started on the system the tests don't
> work, the
On Mon, May 12, 2014 at 1:22 PM, Rick "Zero_Chaos" Farina
wrote:
> That would be nice, can we do the network namespaces so that I at least
> don't have to bind to a random port? That alone would be a major
> improvement in usability.
>From my very limited understanding of network namespaces, when
On Tue, May 13, 2014 at 7:01 AM, Andrew Savchenko wrote:
>
> If we are trying to consider all possible cases, some filesystems
> may benefit even from compression of very small files (e.g. from
> 140 to 100 bytes) due to packing of multiple small files in the
> same inode. ReiserFS is a good examp
On Tue, May 13, 2014 at 1:28 AM, Andrew Savchenko wrote:
>
> Please do not enable them prior rigorous testing.
>
> I tried network-sandbox — this is a disaster. It brokes distcc
> completely since distcc client can't connect to remote servers (and
> even to a local one if any).
Certainly agree on
On Wed, May 14, 2014 at 12:53 PM, Roy Bamford wrote:
> What about not compressing files smaller than the filesysem block size
> at all. In my case its 4k. Any file gets allocated 4k on disc anyway,
> so compression/decompression is just a waste of resource for files
> <=4k.
>
> I'm not suggestin
On Fri, May 30, 2014 at 12:50 PM, Tom Wijsman wrote:
> On Fri, 30 May 2014 19:26:38 +0300
> Samuli Suominen wrote:
>
>> I have no plans in inserting my name to genkernel's ChangeLog,
>> and I've done my best to contact people (nobody cares)
>>
>> Only initramfs tool I care and can warmly recommen
On Fri, May 30, 2014 at 1:02 PM, Ben Kohler wrote:
> As nice at it sounds to just DROP these configs, that option is not really
> feasible considering the way we currently use genkernel in our handbook.
> Relying on the kernel's own defconfig, "genkernel all" will NOT produce the
> same mostly-usa
On Tue, Jun 3, 2014 at 7:25 AM, Samuli Suominen wrote:
>
> On 03/06/14 14:40, J. Roeleveld wrote:
>> Would have been nice to fix all the dependencies BEFORE marking the
>> systemd- depending "sys-power/upower-pm-utils" stable. -- Joost
>
> No clue what you mean, sys-power/upower-pm-utils doesn't d
On Tue, Jun 3, 2014 at 8:24 AM, Samuli Suominen wrote:
> On 03/06/14 15:08, Tom Wijsman wrote:
>> On Tue, 3 Jun 2014 07:35:42 -0400
>> Rich Freeman wrote:
>>
>>> This probably could have used a news item, as the change impacts both
>>> stable and ~arch user
On Tue, Jun 3, 2014 at 9:20 AM, Tom Wijsman wrote:
> On Tue, 3 Jun 2014 09:04:23 -0400
> Rich Freeman wrote:
>
>> This has already hit stable. The dependency on systemd is present in
>> sys-power/upower-0.9.23-r3, which was just stablized.
>
> Ehm, no, version 0.9
On Tue, Jun 3, 2014 at 9:46 AM, Samuli Suominen wrote:
> To prevent OpenRC users from installing this version because it's
> an old UPower with no pm-utils support, with no hibernate/suspend support,
> to ensure desktops don't end up with greyed out Hibernate/Suspend
> buttons
So, I get why you d
On Tue, Jun 3, 2014 at 10:05 AM, Tom Wijsman wrote:
> On Tue, 3 Jun 2014 09:53:45 -0400
> Rich Freeman wrote:
>
>> Whatever - short of profiles/mix-ins or whatever you want to do on a
>> big scale there isn't a simple solution to problems like this.
>
> Why is
On Tue, Jun 3, 2014 at 4:24 PM, Alan McKinnon wrote:
>
> Yes, it *is* a simple matter of running one easy command. Portage does
> that for you with trivial ease. But portage doesn't tell you *which* is
> the one easy command.
>
> A news item does that.
That is the real challenge here. It isn't o
On Mon, Jun 9, 2014 at 4:57 AM, Amadeusz Żołnowski wrote:
>
> We should focus on forcing people who were involved into OpenRC to
> document what they know.
Uh, you can't force anybody to do anything, and most of them are no
longer around. You can always encourage or ask nicely. You can also
set
On Tue, Jun 10, 2014 at 4:57 AM, Thomas Kahle wrote:
>
> My personal attitude: It is just not worth the effort to rewrite
> their build systems for the ~10 users out there. I have better
> things to do with my time and I think that these packages can
> live forever in the overlay and that is comp
On Tue, Jun 10, 2014 at 12:45 PM, Andrew Savchenko wrote:
>
> Why are you saying that git is inefficient with large projects? It
> was developed with efficiency in mind in the first place. And
> kernel guys will likely disagree with "git is not great with crazy
> big projects" statement.
The kern
On Tue, Jun 10, 2014 at 3:58 PM, hasufell wrote:
>
> interesting read:
> http://thread.gmane.org/gmane.comp.version-control.git/189776
>
> Does any1 know what fb currently uses or if any of these issues have
> been resolved?
>
Not sure, but I did a git status on the actual gentoo-x86 converted
re
On Tue, Jun 10, 2014 at 6:59 PM, Patrick Lauer wrote:
> The first migration attempt failed after consuming nearly 100GB of RAM!
> When it did work it took obscene amounts of time, and the result was
> unusably large (e.g. initial checkout would take 16GB RAM on the server,
> thus not allowing a fe
On Wed, Jun 11, 2014 at 12:17 AM, Patrick Lauer wrote:
> Now git has some/all of the needed features, and people wait on a future
> potential git migration instead of figuring out the important bits now
> (a good part of that is defined in GLEP 63, but there's no action apart
> from work on gentoo
On Wed, Jun 11, 2014 at 8:54 AM, Alex Xu wrote:
>
> https://bugs.gentoo.org/show_bug.cgi?id=333701:
>> What comment #2 should have said: "This bug is so low priority to the
>> overall initiative that there shouldn't be anyone considering it a
>> blocker, show me the git repo then we can talk" :)
>
On Wed, Jun 11, 2014 at 10:34 AM, Rich Freeman wrote:
> We have a git repo now. We can generate one at any time. We still
> don't have infra tools.
>
> I don't know if the repo is published anywhere, but there are plenty
> of bundles on dev.gentoo.org:/space/git-work/
On Fri, Jun 13, 2014 at 9:22 AM, Jeroen Roovers wrote:
> The problem I see is that anyone who wants to switch to having
> -fstack-protector enabled by default early will run into the glibc
> problem (much as I did), when all the bug reports that point out the
> problem have been closed as INVALID.
On Sat, Jun 14, 2014 at 12:31 PM, Ciaran McCreesh
wrote:
> On Sat, 14 Jun 2014 12:17:52 -0400
> Alexandre Rostovtsev wrote:
>> On Sat, 2014-06-14 at 16:56 +0100, Ciaran McCreesh wrote:
>> > On Sat, 14 Jun 2014 11:50:29 -0400
>> > Alexandre Rostovtsev wrote:
>> > > On Sat, 2014-06-14 at 16:13 +01
On Sat, Jun 14, 2014 at 5:46 PM, Jeroen Roovers wrote:
> On Sun, 15 Jun 2014 03:50:06 +0700
> "Vadim A. Misbakh-Soloviov" wrote:
>
>> You're right in all remarks, but Maxim is just proxy here.
>
> And that's where the whole proxy maintainership falls down, isn't it?
> The committer should check f
On Sat, Jun 14, 2014 at 9:44 PM, Jeroen Roovers wrote:
> On Sat, 14 Jun 2014 19:17:49 -0400
> Rich Freeman wrote:
>
>> Sure, those who commit are responsible for QA, but in general we
>> should be going easy on them, especially for minor stuff.
>
> Nobody was goi
I debated where to post this, but the topic is fairly dev-oriented and
has big long-term impact so I landed here. This really isn't
organizational in nature.
During the council meeting there was a bit of a philosophical debate
over the proper role of EAPI vs implementing functions in eclasses. I
On Mon, Jun 16, 2014 at 5:47 AM, Pacho Ramos wrote:
> El sáb, 14-06-2014 a las 12:50 -0400, Alexandre Rostovtsev escribió:
> [...]
>> A solution to unnecessary rebuilds in these situations, as well as for
>> case (1), might be in the form of subslots as a key:value list, with
>> different users su
On Tue, Jun 17, 2014 at 8:30 AM, hasufell wrote:
> No, that's not how opensource works. You don't work on things after
> "upstream" said "not interested".
That is hardly true though - which is why we have 47 different
implementations of everything to debate the merits of. :)
Besides, if this we
On Thu, Jun 19, 2014 at 1:03 PM, William Hubbs wrote:
> Hi all:
>
> I am strongly in favor of the eapi-based approach as well, for all of
> the reasons mentioned in the thread so far.
Good thing your proxy got it right then! :)
http://www.gentoo.org/proj/en/council/meeting-logs/20140617-summary
On Thu, Jun 19, 2014 at 6:05 PM, Steven J. Long
wrote:
> So which way do you actually prefer?
>
> You appear to be arguing for, and implementing, common code by EAPI,
> in the rest of your mail. Since that's always been the point of
> them, based on developer consensus about what is truly essentia
On Sun, Jun 22, 2014 at 9:11 AM, Kent Fredric wrote:
> On 23 June 2014 01:02, Duncan <1i5t5.dun...@cox.net> wrote:
>>
>>
>> The usual conditional for that is USE=custom-cflags or a similar variant
>> like custom-optimization. See the firefox ebuilds, which use both.
>>
>> $ equery -N u firefox |
On Wed, Jun 25, 2014 at 2:44 PM, Michał Górny wrote:
> Long story short, doing anything to Gentoo profiles is utter pain
> and comes with random breakage guarantee. Therefore, I'm asking -- nuke
> those damn profiles, and start over! The current situation is
> completely unmaintainable.
++
But,
On Sat, Jun 28, 2014 at 11:17 PM, Jeroen Roovers wrote:
> On Sat, 28 Jun 2014 19:58:22 -0700
> Greg Kroah-Hartman wrote:
>
>> Hi Markos,
>>
>> I was wondering why docker 1.0.0 wasn't seeming to get updated on my
>> boxes recently, despite me commiting the update to the cvs tree, and
>> Tianon not
On Sun, Jun 29, 2014 at 7:36 AM, hasufell wrote:
> If something is that fragile that you want to add it to the tree masked,
> maybe it isn't even ready for it yet.
> Fun-stuff, alpha-software and other broken things have a good place in
> overlays.
How is not putting it in the tree at all better
On Sun, Jun 29, 2014 at 8:12 AM, hasufell wrote:
> Also, those masks are rarely short-term in practice, because well, see
> this thread.
Is there any evidence to support this statement? You only notice
masks when they're a problem, and these kinds of masks tend to be a
problem only if they're lo
On Sun, Jun 29, 2014 at 8:36 AM, hasufell wrote:
> This is still too vague for me. If it's expected to be short-term, then
> it can as well just land in ~arch.
A package that hasn't been tested AT ALL doesn't belong in ~arch.
Suppose the maintainer is unable to test some aspect of the package,
or
On Mon, Jun 30, 2014 at 12:01 AM, William Hubbs wrote:
>
> On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote:
>> On Sun, Jun 29, 2014 at 8:36 AM, hasufell wrote:
>> > This is still too vague for me. If it's expected to be short-term, then
>> >
On Mon, Jun 30, 2014 at 7:29 AM, hasufell wrote:
> Huh? That's exactly the place. However, if you mean "AT ALL" in the
> sense that no one ever tried to compile it, then the guy who comitted
> should not have commit rights.
I mean in the sense that it has been compiled, but that it hasn't been
ex
On Mon, Jun 30, 2014 at 10:15 AM, Jeroen Roovers wrote:
> On Mon, 30 Jun 2014 09:25:27 -0400
> Rich Freeman wrote:
>
>> Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED
>> AT ALL. The maintainer knows that they compile, and that is
On Mon, Jun 30, 2014 at 12:13 PM, Jeroen Roovers wrote:
> On Mon, 30 Jun 2014 11:40:19 -0400
> Ian Stakenvicius wrote:
>
>> But... if I unmask it, -everyone- using ~arch will install it and
>> it'll break all the systems that it doesn't work on, which -could- be
>> quite a lot at this point. :D
On Mon, Jun 30, 2014 at 12:32 PM, William Hubbs wrote:
> On Mon, Jun 30, 2014 at 06:13:45PM +0200, Jeroen Roovers wrote:
>> On Mon, 30 Jun 2014 11:40:19 -0400
>> Ian Stakenvicius wrote:
>>
>> > But... if I unmask it, -everyone- using ~arch will install it and
>> > it'll break all the systems that
On Mon, Jun 30, 2014 at 3:11 PM, Tom Wijsman wrote:
>
> A test of a package to determine whether it appears to be working OK or
> whether it destructs your system isn't too much asked for; if it works
> it can then be ~arch tested, if it breaks you have a bug # for p.mask.
>
> If someone can't tes
On Tue, Jul 1, 2014 at 8:41 AM, Patrick Lauer wrote:
> On 06/30/14 22:15, Jeroen Roovers wrote:
>> On Mon, 30 Jun 2014 09:25:27 -0400
>> Rich Freeman wrote:
>>
>>> Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED
>>> AT ALL.
On Wed, Jun 25, 2014 at 4:01 PM, Andreas K. Huettel
wrote:
> Am Mittwoch 25 Juni 2014, 15:11:40 schrieb Rich Freeman:
>> On Wed, Jun 25, 2014 at 2:44 PM, Michał Górny wrote:
>> > Long story short, doing anything to Gentoo profiles is utter pain
>> > and comes wit
On Wed, Jul 2, 2014 at 1:56 PM, Tom Wijsman wrote:
> That is an edge case; it's somewhat hard to maintain a package if you
> can't test it, and there are occasions (eg. Amazon EC2 related
> packages) where this is indeed needed. I don't see a need to introduce
> that masked though; but again, it d
On Wed, Jul 2, 2014 at 1:54 PM, Michał Górny wrote:
> I don't feel like we ought to vote on something like this without
> understanding most of the current profiles. And I'm afraid there are
> only few people who have any idea about the current profile
> structure...
No argument there.
We may ve
1201 - 1300 of 2196 matches
Mail list logo
