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

2017-05-02 Thread Neil Bothwick 
On Sun, 30 Apr 2017 08:22:50 +0200, Kai Krakow wrote:

> > > 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. :-)

But tapes also hold a lot more than they did in 1981, so bandwidth is
increasing on both sides ;-)


-- 
Neil Bothwick

QOTD:
The only easy way to tell a hamster from a gerbil is that the
gerbil has more dark meat.


pgpZTu80PEPJK.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] How do you get newer version of Arduino?

2017-05-02 Thread R0b0t1 
On Tue, May 2, 2017 at 10:35 AM, Danny YUE  wrote:
> Hi folks,
>
> I am playing around with my arduino board...
> I know there is an official package arduino, but that is way too old.
> So...where do you get the latest version? For example 1.8?
>
> Thanks in advance.
>
> Danny
>

I tend to go for downloading the compressed distribution on the
Arduino website when I need it. It's sometimes necessary to keep
multiple versions of it around, and in some cases keep versions with
mutually exclusive configurations.

Re: [gentoo-user] How do you get newer version of Arduino?

2017-05-02 Thread Neil Bothwick 
On Tue, 02 May 2017 23:35:56 +0800, Danny YUE wrote:

> I am playing around with my arduino board...
> I know there is an official package arduino, but that is way too old.
> So...where do you get the latest version? For example 1.8?

From one of the several overlays that have it.

% eix -Rcn arduino
[N] dev-embedded/arduino ((~)1.8.1[1]): An open-source AVR electronics 
prototyping platform
[N] dev-embedded/arduino-bin ((~)1.8.1[8]): electronics prototyping platform 
based on easy-to-use hardware and software
[N] dev-embedded/arduino-ide ((~)1.8.1[1]): An open-source AVR electronics 
prototyping platform
[N] dev-embedded/arduino-libs ((~)1.8.1[1]): An open-source AVR electronics 
prototyping platform
[N] dev-embedded/arduino-mk [7] ((~)1.3.4): Makefile for Arduino sketches.
[N] dev-ros/rosserial_arduino ((~)0.7.6): Libraries and examples for ROSserial 
usage on Arduino/AVR Platforms
[1] "alexxy" layman/alexxy
[2] "benklop" layman/benklop
[3] "fkmclane" layman/fkmclane
[4] "pypy_alice" layman/pypy_alice
[5] "ssnb" layman/ssnb
[6] "TAJJADA" layman/TAJJADA
[7] "vaca" layman/vaca
[8] "vifino-overlay" layman/vifino-overlay


-- 
Neil Bothwick

.<-Stealth Tagline


pgpqBpXgRkpgD.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Inconsistent behavior in my Gentoo OS instance

2017-05-02 Thread Raffaele Belardi 

Miroslav Rovis wrote:

gzip apparently inconsistent behavior occupies the most part of the report on
inconsistencies here (esp. the script make_gzip_archives_consistent.sh).


Checked on my system, same behaviour, looking inside the gzip file you see why. I used 
shed but strings is easier:


$  strings eix-installed-after_1.gz
eix-installed-after_1
...

$ strings eix-installed-after_2.gz
eix-installed-after_2
...

gzip stores the filename in the compressed file so the files differ.

But you get different results even if you use the same file name, so digging into the file 
format (e.g. http://www.zlib.org/rfc-gzip.html#file-format) you find that gzip stores the 
MTIME (Modification TIME) in the file header, so even equally-named files will also differ.


HTH, I did not have the time to go through your long email completely.

raffaele

[gentoo-user] Re: gtk+-2.x, adwaita, gsettings and all that

2017-05-02 Thread Ian Zimmerman 
On 2017-05-02 00:32, Jonathan Callen wrote:

> To set the GTK-2 theme, edit the file ~/.gtkrc-2.0, and add lines
> like:
> 
> gtk-theme-name = "Raleigh"
> gtk-icon-theme-name = "hicolor"
> gtk-cursor-theme-name = ""

This worked, thanks.  Some icons _are_ different but I suppose that's
because the default ones built into gtk itself changed, and I'm not
going to hold up the update because of that.

-- 
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] Inconsistent behavior in my Gentoo OS instance

