Re: [gentoo-user] Guidance on using Gentoo to clone a Win 10 system drive

[Michael Jones]

On Wed, Jan 8, 2020 at 1:01 AM Wols Lists  wrote:

> On 06/01/20 19:55, Michael Jones wrote:
> >
> > As for windows 10 licensing, don't trust me on this blindly, but your
> > license should be tied to the hardware fingerprint of the laptop. So
> > even installing windows fresh on your new SSD should result in Windows
> > activating automatically. In fact, you might want to take this
> > opportunity to try that out, to get a completely fresh installation
> > without the decade of old cruft built up by window's lack of a package
> > manager.
>
> Two points with this - firstly if (like me) you DON'T have an MS
> account, this fingerprint is not stored anywhere so that won't work.
> Secondly, the fingerprint is likely stored on the hard drive somewhere
> so if you clone the hard drive you are hopefully good, and thirdly it's
> possible that the new hard drive will break the fingerprint so you're
> SOL whatever you do. However, in that last case, if you ring the
> licencing help line they MAY give you a new code because it is, still,
> technically the same laptop.
>
> Cheers,
> Wol
>
>
I don't mean to continue the windows discussion on the gentoo list, but I
wanted to point out that this is incorrect

I don't have a microsoft account at all, and regularly reactivate Windows
10 Home / Pro using the hardware fingerprint method using completely clean
installations on factory-new harddrives with existing hardware. The
fingerprint is stored on Microsoft's activation servers somewhere. I don't
know how it works beyond that it's not required that you have a Microsoft
account to use it.

Re: [gentoo-user] Guidance on using Gentoo to clone a Win 10 system drive

[Wols Lists]

On 06/01/20 23:37, Mark Knecht wrote:
> Michael,
>I got Win 10 Pro installed via the M$ tool that creates USB install
> devices. It worked fine. Reading online it seems that if M$ sees the new
> disk as still the same 'hardware' then it's supposed to automatically
> validate and I'd be good to go. so far, after 2 hours it hasn't done
> that but I'll give it awhile and see what happens. As it only took an
> hour I might still try the disk copy path and see if that comes up
> validated as that would also transfer the couple of applications I have
> on the original hard drive.
> 
>Anyway, thanks for the ideas.
> 
A few more ideas from my experience -

Have you ever re-installed windows and actually used the licence key
that came with the laptop? No? Then try a clean install of Win10 using
the Win7 key.

Nearly all regular computers come with a bulk licence install, and the
key that is actually on the sticker is usually completely unused. If you
try to install Win10 with a Win7 key that has never been used, it will
activate. That's how I did a clean install on my laptop. (And it's
certainly true of Office, maybe of Win also - if you give it a key, it
will install the version that matches the key.)

Or just buy a key from Amazon. I think I paid about £15 and had
absolutely no trouble. I've bought a bunch of Win and Office keys off
Amazon at between £10 and £20 and they've all installed no problem
whatsoever. (Thanks to an EU legal ruling, MS cannot block the sale of
2nd-hand licence keys ...)

The last route, if you want to clean as much cruft as you can, is to do
a "factory reset" of the laptop, and then upgrade to Win10 over it.
Okay, it's not a completely clean install, but it gets you as close as
possible to a clean OEM install.

Cheers,
Wol

Re: [gentoo-user] Guidance on using Gentoo to clone a Win 10 system drive

[Wols Lists]

On 06/01/20 19:55, Michael Jones wrote:
> 
> As for windows 10 licensing, don't trust me on this blindly, but your
> license should be tied to the hardware fingerprint of the laptop. So
> even installing windows fresh on your new SSD should result in Windows
> activating automatically. In fact, you might want to take this
> opportunity to try that out, to get a completely fresh installation
> without the decade of old cruft built up by window's lack of a package
> manager.

Two points with this - firstly if (like me) you DON'T have an MS
account, this fingerprint is not stored anywhere so that won't work.
Secondly, the fingerprint is likely stored on the hard drive somewhere
so if you clone the hard drive you are hopefully good, and thirdly it's
possible that the new hard drive will break the fingerprint so you're
SOL whatever you do. However, in that last case, if you ring the
licencing help line they MAY give you a new code because it is, still,
technically the same laptop.

Cheers,
Wol

Re: [gentoo-user] Netgear AC1750 C7 V2 and IPv6

[Dale]

