Re: [gentoo-user] Pick your hypothesis:

[Kai Peter]

On 2019-01-24 21:59, Michael Jones wrote:



You really can't run Gentoo safely for very long without paying

close attention to what you are doing - with both installs and
upgrades.

I don't know that this is true. I've had the same set of use flags
configured on all of my Gentoo computers for 5-ish years now, and I've
only very rarely messed with them. For the most part, running
"eix-sync && emerge --update --newuse --deep @world" once a week has
allowed me to have unattended upgrades for many months at a time, only
needing to adjust one or two things every several months. Needing to
tweak something is my exception, not my rule.
+1. That's a core point to me. An update once a week and adjusting USE 
flags (down) to the _real_ requirements makes multiple Gentoo 
installations long term stable.


Happy compiling :-)


--
Sent with eQmail-1.11 beta - a fork of djb's famous qmail

Re: [gentoo-user] Pick your hypothesis:

[Alan Grimes]

Rich Freeman wrote:
>
> If you use emerge-webrsync then the sync operation itself should use
> gpg signature checking and that should rule out server issues.  Ditto
> if you sync with git with the appropriate settings, though git also
> has internal hash consistency checking (that doesn't prevent
> intentional tampering but should catch data transmission issues).


emerge-webrsync actually fixed it, it's running now.  WTF^100

Now it's only a problem of maxing out the load average on my Ryzen 1800x
processor. =P

Currently 10.0 with a throttle value of 12, 16 hardware threads are
available

-- 
Please report bounces from this address to a...@numentics.com

Powers are not rights.

Re: [gentoo-user] Pick your hypothesis:

[Dale]

Alan Grimes wrote:
> Michael Jones wrote:
>> My reason for replying initially was that I didn't think it was fair
>> to make light of users who don't expect to *need* to scrutinize the
>> output of emerge every single time they run it. Those people exist
>> (hi, nice to meet you), and it's not fair to say they're wrong or
>> somehow making a grave error in judgement.
>>
>> It's entirely fair to say that they are treading on thin ice, and that
>> if they choose to do this they should understand the risks, but it's
>> not fair to say they're automatically wrong to use the tool in a way
>> that the tool allows itself to be used.
>>
>> Either way, we don't need to turn this into a long and in depth
>> discussion, so I probably won't reply to the list again unless you
>> have any specific questions or concerns for me.
> Thank you for the reasonable response.
>
> Dale, of course, has spewed hate at me for simply trying to make my life
> as convenient as possible while still using Gentoo over here without
> even providing a satisfactory answer as to why.
>

Spewed hate?  Make your life convenient?  I went back and looked at
threads you posted several years ago, before your posting privileges
were stopped, not sure what action was taken just that you didn't post
for a while.  Back then, Neil, the other Alan, myself and several others
were trying to help you.  Mostly, it was pointed out that the script you
were using was causing problems and was certainly not making things
easier much less convenient.  That's not spewing hate.  That's trying to
help you with the problem.  I might add, I was one of very few who kept
trying to help when others had already stopped replying to you.  Maybe
you forgot that??

If you want a easy way to update your system, I'll list what I do here
and it has worked for a long time.  I been using Gentoo since early
2003.  Sure, sometimes I run into a issue that I need help on but that
isn't to often.  When it does, I post all the info I think is needed for
others to look at and advise on how to proceed.  Sometimes, it is a
change upstream, sometimes it is something I have going on on my end. 
Either way, I adjust to the fix. 

First, sync the tree and any related overlays.  I use eix-sync since it
does all of it in one command.  It syncs the tree and any overlays at
the same time.  My first command looks like this.

eix-sync && emerge -uvaDN world

Since I have some default options in make.conf, it ends up like this for
emerge.

emerge --jobs=5 --update --backtrack=100 --keep-going --verbose --newuse
--oneshot --quiet-build=n --with-bdeps=y --unordered-display --ask
--deep world

That looks long but most of that is in make.conf so that I don't have to
type it all in every time.  I also see I can leave off the -u since it
is in make.conf.  Once the sync is done, it then runs emerge to see what
packages are going to be updated, what their USE flags are and if emerge
will have any issues emerging them such as hard blocks or USE flag
conflicts.  I always check for what is being installed new, what USE
flags are changing and for upgrades to packages I specifically installed
myself.  Most changes in the list are color coded.  It makes it very
easy to see what is changing.  If I see something changing that I don't
want or want handled another way, I go edit the needed config file(s)
and run emerge again to see if it is like I want.  Sometimes, that takes
a few times.  Sometimes, it works fine the very first time.  Once it is
like I want/need, I then hit y and let emerge proceed with the update. 
At this point, you can walk away.  I run some packages unstable and
still it is rare that a package fails.  I might add, going over that
list usually takes less than five minutes, even if I have to edit a
config file to get things like I want. 

Odds are, if you do it that way, it will work almost every time.  The
thing is, you have to stay on top of it and update on a regular basis. 
I saw that was mentioned a few times several years ago.  Gentoo supports
going a year without a update but it doesn't mean that updating a system
10, 12 or 13 months out of date is going to be easy.  Depending on what
changes has been made, it could be difficult. 

