from:"Lars E. Pettersson"

On 12/03/2011 09:40 AM, JB wrote:
 Even with a total rewrite of GNOME code base, they could choose to offer
 GNOME2-like GUI on top of it as a still *default* DE in Fedora, while

If you chose the 'Forced Fallback Mode' in 'System info' you will get 
something that resembles Gnome2 (Gnome3 with metacity). So the 
Gnome2-like GUI is there, but very well hidden.

Lars
-- 
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: The Linus view of GNOME 3.2

On 12/03/2011 09:40 AM, JB wrote:
 Even with a total rewrite of GNOME code base, they could choose to offer
 GNOME2-like GUI on top of it as a still *default* DE in Fedora, while

If you chose the 'Forced Fallback Mode' in 'System info' you will get 
something that resembles Gnome2 (Gnome3 with metacity). So the 
Gnome2-like GUI is there, but very well hidden.

Lars
-- 
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Static interface-addresses and Firefox/Thunderbird off-line mode

At work I have a system with static interface addresses. I.e. I have set 
the IP-numbers outside of NetworkManager, I even did not have 
NetworkManager installed (can not see any reason for that on a system 
that is stationary and have static IP_addresses).

Since I upgraded this system from Fedora-14 to Fedora-16 Firefox and 
Thunderbird starts up in off-line mode. I installed NetworkManager to 
see if that helped. But they still start up in off-line mode, which is 
annoying as the network is there and has been since the computer was 
started.

Anyone else had this problem? Or anyone out there that can give me a 
pointer on how to get Firefox and Thunderbird started in on-line mode, 
just as it was in Fedora-14?

I am using Gnome3 in forced fall-back mode.

Lars
-- 
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: The Linus view of GNOME 3.2

On 12/04/2011 03:34 PM, Aaron Konstam wrote:
 Where does one find System info? I can't find it.

Left click on your name in the upper right corner of the screen.
Chose 'Systems Settings'
Chose 'System Info'
Chose 'Graphics'
There you have a toggle for 'Forced Fallback Mode'

To add things to the panels, press and hold Alt, and then right click.

It seem to be quite close to what you get in Gnome2.

Lars
-- 
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Static interface-addresses and Firefox/Thunderbird off-line mode

On 12/04/2011 03:10 PM, Ed Greshko wrote:
 In Firefox go to about:config and set network.manage-offline-status to
 false

 In Thunderbird set toolkit.networkmanger.disable to true

Nice! That sounds like the correct things to toggle, I'll test it at 
work tomorrow.

Thanks!

Lars
-- 
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

SOLVED: Re: Static interface-addresses and Firefox/Thunderbird off-line mode

2011-12-05 Thread Lars E. Pettersson

On 12/04/2011 03:10 PM, Ed Greshko wrote:
 In Firefox go to about:config and set network.manage-offline-status to
 false

Worked!

 In Thunderbird set toolkit.networkmanger.disable to true

Did not work, strangely enough.

I then went into system-config-network to take a look, that's were I 
once had my interfaces setup, and noticed that 'Controlled by 
NetworkManager' was un-ticked, so i ticked it, reset the configuration 
options above, and tried again. This times both thunderbird and firefox 
started at once when logging in.

So apparently, to make NetworkManager happy with static addresses that 
has been set up with system-config-network, one needs to tick 
'Controlled by NetworkManager'.

Lars
-- 
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: The Linus view of GNOME 3.2

2011-12-05 Thread Lars E. Pettersson

On 12/04/2011 11:44 PM, Scott Doty wrote:
 But this resembles an _unconfigured_ gnome2 installation -- all of the
 buttons, drawers, and widgets from Gnome 2's gnome-panel are lost.

To add things to the panels, press alt and hold, press right mouse click.

The drawers are not there though, but buttons, and most widgets etc. are 
there.

 I really wish people would stop trying to put lipstick on the fallback
 mode -- just tell folks to move to kde, or xfce.

Lipstick? For me it is as close to Gnome2 that I can get, I can get the 
buttons and widgets I used, and most importantly, it restores the 
work-flow that I once had in Gnome2, the work-flow that Gnome3 with its 
shell totally destroyed. I can get my work done again, and that's what 
it is important for me.

I actually did use Xfce since Gnome3 hit me, but turned to the fall-back 
mode mentioned above (i.e. Gnome3 with metacity, Gnome3 with compiz I 
did not get to work though, could not add things to the panels).

The sad thing is that they have hidden this fall-back mode quite thoroughly.

Lars.
-- 
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: gnome 3

2011-12-08 Thread Lars E. Pettersson

On 12/08/2011 04:18 PM, Patrick Dupre wrote:
 one running with fedora 14) to gnome 3. Is there any option to keep
 the previous version of gnome runing with the more recent versions of
 fedora?

You could get a Gnome2-like version by doing this in Gnome3 shell:

- click on your name in the top right corner
- chose System Settings
- chose System Info
- chose Graphics
- set Forced Fallback Mode to ON

This will give you Gnome3 with metacity, that is quite close to Gnome2. 
To add things to the panel, press ALT-key, and hold, and the right-click 
(took a while for me to find this...)

I tried Gnome3 with compiz, but could not add things to the panel there 
(I did not try that hard though).

Lars
-- 
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: gnome 3

2011-12-08 Thread Lars E. Pettersson

On 12/08/2011 06:09 PM, Michael Cronenworth wrote:
 That's only delaying the inevitable. The fall back will go away once the
 LLVMpipe driver goes in to Fedora 17 or 18.

According to Vincent Untz https://live.gnome.org/VincentUntz the 
fall-back mode will be there during the whole Gnome3 life cycle, see 
http://www.vuntz.net/journal/post/2011/04/13/gnome-panel-is-dead,-long-live-gnome-panel!

Lars
-- 
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: System mail (Fedora 20)


On 12/25/2013 06:56 AM, Frank Murphy wrote:

On Wed, 25 Dec 2013 06:30:22 +0100
lee l...@yun.yagibdah.de wrote:


A system cannot correctly function without a way for such processes
to send email.


Yes, they can. Cron can work whether you know about it or not
eg. journalctl | grep cron | less


# time journalctl | grep cron
...lots of lines since July 28 (!)...

real26m0.921s
user10m25.731s
sys 3m7.579s
#

Not that useful. Any idea on how to improve that?

On my desktop it took 6 seconds, starting July 6, but it had only a few 
lines about the yum-cron problems the last two weeks. So on that 
computer I seem to miss a lot of lines in the systemd-log, that is 
present in the /var/log/cron file.


Strange things are happening, apparently...


Has all the software that (potentially) sends email been modified to
accommodate a crippled system?


How is it crippled, it's still logged?


One example. I get mail from cron, using yum-cron, with contents like 
the following. How is that handled without a MTA? Never got a response 
from Lennart Poettering on the devel list...


/etc/cron.hourly/yum.cron:

Loaded plugins: changelog, dellsysid, fastestmirror, refresh-packagekit
Loading mirror speeds from cached hostfile
 * fedora: vesta.informatik.rwth-aachen.de
 * rpmfusion-free: ftp-stud.hs-esslingen.de
 * rpmfusion-free-updates: ftp-stud.hs-esslingen.de
 * rpmfusion-nonfree: ftp-stud.hs-esslingen.de
 * rpmfusion-nonfree-updates: ftp-stud.hs-esslingen.de
 * updates: vesta.informatik.rwth-aachen.de
No packages marked for update
Loaded plugins: changelog, dellsysid, fastestmirror, refresh-packagekit
Loading mirror speeds from cached hostfile
 * fedora: ftp.lysator.liu.se
 * rpmfusion-free: ftp-stud.hs-esslingen.de
 * rpmfusion-free-updates: ftp-stud.hs-esslingen.de
 * rpmfusion-nonfree: ftp-stud.hs-esslingen.de
 * rpmfusion-nonfree-updates: ftp-stud.hs-esslingen.de
 * updates: ftp.lysator.liu.se
No packages marked for update

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: System mail (Fedora 20)


On 12/26/2013 06:46 PM, Lars E. Pettersson wrote:

On my desktop it took 6 seconds, starting July 6, but it had only a few
lines about the yum-cron problems the last two weeks. So on that
computer I seem to miss a lot of lines in the systemd-log, that is
present in the /var/log/cron file.


Ah, sorry, just realized, just after sending the mail, that I was not 
logged in as root. As root those lines appeared, and this was the time 
for it, since July 2nd


real0m26.801s
user0m9.099s
sys 0m1.731s

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: f20 - gedit


On 12/19/2013 09:07 AM, Ahmad Samir wrote:

AppMenu is only used when running under GNOME, when using any other DE
it's not used.

FWIW, you can get the old behaviour back under GNOME by editing the
'org.gnome.settings-daemon.plugins.xsettings overrides' key:

gsettings set org.gnome.settings-daemon.plugins.xsettings overrides
{'Gtk/ShellShowsAppMenu': 0}


As the App Menu works bad when using multiple windows and focus follow 
mouse, this should perhaps be a part of gnome-tweak-tool (a tick box 
there to chose App Menu or not), so one doesn't have to dig into dconf 
with dconf-editor. Will make life a tad easier for the ordinary user.


I should perhaps write a RFE on that...

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: System mail (Fedora 20)


On 12/26/2013 07:32 PM, Pete Travis wrote:

Try `journalctl -u crond --since today`  for example.  journalctl has
filtering options built in, the man page is worth skimming.


OK, took 12 seconds (cat /var/log/cron is even faster though :). But 
'journalctl -u crond --since today' does not produce the same output as 
'journalctl --since today | grep cron' (which more or less resembles 
what I have in /var/log/cron). Shouldn't -u crond produce the same 
output (more or less) as /var/log/cron?


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: fedup leaves half done 18 19


On 12/26/2013 08:01 PM, Sean Darcy wrote:

Rebooted. No FC19. Booted into FC18.


What does 'cat /etc/issue' say?

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: fedup leaves half done 18 19

2013-12-29 Thread Lars E. Pettersson


On 12/29/2013 04:36 AM, Joe Zeff wrote:

It means that the release version is, or should be, 19.  However, I'd
suggest that you use package-cleanup --dupes and check to see if you
have duplicate versions of fedora-release-noarch.


You can use 'package-cleanup --cleandupes' to remove any old packages 
still there.


After that, use 'yum distro-sync' to get everything as close to a new 
f19 install as possible, and also install the missing f19 kernel.


You should also check for *.rpmnew and *.rpmsave files (new or old 
configuration files saved), and update the configuration files that need 
updates (check with diff what the differences are, if something 
significant, update the configuration file)


find / -xdev -name '*.rpmnew' -o -name '*.rpmsave'

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: System mail (Fedora 20)

2013-12-29 Thread Lars E. Pettersson


On 12/29/2013 01:24 PM, Frank Murphy wrote:

As I stated mailx allows me to read system-mail in claws-mail.


Have you changed anything in the mailx setup? /etc/mail.rc ?

As far as I can tell I can only get system mail when using an MTA, mailx 
without any changes seem to do nothing here.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 12/30/2013 08:20 PM, Bruno Wolff III wrote:

they aren't likely to be reading mail from the local machine (and less
likely to be reading root's email).


That's the reason for /etc/aliases Just make an alias for root, sending 
root mail to a certain user or users.



So for mail delivery I think it
would make more sense to be able to easily send it to remote addresses
rather than trying to drop it into /var/mail.


/etc/aliases
root local_user
or
root s...@where.org

should do it...

This should IMHO be a part of the install process. We then need an MTA 
of some sort. (I mentioned this when dropping sendmail was discussed on 
the devel list, but sadly they chose to remove the MTA, thereby loosing 
mail from cron jobs, logwatch, etc.)


Most mail clients can receive local mail, so it ending up in 
/var/spool/mail/something is better that it getting lost totally. You 
can even do 'tail -100 /var/spool/mail/user' to read that mail :)