Dale wrote:
> Howdy,
>
> <<< SNIP >>>
> Does this look like a upstream problem with my ISP or am I missing some
> setting somewhere?  If you need additional info, let me know.  The
> changes I made in IP numbers should be the same whether it's the modem,
> router or puter.  I tried to match them up and only change enough to
> make tracking hard.
>
> Thanks much.
>
> Dale
>
> :-)  :-)
>


If no one here has any ideas on this thing, it has to be serious.  I'm
thinking it is a upstream thing because someone on this list would know
it if was something on my end.  ;-)

@Peter, link helped me understand a bit but still can't figure out my
problem.  The extra info was good tho. 

Dale

:-)  :-) 

P. S.  On the SMR drive thing, I came up with a plan.  After I finish my
backups, I leave it on for a bit mounted, then unmount and leave it on a
little while longer before powering it off.  That way I know it has
finished doing what it needs to.  Plus it gives the SMART stuff time to
do a little work too. 

Re: [gentoo-user] Guidance on using Gentoo to clone a Win 10 system drive

[Daniel Frey]

On 1/7/20 8:58 AM, Mark Knecht wrote:



On Tue, Jan 7, 2020 at 4:52 AM Mick > wrote:

>
> This is getting a tad O/T, since we're talking about activation of a 
non-

> Gentoo OS, but here it goes:
>

I completely agree. I wasn't expecting the conversation to go this 
direction when I posted. I'm happy to participate if others want to.


> On Tuesday, 7 January 2020 00:39:19 GMT Mark Knecht wrote:
>
> >    I'm going to let the machine sit overnight and see if it activates
> > automatically.
>
> It should activate as long as it is connected to the Internet, but 
there are
> two different ways of activating Windows 10 manually, should you not 
do so

> during the installation procedure.
>

After maybe 16 hours it didn't activate but logically I don't know why 
it would have. I've installed Win 10 using the M$ install tool writing 
to a USB flash drive but I'm not given any product IDs/Keys. M$ would 
have had to determine on their own with no help from me this was a 
reinstall and generously activated it which I think is asking too much.


Owing that I'm not 100% sure the previous install was actually Win 10 
Pro, having updated from Win 7 with their free conversion to Win 10, 
I'm going to put the old drive back in, double check what version of 
Win 10 I was using and then try again if I installed the wrong version 
this time.


On a more Linux note I'll build a bootable USB drive with clonezilla 
and see about cloning the old drive to the new SDD that way. that sort 
of solution is why I posted here in the first place. Trying the Win 10 
install and hoping it worked was just an easy 1-day experiment.


Thanks all,
Mark

P.S. - I'd love to get back to running Gentoo one of these days. For 
those of us that wanted a stable machine with just a couple of testing 
packages, especially as the machines become older and the software 
becomes larger, it just became too many hours building code, 
especially on these older laptops. Kubuntu has worked well enough for 
me be there's no better community that you here at gentoo-user for 
straight forward technical discussion and I want to thank everyone 
here for years and years of good times and good information.



As mentioned earlier you need your Windows 7 key for activation. If you 
have to reenter the key sometimes the Windows UI is dubious and doesn't 
offer a clear-cut way to do this. To get around it, open Powershell and 
use `slmgr /ipk ` to install the key you have.


Dan

Re: [gentoo-user] Guidance on using Gentoo to clone a Win 10 system drive

[Mick]

I'll keep going with this, because there is a Gentoo twist at the end!  LOL!

On Tuesday, 7 January 2020 16:58:43 GMT Mark Knecht wrote:

> After maybe 16 hours it didn't activate but logically I don't know why it
> would have. I've installed Win 10 using the M$ install tool writing to a
> USB flash drive but I'm not given any product IDs/Keys. M$ would have had
> to determine on their own with no help from me this was a reinstall and
> generously activated it which I think is asking too much.

The (re)activation process does not work like you assume.  Your MS Product key 
would have been provided with the original (Windows 7) installation media, a 
sticker under the laptop, your laptop's OEM box/activation card, or the 
MSWindows Online Shop.  If you do not possess this key you cannot readily 
(re)activate the installation.

You could call Microsoft Support to ask for your key since this is a legit 
installation, but as the key is still in the original disk, boot into the old 
disk and use some of the methods mentioned here to extract it:

https://www.howtogeek.com/206329/how-to-find-your-lost-windows-or-office-product-keys/


