On Sat, 2024-07-20 at 20:25 +0300, Alexander Tsoy wrote:
>
> No, their names are predefined. For example with the current in-tree
> nginx:
>
> $ sudo ls -1 /var/lib/nginx/tmp/
> client
> fastcgi
> proxy
> scgi
> uwsgi
Ok, thanks. I see them now in the eclass (for the list: they're being
grepped
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/16/2012 09:22 AM, Pacho Ramos wrote:
> net-misc/openntpd
This one's easy, I could proxy-maintain it. These two are also
maintainer-needed:
* app-doc/djbdns-man
I'm maintaining djbdns, so I suppose I should have this one too. On
the o
Inspired by the number of packages being unmaintained -- why not use
some of that bug bounty money to fix up the recruitment documentation
and maybe give the webpage a makeover? Marketing is a big part of the
problem.
1. Even MediaWiki (wiki.gentoo.org) looks better than www.gentoo.org.
Tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/16/2012 12:02 PM, Fabian Groffen wrote:
> On 16-12-2012 11:57:35 -0500, Michael Orlitzky wrote:
>> 3. Get off CVS for Christ's sake. Nobody wants to work with that.
>> I don't know how this fits into my bullet li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/16/2012 12:23 PM, Fabian Groffen wrote:
> On 16-12-2012 12:20:10 -0500, Michael Orlitzky wrote:
>> Many new developers who want to contribute to to some project
>> will learn git, because a large number of important projects use
On 12/16/2012 01:27 PM, Duncan wrote:
> Michael Orlitzky posted on Sun, 16 Dec 2012 12:20:10 -0500 as excerpted:
>
>> On 12/16/2012 12:02 PM, Fabian Groffen wrote:
>>> On 16-12-2012 11:57:35 -0500, Michael Orlitzky wrote:
>>>> 3. Get off CVS for Christ'
On 12/16/12 16:32, Michał Górny wrote:
>
> Get off powerpoint for your god of choice's sake. Nobody wants to work
> with that (well, everybody I meet outside actually wants but
> whatever) :P. Sorry, couldn't resist.
>
I was hoping nobody would call my bluff. This is the only avenue
available to
On 12/16/12 13:53, Andreas K. Huettel wrote:
>> 1. Even MediaWiki (wiki.gentoo.org) looks better than www.gentoo.org.
>> That's impressive-bad.
>>
>> People still think of Gentoo as a ricer distro that's broken all
>> the time, when in reality, it's one of the most stable. No one
>
On 12/16/12 14:04, Markos Chandras wrote:
> On 16 December 2012 16:57, Michael Orlitzky wrote:
>> Inspired by the number of packages being unmaintained -- why not use
>> some of that bug bounty money to fix up the recruitment documentation
>
> Recruitment documentatiob
On 12/17/2012 10:32 AM, Anthony G. Basile wrote:
> Hi everyone,
>
> Give the talk on the list about attracting devs, I've should probably
> mention that I'm teaching a College Course on Gentoo Development next
> semester. I know two students will most likely go through the
> recruitment proces
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/01/2013 02:14 PM, Vadim A. Misbakh-Soloviov wrote:
> Hi there! Long time ago I discovered that many language-specific
> packages (libraries, webapps) written on languages like PHP, Ruby,
> Lua and so on has (often) almost hardcoded dependence to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/01/2013 04:53 PM, Diego Elio Pettenò wrote:
> On 01/01/2013 22:12, Michael Orlitzky wrote:
>>
>> In lieu of that, what we do is create ebuilds like
>> www-apps/redmine-dependencies. I manually parse the Gemfile for
>&
On 01/05/2013 12:47 AM, Donnie Berkholz wrote:
>
> Some early work on it using Bootstrap:
>
> http://a3li.li/~alex/g.o/
>
I really like this. The (admittedly kind-of ugly) logo and the flying
saucer thing are incorporated tastefully and it makes a big difference.
The zebra tables, and especial
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/13/2013 12:58 PM, Michał Górny wrote:
>
> If something is a six-liner made by Gentoo and for Gentoo, noone
> cares enough to create a homepage for it.
>
> http://gentoo.org is the most useless 'homepage' value you can use.
> It doesn't mean any
On 01/16/2013 11:36 AM, Michael Weber wrote:
>
>>> emerge --upgrade
> with a predefined EMERGE_UPGRADE_OPTS in make.conf (where
> EMERGE_DEFAULT_OPTS lives).
+1 so I can stop adding --oneshot onto every upgrade.
On 01/16/2013 11:47 AM, Michael Orlitzky wrote:
> On 01/16/2013 11:36 AM, Michael Weber wrote:
>>
>>>> emerge --upgrade
>> with a predefined EMERGE_UPGRADE_OPTS in make.conf (where
>> EMERGE_DEFAULT_OPTS lives).
>
> +1 so I can stop adding --oneshot on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/16/2013 12:24 PM, Ian Stakenvicius wrote:
> On 16/01/13 11:47 AM, Michael Orlitzky wrote:
>> On 01/16/2013 11:36 AM, Michael Weber wrote:
>>>
>>>>> emerge --upgrade
>>> with a predefin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/16/2013 12:24 PM, Ian Stakenvicius wrote:
>
> --upgrade wouldn't (couldn't, imo) replace --update.
>
Yes, sorry for the confusion. I use more than one package manager, and
when doing an "update" or "upgrade" I'm basically flipping a coin.
I j
On 01/17/2013 09:52 AM, Zac Medico wrote:
>>
>> I strongly believe that it shouldn't; nevertheless, it does.
>
> You can avoid this by adding --select=n to EMERGE_DEFAULT_OPTS. Then, if
> you want to add something to world, use --select (or -w in latest
> portage which isn't marked stable yet).
T
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/17/2013 12:11 PM, Ian Stakenvicius wrote:
>
> ... so what's the problem here, exactly?
>
I don't want @world to get screwed up, either by having unnecessary
packages, or by missing ones we need.
> (a) 'emerge -u [pkg]' adds extra bits to @wo
On 01/24/13 05:02, Michael Haubenwallner wrote:
>
> I've recently upgraded some server from kernel-2.6.28 to kernel-3.5.7 and
> encountered that the root-device was renamed from /dev/cciss/c0d0p1 to
> /dev/sda1 due to some kernel driver change (took me a while to find out).
> I'm not using genkern
On 01/24/13 13:25, Rich Freeman wrote:
> On Thu, Jan 24, 2013 at 1:18 PM, Ian Stakenvicius wrote:
>> a fatal die in pkg_pretend could be circumvented by an environment
>> variable such as ${PN}_I_KNOW_WHAT_IM_DOING being set. Just a thought.
>
> If we're going to do this I'd definitely have the
On 01/24/13 13:58, Ian Stakenvicius wrote:
>
>
> How about, you know what you're doing and are going to build a new
> kernel as soon as the emerge finishes (since the emerge is also
> bringing in a new gentoo-sources)??
>
If you're going to upgrade both anyway, you should be upgrading the
kerne
On 01/24/13 15:26, viv...@gmail.com wrote:
>> If you're going to upgrade both anyway, you should be upgrading the
>> kernel first. That way if you lose power or the system crashes, the box
>> can reboot.
>>
> which can be the exact opposite order if instead you have to _disable_ a
> feature in the
On 01/24/13 15:39, Michael Orlitzky wrote:
> On 01/24/13 15:26, viv...@gmail.com wrote:
>>> If you're going to upgrade both anyway, you should be upgrading the
>>> kernel first. That way if you lose power or the system crashes, the box
>>> can reboot.
>>&
On 01/24/13 19:29, viv...@gmail.com wrote:
> actually it wasn't an issue that could made a system un-bootable but was
> like this:
>
> * udev-129 could live with CONFIG_SYSFS_DEPRECATED=y
> * udev-130 require CONFIG_SYSFS_DEPRECATED not set
>
> The example was given just to underline the fact tha
On 01/24/2013 08:39 PM, Duncan wrote:
>
> Now I've chosen to set that using package.env so it applies only to glibc,
> but I imagine many users have it set in their make.conf, because a lot of
> packages use it, and they were forced to set it for one or another at
> some point.
Using package.e
On 01/24/2013 10:12 PM, Rich Freeman wrote:
>
> Otherwise we're just finding creative ways to drive away users. Sure,
> we can call them stupid on their way out the door, but while I can't
> speak for anybody else, I'm mainly here because I'd like to do some
> good, and I wouldn't mind it if I fo
On 03/10/2013 02:11 PM, hasufell wrote:
> On 03/10/2013 07:04 PM, Jeroen Roovers wrote:
>> On Sun, 3 Mar 2013 12:44:18 +0100
>> Tomáš Chvátal wrote:
>>
>>> If I remember correctly the damn rule is to put it for 30 days into
>>> testing, and as you said there was no previous version on arm so users
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/23/2013 02:50 PM, Pacho Ramos wrote:
> El sáb, 23-03-2013 a las 14:40 -0400, Rick "Zero_Chaos" Farina
> escribió:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 03/23/2013 02:06 PM, Pacho Ramos wrote:
>>> Today I tried to boot latest
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/23/2013 04:02 AM, Daniel Campbell wrote:
>
>
> I can't speak for others who wish to rid their systems of systemd,
> but personally I look for any excessive use of space on my HDD,
> despite it being rather large. Since you brought it up, which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/12/2013 01:13 PM, Ciaran McCreesh wrote:
> On Wed, 12 Jun 2013 19:05:29 +0200 hasufell
> wrote:
>>> Isn't it more an indication that Gentoo needs better package
>>> management support for overlays?
>
>> No.
>
> You make a persuasive argument.
On 06/12/2013 06:31 PM, Greg Turner wrote:
> On Wed, Jun 12, 2013 at 10:23 AM, Michael Orlitzky
> wrote:
>> On 06/12/2013 01:13 PM, Ciaran McCreesh wrote:
>>> On Wed, 12 Jun 2013 19:05:29 +0200 hasufell
>>> wrote:
>>>>> Isn't it m
On 06/13/2013 12:56 AM, Alexander V Vershilov wrote:
>> The main reason it isn't is because nobody wants to use CVS. For
>> good
examples, see sunrise or
>> gentoo-haskell.
>
> As a part of gentoo-haskell team, I'd like to say that CVS issue is
> not strongest one, there are much more meaningful
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/04/2013 04:37 PM, William Hubbs wrote:
>
> I thought about gentoo-networking, but that sucks in a way too
> because it implies that everyone on gentoo should be using it.
>
> ...
>
>> How about gen-net? It's nice, short and the name is more
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/04/2013 06:20 PM, William Hubbs wrote:
> On Sun, Aug 04, 2013 at 10:15:35PM +, Duncan wrote:
>> Michael Orlitzky posted on Sun, 04 Aug 2013 18:01:40 -0400 as
>> excerpted:
>>
>>> Since it was pulled out of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/04/2013 06:36 PM, Michał Górny wrote:
>
>> Since it was pulled out of openrc, the name "netrc" also suggests
>> itself.
>
> 'net run control'?
>
Sounds about right. We can say it's "net run configuration" if that's
better politically.
-BE
On 08/05/2013 06:09 PM, Robin H. Johnson wrote:
> - netrc (conflicts)
Would naming it net-rc alleviate the perceived conflict?
On 08/05/2013 09:45 PM, Michael Orlitzky wrote:
> On 08/05/2013 06:09 PM, Robin H. Johnson wrote:
>> - netrc (conflicts)
>
> Would naming it net-rc alleviate the perceived conflict?
>
Or, duh, networkrc.
On 08/18/2013 12:39 PM, Ulrich Mueller wrote:
>
> The current epatch() would remain available in eutils.eclass for cases
> where its more advanced modes of operation are needed.
> ...
> 2. Should the function do automatic -p* detection, or should it
>default to -p1? Both would be overridable
On 08/20/2013 02:19 PM, William Hubbs wrote:
> My question is, how can we improve our stabilization procedures/policies
> so we can convince people not to run production servers on ~arch and
> keep the stable tree more up to date?
Just delete /etc/conf.d/net with an ~arch update every once in a wh
On 08/21/2013 12:35 AM, Ben de Groot wrote:
> On 21 August 2013 04:12, Michael Orlitzky wrote:
>> [snip]
>> Ok, this one is ridiculous. The stable version of Rails is 2.3.18, and
>> 3.0 was released almost exactly three years ago. Every time rails-3.x
>> gets bumped, I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/21/2013 11:42 AM, Mike Gilbert wrote:
> GRUB2 will be stabilized soon (bug 455544). Here's a draft of a
> news item to hopefully prevent any confusion. Please review.
The "FAQ / Known Problems / Gotchas" section of the guide is still
empty. Mayb
On 11/04/2013 04:46 PM, Duncan wrote:
>
> I imagine were emerge being written today, -1 /would/ be the default, and
> there'd be an option like --select to add to the @world file if
> necessary. That's actually the way I setup my scripts, with -1 the
> default, and an extra "2" suffix script v
On 11/05/2013 09:49 AM, mingdao wrote:
>
> Flameeyes wrote the following blog post concerning this issue:
>
> http://blog.flameeyes.eu/2012/10/may-i-have-a-network-connection-please
>
> and the link gives me a (Error code: sec_error_ocsp_unknown_cert).
>
You should disable OCSP anyway. In Fire
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/06/2013 02:11 PM, Thomas D. wrote:
>
> This is going OT but I cannot leave this statement uncommented,
> because from my knowledge this is wrong/you are hiding important
> information everyone should know about:
I figure everyone here is smart
On 12/10/2013 09:18 PM, Paul B. Henson wrote:
>
> I'd say go one step further and get rid of vixie-cron completely, is
> there anything it does that cronie can't do as well or better?
Is cronie a drop-in replacement, or do I have to do some thinking when
replacing vixie-cron?
On 12/11/2013 03:03 PM, Mike Gilbert wrote:
>>
>> Is cronie a drop-in replacement, or do I have to do some thinking when
>> replacing vixie-cron?
>>
>
> It should be a drop-in. The only change to make would be to remove
> vixie-cron and add cronie to the default runlevel.
>
I noticed two small d
On 12/16/2013 05:44 AM, Duncan wrote:
> Matt Turner posted on Sun, 15 Dec 2013 15:34:13 -0800 as excerpted:
>
>> sse3: Use the SSE3 instruction set (pni in cpuinfo)
>> ssse3: Use the SSSE3 instruction set
>
> I'd suggest a parenthetical on ssse3 as well, something like:
>
> ssse3: Use the SSSE3
On 12/16/2013 01:21 PM, Alan McKinnon wrote:
>>
>> "Enable use of the SSSE3 instruction set (NOT sse3). This is needed by
>> projects which contain assembly code or which use certain compiler
>> intrinsics. It is not a replacement for CFLAGS and friends."
>
> The second and third sentences add not
On 12/23/2013 10:54 PM, Vadim A. Misbakh-Soloviov wrote:
>> rc-update del vixie-cron default
>> /etc/init.d/vixie-cron stop
>> emerge -C vixie-cron
>> emerge cronie
>> rc-update add cronie default
>> /etc/init.d/cronie start
>
> Why /etc/init.d instead of rc-service? :)
>
Uhh
On 01/01/2014 05:28 PM, Ulrich Mueller wrote:
> Hi,
> According to GLEP 23 [1], the LICENSE variable regulates the software
> that is installed on a system. There is however some ambiguity in
> this: should it cover the actual files installed on the system, or
> everything that is included in the p
On 01/01/2014 09:10 PM, Rich Freeman wrote:
> On Wed, Jan 1, 2014 at 8:51 PM, Michael Orlitzky 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
>> temporaril
On 01/01/2014 09:13 PM, Rick "Zero_Chaos" Farina wrote:
>
>> What use case is there for having the LICENSE apply to anything else?
>
> Some of us do redistribute the entire source package, so it does matter.
> If it doesn't matter to you as a user then you can always leave it
> unset and you rem
On 01/01/2014 09:38 PM, Rich Freeman wrote:
> On Wed, Jan 1, 2014 at 9:19 PM, Michael Orlitzky 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 red
On 01/02/2014 07:54 AM, Ulrich Mueller wrote:
>>>>>> On Wed, 01 Jan 2014, Michael Orlitzky wrote:
>
>> As I said in another reply, more license metadata is good and we
>> should make it available. But a USE flag that changes the meaning of
>> an impo
On 01/12/2014 02:53 AM, Ryan Hill wrote:
> fortran:
> Do we want to keep enabling fortran by default? The majority of users will
> never get the urge to install a fortran package, and the fortran eclass
> handles
> those that do. I think it should be treated as all the other optional
> languages
On 01/14/2014 04:37 PM, William Hubbs wrote:
>
> 2. I would like to see the policy below applied to all arch's [2].
[ ] Yup
[X] Nope
On 01/14/2014 05:33 PM, William Hubbs wrote:
> On Tue, Jan 14, 2014 at 04:57:30PM -0500, Michael Orlitzky wrote:
>> On 01/14/2014 04:37 PM, William Hubbs wrote:
>>>
>>> 2. I would like to see the policy below applied to all arch's [2].
>>
>> [ ] Yup
>
On 01/14/2014 06:11 PM, William Hubbs wrote:
>>
>> For users, both options are worse than the status quo.
>
> The first option would start reverting things back to ~ and users would
> have to unmask them.
>
> The second option would introduce new things to stable which may not be
> stable due to
On 01/14/2014 07:13 PM, Tom Wijsman wrote:
>>
>> For users, both options are worse than the status quo.
>
> When you do nothing then things are bound to get worse, under the
> assumption that manpower doesn't change as well as the assumption that
> the queue fills faster than stabilization bugs ge
On 01/14/2014 08:08 PM, Tom Wijsman wrote:
>
> This is under the assumption that the user knows of the state of the
> stabilization worsening; if the user is unaware of that change, the
> "could have done anyway" might be less common and first something bad
> would need to happen before they reali
On 01/14/2014 08:23 PM, Tom Wijsman wrote:
> On Tue, 14 Jan 2014 20:11:24 -0500
> Michael Orlitzky wrote:
>
>> On 01/14/2014 08:08 PM, Tom Wijsman wrote:
>>>
>>> This is under the assumption that the user knows of the state of the
>>> stabilization
On 01/14/2014 09:09 PM, William Hubbs wrote:
>
> After the package has been sitting in ~arch for 90 days with an open
> stable request with no blockers that the arch team has not taken any
> action on. We are not talking about randomly yanking package versions,
> just doing something when arch tea
On 01/14/2014 09:34 PM, Tom Wijsman wrote:
>
>> Strictly from a user's perspective. I don't, unless I do, in which
>> case I know that I do, and I could just keyword the thing if I wanted
>> to.
>
> This is the exact same argument as in your other mail, which is your
> point of view; this is unde
On 01/25/2014 09:24 AM, Markos Chandras wrote:
> (picking a random email from the thread)
>
> ping again. 3 months later, the list of bugs remain the same. Shall we
> consider dropping it to maintainer-needed?
>
These are easy fixes, some for nagios-plugins:
* https://bugs.gentoo.org/show_bug
On 03/31/2014 02:14 PM, Samuli Suominen wrote:
>
> On 31/03/14 21:15, Kfir Lavi wrote:
>> Hi all,
>> I'm trying to create an ebuild to install matlab MCR on gentoo.
>> The installer InstallShileld try to create directory
>> /root/InstallShield ;-)
>> mkdir is run by java binary that try this. So I
On 09/16/2014 10:03 AM, Rich Freeman wrote:
>
> The gpg signature is on the entire contents of the "commit." However,
> the contents of the commit do not include the files that are being
> committed - it includes hashes of the parent commit, the commit
> message, other headers, and the hash of th
I've got two obsolete packages masked currently: app-text/unix2dos and
app-doc/djbdns-man. Both of them block other stable packages,
app-text/dos2unix and net-dns/djbdns respectively.
Fortunately, both of them have had version/revision bumps since the
blocker so we can remove the blocker from the
On 10/13/2014 02:41 PM, Mike Gilbert wrote:
>
> I agree with Diego and Ralph: Go with d.
>
> repoman will generate a warning (not an error) about a dependency
> which does not exist, but this is safe to ignore.
>
Given that (d) didn't require me to do anything else, I just went ahead
and remove
On 10/18/2014 01:00 PM, Diego Elio Pettenò wrote:
> All the stack is at https://github.com/gentoo/tboxanalysis
>
> The opening of the bug report is done by a piece of meatware called
> "me". The UI displays a link that I can click to pre-fill the bug
> report. The rest of the information is filled
On 10/18/2014 01:34 PM, Pacho Ramos wrote:
>
> Supposedly we always must attach files to bug reports to ensure they are
> kept forever with that bug reports instead of relying on external
> resources that could disappear in the future (or far future). If I don't
> misremember, flameeyes was paying
When I was taking my ebuild quizzes, I asked for someone to clarify the
implicit system dependency that we have enshrined in the devmanual:
https://bugs.gentoo.org/show_bug.cgi?id=485356
There is... some agreement, but also special cases and special-special
cases that are folklore-only at this
On 11/13/2014 05:30 AM, Michael Palimaka wrote:
>
> Suggested policy to get the ball rolling:
>
> In general, a package must explicitly depend upon what it directly uses.
> However, to avoid ebuild complexity and developer burden there are some
> exceptions. Packages that appear in the base syste
On 11/13/2014 10:17 AM, Ian Stakenvicius wrote:
>> Isn't it possible to disable C++ in GCC with USE="-cxx"?
>
> It is.. but unfortunately there's no way in DEPEND to ensure it's
> satisfied, as you can have a gcc installed with that flag enabled but
> have a second one (that's actually selected
On 11/13/2014 01:13 PM, Mike Gilbert wrote:
> On Thu, Nov 13, 2014 at 10:27 AM, Michael Palimaka
> wrote:
>> On 14/11/14 01:05, Michael Orlitzky wrote:
>>> Isn't it possible to disable C++ in GCC with USE="-cxx"?
>>
>> It is, but I think if that&#x
On 11/21/2014 05:06 PM, Piotr Szymaniak wrote:
> On Wed, Nov 19, 2014 at 08:07:36PM +0800, Patrick Lauer wrote:
>> http://packages.gentooexperimental.org/repoman-checks/
>>
>> updated per cron job, split by category. Much easier to handle :)
>>
>> Feel free to work on fixing things - there's enough
We've got a bug in Nagios's `ping` command format detection:
https://bugs.gentoo.org/show_bug.cgi?id=468296
It's easy to reproduce by taking down your "lo" interface, or by
filtering all icmp packets in iptables.
Fortunately, you can override the auto-detection by passing it a magic
string, an
On 11/26/2014 01:43 PM, Sergey Popov wrote:
>
> Standart - cross-compilation and prefix. If you do not care about the
> latter(not having keywords for your package) - it's ok.
> Cross-compilation, or compilation into another root is trickier - you
> should support it.
>
With ping and ping6 comin
On 11/26/2014 03:57 PM, Diego Elio Pettenò wrote:
>>
>> And with the command set to ${ROOT}bin/ping, building for a Gentoo
>> system under another root should work, right?
>
> No, $ROOT should not seep into the compiled code.
>
Ah, I think I see my mistake: when running *within* a chroot, you do
On 07/19/2018 05:51 PM, Ben Kohler wrote:
> Hello,
>
> I'd like to propose adding USE=udev to our linux profiles (in
> profiles/default/linux/make.defaults probably). This flag is already
> enabled on desktop profiles but it also affects quite a few packages
> used on non-desktop linux systems
On 07/19/2018 11:49 PM, Aaron Bauman wrote:
> You are denying the majority default here. Granted, we don't have
> statistics... Cuz Gentoo.
No I'm not. I'm saying add them per-package, because it's a better
design. We have package.use in profiles now, not just IUSE defaults.
Global defaults have
On 07/20/2018 01:06 AM, Mart Raudsepp wrote:
>>
>> * They can't be undone. It's next to impossible for me to undo
>> USE=udev when set in a profile that is inherited by all others.
>
> You set USE=-udev in your make.conf.
That doesn't work, for reasons already stated.
If I set USE="-udev"
On 07/20/2018 02:12 AM, Mart Raudsepp wrote:
>
> Ok, I can see that point of view for make.conf.
> I can't agree with changes in other profiles though, as other profile
> will fall under the same category in USE_ORDER (in fact, it's the same
> thing, as the end USE from "defaults" comes from your
On 07/20/2018 07:55 AM, Rich Freeman wrote:
>
> While I agree that setting USE=-udev isn't the same as leaving it to
> package defaults, you further claim that setting this globally causes
> severe breakage in some cases. Can you provide an example of this?
>
https://bugs.gentoo.org/640226
Or
On 07/20/2018 03:37 AM, Matt Turner wrote:
>>
>> If I want to undo your new flag, I have to set USE="-udev" globally, and
>> that clobbers any important per-package defaults that maintainers have set.
>
> I understand the concern at least in theory. But can you please give
> me a concrete example
On 07/21/2018 03:01 AM, Dennis Schridde wrote:
>
> What about adding a third operator, e.g. `^`, that resets a use flag to the
> unset state?
>
The behavior of USE (in profiles) is documented in the PMS, so I don't
think we can add a new operator so easily. But, this is what the PMS has
to say
On 07/21/2018 12:59 PM, Matt Turner wrote:
>
> If it adds no additional dependencies, why do you care?
>
It adds complexity and attack surface for something I apparently don't
need. You'll have to take it on faith that turning off shit I don't
understand has made my job/life a lot easier over th
On 07/24/2018 11:39 AM, Mike Gilbert wrote:
>
> You can run any system without udev, but you need to be very careful
> about what Linux features you utilize and how you have the system
> configured.
>
> Most Linux servers out in the wild are running udev; your
> configuration is an exception to t
On 07/24/2018 12:14 PM, Rich Freeman wrote:
>
> I don't believe anybody suggested making Gentoo harder to customize.
> This is just about setting reasonable defaults.
For the (N+1)th time: enabling this flag by default does make Gentoo
harder to customize, because you can't turn it off. And so ye
On 07/24/2018 12:24 PM, Mike Gilbert wrote:
>
> For example, dhcpcd integrates with udevd via libudev to ensure that
> udev has finished renaming your network interfaces before dhcpcd
> attempts to configure them. I believe lvm2 uses libudev to prevent
> various races in block device setup and met
On 07/24/2018 12:37 PM, Rich Freeman wrote:
>> harder to customize, because you can't turn it off.
>
> This was already addressed in a previous comment - PMS can be modified
> to nullify flags
Saying that hypothetically we could modify the PMS and wait for a new
EAPI and wait for all package manag
On 08/06/2018 04:23 PM, Toralf Förster wrote:
> On 08/06/2018 10:09 PM, Alec Warner wrote:
>>
>> They do not even do so by convention; there are numerous EAPIs in the
>> wild that are non-numeric.
>
> Then this line
>
>if [[ ${EAPI} == [0123456] ]]; then
>
> is a short-term solution, rig
On 08/08/2018 05:34 PM, Michał Górny wrote:
>
> - if path_exists -o "${EROOT%/}"/etc/openvpn/*/local.conf ; then
> + if path_exists "${EROOT%/}"/etc/openvpn/*/local.conf ; then
> ewarn "WARNING: The openvpn init script has changed"
> ewarn ""
> fi
Not th
On 08/12/2018 03:22 AM, Michał Górny wrote:
> Hi, everyone.
>
> Here's a long batch of patches adding @SUPPORTED_EAPIS to eclasses.
We should add this to https://devmanual.gentoo.org/eclass-writing, too.
I see you already got app-portage/eclass-manpages.
On 09/09/2018 07:32 AM, Andrew Savchenko wrote:
> Hi!
>
> Our current -Werror policy demands unconditional removal:
> https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed
>
> I think this is wrong, see bugs 665464, 665538 for a recent
> discussi
On 09/14/2018 01:52 PM, Rich Freeman wrote:
>
> Wouldn't the flip side of this be demonstrating that this has actually
> caused issues? If following upstream discovers no bugs and also
> causes no issues, why not leave it to maintainer discretion?
>
We know it causes issues, there are hundreds
On 09/14/2018 03:58 PM, Richard Yao wrote:
>>
>> No one has answered the question: what do you do when a stable package
>> breaks because of a new warning?
>>
>> ...>
> Wouldn’t this be largely covered as part of GCC stabilization? We could
> reserve the right to kill -Werror in a package where it
On 09/16/2018 02:59 AM, Michał Górny wrote:
> Hi, everyone.
>
> Just FYI: the Trustees have approved GLEP 76 aka our new copyright
> policy [1]. While the exact implementation details are to be determined
> yet, please note that *Signed-off-by* line will mean you are certifying
> our GCO [2].
>
uster/open-mx
but their maintainers haven't responsed to the bug, email, or IRC. So
for lack of a better option, I'd like to offer this up as-is again.
v2 is simply a rebase onto ::gentoo master, and adds my signoff.
Michael Orlitzky (1):
profiles: unset USE=modules by default.
401 - 500 of 914 matches
Mail list logo
