On 29/08/2016 21:08, Neil Bothwick wrote:
On Mon, 29 Aug 2016 17:04:08 +0100, Peter Humphrey wrote:
I remember someone (Dale?) some time ago being dismayed at the large
number of packages that would be installed by emerge @system.
Now I see what he meant: on this box 401 of the 1103 installed
On Mon, 29 Aug 2016 17:04:08 +0100, Peter Humphrey wrote:
> I remember someone (Dale?) some time ago being dismayed at the large
> number of packages that would be installed by emerge @system.
>
> Now I see what he meant: on this box 401 of the 1103 installed
> packages. I'd like to construct a s
Hello list,
I remember someone (Dale?) some time ago being dismayed at the large number
of packages that would be installed by emerge @system.
Now I see what he meant: on this box 401 of the 1103 installed packages. I'd
like to construct a set that would create a reliable basis for building the
On 06/22/2016 09:39 AM, Dan Douglas wrote:
> On Tue, Jun 21, 2016 at 10:04 AM, Neil Bothwick wrote:
>> On Tue, 21 Jun 2016 09:39:42 -0500, Dan Douglas wrote:
>>
>>> Is something misconfigured on my end or is this just a long-standing
>>> bug? I at least need a way to either recover the list of pac
On Mon, Jun 27, 2016 at 06:46:51AM -0400, Harry Putnam wrote
> Anyone know what needs to be done here?
>
> Are there perl pkgs that need emerging first?
Have you tried revdep-rebuild?
--
Walter Dnes
I don't run "desktop environments"; I run useful applications
Setup:
Running gentoo thru vbox as guest on a Solaris host (openindiana)
While executing `emerge -vuD world', when the `screen' package rolled
around I get this `tail' of the compile process:
CPP="i686-pc-linux-gnu-gcc -E -DMAXWIN=100 -DNONETHACK
-DETCSCREENRC='"/etc/screenrc"'
-DSCREENENCO
On Wed, 22 Jun 2016 14:57:50 -0500, Dan Douglas wrote:
> >> --keep-going is in EMERGE_DEFAULT_OPTS so the problem is only when
> >> that fails for whatever reason, --resume (with or without
> >> --skip-first) always fails too.
> > On 06/22/2016 12:31 PM, Neil Bothwick wrote:
> > That makes sense
On 06/22/2016 12:31 PM, Neil Bothwick wrote:
> On Wed, 22 Jun 2016 08:39:59 -0500, Dan Douglas wrote:
>> --keep-going is in EMERGE_DEFAULT_OPTS so the problem is only when
>> that fails for whatever reason, --resume (with or without
>> --skip-first) always fails too.
> On 06/22/2016 12:31 PM, Neil
On Wed, 22 Jun 2016 08:39:59 -0500, Dan Douglas wrote:
> >> Is something misconfigured on my end or is this just a long-standing
> >> bug? I at least need a way to either recover the list of packages
> >> manually or force portage to continue on because any failure prevents
> >> updating a system.
On Tue, Jun 21, 2016 at 10:04 AM, Neil Bothwick wrote:
> On Tue, 21 Jun 2016 09:39:42 -0500, Dan Douglas wrote:
>
>> Is something misconfigured on my end or is this just a long-standing
>> bug? I at least need a way to either recover the list of packages
>> manually or force portage to continue on
On Tue, 21 Jun 2016 09:39:42 -0500, Dan Douglas wrote:
> Is something misconfigured on my end or is this just a long-standing
> bug? I at least need a way to either recover the list of packages
> manually or force portage to continue on because any failure prevents
> updating a system.
Have you t
Hi. I don't believe I've ever seen portage's --resume --skipfirst
option work correctly without saying "invalid resume list". I know
this is incorrect because I've manually checked that all deps are
satisfied and it even occurs if a custom package I'm working on with
nothing depending upon it fails
Ok ,
/var/lib/portage/config keeps the hashes of the original modified files.
Thanks
Marco
On Wed, 15 Jun 2016 17:14:01 +0100
Neil Bothwick wrote:
> On Wed, 15 Jun 2016 18:07:21 +0200, ma...@nucleus.it wrote:
>
> > then i change parameters in /etc/dhcp/dhcpd.conf
> > and /etc/conf.d/dhcpd
>
On Wed, 15 Jun 2016 18:07:21 +0200, ma...@nucleus.it wrote:
> then i change parameters in /etc/dhcp/dhcpd.conf and /etc/conf.d/dhcpd
>
> then i upgrade the net-misc/dhcp (net-misc/dhcp ~amd64)
>
> emerge -v1 net-misc/dhcp
> [ebuild U ~] net-misc/dhcp-4.3.4::gentoo [4.3.3_p1::gentoo]
>
> bu
Hi all,
i need explanation about how emerge does updates of config files.
example:
emerge -v1 =net-misc/dhcp-4.3.3_p1
then i change parameters in /etc/dhcp/dhcpd.conf and /etc/conf.d/dhcpd
then i upgrade the net-misc/dhcp (net-misc/dhcp ~amd64)
emerge -v1 net-misc/dhcp
[ebuild U ~] net-mis
From the does-this-happen-to-anyone-else-or-is-it-just-me department.
I'm finding that if I include "--rebuild-if-new-rev y", I get a slew of new
packages built, *even if I just built them*. That seems wrong. I've tried
removing it, and the problem goes away. The presence or absence of "--rebuil
On Sat, 16 Apr 2016 10:26:34 -0400, Alan Grimes wrote:
> but on my desktop, all of these problems would go away by the end of the
> update list and 95% of the time, revdep-rebuild wouldn't have anything
> to do.
That would mean that one in twenty updates would break your system,
requiring revdep-
On Sat, 16 Apr 2016 12:41:37 -0400, Alan Grimes wrote:
> I've got more years on gentoo that most of you. Indeed, my home
> directory probably has detritus in it dating back to 2004.
Does that mean you have 12 years experience, or 3 months experience 48
times over?
> I only joined this list a few
On Sat, 16 Apr 2016 12:47:14 -0400, Alan Grimes wrote:
> It is fundamentally broken. =|
Of course it is, that's why almost all of us[1] are experiencing the
same problems as you. If it was just you, then is would be reasonable to
assume the problem was with you, which is clearly impossible to ev
On 16/04/2016 18:47, Alan Grimes wrote:
> Volker Armin Hemmann wrote:
>> you do stupid things and then complain that the system does not work.
>>
>> Why don't you stop doing stupid things?
>>
>> That said, C 1.0 blocks A 1.0 but updating to C 2.0 would solve it, does
>> happen, even if you do not a
On Saturday, April 16, 2016 12:47:14 PM Alan Grimes wrote:
> Volker Armin Hemmann wrote:
> > you do stupid things and then complain that the system does not work.
> >
> > Why don't you stop doing stupid things?
> >
> > That said, C 1.0 blocks A 1.0 but updating to C 2.0 would solve it, does
> > h
On Saturday, April 16, 2016 12:41:37 PM Alan Grimes wrote:
> Dale wrote:
> > Basically, take the advice from some people who have been doing this
> > for years or continue along the path that you have proven doesn't work.
>
> I've got more years on gentoo that most of you. Indeed, my home
> direct
Alan Grimes wrote:
> Volker Armin Hemmann wrote:
>> you do stupid things and then complain that the system does not work.
>>
>> Why don't you stop doing stupid things?
>>
>> That said, C 1.0 blocks A 1.0 but updating to C 2.0 would solve it, does
>> happen, even if you do not act retarded, BUT thos
Alan Grimes wrote:
> Dale wrote:
>> Basically, take the advice from some people who have been doing this
>> for years or continue along the path that you have proven doesn't work.
> I've got more years on gentoo that most of you. Indeed, my home
> directory probably has detritus in it dating back
Volker Armin Hemmann wrote:
> you do stupid things and then complain that the system does not work.
>
> Why don't you stop doing stupid things?
>
> That said, C 1.0 blocks A 1.0 but updating to C 2.0 would solve it, does
> happen, even if you do not act retarded, BUT those instances are usually
> e
Dale wrote:
> Basically, take the advice from some people who have been doing this
> for years or continue along the path that you have proven doesn't work.
I've got more years on gentoo that most of you. Indeed, my home
directory probably has detritus in it dating back to 2004.
I only joined th
Am 16.04.2016 um 16:26 schrieb Alan Grimes:
> Mick wrote:
>> Hello Mr Grimes,
>>
>> I see you still have trouble dealing with your rage issues.
>>
>> I recommend you seek professional help about that.
>> Nah! Let the man vent. Gentoo is a particularly effective (meta)distro for
>> this purpose t
Alan Grimes wrote:
> Mick wrote:
>> Hello Mr Grimes,
>>
>> I see you still have trouble dealing with your rage issues.
>>
>> I recommend you seek professional help about that.
>> Nah! Let the man vent. Gentoo is a particularly effective (meta)distro for
>> this purpose too. It will invariably d
Mick wrote:
> Hello Mr Grimes,
>
> I see you still have trouble dealing with your rage issues.
>
> I recommend you seek professional help about that.
> Nah! Let the man vent. Gentoo is a particularly effective (meta)distro for
> this purpose too. It will invariably do *exactly* what you instruc
On Sat, 16 Apr 2016 11:05:40 +0100, Mick wrote:
> > Hello Mr Grimes,
> >
> > I see you still have trouble dealing with your rage issues.
> >
> > I recommend you seek professional help about that.
>
> Nah! Let the man vent. Gentoo is a particularly effective
> (meta)distro for this purpose t
On Saturday 16 Apr 2016 11:10:45 Alan McKinnon wrote:
> On 16/04/2016 05:36, Alan Grimes wrote:
> > Emerge won't update a single goddammned package on my system.
> >
> >
> > My number theory code finished a segment of work, (after a month), and
> > it's time to reboot the system to propagate upda
On 16/04/2016 05:36, Alan Grimes wrote:
> Emerge won't update a single goddammned package on my system.
>
>
> My number theory code finished a segment of work, (after a month), and
> it's time to reboot the system to propagate updates to nvidia drivers
> and such, uptime = 81 days.
>
> I thought
On Fri, 15 Apr 2016 23:36:17 -0400, Alan Grimes wrote:
> Emerge won't update a single goddammned package on my system.
>
> My number theory code finished a segment of work, (after a month), and
> it's time to reboot the system to propagate updates to nvidia drivers
> and such, uptime = 81 days.
On April 16, 2016 5:36:17 AM GMT+02:00, Alan Grimes
wrote:
>Emerge won't update a single goddammned package on my system.
>
>
>My number theory code finished a segment of work, (after a month), and
>it's time to reboot the system to propagate updates to nvidia drivers
>and such, uptime = 81 days.
Emerge won't update a single goddammned package on my system.
My number theory code finished a segment of work, (after a month), and
it's time to reboot the system to propagate updates to nvidia drivers
and such, uptime = 81 days.
I thought the hell emerge put me through last time would cover me
11.04.2016 17:09, Alan McKinnon wrote:
On 11/04/2016 15:15, Yuri K. Shatroff wrote:
Hi gentoo users,
Got a strange problem. While emerging kde-plasma/kscreenlocker (as part
of upgrading to the brand new plasma desktop), the build fails with the
following error:
* Applying kscreenlocker-5.4.90-
On 11/04/2016 15:15, Yuri K. Shatroff wrote:
> Hi gentoo users,
>
> Got a strange problem. While emerging kde-plasma/kscreenlocker (as part
> of upgrading to the brand new plasma desktop), the build fails with the
> following error:
>
> * Applying kscreenlocker-5.4.90-no-SUID-no-GUID.patch ...
>
Hi gentoo users,
Got a strange problem. While emerging kde-plasma/kscreenlocker (as part
of upgrading to the brand new plasma desktop), the build fails with the
following error:
* Applying kscreenlocker-5.4.90-no-SUID-no-GUID.patch ...
/var/tmp/portage/kde-plasma/kscreenlocker-5.6.2/temp/envi
On Mon, 14 Mar 2016 13:53:44 -0400, Alan Grimes wrote:
> No, skipfirst only works when it actually tries to compile something.
> Here it is failing in some strange pre-compile stage. I don't know why
> it has to be so anal about this, The normal solution would be to log the
> error, drop the two p
On Mon, 14 Mar 2016 11:12:20 -0400, Alan Grimes wrote:
> * If you need support, post the output of `emerge --info
> '=app-emulation/wine-1.9.5::gentoo'`,
> * the complete build log and the output of `emerge -pqv
> '=app-emulation/wine-1.9.5::gentoo'`.
I couldn't see this anywhere your post.
I encountered something similar to this myself a bit ago.
Apparently, GCC 5.3 has a bug in how it works with the stack alignment
in some cases, which causes compiling wine to fail halfway through [1].
I believe that that is the check for that bug.
If you have GCC 5.3, you may want to consider movi
On Monday, March 14, 2016 11:12:20 AM Alan Grimes wrote:
> In order to press ahead, I had to drop ktorrent and digikam, both
> packages that I consider high priority. =\
>
>
> I thought that would finally get me going...
>
>
> Oh what a fool I was...
>
> #
>
> >>> Running
No, skipfirst only works when it actually tries to compile something.
Here it is failing in some strange pre-compile stage. I don't know why
it has to be so anal about this, The normal solution would be to log the
error, drop the two packages that were affected, and then compile the
rest...
but no
man emerge
search for "skipfirst" and "keep-going"
It also seems you did not post the actual error or log. At least the
snipped you posted does not make any sense.
2016-03-14 16:12 GMT+01:00 Alan Grimes :
> In order to press ahead, I had to drop ktorrent and digikam, both
> packages that I consid
On Monday 14 March 2016 11:12:20 Alan Grimes wrote:
[...]
>So this one stupid leaf package is killing my ENTIRE update???
[...]
Does passing "--keep-going" to emerge help? I have it in my
EMERGE_DEFAULT_OPTS.
HTH
--
Marc Joliet
--
"People who think they know everything really annoy those of us w
In order to press ahead, I had to drop ktorrent and digikam, both
packages that I consider high priority. =\
I thought that would finally get me going...
Oh what a fool I was...
#
>>> Running pre-merge checks for kde-plasma/plasma-workspace-5.5.5-r2
>>> Running pre-merge c
On Sat, Jan 23, 2016 at 09:52:29PM +0100, k...@aspodata.se wrote:
> Karl Hammar:
> > Alec Ten Harmsel:
> > > On Tue, Jan 19, 2016 at 10:05:49PM +0100, k...@aspodata.se wrote:
> > > > Alec: Ten Harmsel:
> > > > > On Tue, Jan 19, 2016 at 08:01:19PM +0100, k...@aspodata.se wrote:
> > > > > > Makefile
Karl Hammar:
> Alec Ten Harmsel:
> > On Tue, Jan 19, 2016 at 10:05:49PM +0100, k...@aspodata.se wrote:
> > > Alec: Ten Harmsel:
> > > > On Tue, Jan 19, 2016 at 08:01:19PM +0100, k...@aspodata.se wrote:
> > > > > Makefile:1318: recipe for target 'xinput.c' failed
> > > > > when emerging x11-libs/li
On Tuesday 19 January 2016 22:40:31 k...@aspodata.se wrote:
> Alec Ten Harmsel:
> > In general (someone else, correct me if I'm wrong) this list would much
> > rather have you attach a compressed build.log when you mail in the
> > problem. That way, there is no chance of permissions problems, and
>
Alec Ten Harmsel:
> On Tue, Jan 19, 2016 at 10:05:49PM +0100, k...@aspodata.se wrote:
> > Alec: Ten Harmsel:
> > > On Tue, Jan 19, 2016 at 08:01:19PM +0100, k...@aspodata.se wrote:
> > > > I'm getting
> > > >
> > > > Makefile:1318: recipe for target 'xinput.c' failed
> > > >
> > > > when emergin
On Tue, Jan 19, 2016 at 10:05:49PM +0100, k...@aspodata.se wrote:
> Alec: Ten Harmsel:
> > On Tue, Jan 19, 2016 at 08:01:19PM +0100, k...@aspodata.se wrote:
> > > I'm getting
> > >
> > > Makefile:1318: recipe for target 'xinput.c' failed
> > >
> > > when emerging x11-libs/libxcb-1.11.1, logs etc
Alec: Ten Harmsel:
> On Tue, Jan 19, 2016 at 08:01:19PM +0100, k...@aspodata.se wrote:
> > I'm getting
> >
> > Makefile:1318: recipe for target 'xinput.c' failed
> >
> > when emerging x11-libs/libxcb-1.11.1, logs etc.:
> >
> > http://turkos.aspodata.se/tmp/gentoo/
>
> I can't read build.log -
On Tue, Jan 19, 2016 at 08:01:19PM +0100, k...@aspodata.se wrote:
> I'm getting
>
> Makefile:1318: recipe for target 'xinput.c' failed
>
> when emerging x11-libs/libxcb-1.11.1, logs etc.:
>
> http://turkos.aspodata.se/tmp/gentoo/
I can't read build.log - 403 permission denied.
> I get simila
I'm getting
Makefile:1318: recipe for target 'xinput.c' failed
when emerging x11-libs/libxcb-1.11.1, logs etc.:
http://turkos.aspodata.se/tmp/gentoo/
I get similar errors with:
emerge =libxcb-1.10
emerge =libxcb-1.9.1
Have anyone seen anything similar, maybe there something missing here ?
On 31/12/2015 04:50, Philip Webb wrote:
151230 Harry Putnam wrote:
emerge output:
The following pkgs are causing rebuilds:
[list of pkgs]
I suspect this ground has been covered in depth
but finding a good discussion of what it means is a different story.
So, is this bad news? Or something
On 31 December 2015 02:50:32 GMT+00:00, Philip Webb
wrote:
> 151230 Harry Putnam wrote:
> > emerge output:
> > The following pkgs are causing rebuilds:
> > [list of pkgs]
> > I suspect this ground has been covered in depth
> > but finding a good discussion of what it means is a different stor
151230 Harry Putnam wrote:
> emerge output:
> The following pkgs are causing rebuilds:
> [list of pkgs]
> I suspect this ground has been covered in depth
> but finding a good discussion of what it means is a different story.
> So, is this bad news? Or something that needs my attention...?
It
On 12/30/2015 06:54 PM, Harry Putnam wrote:
>
> emerge output:
> The following pkgs are causing rebuilds:
> [list of pkgs]
>
> I suspect this ground has been covered in depth but finding a good
> discussion of what it means is a different story. So, is this bad news?
> Or something that needs
emerge output:
The following pkgs are causing rebuilds:
[list of pkgs]
I suspect this ground has been covered in depth but finding a good
discussion of what it means is a different story. So, is this bad news?
Or something that needs my attention...?
Maybe someone can point me at some docume
On 11/11/2015 21:35, Walter Dnes wrote:
> Ongoing installation. I looked at 2 instances of
> "emerge -pv x11-base/xorg-server" and the order was somewhat different.
> Here are a couple of outputs, just a few seconds apart. Is this a bug
> or a feature? See attachments.
>
Emerge order is not
Ongoing installation. I looked at 2 instances of
"emerge -pv x11-base/xorg-server" and the order was somewhat different.
Here are a couple of outputs, just a few seconds apart. Is this a bug
or a feature? See attachments.
--
Walter Dnes
I don't run "desktop environments"; I run useful appli
On Tue, 13 Oct 2015 17:53:54 Marat BN wrote:
> Hello there,
>
> I'm having a curious problem trying to update my system.
>
> I issue the command:
>
> emerge --update @world -pv
>
>
> Portage comes back with the following:
>
> !!! Multiple package instances within a single package slot have be
Hello there,
I'm having a curious problem trying to update my system.
I issue the command:
emerge --update @world -pv
Portage comes back with the following:
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict
On Sun, 30 August 2015, at 7:37 am, Harry Putnam wrote:
> ...
> I've been building cpan packages and have them installed at the locations
> mentioned above. Then, to get perl to include them in `@INC', I've utilized
> the PERL5LIB variable in one of my login scripts, just as it appears in the
>
On Saturday 29 Aug 2015 20:36:04 neu pat wrote:
> I emerge python3.4 set as active:
> eselect python list
> Available Python interpreters:
> [1] python2.7
> [2] python3.3
> [3] python3.4 *
> but it still complain about Multiple package instances
>
> [ebuild U ] sys-apps/portage-2.
Setup: running gentoo inside vbox on Solaris (x86)
Very new install
Running `emerge -v dev-vcs/git' when it comes to installing several dev-perl
pkgs begining with dev-perl/Digest-HMAC-1.30.0-r1::gentooi, it fails with a
brief explanation:
>>> Configuring source in
/var/tmp/portage/dev-perl/Di
Here is my emerge-info
python target is 2.7.9-r1, 3.3.5-r1, 3.4.1
emerge --info
Portage 2.2.14 (python 2.7.9-final-0, default/linux/x86/13.0/desktop,
gcc-4.8.4, glibc-2.19-r1, 3.10.17-gentoo i686)
=
System uname:
Linux-3.10.17-gentoo
On Sat, Aug 29, 2015 at 02:02:29PM -0600, neu pat wrote:
> I emerge python3.4 set as active:
>
> eselect python list
> Available Python interpreters:
> [1] python2.7
> [2] python3.3
> [3] python3.4 *
What is the value of PYTHON_TARGETS? Can you post the output of `emerge
--info'?
> b
On Saturday, August 29, 2015 2:02:29 PM neu pat wrote:
> I emerge python3.4 set as active:
>
> eselect python list
> Available Python interpreters:
> [1] python2.7
> [2] python3.3
> [3] python3.4 *
>
> but it still complain
>
>
> [ebuild U ] sys-apps/portage-2.2.20.1 [2.2.14]
>
I emerge python3.4 set as active:
eselect python list
Available Python interpreters:
[1] python2.7
[2] python3.3
[3] python3.4 *
but it still complain
[ebuild U ] sys-apps/portage-2.2.20.1 [2.2.14]
PYTHON_TARGETS="python3_4* -python3_3*"
!!! Multiple package instances within a
I emerge python3.4 set as active:
eselect python list
Available Python interpreters:
[1] python2.7
[2] python3.3
[3] python3.4 *
but it still complain about Multiple package instances
[ebuild U ] sys-apps/portage-2.2.20.1 [2.2.14]
PYTHON_TARGETS="python3_4* -python3_3*"
!!! Multi
On 24/08/2015 15:17, Alan Mackenzie wrote:
> Hello, Harry,
>
> Long time, no see!
>
> On Sun, Aug 23, 2015 at 10:19:42PM -0400, Harry Putnam wrote:
>> My gentoo OS is running on Openindiana (solaris) inside oracle's vbox.
>
>> It's been left setting for at least 4-5 months maybe a couple more.
>
On Mon, Aug 24, 2015 at 08:41:48AM -0400, Rich Freeman wrote:
> And a note to everybody else on the list: take it easy on the poor
> guy. People used to other distros are used to doing things like
> blowing away their installs every other year with a fresh install.
> Release-based distros get peo
Hello, Harry,
Long time, no see!
On Sun, Aug 23, 2015 at 10:19:42PM -0400, Harry Putnam wrote:
> My gentoo OS is running on Openindiana (solaris) inside oracle's vbox.
> It's been left setting for at least 4-5 months maybe a couple more.
> After eix-sync, attempting an `emerge vuND world' comes
On Sun, Aug 23, 2015 at 10:19 PM, Harry Putnam wrote:
> Can anyone advise me which iso to use? And which profile to set for
> general use in a vbox, hopefully to allow a `no sweat' emerge to a
> full OS.
As others have pointed out you probably just need to update your gcc
and all will be well, o
On Sun, Aug 23, 2015 at 10:19:42PM -0400, Harry Putnam wrote:
> My gentoo OS is running on Openindiana (solaris) inside oracle's vbox.
>
> It's been left setting for at least 4-5 months maybe a couple more.
>
> After eix-sync, attempting an `emerge vuND world' comes up with so
> many blocks, use
2015-08-23 20:19 GMT-06:00 Harry Putnam :
> My gentoo OS is running on Openindiana (solaris) inside oracle's vbox.
>
Why so much overhead for compiling, and not doing it bare-metal?
> It's been left setting for at least 4-5 months maybe a couple more.
>
> After eix-sync, attempting an `emerge vuN
My gentoo OS is running on Openindiana (solaris) inside oracle's vbox.
It's been left setting for at least 4-5 months maybe a couple more.
After eix-sync, attempting an `emerge vuND world' comes up with so
many blocks, use flag changes and a variety of other bad news in
such proliferation... I'm
Hi List,
I have just updated MythTV, but when I do `emerge -s mythtv` I get
the previous version is the installed version
# emerge -s mythtv
[ Results for search key : mythtv ]
Searching...
* media-tv/mythtv
Latest version available: 0.27.5_p20150627
Latest version insta
On 29/06/2015 22:00, Grant Edwards wrote:
> After futzing around for a while installing and re-installing
> different versions of libftdi trying to get python support installed,
> I finally noticed that building libftdi python support requires swig.
> I didn't have swig installed and the ebuild app
After futzing around for a while installing and re-installing
different versions of libftdi trying to get python support installed,
I finally noticed that building libftdi python support requires swig.
I didn't have swig installed and the ebuild apparently doesn't have it
as a dependency.
Is the r
On Wednesday, May 06, 2015 10:08:11 AM Dale wrote:
>
> Maybe that will fix it and you can stay stable. Maybe. ;-)
>
Thank you. I installed that and saw the news too.
It is working again, but it seems I have a lot to rebuild!
Behrouz Khosravi wrote:
> On Wednesday, May 06, 2015 04:37:55 AM Dale wrote:
>
>>> This is my output:
>> The P means it is in the portage tree. The I means that it is
>> installed. Based on your info, you are using a older version of
>> bash-completion than I am.
>>
>> Dale
>>
>> :-) :-)
> Thank
On Wednesday, May 06, 2015 04:37:55 AM Dale wrote:
> > This is my output:
> The P means it is in the portage tree. The I means that it is
> installed. Based on your info, you are using a older version of
> bash-completion than I am.
>
> Dale
>
> :-) :-)
Thanks, Are you on ~AMD64 ?
My version
Behrouz Khosravi wrote:
> On Wednesday, May 06, 2015 04:21:45 AM Dale wrote:
>
>> root@fireball / # equery list -p bash-completion
>> * Searching for bash-completion ...
>> [-P-] [ ] app-shells/bash-completion-1.3-r2:0
>> [-P-] [ ] app-shells/bash-completion-2.1:0
>> [-P-] [ ] app-shells/bash-c
On Wednesday, May 06, 2015 04:21:45 AM Dale wrote:
> root@fireball / # equery list -p bash-completion
> * Searching for bash-completion ...
> [-P-] [ ] app-shells/bash-completion-1.3-r2:0
> [-P-] [ ] app-shells/bash-completion-2.1:0
> [-P-] [ ] app-shells/bash-completion-2.1-r2:0
> [-P-] [ ]
Behrouz Khosravi wrote:
> hello everyone. I have a problem with bash-completion with emerge
> command for packages. when I press tab-tab it only shows "world" and
> "system" but I was working OK before, I mean It was able to show the list of
> packages. Is anything changed?
>
>
I get this here
hello everyone. I have a problem with bash-completion with emerge
command for packages. when I press tab-tab it only shows "world" and
"system" but I was working OK before, I mean It was able to show the list of
packages. Is anything changed?
On Tue, Mar 24, 2015 at 05:10:26PM +, Neil Bothwick wrote
> On Mon, 23 Mar 2015 22:52:39 -0400, Walter Dnes wrote:
>
> > What does it mean? It shows up on the screen at the start of
> > "emerge", but it's not in the log files. Is it possibly a message
> > from the server that emerge is gra
On Mon, 23 Mar 2015 22:52:39 -0400, Walter Dnes wrote:
> What does it mean? It shows up on the screen at the start of
> "emerge", but it's not in the log files. Is it possibly a message from
> the server that emerge is grabbing the tarball from?
It appears to be a BSD function used by some FT
What does it mean? It shows up on the screen at the start of
"emerge", but it's not in the log files. Is it possibly a message from
the server that emerge is grabbing the tarball from?
--
Walter Dnes
I don't run "desktop environments"; I run useful applications
On Sun, Jan 25, 2015 at 9:57 AM, wrote:
> Marc Joliet wrote:
>>
>> The man page to cfg-update says that it needs diff3 for the automatic
>> three-way
>> merge (STAGE2), which is part of diffutils. Interestingly, cfg-update does
>> not
>> depend on diffutils, so maybe you (Covici) just need to
Marc Joliet wrote:
> Am Fri, 23 Jan 2015 21:30:07 -0500
> schrieb Rich Freeman :
>
> > On Fri, Jan 23, 2015 at 7:12 PM, wrote:
> > >> On Fri, Jan 23, 2015 at 5:45 PM, shawn wilson wrote:
> > >> > Is there a way to have default config lines that emerge updates won't
> > >> > touch?
> > >> >
>
Am Fri, 23 Jan 2015 21:30:07 -0500
schrieb Rich Freeman :
> On Fri, Jan 23, 2015 at 7:12 PM, wrote:
> >> On Fri, Jan 23, 2015 at 5:45 PM, shawn wilson wrote:
> >> > Is there a way to have default config lines that emerge updates won't
> >> > touch?
> >> >
> >>
> >> I'd be interested in hearing
On Fri, 23 Jan 2015 18:30:52 -0500
Rich Freeman wrote:
> On Fri, Jan 23, 2015 at 5:45 PM, shawn wilson
> wrote:
> > Is there a way to have default config lines that emerge updates
> > won't touch?
> >
>
> I'd be interested in hearing about alternatives, but I switched to
> cfg-update from dispa
On 2015-01-23 23:45, shawn wilson wrote:
Is there a way to have default config lines that emerge updates won't
touch?
For instance, my /etc/ssh/sshd_config differs from the default in some
places. I know this and upstream shows me the same diffs in that file
over and over again. But maybe upstr
Rich Freeman wrote:
> On Fri, Jan 23, 2015 at 7:12 PM, wrote:
> >> On Fri, Jan 23, 2015 at 5:45 PM, shawn wilson wrote:
> >> > Is there a way to have default config lines that emerge updates won't
> >> > touch?
> >> >
> >>
> >> I'd be interested in hearing about alternatives, but I switched t
On Fri, Jan 23, 2015 at 7:12 PM, wrote:
>> On Fri, Jan 23, 2015 at 5:45 PM, shawn wilson wrote:
>> > Is there a way to have default config lines that emerge updates won't
>> > touch?
>> >
>>
>> I'd be interested in hearing about alternatives, but I switched to
>> cfg-update from dispatch-conf a
On Fri, Jan 23, 2015 at 7:12 PM, wrote:
> Rich Freeman wrote:
>
>> On Fri, Jan 23, 2015 at 5:45 PM, shawn wilson wrote:
>> > Is there a way to have default config lines that emerge updates won't
>> > touch?
>> >
>>
>> I'd be interested in hearing about alternatives, but I switched to
>> cfg-up
Rich Freeman wrote:
> On Fri, Jan 23, 2015 at 5:45 PM, shawn wilson wrote:
> > Is there a way to have default config lines that emerge updates won't touch?
> >
>
> I'd be interested in hearing about alternatives, but I switched to
> cfg-update from dispatch-conf and such because it does automat
401 - 500 of 3114 matches
Mail list logo