This change, combined with the syslog removal, will probably lead to 
more users missing information, as they do not get any mails from the 
system, and reading logs has become bit harder, as we no longer have 
plain text files but must use journalctl (that on my systems is quite 
sluggish).



I think for normal desktop users, desktop alerts of abnormal activity is
going to be more useful then log extracts. However, currently logwatch
reports a lot of stuff that isn't really important and you wouldn't want
generate alerts for everything it currently reports on.


Logwatch watches the logs and report strange things. I find it useful. 
What would you like removed from it?


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 12/30/2013 08:23 PM, Ed Greshko wrote:

I can't see what the problem is.

yum install sendmailgets you what was before.

Is this really an insurmountable obstacle?


No. Not for me. But perhaps for other users. Perhaps not as savvy when 
it comes to computers. Would it not be nice if these people easily could 
get information from the system in form of mails?


Removing sendmail and syslog will probably make it harder for an 
ordinary user to understand problems on their computer, as they not 
easily can get information about what is happening to their system.


Including sendmail and syslog makes it easier for the ordinary user. And 
that is a good thing. At least in my book.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 12/31/2013 06:27 PM, Rahul Sundaram wrote:

That seems to be made up.  ordinary users  are not reading mails send
to root or carefully reading /var/log/messages and to the extend any
user is wanting to go through logs, they will find the features of
integrated tools like journalctl much much more useful than raw grepping.


Made up? No. Rahul, ordinary users do read mail, and if they easily 
can find out how to use journalctl, they could equally easily find out 
how to get root mail sent to their own local mail spool (I have even 
proposed that this, adding 'root local_user' to /etc/aliases, should be 
a part of the install of Fedora).


Reading a text file is easy, fast, and creates no problems for most 
users. Journalctl has on my systems been sluggish (simple searches have 
taken a long time, even systemctl status takes long time when showing 
the log lines), and if you want to get information about a certain event 
you often have to use grep, the same grep command that you refer to, to 
find what you are looking for.


Rahul. Mail is sent to root by different parts of the install, it could 
be outputs from cron, logwatch, etc. Is it not better that this 
information is sent to the main user on the system, than being lost? Is 
it not better to include a simple basic form of log, in pure ASCII form, 
that can be easily read?


Again, for you or me this is no problem. We can set up our computers to 
do exactly whatever we want, but should we not strive to make the system 
easy to use, and to get information from, even for an ordinary user 
not as savvy as we?


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 12/31/2013 07:28 PM, Rahul Sundaram wrote:

I don't buy into this argument at all.  For one, there are graphical log
utilities that a regular user would be a lot more comfortable and then
root mail is mostly useless for a regular user.   If you think a regular
user is spending time reading mails from root or reading
/var/log/messages, you got a definition of normal user that doesn't
look anything close to realistic.   Anyone who is interested enough in
reading root mails in a Fedora box should be more than capable of
installing an MTA.


What graphical log utilities are you thinking about?

Yes, regular users do spend time reading mail from root (after they have 
found out how /etc/aliases work), and they do look at /var/log/messages. 
Of course there are users that never have done either, but I would bet a 
majority has (this based on people I know and have met since I started 
with Linux mid 1990).


We should have sane defaults in the system. And providing a facility to 
move mail locally is a good one. Why let the mails sent to root get 
totally lost? As is the case in f20? Would it not be better to use an 
MTA to move this to the main users mail spool (using /etc/aliases setup 
at installation of the system)?


Why should we guard the user from seeing mail from the system? Or 
provide a simple way for them to find out what is happening with the system?


How do you propose that we should make it simple for an ordinary user to 
get information from and about the system?


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 12/31/2013 08:37 PM, Rahul Sundaram wrote:

That would be a lousy bet really. You can be aligning yourself with more
technical users.


On a similar note. What do you base your opinion on?

(Some of them have been technical users, but by no means all)


Regular uses probably have never heard of /etc/aliases
at all and certainly don't read root mail at all.


If a user can read about journalctl and find information about how to 
use that, he/she could equally well do the same thing regarding 
/etc/aliases and reading root mail. (Remember that I proposed that 
/etc/aliases should be setup at install time of Fedora, so that would 
already be in place, following my proposal)



For desktop users,  there are several methods to get the information
they typically care about ex:  desktop notification that disk is failing
and it is feasible to extend them to cover more things.


That was the use case I was thinking about. (In the server case the 
administrator (hopefully) have knowledge to set up the system the way 
he/she wants, including/excluding MTA and/or syslog facilities.)


Notifications could be one way for some things. Perhaps output from root 
mail, cron, logwatch or similar applications could be taken care of that 
way.


But there must also be a way to look into logs in an easy way.

The user might experience some problems with the installation. He/she 
contacts a friend. The usual response often is, what does the log say, 
or could you find xyz in the log, or something similar. So whatever 
one thinks about logs, they are important, even for non technical users. 
And an ASCII file is often easier for a non technical user to handle 
than a new and perhaps never used command.


As we do not have a (full-blown) system where mail to root could be 
shown to the user as notifications. And simple text files actually is 
easier for non technical users to handle. It still makes sense to 
include a MTA and syslog. When we have applications that take care of 
these things, and present them to the user in a good way, then we could 
remove the MTA and syslog. At the moment the user is left in some sort 
of limbo loosing mails sent to root, and having problems reading log files.


Off to new year celebrations here. Happy new year to all!
Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 12/31/2013 10:49 PM, Rahul Sundaram wrote:

No.  That's just blatantly wrong.  journalctl's output is a pixel
perfect match of /var/log/messages.


No, it's not:

journalctl -f contains the following
Jan 01 00:10:01 tux systemd[1]: Starting Session 98 of user root.
Jan 01 00:10:01 tux systemd[1]: Started Session 98 of user root.
Jan 01 00:10:01 tux CROND[9317]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 01 00:20:01 tux systemd[1]: Starting Session 99 of user root.
Jan 01 00:20:01 tux systemd[1]: Started Session 99 of user root.
Jan 01 00:20:01 tux CROND[9557]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 01 00:30:01 tux systemd[1]: Starting Session 100 of user root.
Jan 01 00:30:01 tux systemd[1]: Started Session 100 of user root.
Jan 01 00:30:01 tux CROND[9726]: (root) CMD (/usr/lib64/sa/sa1 1 1)

tail /var/log/messages

Jan  1 00:10:01 localhost systemd: Starting Session 98 of user root.
Jan  1 00:10:01 localhost systemd: Started Session 98 of user root.
Jan  1 00:20:01 localhost systemd: Starting Session 99 of user root.
Jan  1 00:20:01 localhost systemd: Started Session 99 of user root.
Jan  1 00:30:01 localhost systemd: Starting Session 100 of user root.
Jan  1 00:30:01 localhost systemd: Started Session 100 of user root.

tail /var/log/cron

Jan  1 00:10:01 localhost CROND[9317]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan  1 00:20:01 localhost CROND[9557]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan  1 00:30:01 localhost CROND[9726]: (root) CMD (/usr/lib64/sa/sa1 1 1)

Spot the differences?

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/01/2014 03:16 AM, Rahul Sundaram wrote:

On 12/31/2013 10:49 PM, Rahul Sundaram wrote:

No.  That's just blatantly wrong.  journalctl's output is a pixel
perfect match of /var/log/messages.

...

Sure, it has some improvements controllable via options but nothing that
would trip up grep.  The point is that you don't need to know any fields
to use the journalctl output.


What improvements? Is it possible to get it a pixel perfect match 
using options?


What you do need to know is where the fields differ. This as you might 
need to update your scripts to handle these differences.


I can not see any reason why the output of journalctl can not to be a 
pixel perfect match, so why is it not?


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/01/2014 10:19 PM, Rahul Sundaram wrote:

If you want to find out what journalctl can support, look at the man
page. If you have suggestions for improvements, post it in Bugzilla like
I did yesterday.


OK, I thought you meant that you knew an option that did it pixel 
perfect. Perhaps I misunderstood you.


Bugzilla 1047700

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 12/31/2013 10:20 PM, Rahul Sundaram wrote:

Your proposal is irrelevant when we are talking about current reality.


No it is by no means not. By implementing my proposal this mail is not 
lost (as Lennart Poettering stated it in the devel list) by ending up in 
/var/spool/mail. If included in the installation process of Fedora, 
perhaps also mentioning that the user should/could set up their mail 
client to read spool mail, these message will definitely not be lost.


Sadly messages are lost in F20 as distributed now, read question 1 in 
the mail from Suvayu Ali titled Manipulating journalctl output dated 
20:57 Jan 1, as an example.


He states that his journal says Dec 30 04:36:05 hostname 
rsnapshot[8265]: /usr/bin/rsnapshot daily: ERROR: /usr/bin/rsnapshot 
daily: completed, but with some errors but where to find that error? In 
F19 these errors would have been forwarded to the mail spool via 
/etc/aliases. Now it is lost.



journalctl is not a requirement to read logs.  It is just far more
easier than grepping through /var/log/messages for the common use
cases.


As always that depends on the use case (see at the end). One nice thing 
with journalctl though, is the possibility to filter the last 10 minutes 
and similar, that is a bit awkward to do without using awk or similar on 
/var/log/messages (is it possible to filter out a time slice with 
journalctl, man page gives no clue?). But in all, a pure ASCII file is 
so simple that even a novice can handle it. And for grepping, journalctl 
is too slow.



As I mentioned before desktop environment have graphical
utilities to read log files.  gnome-system-log for /var/log/messages for
example.


Yes, but it is a bit hard to filter using that. (On a side note, on my 
system the Date/time field is white text on white background which makes 
it a bit hard to read. (Do you have a solution for that))



GNOME is also getting a systemd specific log viewer as well

https://mail.gnome.org/archives/gnome-announce-list/2013-September/msg00097.html


OK. Tested that but could not get any usable output from it at the 
moment. Perhaps it is a bit too early to test it yet,



Other similar utilities are available for other DE's as well.If it
is important, the DE should notify the user proactively and not wait on
them to read some log file


On that I agree. And mail from logwatch is an example of that. 
Notifications another. But when you get notified, you tend to look up 
your logs, and then it is good if these are readily available, fast, and 
easy to handle.


Look at the following use case (Fedora 20). The journal starts in July, 
/var/log content in September. In this use case using simple text files 
is extremely faster than journalctl. Also note the differences is size.


(I have not done any changes to the configuration of the journal, so 
this could be the journal of a normal user (well, perhaps not, in this 
case it is my home web and mail server and it probably produces more 
journal data than a desktop user does))


[root@gw ~]# time journalctl | grep xyz
...
real25m31.478s
user11m2.966s
sys 2m36.218s
[root@gw ~]# time grep -r --exclude-dir=journal xyz /var/log
...
real1m6.362s
user0m2.253s
sys 0m1.201s
...
[root@gw ~]# du -sh --exclude=journal /var/log
620M/var/log
[root@gw ~]# du -sh /var/log/journal
3.7G/var/log/journal
[root@gw ~]#

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: announcement --- planned Yum replacement now ready for user testing


On 12/20/2013 12:33 PM, Ales Kozumplik wrote:

On behalf of the DNF team I'd like to invite all the interested Fedora
users in trying out and testing DNF in Fedora 20. DNF is a tool that
aims to fully replace Yum by Fedora 22. Please check out the blog post
for more information:


A question, I found the following on 
http://akozumpl.github.io/dnf/cli_vs_yum.html


dnf erase kernel deletes all packages called kernel

In Yum, the running kernel is spared. There is no reason to keep this in 
DNF, the user can always specify concrete versions on the command line, 
e.g.:


dnf erase kernel-3.9.4

So if I issue 'dnf erase kernel' all kernels will be removed, and I have 
no kernel anymore? Is that really a good thing? Should we not spare the 
running kernel? Or is there some rationale behind this that I am missing?


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/01/2014 11:30 PM, Rahul Sundaram wrote:

You are again missing the point that when evaluating changes, you can't
do so against a hypothesized change that noone is working on.  You will
have to evaluate it against status quo vs someone willing to do the work
involved.  You are not volunteering to work on what you are proposing so
it wouldn't get done unless someone else buys into your ideas and so far
noone has.


