Re: [gentoo-user] How to get memtest onto a USB drive

[Dale]

Peter Humphrey wrote:
> On Friday 28 Apr 2017 17:11:47 Dale wrote:
>
>> This is different but I found this that says it works with your setup.
>> I don't have one like yours, just googled for a possible solution.
>>
>> http://www.memtest86.com/technical.htm#usage
>>
>> If you think that will work, may want to try that memtest.  If not,
>> please ignore me.  ;-)
> Thanks Dale, but I think the problem may be worse than just RAM. The 
> attached screen shot shows what I saw when I did boot an image.  :-(
>


Yep.  I think you have a problem that goes beyond what memtest will
reveal.  It looks bad.  Bummer.  May need to gut that rig and put in
some new gear. 

Dale

:-)  :-) 

Re: [gentoo-user] How to get memtest onto a USB drive

[Peter Humphrey]

On Saturday 29 Apr 2017 02:50:53 Dale wrote:
> Peter Humphrey wrote:
> > On Friday 28 Apr 2017 17:11:47 Dale wrote:
> >> This is different but I found this that says it works with your setup.
> >> I don't have one like yours, just googled for a possible solution.
> >> 
> >> http://www.memtest86.com/technical.htm#usage
> >> 
> >> If you think that will work, may want to try that memtest.  If not,
> >> please ignore me.  ;-)
> > 
> > Thanks Dale, but I think the problem may be worse than just RAM. The
> > attached screen shot shows what I saw when I did boot an image.  :-(
> 
> Yep.  I think you have a problem that goes beyond what memtest will
> reveal.  It looks bad.  Bummer.  May need to gut that rig and put in
> some new gear.

No, it's only a few weeks old, so it's going back for repair or replacement.

-- 
Regards
Peter

Re: [gentoo-user] How to get memtest onto a USB drive

[Rasmus Thomsen]

Hello,

actually had that screen happening to me too, but my hardware was fine. Could 
you try emerging the latest (unstable) memtest86+ package? Symlinking should 
work with that one.

Regards,
Rasmus

Re: [gentoo-user] New AMD hardware. Still can't boot (but making progress).

[Alan Mackenzie]

Hello, Joost.

On Fri, Apr 28, 2017 at 20:16:37 +, J. Roeleveld wrote:
> On April 28, 2017 9:51:07 PM GMT+02:00, Alan Mackenzie  wrote:

> >In the end, I went with grub2, and it has taken a lot of effort to get
> >not very far.  Grub's documentation is suboptimal.

> >The state I've managed to get to is that grub appears to have loaded my
> >kernel (it no longer gives an error message about it not being loaded),
> >but then hangs without the kernel outputting even a single message.  At
> >this point, only the reset-button will do anything - Ctrl-Alt-Del does
> >nothing.

> >Just for reference's sake, my boot setup is EFI on GPT.  I have two
> >NVMe
> >SSDs, which will be working together in several mdadm RAID pairs.  grub
> >can read my SSDs, reporting correctly their partitioning and being able
> >to cat the grub configuration file.

> >So, why, after apparently loading the kernel, does grub fail to start
> >it?
> >Any ideas, anybody?

> >Here are the relevant bits of my grub.cfg:

[  ]

> Have you tried connecting using ssh after boot?
> Also, do you have the EFI console support in your kernel?

I didn't, but do now.

More to the point, I'd forgotten to compile the pertinent Radeon
microcode into my kernel, so it's not surprising I saw nothing on my
screen.  What an idiot!

Now I see 16 penguins on my screen, followed by some messages, followed
by a kernel panic, since it can't find the root partition.  It's a long
time since I've been so happy to see a kernel panic.  ;-)

So thank you to everybody who somehow churned up my thinking enough to
get me over this point.

[  ]

> --
> Joost
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] New AMD hardware. Still can't boot [FIXED].

[Alan Mackenzie]

Hello, Gentoo.

On Sat, Apr 29, 2017 at 11:56:35 +, Alan Mackenzie wrote:

> On Fri, Apr 28, 2017 at 20:16:37 +, J. Roeleveld wrote:

> > Have you tried connecting using ssh after boot?
> > Also, do you have the EFI console support in your kernel?

> I didn't, but do now.

> More to the point, I'd forgotten to compile the pertinent Radeon
> microcode into my kernel, so it's not surprising I saw nothing on my
> screen.  What an idiot!

> Now I see 16 penguins on my screen, followed by some messages, followed
> by a kernel panic, since it can't find the root partition.  It's a long
> time since I've been so happy to see a kernel panic.  ;-)

> So thank you to everybody who somehow churned up my thinking enough to
> get me over this point.

I've now managed to boot natively into my new HW.  The final thing to be
fixed was setting the types of two partitions on each of two SSDs to the
64-bit equivalent of gdisk's FD00 (Linux RAID).  This allowed the kernel
to assemble these two pairs as mdadm arrays, one of them being the root
partition.

So thanks to all who helped!

> [  ]

> > --
> > Joost
> > -- 

-- 
Alan Mackenzie (Nuremberg, Germany).

[gentoo-user] Pseudo first impressions

[Alan Mackenzie]

Hello, Gentoo.

Now able to boot into my new hardware, one of the first things I did was

# emerge --sync

.  Fine.  The next thing I tried was

# emerge -auND @world

, which is probably recommended in the handbook.  This was anything but
fine.

I'm glad I'm not a real Gentoo newby, because I would have been
completely flumoxed by what came up on my screen.

For a start, I could barely read parts of it, which were displayed in
dark blue text on a black background.  Setting up /etc/portage/color.map
is not the first thing a new user should have to do to be able to read
messages from emerge.  This is, however, something I knew had to be
done, and I did it.

The error message was "Multiple package instances within a single
package slot have been pulled into the dependency graph, resulting in a
slot conflict:".  Uhh???

Is this gobbledegook really what a new user should be seeing, having not
yet installed any packages, bar a very few, beyond what is requisite to
bringing a new machine up?

The actual conflict packages are:
dev-lang/perl-5.24.1-r1:0/5.24::gentoo
  and
dev-lang/perl-5.22.3-rc4:0/5.22::gentoo
, "pulled in" by internal system packages I've got no direct interest
in, plus, shockingly, "and 2 more with the same problem" and "and 5 more
with the same problem".

I'm glad I've got the experience with Gentoo to know it's worth
ploughing on through these messes.

Other than that, it seems like a pretty ghastly mistake by Gentoo's
quality control.  I know none of you get paid for it, and you all do it
for love.  I admit I probably wouldn't have done the job much better
myself.  But for Gentoo's sake, something needs to get better.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] GCC 5.4.0

[Alan Grimes]

Dale wrote:
> Dale wrote:
>
> This is something I have noticed that changed since the gcc upgrade. 
> One, Firefox seems to use less memory.  It's not a whole lot less but it
> is less for sure.  It also uses a lot less CPU power.  Used to if I had
> two or three Firefox profiles running, I could see 20, 30 and sometimes
> even more CPU usage.  Gkrellm would have a good bit of orange and the
> little needle thing would be hovering around 30 to 40% on all the cores
> with it spiking to well over 50% quite a lot.  Closing Firefox would put
> it down to single digits so I know it was Firefox causing this.  Now,
> with 4 instances running, it is hovering around 10 to 15%. 


Yeah, I monitor GCC changelogs closely...

A while back they were talking about their new code de-duplication pass
and how, as an example, in Firefox it removed over 30,000 duplicate
functions...

I really don't know what's going on over at the mozilla project these
days. I still use Seamonkey because it has all my e-mails but its
performance is fantastically awful these days.


-- 
Strange Game.
The only winning move is not to play. 

Powers are not rights.

Re: [gentoo-user] Pseudo first impressions

[Mick]