Maybe when you get the current issue sorted out, you will at least
consider this a starting point for doing what is known to work well.  It
took me years to get to this point.  As options are added to emerge, I
adjust make.conf to make things work better.  Thing is, I don't mind
sharing a good way to update and save someone else a lot of issues. 
It's up to them whether they want to use it or not. 

I hope this will help you after you get the current problem fixed. 

Dale

:-)  :-) 

Re: [gentoo-user] Pick your hypothesis:

[Rich Freeman]

On Thu, Jan 24, 2019 at 7:55 PM Neil Bothwick  wrote:
>
> On Thu, 24 Jan 2019 19:18:17 -0500, Alan Grimes wrote:
>
> > Since 2004, I have been using "emerge --sync" to update my portage tree.
> > I understand that it accesses a local list of mirrors and then runs
> > rsync against one of those. On spinning media hard disks it is helpful
> > to pre-cache the portage tree as shown in my scripts, on SSD systems, it
> > is simply harmless. I refreshed my mirror list and selected either HTTP
> > or RSYNC mirrors from across the USA.
>
> I doubt that there is an advantage in pre-caching, all you are doing is
> taking time from the sync process and adding it to another process, but I
> also doubt that has anything to do with your problems.
>
> > The problem is NOT with emerge in that the files that it complains about
> > not being present are in fact not present.
>
> That's the rub, they are present here, so something is interfering with
> your downloading of these patch files. Do you have any entries in
> make.conf that would modify rsync behaviour? Try
>
> emerge --info -v | grep -i sync
>
> Also, what do you have in /etc/portage/repos.conf/gentoo.conf?
>

Some kind of rsync issue (assuming rsync is even being used) seems
likely.  It is a bit odd since I'd think that rsync would download the
missing files at about the same time that it downloads the manifests -
I assume that it goes in directory order.

If you have some kind of environment variable or make.conf option set
that overrides rsync defaults maybe that is causing rsync to not
actually sync the tree?  Deleting /usr/portage and re-syncing seems
like an obvious way to wipe the slate clean.  Other local issues could
be anything that might cause rsync to terminate prematurely (RAM,
ulimit, whatever - obviously unlikely).

Knowing what mirror is in use may also be helpful - could be a bad
mirror or something.  What server/IP/etc is being output in the emerge
--sync output?

If you're syncing with git and manually modify stuff in the local repo
that can cause issues since git will start getting merge conflicts.
rsync just overwrites your repo with the Gentoo one and wipes out your
own changes.

If you use emerge-webrsync then the sync operation itself should use
gpg signature checking and that should rule out server issues.  Ditto
if you sync with git with the appropriate settings, though git also
has internal hash consistency checking (that doesn't prevent
intentional tampering but should catch data transmission issues).