2017-05-02 Thread Miroslav Rovis 
On 170502-17:51+0200, Raffaele Belardi wrote:
> Miroslav Rovis wrote:
> > On 170502-10:33+0200, Raffaele Belardi wrote:
> >> Miroslav Rovis wrote:
> >>> gzip apparently inconsistent behavior occupies the most part of the 
> >>> report on
> >>> inconsistencies here (esp. the script make_gzip_archives_consistent.sh).
> >>
> >> Checked on my system, same behaviour, looking inside the gzip file you see 
> >> why. I used
> >> shed but strings is easier:
> >>
> >> $  strings eix-installed-after_1.gz
> >> eix-installed-after_1
> >> ...
> >>
> >> $ strings eix-installed-after_2.gz
> >> eix-installed-after_2
> >> ...
> >>
> >> gzip stores the filename in the compressed file so the files differ.
> >
> > No, it doesn't, on my system. Did you really check the files:
> > https://lists.gt.net/engine?do=post_attachment;postatt_id=51651;list=gentoo
> > https://lists.gt.net/engine?do=post_attachment;postatt_id=51652;list=gentoo
> > (these should download as eix-installed-after_1.gz former and 
> > eix-installed-after_2.gz the latter)?
> >
> > And they have these SHA256:
> >
> > fff6f3f0f07c863fee6962379f063f742578569fd13fcee3df9161b4a6d99aa7  
> > eix-installed-after_1.tar.gz
> > b88cd07885fbdc2235c9c64be7d02aa9ace7661cc2fce07909355e369366b408  
> > eix-installed-after_2.tar.gz
> >
> > If you did check those files, and there are the strings you say, at what
> > byte, the start, and the end... Really don't know how you got that...
> 
> I did not use your files, I re-generated them on my system based on the 
> /usr/bin/eix-installed-after installed on my system, as you suggested. The 
> command I used 
> was plain gzip, not tar, since the difference in the files appears to come 
> from the gzip 
> execution.
which then is not dealing with the same issue.

> I just checked your files:
> 
> $ cmp -bl gzip_buggy.txt_1.tar.gz gzip_buggy.txt_2.tar.gz
>5   7 ^G12 ^J
Didn't know about cmp. Thanks for a fine example! But cmp found the same
which I found upon visual inspecting with hexdump, and which differences
(but it was a futile non-necessary exercize) I removed with the script I
gave in the first email.

> They differ in byte 5 which, according to the link I posted, is inside the 
> MTIME field. 
> Looks to me that this gzip issue is a non-issue.
Yes, and thanks for the confirmation.

> Regarding the other issues, maybe someone else will have the time to go 
> through the 
> complete email, even the abridged one you re-sent is too much for me. Or 
> maybe if you 
> could concentrate on one issue at a time only...
> 
> raffaele

It is now (likely) only two (2) issues left to go of the four (4) there from the
abridged email, because I got a reply for another issue in the meantime.