On Saturday 29 Apr 2017 14:39:13 Alan Mackenzie wrote:
> Hello, Gentoo.
> 
> Now able to boot into my new hardware, one of the first things I did was
> 
> # emerge --sync
> 
> .  Fine.  The next thing I tried was
> 
> # emerge -auND @world
> 
> , which is probably recommended in the handbook.  This was anything but
> fine.
> 
> I'm glad I'm not a real Gentoo newby, because I would have been
> completely flumoxed by what came up on my screen.
> 
> For a start, I could barely read parts of it, which were displayed in
> dark blue text on a black background.  Setting up /etc/portage/color.map
> is not the first thing a new user should have to do to be able to read
> messages from emerge.  This is, however, something I knew had to be
> done, and I did it.
> 
> The error message was "Multiple package instances within a single
> package slot have been pulled into the dependency graph, resulting in a
> slot conflict:".  Uhh???
> 
> Is this gobbledegook really what a new user should be seeing, having not
> yet installed any packages, bar a very few, beyond what is requisite to
> bringing a new machine up?
> 
> The actual conflict packages are:
> dev-lang/perl-5.24.1-r1:0/5.24::gentoo
>   and
> dev-lang/perl-5.22.3-rc4:0/5.22::gentoo
> , "pulled in" by internal system packages I've got no direct interest
> in, plus, shockingly, "and 2 more with the same problem" and "and 5 more
> with the same problem".
> 
> I'm glad I've got the experience with Gentoo to know it's worth
> ploughing on through these messes.
> 
> Other than that, it seems like a pretty ghastly mistake by Gentoo's
> quality control.  I know none of you get paid for it, and you all do it
> for love.  I admit I probably wouldn't have done the job much better
> myself.  But for Gentoo's sake, something needs to get better.

Try running:

perl-cleaner --reallyall

Then try 'emerge -uaNDv world' again.
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] GCC 5.4.0

[Dale]

Alan Grimes wrote:
> Dale wrote:
>> Dale wrote:
>>
>> This is something I have noticed that changed since the gcc upgrade. 
>> One, Firefox seems to use less memory.  It's not a whole lot less but it
>> is less for sure.  It also uses a lot less CPU power.  Used to if I had
>> two or three Firefox profiles running, I could see 20, 30 and sometimes
>> even more CPU usage.  Gkrellm would have a good bit of orange and the
>> little needle thing would be hovering around 30 to 40% on all the cores
>> with it spiking to well over 50% quite a lot.  Closing Firefox would put
>> it down to single digits so I know it was Firefox causing this.  Now,
>> with 4 instances running, it is hovering around 10 to 15%. 
>
> Yeah, I monitor GCC changelogs closely...
>
> A while back they were talking about their new code de-duplication pass
> and how, as an example, in Firefox it removed over 30,000 duplicate
> functions...
>
> I really don't know what's going on over at the mozilla project these
> days. I still use Seamonkey because it has all my e-mails but its
> performance is fantastically awful these days.
>
>

I use Seamonkey for email and related things too.  I use Firefox for
some other things, it has more add-ons than Seamonkey.  To me, it seems
as if Seamonkey is not getting the attention it used to.  It's not lean
and mean, it's fat and slow.  I'm not sure what makes it so tho.

I'm glad Firefox is better tho.  Makes me wonder about the next gcc.  o_O 

Dale

:-)  :-) 

Re: [gentoo-user] Pseudo first impressions

[J. Roeleveld]

On April 29, 2017 4:39:13 PM GMT+02:00, Alan Mackenzie  wrote:
>Hello, Gentoo.
>
>Now able to boot into my new hardware, one of the first things I did
>was
>
># emerge --sync
>
>.  Fine.  The next thing I tried was
>
># emerge -auND @world
>
>, which is probably recommended in the handbook.  This was anything but
>fine.
>
>I'm glad I'm not a real Gentoo newby, because I would have been
>completely flumoxed by what came up on my screen.
>
>For a start, I could barely read parts of it, which were displayed in
>dark blue text on a black background.  Setting up
>/etc/portage/color.map
>is not the first thing a new user should have to do to be able to read
>messages from emerge.  This is, however, something I knew had to be
>done, and I did it.
>
>The error message was "Multiple package instances within a single
>package slot have been pulled into the dependency graph, resulting in a
>slot conflict:".  Uhh???
>
>Is this gobbledegook really what a new user should be seeing, having
>not
>yet installed any packages, bar a very few, beyond what is requisite to
>bringing a new machine up?
>
>The actual conflict packages are:
>dev-lang/perl-5.24.1-r1:0/5.24::gentoo
>  and
>dev-lang/perl-5.22.3-rc4:0/5.22::gentoo
>, "pulled in" by internal system packages I've got no direct interest
>in, plus, shockingly, "and 2 more with the same problem" and "and 5
>more
>with the same problem".
>
>I'm glad I've got the experience with Gentoo to know it's worth
>ploughing on through these messes.
>
>Other than that, it seems like a pretty ghastly mistake by Gentoo's
>quality control.  I know none of you get paid for it, and you all do it
>for love.  I admit I probably wouldn't have done the job much better
>myself.  But for Gentoo's sake, something needs to get better.

Alan,

I found on several systems that using "--backtrack=100" actually resolved the 
latest blockers with perl.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Re: In search of an truecolor-capable terminal emulator

[Floyd Anderson]

On Sa, 29 Apr 05:15:50 +0200
tu...@posteo.de wrote:


Hi,

before changing my system I took a look at
https://wiki.gentoo.org/wiki/Xorg/Hardware_3D_acceleration_guide

Down the page there is a test, whohc on my system reports:
glxinfo | grep rendering
direct rendering: Yes
   GL_NV_path_rendering, GL_NV_pixel_data_range, GL_NV_point_sprite,
   GL_NV_path_rendering, GL_NV_pixel_data_range, GL_NV_point_sprite,
   GL_NV_packed_float_linear, GL_NV_path_rendering,


For me it reads like: Yes, you have hardware accelerated rendering.

Or did I miss something...?
That need not be the whole truth. Look also for ‘OpenGL renderer’ [1] 
with command:

   glxinfo | grep 'render'
or more verbose:
   glxinfo | grep 'string:'

It may be worth to study the Xorg log file for something like:
 - Direct rendering enabled/disabled
 - 2D and 3D acceleration enabled/disabled
 - reverting to software rendering
 - Loaded and initialized swrast (swrast => software rasterizer)
 - and so on ...


References:
[1] 


--
Regards,
floyd

Re: [gentoo-user] replacement for ftp?

[lee]

Mick  writes:

> On Tuesday 25 Apr 2017 16:45:37 Alan McKinnon wrote:
>> On 25/04/2017 16:29, lee wrote:
>> > Hi,
>> > 
>> > since the usage of FTP seems to be declining, what is a replacement
>> > which is at least as good as FTP?
>> > 
>> > I'm aware that there's webdav, but that's very awkward to use and
>> > missing features.
>> 
>> Why not stick with ftp?
>> Or, put another way, why do you feel you need to use something else?
>> 
>> There's always dropbox
>
>
> Invariably all web hosting ISPs offer ftp(s) for file upload/download.  If 
> you 
> pay a bit more you should be able to get ssh/scp/sftp too.  Indeed, many ISPs 
> throw in scp/sftp access as part of their basic package.
>
> Webdav(s) offers the same basic upload/download functionality, so I am not 
> sure what you find awkward about it, although I'd rather use lftp instead of 
> cadaver any day. ;-)
>
> As Alan mentioned, with JavaScript'ed web pages these days there are many 
> webapp'ed ISP offerings like Dropbox and friends.
>
> What is the use case you have in mind?

transferring large amounts of data and automatization in processing at
least some of it, without involving a 3rd party

"Large amounts" can be "small" like 100MB --- or over 50k files in 12GB,
or even more.  The mirror feature of lftp is extremely useful for such
things.

I wouldn't ever want having to mess around with web pages to figure out
how to do this.  Ftp is plain and simple.  So you see why I'm explicitly
asking for a replacement which is at least as good as ftp.


-- 
"Didn't work" is an error.

Re: [gentoo-user] replacement for ftp?

[lee]

Danny YUE  writes:

> On 2017-04-25 14:29, lee  wrote:
>> Hi,
>>
>> since the usage of FTP seems to be declining, what is a replacement
>> which is at least as good as FTP?
>>
>> I'm aware that there's webdav, but that's very awkward to use and
>> missing features.
>
> What about sshfs? It allows you to mount a location that can be accessed
> via ssh to your local file system, as if you are using ssh.

Doesn't that require ssh access?  And how do you explain that to ppl
finding it too difficult to use Filezilla?  Is it available for Windoze?

> Also samba can be a replacement. I have a samba server on my OpenWRT
> router and use mount.cifs to mount it...

Does that work well, reliably and securely over internet connections?