> Owing that I'm not 100% sure the previous install was actually Win 10 Pro,
> having updated from Win 7 with their free conversion to Win 10, I'm going
> to put the old drive back in, double check what version of Win 10 I was
> using and then try again if I installed the wrong version this time.

Yes, the Product key or Digital License can only be reused on the same Windows 
10 edition as the original.  If not you'll get some error pointing to the fact 
your key is not suitable for the edition of the OS you are trying to activate.


> On a more Linux note I'll build a bootable USB drive with clonezilla and
> see about cloning the old drive to the new SDD that way. that sort of
> solution is why I posted here in the first place. Trying the Win 10 install
> and hoping it worked was just an easy 1-day experiment.

That could be the easiest way without having to fight your way through the 
Windows Activation Process.  On the other hand, if you manage to re-activate 
it, you'll know how to go about it next time you reinstall - this is MSWindows 
after all!  ;-)


> P.S. - I'd love to get back to running Gentoo one of these days. For those
> of us that wanted a stable machine with just a couple of testing packages,
> especially as the machines become older and the software becomes larger, it
> just became too many hours building code, especially on these older
> laptops. Kubuntu has worked well enough for me be there's no better
> community that you here at gentoo-user for straight forward technical
> discussion and I want to thank everyone here for years and years of good
> times and good information.

Have a search for 'chroot' and 'cross-compiling' on Gentoo wiki & forums.  
There should be a few articles explaining how to cross-compile binary packages 
within a chrooted directory on a faster/bigger/better PC and then rsync and 
emerge these packages with '--usepkg y', or '--usepkgonly y' on the slower 
laptop.  As far as the laptop is concerned, this last part ought to be almost 
as fast as updating/installing binary packages on Kubuntu.  This is probably 
the only way to install really large compiled applications like Chromium, 
LibreOffice, etc. on old PCs with very low RAM.

-- 
Regards,
Mick

Re: [gentoo-user] Guidance on using Gentoo to clone a Win 10 system drive

[Mark Knecht]

On Tue, Jan 7, 2020 at 4:52 AM Mick  wrote:
>
> This is getting a tad O/T, since we're talking about activation of a non-
> Gentoo OS, but here it goes:
>

I completely agree. I wasn't expecting the conversation to go this
direction when I posted. I'm happy to participate if others want to.

> On Tuesday, 7 January 2020 00:39:19 GMT Mark Knecht wrote:
>
> >I'm going to let the machine sit overnight and see if it activates
> > automatically.
>
> It should activate as long as it is connected to the Internet, but there
are
> two different ways of activating Windows 10 manually, should you not do so
> during the installation procedure.
>

After maybe 16 hours it didn't activate but logically I don't know why it
would have. I've installed Win 10 using the M$ install tool writing to a
USB flash drive but I'm not given any product IDs/Keys. M$ would have had
to determine on their own with no help from me this was a reinstall and
generously activated it which I think is asking too much.

Owing that I'm not 100% sure the previous install was actually Win 10 Pro,
having updated from Win 7 with their free conversion to Win 10, I'm going
to put the old drive back in, double check what version of Win 10 I was
using and then try again if I installed the wrong version this time.

On a more Linux note I'll build a bootable USB drive with clonezilla and
see about cloning the old drive to the new SDD that way. that sort of
solution is why I posted here in the first place. Trying the Win 10 install
and hoping it worked was just an easy 1-day experiment.

Thanks all,
Mark

P.S. - I'd love to get back to running Gentoo one of these days. For those
of us that wanted a stable machine with just a couple of testing packages,
especially as the machines become older and the software becomes larger, it
just became too many hours building code, especially on these older
laptops. Kubuntu has worked well enough for me be there's no better
community that you here at gentoo-user for straight forward technical
discussion and I want to thank everyone here for years and years of good
times and good information.

Re: [gentoo-user] Stable Python package changes USE flags with ~amd64

[Franz Fellner]

OK, seems I can reproduce (had an issue with my config in a previous
attempt).
Probably related:
https://bugs.gentoo.org/491166
But your view on the matter isn't correct.
Portage is strict when it comes to dependencies. Just because py3_7 is
installed it won't enable the PYTHON_TARGET because you might uninstall
python-3.7 and end up with a broken olefile.
What actually seems to happen: python3_7 (together with other)
PYTHON_TARGETS is disabled in the profile via use.stable.mask.
That config file disables certain USE-Flags for stable packages. That way
py3_7 is available for testing versions but not for stable ones.
olefile-0.46 is only available as stable version. But now adding it to
package.accept_keywords automagically seems to enable those
use.stable.mask'ed USE-Flags.
IMO this is a bug as it introduces totally unpredictable (and AFAICS
undocumented) behaviour.