But sadly more trouble looming with my system (looks actually from
a bigger subject, the first onw on the way and it's shadow)...

Regards!
-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr


signature.asc
Description: Digital signature

Re: [gentoo-user] Inconsistent behavior in my Gentoo OS instance

2017-05-02 Thread Miroslav Rovis 
On 170502-22:19-0400, Bobby Kent wrote:
> Regarding the fourth issue:
> > g0n ~ # eix memtest86+
> > * sys-apps/memtest86
> >  Available versions:  4.3.7 (~)4.3.7-r1 {serial}
> >  Homepage:http://www.memtest86.com/
> >  Description: A stand alone memory test for x86 computers
> ...
> > 
> > Found 2 matches
> > Received SIGSEGV - you probably found a bug in eix.
> ...
> > Anyone else gets this too?

This below is a nice catch:
> Not here (note the results of your "eix memtest86+" appears to be a match
> for " eix memtest86" on my system):
> 
> # eix memtest86+
> [I] sys-apps/memtest86+
>  Available versions:  2.01^t 4.00^t 4.20-r1 ~4.20-r3 5.01-r2 ~5.01-r3
> {floppy iso serial}
>  Installed versions:  5.01-r2(11:23:03 AM 03/18/2017)(-floppy -iso
> -serial)
>  Homepage:http://www.memtest.org/
>  Description: Memory tester based on memtest86
> 
> # eix memtest86
> * sys-apps/memtest86
>  Available versions:  4.3.7 ~4.3.7-r1 {serial}
>  Homepage:http://www.memtest86.com/
>  Description: A stand alone memory test for x86 computers
> 
> [I] sys-apps/memtest86+
>  Available versions:  2.01^t 4.00^t 4.20-r1 ~4.20-r3 5.01-r2 ~5.01-r3
> {floppy iso serial}
>  Installed versions:  5.01-r2(11:23:03 AM 03/18/2017)(-floppy -iso
> -serial)
>  Homepage:http://www.memtest.org/
>  Description: Memory tester based on memtest86
> 
> Found 2 matches
> #
If you look up my first email, I do have both memtest86+ and memtest86
like you, and I do have the same versions available as you

so I just wrongly abrdidged that second email. Sorry.

But you don't have my issue with eix. Thanks for reporting.

Two issues left to go of the ones I presented (and there are more, in
slow time). The Wireshark and the Bash.

Regards!
-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr


signature.asc
Description: Digital signature

Re: [gentoo-user] Can not compile arduino sketch after GCC upgrade

2017-05-02 Thread Dan Johansson 
On 30.04.2017 13:23, Dan Johansson wrote:
> After upgrading GCC to 5.4.0 (from 4.9.3) I can no longer compile my
> sketches.
> 
> At the end of the compile phase a get the following linker error:
> 
> avr-gcc -Os -Wl,--gc-sections -mmcu=atmega32u4 -o
> /tmp/build881550966608502477.tmp/Blinky.cpp.elf
> /tmp/build881550966608502477.tmp/Blinky.cpp.o
> /tmp/build881550966608502477.tmp/FastLED313/hsv2rgb.cpp.o
> /tmp/build881550966608502477.tmp/FastLED313/wiring.cpp.o
> /tmp/build881550966608502477.tmp/FastLED313/colorutils.cpp.o
> /tmp/build881550966608502477.tmp/FastLED313/colorpalettes.cpp.o
> /tmp/build881550966608502477.tmp/FastLED313/lib8tion.cpp.o
> /tmp/build881550966608502477.tmp/FastLED313/FastLED.cpp.o
> /tmp/build881550966608502477.tmp/FastLED313/bitswap.cpp.o
> /tmp/build881550966608502477.tmp/FastLED313/power_mgt.cpp.o
> /tmp/build881550966608502477.tmp/FastLED313/noise.cpp.o
> /tmp/build881550966608502477.tmp/core.a
> -L/tmp/build881550966608502477.tmp -lm
> /usr/libexec/gcc/avr/ld: cannot find crtatmega32u4.o: No such file or
> directory
> /usr/libexec/gcc/avr/ld: cannot find -latmega32u4
> collect2: error: ld returned 1 exit status
> 
> And sure enough, there is not "crtatmega32u4.o" on this system (and only
> one file with "atmega32u4" in the filename:
> /usr/lib64/gcc/avr/5.4.0/device-specs/specs-atmega32u4).
> 
> I have tried to reinstall the avr-crossdev-toolchain:
> crossdev -C avr
> USE="-openmp -hardened -sanitize -vtv" crossdev -s4 -S --target avr
> ln -s /usr/lib64/binutils/avr/2.26.1/ldscripts /usr/avr/lib/ldscript
> 
> 
> And just to be sure I have also re-emerged:
> dev-embedded/avrdude
> dev-embedded/arduino
> 
> Any suggestions what I am missing?
> 

With last nights sync, avr-gcc-4.9.4 was pulled back in (slotted).

Selecting 4.9.4 instead of 5.4.0 solves the issue, I can now compile for
avr again:

$ avr-gcc -Os -Wl,--gc-sections -mmcu=atmega32u4 test.c

$ file a.out
a.out: ELF 32-bit LSB executable, Atmel AVR 8-bit, version 1 (SYSV),
statically linked, not stripped

-- 
D/\N
***
This message is printed on 100% recycled electrons!
***

RE: [gentoo-user] Inconsistent behavior in my Gentoo OS instance

2017-05-02 Thread Bobby Kent 
Regarding the fourth issue:
> g0n ~ # eix memtest86+
> * sys-apps/memtest86
>  Available versions:  4.3.7 (~)4.3.7-r1 {serial}
>  Homepage:http://www.memtest86.com/
>  Description: A stand alone memory test for x86 computers
...
> 
> Found 2 matches
> Received SIGSEGV - you probably found a bug in eix.
...
> Anyone else gets this too?

Not here (note the results of your "eix memtest86+" appears to be a match
for " eix memtest86" on my system):

# eix memtest86+
[I] sys-apps/memtest86+
 Available versions:  2.01^t 4.00^t 4.20-r1 ~4.20-r3 5.01-r2 ~5.01-r3
{floppy iso serial}
 Installed versions:  5.01-r2(11:23:03 AM 03/18/2017)(-floppy -iso
-serial)
 Homepage:http://www.memtest.org/
 Description: Memory tester based on memtest86

# eix memtest86
* sys-apps/memtest86
 Available versions:  4.3.7 ~4.3.7-r1 {serial}
 Homepage:http://www.memtest86.com/
 Description: A stand alone memory test for x86 computers

[I] sys-apps/memtest86+
 Available versions:  2.01^t 4.00^t 4.20-r1 ~4.20-r3 5.01-r2 ~5.01-r3
{floppy iso serial}
 Installed versions:  5.01-r2(11:23:03 AM 03/18/2017)(-floppy -iso
-serial)
 Homepage:http://www.memtest.org/
 Description: Memory tester based on memtest86

Found 2 matches
#

Re: [gentoo-user] Inconsistent behavior in my Gentoo OS instance

2017-05-02 Thread Miroslav Rovis 
On 170502-10:33+0200, Raffaele Belardi wrote:
> Miroslav Rovis wrote:
> > gzip apparently inconsistent behavior occupies the most part of the report 
> > on
> > inconsistencies here (esp. the script make_gzip_archives_consistent.sh).
> 
> Checked on my system, same behaviour, looking inside the gzip file you see 
> why. I used 
> shed but strings is easier:
> 
> $  strings eix-installed-after_1.gz
> eix-installed-after_1
> ...
> 
> $ strings eix-installed-after_2.gz
> eix-installed-after_2
> ...
> 
> gzip stores the filename in the compressed file so the files differ.

No, it doesn't, on my system. Did you really check the files:
https://lists.gt.net/engine?do=post_attachment;postatt_id=51651;list=gentoo
https://lists.gt.net/engine?do=post_attachment;postatt_id=51652;list=gentoo
(these should download as eix-installed-after_1.gz former and 
eix-installed-after_2.gz the latter)?

And they have these SHA256:

fff6f3f0f07c863fee6962379f063f742578569fd13fcee3df9161b4a6d99aa7  
eix-installed-after_1.tar.gz
b88cd07885fbdc2235c9c64be7d02aa9ace7661cc2fce07909355e369366b408  
eix-installed-after_2.tar.gz

If you did check those files, and there are the strings you say, at what
byte, the start, and the end... Really don't know how you got that...

> But you get different results even if you use the same file name, so digging 
> into the file 
> format (e.g. http://www.zlib.org/rfc-gzip.html#file-format) you find that 
> gzip stores the 
> MTIME (Modification TIME) in the file header, so even equally-named files 
> will also differ.
> 
> HTH, I did not have the time to go through your long email completely.
> 
> raffaele

And for easier insight into this plight of mine with these
inconsistencies/issues, I am about to send another, I hope much clearer
email --but no gzip issue in the new email, if gzip to discuss, pls,
this sub-thread should better be used--  I resend a different email
because I need the old quotes, removed in your reply...

Thanks for caring!

-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr


signature.asc
Description: Digital signature

Re: [gentoo-user] Inconsistent behavior in my Gentoo OS instance

2017-05-02 Thread Miroslav Rovis 
I've received one reply, and thanks again, but I had better remove the
gzip-"inconsistency" related bloat from my own previous email... I need the
previous text to make the remaining three important
parts/issues/inconsistencies clearer and easier to check, and reply to,
any of the three.

I will also reorder my quotes to get them easier to skip or skip to,
since they are separate issues/inconsistencies.

On 170501-18:17+0200, Miroslav Rovis wrote:
...
First issue
===
(All first issue-related text have been removed here from all quotes
from my previous message)
...

Second issue

> Another part is actually on Wireshark mailing list. Pls. see:
> 
> Filtering on (negated) frame.time_relative filters out wrong frame.number
> https://www.wireshark.org/lists/wireshark-users/201704/msg00037.html
> as well as my study at:
> https://www.croatiafidelis.hr/foss/cap/cap-170313-git-devuan-mail/git-devuan-mail-4.php
That page has just been updated with clearer instructions.

> (and the previous ones there, but I gave the last as it is simplest/fastest 
> to check)
> 
> There is information that any advanced reader can easily provide by retracing
> some of my steps there, and which would clear some uncertainties here.
...
> ... That's a serious bug or a
> serious malfunction in my Gentoo, the latter being most likely...
> 
> And if it is the latter, it can only be one or the other way. One: the cause
> is in some Gentoo packge. Two: it is an attack by some unknown means.
> 
> (
> If Air-Gapped is some info, I did try and editcap (and the whole
> Wireshark) behave in the same wrong way in my Air-Gapped too.
> ...
> )
> 


Third issue
==

The text it too much because the command line in which bash throw
strange error is a long for loop. The main point is marked with short new
text below.
> This is one of a series of commands that I used to check one of the backups,
> in three different instances of tar-gzip'd archive I checked (such as the
> /root directory tar-gzip'd today), and which showed faultless upon
> decompression in all the three instances, despite the three instances of
> tar-gzip'd archives not being identical (as their SHA256 sums show):
> 
> # for i in $(ls -1d root_170430_g0n*.d/); do sum=$(echo $i|sed 
> 's/\.d\//\.sum/'); echo $sum ; read FAKE ; j=$(echo $i | sed 
> 's/\.d\//\.tar.gz/'); ls -l $j $i ; cd $i; pwd ; read FAKE ; for file in 
> $(find ./ -name '*'); do if [ -f "$file" ]; then sha256sum $file >> ../$sum ; 
> fi; done ; cd - ; done ;
> 
> Now if I just place the cursor, by moving with Alt-F (skipping "words") and 
> Ctrl-F (skipping  1 char) to just after:
> 
> "for i in $(ls -1d root_170430_g0n*.d/" in that command,
> 
> and if I then hit Tab for completion on the experssion there, I get (and I'm
> sorry for the mess, but that's what I get):
> 
> g0n ~ # for i in $(ls -1d root_170430_g0n*.dbash: unexpected EOF while 
> looking for matching `)'bash: syntax error: unexpected end of 
> file//\.tar.gz/'); ls -l $j $i ; cd $i; pwd ; read FAKE ; for file in $(find 
> ./ -name '*'); do if [ -f "$file" ]; then sha256sum $file >> ../$sum ; fi; 
> done ; cd - ; done ;
> 
> NOTE (at proofreading time): rechecked, I do get that same behavior the day
> after (wrote most of this yesterday, still to send this morning).
> 
> [[
> NOTE (before delayed sending): In fact, it is only this clone that exibits the
> above Bash malfunctioning. I just checked the same for loop command (some six
> paragraphs above) in my Air-Gapped master [1] (never any internet it sees,
The [1] is important for understanding, especially this Bash issue in my
Gentoo instance.
Because in my Air-Gapped Gentoo instance that issue does not show at
all.
> longer workaround/detailed checking before updating it with stuff from
> internet, sneakernet or optical media), and it is just fine. That line, simply
> gave what it should:
> 
> # for i in $(ls -1d root_170430_g0n*.d/); do sum=$(echo $i|sed 
> 's/\.d\//\.sum/'); echo $sum ; read FAKE ; j=$(echo $i | sed 
> 's/\.d\//\.tar.gz/'); ls -l $j $i ; cd $i; pwd ; read FAKE ; for file in 
> $(find ./ -name '*'); do if [ -f "$file" ]; then sha256sum $file >> ../$sum ; 
> fi; done ; cd - ; done 
> root_170430_g0n_1.d// root_170430_g0n_2.d// root_170430_g0n.d//   
> # [[and the same command line was back here]]
> 
> under exact same conditions/circumstances as the clone of my Air-Gapped. And
> it's similar with some other completion issues: they seem non-existent in my
> Air-Gapped.
> ]]

This is the main point (in my clone that I use for online):
> IOW, first, Bash sullied the entire line, which is not very considerate of
> Her, and second that's not some usual error. Just for clarity, it wrote this:
> 
The error:
> bash: unexpected EOF while looking for matching `)'bash: syntax error: 
> unexpected end of file
> 
> (and it wrote it by overwriting, which I never used to see in Bash)
  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  
  |  |  |  |  |  |  |  |  |  |  |  | 
Anyone else

Re: [gentoo-user] How do you get newer version of Arduino?

2017-05-02 Thread Jigme Datse Rasku 
I think standard way is to create a new ebuild.  I did that with the Plex
overlay, trying to clean up the old version.

If you do get it working, let the maintainers know, and they can update it
officially...

On May 2, 2017 08:38, "Danny YUE"  wrote:

Hi folks,

I am playing around with my arduino board...
I know there is an official package arduino, but that is way too old.
So...where do you get the latest version? For example 1.8?

Thanks in advance.

Danny

[gentoo-user] How do you get newer version of Arduino?

2017-05-02 Thread Danny YUE 
Hi folks,

I am playing around with my arduino board...
I know there is an official package arduino, but that is way too old.
So...where do you get the latest version? For example 1.8?

Thanks in advance.

Danny

Re: [gentoo-user] Inconsistent behavior in my Gentoo OS instance

2017-05-02 Thread Raffaele Belardi 

Miroslav Rovis wrote:

On 170502-10:33+0200, Raffaele Belardi wrote:

Miroslav Rovis wrote:

gzip apparently inconsistent behavior occupies the most part of the report on
inconsistencies here (esp. the script make_gzip_archives_consistent.sh).


Checked on my system, same behaviour, looking inside the gzip file you see why. 
I used
shed but strings is easier:

$  strings eix-installed-after_1.gz
eix-installed-after_1
...

$ strings eix-installed-after_2.gz
eix-installed-after_2
...

gzip stores the filename in the compressed file so the files differ.


No, it doesn't, on my system. Did you really check the files:
https://lists.gt.net/engine?do=post_attachment;postatt_id=51651;list=gentoo
https://lists.gt.net/engine?do=post_attachment;postatt_id=51652;list=gentoo
(these should download as eix-installed-after_1.gz former and 
eix-installed-after_2.gz the latter)?

And they have these SHA256:

fff6f3f0f07c863fee6962379f063f742578569fd13fcee3df9161b4a6d99aa7  
eix-installed-after_1.tar.gz
b88cd07885fbdc2235c9c64be7d02aa9ace7661cc2fce07909355e369366b408  
eix-installed-after_2.tar.gz

If you did check those files, and there are the strings you say, at what
byte, the start, and the end... Really don't know how you got that...


I did not use your files, I re-generated them on my system based on the 
/usr/bin/eix-installed-after installed on my system, as you suggested. The command I used 
was plain gzip, not tar, since the difference in the files appears to come from the gzip 
execution.


I just checked your files:

$ cmp -bl gzip_buggy.txt_1.tar.gz gzip_buggy.txt_2.tar.gz
  5   7 ^G12 ^J

They differ in byte 5 which, according to the link I posted, is inside the MTIME field. 
Looks to me that this gzip issue is a non-issue.


Regarding the other issues, maybe someone else will have the time to go through the 
complete email, even the abridged one you re-sent is too much for me. Or maybe if you 
could concentrate on one issue at a time only...


raffaele

[gentoo-user] xen-tools-4.8.1.ebuild pulling in old ovmf.bin

2017-05-02 Thread Håkon Alstadheim 
I have a problem where xen hvm guests using ovmf (efi) as "bios" will
not read efi variables stored in /NvVars. I believe that may
be a known bug in old versions of tianocore.

Building xen-tools-4.8.1 now, and I notice that the ebuild still has
OVMF_PV=20151110 . Tried building a newer one myself for 4.8.0 by
pulling the sources that are referred to in the upstream makefile.
However, I can't seem to get it to boot :-/, never mind getting the
ebuild to make it.

Is there any hope that the ebuild might be updated with newer ovmf source ?

[gentoo-user] Re: replacement for ftp?

2017-05-02 Thread Ian Zimmerman 
On 2017-05-02 09:05, Neil Bothwick wrote:

>> miles per hour, internet almost always won lately. :-)

> But tapes also hold a lot more than they did in 1981

And so do trucks :-(

-- 
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] Re: replacement for ftp?

2017-05-02 Thread Poison BL. 
On Tue, May 2, 2017 at 12:01 PM, Ian Zimmerman  wrote:

> On 2017-05-02 09:05, Neil Bothwick wrote:
>
> >> miles per hour, internet almost always won lately. :-)
>
> > But tapes also hold a lot more than they did in 1981
>
> And so do trucks :-(
>
> --
> 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
>
>
Not just trucks loaded with tapes... trucks loaded full of MicroSD cards
are getting downright silly, density-wise... and the bandwidth of that
running down a highway still wins.

-- 
Poison [BLX]
Joshua M. Murphy