11:59 a.m.
Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d 'YYYY-MM-DD HH:MM UTC'
Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9
= Followups =
#topic #1117 Generalize policy about privilege escalation and
Administrator user accounts
.fesco 1177
https://fedorahosted.org/fesco/ticket/1177
#topic #1161 fqdn should be clearly display at login and command prompt
.fesco 1161
https://fedorahosted.org/fesco/ticket/1161
#topic #1148 F20 System Wide Change: Application Installer -
https://fedoraproject.org/wiki/Changes/AppInstaller
.fesco 1148
https://fedorahosted.org/fesco/ticket/1148
#topic #1164 F20 Changes - Progress on Changes Freeze
.fesco 1164
https://fedorahosted.org/fesco/ticket/1164
= New business =
#topic #1173 provenpackager request
.fesco 1173
https://fedorahosted.org/fesco/ticket/1173
#topic #1174 Exception - F20 Self Contained Change: WildFly 8 -
https://fedoraproject.org/wiki/Changes/WildFly8
.fesco 1174
https://fedorahosted.org/fesco/ticket/1174
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
3:23 a.m.
On 09/10/2013 06:59 PM, Marcela Mašláňová wrote:
Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d 'YYYY-MM-DD HH:MM UTC'
Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9
= Followups =
#topic #1117 Generalize policy about privilege escalation and
Administrator user accounts
.fesco 1177
https://fedorahosted.org/fesco/ticket/1177
#topic #1161 fqdn should be clearly display at login and command prompt
.fesco 1161
https://fedorahosted.org/fesco/ticket/1161
#topic #1148 F20 System Wide Change: Application Installer -
https://fedoraproject.org/wiki/Changes/AppInstaller
.fesco 1148
https://fedorahosted.org/fesco/ticket/1148
#topic #1164 F20 Changes - Progress on Changes Freeze
.fesco 1164
https://fedorahosted.org/fesco/ticket/1164
= New business =
#topic #1173 provenpackager request
.fesco 1173
https://fedorahosted.org/fesco/ticket/1173
#topic #1174 Exception - F20 Self Contained Change: WildFly 8 -
https://fedoraproject.org/wiki/Changes/WildFly8
.fesco 1174
https://fedorahosted.org/fesco/ticket/1174
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
Adding to new business:
#topic #1170 Working Group call for Volunteers
.fesco 1170
https://fedorahosted.org/fesco/ticket/1170
8:13 a.m.
On 09/11/2013 08:23 AM, Marcela Mašláňová wrote:
#topic #1170 Working Group call for Volunteers
.fesco 1170
https://fedorahosted.org/fesco/ticket/1170
Given that Matthew wanted me to come up with a concrete, positive
proposals [¹] surrounding Fedora as a platform, as essentially an tool
for sub communities to build upon the core/baseOS and deliver their
product as opposed to us having now three categorized defaults as he
proposes instead of one.
I would like to ask FESCO and other to hold of any work on the "ring"
proposal so I can build and present to the community and we can have the
community vote on both those proposal as an way forward for the project
for the next 5 - 10 years.
Thanks
JBG
9:41 a.m.
On Wed, Sep 11, 2013 at 3:13 PM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com> wrote:
On 09/11/2013 08:23 AM, Marcela Mašláňová wrote:
>
>
> #topic #1170 Working Group call for Volunteers
> .fesco 1170
> https://fedorahosted.org/fesco/ticket/1170
Given that Matthew wanted me to come up with a concrete, positive proposals
[¹] surrounding Fedora as a platform, as essentially an tool for sub
communities to build upon the core/baseOS and deliver their product as
opposed to us having now three categorized defaults as he proposes instead
of one.
This would be a complete chaos from a users POV. We cannot equally
support 10 different workstation or server products. Claiming
otherwise is dishonest against our users.
11:27 a.m.
On 09/11/2013 02:41 PM, drago01 wrote:
This would be a complete chaos from a users POV. We cannot equally
support 10 different workstation or server products. Claiming
otherwise is dishonest against our users.
?
For the first we dont support anything we only provide best effort
secondly we already have extensive server and desktop environment
application ( each in a sense an product ) portfolio existing in the
project.
The only "product" that we as an larger community would be delivering is
the core/baseOS something that might be called "FedoraOS"
The only thing the services sub community would have main focus on
"supporting" is the "FedoraOS" as well as the installer since it's
the
"product" that the sub community would building their product upon and
delivering to the world.
But hey please give me the time and allow me to provide the community
the concrete proposal as an alternative to what Matthew suggested before
you shoot it down..
JBG
12:37 p.m.
On Wed, Sep 11, 2013 at 6:27 PM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com> wrote:
On 09/11/2013 02:41 PM, drago01 wrote:
>
> This would be a complete chaos from a users POV. We cannot equally
> support 10 different workstation or server products. Claiming
> otherwise is dishonest against our users.
?
For the first we dont support anything we only provide best effort secondly
we already have extensive server and desktop environment application ( each
in a sense an product ) portfolio existing in the project.
Lets not discuss the word "support" again we have had enough threads of that.
And yes we have other desktop environments in the project but we do
not promote them equally
because we don't have the resources to "support" them on equal terms.
The only "product" that we as an larger community would be
delivering is the
core/baseOS something that might be called "FedoraOS"
And I disagree with that. I thing we should produce something that we
can give to
our users.
The only thing the services sub community would have main focus on
"supporting" is the "FedoraOS" as well as the installer since
it's the
"product" that the sub community would building their product upon and
delivering to the world.
See above.
But hey please give me the time and allow me to provide the community
the
concrete proposal as an alternative to what Matthew suggested before you
shoot it down..
You are of course free to come up with a concrete proposal but it is not like I
cannot kind of predict what kind of direction you want to move in
(based on your past emails not just in this thread) ...
I am not convinced that this one is feasible as way forward.
1:07 p.m.
On 09/11/2013 05:37 PM, drago01 wrote:
Lets not discuss the word "support" again we have had
enough threads of that.
And yes we have other desktop environments in the project but we do
not promote them equally
because we don't have the resources to "support" them on equal terms.
You mean Red Hat is not backing up their development through manpower
equally and not doing so makes them lesser of products then "Gnome" and
hence we should not give them equal place and footing within our project
and our community.
In other words we should only proudly display and stand behind
applications and application stacks that are backed up by Red Hat from
our community.
Yep that's pretty much how that 3 product default sounds to me, I
however do not discriminate between application in our community nor
between the people that are maintaining them.
And encase you have missed the 21 centry...
The fact is even after all those years of people crying "This year will
be the year of the Linux desktop!", we still cant do as basic function
as to update the firmware on our computers, we still cant update the
firmware of all the peripheral devices like camera, mobile
phone,tablets, gps etc.
The manufacturers of those devices still dont provide application for
their devices that run on top of general linux distrubtion and they
never will since they are making the application available for Android
and IOS and are providing tables in schools ( as opposed to pc's ) so
I'm not sure if you have realized it yet but the era of the consumer
desktop environment as we have known it, on any OS is coming to end.
And proposing that we somehow continue to tie ourselves and our
processes to *any* of the desktop environments in the GNU/Linux
ecosystem while they try to redefine themselves and struggle with their
own existence is not doing us as a community any favours nor our users
base.
What I argue with my proposal is that we prepare ourself and our
workflow for that inevitable evolution that will take place in 5 - 10
years and continue to keep ourselves relevant and help shaping the IT
industry in the 21 century.
JBG
2:08 p.m.
On Wed, Sep 11, 2013 at 8:07 PM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com> wrote:
On 09/11/2013 05:37 PM, drago01 wrote:
>
> Lets not discuss the word "support" again we have had enough threads of
> that.
> And yes we have other desktop environments in the project but we do
> not promote them equally
> because we don't have the resources to "support" them on equal terms.
You mean Red Hat is not backing up their development through manpower
equally and not doing so makes them lesser of products then "Gnome" and
hence we should not give them equal place and footing within our project and
our community.
No. This has nothing to do with Red Hat but yes manpower (which is not
limited to
maintainers but also *developers*). And whether are employed by Red
Hat (note: I am not)
or come from another planet does not matter.
In other words we should only proudly display and stand behind
applications
and application stacks that are backed up by Red Hat from our community.
No, see above.
Yep that's pretty much how that 3 product default sounds to me, I
however do
not discriminate between application in our community nor between the people
that are maintaining them.
And encase you have missed the 21 centry...
No I did not.
The fact is even after all those years of people crying "This
year will be
the year of the Linux desktop!", we still cant do as basic function as to
update the firmware on our computers, we still cant update the firmware of
all the peripheral devices like camera, mobile phone,tablets, gps etc.
What does firmware update has to do with anything here?
The manufacturers of those devices still dont provide application for
their
devices that run on top of general linux distrubtion and they never will
since they are making the application available for Android and IOS
What?!. None of those manufactures provide software
to update firmware with for iOS nor Android ....
And proposing that we somehow continue to tie ourselves and our
processes to
*any* of the desktop environments in the GNU/Linux ecosystem while they try
to redefine themselves and struggle with their own existence is not doing us
as a community any favours nor our users base.
Sorry but just because tablets and smart phones outsell PCs does not
mean that we
should start doing everything on tablets. And no we are not "tying our
processes"
to a desktop environment ... that would only apply to the workstation product.
We have a server and a could product as well in Matthew's proposal.
If anything all your mobile
talk suggest that we should have a mobile product as well. And I
wouldn't be really against that
it fits into the picture. But having 1000 workstations, 1000 servers
and 1000 different cloud products
makes no sense.
11:18 a.m.
On Wed, Sep 11, 2013 at 01:13:04PM +0000, "Jóhann B. Guðmundsson" wrote:
I would like to ask FESCO and other to hold of any work on the
"ring" proposal so I can build and present to the community and we
can have the community vote on both those proposal as an way forward
for the project for the next 5 - 10 years.
I *do* continue to welcome alternate proposals, but asking everything to
stop seems... unhelpful. It's not like this proposal is either sudden or
secret. And, it was discussed at several (public, as always) FESCo meetings
and discussed and approved by the Fedora Board last week.
At this point, what I'd _really_ like is your help in making this work going
forward. From what you've said, I don't think we're really all that far out
of alignment, and maybe we can bring that together.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
12:22 p.m.
On 09/11/2013 04:18 PM, Matthew Miller wrote:
At this point, what I'd_really_ like is your help in making this
work going
forward. From what you've said, I don't think we're really all that far out
of alignment, and maybe we can bring that together.
There is alot of alignment in how I see us going forward as are in your
proposal however there is a fundamental difference in what you are
proposing and what I'm proposing we should do.
What I see us going forward with is the core/baseOS "FedoraOS" that the
community delivers at large while the sub community they themselves set
the direction, their target audience and deliver "their" product on top
of the stable foundation we provide them with, the "FedoraOS".
You want to limit the project to three "official default products" that
the community delivers at large, which to me, does not solve existing
problem in our community, narrows down the "scope" of the project as
well as hinders innovation and participation while I want to liberate
the community from the shackles of the "default" thus finally put the
default skeletons to their grave, reduce the "bureaucracy" and allow for
more innovation. more products, and faster adoption for us as an
community in whole to the constantly changing open source environment
and have us contribute shaping that landscape.
Due to the fundamental difference in our proposal I'm not seeing where
we could meet half way through, on a common grounds in them ( i'm all
ears if you have a starting point ).
And since we are setting the direction for the project for the next 5 -
10 years we as a community need to give this some serious thought if
something like what you proposed is the way forward ( tying us down to 3
products ) or if we should move into the direction of what I propose in
that time.
JBG
12:57 p.m.
On Wed, Sep 11, 2013 at 05:22:54PM +0000, "Jóhann B. Guðmundsson" wrote:
What I see us going forward with is the core/baseOS
"FedoraOS" that
the community delivers at large while the sub community they
themselves set the direction, their target audience and deliver
"their" product on top of the stable foundation we provide them
with, the "FedoraOS".
Yes, this is basically the proposal in its current form.
You want to limit the project to three "official default
products"
I don't want to limit the project in that way.
I think these three products are reasonable starting points. I think _one_
doesn't work because it's impossible to be all things to all people and we
also can't (and shouldn't) simply choose one narrow case. I also think
chosing _none_ doesn't work, because there are concrete benefits to having a
clear direction. So, when the idea of three products (Stephen Gallagher's
proposal) came up at Flock, that seemed like a reasonable place to start.
The respective subgroups will need to define exactly what those products
look like -- after establishing governing and communication strategies, this
is their first deliverable. And if working groups other than these three
want to form and start delivering the same, the board can choose to make
those "primary" as well, just as they've approved these three initially.
that the community delivers at large, which to me, does not solve
So, this depends a lot on what you mean by "community at large" here. I want
Fedora to be inclusive, and the work of all of the subgroups to be
considered part of the community.
existing problem in our community, narrows down the "scope"
of the
project as well as hinders innovation and participation while I want
to liberate the community from the shackles of the "default" thus
finally put the default skeletons to their grave, reduce the
"bureaucracy" and allow for more innovation. more products, and
faster adoption for us as an community in whole to the constantly
changing open source environment and have us contribute shaping that
landscape.
I'm not finding much to disagree with in the specifics here, but I don't
think I understand some of the more vague parts. What "existing problem in
our community" in particular do you want to address? What do you mean by
narrows down the scope, when we are going from that single default you
clearly dislike into a broader world? Sure, each of the different products
will no longer be expected to be all things to all people, but it's about
_focus_, not excusion.
Now, about bureaucracy -- I don't think it's overly heavy-handed to require
clear membership, governence model, and so on. Yes, that's more formal than
a SIG, but the working groups don't *need* to have a heavyweight process if
they don't want -- they just need a clear, documented one. And while this
does call for the formation of more committees, each will have more autonomy
than a SIG or spin, and each will have that focus I just mentioned as an
organizing principle, along with clear deliverables.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
1:38 p.m.
On 09/11/2013 05:57 PM, Matthew Miller wrote:
> You want to limit the project to three "official default products"
I don't want to limit the project in that way.
I think these three products are reasonable starting points.
I do not and from my perspective we should only be focusing on what I
call "FedoraOS" ( core/baseOS )
I think _one_
doesn't work because it's impossible to be all things to all people and we
also can't (and shouldn't) simply choose one narrow case.
That's the fundamental disagreement I was talking about unlike you I
think the sub communities that produce their product are the ones that
should be focusing on this.
I also think
chosing _none_ doesn't work, because there are concrete benefits to having a
clear direction. So, when the idea of three products (Stephen Gallagher's
proposal) came up at Flock, that seemed like a reasonable place to start.
The sub communities they themselves will set their own direction, their
own target audience and their own goals as well be in full control how
they will try to meet those goal after all they are the ones doing all
the work necessary to achieve that goal in ( mostly in their spare time
I might add ).
The respective subgroups will need to define exactly what those products
look like -- after establishing governing and communication strategies, this
is their first deliverable. And if working groups other than these three
want to form and start delivering the same, the board can choose to make
those "primary" as well, just as they've approved these three initially.
> that the community delivers at large, which to me, does not solve
So, this depends a lot on what you mean by "community at large" here. I want
Fedora to be inclusive, and the work of all of the subgroups to be
considered part of the community.
By community at large I mean the entire project made up of ever
community member sub-community or otherwise.
I did not call this subgroups but sub communities which I though clearly
indicated they were part of the community at large.
> existing problem in our community, narrows down the "scope" of the
> project as well as hinders innovation and participation while I want
> to liberate the community from the shackles of the "default" thus
> finally put the default skeletons to their grave, reduce the
> "bureaucracy" and allow for more innovation. more products, and
> faster adoption for us as an community in whole to the constantly
> changing open source environment and have us contribute shaping that
> landscape.
I'm not finding much to disagree with in the specifics here, but I don't
think I understand some of the more vague parts. What "existing problem in
our community" in particular do you want to address?
The discrimination problem that has existed this whole time between
contributors as in not all contributors are treated equal nor their work
is getting equal presentation from the project.
What do you mean by
narrows down the scope, when we are going from that single default you
clearly dislike into a broader world? Sure, each of the different products
will no longer be expected to be all things to all people, but it's about
_focus_, not excusion.
As see it it is indeed about exclusion since you will be excluding
everyone that are not part of those three defaults as we are doing now
with a single default.
Now, about bureaucracy -- I don't think it's overly heavy-handed to require
clear membership, governence model, and so on. Yes, that's more formal than
a SIG, but the working groups don't *need* to have a heavyweight process if
they don't want
The sub communities themselves already have existing governing structure.
The cloud community has theirs, the server community has theirs etc.
We dont need an additional layer on top of that other than arguably what
Josh recently proposed on the advisory list.
JBG
3:25 p.m.
New subject: Summary/Minutes from today's FESCo Meeting (2013-09-11)
HI
On Wed, Sep 11, 2013 at 3:17 PM, Marcela Mašláňová wrote:
Can you just paste the content as the body instead of attachments in the
future? Attachments are harder to deal with for mobile devices. Thanks!
Rahul
5:59 p.m.
New subject: Summary/Minutes from today's FESCo Meeting (2013-09-11)
On Wed, 11.09.13 21:17, Marcela Mašláňová (mmaslano(a)redhat.com) wrote:
* #1161 fqdn should be clearly display at login and command prompt
(mmaslano, 18:11:07)
* AGREED: fqdn should be clearly display on login prompt, but not on
commandline prompt (+7,-0,0) (mmaslano, 18:17:19)
What weird "decision" is this? What precisely has been decided here?
That /sbin/login should do a reverse name lookup on the hostname to turn
it into an fqdn? That be really broken, if DNS hangs... You couldn't log
in then anymore.
Or that /etc/hostname now has to contain an FQDN always? That be bogus
too, it doesn't work for anything but single-homed servers...
And where is this all supposed to be implemented?
And why is this discussed at FESCO right at the beginning?
The IRC discussion is not very enlightening, it really appears as if the
folks pushing and discussing this have no idea what this actually takes
to implement....
Lennart
--
Lennart Poettering - Red Hat, Inc.
6:30 p.m.
New subject: Summary/Minutes from today's FESCo Meeting (2013-09-11)
On 09/11/2013 10:59 PM, Lennart Poettering wrote:
On Wed, 11.09.13 21:17, Marcela Mašláňová (mmaslano(a)redhat.com)
wrote:
> * #1161 fqdn should be clearly display at login and command prompt
> (mmaslano, 18:11:07)
> * AGREED: fqdn should be clearly display on login prompt, but not on
> commandline prompt (+7,-0,0) (mmaslano, 18:17:19)
What weird "decision" is this? What precisely has been decided here?
In this case that agetty displayed --long-hostname under Host: entry in
/etc/issue which would make the login prompt look like this
Fedora release 20 (Rawhide)
Kernel 3.11.0-0.rc5.git6.1.fc20.x86_64 on an x86_64 (console)
Host: www.example.com <-- fqdn added
login:
That /sbin/login should do a reverse name lookup on the hostname to turn
it into an fqdn? That be really broken, if DNS hangs... You couldn't log
in then anymore.
?
The other thing that I was proposing was that change the default bashrc
and cshrc
[testuser@www ~]$ becomes --> [testuser(a)www.example.com ~]$
With the following changes..
bashrc
--- a/bashrc
+++ b/bashrc
@@ -38,7 +38,7 @@ if [ "$PS1" ]; then
history -a
# Turn on checkwinsize
shopt -s checkwinsize
- [ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\u@\h \W]\\$
"
+ [ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\u@\H \W]\\$
"
# You might want to have e.g. tty in prompt (e.g. more virtual machines)
# and console windows
# If you want to do so, just add e.g.
--
And
cshrc
-- a/csh.cshrc
+++ b/csh.cshrc
@@ -16,11 +16,11 @@ endif
if ($?prompt) then
if ($?tcsh) then
set promptchars='$#'
- set prompt='[%n@%m %c]%# '
+ set prompt='[%n@%M %c]%# '
# make completion work better by default
set autolist
else
- set prompt=\[$user@`hostname -s`\]\$\
+ set prompt=\[$user@`hostnamectl --static`\]\$\
endif
endif
@@ -38,12 +38,12 @@ if ($?prompt) then
switch($TERM)
case xterm*:
if ($?tcsh) then
- set prompt='%{\033]0;%n@%m:%c\007%}[%n@%m %c]%# '
+ set prompt='%{\033]0;%n@%M:%c\007%}[%n@%M %c]%# '
endif
breaksw
case screen:
if ($?tcsh) then
- set prompt='%{\033k%n@%m:%c\033\\%}[%n@%m %c]%# '
+ set prompt='%{\033k%n@%M:%c\033\\%}[%n@%M %c]%# '
endif
breaksw
default:
Or that /etc/hostname now has to contain an FQDN always? That be bogus
too, it doesn't work for anything but single-homed servers...
I just assume these would turn up empty if not filled out.
And where is this all supposed to be implemented?
In 3 components
And why is this discussed at FESCO right at the beginning?
Because the setup maintainer wanted it to be discussed in wider audience
( with what 5 different people participate in that discussion ) and that
discussion let nowhere and I have better things with my free time
dealing essentially with people that want to show of their bashrc foo
failing to understand this was meant for an group of audience that did
not know their bashrc foo hence not capable of overwriting it.
The IRC discussion is not very enlightening, it really appears as if the
folks pushing and discussing this have no idea what this actually takes
to implement....
Lennart thanks for the vote of confidence and filing I guess filling the
necessary patches to actually implementing this clearly showed that I
did not know what I was doing but worried not I closed all the bugs that
had those patches wontfix anyway so have a nice evening.
JBG
7:18 p.m.
New subject: Summary/Minutes from today's FESCo Meeting (2013-09-11)
On Wed, 11.09.13 23:30, Jóhann B. Guðmundsson (johannbg(a)gmail.com) wrote:
>>* #1161 fqdn should be clearly display at login and command
prompt
>> (mmaslano, 18:11:07)
>> * AGREED: fqdn should be clearly display on login prompt, but not on
>> commandline prompt (+7,-0,0) (mmaslano, 18:17:19)
>What weird "decision" is this? What precisely has been decided here?
In this case that agetty displayed --long-hostname under Host: entry
in /etc/issue which would make the login prompt look like this
The command line of agetty we use on Fedora does not use --long-hostname
currently. I don't grok this?
Are you suggesting it should pass that switch? If so, I'd prefer if this
would become the agetty upstream default. Have you tried asking Karel
for that? Why did you involve FESCO?
Fedora release 20 (Rawhide)
Kernel 3.11.0-0.rc5.git6.1.fc20.x86_64 on an x86_64 (console)
Host: www.example.com <-- fqdn added
How is that fqdn determined? Simply the result of gethostname()? Or is
this the result of "hostname --fqdn"? (the former just reads a string
from the kernel, which is fine; the latter involves DNS resolving that
string, and then reverse resolving it again, which is nothing we should
do when showing a login prompt.)
- [ "$PS1" = "\\s-\\v\\\$ " ] &&
PS1="[\u@\h \W]\\$ "
+ [ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\u@\H \W]\\$
"
This change is simply about whether to truncate at the first dot or
not. This has little to do with qualifying a hostname to become the
fqdn...
So, let me ask explicitly:
Are you suggesting that a configured short kernel hostname should be
qualified to an fqdn on display? (which is what your choice of words
"fqdn" was suggesting).
Or are you simply suggesting that a possibly configured long kernel
hostname should not be truncated on display to become a short name?
If it's the latter I'd appreciate to make this clear in your FESCO
ticket.
Recommended read is the bit about "The FQDN" in hostname(1), to grok
what it means to qualify a short hostname to an fqdn.
Lennart
--
Lennart Poettering - Red Hat, Inc.
7:54 p.m.
New subject: Summary/Minutes from today's FESCo Meeting (2013-09-11)
On Thu, Sep 12, 2013 at 02:18:23AM +0200, Lennart Poettering wrote:
Are you suggesting it should pass that switch? If so, I'd prefer
if this
would become the agetty upstream default. Have you tried asking Karel
for that? Why did you involve FESCO?
This went to FESCo because the bashrc maintainer didn't want to change the
bash prompt otherwise. (And we voted to leave that alone.)
I agree that the FQDN terminology was used loosely and sometimes incorrectly
in the discussion. We can revisit if you (or others) think it should be. I
don't think FESCo makes any claim to infallibility. (At least, I hope not!)
How is that fqdn determined? Simply the result of gethostname()? Or
is
this the result of "hostname --fqdn"? (the former just reads a string
from the kernel, which is fine; the latter involves DNS resolving that
string, and then reverse resolving it again, which is nothing we should
do when showing a login prompt.)
Based on the bugs presented in the ticket, despite the loose use of FQDN,
this appeared to be about putting \n in /etc/issue (after the initial idea
of calling agetty --long-hostname was discarded). The agetty man page says
that's nodename from `uname -n`, which is the underlying implementation to
gethostname().
So, in other words, this:
Or are you simply suggesting that a possibly configured long kernel
hostname should not be truncated on display to become a short name?
but for the specific case of /etc/issue. (Agetty's default is to truncate
the hostname prompt it gives, but I don't think it does that with '\n')
I did read the whole previous mailing list discussion, and the above is what
informed my thinking even though I didn't say so in the discussion. (And I
probably should have.)
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
8:42 p.m.
New subject: Summary/Minutes from today's FESCo Meeting (2013-09-11)
On Wed, 11.09.13 20:54, Matthew Miller (mattdm(a)fedoraproject.org) wrote:
> How is that fqdn determined? Simply the result of gethostname()?
Or is
> this the result of "hostname --fqdn"? (the former just reads a string
> from the kernel, which is fine; the latter involves DNS resolving that
> string, and then reverse resolving it again, which is nothing we should
> do when showing a login prompt.)
Based on the bugs presented in the ticket, despite the loose use of FQDN,
this appeared to be about putting \n in /etc/issue (after the initial idea
of calling agetty --long-hostname was discarded). The agetty man page says
that's nodename from `uname -n`, which is the underlying implementation to
gethostname().
Well, the hostname is also shown directly in front of the "login:"
prompt (on the same line) by agetty itself (i.e. is not generated via
/etc/issue). Do you want to show it twice now, once via /etc/issue and
once via that login prompt agetty generates?
Or is part of this change that --nohostname becomes the default for our
agetty invocations? If so this should probably be a change that is made
in agetty. (Or a bug needs to be filed against systemd to add this to
the agetty cmdline in getty@.service, but I am very cold towards
overriding defaults of other software with systemd).
Guys, you really should figure out what is actually desired before you
start all that misleading bureaucracy.
Lennart
--
Lennart Poettering - Red Hat, Inc.
9:10 p.m.
New subject: Summary/Minutes from today's FESCo Meeting (2013-09-11)
On Thu, Sep 12, 2013 at 03:42:31AM +0200, Lennart Poettering wrote:
> Based on the bugs presented in the ticket, despite the loose use
of FQDN,
> this appeared to be about putting \n in /etc/issue (after the initial idea
> of calling agetty --long-hostname was discarded). The agetty man page says
> that's nodename from `uname -n`, which is the underlying implementation to
> gethostname().
Well, the hostname is also shown directly in front of the "login:"
prompt (on the same line) by agetty itself (i.e. is not generated via
/etc/issue). Do you want to show it twice now, once via /etc/issue and
once via that login prompt agetty generates?
Or is part of this change that --nohostname becomes the default for our
agetty invocations? If so this should probably be a change that is made
in agetty. (Or a bug needs to be filed against systemd to add this to
the agetty cmdline in getty@.service, but I am very cold towards
overriding defaults of other software with systemd).
This was convered in the proposal, and that's why there was a bug already
filed to change the agetty command line in getty@.service. But now Jóhann
has now closed them all as WONTFIX so I'm not sure what's going on.
Personally I don't really care enough about this to drive it further either
way, but it sounded like some other people might.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
2:54 a.m.
New subject: Summary/Minutes from today's FESCo Meeting (2013-09-11)
On 09/12/2013 02:10 AM, Matthew Miller wrote:
This was convered in the proposal, and that's why there was a bug
already
filed to change the agetty command line ingetty@.service. But now Jóhann
has now closed them all as WONTFIX so I'm not sure what's going on.
I sought after fixing a problem but due to "real estate" investment from
FESCO they elected not fixing it ( you know the classic vote on my
personal feelings rather then practicality ), thus not solving the
problem I was actually trying to fix hence closing all bugs with all the
patches.
JBG
3904
days inactive
3906
days old
20 comments
6 participants
participants (6)
-
drago01 -
Jóhann B. Guðmundsson -
Lennart Poettering -
Marcela Mašláňová -
Matthew Miller -
Rahul Sundaram