The suspicion of an error by a Gentoo developer is a possibility, but
these are pretty rare and usually get fixed very quickly.  If you sync
from one of the stable mirrors in git those are all screened by CI
which eliminates these sorts of missing file issues (granted, in git
we don't track FILESDIR in manifests anyway).  If this is happening it
would be trivial to detect on the various online git repositories - so
checking these for the error before pointing fingers is appropriate.
Typically these sorts of errors are caught by bots and result in
plenty of internal shaming already, which is why it is likely a
problem like this would be short-lived.

-- 
Rich

Re: [gentoo-user] Pick your hypothesis:

[Sam Jorna (wraeth)]

On Friday, 25 January 2019 11:18:17 AM AEDT Alan Grimes wrote:
> Michael Jones wrote:
> > My reason for replying initially was that I didn't think it was fair
> > to make light of users who don't expect to *need* to scrutinize the
> > output of emerge every single time they run it. Those people exist
> > (hi, nice to meet you), and it's not fair to say they're wrong or
> > somehow making a grave error in judgement.
> > 
> > It's entirely fair to say that they are treading on thin ice, and that
> > if they choose to do this they should understand the risks, but it's
> > not fair to say they're automatically wrong to use the tool in a way
> > that the tool allows itself to be used.
> > 
> > Either way, we don't need to turn this into a long and in depth
> > discussion, so I probably won't reply to the list again unless you
> > have any specific questions or concerns for me.
> 
> Thank you for the reasonable response.
> 
> Dale, of course, has spewed hate at me for simply trying to make my life
> as convenient as possible while still using Gentoo over here without
> even providing a satisfactory answer as to why.
> 
> 
> My experience with Emerge is that it goes out of it's way to be obscure
> and conceales huge amounts of information from the user by default, like
> all unix programs, and must be coaxed with a litany of flags,
> parameters, and environment variables to produce any useful output at
> all. Whenever it's output pattern changes I need to go do research to
> re-enable whatever it decided to hide this month.

Portage does not "go out of its way to be obscure", it just offers optional 
functionality in packages differently to binary distros, offering them as flags 
on the parent package rather than splitting them into discrete sub-packages. 
If a binary distro were to have a package that it splits component features 
into sub-packages, you'd be in the same situation.

Point is: if you are the admin of the system, you should check the updates 
before committing to them, regardless of whether it's a binary or from-source 
distro. Updates that break the tree are usually caught and resolved quickly, 
particularly for key packages like openssl.

But hey, it's your system. :)

> At this point, I need to update about 25% of my system, or on the order
> of 460 packages. Going through this list manually simply is not feasible
> or even productive. Having tried several approaches to starting the
> update including emerge --update system, emerge --update world, and
> emerge --update packageX, I have decided that the only command that will
> sucessfully update my system in it's present state is emerge --emptytree
> world . The singular obstacle to that working appears to be the absence
> of those patch files.

That sounds like you're not updating correctly. `emerge -uUDa @world` is 
generally all you should need for keeping the system up to date. Very 
occasionally you'll need to do other things, but not as a rule of thumb. Note 
that this will exclude some packages where a flag was added *in a disabled 
state*, so it shouldn't affect the resulting built package. You can include 
those by changing the 'U' to an 'N'.

You might also be interested in the --keep-going flag, rather than spamming 
countless --resumes. This allows portage to build what it can and leave 
anything that fails (and dependents that subsequently can't be built) to be 
resolved and re-tried at the end (providing you read the output showing what 
failed and what couldn't be built as a result).

Also note that you can expect to encounter a few more bugs if you're using 
~arch. That's why it's known as "testing" and why it isn't enabled by default.

> Now, back to the problem at hand.
> 
> Since 2004, I have been using "emerge --sync" to update my portage tree.
> I understand that it accesses a local list of mirrors and then runs
> rsync against one of those. On spinning media hard disks it is helpful
> to pre-cache the portage tree as shown in my scripts, on SSD systems, it
> is simply harmless. I refreshed my mirror list and selected either HTTP
> or RSYNC mirrors from across the USA.

This sounds like either a broken mirror (which does happen from time to time) 
or options on your system that are preventing it from syncing all the required 
files. It would be useful to see your actual configuration (in the form of an 
`emerge --info`).

> The problem is NOT with emerge in that the files that it complains about
> not being present are in fact not present. I tried to find them on
> google and only found changelogs, not the actual files in a downloadable
> state that I can add manually. I am still angry with Emerge for not
> updating all packages for which those files are not required or even
> compiling packages until it encounters one for which it does not have
> the files.

See my above note about --keep-going.

> I prefer to obey the server's admonition against updating more than once
> a day, however this is an emergency and I have run 

Re: [gentoo-user] Pick your hypothesis:

[Neil Bothwick]

On Thu, 24 Jan 2019 19:18:17 -0500, Alan Grimes wrote:

> Since 2004, I have been using "emerge --sync" to update my portage tree.
> I understand that it accesses a local list of mirrors and then runs
> rsync against one of those. On spinning media hard disks it is helpful
> to pre-cache the portage tree as shown in my scripts, on SSD systems, it
> is simply harmless. I refreshed my mirror list and selected either HTTP
> or RSYNC mirrors from across the USA.

I doubt that there is an advantage in pre-caching, all you are doing is
taking time from the sync process and adding it to another process, but I
also doubt that has anything to do with your problems.

> The problem is NOT with emerge in that the files that it complains about
> not being present are in fact not present.

That's the rub, they are present here, so something is interfering with
your downloading of these patch files. Do you have any entries in
make.conf that would modify rsync behaviour? Try

emerge --info -v | grep -i sync

Also, what do you have in /etc/portage/repos.conf/gentoo.conf?

> I tried to find them on
> google and only found changelogs, not the actual files in a downloadable
> state that I can add manually.

Try https://github.com/gentoo/gentoo

> I am still angry with Emerge for not
> updating all packages for which those files are not required or even
> compiling packages until it encounters one for which it does not have
> the files.

It detected corruption of your portage tree, if files don't match the
manifests all sorts of unpleasant consequences are possible, so aborting
seems a safe option. Rather than trying to work around the issue, try to
find the cause. If the files are not on Github, file a bug report. If
they are, find out why rsync is not downloading them on your system but
is on others.

If this problem was widespread, you would have had a chorus of "me too"
replies and b.g.o would be full of reports - you did check b.g.o?


-- 
Neil Bothwick

A bit of tolerance is worth a megabyte of flaming. -- Henry Spencer


pgpPUXdnOWSwm.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Pick your hypothesis:

[Alan Grimes]

Michael Jones wrote:
>
> My reason for replying initially was that I didn't think it was fair
> to make light of users who don't expect to *need* to scrutinize the
> output of emerge every single time they run it. Those people exist
> (hi, nice to meet you), and it's not fair to say they're wrong or
> somehow making a grave error in judgement.
>
> It's entirely fair to say that they are treading on thin ice, and that
> if they choose to do this they should understand the risks, but it's
> not fair to say they're automatically wrong to use the tool in a way
> that the tool allows itself to be used.
>
> Either way, we don't need to turn this into a long and in depth
> discussion, so I probably won't reply to the list again unless you
> have any specific questions or concerns for me.

Thank you for the reasonable response.

Dale, of course, has spewed hate at me for simply trying to make my life
as convenient as possible while still using Gentoo over here without
even providing a satisfactory answer as to why.


My experience with Emerge is that it goes out of it's way to be obscure
and conceales huge amounts of information from the user by default, like
all unix programs, and must be coaxed with a litany of flags,
parameters, and environment variables to produce any useful output at
all. Whenever it's output pattern changes I need to go do research to
re-enable whatever it decided to hide this month.

At this point, I need to update about 25% of my system, or on the order
of 460 packages. Going through this list manually simply is not feasible
or even productive. Having tried several approaches to starting the
update including emerge --update system, emerge --update world, and
emerge --update packageX, I have decided that the only command that will
sucessfully update my system in it's present state is emerge --emptytree
world . The singular obstacle to that working appears to be the absence
of those patch files.

Now, back to the problem at hand.

Since 2004, I have been using "emerge --sync" to update my portage tree.
I understand that it accesses a local list of mirrors and then runs
rsync against one of those. On spinning media hard disks it is helpful
to pre-cache the portage tree as shown in my scripts, on SSD systems, it
is simply harmless. I refreshed my mirror list and selected either HTTP
or RSYNC mirrors from across the USA.

The problem is NOT with emerge in that the files that it complains about
not being present are in fact not present. I tried to find them on
google and only found changelogs, not the actual files in a downloadable
state that I can add manually. I am still angry with Emerge for not
updating all packages for which those files are not required or even
compiling packages until it encounters one for which it does not have
the files.

I prefer to obey the server's admonition against updating more than once
a day, however this is an emergency and I have run sync against it maybe
a dozen times. I have no reason to expect that there is any discrepency
between the files I have and what's actually on the servers unless there
is an entirely different set of servers out there which actually do have
the files I need or a completely new and different way to sync them, 
(WTF IS Eix? ) . =|

-- 
Please report bounces from this address to a...@numentics.com

Powers are not rights.

Re: [gentoo-user] Pick your hypothesis:

[Michael Jones]

On Thu, Jan 24, 2019 at 2:33 PM Jack 
wrote:

> On 2019.01.24 15:17, Michael Jones wrote:
> [snip]
> > A lot of people run emerge without checking the preliminary console
> > output.
> But most (I hope) of them understand the possible problems, and are
> willing to "pick up the pieces" if something goes wrong.  Most of them
> do not blame the Gentoo developers in such a case.
>

Of course.


> > I don't think it's fair to imply that doing that is somehow wrong.
> Some/many of us might disagree.  If you don't check the output to see
> exactly what emerge is going to do, it may well not do what you
> want/expect.  Is it "wrong" to drive your car with a blindfold on.
>

You're absolutely right that if you don't check the output, it might be
doing something different than what you expect.

I don't really see how the car analogy is applicable though, so I can't
agree with that.


> > The vast majority of Linux distributions support unattended upgrades
> > without a second thought.
> The vast majority of Linux distributions are binary distributions,
> where a package either works or not, and if it doesn't, it is very
> likely a packaging error.  The vast majority of Linux distributions do
> not install from source, with lots of ways of configuring things to the
> user's liking, many of which possible configurations will not work.  I
> would say that binary distributions are much more deterministic in
> their behavior.  You really can't run Gentoo safely for very long
> without paying close attention to what you are doing - with both
> installs and upgrades.
>
>
Well,lets break this down into smaller pieces:

> The vast majority of Linux distributions are binary distributions,
where a package either works or not, and if it doesn't, it is very
likely a packaging error.

Sure, a lot of the time problems with binary distros are packaging errors.
Bugs can happen in a lot of ways. Sometimes the package is just broken
*shrug*.

> The vast majority of Linux distributions do not install from source, with
lots of ways of configuring things to the user's liking, many of which
possible configurations will not work.

Sure, that's true.

While I agree that the number of user facing toggles increase the
likelihood of something going wrong, I don't agree that this is inherently
an excuse. Obviously it's an explanation as to how something going wrong
wasn't able to be addressed ahead of time, but it's not automatically a
fair excuse / justification for delivering an ebuild to the portage tree
that has problems.

I'm not arguing that the Gentoo developers are somehow beholden to users,
nor am I saying that it's wise to assume everything will work correctly.
I'm simply saying that it's not fair to say that not checking the output of
emerge is inherently wrong. If it was inherently wrong, then emerge should
not allow for a package to be emerged until the user has reviewed it's
stated plan.

> You really can't run Gentoo safely for very long without paying close
attention to what you are doing - with both installs and upgrades.

I don't know that this is true. I've had the same set of use flags
configured on all of my Gentoo computers for 5-ish years now, and I've only
very rarely messed with them. For the most part, running "eix-sync &&
emerge --update --newuse --deep @world" once a week has allowed me to have
unattended upgrades for many months at a time, only needing to adjust one
or two things every several months. Needing to tweak something is my
exception, not my rule.

My reason for replying initially was that I didn't think it was fair to
make light of users who don't expect to *need* to scrutinize the output of
emerge every single time they run it. Those people exist (hi, nice to meet
you), and it's not fair to say they're wrong or somehow making a grave
error in judgement.

It's entirely fair to say that they are treading on thin ice, and that if
they choose to do this they should understand the risks, but it's not fair
to say they're automatically wrong to use the tool in a way that the tool
allows itself to be used.

Either way, we don't need to turn this into a long and in depth discussion,
so I probably won't reply to the list again unless you have any specific
questions or concerns for me.

Happy compiling :-)

Re: [gentoo-user] Pick your hypothesis:

[Dale]

Michael Jones wrote:
>
>
> On Thu, Jan 24, 2019 at 2:04 PM Dale  > wrote:
>
> Neil Bothwick wrote:
> > On Thu, 24 Jan 2019 13:42:04 -0600, Dale wrote:
> >
> >> I'm trying to recall but am not sure, is this the same Alan
> that used to
> >> come on here and post this sort of thing when the problem was
> in the
> >> chair not Gentoo?  I recall the person I'm speaking of having a
> script
> >> that just created a mess and then he blamed it on Gentoo.  I
> might still
> >> have some of those emails but someone else may recall if this
> is the
> >> same person or not.
> > It is.
> >
> >
>
>
> Yep.  I went and found this little gem.  For those interested, this is
> the script he used back then.  I'm not sure if he still does today or
> not.  Some of you may find it funny.  Some may just cry, for various
> reasons.  ;-) 
>
>


>
> I have to say, the first sentence says a LOT.  Who here runs emerge
> without checking to make sure it is going to do what you want it to
> first?  Heck, I always run with -a and look at USE flags and such
> before
> even thinking about hitting y to continue.  Sometimes, it may take me
> adjusting settings two or three times to get what I need.  It goes
> downhill from there with his script.  Heck, if I were emerge, I'd
> break
> too.  lol 
>
> Dale
>
> :-)  :-) 
>
>
>
>
> A lot of people run emerge without checking the preliminary console
> output. 
>
> I don't think it's fair to imply that doing that is somehow wrong.
>
> The vast majority of Linux distributions support unattended upgrades
> without a second thought. 