I think you are missing the point. As I do not have the knowledge about 
anaconda nor other install related programs to do the change myself 
(which I would, if I was part of that group and had knowledge of 
Anaconda and related programs) my proposal could be regarded as a RFE to 
improve the handling of mail created by different programs and daemons.


Some regard mail sent to /var/spool/mail/root as lost, my proposal make 
these mails visible to the (chosen) user. This is a good thing. And, as 
it is now, in a new install of F20, these mail will be totally lost, 
they will not even end up in /var/spool/root. Which is a bad thing.


This by no means mean that I am not volunteering, it simply states that 
I do not have the knowledge to do these changes myself, nor am I part of 
the group working with those programs.


Is not one of the reasons for the these mailing lists to encourage 
people to discuss things like this (changes to improve Fedora)?



You haven't considered all the different use cases which
makes it very difficult to make any meaningful decisions during
installation time.


How could adding a user to /etc/aliases create any problems? It just 
tells the system which user should get the mail now sent to root.


The proposed question could (should) be asked when the system is 
restarted for the first time, and the first user is created. No 
implications come to mind.


In a system without users the mail ends up in root mail as now. No 
implications come to mind.


What use cases do I miss? And in what way would these makes it very 
difficult to make any meaningful decisions during installation time. 
Could you give me any examples.



I won't list them but one quick example:  Anaconda
doesn't require you to create a user at installation time. Instead you
can do so during initial-setup time and that user may not be a local
user at all.


u...@remote.host added to /etc/aliases is also valid. Not adding 
anything to /etc/aliases is also valid (mail ends up in 
/var/spool/mail/root as before). Again, no implications come to mind.



The current design of the installer is to do the minimum
needed during installation time and your proposal doesn't fit with that
model either.


I have clarified the proposal above. The question about /etc/aliases is 
supposed to be asked when you create the first user of the system. If 
you chose not to use /etc/aliases, the mail ends up in root mail as 
before. It fits the current model without problems.



  As always that depends on the use case (see at the end)

I said common use cases.  If you have to fallback to using grep, so be
it but what journalctl offers is a supset of what traditional syslog
daemons offer for a local user.  That is undisputed.


A (very) common use case is that you want to find something in the log. 
The first thing you do then is 'grep /var/log/applicable_log_file'. Yes 
journalctl has options for some things that you use grep for when 
looking at the /var/log files, but for many use cases you still need to 
use grep (and as seen in my earlier post, it can take extremely long 
time grepping output from journalctl when the journal is big).


If you know a better way to search for a random text segment in the logs 
(using journalctl) than using grep, please let me know.



Unfiled bugs
doesn't fundamentally change that although if you find any, you can file
them and get the transition to be smoother.


Do you regard the sluggish journal I have as a bug? I will gladly file a 
bug if you think so.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 01:05 AM, Rahul Sundaram wrote:

  my proposal could be regarded as a RFE to improve the handling of
mail created by different programs and daemons.

No.  Not unless it is actually filed in bugzilla with the details.
Filing a RFE requires no prior knowledge other than how to file it which
you already have.


So what do we have these mailing list for if we are not supposed to 
discuss ways to better Fedora? Rahul, I simply do not understand you on 
this issue.



  How could adding a user to /etc/aliases create any problems? It just
tells the system   which user should get the mail now sent to root.

  When no users are created by the installer, there is nothing to add to
/etc/aliases and as I noted before, user creation is an optional step
within the installer.  I don't see anything in your proposal that
addresses this.


As I mentioned before, /etc/aliases will in that case be intact and mail 
will be sent to root, just as it has been done for years.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 12:28 AM, Lars E. Pettersson wrote:

On 01/01/2014 11:30 PM, Rahul Sundaram wrote:

...

Unfiled bugs
doesn't fundamentally change that although if you find any, you can file
them and get the transition to be smoother.


Do you regard the sluggish journal I have as a bug? I will gladly file a
bug if you think so.


1047719

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 01:12 AM, Lars E. Pettersson wrote:

On 01/02/2014 01:05 AM, Rahul Sundaram wrote:

...

  When no users are created by the installer, there is nothing to add to
/etc/aliases and as I noted before, user creation is an optional step
within the installer.  I don't see anything in your proposal that
addresses this.


As I mentioned before, /etc/aliases will in that case be intact and mail
will be sent to root, just as it has been done for years.


Let me rephrase that.

* The question should be in that part were you create the first user on 
the system (and after the user creating step, disregarding if you have 
added a user or not)

* You can chose
- keep /etc/aliases as is (this is how it has been for years)
- add the newly created user (if you added one)
- add a remote user or users (u...@somewhere.else)
- or add a combination of local user and remote user(s)

If you do an install where this question (add a new user) does not 
appear, /etc/aliases will be intact and mail will be sent to root, just 
as it has been done for years. If you do an even more esoteric install, 
you probably know how to change /etc/aliases yourself, and no action 
will be taken.


Hope this made it a bit more clearer.

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 01:51 AM, Rahul Sundaram wrote:

I don't see the installer developers will agree to this proposal.  If
you want this amount of control, you are better off using kickstart IMO
but feel free to file it if you want to.


The proposal is intended to help the non technical users of Fedora, and 
I do not see them using kickstart, so that is not a solution.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 02:01 AM, Joe Zeff wrote:

ICBW, but I think he means that while we can work out exactly what
enhancement is needed and what's just re-inventing the wheel, nothing is
going to get done unless somebody files the appropriate RFE.


Yes, and at the moment we are in the work out phase. Next step is of 
course a RFE.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 02:00 AM, Rahul Sundaram wrote:

  As I mentioned before, /etc/aliases will in that case be intact and
mail will be sent to root, just as it has been done for years.

So in the end you will be adding a complex UI for a optional edge use
case.


edge use case? I have to strongly disagree. We have mail from 
different daemons etc that ends up in mail to root. The normal non 
technical user does not see this mail, and may even by totally unaware 
of it. This mail should be sent to the non technical user in an easy way.


One easy way to make the non technical user aware of this, and to set up 
the system so that he/she receives this mail, is my proposal.


The technical user already knows all this and makes the changes needed 
manually after installing Fedora. So this proposal is, again, to make 
the system easier to use for a normal non technical user.


 None of this will become part of the default workflow.

Sorry. I do not follow you here. I am not sure what you mean.

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 02:17 AM, Rahul Sundaram wrote:

Yes but non technical users wouldn't care to navigate the UI you are
proposing either.   The entire proposal only satisfies a very small
small niche for users receiving root mail and want to control exactly
how they get it during installation itself.


Why would they not care? The UI will make them aware of something they 
probably is not aware of. I can not see that lost emails is a good 
thing. Better to make the user aware of that that mail exist, and make 
it easy for them to receive it.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix

On 01/02/2014 02:31 AM, Rahul Sundaram wrote:

Why? Non technical users don't care about daemons. They are not
expected to baby sit daemons or diagnose problems with them. What
specifically did you expect is important enough in there? Show me an
example

Why? For the same reason we have notifications.

OK, one example:

A user might install yum-cron to update the system. It could be nice to
know about errors leading to yum not updating the system.

At the moment I get the following from my yum-cron (due to this yum is
not updating):

/etc/cron.hourly/0yum-hourly.cron:

Traceback (most recent call last):
[ ... a lot of trace lines removed ...]
yum.Errors.NoMoreMirrorsRepoError: failure: repodata/repomd.xml from
fedora-chromium-stable: [Errno 256] No more mirrors to try.
http://repos.fedorapeople.org/repos/spot/chromium-stable/fedora-20/x86_64/repodata/repomd.xml:
[Errno 14] HTTP Error 404 - Not Found

None of this will become part of the default workflow.

Sorry. I do not follow you here. I am not sure what you mean.

The default workflow of the installer does not mandate creating a non
root user

Yes. And in my proposal, described earlier, that use case is taken care
of (either everything will be as it has been for years, i.e.
/etc/aliases is intact and the mail end up in mail to root, or you can
chose to send it to a remote user)

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 02:55 AM, Rahul Sundaram wrote:

Notifications aren't the same UI as email.  Even a cursory guide on UI
would tell you that.


We have notifications to notify the user. The mail sent to root is (in 
most cases) to notify the user. The UI differ, but it is used, in this 
context, for more or less the same thing, notifying the user.



OK, one example:

A user might install yum-cron to update the system


Bad example. Non technical users don't install yum-cron.


Why not? The might...

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 03:08 AM, Rahul Sundaram wrote:

Sure but context in which they are used are very different.  If you
really want to know the difference in detail,  I recommend you get a
good UI book.  My suggestion would be Don't make me think!  by Steve
Krug.


Rahul, I am not talking about the UI, I am talking about the information 
you get from the two systems, and what that content tells the user. The 
UI is totally irrelevant in this case.



In that case, I wouldn't consider them non technical users.  Like I
said, your notion of what non technical users seems pretty skewed.   Non
technical users don't care about automated updates on the command line
and certainly don't try to resolve failures in third party repos.


Even non-technical user do strange things, so I would say that your 
notion of what non technical users do is pretty skewed.


If they do not care about problems with updates etc, then why do we have 
notifications? They serve, in this context, the same purpose, informing 
the user about problems with the system.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 03:20 AM, Rahul Sundaram wrote:

  UI always matters especially when we are talking about non technical
users.  A typical non technical user would click on updates when the DE
notifies them and nothing more complicated than that.


Again. A notification notifies the user, a mail notifies the user. I.e. 
two different ways of notifying the user. The UI is totally irrelevant 
in this case. The relevant part is the text message presented to the 
user. This text message can come from a notification popping up on the 
screen, or from a a mail, the UI does not matter at all.



It is based on real life experiences dealing with them on a regular
basis and development of distribution cannot be based on supporting
strange choices from users.


So you think it is better that these mails, sent to root, is lost, 
i.e. never delivered to the user? Why?



You cannot expect non technical users to do
anything about third party repository failures.  Color me unconvinced by
your example.


You missed the point. The point of the example was not fixing third 
party repository failures. The point was that the user was informed 
about an error that stopped yum from working.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 03:39 AM, Suvayu Ali wrote:

I'm sorry but I do not see the reasoning behind the assumption:
non-technical implies we need to protect them from good practice.


Perhaps a bad term to use on my part. New Linux user would perhaps be 
better. The idea was to make it easier for them to discover problems 
with their system. As the MTA has been removed, they will potentially 
miss important information.



What does removing an MTA (IOW system mail) serve?  If the argument is
saving resources, then one could counter argue a non-technical user is
less likely to care about saving system resources.


With current day computers an MTA for local delivery is no problem at 
all. They have all been locked down for quite a long time (only 
accepting mail from 127.0.0.1) so they have no big security risk either.


Lennart Poettring mentioned the following reasons (07/22/2013 06:36 PM, 
Re: F20 System Wide Change: No Default Sendmail)


since the current way it is set up by default it just eats up messages
silently, with not indication of error and no useful tools installed to
actually get the messages out of it again.

I think, based on other writings, that he means that mail is eaten up by 
being delivered to /var/spool/mail/root where the user can not read it. 
With no useful tool he means that we have no mail client that can read 
spool mail.


Spool mail can be read by mutt, Thunderbird, and probably other mail 
clients. What is needed is an easy way to get the mail to a suitable 
user. That is where my proposal comes in.


So, in my opinion, removing a local delivery MTA was wrong. It should be 
added again, and something in the line of my proposal should be added so 
that root mail is sent to a suitable user.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: announcement --- planned Yum replacement now ready for user testing


On 01/02/2014 11:54 AM, Ales Kozumplik wrote:

yes that's the idea. In practice however, a user doesn't type 'dnf erase
-y kernel' by accident and we don't feel the need to protect users who
really know what they are doing from doing so.


I would urge you to reconsider this given the importance of the kernel.

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: systemd-journald, was: Unintended consequences of no default MTA - How best to fix