-- 
"Didn't work" is an error.

Re: [gentoo-user] Pseudo first impressions

[lee]

Alan Mackenzie  writes:

> For a start, I could barely read parts of it, which were displayed in
> dark blue text on a black background.

Yes, that always annoys me, too.  You need to copy it from the terminal
and paste it into emacs, and then it's still not exactly readable or
even understandable.

> Setting up /etc/portage/color.map is not the first thing a new user
> should have to do to be able to read messages from emerge.  This is,
> however, something I knew had to be done, and I did it.

I didn't know that there's such a thing.  That should be mentioned in
the docs.

> The error message was "Multiple package instances within a single
> package slot have been pulled into the dependency graph, resulting in a
> slot conflict:".  Uhh???

Yeah, I never saw that graph.

> Is this gobbledegook really what a new user should be seeing, having not
> yet installed any packages, bar a very few, beyond what is requisite to
> bringing a new machine up?

The common answer to this is that the devs don't have time and/or can't
be bothered to improve this, and it's too complicated anyway.

> The actual conflict packages are:
> dev-lang/perl-5.24.1-r1:0/5.24::gentoo
>   and
> dev-lang/perl-5.22.3-rc4:0/5.22::gentoo
> , "pulled in" by internal system packages I've got no direct interest
> in, plus, shockingly, "and 2 more with the same problem" and "and 5 more
> with the same problem".

It's usually hundreds, not only 2 or 5.

> I'm glad I've got the experience with Gentoo to know it's worth
> ploughing on through these messes.

How's all the pain worth it?  It's not even all about the pain, it's
about keeping things working and up to date.  Even just that may be
impossible with Gentoo, even if you have the time.

> Other than that, it seems like a pretty ghastly mistake by Gentoo's
> quality control.  I know none of you get paid for it, and you all do it
> for love.  I admit I probably wouldn't have done the job much better
> myself.  But for Gentoo's sake, something needs to get better.

Being able to update at all would be a good start.


BTW, what's with this:


emerge -a feh
[...]
!!! existing preserved libs:
>>> package: sys-libs/binutils-libs-2.27
 *  - /usr/lib64/libbfd-2.25.1.so
 *  used by 
/usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so 
(sys-devel/binutils-2.25.1-r1)
Use emerge @preserved-rebuild to rebuild packages using these libraries

emerge @preserved-rebuild
[...]
>>> Emerging (1 of 1) sys-devel/binutils-2.25.1-r1::gentoo
[...]
>>> Installing (1 of 1) sys-devel/binutils-2.25.1-r1::gentoo
>>> Jobs: 1 of 1 complete   Load avg: 3.41, 1.36, 0.60
[...]
!!! existing preserved libs:
>>> package: sys-libs/binutils-libs-2.27
 *  - /usr/lib64/libbfd-2.25.1.so
 *  used by 
/usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so 
(sys-devel/binutils-2.25.1-r1)
Use emerge @preserved-rebuild to rebuild packages using these libraries



It's not possible to emerge net-dns/bind (I'm guessing that might be
because of binutils having some issue) and mysql-workbench.  The old
version of bind is still working, but what if it wasn't already
installed?  Also, I had to patch dev-perl/GD to get that to work.  What
will fail next?

So yes, it's not only about updates but about installing something in
general: It may work or not, and it may break other things or not, or it
may require you to do something because something has been pulled into
something by something, or you need to remove something, or something
doesn't work because of something ...


-- 
"Didn't work" is an error.

Re: [gentoo-user] replacement for ftp?

[lee]

Alan McKinnon  writes:

> On 25/04/2017 16:29, lee wrote:
>> 
>> Hi,
>> 
>> since the usage of FTP seems to be declining, what is a replacement
>> which is at least as good as FTP?
>> 
>> I'm aware that there's webdav, but that's very awkward to use and
>> missing features.
>> 
>> 
>
> Why not stick with ftp?

The intended users are incompetent, hence it is too difficult to use ...

> Or, put another way, why do you feel you need to use something else?

I don't want to use anything else.

Yet even Debian has announced that they will shut down their ftp
services in November, one of the reasons being that almost no one uses
them.  Of course, their application is different from what I'm looking
for because they only have downloads and no uploads.

However, another reason given was that ftp isn't exactly friendly to
firewalls and requires "awkward kludges" when load balancing is used.
That is a pretty good reason.

Anyway, when pretty much nobody uses a particular software anymore, it
won't be very feasible to use that software.

> There's always dropbox

Well, dropbox sucks.  I got a dropbox link and it didn't work at all,
and handing out the data to some 3rd party is a very bad idea.  It's
also difficult to automate things with that.


-- 
"Didn't work" is an error.

Re: [gentoo-user] Re: replacement for ftp?

[lee]

Kai Krakow  writes:

> Am Tue, 25 Apr 2017 15:29:18 +0100
> schrieb lee :
>
>> since the usage of FTP seems to be declining, what is a replacement
>> which is at least as good as FTP?
>> 
>> I'm aware that there's webdav, but that's very awkward to use and
>> missing features.
>
> If you want to sync files between two sites, try rsync. It is supported
> through ssh also. Plus, it's very fast also.

Yes, I'm using it mostly for backups/copies.

The problem is that ftp is ideal for the purpose, yet users find it too
difficult to use, and nobody uses it.  So there must be something else
as good or better which is easier to use and which ppl do use.  I don't
see how they would transfer files without ftp when ftp is the ideal
solution.


-- 
"Didn't work" is an error.

Re: [gentoo-user] replacement for ftp?

[lee]

"Poison BL."  writes:

> On Tue, Apr 25, 2017 at 10:29 AM, lee  wrote:
>
>>
>> Hi,
>>
>> since the usage of FTP seems to be declining, what is a replacement
>> which is at least as good as FTP?
>>
>> I'm aware that there's webdav, but that's very awkward to use and
>> missing features.
>>
>>
>> --
>> "Didn't work" is an error.
>>
>>
> The one issue I have with all the answers I've seen is that they all lack
> the most important question. You're asking for alternatives for an old tool
> that was used for many use cases that, these days, have evolved to have
> very different requirements for security, integration of access methods,
> and general workflows for use. FTP used to be the go-to for long distance
> file sharing for *all* use cases, one to one (user managing a website's
> content), many to one (upload site), one to many (download site), etc.
> What's your use case?

all of them, with encrypted transfers and users needing a password for
access

I don't know anything better than ftp for this.  Alternatively, there
would need to be several different services for each group of users
accommodating their particular use case, and being a nightmare to deploy,
to maintain and to use.


-- 
"Didn't work" is an error.

Re: [gentoo-user] replacement for ftp?

[Poison BL.]

On Sat, Apr 29, 2017 at 3:24 PM, lee  wrote:

> Mick  writes:
>
> > On Tuesday 25 Apr 2017 16:45:37 Alan McKinnon wrote:
> >> On 25/04/2017 16:29, lee wrote:
> >> > Hi,
> >> >
> >> > since the usage of FTP seems to be declining, what is a replacement
> >> > which is at least as good as FTP?
> >> >
> >> > I'm aware that there's webdav, but that's very awkward to use and
> >> > missing features.
> >>
> >> Why not stick with ftp?
> >> Or, put another way, why do you feel you need to use something else?
> >>
> >> There's always dropbox
> >
> >
> > Invariably all web hosting ISPs offer ftp(s) for file upload/download.
> If you
> > pay a bit more you should be able to get ssh/scp/sftp too.  Indeed, many
> ISPs
> > throw in scp/sftp access as part of their basic package.
> >
> > Webdav(s) offers the same basic upload/download functionality, so I am
> not
> > sure what you find awkward about it, although I'd rather use lftp
> instead of
> > cadaver any day. ;-)
> >
> > As Alan mentioned, with JavaScript'ed web pages these days there are many
> > webapp'ed ISP offerings like Dropbox and friends.
> >
> > What is the use case you have in mind?
>
> transferring large amounts of data and automatization in processing at
> least some of it, without involving a 3rd party
>
> "Large amounts" can be "small" like 100MB --- or over 50k files in 12GB,
> or even more.  The mirror feature of lftp is extremely useful for such
> things.
>
> I wouldn't ever want having to mess around with web pages to figure out
> how to do this.  Ftp is plain and simple.  So you see why I'm explicitly
> asking for a replacement which is at least as good as ftp.
>
>
> --
> "Didn't work" is an error.
>
>
Half petabyte datasets aren't really something I'd personally *ever* trust
ftp with in the first place. That said, it depends entirely on the network
you're working with. Are you pushing this data in/out of the network your
machines live in, or are you working primarily internally? If internal,
what're the network side capabilities you have? Since you're likely already
using something on the order of CEPH or Gluster to back the datasets where
they sit, just working with it all across network from that storage would
be my first instinct.

