On Tue, Jun 3, 2014 at 7:25 AM, Samuli Suominen ssuomi...@gentoo.org 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,
On Tue, Jun 3, 2014 at 8:24 AM, Samuli Suominen ssuomi...@gentoo.org wrote:
On 03/06/14 15:08, Tom Wijsman wrote:
On Tue, 3 Jun 2014 07:35:42 -0400
Rich Freeman ri...@gentoo.org wrote:
This probably could have used a news item, as the change impacts both
stable and ~arch users.
Are we going
On Tue, Jun 3, 2014 at 9:20 AM, Tom Wijsman tom...@gentoo.org wrote:
On Tue, 3 Jun 2014 09:04:23 -0400
Rich Freeman ri...@gentoo.org 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.23-r3
On Tue, Jun 3, 2014 at 9:46 AM, Samuli Suominen ssuomi...@gentoo.org 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
On Tue, Jun 3, 2014 at 10:05 AM, Tom Wijsman tom...@gentoo.org wrote:
On Tue, 3 Jun 2014 09:53:45 -0400
Rich Freeman ri...@gentoo.org 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 the mix
On Fri, May 30, 2014 at 12:50 PM, Tom Wijsman tom...@gentoo.org wrote:
On Fri, 30 May 2014 19:26:38 +0300
Samuli Suominen ssuomi...@gentoo.org 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
On Fri, May 30, 2014 at 1:02 PM, Ben Kohler bkoh...@gmail.com 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
On Wed, May 14, 2014 at 12:53 PM, Roy Bamford neddyseag...@gentoo.org 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.
On Tue, May 13, 2014 at 7:01 AM, Andrew Savchenko birc...@gmail.com 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
On Mon, May 12, 2014 at 12:07 PM, Rick Zero_Chaos Farina
zeroch...@gentoo.org 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
On Mon, May 12, 2014 at 1:22 PM, Rick Zero_Chaos Farina
zeroch...@gentoo.org 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
On Sat, May 10, 2014 at 9:00 AM, hasufell hasuf...@gentoo.org 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
On Sat, May 10, 2014 at 9:36 AM, hasufell hasuf...@gentoo.org 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
On Mon, Apr 28, 2014 at 5:46 PM, Andrew Savchenko birc...@gmail.com 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 things you probably don't
On Sat, Apr 26, 2014 at 10:37 PM, C. Bergström
cbergst...@pathscale.com 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
On Sun, Apr 27, 2014 at 7:41 AM, C. Bergström
cbergst...@pathscale.com 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't really need.
I
On Sun, Apr 27, 2014 at 6:56 PM, Joshua Kinard ku...@gentoo.org 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?
On Sat, Apr 26, 2014 at 6:23 AM, Michał Górny mgo...@gentoo.org 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
On Sat, Apr 26, 2014 at 11:00 AM, Martin Vaeth mar...@mvath.de wrote:
Rich Freeman ri...@gentoo.org 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 mar...@mvath.de 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
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 Tue, Apr 8, 2014 at 11:03 PM, Rick Zero_Chaos Farina
zeroch...@gentoo.org 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
On Fri, Apr 4, 2014 at 1:50 AM, Michał Górny mgo...@gentoo.org wrote:
It also tries to use '--reflink=auto' if available to make use of
btrfs CoW support.
++
Rich
On Wed, Apr 2, 2014 at 3:55 PM, Mike Gilbert flop...@gentoo.org 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
(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
zeroch...@gentoo.org 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
On Wed, Apr 2, 2014 at 4:23 PM, Alex Xu alex_y...@yahoo.ca 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 not? In general I
On Wed, Apr 2, 2014 at 4:27 PM, Rick Zero_Chaos Farina
zeroch...@gentoo.org 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.
On Tue, Apr 1, 2014 at 9:58 AM, Alexandre Rostovtsev
tetrom...@gentoo.org 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
On Tue, Apr 1, 2014 at 11:28 AM, Tom Wijsman tom...@gentoo.org 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
On Tue, Apr 1, 2014 at 8:13 PM, Patrick Lauer patr...@gentoo.org 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
On Sat, Mar 29, 2014 at 4:34 AM, Michał Górny mgo...@gentoo.org 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
On Fri, Mar 28, 2014 at 5:48 PM, Rick Zero_Chaos Farina
zeroch...@gentoo.org 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
On Fri, Mar 28, 2014 at 2:57 PM, Kent Fredric kentfred...@gmail.com wrote:
On 29 March 2014 06:12, Ciaran McCreesh ciaran.mccre...@googlemail.com
wrote:
These look a lot like they're just parameters to an eclass... An
alternative approach is to make this explicit, rather than having
On Sat, Mar 22, 2014 at 7:48 PM, hasufell hasuf...@gentoo.org 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
On Wed, Mar 12, 2014 at 12:52 PM, William Hubbs willi...@gentoo.org 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
On Wed, Mar 12, 2014 at 9:30 AM, Richard Yao r...@gentoo.org 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
On Wed, Mar 12, 2014 at 11:16 AM, Alexandre Rostovtsev
tetrom...@gentoo.org 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.
On Tue, Mar 11, 2014 at 1:54 PM, Michał Górny mgo...@gentoo.org wrote:
Dnia 2014-03-10, o godz. 18:30:29
William Hubbs willi...@gentoo.org 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.
On Mon, Mar 3, 2014 at 3:16 PM, Wyatt Epp wyatt@gmail.com 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
On Sat, Mar 1, 2014 at 1:31 PM, Alec Warner anta...@gentoo.org 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
On Sun, Mar 2, 2014 at 1:09 PM, Jeroen Roovers j...@gentoo.org 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
On Sun, Mar 2, 2014 at 2:44 PM, Mike Gilbert flop...@gentoo.org wrote:
On Sun, Mar 2, 2014 at 1:09 PM, Jeroen Roovers j...@gentoo.org 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
On Fri, Feb 28, 2014 at 9:44 AM, Samuli Suominen ssuomi...@gentoo.org 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,
On Fri, Feb 28, 2014 at 10:59 AM, hasufell hasuf...@gentoo.org 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
On Fri, Feb 28, 2014 at 8:09 PM, Steev Klimaszewski st...@gentoo.org 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
On Fri, Feb 28, 2014 at 8:57 PM, Steev Klimaszewski st...@gentoo.org 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
On Wed, Feb 26, 2014 at 5:49 AM, Thomas D. whi...@whissi.de 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
On Tue, Feb 25, 2014 at 6:39 AM, Thomas D. whi...@whissi.de 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
On Tue, Feb 25, 2014 at 8:26 AM, Thomas D. whi...@whissi.de wrote:
Rich Freeman wrote:
On Tue, Feb 25, 2014 at 6:39 AM, Thomas D. whi...@whissi.de 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
On Sun, Feb 16, 2014 at 3:41 AM, Pacho Ramos pa...@gentoo.org 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
On Sun, Feb 16, 2014 at 8:48 AM, Jeroen Roovers j...@gentoo.org 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
On Sun, Feb 16, 2014 at 9:31 AM, Jeroen Roovers j...@gentoo.org wrote:
On Sun, 16 Feb 2014 09:22:49 -0500
Rich Freeman ri...@gentoo.org 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 understaffed team
On Sat, Feb 15, 2014 at 8:30 AM, Jeroen Roovers j...@gentoo.org wrote:
On Sat, 15 Feb 2014 11:41:57 +0100
Tom Wijsman tom...@gentoo.org 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
On Thu, Feb 13, 2014 at 10:30 AM, Kent Fredric kentfred...@gmail.com wrote:
On 14 February 2014 04:28, Anthony G. Basile bluen...@gentoo.org 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
On Thu, Feb 13, 2014 at 11:07 AM, Brian Dolbec dol...@gentoo.org 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
On Tue, Feb 11, 2014 at 1:56 AM, Michael Palimaka kensing...@gentoo.org 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
On Tue, Feb 11, 2014 at 7:39 AM, Michael Palimaka kensing...@gentoo.org 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 configures sandbox
On Mon, Feb 10, 2014 at 7:43 AM, Patrick Lauer patr...@gentoo.org 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
On Mon, Feb 10, 2014 at 8:46 AM, Patrick Lauer patr...@gentoo.org 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
On Mon, Feb 10, 2014 at 9:23 AM, Tom Wijsman tom...@gentoo.org 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
On Mon, Feb 10, 2014 at 10:31 AM, Ulrich Mueller u...@gentoo.org 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
On Mon, Feb 10, 2014 at 12:20 PM, Tom Wijsman tom...@gentoo.org wrote:
On Mon, 10 Feb 2014 17:05:22 +0100
Ulrich Mueller u...@gentoo.org 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
On Mon, Feb 10, 2014 at 7:00 PM, yac y...@gentoo.org 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
On Sun, Feb 9, 2014 at 1:23 PM, Richard Yao r...@gentoo.org 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
On Tue, Feb 4, 2014 at 10:15 PM, Steev Klimaszewski st...@gentoo.org wrote:
You know what - this is pure and utter bullshit. Keeping it around for
slower arches does NOT block progress. I have intimate knowledge with
what ACTUALLY happens when people pull this bullshit - and that is a
On Wed, Feb 5, 2014 at 8:00 PM, Rick Zero_Chaos Farina
zeroch...@gentoo.org wrote:
On 02/05/2014 07:48 PM, Tom Wijsman wrote:
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies
That policy doesn't permit removal of keywords/ebuilds without following
gentoo standard policy,
On Mon, Feb 3, 2014 at 11:42 AM, Rick Zero_Chaos Farina
zeroch...@gentoo.org wrote:
I'm more worried about how long it takes me to learn
how to news than the actual second the snapshot is taken.
Just read the GLEP and post some text to the list. Bikeshedding will
occur. If you need help
On Sat, Feb 1, 2014 at 12:35 PM, Rick Zero_Chaos Farina
zeroch...@gentoo.org wrote:
I see exactly zero downside to doing this, so if whoever is going to
actually do the editing of the profiles would like to work with me (to
give me warning), I think I can manage the rest.
I see no harm in
On Fri, Jan 31, 2014 at 1:14 AM, Alec Warner anta...@gentoo.org wrote:
sounds to me like QA is giving itself carte blanche to make any fix
they want as per we think a developer's actions are causing problems
hmm?
So in short, while one could read that passage as you did, I don't think
that
On Tue, Jan 28, 2014 at 12:23 PM, Jeroen Roovers j...@gentoo.org wrote:
On Tue, 28 Jan 2014 08:33:05 -0800
Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:
Why not allow maintainers to drop redundant stable and even ~arch
keywords from their packages?
This is standard practice already.
If
On Mon, Jan 27, 2014 at 2:41 AM, Steev Klimaszewski st...@gentoo.org wrote:
It's not necessarily the STABLEREQs stopping, some of the issues are (at
least on some arches!) that some of the unstable software doesn't quite
work properly anymore, and we are failing at communicating. And in
those
On Sat, Jan 25, 2014 at 11:53 PM, Peter Stuge pe...@stuge.se wrote:
Rich Freeman wrote:
It seems like the simplest solution in these cases is to just have
them focus on @system packages for the stable tree, and let users
deal with more breakage outside of that set
Why not make stable
On Sun, Jan 26, 2014 at 1:56 PM, Peter Stuge pe...@stuge.se wrote:
I don't think that's completely optional though, it sounds like a
one-way function. If have ever stabilized a package once then must
ensure a stable package forever.
I think arbitrarily removing stable versions should also be
On Fri, Jan 24, 2014 at 11:02 PM, Duncan 1i5t5.dun...@cox.net wrote:
I've often wondered just how much faster gentoo could move, and how much
better we could keep up with upstream, if we weren't so focused on 30+day
outdated stab?l3 bumping all the time. All that effort... from my
viewpoint
On Wed, Jan 22, 2014 at 7:34 AM, Patrick Lauer patr...@gentoo.org wrote:
On 01/22/2014 03:00 PM, Alan McKinnon wrote:
I don't want to appear rude, but when reading this entire mail all I see
is someone who has probably never had to do it for real.
People are not machines. Volunteers really do
On Tue, Jan 21, 2014 at 9:56 AM, Tom Wijsman tom...@gentoo.org wrote:
If a developer does an unannounced mass action that breaks the tree
severely or is heavily prohibited by policy, is unreachable while he
continues to commit this; then it would be handy to temporarily be
able to withdraw the
On Tue, Jan 21, 2014 at 12:26 PM, William Hubbs willi...@gentoo.org wrote:
On Tue, Jan 21, 2014 at 10:47:50AM -0500, Rich Freeman wrote:
If Comrel really objects to this I'm not entirely opposed to letting
QA have the reins (certainly we can't just let policy go unenforced
entirely). However
On Sun, Jan 19, 2014 at 9:54 PM, Tom Wijsman tom...@gentoo.org wrote:
#gentoo-qa | @hwoarang: pretty sure diego had the powerzz to suspend
people
Whether this has actually happened is something that is questionable;
Not that this necessarily needs to make it into the GLEP, and I'm
On Mon, Jan 20, 2014 at 7:22 PM, Patrick Lauer patr...@gentoo.org wrote:
Yey, we're allowed to sometimes do revert games, if we're asking nicely
... and the only way to stop the revert game is for QA to stand down.
We're allowed to send strongly-worded emails, but getting things baked
into
On Fri, Jan 17, 2014 at 2:58 AM, Matt Turner matts...@gentoo.org wrote:
On Thu, Jan 16, 2014 at 11:02 PM, gro...@gentoo.org wrote:
Maybe, a good solution is to introduce a special arch, noarch, for such
packages (similar to what's done in the rpm world). Then, if a package is
~noarch, it is
On Thu, Jan 16, 2014 at 10:54 AM, Peter Stuge pe...@stuge.se wrote:
Sergey Popov wrote:
As i said earlier, problem begins when we NEED to stabilize
something to prevent breakages and arch teams are slow.
Isn't that simply a matter of assigning and respecting priority on
bugs properly?
Are
On Thu, Jan 16, 2014 at 1:11 PM, Peter Stuge pe...@stuge.se wrote:
I certainly don't think the work needs to go away if the work is
considered to be important. It's fine to have open bugs for years
in the absence of a good solution.
I get what you're saying, though there is still a cost to
On Wed, Jan 15, 2014 at 4:54 AM, Michał Górny mgo...@gentoo.org wrote:
2) has to add package.accept_keywords entry for the package. Which
means turning a pure stable system into an unsupported mixed-keyword
system.
As opposed to an unsupported pure stable system or an unsupported pure
On Fri, Jan 10, 2014 at 7:41 AM, Igor lanthrus...@gmail.com wrote:
What I offer is to make the response and self-assessment on Gentoo
changes automated and fast. Then it will be getting better by itself.
The rate of experience Dev is attaining will jump several times up and
the level drudgery
On Fri, Jan 10, 2014 at 8:10 AM, Igor lanthrus...@gmail.com wrote:
Hello Patrick,
Friday, January 10, 2014, 4:39:59 PM, you wrote:
Bad code is bad. You can write bad code in any language.
BTW Perl is faster than Python too.
Try writing quick sort in Perl, Ptyhon and G++
then dump the
On Thu, Jan 9, 2014 at 5:29 PM, Rick Zero_Chaos Farina
zeroch...@gentoo.org wrote:
I never felt manipulating cflags with use flags was a great idea, but in
this case is does feel extra pointless.
Tend to agree, though one place I could see it being hypothetically
useful is if we need to set a
On Thu, Jan 2, 2014 at 10:25 AM, Michael Orlitzky m...@gentoo.org wrote:
If you think the transition period for that is long, how long do you
think it will take for people to become aware of the magic USE flag and
begin populating the other-LICENSE-contained-within-LICENSE variable?
How long
On Thu, Jan 2, 2014 at 1:17 PM, Ulrich Mueller u...@gentoo.org wrote:
This is not primarily about distfiles mirroring, about about giving
users a choice what distfiles they will accept on their systems (for
whatever reasons, e.g. legal or philosophical). Besides, not all users
are under the
On Thu, Jan 2, 2014 at 4:11 PM, Ryan Hill dirtye...@gentoo.org wrote:
That's only possible if we enumerate every license in every distfile we
distribute, which I don't think is a good idea. Or at least not on the
basis of a theoretic user that might not actually exist.
Why would we need to do
On Wed, Jan 1, 2014 at 8:51 PM, Michael Orlitzky m...@gentoo.org wrote:
In essence, I don't want to *use* code that isn't @FREE. This includes
the installed files, of course, but also the build system (that I use
temporarily). We could generalize this to any file accessed during
emerge to be
On Wed, Jan 1, 2014 at 9:19 PM, Michael Orlitzky m...@gentoo.org wrote:
Is there a real example where the license matters for something
redistributed to yourself?
Well, yourself is a loose term. If I were to redistribute MS
Windows across 300 PCs for my employer I suspect some people would
On Wed, Jan 1, 2014 at 9:50 PM, Michael Orlitzky m...@gentoo.org wrote:
But Gentoo can't distribute MS Windows to you in the first place. Is
there a package that Gentoo can distribute to you, but you can't
redistribute within your organization?
Well, ACCEPT_LICENSE is about more than just
On Wed, Dec 11, 2013 at 7:41 PM, Patrick Lauer patr...@gentoo.org wrote:
Well, given that systemd unit files don't express dependencies ...
Sure they do. They declare wants, after, wantedby, etc. Looking in
my /usr/lib/systemd/system it seems like all the units I looked at
declared their
On Wed, Dec 11, 2013 at 3:47 PM, Chris Reffett creff...@gentoo.org wrote:
The idea of running a sed on inittab in an ebuild, no matter what the
context, terrifies me. Perhaps we can ease this in slowly by renaming rc -
openrc and symlinking rc - openrc and making a release with that change
On Tue, Dec 10, 2013 at 5:31 AM, Steev Klimaszewski st...@gentoo.org wrote:
On Mon, 2013-12-09 at 20:33 -0500, Rich Freeman wrote:
You're thinking with your x86/amd64 hat on here.
Actually, I probably just underquoted. I am well-aware that there are
issues with ARM, hence my previous
On Mon, Dec 9, 2013 at 9:50 AM, Rick Zero_Chaos Farina
zeroch...@gentoo.org wrote:
I can honestly say most of the time when setup my arm systems I'm
unpacking the arm stage3 on an amd64 and then booting the arm device
with the base stage3 and fixing things from there. I suppose it is
possible
On Mon, Dec 9, 2013 at 5:55 AM, Tom Wijsman tom...@gentoo.org wrote:
For the dependency syntax, having :* as a default breaks things or
causes a lot of work. If explicit slots (or :0) were the default, it
works and you spare out dealing with lots of reverse dependencies when
you introduce a
On Mon, Dec 9, 2013 at 2:56 PM, Rick Zero_Chaos Farina
zeroch...@gentoo.org wrote:
I really don't like the idea of having no networking in the stage3 by
default, however, I'm becoming more open minded on what qualifies as
networking. What I'm wrestling with is this, what if I want to slap a
On Sun, Dec 8, 2013 at 12:46 PM, Tom Wijsman tom...@gentoo.org wrote:
Given that the retroactive change I suggest causes a lot of complexity;
changing it on the next EAPI indeed sounds like one way to go, the
alternative is to make it a suggestive guideline or policy and cover
it as a QA
On Sun, Dec 8, 2013 at 2:14 PM, Ulrich Mueller u...@gentoo.org wrote:
PMS just provides a mechanism, but doesn't prefer one SLOT value over
another. Such a change would introduce policy into PMS which is not
the right way to go.
Sure it does - it defaults to :* when :* was never specified. I
1201 - 1300 of 2142 matches
Mail list logo