I'm not sure that many actually do that with Gentoo and have no problems
with it.  Packages are constantly changing, USE flags are changing and a
whole host of other things are changing and in a source based distro,
you have to monitor those changes and adjust based on them.  Sure, a lot
of people sync and have the -p version of emerge emailed to them.  Thing
is, that isn't a update.  That is preparing for a update.  The update
happens when emerge starts compiling and installing packages.  It's on
the user to check that and correct things before updating.  If the user
doesn't, then that is not Gentoo's fault, that is the users fault.  That
is something several us tried to tell Alan. 

As Jack pointed out, most distros are binary based.  They are made to
upgrade even without the user doing anything.  Some do it automatically
as well.  Thing is, that doesn't work as well when there are choices to
be made.  Gentoo is about choices.  It's the user that has to make
those.  That's why emerge spits out what it is about to do for you to
look at.  If you don't look at it, you may not get what you want.  The
longer you ignore it, the more likely that is to create problems. 

Sure, if you want to blindly update Gentoo and never look at what is
going on, that's fine.  Just don't be surprised when you get a broken
system  I learned long ago, you either spend a few minutes on the front
end making sure the updates are headed where you want them or you spend
hours trying to figure out what went wrong.  Some learn that the hard way. 

I might add, several of us tried to work with Alan back then.  Based on
posts back then, quite a few blacklisted him because he wouldn't take
advice.  Some just ignored his posts.  Several of us pointed out that
his script, as a whole, is a disaster and nothing good is going to come
from it long term or even short term really.  If he wants to keep doing
things the way we know doesn't work, we can't help him. 