Let's see what the DEVs say about this!

Regards
Franz

Am Di., 7. Jan. 2020 um 18:27 Uhr schrieb Mickaël Bucas :

> I get the following result:
> # emerge -pv1 olefile
>
>
> These are the packages that would be merged, in order:
> Calculating dependencies... done!
> [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
> PYTHON_TARGETS="python2_7 python3_6 (-pypy3) (-python3_7*) (-python3_8)" 0
> KiB
> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>
> It seems to be in line with the interpretation I've come up with.
>
> Best regards
> Mickaël Bucas
>
> Le mar. 7 janv. 2020 à 16:18, Franz Fellner  a
> écrit :
>
>> And what if you change the line to "dev-python/olefile amd64"?
>>
>> Am Di., 7. Jan. 2020 um 17:10 Uhr schrieb Mickaël Bucas > >:
>>
>>> Hi Franz
>>>
>>> Thanks for your reply.
>>>
>>> However your assumption is incorrect: these two commands are run on the
>>> same machine, with only the keyword on "olefile" changed.
>>> Thinking a bit more about it, Python 3.7 isn't stable yet, so I also
>>> have "=dev-lang/python-3.7* ~amd64" in package.accept_keyword.
>>>
>>> I've been able to reproduce this behavior in a chroot based on stage 3
>>> with the minimum packages installed.
>>> I have in make.conf
>>> PYTHON_TARGETS="python2_7 python3_6 python3_7"
>>> In /var/lib/portage/world
>>> dev-lang/python:3.7
>>> dev-python/olefile
>>> In /etc/portage/package.accept_keywords
>>> dev-python/olefile ~amd64
>>> =dev-lang/python-3.7* ~amd64
>>> dev-python/setuptools ~amd64
>>> dev-python/certifi ~amd64
>>>
>>> And emerge says :
>>> # emerge -pv1 olefile
>>> These are the packages that would be merged, in order:
>>> Calculating dependencies... done!
>>> [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
>>> PYTHON_TARGETS="python2_7 python3_6 python3_7 -pypy3 -python3_8" 0 KiB
>>> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>>>
>>> When I remove " dev-python/olefile ~amd64", Python 3.7 would be disabled
>>> :
>>> # emerge -pv1 olefile
>>> These are the packages that would be merged, in order:
>>> Calculating dependencies... done!
>>> [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
>>> PYTHON_TARGETS="python2_7 python3_6 (-pypy3) (-python3_7*) (-python3_8)" 0
>>> KiB
>>> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>>>
>>> This is still puzzling me, but one interpretation may be :
>>> I you enable the unstable ~amd64 keyword on a package, the stable
>>> version of said package is allowed to run on the unstable version of the
>>> Python interpreter.
>>>
>>> This seems to be the intended behavior, as I found that at least 40
>>> Python packages on each of my 2 systems are stable and have Python 3.7
>>> enabled (I keyworded all of them sometime in the past...)
>>>
>>> Thanks
>>> Best regards
>>> Mickaël Bucas
>>>
>>> Le mar. 7 janv. 2020 à 08:08, Franz Fellner  a
>>> écrit :
>>>
 I assume those emerge commands weren't done on one machine but come
 from those two different machines.
 This change in USE Flags can't come from that line in
 package.accept_keywords.
 This is a change in PYTHON_TARGETS in make.conf, package.use or
 package.env.
 Carefully go through those config files/directories, I am sure you will
 find the offending line.

 Regards
 Franz

 Am Fr., 3. Jan. 2020 um 11:44 Uhr schrieb Mickaël Bucas <
 mbu...@gmail.com>:

> Hello
>
> For some time I've been wondering why I had a difference on
> dev-python/olefile-0.46 between 2 machines : one was installed with
> python_targets_python3_7, the other wasn't.
> And I finally pinpointed it to package.accept_keywords containing
> "dev-python/olefile ~amd64" on one of the machines only
>
> At the time of writing, dev-python/olefile-0.46 is the stable version,
> and KEYWORDS contains "amd64" (no tilde) among others.
>
> When package.accept_keywords doesn't contain "dev-python/olefile
> ~amd64", I get :
> emerge -pv1 --verbose-conflicts olefile
> These are the packages that would be merged, in order:
> 

Re: [gentoo-user] Stable Python package changes USE flags with ~amd64

[Mickaël Bucas]

I get the following result:
# emerge -pv1 olefile


These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
PYTHON_TARGETS="python2_7 python3_6 (-pypy3) (-python3_7*) (-python3_8)" 0
KiB
Total: 1 package (1 reinstall), Size of downloads: 0 KiB

It seems to be in line with the interpretation I've come up with.

Best regards
Mickaël Bucas

Le mar. 7 janv. 2020 à 16:18, Franz Fellner  a
écrit :

> And what if you change the line to "dev-python/olefile amd64"?
>
> Am Di., 7. Jan. 2020 um 17:10 Uhr schrieb Mickaël Bucas  >:
>
>> Hi Franz
>>
>> Thanks for your reply.
>>
>> However your assumption is incorrect: these two commands are run on the
>> same machine, with only the keyword on "olefile" changed.
>> Thinking a bit more about it, Python 3.7 isn't stable yet, so I also have
>> "=dev-lang/python-3.7* ~amd64" in package.accept_keyword.
>>
>> I've been able to reproduce this behavior in a chroot based on stage 3
>> with the minimum packages installed.
>> I have in make.conf
>> PYTHON_TARGETS="python2_7 python3_6 python3_7"
>> In /var/lib/portage/world
>> dev-lang/python:3.7
>> dev-python/olefile
>> In /etc/portage/package.accept_keywords
>> dev-python/olefile ~amd64
>> =dev-lang/python-3.7* ~amd64
>> dev-python/setuptools ~amd64
>> dev-python/certifi ~amd64
>>
>> And emerge says :
>> # emerge -pv1 olefile
>> These are the packages that would be merged, in order:
>> Calculating dependencies... done!
>> [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
>> PYTHON_TARGETS="python2_7 python3_6 python3_7 -pypy3 -python3_8" 0 KiB
>> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>>
>> When I remove " dev-python/olefile ~amd64", Python 3.7 would be disabled :
>> # emerge -pv1 olefile
>> These are the packages that would be merged, in order:
>> Calculating dependencies... done!
>> [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
>> PYTHON_TARGETS="python2_7 python3_6 (-pypy3) (-python3_7*) (-python3_8)" 0
>> KiB
>> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>>
>> This is still puzzling me, but one interpretation may be :
>> I you enable the unstable ~amd64 keyword on a package, the stable version
>> of said package is allowed to run on the unstable version of the Python
>> interpreter.
>>
>> This seems to be the intended behavior, as I found that at least 40
>> Python packages on each of my 2 systems are stable and have Python 3.7
>> enabled (I keyworded all of them sometime in the past...)
>>
>> Thanks
>> Best regards
>> Mickaël Bucas
>>
>> Le mar. 7 janv. 2020 à 08:08, Franz Fellner  a
>> écrit :
>>
>>> I assume those emerge commands weren't done on one machine but come from
>>> those two different machines.
>>> This change in USE Flags can't come from that line in
>>> package.accept_keywords.
>>> This is a change in PYTHON_TARGETS in make.conf, package.use or
>>> package.env.
>>> Carefully go through those config files/directories, I am sure you will
>>> find the offending line.
>>>
>>> Regards
>>> Franz
>>>
>>> Am Fr., 3. Jan. 2020 um 11:44 Uhr schrieb Mickaël Bucas <
>>> mbu...@gmail.com>:
>>>
 Hello

 For some time I've been wondering why I had a difference on
 dev-python/olefile-0.46 between 2 machines : one was installed with
 python_targets_python3_7, the other wasn't.
 And I finally pinpointed it to package.accept_keywords containing
 "dev-python/olefile ~amd64" on one of the machines only

 At the time of writing, dev-python/olefile-0.46 is the stable version,
 and KEYWORDS contains "amd64" (no tilde) among others.

 When package.accept_keywords doesn't contain "dev-python/olefile
 ~amd64", I get :
 emerge -pv1 --verbose-conflicts olefile
 These are the packages that would be merged, in order:
 Calculating dependencies... done!
 [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
 PYTHON_TARGETS="python2_7 python3_6 (-pypy3) (-python3_7) (-python3_8)" 0
 KiB
 Total: 1 package (1 reinstall), Size of downloads: 0 KiB

 => Python 3.7 is disabled

 When package.accept_keywords contains "dev-python/olefile ~amd64", I
 get :
 emerge -pv1 olefile
 These are the packages that would be merged, in order:
 Calculating dependencies... done!
 [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
 PYTHON_TARGETS="python2_7 python3_6 python3_7* -pypy3 -python3_8" 0 KiB
 Total: 1 package (1 reinstall), Size of downloads: 0 KiB

 => Python 3.7 is enabled

 It seems really really strange to me for the same version of a stable
 package to be "influenced" by keywording.
 Is it a bug or a feature ?
 Did I do something wrong ?

 Thanks
 Best regards
 Mickaël Bucas

>>>

Re: [gentoo-user] Stable Python package changes USE flags with ~amd64

[Franz Fellner]

And what if you change the line to "dev-python/olefile amd64"?

Am Di., 7. Jan. 2020 um 17:10 Uhr schrieb Mickaël Bucas :

> Hi Franz
>
> Thanks for your reply.
>
> However your assumption is incorrect: these two commands are run on the
> same machine, with only the keyword on "olefile" changed.
> Thinking a bit more about it, Python 3.7 isn't stable yet, so I also have
> "=dev-lang/python-3.7* ~amd64" in package.accept_keyword.
>
> I've been able to reproduce this behavior in a chroot based on stage 3
> with the minimum packages installed.
> I have in make.conf
> PYTHON_TARGETS="python2_7 python3_6 python3_7"
> In /var/lib/portage/world
> dev-lang/python:3.7
> dev-python/olefile
> In /etc/portage/package.accept_keywords
> dev-python/olefile ~amd64
> =dev-lang/python-3.7* ~amd64
> dev-python/setuptools ~amd64
> dev-python/certifi ~amd64
>
> And emerge says :
> # emerge -pv1 olefile
> These are the packages that would be merged, in order:
> Calculating dependencies... done!
> [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
> PYTHON_TARGETS="python2_7 python3_6 python3_7 -pypy3 -python3_8" 0 KiB
> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>
> When I remove " dev-python/olefile ~amd64", Python 3.7 would be disabled :
> # emerge -pv1 olefile
> These are the packages that would be merged, in order:
> Calculating dependencies... done!
> [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
> PYTHON_TARGETS="python2_7 python3_6 (-pypy3) (-python3_7*) (-python3_8)" 0
> KiB
> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>
> This is still puzzling me, but one interpretation may be :
> I you enable the unstable ~amd64 keyword on a package, the stable version
> of said package is allowed to run on the unstable version of the Python
> interpreter.
>
> This seems to be the intended behavior, as I found that at least 40 Python
> packages on each of my 2 systems are stable and have Python 3.7 enabled (I
> keyworded all of them sometime in the past...)
>
> Thanks
> Best regards
> Mickaël Bucas
>
> Le mar. 7 janv. 2020 à 08:08, Franz Fellner  a
> écrit :
>
>> I assume those emerge commands weren't done on one machine but come from
>> those two different machines.
>> This change in USE Flags can't come from that line in
>> package.accept_keywords.
>> This is a change in PYTHON_TARGETS in make.conf, package.use or
>> package.env.
>> Carefully go through those config files/directories, I am sure you will
>> find the offending line.
>>
>> Regards
>> Franz
>>
>> Am Fr., 3. Jan. 2020 um 11:44 Uhr schrieb Mickaël Bucas > >:
>>
>>> Hello
>>>
>>> For some time I've been wondering why I had a difference on
>>> dev-python/olefile-0.46 between 2 machines : one was installed with
>>> python_targets_python3_7, the other wasn't.
>>> And I finally pinpointed it to package.accept_keywords containing
>>> "dev-python/olefile ~amd64" on one of the machines only
>>>
>>> At the time of writing, dev-python/olefile-0.46 is the stable version,
>>> and KEYWORDS contains "amd64" (no tilde) among others.
>>>
>>> When package.accept_keywords doesn't contain "dev-python/olefile
>>> ~amd64", I get :
>>> emerge -pv1 --verbose-conflicts olefile
>>> These are the packages that would be merged, in order:
>>> Calculating dependencies... done!
>>> [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
>>> PYTHON_TARGETS="python2_7 python3_6 (-pypy3) (-python3_7) (-python3_8)" 0
>>> KiB
>>> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>>>
>>> => Python 3.7 is disabled
>>>
>>> When package.accept_keywords contains "dev-python/olefile ~amd64", I get
>>> :
>>> emerge -pv1 olefile
>>> These are the packages that would be merged, in order:
>>> Calculating dependencies... done!
>>> [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
>>> PYTHON_TARGETS="python2_7 python3_6 python3_7* -pypy3 -python3_8" 0 KiB
>>> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>>>
>>> => Python 3.7 is enabled
>>>
>>> It seems really really strange to me for the same version of a stable
>>> package to be "influenced" by keywording.
>>> Is it a bug or a feature ?
>>> Did I do something wrong ?
>>>
>>> Thanks
>>> Best regards
>>> Mickaël Bucas
>>>
>>

Re: [gentoo-user] Stable Python package changes USE flags with ~amd64

[Mickaël Bucas]

Hi Franz

Thanks for your reply.

However your assumption is incorrect: these two commands are run on the
same machine, with only the keyword on "olefile" changed.
Thinking a bit more about it, Python 3.7 isn't stable yet, so I also have
"=dev-lang/python-3.7* ~amd64" in package.accept_keyword.

I've been able to reproduce this behavior in a chroot based on stage 3 with
the minimum packages installed.
I have in make.conf
PYTHON_TARGETS="python2_7 python3_6 python3_7"
In /var/lib/portage/world
dev-lang/python:3.7
dev-python/olefile
In /etc/portage/package.accept_keywords
dev-python/olefile ~amd64
=dev-lang/python-3.7* ~amd64
dev-python/setuptools ~amd64
dev-python/certifi ~amd64

And emerge says :
# emerge -pv1 olefile
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
PYTHON_TARGETS="python2_7 python3_6 python3_7 -pypy3 -python3_8" 0 KiB
Total: 1 package (1 reinstall), Size of downloads: 0 KiB

When I remove " dev-python/olefile ~amd64", Python 3.7 would be disabled :
# emerge -pv1 olefile
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
PYTHON_TARGETS="python2_7 python3_6 (-pypy3) (-python3_7*) (-python3_8)" 0
KiB
Total: 1 package (1 reinstall), Size of downloads: 0 KiB

This is still puzzling me, but one interpretation may be :
I you enable the unstable ~amd64 keyword on a package, the stable version
of said package is allowed to run on the unstable version of the Python
interpreter.

This seems to be the intended behavior, as I found that at least 40 Python
packages on each of my 2 systems are stable and have Python 3.7 enabled (I
keyworded all of them sometime in the past...)

Thanks
Best regards
Mickaël Bucas

Le mar. 7 janv. 2020 à 08:08, Franz Fellner  a
écrit :

> I assume those emerge commands weren't done on one machine but come from
> those two different machines.
> This change in USE Flags can't come from that line in
> package.accept_keywords.
> This is a change in PYTHON_TARGETS in make.conf, package.use or
> package.env.
> Carefully go through those config files/directories, I am sure you will
> find the offending line.
>
> Regards
> Franz
>
> Am Fr., 3. Jan. 2020 um 11:44 Uhr schrieb Mickaël Bucas  >:
>
>> Hello
>>
>> For some time I've been wondering why I had a difference on
>> dev-python/olefile-0.46 between 2 machines : one was installed with
>> python_targets_python3_7, the other wasn't.
>> And I finally pinpointed it to package.accept_keywords containing
>> "dev-python/olefile ~amd64" on one of the machines only
>>
>> At the time of writing, dev-python/olefile-0.46 is the stable version,
>> and KEYWORDS contains "amd64" (no tilde) among others.
>>
>> When package.accept_keywords doesn't contain "dev-python/olefile ~amd64",
>> I get :
>> emerge -pv1 --verbose-conflicts olefile
>> These are the packages that would be merged, in order:
>> Calculating dependencies... done!
>> [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
>> PYTHON_TARGETS="python2_7 python3_6 (-pypy3) (-python3_7) (-python3_8)" 0
>> KiB
>> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>>
>> => Python 3.7 is disabled
>>
>> When package.accept_keywords contains "dev-python/olefile ~amd64", I get
>> :
>> emerge -pv1 olefile
>> These are the packages that would be merged, in order:
>> Calculating dependencies... done!
>> [ebuild   R] dev-python/olefile-0.46::gentoo  USE="-doc"
>> PYTHON_TARGETS="python2_7 python3_6 python3_7* -pypy3 -python3_8" 0 KiB
>> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>>
>> => Python 3.7 is enabled
>>
>> It seems really really strange to me for the same version of a stable
>> package to be "influenced" by keywording.
>> Is it a bug or a feature ?
>> Did I do something wrong ?
>>
>> Thanks
>> Best regards
>> Mickaël Bucas
>>
>

Re: [gentoo-user] Guidance on using Gentoo to clone a Win 10 system drive

[Mick]

This is getting a tad O/T, since we're talking about activation of a non-
Gentoo OS, but here it goes:

On Tuesday, 7 January 2020 00:39:19 GMT Mark Knecht wrote:

>I'm going to let the machine sit overnight and see if it activates
> automatically.

It should activate as long as it is connected to the Internet, but there are 
two different ways of activating Windows 10 manually, should you not do so 
during the installation procedure.

1. Using a product key and entering this when you try to activate it.  This is 
the conventional way of activating the installation when you buy a Windows 10 
from a retailer.  To check the activation status go to Start > Settings > 
Update & Security > Activation.

NOTE:  A Windows 10 installation is linked to the UUID of the MoBo, which is 
stored on the Windows Activation Servers and mapped against your Product key.  
If you change the hardware you will need to re-enter the Product key to 
activate the upgraded hardware.

2. Using your Microsoft account credentials, which must be linked to the 
Windows 10 installation's "Digital License".  This is a relatively new way and 
allows you to install Windows 10 on different PCs (one at a time), change the 
MoBo, etc., but each time you (re)install it you must use the same edition of 
Windows 10 and sign in to your Microsoft account linked to the original 
digital license.

Since your existing installation is already activated, you may be able to link 
its Digital License to your Microsoft account - but this depends how it was 
activate (Product Key or Digital License).  If the activation status shows:

"Windows is activated with a digital license", then your Microsoft account is 
not yet linked to this installation.  In this case, follow instructions to 
"Add an account".

"Windows is activated with a digital license linked to your Microsoft 
account", then you are good to install afresh on a different disk/PC and add 
your Microsoft account credentials when asked.


> If it doesn't I'll go back to the old drive and if needed
> will do a new reinstall with the right version. If I can get away with this
> path I will. If not I'll go with something like Mick suggested.
> 
> thanks,
> Mark

Partition UUIDs are important if you are restoring Windows from an old 
installation, but for a different reason.  The Windows boot loader uses the 
partition UUIDs to boot the OS.  If you have created a new C:\ partition and 
transferred all the OS files in there, the boot loader will fail to boot it 
because the new partition's UUID will be different.


PS. The above is just a summary of my understanding.  I am not an experienced 
MSWindows user, so I may well have got some details wrong.  You should search 
the https://support.microsoft.com/ website for reinstallation steps.

PPS. As far as I know you can use Windows 10 without activating it, but there 
is no guarantee Microsoft won't stop Windows Updates for installations which 
have not been activated some day in the future and future upgrades to later OS 
releases may be blocked.  As far as I know a non-activated installation is not 
crippleware.  Perhaps some 3rd party proprietary applications will refuse to 
install on a non-activated MSWindows installation, but I haven't come across 
any in my very limited experience with this OS.
-- 
Regards,
Mick

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

Re: [gentoo-user] Netgear AC1750 C7 V2 and IPv6

[Peter Humphrey]

On Tuesday, 7 January 2020 07:08:04 GMT Dale wrote:

> Starting a new thread.  I got my modem and router all hooked up. 
> Networking works except IPv6 isn't quite there yet.  I even got my cell
> phone and printer working again, IP network address changed.  I'm almost
> certain the modem and my puter has a working IPv6.  Going to give some
> info but some numbers may be changed, for obvious reasons since I don't
> want some weirdo tracking me down.  Modem first: 

I'll leave IPv6 congnoscenti to answer your particular questions, but I found 
that the way to start was with the LAN addressing, only later connecting to 
the Internet. I think this was the most helpful page:

https://www.jumpingbean.co.za/blogs/mark/set-up-ipv6-lan-with-linux

Reading that gave me a much improved understanding of what I was doing.

HTH.

-- 
Regards,
Peter.