How often does it need moved in/out of your facility, and is there no way
to break up the processing into smaller chunks than a 0.6PB mass of files?
Distribute out the smaller pieces with rsync, scp, or the like, operate on
them, and pull back in the results, rather than trying to shift around the
entire set. There's a reason Amazon will send a physical truck to a site to
import large datasets into glacier... ;)

-- 
Poison [BLX]
Joshua M. Murphy

[gentoo-user] having unavailable packages installed

[lee]

Hi,

how is it possible that a package is installed which is not available?


eix glibmm
[?] dev-cpp/glibmm
 Verfügbare Versionen:   (2) 2.44.0 2.46.4 2.48.1 ~2.50.0
   {debug doc examples test ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" 
ABI_S390="32 64" ABI_X86="32 64 x32"}
 Installierte Versionen: 2.50.1(2)(16:58:00 24.04.2017)(-debug -doc -test 
ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 
-x32")
 Startseite: http://www.gtkmm.org
 Beschreibung:   C++ interface for glib2


2.50.1(2) appears to be installed but is not available.


-- 
"Didn't work" is an error.

Re: [gentoo-user] having unavailable packages installed

[Dale]

lee wrote:
> Hi,
>
> how is it possible that a package is installed which is not available?
>
>
> eix glibmm
> [?] dev-cpp/glibmm
>  Verfügbare Versionen:   (2) 2.44.0 2.46.4 2.48.1 ~2.50.0
>{debug doc examples test ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" 
> ABI_S390="32 64" ABI_X86="32 64 x32"}
>  Installierte Versionen: 2.50.1(2)(16:58:00 24.04.2017)(-debug -doc -test 
> ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 
> -32 -x32")
>  Startseite: http://www.gtkmm.org
>  Beschreibung:   C++ interface for glib2
>
>
> 2.50.1(2) appears to be installed but is not available.
>
>

Usually when you see that, it was removed from the tree.  Some packages
are upgraded in the tree then a little while later, older versions are
removed from the tree.  I've seen that several times.  There may be
other reasons for that but that is the one I see quite often. 

By the way, if for some reason you have to have that version, you can
grab the ebuild and put it in a local overlay.  Make sure you don't let
that get updated/removed before you do that tho. 

Hope that helps.

Dale

:-)  :-) 

Re: [gentoo-user] Pseudo first impressions

[Daniel Frey]

On 04/29/2017 01:38 PM, lee wrote:
> !!! existing preserved libs:
 package: sys-libs/binutils-libs-2.27
>  *  - /usr/lib64/libbfd-2.25.1.so
>  *  used by 
> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so 
> (sys-devel/binutils-2.25.1-r1)
> Use emerge @preserved-rebuild to rebuild packages using these libraries
> 
> 
> 
> It's not possible to emerge net-dns/bind (I'm guessing that might be
> because of binutils having some issue) and mysql-workbench.  The old
> version of bind is still working, but what if it wasn't already
> installed?  Also, I had to patch dev-perl/GD to get that to work.  What
> will fail next?
> 
> So yes, it's not only about updates but about installing something in
> general: It may work or not, and it may break other things or not, or it
> may require you to do something because something has been pulled into
> something by something, or you need to remove something, or something
> doesn't work because of something ...
> 
> 

Do a --depclean and that will resolve itself.

Dan

Re: [gentoo-user] Pseudo first impressions

[Daniel Frey]

On 04/29/2017 10:28 AM, J. Roeleveld wrote:
> 
> I found on several systems that using "--backtrack=100" actually resolved the 
> latest blockers with perl.
> 

I find doing `emerge --oneshot --nodeps perl` then `perl-cleaner --all`
was faster. Portage would chug for over five minutes on some of my
machines trying to resolve the dependencies. By the time it figured out
what it wanted to do, the manual way I used was almost finished.

(Do note the CPU is slow on the machines I use but compiling is done
with distcc so that was done relatively quickly.)

Dan

Re: [gentoo-user] replacement for ftp?

[lee]

"Poison BL."  writes:

> On Sat, Apr 29, 2017 at 3:24 PM, lee  wrote:
>
>> Mick  writes:
>>
>> > On Tuesday 25 Apr 2017 16:45:37 Alan McKinnon wrote:
>> >> On 25/04/2017 16:29, lee wrote:
>> >> > Hi,
>> >> >
>> >> > since the usage of FTP seems to be declining, what is a replacement
>> >> > which is at least as good as FTP?
>> >> >
>> >> > I'm aware that there's webdav, but that's very awkward to use and
>> >> > missing features.
>> >>
>> >> Why not stick with ftp?
>> >> Or, put another way, why do you feel you need to use something else?
>> >>
>> >> There's always dropbox
>> >
>> >
>> > Invariably all web hosting ISPs offer ftp(s) for file upload/download.
>> If you
>> > pay a bit more you should be able to get ssh/scp/sftp too.  Indeed, many
>> ISPs
>> > throw in scp/sftp access as part of their basic package.
>> >
>> > Webdav(s) offers the same basic upload/download functionality, so I am
>> not
>> > sure what you find awkward about it, although I'd rather use lftp
>> instead of
>> > cadaver any day. ;-)
>> >
>> > As Alan mentioned, with JavaScript'ed web pages these days there are many
>> > webapp'ed ISP offerings like Dropbox and friends.
>> >
>> > What is the use case you have in mind?
>>
>> transferring large amounts of data and automatization in processing at
>> least some of it, without involving a 3rd party
>>
>> "Large amounts" can be "small" like 100MB --- or over 50k files in 12GB,
>> or even more.  The mirror feature of lftp is extremely useful for such
>> things.
>>
>> I wouldn't ever want having to mess around with web pages to figure out
>> how to do this.  Ftp is plain and simple.  So you see why I'm explicitly
>> asking for a replacement which is at least as good as ftp.
>>
>>
>> --
>> "Didn't work" is an error.
>>
>>
> Half petabyte datasets aren't really something I'd personally *ever* trust
> ftp with in the first place.

Why not?  (12GB are nowhere close to half a petabyte ...)

> That said, it depends entirely on the network
> you're working with. Are you pushing this data in/out of the network your
> machines live in, or are you working primarily internally? If internal,
> what're the network side capabilities you have? Since you're likely already
> using something on the order of CEPH or Gluster to back the datasets where
> they sit, just working with it all across network from that storage would
> be my first instinct.

The data would come in from suppliers.  There isn't really anything
going on atm but fetching data once a month which can be like 100MB or
12GB or more.  That's because ppl don't use ftp ...

> How often does it need moved in/out of your facility, and is there no way
> to break up the processing into smaller chunks than a 0.6PB mass of files?
> Distribute out the smaller pieces with rsync, scp, or the like, operate on
> them, and pull back in the results, rather than trying to shift around the
> entire set. There's a reason Amazon will send a physical truck to a site to
> import large datasets into glacier... ;)

Amazon has trucks?  Perhaps they do in other countries.  Here, amazon is
just another web shop.  They might have some delivery vans, but I've
never seen one, so I doubt it.  And why would anyone give them their
data?  There's no telling what they would do with it.


-- 
"Didn't work" is an error.

Re: [gentoo-user] Pseudo first impressions

[lee]

Daniel Frey  writes:

> On 04/29/2017 01:38 PM, lee wrote:
>> !!! existing preserved libs:
> package: sys-libs/binutils-libs-2.27
>>  *  - /usr/lib64/libbfd-2.25.1.so
>>  *  used by 
>> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so 
>> (sys-devel/binutils-2.25.1-r1)
>> Use emerge @preserved-rebuild to rebuild packages using these libraries
>> 
>> 
>> 
>> It's not possible to emerge net-dns/bind (I'm guessing that might be
>> because of binutils having some issue) and mysql-workbench.  The old
>> version of bind is still working, but what if it wasn't already
>> installed?  Also, I had to patch dev-perl/GD to get that to work.  What
>> will fail next?
>> 
>> So yes, it's not only about updates but about installing something in
>> general: It may work or not, and it may break other things or not, or it
>> may require you to do something because something has been pulled into
>> something by something, or you need to remove something, or something
>> doesn't work because of something ...
>> 
>> 
>
> Do a --depclean and that will resolve itself.