On 01/02/2014 04:33 AM, Chris Murphy wrote:

rsyslog pulls data directly from journal files, so the source data is 
identical. What's different is how journalctl displays it compared to the 
message file rsyslog produces from the same journal file. I think this might be 
more a feature request of rsyslog than systemd, but if you're going to ask two 
projects to somehow negotiate and coordinate on producing an identical 
formatting of the journal file, I think it won't go anywhere. If you prefer the 
formatting of rsyslog then use that. If you prefer the formatting of journalctl 
use that, it's already available anyway and even has advantages to help you 
parse it to get what you're looking for.


If we have something (journal(ctl)) that replaces something else 
(syslog), it is good thing to be backwards compatible. As seen the 
differences are minor. Keeping these minor changes is like the saying 
standards are good, everyone should have one, in practice this does 
not work, and the minor changes (may) pose problems to certain scripts. 
The simple spolution is to make the output the same (which would be easy 
to do as they are created by the same underlying structure, just as you 
mention).



I think this is the response you're likely to get if you get one at all:
https://lists.fedoraproject.org/pipermail/devel/2013-July/185783.html


Yes, sadly enough...


What improvements? Is it possible to get it a pixel perfect match using 
options?


There are a lot.


I was thinking of Rahuls statement that the output from journalctl and 
syslog was pixel perfect, which it is not, and he mentioning options. 
As I understand it, no options are available to do the outputs pixel 
perfect


Regarding the journal in general, yes, it has many options that make it 
quite usable, and I do use it from time to time. In my situation, with a 
journal of about 3.7 GB, it is extremely slow though, which makes the 
journal hard to use, even systemctl status something takes time, as 
it has to go through the journal to output the last lines from the log.


This may all be a bug (I filed bug 1047719 on this).

Anyhow, thanks for the information about options etc. Sadly the man page 
is somewhat sparse on examples which makes the transition to journalctl 
a bit hard.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 04:40 AM, Chris Murphy wrote:

Why put a feature in the GUI installer to add a user to /etc/aliases for
getting system mail messages when there isn't an MTA? Since the MTA will
need to be installed, edit /etc/aliases at that time? This seems to add
complexity for minimal value.


My proposal is to keep the MTA, not to loose the messages that we now 
loose due to not having an MTA (I opposed removing the MTA in the first 
place). To get these now lost mails to the (main) user the user has to 
made aware of the mail to root, and instead send it to the applicable 
user. One way to do this is by making it (setting up /etc/aliases) a 
part of the installation process, as I described earlier.


The value is great, as the mail now lost is no longer lost, and instead 
sent to the user of the system.



be exposed in GUI, to me it sounds like an edge case request.


Important mail to/from root is not an edge case.

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 07:30 PM, Chris Murphy wrote:

There is no deficiency in omitting the installation of something that does 
nothing by default. To gain functionality from sendmail required the user 
configure it.


It delivers mail, so it certainly does something. It is not an idle 
process doing nothing.



Since the user needs to know enough to configure it, for it to do anything 
useful, there's no meaningful problem with requiring users who were going to 
have to configure one anyway to now install it.


A user only needs to know how to edit /etc/aliases, i.e. add a line 
'root: username' to it, run newaliases (or something in the line of my 
proposal earlier), and to setup the mail client to read that mail. Not 
more esoteric than to setup ordinary mail.


Not having a MTA leads to lost mail, this has to be addressed and solved 
before the MTA is removed.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 07:52 PM, Chris Murphy wrote:

On Jan 2, 2014, at 5:34 AM, Lars E. Pettersson l...@homer.se wrote:

...

Important mail to/from root is not an edge case.


So important that by default root isn't informed of these messages?


Huh?


With sendmail I was not informed of any such messages when logging in as root. 
Without sendmail, there's been no change in behavior at all. So what am I 
missing, exactly? How am I missing it?


Log in as root, write mail, press enter, there you go.

How you miss it?

With an MTA mail is delivered to root until you change /etc/aliases. To 
read roots mail you have to login as root and run a mail client. With a 
change of the aliases file you can chose to deliver root mail to a user, 
on the current system, another system, or a combination of these. The 
mail is read using a mail client.


Without an MTA these mails are totally lost, they do not appear in 
/var/spool/mail/root, nor any other user, they are never deliver, and 
thereby lost.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 08:09 PM, Chris Murphy wrote:

On Jan 2, 2014, at 11:45 AM, Lars E. Pettersson l...@homer.se wrote:

It delivers mail, so it certainly does something. It is not an idle process 
doing nothing.


I've never seen it do anything since I started using Fedora, except cause 
longer boot times.


Strange, what kind of install do you have?

Long boot time would be it waiting for network, otherwise it starts quickly.

9.093s postfix.service (my mailserver)
64ms sendmail.service (my desktop)


A user only needs to know how to edit /etc/aliases, i.e. add a line 'root: 
username' to it, run newaliases (or something in the line of my proposal 
earlier), and to setup the mail client to read that mail. Not more esoteric than to 
setup ordinary mail.


It's a minority use case.


How can it be a minority use case?


Not having a MTA leads to lost mail, this has to be addressed and solved before 
the MTA is removed.


Presumably if it's that important, an error is generated due to the lack of an 
MTA? If not, then it's not important. If ithere is an error, then at least it's 
being logged somewhere where it might be seen,


Someone sent a question about how to read mail to root without the MTA 
delivering it. It was logged that cron had a problem, but the output 
from cron, usually sent as a mail, was lost.


Exactly this question I asked Lennart Poettering on the devel list, but 
sadly got no answer.


How do we solve this problem without an MTA? (cron output lost)

 rather than the sendmail by default case which is the silent 
accumulation of emails in /var/spool/mail/root that most users have *no 
idea* is happening, and even if you managed to inform a majority of 
users this is happening,


This was the reason behind my proposal, to make it more obvious to the 
user that (possible) important mails from the system show up in spool mail.



the majority (like me) still have no idea how to retrieve, redirect, or stop 
them from being unnecessarily generated.


In what way unnecessary? If cron has problems, do you not want to know 
the output of that cron job, to be able to solve the problem?


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 08:32 PM, Pete Travis wrote:

Before, if you suspected a problem with a crond job, you looked at the
user's mail. Now, if you suspect a problem with a cron job, you look at
the journal.

Is there something you expect to see that is missing from the journal?


Yes, the output of cron, that is not a part of the journal output.

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 08:31 PM, Chris Murphy wrote:

Right. I wasn't informed they exist, therefore they are not important messages.


You not being informed has nothing to do with the importance of the 
message content.


(My proposal was a direct hit at this, making it clear for the user that 
potentially important mails are generated on a Linux systems, and giving 
a way for you to receive them)



The *overwhelming* use case of Fedora, users login at gdm into gnome-shell. 
They don't login as root. How are these users informed of silently accumulating 
emails? Oh, they aren't. Guess they aren't important messages.


Again, this was the reason for my earlier proposal to include a setup of 
/etc/aliases at first bot setup of the system,.



And even in the case where I do login as root, why would I type mail? How would 
that ever occur to me?


If new mail arrives while you are logged in as root you will be 
informed. But again, my proposal was to remove this problem by making 
spool mail visible to the user.



How you miss it?


Miss what? Typing a word I have no reason to type?


Sorry, my bad, I was just repeating your question, the two following 
paragraphs was the answer to that question.



With an MTA mail is delivered to root until you change /etc/aliases. To read 
roots mail you have to login as root and run a mail client. With a change of 
the aliases file you can chose to deliver root mail to a user, on the current 
system, another system, or a combination of these. The mail is read using a 
mail client.


Sounds like it's from the pleistocene of computing. It's obsolete for the 
majority.


In what way is it obsolete?


But happy days, you can just yum install and get the result you want, it's 
self-evident for your use case. It's not self-evident how I get rid of useless 
things that I don't even know exist, so the burden shouldn't be on me. Thanks 
to FESCO for getting rid of this crusty thing I never used or benefited from in 
any way shape or form.


Well, then you miss potentially important mails from the system.


Without an MTA these mails are totally lost, they do not appear in 
/var/spool/mail/root, nor any other user, they are never deliver, and thereby 
lost.


They were being lost anyway.


No.


When the devel@ mega thread appeared in July, was the first time inyears I went 
to look for these messages. And I found a pile of utterly useless crap being 
generated; and without notification, or a good reason for them to be generated 
in the first place. I'm glad it's gone by default.


Please read my proposal again, it addresses the issues you are mentioning.

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 08:45 PM, Chris Murphy wrote:

Is there something you expect to see that is missing from the journal?


Yes, the output of cron, that is not a part of the journal output.


Then cron is broken.


cron by default sends the output to root

$ head /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

From 'man cron':

When executing commands, any output is mailed to the owner of the 
crontab (or to the  user  specified  in  the MAILTO  environment 
variable in the crontab, if such exists).


It also states:

Any job output can also be sent to syslog by using the -s option.

The problem with that option is that the output from cron can 
voluminous, and voluminous messages are better suited as mails.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 08:45 PM, Chris Murphy wrote:

In the Fedora 19 era it was ~ 30-60 seconds according to systemd-analyze blame. There was 
a bug on it in the bugzilla which was blocking the why we boot so slow 
tracker for systemd. I think it's since been fixed, not sure, but now that the glory of 
no sendmail by default is here with Fedora 20 I don't need to think about that bug 
anymore.


On a Fedora 19 desktop:
27ms sendmail.service

How can 27 or 64 ms to start sendmail be a problem?


Really? In the whole world of computing you don't see this is a tiny tiny 
minority use case? It's so small it's not even really an edge case, it fell off 
the edge years ago. Even if we look at just linux derived systems, no Android 
system even has root enabled by default, let alone an MTA. It has a modern way 
of informing me of problems rather than sending me useless spam, without 
notifications of such.


No, loosing important mails is not a minority use case.


How do we solve this problem without an MTA? (cron output lost)


yum install sendmail?


How can we solve the problem without having, or installing, an MTA?


So you think a majority of users use cron?


You do not have cron installed and running?


I don't use cron. Probably in five years or so we can have a conversation on it 
not being installed by default.


Don't think so.

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 09:24 PM, Chris Murphy wrote:

OH but wait, I don't really want more email because I think email in general 
sucks because of abuse just like this. And on top of it, from my sampling, the 
messages were useless, so had I been getting them by email, I'd have considered 
them spam and it would have made me angry that I was receiving them.


Well, then you just skip that question I propose that we ad to the first 
install/setup program. And you will never ever get any mails and will be 
happy ever after.



I'm glad Fedora caught up with the rest of modern computing and got rid of it 
by default.


This has nothing to do with modernity at all.


And guess what! You can still install it and get the behavior you want.


That's not the point. It's about sane defaults so that potential 
important message are not lost.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 09:45 PM, Chris Murphy wrote:

If they're important, they should go in the journal.


How big files can you send to the journal? The content we are talking 
about can be everything from oneliners to really long tracebacks.


If it ends up in the journal, how will the user be informed that the 
content is in the journal and should (perhaps) be acted upon?


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 10:08 PM, Chris Murphy wrote:

How big files can you send to the journal? The content we are talking about can 
be everything from oneliners to really long tracebacks.


By default it is compressed, and set to use 10% of free space. It's 
configurable, man journald.conf.


I meant how big files, i.e. content, can you send to the journal, not 
the size of journal itself. The content now sent via mail, that you want 
to be sent to the journal, can be quite voluminous. So what is the size 
limit of the content sent to the journal?



If it ends up in the journal, how will the user be informed that the content is 
in the journal and should (perhaps) be acted upon?


On Fedora 19 and older, when sendmail was the default, I was not ever informed 
of such things. Therefore the default installation of an MTA is orthogonal to 
actually successfully informing the user of anything.


Well, to be picky, you was informed, but you did not know were to look 
for the information you was informed about. This is (was) a lack in the 
documentation of Fedora. If this had been documented, you could have set 
up /etc/aliases and gotten informed.


