2 p.m.
Hi,
Running
cat /etc/dnf/dnf.conf | grep install
gives:
installonly_limit=3
So then why do I have 4 kernels ?
$ rpm -q kernel
kernel-5.3.7-301.fc31.x86_64
kernel-5.5.15-200.fc31.x86_64
kernel-5.6.8-200.fc31.x86_64
kernel-5.6.10-300.fc32.x86_64
Shouldn't the 5.3 kernel version be removed ?
Or is it treating the 2 5.6 versions as one ?
--
Regards,
Sreyan
2:21 p.m.
On 5/9/20 12:00 PM, Sreyan Chakravarty wrote:
installonly_limit=3
So then why do I have 4 kernels ?
That's a good question. Watch what happens the next time you have a
kernel update.
$ rpm -q kernel
kernel-5.3.7-301.fc31.x86_64
kernel-5.5.15-200.fc31.x86_64
kernel-5.6.8-200.fc31.x86_64
kernel-5.6.10-300.fc32.x86_64
Shouldn't the 5.3 kernel version be removed ?
Yes.
Or is it treating the 2 5.6 versions as one ?
No.
2:48 a.m.
On 5/10/20 12:43 AM, Sreyan Chakravarty wrote:
On 5/10/20 12:51 AM, Samuel Sieb wrote:
> That's a good question. Watch what happens the next time you have a
> kernel update.
So this is a bug ?
I suppose, but it's not a problem as long as it doesn't keep
accumulating them. And it's probably not reproducible. I'm wondering
if the next kernel will keep 4 or remove 2 to get back to 3.
Did you ever install a kernel directly with rpm or dnf or has it always
been through dnf upgrades?
3:38 a.m.
On 5/10/20 1:18 PM, Samuel Sieb wrote:
Did you ever install a kernel directly with rpm or dnf or has it
always been through dnf upgrades?
All the upgrades I have done is throuugh GNOME software. I didn't use
dnf upgrade. Do you think that will cause a problem ?
--
Regards,
Sreyan
3:58 a.m.
On 2020-05-10 16:38, Sreyan Chakravarty wrote:
On 5/10/20 1:18 PM, Samuel Sieb wrote:
> Did you ever install a kernel directly with rpm or dnf or has it always been through
dnf upgrades?
All the upgrades I have done is throuugh GNOME software. I didn't use dnf upgrade. Do
you think that will cause a problem ?
I don't used gnome software tools to update. However, I think I read that the gnome
stuff does now
use dnf.
If you type
sudo dnf history
do you get a list of transactions?
If so, you should be able to find the ones with kernel updates and check to see if
something odd happend.
--
The key to getting good answers is to ask good questions.
6:15 a.m.
On 5/10/20 2:28 PM, Ed Greshko wrote:
I don't used gnome software tools to update. However, I think I
read that the gnome stuff does now
use dnf.
Yeah, I want to do the same. Could you please share the dnf commands you
use for an upgrade and a full distribution upgrade(Upgrading from F31 to
F32) ?
If you type
sudo dnf history
do you get a list of transactions?
Nopes, this is what I get :
$ dnf history
ID | Command line | Date and time | Action(s) |
Altered
--------------------------------------------------------------------------------
19 | | 2020-05-09 18:02 | D, E, I, U
| 2335
18 | install -y hexchat | 2020-05-09 16:14 | Install
| 1
17 | | 2020-05-09 15:14 | I, U
| 227
16 | group install --with-opti | 2020-05-02 07:31 | I, U
| 61
15 | | 2020-05-02 06:28 | Install
| 1
14 | install neovim python3-ne | 2020-04-29 00:18 | Install
| 13
13 | remove vim-X11 | 2020-04-29 00:17 | Removed
| 2
12 | install powerline-fonts | 2020-04-18 20:44 | Install
| 1
11 | | 2020-04-13 22:10 | Upgrade
| 1
10 | | 2020-04-13 22:07 | Removed
| 1
9 | | 2020-04-13 22:06 | Removed
| 1
8 | | 2020-04-13 22:06 | Removed
| 1
7 | install vlc | 2020-04-13 21:48 | Install
| 62
6 | | 2020-04-13 20:06 | Install
| 2
5 | | 2020-04-13 18:17 | Install
| 1
4 | | 2020-04-13 18:17 | Install
| 1
3 | | 2020-04-13 17:19 | E, I, U
| 1115
2 | | 2020-04-13 17:04 | Install
| 1
1 | | 2020-04-13 16:42 | Install
| 2197 EE
As you can see there is no mention of an upgrade here. I wonder if that
is because Gnome uses a seperate tty for it or not.
--
Regards,
Sreyan
6:27 a.m.
On 2020-05-10 19:15, Sreyan Chakravarty wrote:
On 5/10/20 2:28 PM, Ed Greshko wrote:
> I don't used gnome software tools to update. However, I think I read that the
gnome stuff does now
> use dnf.
Yeah, I want to do the same. Could you please share the dnf commands you use for an
upgrade and a full distribution upgrade(Upgrading from F31 to F32) ?
This is a good reference.
https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
>
> If you type
>
> sudo dnf history
>
> do you get a list of transactions?
Nopes, this is what I get :
$ dnf history
ID | Command line | Date and time | Action(s) | Altered
--------------------------------------------------------------------------------
19 | | 2020-05-09 18:02 | D, E, I, U | 2335
18 | install -y hexchat | 2020-05-09 16:14 | Install | 1
17 | | 2020-05-09 15:14 | I, U | 227
As you can see there is no mention of an upgrade here. I wonder if that is because Gnome
uses a seperate tty for it or not.
It does look as if a system upgrade using the gnome tools does something different.
I suppose I should learn what it does....someday. :-)
--
The key to getting good answers is to ask good questions.
6:24 a.m.
On Sun, 10 May 2020 at 08:28, Ed Greshko <ed.greshko(a)greshko.com> wrote:
On 2020-05-10 19:15, Sreyan Chakravarty wrote:
>
> On 5/10/20 2:28 PM, Ed Greshko wrote:
>> I don't used gnome software tools to update. However, I think I read
that the gnome stuff does now
>> use dnf.
> Yeah, I want to do the same. Could you please share the dnf commands you
use for an upgrade and a full distribution upgrade(Upgrading from F31 to
F32) ?
This is a good reference.
https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
>>
>> If you type
>>
>> sudo dnf history
>>
>> do you get a list of transactions?
>
> Nopes, this is what I get :
>
> $ dnf history
>
> ID | Command line | Date and time | Action(s) |
Altered
>
--------------------------------------------------------------------------------
> 19 | | 2020-05-09 18:02 | D, E, I, U |
2335
> 18 | install -y hexchat | 2020-05-09 16:14 | Install
| 1
> 17 | | 2020-05-09 15:14 | I, U
| 227
>
>
> As you can see there is no mention of an upgrade here. I wonder if that
is because Gnome uses a seperate tty for it or not.
>
It does look as if a system upgrade using the gnome tools does something
different.
I suppose I should learn what it does....someday. :-)
Quoting from an Above the Line, Below the Line in ACM Queue by Richard I.
Cook, M.D. <https://queue.acm.org/detail.cfm?id=3380777>
“Near-constant effort is required to calibrate and refresh the
understanding of the workings, dependencies, limitations, and capabilities
of what is present,” Cook writes. “Individuals and groups must be content
with partial, fragmented mental models that require more or less constant
updating and adjustment if they are to be useful.”
The article is about Internet facing systems, but much of what he says
applies to modern linux distro GUI's.
--
George N. White III
6:52 a.m.
Quoting from an Above the Line, Below the Line in ACM Queue by Richard I.
Cook, M.D. <https://queue.acm.org/detail.cfm?id=3380777>
“Near-constant effort is required to calibrate and refresh the
understanding of the workings, dependencies, limitations, and capabilities
of what is present,” Cook writes. “Individuals and groups must be content
with partial, fragmented mental models that require more or less constant
updating and adjustment if they are to be useful.”
The article is about Internet facing systems, but much of what he says
applies to modern linux distro GUI's.
I have no idea what is the relevance of this.
On Mon, May 11, 2020 at 4:55 PM George N. White III <gnwiii(a)gmail.com>
wrote:
On Sun, 10 May 2020 at 08:28, Ed Greshko
<ed.greshko(a)greshko.com> wrote:
> On 2020-05-10 19:15, Sreyan Chakravarty wrote:
> >
> > On 5/10/20 2:28 PM, Ed Greshko wrote:
> >> I don't used gnome software tools to update. However, I think I read
> that the gnome stuff does now
> >> use dnf.
> > Yeah, I want to do the same. Could you please share the dnf commands
> you use for an upgrade and a full distribution upgrade(Upgrading from F31
> to F32) ?
>
> This is a good reference.
>
> https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
>
> >>
> >> If you type
> >>
> >> sudo dnf history
> >>
> >> do you get a list of transactions?
> >
> > Nopes, this is what I get :
> >
> > $ dnf history
> >
> > ID | Command line | Date and time | Action(s)
> | Altered
> >
> --------------------------------------------------------------------------------
> > 19 | | 2020-05-09 18:02 | D, E, I, U
> | 2335
> > 18 | install -y hexchat | 2020-05-09 16:14 | Install
> | 1
> > 17 | | 2020-05-09 15:14 | I, U
> | 227
> >
> >
> > As you can see there is no mention of an upgrade here. I wonder if that
> is because Gnome uses a seperate tty for it or not.
> >
>
> It does look as if a system upgrade using the gnome tools does something
> different.
> I suppose I should learn what it does....someday. :-)
>
Quoting from an Above the Line, Below the Line in ACM Queue by Richard I.
Cook, M.D. <https://queue.acm.org/detail.cfm?id=3380777>
“Near-constant effort is required to calibrate and refresh the
understanding of the workings, dependencies, limitations, and capabilities
of what is present,” Cook writes. “Individuals and groups must be content
with partial, fragmented mental models that require more or less constant
updating and adjustment if they are to be useful.”
The article is about Internet facing systems, but much of what he says
applies to modern linux distro GUI's.
--
George N. White III
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
--
Regards,
Sreyan Chakravarty
6:57 a.m.
On 2020-05-11 19:52, Sreyan Chakravarty wrote:
Quoting from an Above the Line, Below the Line in ACM Queue by Richard I. Cook, M.D.
<https://queue.acm.org/detail.cfm?id=3380777>
“Near-constant effort is required to calibrate and refresh the understanding of the
workings, dependencies, limitations, and capabilities of what is present,” Cook writes.
“Individuals and groups must be content with partial, fragmented mental models that
require more or less constant updating and adjustment if they are to be useful.”
The article is about Internet facing systems, but much of what he says applies to
modern linux distro GUI's.
I have no idea what is the relevance of this.
To your issue, no.
To my comment about learning/determining how GNOME does system-upgrades, yes.
--
The key to getting good answers is to ask good questions.
7:04 a.m.
To your issue, no.
To my comment about learning/determining how GNOME does system-upgrades,
yes.
Is there a Fedora Gnome team that I can reach out to ?
On Mon, May 11, 2020 at 5:28 PM Ed Greshko <ed.greshko(a)greshko.com> wrote:
On 2020-05-11 19:52, Sreyan Chakravarty wrote:
>
> Quoting from an Above the Line, Below the Line in ACM Queue
by Richard I. Cook, M.D. <https://queue.acm.org/detail.cfm?id=3380777>
> “Near-constant effort is required to calibrate and refresh the
understanding of the workings, dependencies, limitations, and capabilities
of what is present,” Cook writes. “Individuals and groups must be content
with partial, fragmented mental models that require more or less constant
updating and adjustment if they are to be useful.”
>
> The article is about Internet facing systems, but much of what he
says applies to modern linux distro GUI's.
>
>
> I have no idea what is the relevance of this.
>
To your issue, no.
To my comment about learning/determining how GNOME does system-upgrades,
yes.
--
The key to getting good answers is to ask good questions.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
--
Regards,
Sreyan Chakravarty
7:14 a.m.
On 2020-05-11 20:04, Sreyan Chakravarty wrote:
To your issue, no.
To my comment about learning/determining how GNOME does system-upgrades, yes.
Is there a Fedora Gnome team that I can reach out to ?
I don't know.... But, I still think this is a very minor issue that probably
won't happen again.
And the cause will be hard to determine as so much time has passed.
Which is why I'd be deleting the old kernel and just check after the next kernel
date.
--
The key to getting good answers is to ask good questions.
7:33 a.m.
I don't know.... But, I still think this is a very minor issue that
probably won't happen again.
I hope so. Lets leave it at that then.
On Mon, May 11, 2020 at 5:46 PM Ed Greshko <ed.greshko(a)greshko.com> wrote:
> On 2020-05-11 20:04, Sreyan Chakravarty wrote:
> >
> > To your issue, no.
> > To my comment about learning/determining how GNOME does
> system-upgrades, yes.
> >
> >
> > Is there a Fedora Gnome team that I can reach out to ?
> >
I don't know.... But, I still think this is a very minor issue that
probably won't happen again.
> And the cause will be hard to determine as so
much time has passed.
> Which is why I'd be deleting the old kernel and just check after the next
> kernel date.
>
> --
> The key to getting good answers is to ask good questions.
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
>
--
Regards,
Sreyan Chakravarty
2:23 p.m.
On 5/10/20 4:57 PM, Ed Greshko wrote:
It does look as if a system upgrade using the gnome tools does
something different.
I suppose I should learn what it does....someday.:-)
GNOME uses a system called PackageKit. It makes sense I will be having
more kernels even though I have 3 install candidates set in DNF.
Thus, PackageKit has no reason to obey a setting in DNF does it.
--
Regards,
Sreyan
3:01 p.m.
On 5/11/20 12:23 PM, Sreyan Chakravarty wrote:
On 5/10/20 4:57 PM, Ed Greshko wrote:
> It does look as if a system upgrade using the gnome tools does
> something different.
> I suppose I should learn what it does....someday.:-)
GNOME uses a system called PackageKit. It makes sense I will be having
more kernels even though I have 3 install candidates set in DNF.
Thus, PackageKit has no reason to obey a setting in DNF does it.
PackageKit uses dnf (or at least libdnf) to do the work.
6:05 p.m.
On 2020-05-12 04:33, Samuel Sieb wrote:
On 5/11/20 1:03 PM, Sreyan Chakravarty wrote:
>
> On 5/12/20 1:31 AM, Samuel Sieb wrote:
>> PackageKit uses dnf (or at least libdnf) to do the work.
>
> And the mystery deepens...
>
> Then why isn't it respecting my settings?
Just wait for the next kernel update and see what happens.
OK, are you ready for the "answer"?
I resurrected an F30 GNOME only VM. I then used the GNOME System Upgrade Method to
upgrade
to F32.
Before Upgrade
[egreshko@f30g ~]$ cat Before-Upgrade
kernel-5.5.8-100.fc30.x86_64
kernel-5.5.10-100.fc30.x86_64
kernel-5.6.8-100.fc30.x86_64
After Upgrade
[egreshko@f30g ~]$ cat After-Upgrade
kernel-5.5.8-100.fc30.x86_64
kernel-5.5.10-100.fc30.x86_64
kernel-5.6.8-100.fc30.x86_64
kernel-5.6.10-300.fc32.x86_64
So, we can see that the GNOME Method will leave an extra kernel, unlike using dnf
system-upgrade.
But then, I enabled updates-testing and ran packagekit from the command line "pkcon
update" as there
is a new kernel in updates-testing.
And now......
[egreshko@f30g ~]$ rpm -q kernel
kernel-5.6.8-100.fc30.x86_64
kernel-5.6.10-300.fc32.x86_64
kernel-5.6.11-300.fc32.x86_64
So, everything will go back to normal when the kernel updates get pushed.
What a way to waste a morning. :-) :-) :-)
--
The key to getting good answers is to ask good questions.
6:12 p.m.
On 5/11/20 4:05 PM, Ed Greshko wrote:
On 2020-05-12 04:33, Samuel Sieb wrote:
> On 5/11/20 1:03 PM, Sreyan Chakravarty wrote:
>>
>> On 5/12/20 1:31 AM, Samuel Sieb wrote:
>>> PackageKit uses dnf (or at least libdnf) to do the work.
>>
>> And the mystery deepens...
>>
>> Then why isn't it respecting my settings?
>
> Just wait for the next kernel update and see what happens.
OK, are you ready for the "answer"?
I resurrected an F30 GNOME only VM. I then used the GNOME System Upgrade Method to
upgrade
to F32.
Before Upgrade
[egreshko@f30g ~]$ cat Before-Upgrade
kernel-5.5.8-100.fc30.x86_64
kernel-5.5.10-100.fc30.x86_64
kernel-5.6.8-100.fc30.x86_64
After Upgrade
[egreshko@f30g ~]$ cat After-Upgrade
kernel-5.5.8-100.fc30.x86_64
kernel-5.5.10-100.fc30.x86_64
kernel-5.6.8-100.fc30.x86_64
kernel-5.6.10-300.fc32.x86_64
So, we can see that the GNOME Method will leave an extra kernel, unlike using dnf
system-upgrade.
Does that mean that PackageKit doesn't respect the install_only setting
during a system upgrade? Sounds like a bug. I wonder if there are
other settings it neglects then as well.
6:23 p.m.
On 2020-05-12 07:12, Samuel Sieb wrote:
Does that mean that PackageKit doesn't respect the install_only
setting during a system upgrade? Sounds like a bug. I wonder if there are
other settings it neglects then as well.
It would appear so....
There is a dnf transaction history for the system upgrade using the GNOME Method.
16 | | 2020-05-12 06:19 | E, I, U | 1676
With these entries...
Install kernel-5.6.10-300.fc32.x86_64 @updates
Install kernel-core-5.6.10-300.fc32.x86_64 @updates
Install kernel-modules-5.6.10-300.fc32.x86_64 @updates
Upgraded kernel-headers-5.6.7-100.fc30.x86_64 @@System
Unlike in a dnf system upgrade which shows (I do have a few more kernel* packages
installed
this system)
Install kernel-5.6.6-300.fc32.x86_64
@fedora
Install kernel-core-5.6.6-300.fc32.x86_64
@fedora
Install kernel-devel-5.6.6-300.fc32.x86_64
@fedora
Install kernel-modules-5.6.6-300.fc32.x86_64
@fedora
Install kernel-modules-extra-5.6.6-300.fc32.x86_64
@fedora
Upgrade kernel-headers-5.6.6-300.fc32.x86_64
@fedora
Removed kernel-5.5.15-200.fc31.x86_64
@@System
Removed kernel-core-5.5.15-200.fc31.x86_64
@@System
Removed kernel-devel-5.5.15-200.fc31.x86_64
@@System
Removed kernel-modules-5.5.15-200.fc31.x86_64
@@System
Removed kernel-modules-extra-5.5.15-200.fc31.x86_64
@@System
Maybe I'd call it a "transient bug"? :-)
--
The key to getting good answers is to ask good questions.
9:53 p.m.
On 2020-05-12 07:23, Ed Greshko wrote:
Maybe I'd call it a "transient bug"?
For completeness I restored the "Before" snapshot and ran
pkcon upgrade-system 32
from the command line. I expected it to download the packages and tell me to reboot to
complete the process. But it didn't. It upgraded "live".
Upon reboot there were 4 kernels.
So, if anyone is interested they can file a Bugzilla against packagekit.
--
The key to getting good answers is to ask good questions.
6:26 a.m.
On 5/12/20 8:23 AM, Ed Greshko wrote:
So, if anyone is interested they can file a Bugzilla against
packagekit.
I will be doing that then.
I have a couple of questions about System Upgradation via DNF from this doc:
https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
1) If I want to update my system do I do:
sudo dnf upgrade --refresh
or
sudo dnf system-upgrade reboot
What is the difference between the two ? And when should use one over
the other ?
2) Will
sudo dnf upgrade --refresh
result in a reboot or do I have to do it manually ?
--
Regards,
Sreyan
6:49 a.m.
On 2020-05-12 19:26, Sreyan Chakravarty wrote:
I have a couple of questions about System Upgradation via DNF from this doc:
https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
<rant>
I have a issue in the way words are used in the "Fedora Project". I think my
issue
stems from my days as a hardware engineer.
It seems that the words "upgrade" and "update" are used
interchangeably. I personally
don't see it that way. To me "update" means to apply changes to the current
"release"
release. While "upgrade" means to go from one release to a newer release.
<\rant>
But, now on to your question.
1) If I want to update my system do I do:
sudo dnf upgrade --refresh
The above will update the current system with packages that are in the repository
"updates"
that are currently installed on your system.
or
sudo dnf system-upgrade reboot
The above command is not to be used on its own. It is done after the command
sudo dnf system-upgrade download --refresh --releasever=###
These commands are used in combination to upgrade a system from one release to another.
Like F31 to F32.
The "dnf system-upgrade download" command will download the packages for the
next release
and do a verification that the upgrade can proceed. It will also download the new
gpg-keys.
The actual install of the download packages will happen when doing "sudo dnf
system-upgrade reboot"
in a "disconnected" fashion.
What is the difference between the two ? And when should use one over the other ?
2) Will
sudo dnf upgrade --refresh
result in a reboot or do I have to do it manually ?
The above will not result in a reboot. Generally speaking the decision to reboot or not
is up to the
user. There are many opinions on when/why to reboot. I can only tell you what I do....
I did "sudo dnf install tracer" on all my systems and then after every update I
run
sudo tracer
And act on the advice given.
--
The key to getting good answers is to ask good questions.
7:40 a.m.
On Tue, 2020-05-12 at 19:49 +0800, Ed Greshko wrote:
<rant>
I have a issue in the way words are used in the "Fedora Project". I think my
issue
stems from my days as a hardware engineer.
It seems that the words "upgrade" and "update" are used
interchangeably. I personally
don't see it that way. To me "update" means to apply changes to the
current "release"
release. While "upgrade" means to go from one release to a newer release.
<\rant>
I tend to agree, but I think the reason is historical. IIRC at one time
there was a distinction in "yum" between the two terms (which reflect a
distinction in the apt universe, which still AFAIK persists), but for
some time now that distinction has disappeared, i.e. yum and dnf both
treat the two terms as equivalent. It's unfortunate, but there it is.
poc
9:40 a.m.
New subject: OT: Re: Why do I have 4 kernels when the install limit is 3 ?
On Tue, 12 May 2020 19:49:41 +0800
Ed Greshko <ed.greshko(a)greshko.com> wrote:
<rant>
I have a issue in the way words are used in the "Fedora Project". I
think my issue stems from my days as a hardware engineer.
It seems that the words "upgrade" and "update" are used
interchangeably. I personally don't see it that way. To me "update"
means to apply changes to the current "release" release. While
"upgrade" means to go from one release to a newer release. <\rant>
I agree. I think this would be the common interpretation for native
speakers of English, though I certainly don't know that for sure. It
has always bothered me, like a small grain of sand in my shoe while I'm
walking.
9:53 a.m.
New subject: OT: Re: Why do I have 4 kernels when the install limit is 3 ?
On 5/12/20 7:40 AM, stan via users wrote:
On Tue, 12 May 2020 19:49:41 +0800
Ed Greshko <ed.greshko(a)greshko.com> wrote:
> <rant>
> I have a issue in the way words are used in the "Fedora Project". I
> think my issue stems from my days as a hardware engineer.
>
> It seems that the words "upgrade" and "update" are used
> interchangeably. I personally don't see it that way. To me "update"
> means to apply changes to the current "release" release. While
> "upgrade" means to go from one release to a newer release. <\rant>
I agree. I think this would be the common interpretation for native
speakers of English, though I certainly don't know that for sure. It
has always bothered me, like a small grain of sand in my shoe while I'm
walking.
In the ubuntu universe "update" means to refresh the list of repos while
"upgrade" means to bring the current release up to date. To move to the
next release version is to "do-release-upgrade".
update and up to date could certainly be confused, especially by a
non-native speaker :/
11:03 a.m.
New subject: OT: Re: Why do I have 4 kernels when the install limit is 3 ?
On Tue, 12 May 2020 at 11:40, stan via users <users(a)lists.fedoraproject.org>
wrote:
On Tue, 12 May 2020 19:49:41 +0800
Ed Greshko <ed.greshko(a)greshko.com> wrote:
> <rant>
> I have a issue in the way words are used in the "Fedora Project". I
> think my issue stems from my days as a hardware engineer.
>
> It seems that the words "upgrade" and "update" are used
> interchangeably. I personally don't see it that way. To me "update"
> means to apply changes to the current "release" release. While
> "upgrade" means to go from one release to a newer release. <\rant>
I agree. I think this would be the common interpretation for native
speakers of English, though I certainly don't know that for sure. It
has always bothered me, like a small grain of sand in my shoe while I'm
walking.
For me, a native English speaker (living in Canada with many native French
speaking colleagues), update implies bringing something up to the current
state, while upgrade implies adding some new capabilities. The difference
IS confusing to non-native speakers. As Mike says, Debian-based
distros use "update" in reference to package metadata. Having multiple
tools (dnf, Gnome) indicates neither tool is fully satisfactory. Debian
also
suffers from having multiple tools with different behaviours.
Debian Reference Chapter 2.1.7: The Event Flow of the Package Management
(sic)
<https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_the_eve...
Our understanding of package management has improved over the years, but
the terminology has lagged. Debian Reference Table 2.6 gives a number of
command-line examples. The first 7 lines are basic operations needed to
install, upgrade, or remove packages with variations (include dependencies,
remove packages while preserving configuration files or not, handling of
conflicts).
I like Debian aptitude's ability to show you conflicts and offer a variety
of
resolutions, but sometimes misses the appropriate solution.
There is the macports project on macOS, but since it doesn't touch the OS
it has an easier job than linux package managers. Macports' package
manager is called "port":
port sync -- downloads current package metadata
port list outdated -- shows candidates for upgrading
port upgrade outdated except <list of packages to keep at current
version>
Certainly "sync" is a better term for metadata "updating" as it
implies
making
a local metadata store match the master store.
--
George N. White III
6:47 a.m.
On 5/12/20 8:23 AM, Ed Greshko wrote:
So, if anyone is interested they can file a Bugzilla against
packagekit.
And here is the shiny new bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1834770
--
Regards,
Sreyan
6:33 a.m.
On 5/12/20 4:42 AM, Samuel Sieb wrote:
Does that mean that PackageKit doesn't respect the install_only
setting during a system upgrade? Sounds like a bug. I wonder if
there are other settings it neglects then as well.
Which is why I think it is potentially dangerous to use PackageKit for
any upgradation.
Clearly something weird is going on here.
--
Regards,
Sreyan
6:55 a.m.
On 2020-05-12 19:33, Sreyan Chakravarty wrote:
On 5/12/20 4:42 AM, Samuel Sieb wrote:
> Does that mean that PackageKit doesn't respect the install_only setting during a
system upgrade? Sounds like a bug. I wonder if there are other settings it neglects then
as well.
Which is why I think it is potentially dangerous to use PackageKit for any upgradation.
Clearly something weird is going on here.
PackageKit has been used for quite some time and predates dnf.
There is no inherent "danger" in using packagekit. Having 4 installed kernels
presents no "danger".
So, I feel you need to define what you mean by that word.
--
The key to getting good answers is to ask good questions.
7:18 a.m.
On 5/12/20 5:25 PM, Ed Greshko wrote:
So, I feel you need to define what you mean by that word.
I always prefer software that works as expected.
My /boot is 68% full. I am worried that the next upgrade will not go
through due to lack to space.
That's why I wanted to know about the DNF commands in more detail.
--
Regards,
Sreyan
7:33 a.m.
On 2020-05-12 20:18, Sreyan Chakravarty wrote:
On 5/12/20 5:25 PM, Ed Greshko wrote:
> So, I feel you need to define what you mean by that word.
I always prefer software that works as expected.
Well, for all we know, the packagekit upgrade is expected to not remove
"running" kernel.
As a matter of fact, after I wrote that, I bet that is the intended behavior. Why?
Because in my "testing" I did do "pkcon upgrade-system 32" and the
upgrade from
F30 to F32 was done *Live". If the process were to delete the current running kernel
it would
have been a disaster.
My /boot is 68% full. I am worried that the next upgrade will not go through due to lack
to space.
The % isn't important. It is the free space. I think an kernel upgrade really only
needs an
additional 50MB or so.
--
The key to getting good answers is to ask good questions.
3:59 p.m.
On 5/12/20 5:33 AM, Ed Greshko wrote:
On 2020-05-12 20:18, Sreyan Chakravarty wrote:
>
> On 5/12/20 5:25 PM, Ed Greshko wrote:
>> So, I feel you need to define what you mean by that word.
>
> I always prefer software that works as expected.
Well, for all we know, the packagekit upgrade is expected to not remove
"running" kernel.
As a matter of fact, after I wrote that, I bet that is the intended behavior. Why?
Because in my "testing" I did do "pkcon upgrade-system 32" and the
upgrade from
F30 to F32 was done *Live". If the process were to delete the current running
kernel it would
have been a disaster.
dnf specifically will not remove the running kernel. Even if you are
running the oldest kernel, it will not be removed. It will remove the
oldest kernel that you are not running. So, this should be irrelevant
to the packagekit issue.
4:51 p.m.
On 2020-05-13 04:59, Samuel Sieb wrote:
On 5/12/20 5:33 AM, Ed Greshko wrote:
> On 2020-05-12 20:18, Sreyan Chakravarty wrote:
>>
>> On 5/12/20 5:25 PM, Ed Greshko wrote:
>>> So, I feel you need to define what you mean by that word.
>>
>> I always prefer software that works as expected.
>
> Well, for all we know, the packagekit upgrade is expected to not remove
"running" kernel.
>
> As a matter of fact, after I wrote that, I bet that is the intended behavior. Why?
>
> Because in my "testing" I did do "pkcon upgrade-system 32" and
the upgrade from
> F30 to F32 was done *Live". If the process were to delete the current running
kernel it would
> have been a disaster.
dnf specifically will not remove the running kernel. Even if you are running the oldest
kernel, it will not be removed. It will remove the oldest kernel that you are not
running. So, this should be irrelevant to the packagekit issue.
Yes, "dnf" will not remove the running kernel. But, are we 100% certain that
"pkcon" follows the same
rule? I suppose I could try it on a VM to test. And even if it doesn't
"today", it didn't always use libdnf.
So, it could be a remnant.
--
The key to getting good answers is to ask good questions.
5:50 p.m.
On 2020-05-13 05:51, Ed Greshko wrote:
On 2020-05-13 04:59, Samuel Sieb wrote:
> dnf specifically will not remove the running kernel. Even if you are running the
oldest kernel, it will not be removed. It will remove the oldest kernel that you are not
running. So, this should be irrelevant to the packagekit issue.
Yes, "dnf" will not remove the running kernel. But, are we 100% certain that
"pkcon" follows the same
rule? I suppose I could try it on a VM to test. And even if it doesn't
"today", it didn't always use libdnf.
So, it could be a remnant.
Well.....
[root@f30g ~]# uname -r
5.6.8-100.fc30.x86_64
[root@f30g ~]# pkcon remove kernel
Resolving [=========================] More than one package
matches:
1. kernel-5.5.8-100.fc30.x86_64 [installed:updates]
2. kernel-5.5.10-100.fc30.x86_64 [installed:updates]
3. kernel-5.6.8-100.fc30.x86_64 [installed:updates]
Please choose the correct package: 3
[=========================]
Starting [=========================]
Testing changes [=========================]
Finished [ ] (0%)
The following packages have to be removed:
kernel-5.6.8-100.fc30.x86_64 The Linux kernel
Proceed with changes? [N/y] y
[=========================]
Testing changes [=========================]
Removing [=========================]
Requesting data [=========================]
Finished [=========================]
[root@f30g ~]# rpm -q kernel
kernel-5.5.8-100.fc30.x86_64
kernel-5.5.10-100.fc30.x86_64
However, it didn't actually delete anything since upon reboot it was still in the boot
menu and
[root@f30g ~]# uname -r
5.6.8-100.fc30.x86_64
But still...
[root@f30g ~]# rpm -q kernel
kernel-5.5.8-100.fc30.x86_64
kernel-5.5.10-100.fc30.x86_64
So, it is at least marked as removed in the rpm database. This probably will result in
images being left on
disk. Not a big deal but could cause some confusion to the user at some point.
Maybe that would be a similar result on an "upgrade-system"?
Oh, and for the record....
[root@f30g ~]# dnf erase kernel-5.6.8
Dependencies resolved.
================================================================================
Package Architecture Version Repository Size
================================================================================
Removing:
kernel x86_64 5.6.8-100.fc30 @updates 0
Transaction Summary
================================================================================
Remove 1 Package
Freed space: 0
Is this ok [y/N]: y
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Erasing : kernel-5.6.8-100.fc30.x86_64 1/1
Running scriptlet: kernel-5.6.8-100.fc30.x86_64 1/1
Verifying : kernel-5.6.8-100.fc30.x86_64 1/1
Removed:
kernel-5.6.8-100.fc30.x86_64
Complete!
[root@f30g ~]# uname -r
5.6.8-100.fc30.x86_64
[root@f30g ~]# rpm -q kernel
kernel-5.5.8-100.fc30.x86_64
kernel-5.5.10-100.fc30.x86_64
So, dnf does the same.
FWIW, this holds true for "erase" of any kernel. It just translates in to
"mark uninstalled".
Anyway, I think this has been flogged enough. :-)
--
The key to getting good answers is to ask good questions.
6:01 p.m.
On 5/12/20 3:50 PM, Ed Greshko wrote:
However, it didn't actually delete anything since upon reboot it
was still in the boot menu and
That should have been your clue that you missed something. You were
tricked! :-)
"kernel" is a metapackage and contains nothing:
# rpm -ql kernel
(contains no files)
Try doing the same thing with kernel-core:
# dnf remove kernel-core-5.5.17-200.fc31.x86_64
Error:
Problem: The operation would result in removing the following
protected packages: kernel-core
(try to add '--skip-broken' to skip uninstallable packages)
6:19 p.m.
On 2020-05-13 07:01, Samuel Sieb wrote:
On 5/12/20 3:50 PM, Ed Greshko wrote:
> However, it didn't actually delete anything since upon reboot it was still in the
boot menu and
That should have been your clue that you missed something. You were tricked! :-)
Not a surprise at 06:50 and no coffee.....
"kernel" is a metapackage and contains nothing:
# rpm -ql kernel
(contains no files)
Try doing the same thing with kernel-core:
# dnf remove kernel-core-5.5.17-200.fc31.x86_64
Error:
Problem: The operation would result in removing the following protected packages:
kernel-core
(try to add '--skip-broken' to skip uninstallable packages)
[root@f30g ~]# pkcon remove kernel-core-5.6.8-100
Resolving [=========================] Package not found:
kernel-core-5.6.8-100
Command failed: This tool could not find the installed package: No packages were found
[root@f30g ~]# pkcon remove kernel-core-5.6.8-100.fc30.x86_64
Resolving [=========================] Package not found:
kernel-core-5.6.8-100.fc30.x86_64
Command failed: This tool could not find the installed package: No packages were found
And even an earlier one....
[root@f30g ~]# pkcon remove kernel-core-5.5.8-100.fc30.x86_64
Resolving [=========================] Package not found:
kernel-core-5.5.8-100.fc30.x86_64
Command failed: This tool could not find the installed package: No packages were found
I suppose the bigger question is: Why am I doing this? :-) :-)
--
The key to getting good answers is to ask good questions.
6:31 a.m.
On 5/12/20 4:35 AM, Ed Greshko wrote:
I resurrected an F30 GNOME only VM. I then used the GNOME System
Upgrade Method to upgrade
to F32.
This is what I will be trying now. Completely forgot about this.
But then, I enabled updates-testing and ran packagekit from the
command line "pkcon update" as there
is a new kernel in updates-testing.
And now......
[egreshko@f30g ~]$ rpm -q kernel
kernel-5.6.8-100.fc30.x86_64
kernel-5.6.10-300.fc32.x86_64
kernel-5.6.11-300.fc32.x86_64
So are you saying that once there are 3 kernels in
5.6 it will get rid
of 5.5 ? I did not understand clearly what was going on here.
--
Regards,
Sreyan
6:52 a.m.
On 2020-05-12 19:31, Sreyan Chakravarty wrote:
On 5/12/20 4:35 AM, Ed Greshko wrote:
> I resurrected an F30 GNOME only VM. I then used the GNOME System Upgrade Method to
upgrade
> to F32.
This is what I will be trying now. Completely forgot about this.
> But then, I enabled updates-testing and ran packagekit from the command line
"pkcon update" as there
> is a new kernel in updates-testing.
>
> And now......
>
> [egreshko@f30g ~]$ rpm -q kernel
> kernel-5.6.8-100.fc30.x86_64
> kernel-5.6.10-300.fc32.x86_64
> kernel-5.6.11-300.fc32.x86_64
So are you saying that once there are 3 kernels in 5.6 it will get rid of 5.5 ? I did not
understand clearly what was going on here.
I am saying that when a new kernel is available or install from the "updates"
repo and the latest kernel is
installed the 5.5 kernel will be erased as well as one oldest 5.6 kernels to give what is
expected. That is
3 installed kernels. I "forced" the install of the latest 5.6 kernel from
"updates-testing".
--
The key to getting good answers is to ask good questions.
7:15 a.m.
On 5/12/20 5:22 PM, Ed Greshko wrote:
I am saying that when a new kernel is available or install from the
"updates" repo and the latest kernel is
installed the 5.5 kernel will be erased as well as one oldest 5.6 kernels to give what is
expected. That is
3 installed kernels. I "forced" the install of the latest 5.6 kernel from
"updates-testing".
So this upgrade was not a "system" upgrade. Correct ?
That means the settings are not respected for system upgrades only.
Correct ?
--
Regards,
Sreyan
7:25 a.m.
On 2020-05-12 20:15, Sreyan Chakravarty wrote:
On 5/12/20 5:22 PM, Ed Greshko wrote:
> I am saying that when a new kernel is available or install from the
"updates" repo and the latest kernel is
> installed the 5.5 kernel will be erased as well as one oldest 5.6 kernels to give
what is expected. That is
> 3 installed kernels. I "forced" the install of the latest 5.6 kernel from
"updates-testing".
So this upgrade was not a "system" upgrade. Correct ?
Yes, this is an "upgrade" (I would prefer using update) of the current version.
It is not a "system upgrade".
That means the settings are not respected for system upgrades only. Correct ?
Yes, the issue with having more kernels than defined in the settings is only a problem
on an "upgrade". That is going from F## to F##+X.
--
The key to getting good answers is to ask good questions.
8:11 a.m.
On 5/12/20 5:55 PM, Ed Greshko wrote:
Yes, the issue with having more kernels than defined in the settings
is only a problem
on an "upgrade". That is going from F## to F##+X.
Well, I got news.
I just did an update through Gnome software. It removed both my 5.5 and
5.3 kernels. Now I have only 3 kernels :
Installed Packages
kernel.x86_64 5.6.8-200.fc31 @updates
kernel.x86_64 5.6.10-300.fc32 @updates
kernel.x86_64 5.6.11-300.fc32 @updates
Well, this was a wild goose chase. I will closing the bug.
--
Regards,
Sreyan
4:02 p.m.
On 5/12/20 6:11 AM, Sreyan Chakravarty wrote:
On 5/12/20 5:55 PM, Ed Greshko wrote:
> Yes, the issue with having more kernels than defined in the settings
> is only a problem
> on an "upgrade". That is going from F## to F##+X.
Well, I got news.
I just did an update through Gnome software. It removed both my 5.5 and
5.3 kernels. Now I have only 3 kernels :
Installed Packages
kernel.x86_64 5.6.8-200.fc31 @updates
kernel.x86_64 5.6.10-300.fc32 @updates
kernel.x86_64 5.6.11-300.fc32 @updates
Well, this was a wild goose chase. I will closing the bug.
Why? As Ed verified, packagekit does not respect the install_only
setting when doing a system upgrade. I consider that to be a bug. He
also verified that installing another kernel after that would bring the
number back to where it should be.
3:58 p.m.
Zen and the Art of Linux (Fedora version) requires patience. It is
best to observe and learn.
"The secret of Zen is just two words: not always so." -Shunryn Suzuki Roshi.
On Mon, 11 May 2020 at 16:04, Sreyan Chakravarty <sreyan32(a)gmail.com> wrote:
On 5/12/20 1:31 AM, Samuel Sieb wrote:
> PackageKit uses dnf (or at least libdnf) to do the work.
And the mystery deepens...
Then why isn't it respecting my settings?
--
Regards,
Sreyan
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
--
------------------------------------------------------------------------------------------------
Stephen E. Perkins, RN Poetry and Community Health
RuralTechnologies.net Linux since Red Hat 5.1, 1998
Open-source Collaboration Fedora since 2003
“With credulity come propaganda and advertising to dupe the citizen
with political jobbery and compromises, and the lie reaches proportions
never known before in the history of the world.”
– C. G. Jung, The Undiscovered Self (1957)
------------------------------------------------------------------------------------------------------
3:52 p.m.
On 2020-05-12 03:23, Sreyan Chakravarty wrote:
On 5/10/20 4:57 PM, Ed Greshko wrote:
> It does look as if a system upgrade using the gnome tools does something different.
> I suppose I should learn what it does....someday.:-)
GNOME uses a system called PackageKit. It makes sense I will be having more kernels even
though I have 3 install candidates set in DNF.
The comment by me is related to the question of "system upgrade". i.e. going
from one version of
fedora to another. For example F31--->F32.
I feel the horse is dead.
But, looking back at the history you supplied. #19 Altered quite a bit of packages.
19 | | 2020-05-09 18:02 | D, E, I, U | 2335
It looks to be a "system upgrade" entry.
When a system upgrade is done via the command line the history entry looks like.
1257 | system-upgrade upgrade | 2020-04-25 08:01 | D, E, I, O, U | 3166 EE
And, in my case, doing "dnf history info 1257"
Shows....
Transaction ID : 1257
Begin time : Sat 25 Apr 2020 08:01:15 AM CST
Begin rpmdb : 3153:6bbef486d6901bd9868b98fee7c4f00ab266d6ed
End time : Sat 25 Apr 2020 08:32:47 AM CST (31 minutes)
End rpmdb : 3157:78f626f8e7ac68452abef9e0ed6aab9e79d0cf43
User : System <unset>
Return-Code : Success
Releasever : 32
Command Line : system-upgrade upgrade
With the command line being shown.
Yours doesn't show a command line entry. Thus, my question about how GNOME goes
about
doing the upgrade from the GUI.
--
The key to getting good answers is to ask good questions.
4:22 a.m.
On 2020-05-10 16:38, Sreyan Chakravarty wrote:
On 5/10/20 1:18 PM, Samuel Sieb wrote:
> Did you ever install a kernel directly with rpm or dnf or has it always been through
dnf upgrades?
All the upgrades I have done is throuugh GNOME software. I didn't use dnf upgrade. Do
you think that will cause a problem ?
Oh, I just realized the earliest kernel is quite old. So, it will probably be hard to
determine why
it wasn't removed when it should have been. One would expect that you probably
did updates to the kernel between kernel-5.3.7 and kernel-5.5.15 and that early kernel
will
continue to exist.
One does have to ask, at some time did you modify /etc/dnf/dnf.conf to exclude that
kernel?
In any event. you could just erase that one kernel.
--
The key to getting good answers is to ask good questions.
6:23 a.m.
On 2020-05-10 19:12, Sreyan Chakravarty wrote:
On 5/10/20 2:52 PM, Ed Greshko wrote:
> One does have to ask, at some time did you modify /etc/dnf/dnf.conf to exclude that
kernel?
No I did no such thing.
OK. It is not uncommon to make configuration changes and then at sometime in the furture
forget having done that. Or, maybe only I've fallen victim to that. :-)
--
The key to getting good answers is to ask good questions.
3:54 a.m.
New subject: Fedora 32: hibernate/resume does not work
Hi everybody
Environment here:
[root@caprioli ~]# cat /etc/fedora-release
Fedora release 32 (Thirty Two)
[root@caprioli ~]#
root@caprioli ~]# uname -r
5.6.10-300.fc32.x86_64
[root@caprioli ~]#
[root@caprioli ~]# grub2-editenv - list
saved_entry=966c5755b3384d1192dbf3d3658c1e29-5.6.10-300.fc32.x86_64
kernelopts=root=UUID=3f218a1e-7f30-48b1-add4-fb17bff5a6b5 ro
resume=UUID=0d51db0e-8463-4741-8bbe-d907fb2b1cb2
boot_success=1
boot_indeterminate=0
[root@caprioli ~]#
[cellino@caprioli ~]$ cat /proc/cmdline
BOOT_IMAGE=(hd3,gpt5)/boot/vmlinuz-5.6.10-300.fc32.x86_64
root=UUID=3f218a1e-7f30-48b1-add4-fb17bff5a6b5 ro
resume=UUID=0d51db0e-8463-4741-8bbe-d907fb2b1cb2
[cellino@caprioli ~]$
suspend works fine on this machine, but hibernate does›nt. Another
installation on the same machine with fedora 31 hibernates/resumes
flawlessly.
I assume very much that when closing down for hibernate, no image is
created, because after booting up from (so to speak) hibernate, the last
lines in the journal are:
[root@caprioli ~]# journalctl -b -1
<snip>
May 10 09:47:53 caprioli.dyn.lan systemd[1]: Reached target Sleep.
May 10 09:47:53 caprioli.dyn.lan systemd[1]: Starting Hibernate...
May 10 09:47:53 caprioli.dyn.lan kernel: PM: Image not found (code -22)
May 10 09:47:53 caprioli.dyn.lan kernel: PM: hibernation: hibernation entry
May 10 09:47:53 caprioli.dyn.lan systemd-sleep[3134]: Suspending system...
lines 2285-2371/2371 (END)
where the 3rd line tells me, that no image has been created and written
to swap.
The swap partition has 19.6 GB. The memory is 16 GB. I tried to give the
system a much larger (1 TB) swap partition, no joy.
I also tried to go down to runlevel 3 before hibernating, and then
resume into runlevel 3: no joy.
I also tried to adapt the dracut command-line.
[root@caprioli ~]# dracut --print-cmdline
root=UUID=3f218a1e-7f30-48b1-add4-fb17bff5a6b5 rootfstype=ext4
rootflags=rw,relatime
[root@caprioli ~]#
to include the resume parameter, but dracut did not even take my
dracut.conf file into consideration.
Because the Fedora 31 installation on the same machine works flawlessly
as far as hibernate/resume is concerned, I assume the BIOS parameters
are such, that suspending/resuming is allowed.
Does the Fedora 32 Kernel, by default, prevent hibernate/resume?
I am at a loss of ideas on how to investigate further.
Any hint is highly appreciated. Thank you very much.
suomi
4:47 a.m.
On 2020-05-10 03:00, Sreyan Chakravarty wrote:
So then why do I have 4 kernels ?
$ rpm -q kernel
kernel-5.3.7-301.fc31.x86_64
kernel-5.5.15-200.fc31.x86_64
kernel-5.6.8-200.fc31.x86_64
kernel-5.6.10-300.fc32.x86_64
The follow-on question would be what do you get for
dnf list installed kernel*5.3.7*
--
The key to getting good answers is to ask good questions.
1446
days inactive
1449
days old
51 comments
9 participants
participants (9)
-
Ed Greshko -
fedora -
George N. White III -
Mike Wright -
Patrick O'Callaghan -
Samuel Sieb -
Sreyan Chakravarty -
stan -
Stephen Perkins