Last time I tried that, it wanted to remove the source of the kernel I'm
using, along with other things.  It would have made sense if I had
upgraded the kernel, too, but I didn't have the time to do that yet.


-- 
"Didn't work" is an error.

Re: [gentoo-user] having unavailable packages installed

[lee]

Dale  writes:

> lee wrote:
>> Hi,
>>
>> how is it possible that a package is installed which is not available?
>>
>>
>> eix glibmm
>> [?] dev-cpp/glibmm
>>  Verfügbare Versionen:   (2) 2.44.0 2.46.4 2.48.1 ~2.50.0
>>{debug doc examples test ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" 
>> ABI_S390="32 64" ABI_X86="32 64 x32"}
>>  Installierte Versionen: 2.50.1(2)(16:58:00 24.04.2017)(-debug -doc 
>> -test ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" 
>> ABI_X86="64 -32 -x32")
>>  Startseite: http://www.gtkmm.org
>>  Beschreibung:   C++ interface for glib2
>>
>>
>> 2.50.1(2) appears to be installed but is not available.
>>
>>
>
> Usually when you see that, it was removed from the tree.  Some packages
> are upgraded in the tree then a little while later, older versions are
> removed from the tree.  I've seen that several times.  There may be
> other reasons for that but that is the one I see quite often. 

You mean one of the not-so-old version was removed?  That could be.

> By the way, if for some reason you have to have that version, you can
> grab the ebuild and put it in a local overlay.  Make sure you don't let
> that get updated/removed before you do that tho. 

I don't know, I only came across it when trying to get mysql-workbench
to compile.  I don't know why it's installed.

> Hope that helps.

ty :)

> Dale
>
> :-)  :-) 
>
>
>

-- 
"Didn't work" is an error.

Re: [gentoo-user] having unavailable packages installed

[Dale]

lee wrote:
> Dale  writes:
>
>> lee wrote:
>>> Hi,
>>>
>>> how is it possible that a package is installed which is not available?
>>>
>>>
>>> eix glibmm
>>> [?] dev-cpp/glibmm
>>>  Verfügbare Versionen:   (2) 2.44.0 2.46.4 2.48.1 ~2.50.0
>>>{debug doc examples test ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" 
>>> ABI_S390="32 64" ABI_X86="32 64 x32"}
>>>  Installierte Versionen: 2.50.1(2)(16:58:00 24.04.2017)(-debug -doc 
>>> -test ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" 
>>> ABI_X86="64 -32 -x32")
>>>  Startseite: http://www.gtkmm.org
>>>  Beschreibung:   C++ interface for glib2
>>>
>>>
>>> 2.50.1(2) appears to be installed but is not available.
>>>
>>>
>> Usually when you see that, it was removed from the tree.  Some packages
>> are upgraded in the tree then a little while later, older versions are
>> removed from the tree.  I've seen that several times.  There may be
>> other reasons for that but that is the one I see quite often. 
> You mean one of the not-so-old version was removed?  That could be.


I guess it depends on how the maintainer does it.  I've seen a few times
when they release a minor update that fixes something serious and then
remove the old one right away or very shortly after.   Some maintainers
leave older versions in the tree for quite a while.  I stopped
scratching my head over it a long time ago.  lol 

>
>> By the way, if for some reason you have to have that version, you can
>> grab the ebuild and put it in a local overlay.  Make sure you don't let
>> that get updated/removed before you do that tho. 
> I don't know, I only came across it when trying to get mysql-workbench
> to compile.  I don't know why it's installed.
>

I have it installed here as well.  This is what pulls it in here:


root@fireball / # equery d glibmm
 * These packages depend on glibmm:
dev-cpp/atkmm-2.24.2
(>=dev-cpp/glibmm-2.46.2:2[doc?,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
dev-cpp/gtkmm-2.24.5
(>=dev-cpp/glibmm-2.34.1:2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
dev-cpp/pangomm-2.40.1
(>=dev-cpp/glibmm-2.48.0:2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
sys-block/gparted-0.27.0 (>=dev-cpp/glibmm-2.14:2)
root@fireball / # 


It seems several packages here pull it in. 


>> Hope that helps.
> ty :)
>
>> Dale
>>
>> :-)  :-) 
>>
>>
>>

Welcome. 

Dale

:-)  :-) 

Re: [gentoo-user] replacement for ftp?

[Walter Dnes]

> transferring large amounts of data and automatization in processing at
> least some of it, without involving a 3rd party
> 
> "Large amounts" can be "small" like 100MB --- or over 50k files in 12GB,
> or even more.  The mirror feature of lftp is extremely useful for such
> things.
> 
> I wouldn't ever want having to mess around with web pages to figure out
> how to do this.  Ftp is plain and simple.  So you see why I'm explicitly
> asking for a replacement which is at least as good as ftp.

  How about "wget"?  It can handle ftp and http, and it can be scripted.
And it can discriminate on timestamps, i.e. only download a file if it
has been changed since the latest download at your site.

  Then there's always "sneakernet".  To quote Andrew Tanenbaum from 1981

> Never underestimate the bandwidth of a station wagon full of tapes
> hurtling down the highway.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] replacement for ftp?

[Alan McKinnon]

On 30/04/2017 03:11, lee wrote:
> "Poison BL."  writes:
> 
>> On Sat, Apr 29, 2017 at 3:24 PM, lee  wrote:
>>
>>> Mick  writes:
>>>
 On Tuesday 25 Apr 2017 16:45:37 Alan McKinnon wrote:
> On 25/04/2017 16:29, lee wrote:
>> Hi,
>>
>> since the usage of FTP seems to be declining, what is a replacement
>> which is at least as good as FTP?
>>
>> I'm aware that there's webdav, but that's very awkward to use and
>> missing features.
>
> Why not stick with ftp?
> Or, put another way, why do you feel you need to use something else?
>
> There's always dropbox


 Invariably all web hosting ISPs offer ftp(s) for file upload/download.
>>> If you
 pay a bit more you should be able to get ssh/scp/sftp too.  Indeed, many
>>> ISPs
 throw in scp/sftp access as part of their basic package.

 Webdav(s) offers the same basic upload/download functionality, so I am
>>> not
 sure what you find awkward about it, although I'd rather use lftp
>>> instead of
 cadaver any day. ;-)

 As Alan mentioned, with JavaScript'ed web pages these days there are many
 webapp'ed ISP offerings like Dropbox and friends.

 What is the use case you have in mind?
>>>
>>> transferring large amounts of data and automatization in processing at
>>> least some of it, without involving a 3rd party
>>>
>>> "Large amounts" can be "small" like 100MB --- or over 50k files in 12GB,
>>> or even more.  The mirror feature of lftp is extremely useful for such
>>> things.
>>>
>>> I wouldn't ever want having to mess around with web pages to figure out
>>> how to do this.  Ftp is plain and simple.  So you see why I'm explicitly
>>> asking for a replacement which is at least as good as ftp.
>>>
>>>
>>> --
>>> "Didn't work" is an error.
>>>
>>>
>> Half petabyte datasets aren't really something I'd personally *ever* trust
>> ftp with in the first place.
> 
> Why not?  (12GB are nowhere close to half a petabyte ...)
> 
>> That said, it depends entirely on the network
>> you're working with. Are you pushing this data in/out of the network your
>> machines live in, or are you working primarily internally? If internal,
>> what're the network side capabilities you have? Since you're likely already
>> using something on the order of CEPH or Gluster to back the datasets where
>> they sit, just working with it all across network from that storage would
>> be my first instinct.
> 
> The data would come in from suppliers.  There isn't really anything
> going on atm but fetching data once a month which can be like 100MB or
> 12GB or more.  That's because ppl don't use ftp ...

I have the opposite experience.
I have the devil's own time trying to convince people to NOT use ftp for
anything and everything under the sun that even remotely resembles
getting data from A to B... (especially things that are best done over a
message bus)