Just saying.

Dale

:-)  :-) 

Re: [gentoo-user] Pick your hypothesis:

[Rich Freeman]

On Thu, Jan 24, 2019 at 1:39 PM Alan Grimes  wrote:
>
> Hypothesis 1:
>
> Rsync failed to correctly perform it's primary function.
>
>
> Hypothesis 2:
>
> Some F-tard at Gentoo world headquarters left the portage tree in an
> inconsistient state, shrugged, and walked away.
>

Speaking on behalf of the proctors we are issuing a warning that this
post is in violation of the Gentoo Code of Conduct:
https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct

Please review the points of the CoC, both positive and negative.
Honestly, almost all of them apply to this post.

Sharing problems and frustrations on this list is a large part of what
it is here for.  However, others can only help you to the degree that
you enable them, and that means giving accurate reports of problems
and sincerely working with those who offer potential solutions.
Jumping to negative conclusions and pointing fingers without any real
evidence is just not helpful and drives away those who might want to
help, and isn't conducive to getting more serious problems fixed even
if they are real.

Additionally, it isn't necessary for everybody else to pile on.  One
of the goals of Proctors is to try to have an official way to deal
with this stuff in a measured way without everybody feeling like they
have to act on their own.

-- 
Rich

Re: [gentoo-user] Pick your hypothesis:

[Jack]

On 2019.01.24 15:17, Michael Jones wrote:
[snip]
A lot of people run emerge without checking the preliminary console  
output.
But most (I hope) of them understand the possible problems, and are  
willing to "pick up the pieces" if something goes wrong.  Most of them  
do not blame the Gentoo developers in such a case.



I don't think it's fair to imply that doing that is somehow wrong.
Some/many of us might disagree.  If you don't check the output to see  
exactly what emerge is going to do, it may well not do what you  
want/expect.  Is it "wrong" to drive your car with a blindfold on?