But if this information now instead ends up in the journal, how to 
inform the user to look there?



If you want to do this correctly, you need a notification API. And I think 
Gnome at least has something like this now. For things like hard drives that 
die in a raid5, I see a banner alerting me of this fact, by default, in Gnome 
Shell. I don't know how that works but I don't think it's smartd that uses this 
API and informs Gnome. I think Gnome has it's own monitoring of such things. So 
either the program you want monitored needs to support such an API so it can 
issue a message for user notification in certain instances. Or maybe you need a 
configurable journal monitoring service that triggers notifications when 
certain priority messages appear in the journal.


Yes, that works for the desktop user.

But how do we do this in the use case of a home server? The user may not 
log into a graphical account that often. So how do we inform the user then?


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/02/2014 11:31 PM, Rahul Sundaram wrote:

Yes, all critical notifications are supposed to stay persistent.  That
is the right model to alert desktop users about anything relevant enough
to bother them with.   Not emails.


Works OK on a desktop, but how is the home server use case, where the 
user is not logged in on the computer, supposed to be handled?


Regarding emails. I still have not gotten any response from anyone on 
how to handle the output from, as an example, cron, logwatch, etc. 
Hopefully someone could tell how that is supposed top be taken care of 
now that the MTA is removed. That would involve both adding to the 
journal, and notify the user, and/or other actions. Shouldn't that have 
been addressed *before* removing the MTA?


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: f20 - gedit


On 01/03/2014 06:17 AM, Ahmad Samir wrote:

On 26 December 2013 20:00, Lars E. Pettersson l...@homer.se wrote:

...

As the App Menu works bad when using multiple windows and focus follow
mouse, this should perhaps be a part of gnome-tweak-tool (a tick box there
to chose App Menu or not), so one doesn't have to dig into dconf with
dconf-editor. Will make life a tad easier for the ordinary user.

I should perhaps write a RFE on that...



I didn't know it at the time, but it looks like they have already
added such an option in gnome-tweak-tool - Top Bar - Show
Application Menu in GNOME 3.10.


Ah, that seems to be the solution, had missed that. Then I don't need to 
file a RFE :)


Thanks!

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/03/2014 05:07 AM, Pete Travis wrote:

I think there was some misunderstanding here. If you can't find your
cronjob output in the journal, *your* cron is broken.


Default installation:

[root@tux ~]# rpm -V cronie
[root@tux ~]# rpm -q cronie
cronie-1.4.11-4.fc20.x86_64
[root@tux ~]# rpm -V crontabs
[root@tux ~]# rpm -q crontabs
crontabs-1.11-7.20130830git.fc20.noarch


Before I get too
far in, in my opinion, mails are good for notification, voluminous
content should be in the logs that the mail notifies about. The journal
is good at logs.


Mail has no problem handling voluminous content. It is also very easy to 
retrieve without knowing quite a lot of strange options to a command 
that you have to print in a terminal.



$ journalctl SYSLOG_IDENTIFIER=CROND -f  #filtered for convenience


Where is my output from yum-cron (yum-cron is run hourly and it has a 
fault at the moment due to spots Chrome repository not yet being up to 
Fedora 20)?


[root@tux ~]# journalctl SYSLOG_IDENTIFIER=CROND --since=-2h
-- Logs begin at Tue 2013-07-02 20:53:56 CEST, end at Fri 2014-01-03 
11:40:01 CE

Jan 03 09:50:01 tux CROND[3666]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 03 10:00:01 tux CROND[3895]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 03 10:01:01 tux CROND[4044]: (root) CMD (run-parts /etc/cron.hourly)
Jan 03 10:10:01 tux CROND[4358]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 03 10:20:01 tux CROND[5345]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 03 10:30:01 tux CROND[5521]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 03 10:40:01 tux CROND[5790]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 03 10:50:01 tux CROND[6135]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 03 11:00:01 tux CROND[6388]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 03 11:01:01 tux CROND[6541]: (root) CMD (run-parts /etc/cron.hourly)
Jan 03 11:10:01 tux CROND[6763]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 03 11:20:01 tux CROND[6963]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 03 11:30:01 tux CROND[7380]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 03 11:40:01 tux CROND[7681]: (root) CMD (/usr/lib64/sa/sa1 1 1)


But wait! These things could get all mixed up on a busy machine, you
say! Let's take a closer look at a message:

MESSAGE=(pete) CMDOUT (New Things are Different.)

[lots of lines removed]

 SYSLOG_IDENTIFIER=CROND
 _CMDLINE=/usr/sbin/CROND -n
 _BOOT_ID=0557929cbde247928f945d8b53a6e067


How is non technical user supposed to understand this? What command 
sequence did you use to get that output?



$ journalctl SYSLOG_IDENTIFIER=CROND _AUDIT_SESSION=83 -b


How do you find out the _AUDIT_SESSION to use?


Stop! I don't want all that extra information, you say! `journalctl`
should KNOW I'm not interested in the timestamp, or the hostname, or the
name and PID of the reporting binary - just give me the message!