I'm still not understanding why you are asking your questions. What you
describe looks like the ideal case for ftp:

- supplier pushes a file or files somewhere
- you fetch those files later at a suitable time

it looks like a classic producer/consumer scenario and ftp or any of
it's webby clones like dropbox really it still the best tool overall.
Plus it has the added benefit that no user needs extra software - all
OSes have ftp clients even if it's just a browser

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] having unavailable packages installed

[Alan McKinnon]

On 30/04/2017 01:01, lee wrote:
> 
> Hi,
> 
> how is it possible that a package is installed which is not available?
> 
> 
> eix glibmm
> [?] dev-cpp/glibmm
>  Verfügbare Versionen:   (2) 2.44.0 2.46.4 2.48.1 ~2.50.0
>{debug doc examples test ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" 
> ABI_S390="32 64" ABI_X86="32 64 x32"}
>  Installierte Versionen: 2.50.1(2)(16:58:00 24.04.2017)(-debug -doc -test 
> ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 
> -32 -x32")
>  Startseite: http://www.gtkmm.org
>  Beschreibung:   C++ interface for glib2
> 
> 
> 2.50.1(2) appears to be installed but is not available.
> 
> 

it was available
you installed it
then it went out of portage
you still have it installed
portage has yet to find a good reason to upgrade/remove/touch it

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] gcc with graphite flag?

[Walter Dnes]

On Fri, Apr 28, 2017 at 09:04:19AM -0500, Corbin Bird wrote

> On my Gentoo box ...
> 
> [ebuild   R] sys-devel/gcc-5.4.0-r3:5.4.0::gentoo  USE="cxx fortran
> gcj graphite (multilib) nls nptl objc objc++ objc-gc openmp sanitize vtv
> (-altivec) (-awt) -cilk -debug -doc (-fixed-point) -go (-hardened)
> (-jit) (-libssp) -mpx -nopie -nossp -regression-test -vanilla" 0 KiB
> 
> 
> "cloog" has been removed, going from GCC 4.9.4 -> GCC 5.4.0

  So much for that wiki entry.  BTW, I ended up putting...

sys-devel/gcc graphite

...in package.use.  The "graphite" USE flag means something entirely
different for harfbuzz, i.e. build against media-libs/harfbuzz against
media-gfx/graphite2

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Pseudo first impressions

[Daniel Frey]

On 04/29/2017 06:23 PM, lee wrote:
> Daniel Frey  writes:
>> Do a --depclean and that will resolve itself.
> 
> Last time I tried that, it wanted to remove the source of the kernel I'm
> using, along with other things.  It would have made sense if I had
> upgraded the kernel, too, but I didn't have the time to do that yet.
> 
> 

It will only remove things that it deems not needed. Usually these are
packages that have just been upgraded.

For kernel sources, tell portage to not remove it:

`emerge --noreplace sys-kernel/gentoo-sources:4.4.52`

as an example.

If you do that, --depclean will not remove the sources for 4.4.52 (as an
example.)

Dan

[gentoo-user] Re: Pseudo first impressions

[Ian Zimmerman]

On 2017-04-30 02:23, lee wrote:

> > Do a --depclean and that will resolve itself.
> 
> Last time I tried that, it wanted to remove the source of the kernel
> I'm using, along with other things.  It would have made sense if I had
> upgraded the kernel, too, but I didn't have the time to do that yet.

emerge --select =sys-kernel/gentoo-sources-${VERSION}

or add a line for the exact version to the world file manually

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign:
http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html

Re: [gentoo-user] replacement for ftp?

[Poison BL.]

On Sat, Apr 29, 2017 at 9:11 PM, lee  wrote:
>
> "Poison BL."  writes:
> > Half petabyte datasets aren't really something I'd personally *ever*
trust
> > ftp with in the first place.
>
> Why not?  (12GB are nowhere close to half a petabyte ...)

Ah... I completely misread that "or over 50k files in 12GB" as 50k files
*at* 12GB each... which works out to 0.6 PB, incidentally.

> The data would come in from suppliers.  There isn't really anything
> going on atm but fetching data once a month which can be like 100MB or
> 12GB or more.  That's because ppl don't use ftp ...

Really, if you're pulling it in from third party suppliers, you tend to be
tied to what they offer as a method of pulling it from them (or them
pushing it out to you), unless you're in the unique position to dictate the
decision for them. From there, assuming you can push your choice of product
on them, it becomes a question of how often the same dataset will need
updated from the same sources, how much it changes between updates, how
secure it needs to be in transit, how much you need to be able to trust
that the source is still legitimately who you think it is, and how much
verification that there wasn't any corruption during the transfer. Generic
FTP has been losing favor over time because it was built in a time that
many of those questions weren't really at the top of the list for concerns.

SFTP (or SCP) (as long as keys are handled properly) allows for pretty
solid certainty that a) both ends of the connection are who they say they
are, b) those two ends are the only ones reading the data in transit, and
c) the data that was sent is the same that was received (simply as a side
benefit of the encryption/decryption). Rsync over SSH gives the same set of
benefits, reduces the bandwidth used for updating the dataset (when it's
the same dataset, at least), and will also verify the data on both ends (as
it exists on disk) matches. If you're particularly lucky, the data might
even hit just the right mark that benefits from the in-line compression you
can turn on with SSH, too, cutting down the actual amount of bandwidth you
burn through for each transfer.

If your suppliers all have *nix based systems available, those are also
standard tools that they'll have on hand. If they're strictly Windows
shops, SCP/SFTP are still readily available, though they aren't built into
the OS... rsync gets a bit trickier.

> > How often does it need moved in/out of your facility, and is there no
way
> > to break up the processing into smaller chunks than a 0.6PB mass of
files?
> > Distribute out the smaller pieces with rsync, scp, or the like, operate
on
> > them, and pull back in the results, rather than trying to shift around
the
> > entire set. There's a reason Amazon will send a physical truck to a
site to
> > import large datasets into glacier... ;)
>
> Amazon has trucks?  Perhaps they do in other countries.  Here, amazon is
> just another web shop.  They might have some delivery vans, but I've
> never seen one, so I doubt it.  And why would anyone give them their
> data?  There's no telling what they would do with it.

Amazon's also one of the best known cloud computing suppliers on the planet
(AWS = Amazon Web Services). They have everything from pure compute
offerings to cloud storage geared towards *large* data archival. The latter
offering is named "glacier", and they offer a service for the import of
data into it (usually the "first pass", incremental changes are generally
done over the wire) that consists of a shipping truck with a rather nifty
storage system in the back of it that they hook right into your network.
You fill it with data, and then they drive it back to one of their data
centers to load it into place.

--
Poison [BLX]
Joshua M. Murphy

[gentoo-user] Re: Pseudo first impressions

[Kai Krakow]

Am Sat, 29 Apr 2017 14:39:13 +
schrieb Alan Mackenzie :

> For a start, I could barely read parts of it, which were displayed in
> dark blue text on a black background.  Setting
> up /etc/portage/color.map is not the first thing a new user should
> have to do to be able to read messages from emerge.  This is,
> however, something I knew had to be done, and I did it.

This is a problem with most terminal emulators having a much too dark
"dark blue". On an old DOS CRT, this dark blue was still bright enough
to be read easily on black background. Especially, I found PuTTY in
Windows having a dark blue barely readable.

E.g., in KDE Konsole I usually switch to a different terminal color
scheme which usually gets around this. But then, contrast on bright
colors is usually very bad, as can be seen in MC at some points. But
the new "breeze" color scheme from current Plasma versions is quite
nice and an overall good fit.

> The error message was "Multiple package instances within a single
> package slot have been pulled into the dependency graph, resulting in
> a slot conflict:".  Uhh???

This wouldn't happen if this would actually be a new system with vendor
stage tarball. I guess you're upgrading an existing system from new
hardware.

> Is this gobbledegook really what a new user should be seeing, having
> not yet installed any packages, bar a very few, beyond what is
> requisite to bringing a new machine up?
> 
> The actual conflict packages are:
> dev-lang/perl-5.24.1-r1:0/5.24::gentoo
>   and
> dev-lang/perl-5.22.3-rc4:0/5.22::gentoo
> , "pulled in" by internal system packages I've got no direct interest
> in, plus, shockingly, "and 2 more with the same problem" and "and 5
> more with the same problem".