The vast majority of Linux distributions support unattended upgrades  
without a second thought.
The vast majority of Linux distributions are binary distributions,  
where a package either works or not, and if it doesn't, it is very  
likely a packaging error.  The vast majority of Linux distributions do  
not install from source, with lots of ways of configuring things to the  
user's liking, many of which possible configurations will not work.  I  
would say that binary distributions are much more deterministic in  
their behavior.  You really can't run Gentoo safely for very long  
without paying close attention to what you are doing - with both  
installs and upgrades.


Jack

Re: [gentoo-user] Pick your hypothesis:

[Michael Jones]

On Thu, Jan 24, 2019 at 2:04 PM Dale  wrote:

> Neil Bothwick wrote:
> > On Thu, 24 Jan 2019 13:42:04 -0600, Dale wrote:
> >
> >> I'm trying to recall but am not sure, is this the same Alan that used to
> >> come on here and post this sort of thing when the problem was in the
> >> chair not Gentoo?  I recall the person I'm speaking of having a script
> >> that just created a mess and then he blamed it on Gentoo.  I might still
> >> have some of those emails but someone else may recall if this is the
> >> same person or not.
> > It is.
> >
> >
>
>
> Yep.  I went and found this little gem.  For those interested, this is
> the script he used back then.  I'm not sure if he still does today or
> not.  Some of you may find it funny.  Some may just cry, for various
> reasons.  ;-)
>
> Alan Grimes wrote:
> > I use two scripts for all emerge use, the goal is to run one command and
> > then walk away:
> >
> > Standard general update script:
> > ###
> > tortoise ~ # cat sysupdate
> >
> > #they must have moved or removed the logs, might have to track them down
> > again...
> > #rm /var/log/emerge*
> >
> > # cache /usr/portage
> > echo "caching /usr/portage.  This will take a long time."
> > time ls -R /usr/portage > /dev/null
> >
> > emerge --sync
> > layman --sync ALL
> >
> > emerge --update --verbose portage
> > emerge --update --newuse --deep --with-bdeps=y system --keep-going
> > emerge --update --newuse --deep --with-bdeps=y world --keep-going
> >
> > rm -f /var/cache/revdep-rebuild/*.rr
> > revdep-rebuild
> > emerge --skipfirst --resume
> > emerge --skipfirst --resume
> > etc-update
> > eclean-dist
> > 
> >
> > The eclean line was added just a few days ago from this thread...
> >
> > This one is intended to be a nice gentle update script.
> > It caches the portage tree, then syncs everything, then updates
> > everything starting with critical system packages, then all world
> > packages...
> >
> > Then it cleans stuff up, it jcakhammers the revdep-rebuild but not too
> > hard
> >
> >
> > This next script is what I use when emerge starts giving me shit:
> >
> > ##
> > tortoise ~ # cat keepgoing
> > emerge --update --newuse --deep --with-bdeps=y system
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> >
> > emerge --update --newuse --deep --with-bdeps=y world
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> >
> > rm /var/cache/revdep-rebuild/*.rr
> > revdep-rebuild
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> >
> > etc-update
> > ###
> >
> > It's basically the same as the working section of the above but instead
> > of letting emerge do it's thing, it jackhammers that bitch as hard as
> > possible to get as much updated as possible, but it requires emerge to
> > do something and not error out for no good reason... I expect prune and
> > depclean to be useless but I kinda need update to basically work every
> > time. =\
> > Whatever fails on this script, I just live with until next week/month.
> >
> > ###
> > tortoise ~ # ./pretendupdate
> >
> > These are the packages that would be merged, in order:
> >
> > Calculating dependencies /
> >
> > !!! Problem resolving dependencies for sys-apps/util-linux from @system
> > ... done!
> >
> > !!! The ebuild selected to satisfy "sys-apps/util-linux" has unmet
> > requirements.
> > - sys-apps/util-linux-2.27.1::gentoo USE="caps cramfs ncurses nls pam
> > python readline suid udev unicode -build -fdformat -kill (-selinux)
> > -slang -static-libs -systemd -test -tty-helpers" ABI_X86="32 64 -x32"
> > PYTHON_SINGLE_TARGET="-python2_7 -python3_3 -python3_4"
> > PYTHON_TARGETS="python2_7 python3_4 -python3_3"
> >
> >   The following REQUIRED_USE flag constraints are unsatisfied:
> > python? ( exactly-one-of ( python_single_target_python2_7
> > python_single_target_python3_3 python_single_target_python3_4 ) )
> >
> >   The above constraints are a subset of the following complete
> expression:
> > python? ( exactly-one-of ( python_single_target_python2_7
> > python_single_target_python3_3 python_single_target_python3_4 )
> > python_single_target_python2_7? ( python_targets_python2_7 )
> > python_single_target_python3_3? ( python_targets_python3_3 )
> > python_single_target_python3_4? ( python_targets_python3_4 ) )
> >
> > (dependency required by "@system" [set])
> > (dependency required by "@world" [argument])
> >
> > tortoise ~ # 

Re: [gentoo-user] Pick your hypothesis:

[Dale]

Neil Bothwick wrote:
> On Thu, 24 Jan 2019 13:42:04 -0600, Dale wrote:
>
>> I'm trying to recall but am not sure, is this the same Alan that used to
>> come on here and post this sort of thing when the problem was in the
>> chair not Gentoo?  I recall the person I'm speaking of having a script
>> that just created a mess and then he blamed it on Gentoo.  I might still
>> have some of those emails but someone else may recall if this is the
>> same person or not.
> It is.
>
>


Yep.  I went and found this little gem.  For those interested, this is
the script he used back then.  I'm not sure if he still does today or
not.  Some of you may find it funny.  Some may just cry, for various
reasons.  ;-) 

Alan Grimes wrote:
> I use two scripts for all emerge use, the goal is to run one command and
> then walk away:
>
> Standard general update script:
> ###
> tortoise ~ # cat sysupdate
>
> #they must have moved or removed the logs, might have to track them down
> again...
> #rm /var/log/emerge*
>
> # cache /usr/portage 
> echo "caching /usr/portage.  This will take a long time."
> time ls -R /usr/portage > /dev/null
>
> emerge --sync
> layman --sync ALL
>
> emerge --update --verbose portage
> emerge --update --newuse --deep --with-bdeps=y system --keep-going
> emerge --update --newuse --deep --with-bdeps=y world --keep-going
>
> rm -f /var/cache/revdep-rebuild/*.rr
> revdep-rebuild
> emerge --skipfirst --resume
> emerge --skipfirst --resume
> etc-update
> eclean-dist
> 
>
> The eclean line was added just a few days ago from this thread...
>
> This one is intended to be a nice gentle update script.
> It caches the portage tree, then syncs everything, then updates
> everything starting with critical system packages, then all world
> packages...
>
> Then it cleans stuff up, it jcakhammers the revdep-rebuild but not too
> hard
>
>
> This next script is what I use when emerge starts giving me shit:
>
> ##
> tortoise ~ # cat keepgoing
> emerge --update --newuse --deep --with-bdeps=y system
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
>
> emerge --update --newuse --deep --with-bdeps=y world
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
>
> rm /var/cache/revdep-rebuild/*.rr
> revdep-rebuild
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
>
> etc-update
> ###
>
> It's basically the same as the working section of the above but instead
> of letting emerge do it's thing, it jackhammers that bitch as hard as
> possible to get as much updated as possible, but it requires emerge to
> do something and not error out for no good reason... I expect prune and
> depclean to be useless but I kinda need update to basically work every
> time. =\
> Whatever fails on this script, I just live with until next week/month.
>
> ###
> tortoise ~ # ./pretendupdate
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies /
>
> !!! Problem resolving dependencies for sys-apps/util-linux from @system
> ... done!
>
> !!! The ebuild selected to satisfy "sys-apps/util-linux" has unmet
> requirements.
> - sys-apps/util-linux-2.27.1::gentoo USE="caps cramfs ncurses nls pam
> python readline suid udev unicode -build -fdformat -kill (-selinux)
> -slang -static-libs -systemd -test -tty-helpers" ABI_X86="32 64 -x32"
> PYTHON_SINGLE_TARGET="-python2_7 -python3_3 -python3_4"
> PYTHON_TARGETS="python2_7 python3_4 -python3_3"
>
>   The following REQUIRED_USE flag constraints are unsatisfied:
> python? ( exactly-one-of ( python_single_target_python2_7
> python_single_target_python3_3 python_single_target_python3_4 ) )
>
>   The above constraints are a subset of the following complete expression:
> python? ( exactly-one-of ( python_single_target_python2_7
> python_single_target_python3_3 python_single_target_python3_4 )
> python_single_target_python2_7? ( python_targets_python2_7 )
> python_single_target_python3_3? ( python_targets_python3_3 )
> python_single_target_python3_4? ( python_targets_python3_4 ) )
>
> (dependency required by "@system" [set])
> (dependency required by "@world" [argument])
>
> tortoise ~ # cat ./pretendupdate
> emerge --update --newuse --deep --with-bdeps=y world --verbose --pretend
> tortoise ~ #
>
> ###
>
> Google is not being helpful with this... =(
>


I have to say, the first sentence says a LOT.  Who here runs emerge
without checking to make sure it is going to do what you want it 

Re: [gentoo-user] Pick your hypothesis:

[Neil Bothwick]

On Thu, 24 Jan 2019 13:42:04 -0600, Dale wrote:

> I'm trying to recall but am not sure, is this the same Alan that used to
> come on here and post this sort of thing when the problem was in the
> chair not Gentoo?  I recall the person I'm speaking of having a script
> that just created a mess and then he blamed it on Gentoo.  I might still
> have some of those emails but someone else may recall if this is the
> same person or not.

It is.


-- 
Neil Bothwick

Things are more like they are today than they ever have been before.


pgpSBBbdR01oj.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Pick your hypothesis:

[Dale]

Mike Gilbert wrote:
> On Thu, Jan 24, 2019 at 1:39 PM Alan Grimes  wrote:
>> Some F-tard at Gentoo world headquarters left the portage tree in an
>> inconsistient state, shrugged, and walked away.
> Comments like this are very unwelcome, and your general attitude sucks.
>
> If you continue to communicate this way, I will request you be banned
> from this mailing list.
>
>


I'm trying to recall but am not sure, is this the same Alan that used to
come on here and post this sort of thing when the problem was in the
chair not Gentoo?  I recall the person I'm speaking of having a script
that just created a mess and then he blamed it on Gentoo.  I might still
have some of those emails but someone else may recall if this is the
same person or not.  If it is, I think he was
restricted/banned/something for a while. 

I might add, a LOT of people put him in the /dev/null file back then. 

Anyone have better memory than me?

Dale

:-)  :-) 

P. S.  Keep in mind, there is like three Alans lurking about. 

Re: [gentoo-user] Pick your hypothesis:

[Davyd McColl]

On January 24, 2019 21:22:25 Mike Gilbert  wrote:


On Thu, Jan 24, 2019 at 1:39 PM Alan Grimes  wrote:

Some F-tard at Gentoo world headquarters left the portage tree in an
inconsistient state, shrugged, and walked away.


Comments like this are very unwelcome, and your general attitude sucks.

If you continue to communicate this way, I will request you be banned
from this mailing list.

<3
Look, I'm on the spectrum, so reading people really isn't my thing. It's 
really nice when someone else corroborates my initial impression.

Re: [gentoo-user] Pick your hypothesis:

[Mike Gilbert]

On Thu, Jan 24, 2019 at 1:39 PM Alan Grimes  wrote:
> Some F-tard at Gentoo world headquarters left the portage tree in an
> inconsistient state, shrugged, and walked away.

Comments like this are very unwelcome, and your general attitude sucks.

If you continue to communicate this way, I will request you be banned
from this mailing list.

Re: [gentoo-user] Pick your hypothesis:

[Neil Bothwick]

On Thu, 24 Jan 2019 13:39:52 -0500, Alan Grimes wrote:

> !!! A file listed in the Manifest could not be found:
> /usr/portage/dev-python/pygments/files/pygments-2.2.0-sphinx17.patch
> 
> !!! A file listed in the Manifest could not be found:
> /usr/portage/dev-lang/ruby/files/2.4/012-openssl_1.1.patch
> 
> !!! A file listed in the Manifest could not be found:
> /usr/portage/dev-lang/ruby/files/2.4/012-openssl_1.1.patch

[snip]

Have you checked whether these files actually exist? The do here.

> Hypothesis 1:
> 
> Rsync failed to correctly perform it's primary function.

It seems to have done here.
> 
> Hypothesis 2:
> 
> Some F-tard at Gentoo world headquarters left the portage tree in an
> inconsistient state, shrugged, and walked away.

This isn't worthy of comment.

Hypothesis 3:

PEBKAC

Have you synced again?
Have you checked whether the files exist?
Have you tried doing a simple "emerge -u @system" first instead of trying
to rebuild everything?
Why are you even using --emptytree?

> I'll leave it to you to decide which is more probable.

I think that's clear.

> Spent a good 2 hours on this just now. =|

More like a bad 2 hours, a good ten minutes may have been more productive.


-- 
Neil Bothwick

... but you can't expect to wield supreme executive power just because
some watery tart threw a sword at you!


pgp13GXqdBFeD.pgp
Description: OpenPGP digital signature

[gentoo-user] Pick your hypothesis:

[Alan Grimes]

Evidence:


#

tortoise ~ # emerge --emptytree world

These are the packages that would be merged, in order:

Calculating dependencies... done!

[]

Total: 1601 packages (421 upgrades, 48 new, 3 in new slots, 1129
reinstalls), Size of downloads: 32,663 KiB
Fetch Restriction: 2 packages

>>> Verifying ebuild manifests

!!! A file listed in the Manifest could not be found:
/usr/portage/dev-python/pygments/files/pygments-2.2.0-sphinx17.patch

!!! A file listed in the Manifest could not be found:
/usr/portage/dev-lang/ruby/files/2.4/012-openssl_1.1.patch

!!! A file listed in the Manifest could not be found:
/usr/portage/dev-lang/ruby/files/2.4/012-openssl_1.1.patch

!!! A file listed in the Manifest could not be found:
/usr/portage/app-text/libetonyek/files/libetonyek-0.1.8-no-parentheses.patch
!!! A file is not listed in the Manifest:
'/usr/portage/kde-apps/kde-dev-utils/files/kde-dev-utils-18.04.3-ki18n-5.48.patch'
!!! A file is not listed in the Manifest:
'/usr/portage/kde-apps/kwrite/files/kwrite-18.04.3-root-user.patch'

!!! A file listed in the Manifest could not be found:
/usr/portage/media-video/obs-studio/files/obs-studio-22.0.3-fdk-build-fix.patch




Hypothesis 1:

Rsync failed to correctly perform it's primary function.


Hypothesis 2:

Some F-tard at Gentoo world headquarters left the portage tree in an
inconsistient state, shrugged, and walked away.



I'll leave it to you to decide which is more probable.

Spent a good 2 hours on this just now. =|



-- 
Please report bounces from this address to a...@numentics.com

Powers are not rights.