journalctl SYSLOG_IDENTIFIER=CROND _AUDIT_SESSION=83 -o cat
(pete) CMD (LARSHAPPY=no; if [[ $LARSHAPPY == no ]]; then echo -e
This isn't the same.\nNew Th
(pete) CMDOUT (This isn't the same.)
(pete) CMDOUT (New Things are Different.)
(pete) CMDOUT (Some people like the old thing.)


That is several messages. I want only one...

How am I notified that I should look in the journal when things go 
wrong? (With mail I am notified and also get the log lines all at once)



I'll agree that this isn't as *simple* as banging out a four letter word
and reading message, but the journal can provide context, too.


I am not arguing whether the journal is good or not, I am arguing 
whether removing the MTA used to send mail, sent from some applications, 
is good or bad. As I see it, as long as some applications do send mail, 
we have to have a MTA. Or at least let those applications have a 
requirement of a MTA so that the MTA is installed when those 
applications are installed on the system. That is my key argument, not 
that the journal is bad.


The journal is OK, but very hard for a non technical user to use. What 
is needed is probably a very good graphical frontend that hides all 
these strange things you show us in your mail. How is a non technical 
user supposed to understand all this?



You're putting lots of effort into complaining about a hugely useful
tool, and apparently little into learning about it.  If the complaint is
about cronjobs, start here:


I am not complaining about the journal. But please let us know where to 
find a journal for dummies text where we can find out how to become 
journal experts. The man page is a bit sparse on information.



Of course, if you like the old way, you can just install and configure
an MTA.


I have to as long as some applications use that path to send messages to 
me. The same thing goes for all others installing these applications. 
Without a MTA these messages are lost in bit space.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/03/2014 12:01 AM, Rahul Sundaram wrote:

https://fedoraproject.org/wiki/F20_release_announcement#No_Default_Sendmail.2C_Syslog


Rahul, as long as we have applications that do send mail, we need an MTA 
to take care of these mails, or else they are totally lost. Or at least 
let those applications have a requirement of a MTA so that the MTA is 
installed when those applications are installed on the system.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/03/2014 12:56 AM, Chris Murphy wrote:

If you like the MTA method of being notified, install an MTA. Simple. You have 
been told this numerous times so don't say you haven't gotten any responses.


My question was how those, that do not have a MTA installed, is supposed 
to be notified. Could you perhaps answer that for me?


We do have applications that actually do send messages as mails. Without 
a MTA installed those messages are lost. How should the user on a non 
MTA system get notified from those applications?



No because no one was getting messages with the MTA unless they went looking 
for them in the first place. And now they merely have one more step which is 
installing the MTA of their choice, which for a lot of Fedora users wasn't 
sendmail anyway.


No one? How do you know that? You not knowing says nothing of all the 
others.



Sendmail was taking up space on the install media, on users computers, for no 
benefit for the vast majority of users. I don't know how many times this has to 
be said - look at the number of unique individuals involved in the conversation 
in this thread? It's less than a dozen. So we're talking thousands of users, 
and less than 12 give a crap whether an MTA is installed by default or not. 
It's really close to zero people care about it.


Sendmail is only a small portion of the install media space, it also 
starts quickly and should be no problem to handle at all on a normal 
computer. And as long as we have applications that do send mail we need 
an MTA to take care of those mails. Fix the mail situation first, *then* 
remove the MTA, if that is what you want. Now they have removed the MTA 
without fixing the applications that do need an MTA.


How many that participates in a discussion says nothing about the majority.

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/03/2014 12:48 AM, Chris Murphy wrote:

I meant how big files, i.e. content, can you send to the journal, not the size 
of journal itself.


It accepts a stream with a configurable rate limiter.


No size limit? How does it show up in the kernel? Say that I have the 
following data, how is it presented, and how do I retrieve it?


--- start text
/etc/cron.hourly/0yum-hourly.cron:

Traceback (most recent call last):
  File /usr/sbin/yum-cron, line 721, in module
main()
  File /usr/sbin/yum-cron, line 718, in main
base.updatesCheck()
  File /usr/sbin/yum-cron, line 606, in updatesCheck
self.populateUpdateMetadata()
  File /usr/sbin/yum-cron, line 418, in populateUpdateMetadata
self.upinfo
  File /usr/lib/python2.7/site-packages/yum/__init__.py, line 1113, 
in lambda

upinfo = property(fget=lambda self: self._getUpdateinfo(),
  File /usr/lib/python2.7/site-packages/yum/__init__.py, line 1023, 
in _getUpdateinfo

if 'updateinfo' not in repo.repoXML.fileTypes():
  File /usr/lib/python2.7/site-packages/yum/yumRepo.py, line 1670, in 
lambda

repoXML = property(fget=lambda self: self._getRepoXML(),
  File /usr/lib/python2.7/site-packages/yum/yumRepo.py, line 1666, in 
_getRepoXML

self._loadRepoXML(text=self.ui_id)
  File /usr/lib/python2.7/site-packages/yum/yumRepo.py, line 1657, in 
_loadRepoXML

return self._groupLoadRepoXML(text, self._mdpolicy2mdtypes())
  File /usr/lib/python2.7/site-packages/yum/yumRepo.py, line 1631, in 
_groupLoadRepoXML

if self._commonLoadRepoXML(text):
  File /usr/lib/python2.7/site-packages/yum/yumRepo.py, line 1456, in 
_commonLoadRepoXML

result = self._getFileRepoXML(local, text)
  File /usr/lib/python2.7/site-packages/yum/yumRepo.py, line 1234, in 
_getFileRepoXML

size=102400) # setting max size as 100K
  File /usr/lib/python2.7/site-packages/yum/yumRepo.py, line 1030, in 
_getFile

raise e
yum.Errors.NoMoreMirrorsRepoError: failure: repodata/repomd.xml from 
fedora-chromium-stable: [Errno 256] No more mirrors to try.
http://repos.fedorapeople.org/repos/spot/chromium-stable/fedora-20/x86_64/repodata/repomd.xml: 
[Errno 14] HTTP Error 404 - Not Found

--- end text


Even if I set up /etc/aliases I'm not informed if I don't use the local system 
to receive emails. And even if I do, it's not going to send those emails to 
gmail is it?


OK, the documentation should have let you now how to set up 
/etc/aliases, *and* also inform you to set up the mail client of your 
choice to receive that mail.


The following solves the gmail problem (/etc/aliases):
root: u...@gmal.com

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/03/2014 12:35 PM, Rahul Sundaram wrote:

You talked about home servers and I pointed out that this change was
done only on the desktop live image.  Instead of acknowledging that, you
are talking about how some people need an MTA which I don't think anyone
has denied.  If some package that requires an MTA doesn't depend on it,
that is a packaging bug.


Yes, instead of of discussing different levels of users, or different 
levels of computer systems, I tried to point on the route problem, not 
getting astray on tangents out of tangents, to steer the discussion onto 
a more constructive path.


The route problem is what I wrote. That we have applications that 
actually rely on mail, and that these do need an MTA to communicate with 
the user.


If this is a packaging problem, it should be addressed, and it would 
have been good if this had been taken care of before removing the MTA.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/03/2014 12:57 PM, Rahul Sundaram wrote:

It was you who brought in the topic of home servers when this change was
done only on the desktop live image.  It is not clear from your reply
whether you were already aware of this fact or not.


Yes, in response to Yes, all critical notifications are supposed to 
stay persistent.  That is the right model to alert desktop users about 
anything relevant enough to bother them with. Not emails..


That (notifications) works on a desktop onto which a user log in, but 
not on a home server, that you do not log in to that often. So that was 
more a general comment directed to the use of notifications, pointing 
toward the fact that mails actually has some merit on some kind of systems.


So that particular comment was perhaps a tad off topic, and was, as I 
stated above, directed to the desktop notification system, not the no 
default MTA as this thread is (or should) be about. But we should 
perhaps delay a discussion about that to another thread another day.



If you find out any single package in the desktop live image that
requires an MTA to work on the default setup, feel free to file a bug
report.  Unknown bugs cannot be fixed.


I will make a fresh install in VirtualBox and take a closer look.

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: since F20 update, cron has stopped sending mail


On 01/03/2014 04:13 PM, Steven Stern wrote:

Any idea what I need to do to get my cron email restored?


Is it an upgraded system or a new install? If it is a new install 
sendmail is no longer installed, so you have to install it yourself.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: since F20 update, cron has stopped sending mail


On 01/03/2014 04:39 PM, Steven Stern wrote:

$ crontab -l


I had only root do cron stuff, but set up a small cronjob for my own 
user. That mail went through without a hitch. So it is probably not 
related to who is running cron, root or an ordinary user.


Could there, for some reason, be that your script did not output any 
data this time?


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: since F20 update, cron has stopped sending mail


On 01/03/2014 04:22 PM, Steven Stern wrote:

It's an upgrade. Sendmail is installed, enabled, and working.


Ah, OK. I also have an upgraded system, and I also have the same lines 
in the crontab file, so I think it should just work. Strange. What is 
the output of 'systemctl -l status crond.service'?


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/03/2014 06:31 PM, Pete Travis wrote:

On Jan 3, 2014 4:08 AM, Lars E. Pettersson l...@homer.se
mailto:l...@homer.se wrote:
 
  On 01/03/2014 05:07 AM, Pete Travis wrote:
 
  I think there was some misunderstanding here. If you can't find your
  cronjob output in the journal, *your* cron is broken.
 
 
  Default installation:
 
  [root@tux ~]# rpm -V cronie
  [root@tux ~]# rpm -q cronie
  cronie-1.4.11-4.fc20.x86_64
  [root@tux ~]# rpm -V crontabs
  [root@tux ~]# rpm -q crontabs
  crontabs-1.11-7.20130830git.fc20.noarch


Pete, you did not answer this part. As seen cron is untouched, i.e. not 
broken. I can not find any output from cron in the journal (you only see 
the trigger part in the journal). So please, how do I read the output 
from cron with journalctl?



  Mail has no problem handling voluminous content. It is also very easy
to retrieve without knowing quite a lot of strange options to a command
that you have to print in a terminal.
 

Yes, we know you prefer mail... Mail on the command line is exactly what
you describe - it requires knowing esoteric command line options to an
awkward terminal application.  Two unfamiliar and clunky terminal
applications for the purpose would be redundant, so one is gone.


What I prefer is not the discussion, the discussion is how to make sure 
that information is not lost for a user of Fedora. In Fedora we have 
some applications that do send mail. These mails will be lost on a 
system without an MTA. That is not a good thing, and that is what the 
discussion is about.


Mail on command line was an example of the most simplistic way to read 
mail. Most of us use full blow mail clients, I use Thunderbird, to read 
mail. Thunderbird can read spool mail without a problem. And spool mail 
can also easily be forwarded to gmail etc, if so wanted (as long as we 
have a MTA). Mail is easy to understand and grasp for most users.


The journalctl commands are way more esoteric than the mail command, and 
beyond what most normal users can/want to comprehend. So what the 
journal really need is a graphical frontend to help the non technically 
oriented users. But that is probably better discussed in another thread.



  Jan 03 11:30:01 tux CROND[7380]: (root) CMD (/usr/lib64/sa/sa1 1 1)
  Jan 03 11:40:01 tux CROND[7681]: (root) CMD (/usr/lib64/sa/sa1 1 1)
 

I see  CMD (run-parts /etc/cron.hourly, that could be where the magic
happens.  Maybe the output will show up with other filters, or it could
be rewritten to use systemd-cat.


What you see here is when cron is triggered. But I con not find any 
information on how to read the output that these triggered cron jobs 
(may) produce. How are those retrieved using journalctl? I have no clue, 
do you? (Or any other?)



  How is non technical user supposed to understand this? What command
sequence did you use to get that output?
 

A non-technical user would either understand by example - the part you
cut out - or, they are a nontechnical user and have no interest in such
things .


As I said before, a non technically oriented user should not be (forced) 
to use these esoteric commands to find information on how the system 
behaves. It is good and dandy for us that like to understand the system, 
but this has to be made way more easy to use, as I mentioned before.


Compare receiving a mail of the output from a cron job, with the 
journalctl commands you have shown. What do you think a non technically 
oriented user will find most easy to understand?



  $ journalctl SYSLOG_IDENTIFIER=CROND _AUDIT_SESSION=83 -b
 
 
  How do you find out the _AUDIT_SESSION to use?
 
I didn't guess. There was a straightforward and easy to follow example,
but you removed it.


Yes, but that part was just put into your mail (I removed the middle 
part), but were did it come from? How did you produce that output? Or, 
to have a perhaps more useful question, how do I find out what 
_AUDIT_SESSION is relevant for a certain log line?



  How am I notified that I should look in the journal when things go
wrong? (With mail I am notified and also get the log lines all at once)
 

How is a nontechnical desktop user notified of new mail? That's
rhetorical, don't answer. They aren't .


It shows up in their inbox.

How is non technical user notified to look in the journal?


OK, then, your argument is late and pointless. Appeal to fesco if you
feel strongly about adding sendmail to the default installation, such
decisions are not made on the user support list.


That does not stop us from discussing it. We now have a situation were 
certain applications do produce mail, and without an MTA those mails 
will be lost. That is not a good situation. This should have been taken 
care of *before* removing the MTA, so that information from the system 
is not lost. Why FESCO did not make sure of this is beyond me.



  I have to as long as some applications use that path to send messages
to me. The same thing goes for all others installing

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/03/2014 09:56 PM, Pete Travis wrote:

   $ journalctl SYSLOG_IDENTIFIER=CROND -f  #filtered for convenience
 
  How do you know which IDENTIFIER to use?  I could guess it should be
  CROND if I were to look at the output of journalctl in this case; but is
  there any canonical way to find this out?  Or is it just the unit file
  name?

I picked that by looking at the messages and pairing up the identifier
with my messages. It's reasonable to assume this will be consistent for
cron jobs, so I didn't demonstrate that part.


It should perhaps be added that jounralctl has auto completion. Write 
jounralctl and press tab twice to see what you can use, type 'journalctl 
SYSLOG_IDENTIFIER=' and press tab twice, and you can see what to use there.


With auto completion I see crond, CROND, and crontab. (None of these 
will give me the output from cron by the way.) What is the difference 
between crond and CROND?



`journalctl -o verbose' gives the extra metadata. There are other output
formats, ie json, but this seemed most useful here.


Thanks, that answered my question in the earlier mail from me.


key.  There is a section in the System Administrators Guide on the
journal, which I will probably update this weekend since the usage is
newly fresh in my mind.  It won't be published for f20 immediately, but
I can push a draft if anyone is interested in reviewing. (Hint, readers,
speak up, or I won't do the extra work)


OK, count me in... Could be a good way to get to know that system a bit 
better.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/03/2014 08:32 PM, Tom H wrote:

On Fri, Jan 3, 2014 at 11:10 AM, Lars E. Pettersson l...@homer.se wrote:

Rahul, as long as we have applications that do send mail, we need an MTA to
take care of these mails, or else they are totally lost. Or at least let
those applications have a requirement of a MTA so that the MTA is installed
when those applications are installed on the system.



The point that Chris has made is that these messages were already lost
for most users because they didn't actually exist.


That is not relevant.

(A side note, they [the messages] did exist, in /var/spool/mail/root, 
that the user was not made aware of this was a documentation error)



FESCO has to consider the use-case of the majority of Fedora users and
it decided that they don't need an MTA by default.


As long as some application use mail to inform the user an MTA is needed.


And, as has been said many times already, those who want an MTA,
_understand_its_purpose_,_and_use_the_features_that_it_provides_ can
install one.


That is not the point. The point is that (potentially) important mails 
are lost. Read the first paragraph starting with Rahul above.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/04/2014 02:10 AM, Chris Murphy wrote:

Exactly, it's about expectations. As an alternative OS, Fedora simply cannot depend on 
some 30 year old archaic user hostile way of unsuccessfully delivering 
supposedly important system messages. It's just absurd. And that cannot be fixed by 
somehow figuring out a way to get those emails delivered because it's a hideous way of 
notification anyway. I wouldn't want it to work. When I talk about the majority, I mean 
literally everyone using some kind of computing device.


So age is a bad thing? Why? If it has worked for 30 years, it is 
probably because that way of doing things has its merits.


That you despise mail has nothing to do with the problem we have here. 
We do have applications in Fedora that do send mail. If you are not 
interested in those mails, well fine, ignore them, and do something else 
instead, the message will still be created.


Either those applications has to be changed, to use some other sort of 
communication with the user, a communication that, for the user, works 
the same way (i.e. that the user is notified in  a similar manner, and 
speed, as before, but via another media). Or the MTA has to stay.


By removing the MTA those mails will be lost, and that has to be resolved.

Again, this has nothing, absolutely nothing, to do with loving or hating 
mail. It has to do with a way to inform the user that has to be handled 
in a manner that ensures that the user is informed.


Am I really that bad at explaining what the problem is?

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/04/2014 02:40 AM, Suvayu Ali wrote:

What I fail to follow is, why break the existing mechanism *before* we
have these other future notification mechanisms ready?


*Exactly*

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 NetworkManager bridged br0 firewalld dhcp not getting through?


On 01/04/2014 02:53 AM, Patrick Lists wrote:

Now my first thought is that it makes total sense this does not work
because clearly firewalld, systemctl and journalctl were forged in Mount


You could perhaps try to remove firewalld, or disable it, and run 
iptables with iptables.service that reads the file 
/etc/sysconfig/iptables to setup the firewall. The command iptables-save 
would give you a starting point for that file.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/04/2014 03:13 AM, Chris Murphy wrote:


On Jan 3, 2014, at 6:41 PM, Lars E. Pettersson l...@homer.se wrote:


On 01/04/2014 02:40 AM, Suvayu Ali wrote:

What I fail to follow is, why break the existing mechanism *before* we
have these other future notification mechanisms ready?


*Exactly*


Please, SNMP has been around since 1988. Gnome has had a notification system 
for several years at least, probably longer. If I did 10 minutes of research 
there are probably 1/2 dozen other notification systems out there, a few of 
which are reasonably mature.


What has this to do with the text you quote?

SNMP and the Gnome notification are two entirely different creatures, 
and can not be compared.



So how long do you want for your ancient email only sending program to 
modernize? They haven't picked an alternative by choice. And it is their choice 
to not do so. It is inappropriate for Fedora to sit on its laurels waiting for 
every program to modernize before it makes changes the benefit most users. And 
it's inappropriate for Fedora to dictate these programs use some other method 
of notification than email.


Why should they modernize? If something been around for 30 years, well, 
then it probably has so because of a reason. Please try to do some read 
in on the subject, and perhaps you will understand this very reason.



So *exactly* what are you two even talking about? Precisely how does waiting 
and doing NOTHING encourage program devs to change their notification methods? 
OH right, it doesn't do anything except enhance the stagnation and legitimize 
the non-working notification by email paradigm.


What we are talking about is compressed into the first sentence you 
quoted in this message. Please read that sentence again.



Guess what? Presumably the programs that you use that only notify by email, do 
not modernize because their user base doesn't care for any other kind of 
notification system. In which case you will have to install an MTA to get your 
important messages. I don't see what's so difficult to understand.


By removing the MTA you remove functionality that exist. That you and 
others do not use this functionality does not change that fact. If you 
want top remove that functionality, you first have to change the 
applications to use some other method of communicating with the user. 
This should have be done *before* removing the MTA, as removing the MTA 
remove existing functionality. Is this too hard to comprehend?


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/04/2014 02:59 AM, Chris Murphy wrote:

What I fail to follow is, why break the existing mechanism *before* we
have these other future notification mechanisms ready?


1. Most people weren't using it.


How do you know that?

The functionality is there, you not knowing about it is no reason to 
remove it.



2. No default MTA does *NOT* break the existing mechanism. It simply requires a 
minority of users to not be lazy whiners and yum install blahMTA.


It *does* break existing functionality.

Whiners about sendmail could equally well do 'yum remove sendmail' and 
be over with it. So what is your point? The fact that a user can select 
to add or remove a certain applications has nothing to do with what we 
are discussing now.



This whole thread is like someone died.


No.


Make it easy, just jump straight to acceptance. Nothing is broken.


It is broken. Read in on the subject, and you will see.

Please read the question you quoted, the first one in this mail. Try to 
understand what it says.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/04/2014 02:54 AM, Chris Murphy wrote:

Maybe. But at least as often or more, it's just becoming decrepit. It refuses 
to learn new tricks. It doesn't want to learn to write to a journal or use SNMP 
or Gnome desktop notification services, or anything other than emails that 9 
out of 10 people are not aware of exist or read or care to be notified in that 
fashion.


Then please tell us how this functionality should be moved to Gnome 
desktop notification, SNMP, etc. (you stated earlier that SNMP started 
in 1988, that's 26 years ago, isn't that archaic, old, decript, etc. 
also?), and at the same time retain the information that this 
functionality provides today. Please let us know how to do that.



Look the post office is shrinking because it has a product that has far far 
fewer use cases than before. Should it die totally? I don't know, probably not. 
But does it need to contract? Clearly yes. Email is a big reason why. And now 
there are many other ways to communicate, and abuses of email, that makes it 
time for email to be supplanted. Maybe not go away entirely, but for particular 
use cases. And this is not one of them.


There are more parcels sent around than ever, due to ebay and similar 
sites where people sell stuff. Does not the US postal service also send 
parcels?


What should we use instead of email?


We do have applications in Fedora that do send mail. If you are not interested 
in those mails, well fine, ignore them, and do something else instead, the 
message will still be created.


Fortunately, it's not created anymore.


Which removes existing functionality leading to lost information, which 
is a bad thing, and the reason for this little debate.



Imagine GIMP having some error and instead of a dialog, it sent an email! Ha! 
Talk about ridiculous. So yes, this really is about email. If my refrigerator 
emailed me the door was left open, I'd burn the refrigerator to the ground in 
public and post a video.


GIMP is a user level program with a GUI. What we are talking about are 
mostly system daemons. An entirely different creature.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/05/2014 02:27 AM, Chris Murphy wrote:

I suspect it's used a ton more than an MTA. I enable sshd on all of my Macs and 
Fedora installs as one of the first things done. MTA? Never. Not configured 
even one time in 24 years.


Do you have any numbers on that (MTA vs. sshd)?

So sshd should stay because you use it, and the MTA should go because 
you do not use it. I do not buy into that kind of logic.


Added to this, the MTA is used by some applications, removing the MTA 
breaks the notification mechanism these applications use, i.e. mails. 
Enabling or disabling sshd does not interfere with other applications 
notification systems.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/05/2014 09:25 AM, Frank Murphy wrote:

I use nfs from Windows 8.1 to Fedora (filestore\backup etc..)
As well as between Fedora Boxes


Have you tried sshfs? We moved to that at work years ago (to share 
between Linux boxes, but windows applications for sshfs also exist).


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: removing dnf from fedora 20


On 01/05/2014 02:42 PM, David Shwatrz wrote:

Is it OK to remove dnf with yum remove dnf ? will it cause any problems ?


If you upgrade from F19 to F20 dnf will not be installed, so I see no 
harm in removing it from F20.


yum is the main tool to use, dnf is installed to be tested.

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 - Unintended consequences of no default MTA - How best to fix


On 01/06/2014 07:37 AM, Chris Murphy wrote:

It's obviously a matter of opinion, not fact, as evidenced by the lack of 
universal agreement by fairly reasonable people. I think email is such amazing 
piles of steaming poo that my happiness is inversely proportional to the 
number/rate of emails I'm getting. It simply does not scale well. And like the 
phone, it too easily confuses importance and urgency. Setting up mail rules 
requires duplicative effort, for each user, even when they have very similar 
ideas on notification prioritization. It's ickysauce.


That you despise mail is no reason to remove the MTA when applications 
actually rely on an existing MTA. You can not generalize your way of 
doing things to the entire community. The mail mechanics is there for a 
reason, and has proven its validity for decades.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F20 Boot Delay

2014-01-06 Thread Lars E. Pettersson


On 01/06/2014 10:34 PM, David L. Crow wrote:

On 1/6/2014 1:37 PM, Frank Murphy wrote:

systemd-analyze blame


Seems to be something preventing this from working.


Just a shot out in the blue, have you tried 'sudo yum distro-sync' to 
make sure that all packages have been updated, and that no packages are 
out of sync?


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: rsyslogd pegged at 100% since FC19-FC20 upgrade

2014-01-11 Thread Lars E. Pettersson


On 01/07/2014 10:12 PM, Charlie Zender wrote:

rsyslogd has been pegged at 100% CPU since I upgraded my desktop via
network from FC19-FC20 last month. How to clean up this mess? System
seems completely up-to-date:


For me it finally went down to normal figures. I think I restarted it a 
couple of times also. Not sure what eventually made it slow down, but 
apparently it went through the whole journal, which took some time, 
(why this happened after the upgrade is a very good question though).


Not sure, but it can, in some way, be connected to the 
https://bugzilla.redhat.com/show_bug.cgi?id=1047719 bug about the 
journal being extremely slow.


What numbers do you get for:
time journalctl | grep xyz
journalctl --disk-usage

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Setting a static IP on Fedora 20

2014-01-11 Thread Lars E. Pettersson


On 01/11/2014 01:38 PM, John Aldrich wrote:

How do I assign a static IP on Fedora 20?


Turn off the NetworkManager stuff, install system-config-network, 
configure your network, issue 'systemctl start network.service', and 
'systemctl enable network.service'.


If memory serves me well...

Do not name your interfaces eth0, eth1, etc if you have several 
interfaces, that will create problems depending on when the different 
network interfaces are started, use names as wan, lan, etc. instead.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: f20 - Changing your default file browser

2014-01-11 Thread Lars E. Pettersson


On 01/09/2014 11:50 PM, Robert Moskowitz wrote:

Back in f17, Gnome had a panel where you specified such things as your
default email program, your default editor, and I believe your default
file browser.  I can't find a similar facility in f20.


It's not obvious... Go to Settings (click in the upper right corner, and 
then click on the icon with a wrench and a screw driver), chose 
'Details', there you will find 'Default Applications'


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: what just happened (time went backwards?)

2014-02-25 Thread Lars E. Pettersson


On 02/25/2014 07:58 PM, Dale Dellutri wrote:

It didn't.  Systemd is in control, and /var/log/messages is no longer
necessarily
written in order.  You need to use journalctl to read the log for F20.


The syslog daemon writes whatever systemd sends to it. On one of my 
systems systemd decided to send the whole systemd journal to the syslog 
daemon, by doing so starting to write log lines from last year in my 
/var/log/messages. Quite annoying... It also hogged 100% of the CPU.


But, when systemd behaves, /var/log/messages should be in order. And you 
do not need journalctl to read the log (as long as you have syslogd 
installed).


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: what just happened (time went backwards?)

2014-02-27 Thread Lars E. Pettersson


On 02/26/14 19:23, lee wrote:

What is the purpose of this log duplication?  When systemd has its own
logs, it doesn´t seem necessary to duplicate them by sending their
contents to syslogd.


One could also ask why systemd duplicates the logging formerly only done 
by syslogd.


For me looking through my ASCII-based text-logs created by syslogd is 
far faster than using journalctl. Things that takes over 25 minutes with 
journalctl, only takes 66 seconds grepping the syslogd logs. (see bug 
1047719, that no-one seems to care about)


ASCII-based logs can be read by anybody using any editor. To read the 
journal you need journalctl, or similar program, as the journal is 
binary and not readily readable.


Another reason is that there still exist programs/daemons/etc. that rely 
on the logs in /var/log.


If you do not like syslogd, well F20 does not ship it anymore...

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: what just happened (time went backwards?)

2014-02-28 Thread Lars E. Pettersson


On 02/28/2014 12:54 AM, Chris Murphy wrote:


On Feb 27, 2014, at 12:28 PM, Lars E. Pettersson l...@homer.se wrote:


On 02/26/14 19:23, lee wrote:

What is the purpose of this log duplication?  When systemd has its own
logs, it doesn´t seem necessary to duplicate them by sending their
contents to syslogd.


One could also ask why systemd duplicates the logging formerly only done by 
syslogd.


This has been answered many times already, it's an old argument.


That was not my point of argument.


For me looking through my ASCII-based text-logs created by syslogd is far 
faster than using journalctl. Things that takes over 25 minutes with 
journalctl, only takes 66 seconds grepping the syslogd logs. (see bug 1047719, 
that no-one seems to care about)


Why are the logs so large? Each log file I have is either 8MB, 16MB, or maximum 
24MB. So somehow yours are getting very large before they are turned over. Also 
do you normally search all logs for all time? Or are you searching in the most 
recent boot? You can use journalctl -b -1 to search the last boot, -2 the one 
before that. It can be done using --since with a date to encompass multiple 
boots yet not all boots. There is also -u to filter by unit. If you have 
journalctl do some filtering in advance then not so much stuff is dumped into 
grep to filter.


Why the journal is 4GB? Have no idea, perhaps you could enlighten me? 
The syslogd created text files are only using about 700MB of space for 
the same duration. The problem is not the size of the text files, the 
problem is that systemd/journalctl is extremely sluggish when the 
journal is big. If it takes 20-25 minutes to get the same information 
from journalctl, when it takes about 1 minute going through all syslogd 
created text-files for the same duration, then something is utterly 
wrong with how the journal works, and if it (the journal) is supposed to 
replace the syslogd generated text files, it has to be at least equally 
fast to be usable.


Also note that this sluggishness creates problem for the 'systemctl 
status' command, which is a really bad thing.


Using -b, --since, etc. is not the point, the point is the sluggishness 
shown when the journal is big.



ASCII-based logs can be read by anybody using any editor. To read the journal 
you need journalctl, or similar program, as the journal is binary and not 
readily readable.


It's fine to want plain logs but that is a subset of the amount of information 
the journal can only retain with binary including checksumming so the logs can 
be verified, and universal time/date stamping that causes journalctl to report 
the even in local time even if the server is not local, the list of things that 
can be done are unlimited. So the superset log is a necessity in any case and 
if the plain text rsyslog is meeting your needs then why would you bother with 
journalctl at all?


That is all fine and dandy, but does not change the fact that a text 
file can be read by anyone. The journal needs programs of some sort to 
be read.



Another reason is that there still exist programs/daemons/etc. that rely on the 
logs in /var/log.

If you do not like syslogd, well F20 does not ship it anymore…


I think the repo has both rsyslog and syslog-ng.


That does not change the fact that the F20 install has dameons etc. that 
actually relies on a present MTA and/or the syslog daemon.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Four Tweaks for Gnome 3

2011-06-02 Thread Lars E. Pettersson

On 06/02/2011 02:10 AM, Digimer wrote:
 With that in mind, I'm quickly coming to like Gnome 3. It has wrinkles,
 but it is also a 3.0 release. I think it has a lot of promise, and I
 think people will come to like it as they get used to it. :)

My biggest problem with Gnome 3 is that things that I could do by moving 
the mouse, and a single mouse click, now needs several moves and several 
mouse clicks, this severely disrupts my work flow. At the moment I have 
moved to Xfce (which I aesthetically does not like, but can be made to 
work the way I am used to), but I will check to see if new extensions 
etc. turns up that make Gnome 3 usable (for me).

Sadly the things mentioned in the links earlier in the thread does not 
solve my issues fully.

Lars
-- 
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Four Tweaks for Gnome 3

2011-06-02 Thread Lars E. Pettersson

On 06/02/2011 10:52 PM, Ron Yorston wrote:
 If you're quick you can be the first to download it!

Downloaded :-)  Will go to bed now though, but will take a look 
tomorrow. Seem to solve some issues I have been having though.

Lars
-- 
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: fedup f18-f19 going OK?

2013-07-02 Thread Lars E. Pettersson


On 07/02/2013 08:42 PM, Luan Minh Pham wrote:

Now how do I check if I run 18 or 19?



One way:
cat /etc/issue

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: fedup f18-f19 going OK?

2013-07-02 Thread Lars E. Pettersson


On 07/02/2013 09:22 PM, poma wrote:

One way:
cat /etc/issue


That's just one text file. :)


Yes, but:

$ rpm -qf /etc/issue
fedora-release-19-2.noarch

So the content gives quite a good clue :)

One could also chose Settings from the upper right menu in Gnome 
(whatever that one is called), and chose Details. On my computer it 
says Fedora 19.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: jar command missing in Fedora 19?

2013-07-05 Thread Lars E. Pettersson


On 07/05/2013 06:34 PM, Amadeus W.M. wrote:

rpm -qa | grep -i java
java-1.7.0-openjdk-1.7.0.25-2.3.10.3.fc19.x86_64
javapackages-tools-0.14.1-2.fc19.noarch
tzdata-java-2013c-1.fc19.noarch


Install
java-1.7.0-openjdk-devel-1.7.0.25-2.3.10.4.fc18.x86_64

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Do I need avahi?

2013-08-04 Thread Lars E. Pettersson


On 07/31/2013 05:15 AM, Marko Vojinovic wrote:

You are confusing the avahi library with the avahi daemon. The daemon
doesn't need to run or even be installed for things to work. The
library, however, is a dependency of a large number of packages, and is
needed by the majority of the system, like glibc is.

Of course, you can remove the daemon while keeping the library (the
daemon depends on the library, but not the other way around), so there
should be no problems removing the avahi service itself.


Will not work:

# rpm -qf /usr/sbin/avahi-daemon
avahi-0.6.31-11.fc19.x86_64

# yum erase avahi
...
Remove  1 Package (+310 Dependent packages)

Installed size: 1.6 G
Is this ok [y/N]:

This on a rather newly installed system. Installed as Fedora 18 in June, 
and then updated to 19 when that came along.



My guess is that Lee probably tried to do something like yum remove
avahi* which wanted to remove both the daemon and the library, and
then started complaining endlessly about the daemon. He never even
provided the yum output that he was complaining about.


From session above:

Removing:
 avahi x86_64 0.6.31-11.fc19 
installed 1.0 M

Removing for dependencies:
...
 avahi-autoipd x86_64 0.6.31-11.fc19 
installed  41 k
 avahi-glibx86_64 0.6.31-11.fc19 
installed  15 k
 avahi-gobject x86_64 0.6.31-11.fc19 
installed  48 k
 avahi-libsx86_64 0.6.31-11.fc19 
installed 121 k
 avahi-ui-gtk3 x86_64 0.6.31-11.fc19 
installed  53 k



I see no further point in discussing this thread. The avahi service is
not a dependency on anything serious and you can safely remove it if
you don't want to use it.


No, you can not remove it (the avahi-daemon package named avahi) with 
yum due to dependencies.


Perhaps /usr/sbin/avahi-daemon and associated files should be moved to 
an avahi-daemon package?


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Do I need avahi?

2013-08-04 Thread Lars E. Pettersson


On 08/04/2013 10:16 AM, Lars E. Pettersson wrote:

On 07/31/2013 05:15 AM, Marko Vojinovic wrote:

You are confusing the avahi library with the avahi daemon. The daemon

...

I see no further point in discussing this thread. The avahi service is
not a dependency on anything serious and you can safely remove it if
you don't want to use it.



No, you can not remove it (the avahi-daemon package named avahi) with
yum due to dependencies.


I have now tried it on two other computers, with the exact same result. 
So Marko, it is not PEBKAC. Try 'yum erase avahi' yourself.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Do I need avahi?

2013-08-04 Thread Lars E. Pettersson


On 08/04/2013 02:50 PM, Marko Vojinovic wrote:

If this yum output is reproducible on F19, then I suggest
that you file a bug against avahi (or maybe avahi-glib and avahi-libs)
and complain against unnecessary dependencies. And do emphasize
there that this is a regression from F18, which doesn't have that
problem.

I'd be interested to follow-up on that bugreport, so please post a link
to it here.


OK, I did a test installation of Fedora 18 and found that avahi-libs 
need avahi on Fedora 19, but not Fedora 18. So that dependency of avahi 
from avahi.libs seem to be the culprit. A Bugzilla report on this exist 
since February 20th.


I updated the bug, to hopefully get some action.

https://bugzilla.redhat.com/show_bug.cgi?id=913168

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Save everybody some surprises in Fedora 22!

2014-06-15 Thread Lars E. Pettersson


On 06/09/14 16:28, Patrick O'Callaghan wrote:

Do you have the bug reference? I'd rather find out before dnf leaves me
with a non-bootable system. The reason I'm harping on about it is that
in a thread on this list a few months back the developers didn't seem to
think it was a bug.


It has not been fixed. See bug 1049310. Ales wrote the following If 
there's enough CCs in this bug (40) I will consider the proper way to 
implement something that prevents 'dnf erase kernel' from removing the 
running kernel. So if you want that behaviour (the way yum does it), 
make a CC to that bug.


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Save everybody some surprises in Fedora 22!

2014-06-16 Thread Lars E. Pettersson


On 06/16/14 14:45, Jan Zelený wrote:

We originally didn't want to implement anything like this for three reasons:

a) in our opinion, dnf should not do the thinking for admins


It should have sensible defaults so that a user can not hose the system 
by accident.


What would the use case be to remove the running kernel? If no use case 
exist, then why have that option exposed to the user?



b) the real impact of this feature is questionable


Try 'dnf remove kernel' and see what happens. Then try to fix the problem.


c) we don't want dnf to contain ugly hacks from the beginning


I do not regard sensible defaults as a hack.


ad b) how many times have this feature actually saved you from erasing the
kernel? In 10+ years using Linux I have never managed to do this accidentally.


Well, with 'yum erase kernel' you can not accidentally remove the 
running kernel, so what is your point? :)



feel free to reopen the bug too, otherwise it might get off the radar.


How do I, as a normal user, re-open a bug? Can not see any way more than 
cloning it. Is that how it's supposed to be done? (Google gave no 
conclusive answer)


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: CPU fan running at full speed

2014-07-24 Thread Lars E. Pettersson


On 07/24/14 15:52, poma wrote:
...

drm/nouveau/therm: let the vbios decide on the automatic fan management
mode
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau/core/subdev/therm/fan.c?h=linux-3.15.yid=0e994d6

   This should fix automatic fan management on fermi cards who do not
have 0x46 entries in the thermal table.
   On my nve6, the blob sets the default linear range from 40°C to 100°C
but my nvcf's default values are 40°C to 85°C.
   Let's keep 85 as a default for everyone.


I really must say that I do not understand why this change was made. 
Obviously it breaks the fan management for some (me included). Did it 
solve it for others? And what is 0x46 entries?


This is my card (a Quadro 2000):

01:00.0 VGA compatible controller: NVIDIA Corporation GF106GL [Quadro 
2000] (rev a1) (prog-if 00 [VGA controller])

Subsystem: NVIDIA Corporation Device 084a
Flags: bus master, fast devsel, latency 0, IRQ 45
Memory at f400 (32-bit, non-prefetchable) [size=32M]
Memory at e000 (64-bit, prefetchable) [size=128M]
Memory at e800 (64-bit, prefetchable) [size=64M]
I/O ports at e000 [size=128]
Expansion ROM at f600 [disabled] [size=512K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Endpoint, MSI 00
Capabilities: [b4] Vendor Specific Information: Len=14 ?
Capabilities: [100] Virtual Channel
Capabilities: [128] Power Budgeting ?
Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 
?
Kernel driver in use: nouveau
Kernel modules: nouveau

NVC0 family (Fermi)
NVC3 (GF106)GeForce GT (440, 445M, 545, 555M, 630M, 635M), GTS
450, GTX 460M, Quadro 2000 (D), 2000M

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

BIOS boot partition, 4x3TB disks, and raid, problems with anaconda


Hi!

I tried to set up a system using four 3TB disks as a raid6. The disks 
are new, no old partitions laying around. I used a USB stick as install 
media (Fedora 20 x86_64 Gnome Live).


I chose manual partitioning to get everything as I wanted. When this was 
ready I got the error message that I also needed a BIOS boot partition 
(I gather that this due to being rather large disks). I tried to create 
one of those, but it seemed to only be created on one of the discs in 
the raid array, I wanted it created on all disks, just as the raid 
partitions. This to be able to boot from any of the disks in the array 
in case of a failure. As it is now, if the main disk dies, I can not 
start the system at all.


Actually I ended up having three BIOS boot partition on the first disk, 
being 2, 1, and 1 MB large. Which is quite annoying. But that's another 
problem...


Before submitting a bug report/RFE on this. Is there anyone out there 
that have done this, from anaconda? I.e. creating raid partitions and 
BIOS boot partitions on ALL disks? If so, how did you do it?


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: BIOS boot partition, 4x3TB disks, and raid, problems with anaconda


On 08/28/14 20:21, Bruno Wolff III wrote:

On Thu, Aug 28, 2014 at 11:10:54 -0700,
  Rick Stevens ri...@alldigital.com wrote:


I think you need to reserve some small space on all the drives (and
with 3TB drives you can afford to sacrifice a few MB), use the remainder
as your RAID, and let the system put the boot partition in that reserved
space on the primary drive (the one the BIOS sees as the boot drive).


I think using raid 1 (with the 1.0 header format) can work well for
that. There can still grub issues with having a boot just work, but at
least you have the stuff you need available.


Yes, that was my intention, raid1 for /boot and raid6 for / Accidentally 
I set /boot also to raid6 :)  But that can be fixed.


On my old system I use 1TB disks, with /boot as raid1, and grub 
boot-loader installed on all disks. On that one I can boot the system 
from any of disks. Which is quite handy.


The problem here seem to be that due to the disks being large (larger 
than 1TB) they are setup as GPT (GUID Partition Table), and they then 
also need a BIOS boot partition to work on non UEFI based systems (if I 
have understood it correctly).


So, to be able to boot from any of the disks, I need a BIOS boot 
partition on all disks, but anaconda seem to only install it on one of 
the disks (i.e. I want the exactly identical partition tables on all disks).


Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: 2nd IP address on an interface


On 08/28/14 22:16, Robert Moskowitz wrote:

# cat /etc/sysconfig/network-scripts/ifcfg-eth0:0
DEVICE=eth0:0
BOOTPROTO=none
ONBOOT=yes
TYPE=Ethernet
NAME=System eth0
MTU=1500
GATEWAY=208.83.67.161
IPADDR=208.83.67.164
NETMASK=255.255.255.240


I think you need to add
ONPARENT=yes
to make it start when its parent does.

That is at least the major difference I see comparing to my setup.

Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: 2nd IP address on an interface