This, and similar conflicts, can be easily resolved by forcing rebuilds
of the packages marked in blue in the conflict tree. I particular, here
it works by running:

# emerge -DNua world --reinstall-atoms "$(qlist -ICS dev-perl/
virtual/perl-)"

I found "reinstall-atoms" to become very handy lately. Emerge seems to
be pretty bad at determining rebuilds of dependents in world upgrades,
even when using big backtrack values. Also, bigger backtrack values
increase deptree calculation by a huge factor, especially when emerge
isn't able to figure it out anyways.

You may want to remove all perl virtuals first, which is essentially
what perl-cleaner also does in a first step:

# emerge -Ca $(qlist -IC virtual/perl-)


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: Pseudo first impressions

[Kai Krakow]

Am Sat, 29 Apr 2017 20:53:50 -0700
schrieb Ian Zimmerman :

> On 2017-04-30 02:23, lee wrote:
> 
> > > Do a --depclean and that will resolve itself.  
> > 
> > Last time I tried that, it wanted to remove the source of the kernel
> > I'm using, along with other things.  It would have made sense if I
> > had upgraded the kernel, too, but I didn't have the time to do that
> > yet.  
> 
> emerge --select =sys-kernel/gentoo-sources-${VERSION}
> 
> or add a line for the exact version to the world file manually

If you give a slot instead of a version, it will record that slot in
the world file, which is usually more appropriate:

# emerge --select sys-kernel/gentoo-sources:${VERSION}

No need to add that manually then.

Kernel versions are slotted per minor version, so it is essentially the
same for your example.

-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: replacement for ftp?

[Kai Krakow]

Am Sat, 29 Apr 2017 20:38:24 +0100
schrieb lee :

> Kai Krakow  writes:
> 
> > Am Tue, 25 Apr 2017 15:29:18 +0100
> > schrieb lee :
> >  
> >> since the usage of FTP seems to be declining, what is a replacement
> >> which is at least as good as FTP?
> >> 
> >> I'm aware that there's webdav, but that's very awkward to use and
> >> missing features.  
> >
> > If you want to sync files between two sites, try rsync. It is
> > supported through ssh also. Plus, it's very fast also.  
> 
> Yes, I'm using it mostly for backups/copies.
> 
> The problem is that ftp is ideal for the purpose, yet users find it
> too difficult to use, and nobody uses it.  So there must be something
> else as good or better which is easier to use and which ppl do use.

Well, I don't see how FTP is declining, except that it is unencrypted.
You can still use FTP with TLS handshaking, most sites should support
it these days but almost none forces correct certificates because it is
usually implemented wrong on the server side (by giving you
ftp.yourdomain.tld as the hostname instead of ftp.hostingprovider.tld
which the TLS cert has been issued for). That makes it rather pointless
to use. In linux, lftp is one of the few FTP clients supporting TLS
out-of-the-box by default, plus it forces correct certificates.

But I found FTP being extra slow on small files, that's why I suggested
to use rsync instead. That means, where you could use sftp (ssh+ftp),
you can usually also use ssh+rsync which is faster.

There's also the mirror command in lftp, which can be pretty fast, too,
on incremental updates but still much slower than rsync.

> I don't see how they would transfer files without ftp when ftp is the
> ideal solution.

You simply don't. FTP is still there and used. If you see something
like "sftp" (ssh+ftp, not ftp+ssl which I would refer to as ftps), this
is usually only ftp wrapped into ssh for security reasons. It just
using ftp through a tunnel, but to the core it's the ftp protocol. In
the end, it's not much different to scp, as ftp is really just only a
special shell with some special commands to setup a file transfer
channel that's not prone to interact with terminal escape sequences in
whatever way those may be implemented, something that e.g. rzsz needs
to work around.

In the early BBS days, where you couldn't establish a second transfer
channel like FTP does it using TCP, you had to send special escape
sequences to put the terminal into file transfer mode, and then send
the file. By that time, you used rzsz from the remote shell to initiate
a file transfer. This is more the idea of how scp implements a file
transfer behind the scenes.

FTP also added some nice features like site-to-site transfers where the
data endpoints both are on remote sites, and your local site only is
the control channel. This directly transfers data from one remote site
to another without going through your local connection (which may be
slow due to the dial-up nature of most customer internet connections).

Also, FTP is able to stream multiple files in a single connection for
transferring many small files, by using tar as the transport protocol,
thus reducing the overhead of establishing a new connection per file.
Apparently, I know only few clients that support that, and even fewer
servers which that would with.

FTP can be pretty powerful, as you see. It's just victim of its poor
implementation in most FTP clients that makes you feel it's mostly
declined. If wrapped into a more secure tunnel (TLS, ssh), FTP is still
a very good choice for transferring files, tho not the most efficient.
Depending on your use case, you get away much better using more
efficient protocols like rsync.


-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: Pseudo first impressions

[R0b0t1]

On Sun, Apr 30, 2017 at 12:14 AM, Kai Krakow  wrote:
> Am Sat, 29 Apr 2017 14:39:13 +
> schrieb Alan Mackenzie :
>
>> For a start, I could barely read parts of it, which were displayed in
>> dark blue text on a black background.  Setting
>> up /etc/portage/color.map is not the first thing a new user should
>> have to do to be able to read messages from emerge.  This is,
>> however, something I knew had to be done, and I did it.
>
> This is a problem with most terminal emulators having a much too dark
> "dark blue". On an old DOS CRT, this dark blue was still bright enough
> to be read easily on black background. Especially, I found PuTTY in
> Windows having a dark blue barely readable.
>
> E.g., in KDE Konsole I usually switch to a different terminal color
> scheme which usually gets around this. But then, contrast on bright
> colors is usually very bad, as can be seen in MC at some points. But
> the new "breeze" color scheme from current Plasma versions is quite
> nice and an overall good fit.
>

I have occasionally had this problem (and the reverse - green and
yellow are unreadable on light backgrounds), but the default colors in
URxvt are fairly reasonable.

Not to derail this thread but what is the process for getting changes
into the handbook? I have some suggestions as well, but still only
have a vague idea of how it is maintained. There's a lot that could be
added in relation to maintaining modern systems, and many of the
changes to portage could be added. (E.g. there's people who will come
into the IRC and have a conglomeration of settings that, based on the
quirks and naming conventions, you can tell were taken from 3-4 places
each being published years apart. There probably needs to be some
basic information all in one place.)


And in reply to the Perl problem, though my response probably isn't
needed: I can verify that using a high backtrack number solved this,
and that the dependency chain was the longest I have seen save one
other time.

[gentoo-user] Re: replacement for ftp?

[Kai Krakow]

Am Sat, 29 Apr 2017 20:30:03 +0100
schrieb lee :

> Danny YUE  writes:
> 
> > On 2017-04-25 14:29, lee  wrote:  
> >> Hi,
> >>
> >> since the usage of FTP seems to be declining, what is a replacement
> >> which is at least as good as FTP?
> >>
> >> I'm aware that there's webdav, but that's very awkward to use and
> >> missing features.  
> >
> > What about sshfs? It allows you to mount a location that can be
> > accessed via ssh to your local file system, as if you are using
> > ssh.  
> 
> Doesn't that require ssh access?  And how do you explain that to ppl
> finding it too difficult to use Filezilla?  Is it available for
> Windoze?

Both, sshfs and scp, require a full shell (that may be restricted but
that involves configuration overhead on the server side). You can use
sftp (FTP wrapped into SSH), which is built into SSH. It has native
support in many Windows clients (most implementations use PuTTY in the
background). It also has the advantage that you can easily restrict
users on your system to SFTP-only with an easy server-side
configuration.

> > Also samba can be a replacement. I have a samba server on my OpenWRT
> > router and use mount.cifs to mount it...  
> 
> Does that work well, reliably and securely over internet connections?

It supports encryption as transport security, and it supports kerberos
for secure authentication, the latter is not easy to setup in Linux,
but it should work with Windows clients out-of-the-box.

But samba is a pretty complex daemon and thus offers a big attack
surface for hackers and bots. I'm not sure you want to expose this to
the internet without some sort of firewall in place to restrict access
to specific clients - and that probably wouldn't work for your scenario.

But you could offer access via OpenVPN and tunnel samba through that.
By that time, you can as easily offer FTP, too, through the tunnel
only, as there should be no more security concerns now: It's encrypted
now. OpenVPN also offers transparent compression which can be a big
plus for your scenario.

OpenVPN is not too difficult to setup, and the client is available for
all major OSes. And it's not too complicated to use: Open VPN
connection, then use your file transfer client as you're used to. Just
one simple extra step.


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: replacement for ftp?

[Kai Krakow]

Am Sat, 29 Apr 2017 20:02:57 +0100
schrieb lee :

> Alan McKinnon  writes:
> 
> > On 25/04/2017 16:29, lee wrote:  
> >> 
> >> Hi,
> >> 
> >> since the usage of FTP seems to be declining, what is a replacement
> >> which is at least as good as FTP?
> >> 
> >> I'm aware that there's webdav, but that's very awkward to use and
> >> missing features.
> >> 
> >>   
> >
> > Why not stick with ftp?  
> 
> The intended users are incompetent, hence it is too difficult to
> use ...

If you incompetent users are using Windows: Have you ever tried
entering ftp://u...@yoursite.tld in the explorer directory input bar?

> > Or, put another way, why do you feel you need to use something
> > else?  
> 
> I don't want to use anything else.
> 
> Yet even Debian has announced that they will shut down their ftp
> services in November, one of the reasons being that almost no one uses
> them.  Of course, their application is different from what I'm looking
> for because they only have downloads and no uploads.

And that's the exact reason why: Offering FTP just for downloads (not
even for browsing) is inefficient. Getting a file via HTTP is much more
efficient as the connection overhead is much lower. Removing FTP is
thus just a question of reducing attack surface and server load.

Your scenario differs a lot and doesn't follow the reasoning debian put
behind it.

> However, another reason given was that ftp isn't exactly friendly to
> firewalls and requires "awkward kludges" when load balancing is used.
> That is a pretty good reason.

This is due to FTP incorporating transfer of ports and IP addresses in
the protocol which was a good design decision when the protocol was
specified but isn't nowadays. Embedding FTP into a tunnel solves that,
e.g. by using sftp (ssh+ftp). HTTP also solves that by not embedding
such information at the protocol level. But tunneling FTP is not how
you would deploy such a scenario, so the option is HTTP, hence FTP can
be shut down by debian. KISS principle.

> Anyway, when pretty much nobody uses a particular software anymore, it
> won't be very feasible to use that software.

Nobody said that when debian announced to shut down their FTP servers.
Debian is not the king to rule the internet. You shouldn't care when
they shut down their FTP services. It doesn't matter to the rest of the
world using the internet.

> > There's always dropbox  
> 
> Well, dropbox sucks.  I got a dropbox link and it didn't work at all,
> and handing out the data to some 3rd party is a very bad idea.  It's
> also difficult to automate things with that.

There's also owncloud (or whatever it is called now). You can automate
things by deploying a sync application on your clients side.


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: replacement for ftp?

[Kai Krakow]

Am Sat, 29 Apr 2017 22:02:51 -0400
schrieb "Walter Dnes" :

>   Then there's always "sneakernet".  To quote Andrew Tanenbaum from
> 1981
> 
> > Never underestimate the bandwidth of a station wagon full of tapes
> > hurtling down the highway.  

Hehe, with the improvements in internet connections nowadays, we
almost stopped transferring backups via sneakernet. Calculating the
transfer speed of the internet connection vs. the speed calculating
miles per hour, internet almost always won lately. :-)

Most internet connections are faster than even USB sticks these days.
LAN connections tailored towards storage are even fast then ordinary
hard disks (i.e. SAN).

Nice fun fact, tho. If go "a station wagon full", it probably still
holds true today.


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: Pseudo first impressions

[Kai Krakow]

Am Sun, 30 Apr 2017 00:56:40 -0500
schrieb R0b0t1 :

> On Sun, Apr 30, 2017 at 12:14 AM, Kai Krakow 
> wrote:
> > Am Sat, 29 Apr 2017 14:39:13 +
> > schrieb Alan Mackenzie :
> >  
> >> For a start, I could barely read parts of it, which were displayed
> >> in dark blue text on a black background.  Setting
> >> up /etc/portage/color.map is not the first thing a new user should
> >> have to do to be able to read messages from emerge.  This is,
> >> however, something I knew had to be done, and I did it.  
> >
> > This is a problem with most terminal emulators having a much too
> > dark "dark blue". On an old DOS CRT, this dark blue was still
> > bright enough to be read easily on black background. Especially, I
> > found PuTTY in Windows having a dark blue barely readable.
> >
> > E.g., in KDE Konsole I usually switch to a different terminal color
> > scheme which usually gets around this. But then, contrast on bright
> > colors is usually very bad, as can be seen in MC at some points. But
> > the new "breeze" color scheme from current Plasma versions is quite
> > nice and an overall good fit.
> >  
> 
> I have occasionally had this problem (and the reverse - green and
> yellow are unreadable on light backgrounds), but the default colors in
> URxvt are fairly reasonable.

Much depends on a reasonable color palette in the terminal emulator.
There are only few that get it right.

> Not to derail this thread but what is the process for getting changes
> into the handbook? I have some suggestions as well, but still only
> have a vague idea of how it is maintained. There's a lot that could be
> added in relation to maintaining modern systems, and many of the
> changes to portage could be added. (E.g. there's people who will come
> into the IRC and have a conglomeration of settings that, based on the
> quirks and naming conventions, you can tell were taken from 3-4 places
> each being published years apart. There probably needs to be some
> basic information all in one place.)

There's the Gentoo wiki. I don't know if you need special privileges or
if it's open to everyone to put in improvements. And then, there's
always the BGO (bugs.gentoo.org) where you can suggest even handbook
improvements by selecting the proper bug component.

> And in reply to the Perl problem, though my response probably isn't
> needed: I can verify that using a high backtrack number solved this,
> and that the dependency chain was the longest I have seen save one
> other time.

Usually, using "reinstall-atoms" works much better for me (and it's
faster in most cases because when emerge dumps all those stuff and I
see it's easily resolvable by reinstall-atoms, I do that, instead of
using a high backtrack value, waiting for ages again, only to see that
it may not solve my problem).


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: ebuild: package specific CFLAGS

[Kai Krakow]

Am Sat, 29 Apr 2017 00:14:10 -0400
schrieb John Covici :

> On Fri, 28 Apr 2017 22:10:42 -0400,
> Ian Zimmerman wrote:
> > 
> > I'm trying to create an ebuild of a crufty old program that needs
> > -fgnu89-inline in compiler flags to have any chance of building.
> > 
> > What's the way to do that in an ebuild?  I could have something like
> > 
> > src_configure() {
> > econf $(use_enable nls) CFLAGS=-fgnu89-inline
> > }
> > 
> > but then, will this not _override_ (rather than add to, as desired)
> > the CFLAGS from make.conf?  
> 
> Maybe you'd be better off setting an environment variable outside the
> ebuild in a shell script in /etc/portage/env where you can put the
> whole CCFLAGS .

You should also say that you need to reference that
in /etc/portage/packages.env, similar to how packages.use works. Just
that instead of use flags, you give filenames from /etc/portage/env.

-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: How to get rid of sys-fs/static-dev, or do I really need it?

[Kai Krakow]

Am Tue, 25 Apr 2017 08:29:51 +0100
schrieb Neil Bothwick :

> On Tue, 25 Apr 2017 01:30:07 +0200, wabe wrote:
> 
> > > Do you have virtual/udev installed? That should be enough to keep
> > > virtual/dev-manager happy.
> > 
> > Thanks for your answer. virtual/udev is already installed. Tomorrow
> > I'll make a backup of my system and after that I'll remove
> > sys-fs/static-dev.  
> 
> I can't see it doing any harm, because any static nodes in /dev/ are
> hidden once udev starts.

It's hidden when devtmpfs is mounted by the kernel. Modern kernels do
this automatically, udev is not involved here. That's probably the
reason why it was removed from the profile. The default options of
gentoo-sources suggest devtmpfs to be enabled and automounted by the
kernel at boot.

-- 
Regards,
Kai

Replies to list-only preferred.


pgpI6PUULNrqL.pgp
Description: Digitale Signatur von OpenPGP