f23: How to capture the lid close event and ...

[Dario Lesca]

... do some action, like execute a custom shell, independently from the
desktop environment use?

Many thanks for your suggestion.

-- 
Dario Lesca
(inviato dal mio Linux Fedora 23 Workstation)

-- 
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

[389-users] Re: upgrade to 389-ds-base-1.3.4 Q

[ghiureai]

Rich, still see bellow : and bellow only for ds no admin

_setup-ds-admin.pl -u -d_

==
This program will set up the 389 Directory and Administration Servers.

It is recommended that you have "root" privilege to set up the software.
Tips for using this program:
  - Press "Enter" to choose the default and go to the next screen
  - Type "Control-B" then "Enter" to go back to the previous screen
  - Type "Control-C" to cancel the setup program

Would you like to continue with set up? [yes]:

==
Your system has been scanned for potential problems, missing patches,
etc.  The following output is a report of the items found that need to
be addressed before running this software in a production
environment.

Would you like to continue? [no]: yes

==
Choose a setup type:

   1. Express
   Allows you to quickly set up the servers using the most
   common options and pre-defined defaults. Useful for quick
   evaluation of the products.

   2. Typical
   Allows you to specify common defaults and options.

   3. Custom
   Allows you to specify more advanced options. This is
   recommended for experienced server administrators only.

To accept the default shown in brackets, press the Enter key.




**
_>>setup-ds.pl -u_

==
This program will update the 389 Directory Server.

It is recommended that you have "root" privilege to perform the update.
Tips for using this  program:
  - Press "Enter" to choose the default and go to the next screen
  - Type "Control-B" or the word "back" then "Enter" to go back to the 
previous screen

  - Type "Control-C" to cancel the update

Would you like to continue with update? [yes]: yes

==

The update process can work in one of two modes:

  - Online: The changes are made to the running directory servers using 
LDAP.

The operations must be performed as an administrative user.
You must provide the name and password, for each instance
if there is more than one instance of directory server.
Some operations may require a directory server restart to take
effect.  The update script will notify you if you need to 
restart

the server.

  - Offline: The changes are made to the server configuration files.  The
 servers MUST FIRST BE SHUTDOWN BY YOU.  The script will not
 shutdown the servers for you.  You MUST shutdown the
 servers in order to use this mode.  A username and password
 are not required to use Offline mode.  If the servers are not
 shutdown, CHANGES WILL BE LOST.

To summarize:
  Online - servers remain running - you must provide admin name and 
password

   for each server - servers may need to be restarted
  Offline - servers must be shutdown - no username or password required




On 12/01/2015 01:23 PM, ghiureai wrote:

On 12/01/2015 11:42 AM, ghiureai wrote:

Rich, pls see the answers to your Q's (   the DS upgrade worked but 
the  DS Admin set up will not behave same way )
... 


setup-ds-admin.pl -u

this will not give the noption for upgrade like with (setup-ds.pl -u)
see the menu bellow
setup-ds-admin.pl -u

==
This program will set up the 389 Directory and Administration Servers.

It is recommended that you have "root" privilege to set up the software.
Tips for using this program:
  - Press "Enter" to choose the default and go to the next screen
  Would you like to continue with set up? [yes]:

==
Your system has been scanned for potential problems, missing patches,
etc.  The following output is a report of the items found that need to
be addressed before running this software in a production
environment.

Would you like to continue? [no]: yes

==
Choose a setup type:

   1. Express
   Allows you to quickly set up the servers using the most
   common options and pre-defined defaults. Useful for quick
   evaluation of the products.

2 
... 



What repo are you using? What platform is this? If you are using el6 

[389-users] Re: upgrade to 389-ds-base-1.3.4 Q

[Rich Megginson]

On 12/01/2015 03:07 PM, ghiureai wrote:




Rich, still see bellow : and bellow only for ds no admin

_setup-ds-admin.pl -u -d_

==
This program will set up the 389 Directory and Administration Servers.

It is recommended that you have "root" privilege to set up the software.
Tips for using this program:
  - Press "Enter" to choose the default and go to the next screen
  - Type "Control-B" then "Enter" to go back to the previous screen
  - Type "Control-C" to cancel the setup program

Would you like to continue with set up? [yes]:

==
Your system has been scanned for potential problems, missing patches,
etc.  The following output is a report of the items found that need to
be addressed before running this software in a production
environment.

Would you like to continue? [no]: yes

==
Choose a setup type:

   1. Express
   Allows you to quickly set up the servers using the most
   common options and pre-defined defaults. Useful for quick
   evaluation of the products.

   2. Typical
   Allows you to specify common defaults and options.

   3. Custom
   Allows you to specify more advanced options. This is
   recommended for experienced server administrators only.

To accept the default shown in brackets, press the Enter key.


I don't understand what is going on.  When you use setup-ds-admin.pl -u, 
You should see a prompt like this:


==
The update option will allow you to re-register your servers with the
configuration directory server and update the information about your
servers that the console and admin server uses.  You will need your
configuration directory server admin ID and password to continue.

Continue?
==

I have no idea what's wrong.






**
_>>setup-ds.pl -u_

==
This program will update the 389 Directory Server.

It is recommended that you have "root" privilege to perform the update.
Tips for using this  program:
  - Press "Enter" to choose the default and go to the next screen
  - Type "Control-B" or the word "back" then "Enter" to go back to the 
previous screen

  - Type "Control-C" to cancel the update

Would you like to continue with update? [yes]: yes

==

The update process can work in one of two modes:

  - Online: The changes are made to the running directory servers 
using LDAP.

The operations must be performed as an administrative user.
You must provide the name and password, for each instance
if there is more than one instance of directory server.
Some operations may require a directory server restart to take
effect.  The update script will notify you if you need to 
restart

the server.

  - Offline: The changes are made to the server configuration files.  The
 servers MUST FIRST BE SHUTDOWN BY YOU.  The script will not
 shutdown the servers for you.  You MUST shutdown the
 servers in order to use this mode.  A username and password
 are not required to use Offline mode.  If the servers are not
 shutdown, CHANGES WILL BE LOST.

To summarize:
  Online - servers remain running - you must provide admin name and 
password

   for each server - servers may need to be restarted
  Offline - servers must be shutdown - no username or password required




On 12/01/2015 01:23 PM, ghiureai wrote:

On 12/01/2015 11:42 AM, ghiureai wrote:

Rich, pls see the answers to your Q's (   the DS upgrade worked but 
the  DS Admin set up will not behave same way )
... 


setup-ds-admin.pl -u

this will not give the noption for upgrade like with (setup-ds.pl -u)
see the menu bellow
setup-ds-admin.pl -u

==
This program will set up the 389 Directory and Administration Servers.

It is recommended that you have "root" privilege to set up the software.
Tips for using this program:
  - Press "Enter" to choose the default and go to the next screen
  Would you like to continue with set up? [yes]:

==
Your system has been scanned for potential problems, missing patches,
etc.  The following output is a report of the items found that need to
be addressed before running this 

Re: encrypting /home partition post-install

[Chris Adams]

Once upon a time, Patrick O'Callaghan  said:
> Because I know what physical disks I have in my machine and I want to
> relate that to what I see in the output of df. I might even want to
> move a device to another machine and be able to mount the right
> partitions in the right places. With "normal" (i.e. non-LVM)
> partitioning it's fairly easy to do this. With LVM it's definitely not.

I find quite the opposite: without LVM, I have to know that the drive I
just moved from computer to computer changed from sdb to sdc, and edit
fstab and such manually.  With LVM, I still get /dev/vg_foo/lv_bar, and
don't care what raw device the underlying partition is, how it is
connected, etc. (very useful for example when taking an internal drive
from one computer and connecting it via an external adapter of some type
on another).

-- 
Chris Adams 
-- 
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: encrypting /home partition post-install

[Patrick O'Callaghan]

On Tue, 2015-12-01 at 09:29 -0800, Gordon Messmer wrote:
> > Not so. If you have LVM you have to*know*  you have LVM, otherwise
> your
> > disk partition names won't make any sense. Just doing a "df"
> requires you to know this and understand what it means.
> 
> Why is understanding the device names, as opposed to understanding
> what filesystems are, critical to understanding the output of "df"? 

Because I know what physical disks I have in my machine and I want to
relate that to what I see in the output of df. I might even want to
move a device to another machine and be able to mount the right
partitions in the right places. With "normal" (i.e. non-LVM)
partitioning it's fairly easy to do this. With LVM it's definitely not.

poc
-- 
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: submitted RPMs and awaiting action?

[Terry Polzin]

It's time to take this discussion off-line

On Tue, Dec 1, 2015 at 4:49 PM, Ranjan Maitra  wrote:

> Hi,
>
> >
> > To put it bluntly -- and the Fedora Project has done a good job at
> teaching
> > people to be more blunt -- if you're so reluctant with regard to many
> simple
> > things/tasks, one alternative is to sit and wait and offer your packages
> > somewhere else. Such as Fedora Copr. Or hope that Fedora leadership will
> > move away from current procedures more quickly -- if that still is what
> > they would like to do. Then, however, much will be different, and it is
> > hard to say whether "the distribution" will still be popular at all.
>
> OK, thank you for being "blunt" but my general point is that putting in a
> package for review is needlessly bureaucratic and does no justice to the
> volunteers on either side. For example, creating the spec file (with the
> evolution that seems to be happening all the time) could better be
> automated by some script on a website. At the very least, have it suggest a
> skeleton. Doing so will also leave out extended review discussions. Once a
> package is submitted, let it go through rpmlint, etc. (and fix rpmlint to
> not warn on nonsensical spelling errors) doing the automated checks and
> speed up the process. Do you feel that it is productive for an expert to
> inform a submitter of basic errors which could have been caught by some
> auto-checking mechanism. This would reduce their loads. (R, which btw, is a
> far more used software, does something similar, though of course, a
> distribution running an entire computer can not be equated with one
> software package.)
>
> > It cannot be repeated often enough: The package review queue is publicly
> > visible. If a package in the queue(s) is not evaluated by anyone at all
> > in the community, that means that there is no interest in the package
> > or no interest in maintaining the package with the package collection.
>
> So do you think that packages should be included only if they are in
> demand by multitudes? It sort of defeats the purpose of Linux. Ideally, if
> only two people have need for a package, and if the first person is the
> packager (say), then how likely is it for the second user to actually be a
> member of BZ and the review set, rather than go off to some other
> distribution (AUR, say) where things are easier to come by? (Of course,
> Arch is notoriously complicated to install but Antergos does get around the
> burden quite a bit.)
>
> > For quite some people it is less effort to run with selfmade packages
> > in a private local repo than becoming a volunteer package maintainer
> > with interest in team work (for example).
>
> Agreed! But do you want that to happen? You will then lose the ability to
> have more software packages then. Better to have a stringent but automated
> process for evaluation: if the submitter passes all the steps, let his
> package in or at least put it on probation. Or put it to the top of the
> list. Otherwise, if he has non-standard requirements, send it to BZ.
>
>
> > A good first step would have been to discuss the unclear things then.
>
> Agreed.
>
> Thanks again for responding and the discussion!
>
> Best wishes,
> Ranjan
>
> > --
> > 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
>
>
> --
> Important Notice: This mailbox is ignored: e-mails are set to be deleted
> on receipt. Please respond to the mailing list if appropriate. For those
> needing to send personal or professional e-mail, please use appropriate
> addresses.
>
> 
> Receive Notifications of Incoming Messages
> Easily monitor multiple email accounts & access them with a click.
> Visit http://www.inbox.com/notifier and check it out!
>
>
> --
> 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
>
-- 
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

[389-users] Re: upgrade to 389-ds-base-1.3.4 Q

[ghiureai]

On 12/01/2015 11:42 AM, ghiureai wrote:

Rich, pls see the answers to your Q's (   the DS upgrade worked but the  
DS Admin set up will not behave same way )
... 


setup-ds-admin.pl -u

this will not give the noption for upgrade like with (setup-ds.pl -u)
see the menu bellow
setup-ds-admin.pl -u

==
This program will set up the 389 Directory and Administration Servers.

It is recommended that you have "root" privilege to set up the software.
Tips for using this program:
  - Press "Enter" to choose the default and go to the next screen
  Would you like to continue with set up? [yes]:

==
Your system has been scanned for potential problems, missing patches,
etc.  The following output is a report of the items found that need to
be addressed before running this software in a production
environment.

Would you like to continue? [no]: yes

==
Choose a setup type:

   1. Express
   Allows you to quickly set up the servers using the most
   common options and pre-defined defaults. Useful for quick
   evaluation of the products.

2 
... 



What repo are you using? What platform is this? If you are using el6 or 
el7 you must use epel6 or epel7 to get the admin/console packages.
... 




Linux  2.6.32-431.el6.x86_64 #1 SMP Thu Nov 21 13:35:52 CST 2013 x86_64 
x86_64 x86_64 GNU/Linux

epel6
rpm -qa | grep 389-*
389-ds-console-1.2.12-000.x86_64
389-ds-base-1.3.4.4-000.x86_64
389-admin-1.1.42-000.x86_64
389-admin-console-1.1.10-000.x86_64
389-adminutil-1.1.22-000.x86_64
389-console-1.1.9-000.x86_64



On 12/01/2015 10:42 AM, ghiureai wrote:


Thank you Rich for reply one more related issues I see :

When need to run the  ds admin update  I do not see the  options for
update,  seems goes back and asks all the Q's  as a new fresh
installation ( ??)
What we are missing from this upgrade installation here is what is been
installed
 grep 389-*
389-ds-console-1.2.12-000.x86_64
389-admin-1.1.42-000.x86_64
389-ds-base-1.3.4.4-000.x86_64
389-console-1.1.9-000.x86_64
389-admin-console-1.1.10-000.x86_64
389-adminutil-1.1.22-000.x86_64





On 12/01/2015 09:07 AM, ghiureai wrote:

Hi List,
we are tying to upgrade to 389-ds 1.3.4 from 1.2.2 , after rpm installed
and update the server ,  when restarting the DS geting the following in
DS errorlog, there is no such  "entryallowWeakCipher" in cfg file , what
should we dissable see entries for this cn

SSL alert: Cipher rsa_rc4_128_md5 is weak. It is enabled since
allowWeakCipher is "on" (default setting for the backward
compatibility). We strongly recommend to set it to "off".  Please
replace the value of allowWeakCipher with "off" in the encryption config
entry cn=encryption,cn=config and restart the server.

dn: cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionConfig
cn: encryption
nsSSLSessionTimeout: 0
nsSSLClientAuth: allowed
nsSSL2: off

nsSSL3: off ->>> This was on but turn to "off"

creatorsName: cn=server,cn=plugins,cn=config
modifiersName:
uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoo
t
createTimestamp: 
modifyTimestamp:
nsSSL3Ciphers:
-rsa_null_md5,-rsa_null_sha,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+r

sa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha

,+fortezza,+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_
56_sha,+tls_rsa_aes_128_sha,+tls_rsa_aes_256_sha


xxx
xxx

Thank you for your time
Isabella



--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: upgrade to 389-ds-base-1.3.4 Q

[Rich Megginson]

On 12/01/2015 11:42 AM, ghiureai wrote:



Thank you Rich for reply one more related issues I see :

When need to run the  ds admin update  I do not see the  options for 
update,  seems goes back and asks all the Q's  as a new fresh 
installation ( ??)


setup-ds-admin.pl -u

What we are missing from this upgrade installation here is what is 
been installed

   grep 389-*
389-ds-console-1.2.12-000.x86_64
389-admin-1.1.42-000.x86_64
389-ds-base-1.3.4.4-000.x86_64
389-console-1.1.9-000.x86_64
389-admin-console-1.1.10-000.x86_64
389-adminutil-1.1.22-000.x86_64


What repo are you using?  What platform is this?  If you are using el6 
or el7 you must use epel6 or epel7 to get the admin/console packages.








On 12/01/2015 09:07 AM, ghiureai wrote:

Hi List,
we are tying to upgrade to 389-ds 1.3.4 from 1.2.2 , after rpm installed
and update the server ,  when restarting the DS geting the following in
DS errorlog, there is no such  "entryallowWeakCipher" in cfg file , what
should we dissable see entries for this cn

   SSL alert: Cipher rsa_rc4_128_md5 is weak. It is enabled since
allowWeakCipher is "on" (default setting for the backward
compatibility). We strongly recommend to set it to "off". Please
replace the value of allowWeakCipher with "off" in the encryption config
entry cn=encryption,cn=config and restart the server.

dn: cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionConfig
cn: encryption
nsSSLSessionTimeout: 0
nsSSLClientAuth: allowed
nsSSL2: off

nsSSL3: off ->>> This was on but turn to "off"

creatorsName: cn=server,cn=plugins,cn=config
modifiersName:
uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoo
   t
createTimestamp: 
modifyTimestamp:
nsSSL3Ciphers:
-rsa_null_md5,-rsa_null_sha,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+r
sa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha
,+fortezza,+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_
   56_sha,+tls_rsa_aes_128_sha,+tls_rsa_aes_256_sha


xxx
xxx

Thank you for your time
Isabella


--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org 


--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: upgrade to 389-ds-base-1.3.4 Q

[Rich Megginson]

On 12/01/2015 02:23 PM, ghiureai wrote:

On 12/01/2015 11:42 AM, ghiureai wrote:

Rich, pls see the answers to your Q's (   the DS upgrade worked but 
the  DS Admin set up will not behave same way )
... 


setup-ds-admin.pl -u


Ok, not sure what's going on.  Try running like this:

setup-ds-admin.pl -u -d



this will not give the noption for upgrade like with (setup-ds.pl -u)
see the menu bellow
setup-ds-admin.pl -u

==
This program will set up the 389 Directory and Administration Servers.

It is recommended that you have "root" privilege to set up the software.
Tips for using this program:
  - Press "Enter" to choose the default and go to the next screen
  Would you like to continue with set up? [yes]:

==
Your system has been scanned for potential problems, missing patches,
etc.  The following output is a report of the items found that need to
be addressed before running this software in a production
environment.

Would you like to continue? [no]: yes

==
Choose a setup type:

   1. Express
   Allows you to quickly set up the servers using the most
   common options and pre-defined defaults. Useful for quick
   evaluation of the products.

2 
... 



What repo are you using? What platform is this? If you are using el6 
or el7 you must use epel6 or epel7 to get the admin/console packages.
... 




Linux  2.6.32-431.el6.x86_64 #1 SMP Thu Nov 21 13:35:52 CST 2013 
x86_64 x86_64 x86_64 GNU/Linux

epel6
rpm -qa | grep 389-*
389-ds-console-1.2.12-000.x86_64
389-ds-base-1.3.4.4-000.x86_64
389-admin-1.1.42-000.x86_64
389-admin-console-1.1.10-000.x86_64
389-adminutil-1.1.22-000.x86_64
389-console-1.1.9-000.x86_64



On 12/01/2015 10:42 AM, ghiureai wrote:

Thank you Rich for reply one more related issues I see :

When need to run the  ds admin update  I do not see the  options for
update,  seems goes back and asks all the Q's  as a new fresh
installation ( ??)
What we are missing from this upgrade installation here is what is been
installed
 grep 389-*
389-ds-console-1.2.12-000.x86_64
389-admin-1.1.42-000.x86_64
389-ds-base-1.3.4.4-000.x86_64
389-console-1.1.9-000.x86_64
389-admin-console-1.1.10-000.x86_64
389-adminutil-1.1.22-000.x86_64





On 12/01/2015 09:07 AM, ghiureai wrote:

Hi List,
we are tying to upgrade to 389-ds 1.3.4 from 1.2.2 , after rpm installed
and update the server ,  when restarting the DS geting the following in
DS errorlog, there is no such  "entryallowWeakCipher" in cfg file , what
should we dissable see entries for this cn

SSL alert: Cipher rsa_rc4_128_md5 is weak. It is enabled since
allowWeakCipher is "on" (default setting for the backward
compatibility). We strongly recommend to set it to "off".  Please
replace the value of allowWeakCipher with "off" in the encryption config
entry cn=encryption,cn=config and restart the server.

dn: cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionConfig
cn: encryption
nsSSLSessionTimeout: 0
nsSSLClientAuth: allowed
nsSSL2: off

nsSSL3: off ->>> This was on but turn to "off"

creatorsName: cn=server,cn=plugins,cn=config
modifiersName:
uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoo
t
createTimestamp: 
modifyTimestamp:
nsSSL3Ciphers:
-rsa_null_md5,-rsa_null_sha,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+r

sa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha

,+fortezza,+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_
56_sha,+tls_rsa_aes_128_sha,+tls_rsa_aes_256_sha


xxx
xxx

Thank you for your time
Isabella





--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

Re: submitted RPMs and awaiting action?

[Ranjan Maitra]

Hi,

> 
> To put it bluntly -- and the Fedora Project has done a good job at teaching
> people to be more blunt -- if you're so reluctant with regard to many simple
> things/tasks, one alternative is to sit and wait and offer your packages
> somewhere else. Such as Fedora Copr. Or hope that Fedora leadership will
> move away from current procedures more quickly -- if that still is what
> they would like to do. Then, however, much will be different, and it is
> hard to say whether "the distribution" will still be popular at all.

OK, thank you for being "blunt" but my general point is that putting in a 
package for review is needlessly bureaucratic and does no justice to the 
volunteers on either side. For example, creating the spec file (with the 
evolution that seems to be happening all the time) could better be automated by 
some script on a website. At the very least, have it suggest a skeleton. Doing 
so will also leave out extended review discussions. Once a package is 
submitted, let it go through rpmlint, etc. (and fix rpmlint to not warn on 
nonsensical spelling errors) doing the automated checks and speed up the 
process. Do you feel that it is productive for an expert to inform a submitter 
of basic errors which could have been caught by some auto-checking mechanism. 
This would reduce their loads. (R, which btw, is a far more used software, does 
something similar, though of course, a distribution running an entire computer 
can not be equated with one software package.)
 
> It cannot be repeated often enough: The package review queue is publicly
> visible. If a package in the queue(s) is not evaluated by anyone at all
> in the community, that means that there is no interest in the package
> or no interest in maintaining the package with the package collection.

So do you think that packages should be included only if they are in demand by 
multitudes? It sort of defeats the purpose of Linux. Ideally, if only two 
people have need for a package, and if the first person is the packager (say), 
then how likely is it for the second user to actually be a member of BZ and the 
review set, rather than go off to some other distribution (AUR, say) where 
things are easier to come by? (Of course, Arch is notoriously complicated to 
install but Antergos does get around the burden quite a bit.) 

> For quite some people it is less effort to run with selfmade packages
> in a private local repo than becoming a volunteer package maintainer
> with interest in team work (for example).

Agreed! But do you want that to happen? You will then lose the ability to have 
more software packages then. Better to have a stringent but automated process 
for evaluation: if the submitter passes all the steps, let his package in or at 
least put it on probation. Or put it to the top of the list. Otherwise, if he 
has non-standard requirements, send it to BZ. 


> A good first step would have been to discuss the unclear things then.

Agreed.

Thanks again for responding and the discussion!

Best wishes,
Ranjan

> -- 
> 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


-- 
Important Notice: This mailbox is ignored: e-mails are set to be deleted on 
receipt. Please respond to the mailing list if appropriate. For those needing 
to send personal or professional e-mail, please use appropriate addresses.


Receive Notifications of Incoming Messages
Easily monitor multiple email accounts & access them with a click.
Visit http://www.inbox.com/notifier and check it out!


-- 
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: submitted RPMs and awaiting action?

[Michael Schwendt]

On Tue, 1 Dec 2015 15:49:20 -0600, Ranjan Maitra wrote:

> OK, thank you for being "blunt" but my general point is that putting in a 
> package for review is needlessly bureaucratic and does no justice to the 
> volunteers on either side.
>

If at all, the bureaucracy that could be removed is the review process for
packages from existing members of the packager group, who have demonstrated
before that they know their stuff.

There are some, who could be highly productive and could pipe out a
higher number of packages (e.g. needed dependencies), if they didn't need
to wait for a second pair of eyes to check even trivial packages.

Unfortunately, the review queue (including the needsponsor queue) contains
too many examples of people, who just want to dump a package into the
package collection without real interest in RPM packaging and maintenance of
the package. That isn't anything like a basis for "a distribution" of
packages. There must be a little bit of effort with regard to building
packages in a sane way as well as trying to respond to feedback from the
package users.

> For example, creating the spec file (with the evolution that seems to be
> happening all the time) could better be automated by some script on a
> website.

"Could, could, could". That's always the same cheap talk. Over the years
there have been various tools to automate RPM packaging *including*
determining BuildRequires and explicit Requires. Where is the tool that's
sufficiently complete and safe to use? It's still much easier for human
packagers to do it right and use custom tools to automate some tasks.

> At the very least, have it suggest a skeleton.

A skeleton for what?
Do you realize how much packages can differ? For example, packages for
Java stuff vs. packages for Perl or Python?

There's the template generate "rpmdev-newspec" in the rpmdevtools
package. It creates a spec file for building and packaging a typical
Autotools based program.

> Doing so will also leave out extended review discussions. Once a package
> is submitted, let it go through rpmlint, etc. (and fix rpmlint to not
> warn on nonsensical spelling errors)

It's *so* simple to ignore those warnings (where rpmlint fails because
of poor dictionaries or related issues). Why do you continue to blame
rpmlint for some of its false positives?

> doing the automated checks and speed up the process.

Have you run the fedora-review tool on your packages and/or bugzilla
review tickets yet?

> Do you feel that it is productive for an expert to inform a submitter
> of basic errors which could have been caught by some auto-checking
> mechanism.

It's "necessary evil" as long as (1) the package submitters care a lot less
about their packages than the reviewers, and (2) there is no tool that
can perform fully automated reviews. Some package submitters have the
bad habit of disagreeing with tools, either ignoring findings, claiming
that the tool is mistaken or coming up with strange rationales if a
reviewers asks.

> This would reduce their loads.

There is much higher load for the submitters, provided that they really
want to maintain the package and not only dump it into a repository.

Anyone, who thinks that the review process is too high a hurdle, has never
practised package maintainance before. Not with personal packages in some
private repo, and not with a public personal repo either. Certainly not
for a period of let's say a year or so. Or multiple years in RHEL/EPEL-style.

Of course, in a personal repo you could create packages in a way that
would not only be poorly or wrongly packaged but even "forbidden" at
Fedora.

> So do you think that packages should be included only if they are in
> demand by multitudes?

A single reviewer is needed. A single person with interest in the package
to build the smallest possible team of two. Either that or "review swapping",
which has been advertized/suggested often enough.

Yes, it is a major disappointment, if there is nobody else to even post
runtime test reports for a new package. And if potential users of the
package -- members of the distribution's community (!) -- prefer compiling
from source tarball instead without contributing anything.

> It sort of defeats the purpose of Linux.

Please elaborate. What do you have in mind here?

> Ideally, if only two people have need for a package, and if the first
> person is the packager (say), then how likely is it for the second user
> to actually be a member of BZ and the review set, rather than go off to
> some other distribution (AUR, say) where things are easier to come by?

Pardon? Do you intend to play the "attempted blackmail" card here? That's
quite common for so-called "distro-hoppers", who would switch back and
forth between distributions for every pet peeve they come up with. ;-)

If there's a distribution doing also everything else better *and* not only
offering that certain package that's oh-so-mission-critical for somebody,
hey, great! Let's hope it somehow will lead 

Re: It's 2015, and OOM handling still sucks

[Ian Malone]

On 1 December 2015 at 18:47, Neal Becker  wrote:
> Ian Malone wrote:
>
>> On 1 December 2015 at 15:19, Neal Becker  wrote:
>>> I have a pretty nice workstation, with 8 cores and 32G RAM.
>>>
>>> A stupid little python program just killed it by consuming all the
>>> memory, driving it into swapping hell.
>>>
>>> I couldn't even ssh into it - I started up ssh and went for coffee.  On
>>> return I still didn't have a prompt.  Had to power cycle it.
>>>

>> Maybe one for the devel list where they can do something about it. I
>> haven't actually checked what the current Fedora policies are, since
>> at work I use RHEL. I'd have thought the oom killer would get this.
>> Really taking out all the memory with no swap available seems more
>> likely to kill a system, possibly memory use can expand too fast, but
>> on systems with some swap I've rarely seen things get to the point you
>> can't get a virtual terminal up.

> cat /proc/meminfo


Well, first time for everything. Can you share what the program was?
There are examples on stackoverflow which intentionally do this kind
of thing, but doing it without meaning to is impressive. For my own
interest, is your swap on SSD?

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: encrypting /home partition post-install

[Joe Zeff]

On 12/01/2015 01:31 PM, Chris Adams wrote:

I find quite the opposite: without LVM, I have to know that the drive I
just moved from computer to computer changed from sdb to sdc, and edit
fstab and such manually.


This is why you mount them either by UUID or Label.
--
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: submitted RPMs and awaiting action?

[Michael Schwendt]

On Tue, 1 Dec 2015 16:56:40 -0500, Terry Polzin wrote:

> It's time to take this discussion off-line

That's a strange point of view.

For a user trying to sign up as Fedora packager is is okay to use this
list for a discussion.
-- 
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: encrypting /home partition post-install

[Patrick O'Callaghan]

On Tue, 2015-12-01 at 15:31 -0600, Chris Adams wrote:
> Once upon a time, Patrick O'Callaghan  said:
> > Because I know what physical disks I have in my machine and I want
> > to
> > relate that to what I see in the output of df. I might even want to
> > move a device to another machine and be able to mount the right
> > partitions in the right places. With "normal" (i.e. non-LVM)
> > partitioning it's fairly easy to do this. With LVM it's definitely
> > not.
> 
> I find quite the opposite: without LVM, I have to know that the drive
> I just moved from computer to computer changed from sdb to sdc, and
> edit fstab and such manually.

Maybe so, but it's still easy to do.

> With LVM, I still get /dev/vg_foo/lv_bar, and
> don't care what raw device the underlying partition is, how it is
> connected, etc. (very useful for example when taking an internal
> drive from one computer and connecting it via an external adapter of
> some type on another).

Which is fine if a) the second machine also runs LVM (what if it's on
an Ubuntu machine without LVM, rather than Fedora?) and b) the two use
the same LVM logical layout.

I guess my point is that the average Linux admin is going to have a
working knowledge of disk partitioning, whereas LVM is an *additional*
layer of expertise that may pay dividends in certain use cases, but for
most people is just irrelevant.

Anyway, we're getting way off the original topic of this thread. I
didn't really want to start a whole discussion (all of which has been
said before more than once).

poc
-- 
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: encrypting /home partition post-install

[Chris Adams]

Once upon a time, Patrick O'Callaghan  said:
> On Tue, 2015-12-01 at 15:31 -0600, Chris Adams wrote:
> > With LVM, I still get /dev/vg_foo/lv_bar, and
> > don't care what raw device the underlying partition is, how it is
> > connected, etc. (very useful for example when taking an internal
> > drive from one computer and connecting it via an external adapter of
> > some type on another).
> 
> Which is fine if a) the second machine also runs LVM (what if it's on
> an Ubuntu machine without LVM, rather than Fedora?) and b) the two use
> the same LVM logical layout.

For (a), the only Ubuntu system I have access to also has LVM; do they
not even install the lvm tools?

For (b), I have no idea what you mean by "same LVM logical layout".  The
PV size, VG and LV names, etc. are all part of a particular device.
They don't have to match in any way a separate device (on the same or on
a different computer).

-- 
Chris Adams 
-- 
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: encrypting /home partition post-install

[Joe Zeff]

On 12/01/2015 05:02 PM, Chris Adams wrote:

In the context of moving drives from computer to computer, I doubt
you're going to type a UUID in by hand.  Label works if you remember to
set one.


You get the UUID before moving the drive, and put it in a text file on a 
flash drive.  Then, when you edit fstab, you copy/paste the UUID into 
the file and Bob's your uncle.  It's not exactly rocket surgery, it just 
takes a moment to think ahead.

--
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: encrypting /home partition post-install

[Chris Adams]

Once upon a time, Joe Zeff  said:
> On 12/01/2015 01:31 PM, Chris Adams wrote:
> >I find quite the opposite: without LVM, I have to know that the drive I
> >just moved from computer to computer changed from sdb to sdc, and edit
> >fstab and such manually.
> 
> This is why you mount them either by UUID or Label.

In the context of moving drives from computer to computer, I doubt
you're going to type a UUID in by hand.  Label works if you remember to
set one.
-- 
Chris Adams 
-- 
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: submitted RPMs and awaiting action?

[Rick Stevens]

On 12/01/2015 03:13 PM, Michael Schwendt wrote:

On Tue, 1 Dec 2015 16:56:40 -0500, Terry Polzin wrote:


It's time to take this discussion off-line


That's a strange point of view.

For a user trying to sign up as Fedora packager is is okay to use this
list for a discussion.


I don't agree that this one is appropriate. This is users list, and
really is intended for users. For packagers, I'd suggest using the
developer list since packaging is more of a development job and there's
lots of talk about "upstream" packages there.

Maybe we need a new "packag...@lists.fedoraproject.org" for this sort of
thing.
--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
-Polygon: A dead parrot (With apologies to John Cleese)  -
--
--
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

[389-users] upgrade to 389-ds-base-1.3.4 Q

[ghiureai]

Hi List,
we are tying to upgrade to 389-ds 1.3.4 from 1.2.2 , after rpm installed 
and update the server ,  when restarting the DS geting the following in 
DS errorlog, there is no such  "entryallowWeakCipher" in cfg file , what 
should we dissable see entries for this cn


 SSL alert: Cipher rsa_rc4_128_md5 is weak. It is enabled since 
allowWeakCipher is "on" (default setting for the backward 
compatibility). We strongly recommend to set it to "off".  Please 
replace the value of allowWeakCipher with "off" in the encryption config 
entry cn=encryption,cn=config and restart the server.


dn: cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionConfig
cn: encryption
nsSSLSessionTimeout: 0
nsSSLClientAuth: allowed
nsSSL2: off

nsSSL3: off ->>> This was on but turn to "off"

creatorsName: cn=server,cn=plugins,cn=config
modifiersName: 
uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoo

 t
createTimestamp: 
modifyTimestamp:
nsSSL3Ciphers: 
-rsa_null_md5,-rsa_null_sha,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+r

 sa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha
 ,+fortezza,+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_
 56_sha,+tls_rsa_aes_128_sha,+tls_rsa_aes_256_sha


xxx
xxx

Thank you for your time
Isabella
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

Re: encrypting /home partition post-install

[Gordon Messmer]

On 12/01/2015 03:37 AM, Patrick O'Callaghan wrote:

Not so. If you have LVM you have to*know*  you have LVM, otherwise your
disk partition names won't make any sense. Just doing a "df" requires
you to know this and understand what it means.


Why is understanding the device names, as opposed to understanding what 
filesystems are, critical to understanding the output of "df"? 
Addressing the issue of filesystem use typically involves searching and 
summing file sizes (du).  The first step to addressing filesystem use 
issues is probably archiving or deleting unnecessary data, which isn't 
affected by LVM.  Beyond that, users might choose to address such an 
issue by re-sizing the filesystem, which is possible with LVM but 
generally difficult or impossible without it. Or they might choose to 
reinstall with different filesystem allocations and restore data from 
backup, which also isn't affected by LVM.


I don't see your case, frankly.  I can't find any process here that LVM 
complicates.

--
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: (COMPLETED) Changing systems

[Matthew Miller]

On Fri, Nov 27, 2015 at 01:02:27PM -0600, Mike Chambers wrote:
> Welp, it was as simple as everyone said it would be.
> I took out the 2 drives, put them in the other box.  Then I had to
> modify the BIOS to reorder the boot order of the drives.  Then last
> thing was modifying my router to make sure the MAC address was changed
> and everything else seems to work.

Note that if the hardware is very different (different RAID, for
example), you _might_ need to boot in rescue mode and recreate the
initrd. That's because of
https://fedoraproject.org/wiki/Features/DracutHostOnly

(The benefit is faster boot time and faster kernel updates.)

-- 
Matthew Miller

Fedora Project Leader
-- 
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: encrypting /home partition post-install

[Gordon Messmer]

On 12/01/2015 06:43 AM, Roberto Ragusa wrote:

... should note that you'll have to shrink at least one of your volumes, 
though.  The encrypted PV that you create will be slightly smaller than it was, 
before encryption.  As a result, there won't be enough extents to move all of 
the volumes off and then back.

The PV is used in multiple of the segment size, so, depending on rounding 
errors you may
have some free blocks.


Sounds right.  "pvdisplay" will print information about unusable space 
in the "PV Size" line.  As long as that's larger than the LUKS header 
(2MiB, I believe) you should be able to do a live migration to an 
encrypted PV using a second disk.


Interesting.
--
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: encrypting /home partition post-install

[Gordon Messmer]

On 12/01/2015 02:57 AM, Tim wrote:

Do we have file system recovery tools for it, yet?  (Assuming that a
problem might occur with LVM, itself, rather than an EXT3 filesystem
within it.)


pvck and vgck.  I believe the answer is "yes".  vgck is present in tag 
v1_00_03, so it's at least 12 years old.  pvck looks like it was added 
in 2007.

--
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: encrypting /home partition post-install

[Roberto Ragusa]

On 12/01/2015 06:29 PM, Gordon Messmer wrote:
> On 12/01/2015 03:37 AM, Patrick O'Callaghan wrote:
>> Not so. If you have LVM you have to*know*  you have LVM, otherwise your
>> disk partition names won't make any sense. Just doing a "df" requires
>> you to know this and understand what it means.
> 
> Why is understanding the device names, as opposed to understanding what 
> filesystems are, critical to understanding the output of "df"? Addressing the 
> issue of filesystem use typically involves searching and summing file sizes 
> (du).  The first step to addressing filesystem use issues is probably 
> archiving or deleting unnecessary data, which isn't affected by LVM.  Beyond 
> that, users might choose to address such an issue by re-sizing the 
> filesystem, which is possible with LVM but generally difficult or impossible 
> without it. Or they might choose to reinstall with different filesystem 
> allocations and restore data from backup, which also isn't affected by LVM.
> 
> I don't see your case, frankly.  I can't find any process here that LVM 
> complicates.

lsblk is magic, when you have RAID, encryption, LVM, ...

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
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: encrypting /home partition post-install

[Gordon Messmer]

On 11/30/2015 11:11 PM, Joe Zeff wrote:
It's one more layer of abstraction to confuse newer users when things 
go wrong. 


In the context of a conversation where LVM provides a means of 
addressing the OP's requirement (encrypting a system after-the-fact), 
and where I've outlined numerous concrete examples of LVM features that 
I think are useful on desktop systems (backups, SSD acceleration, and 
virtualization), do you see how "things might go wrong" isn't very 
convincing?  It's kind of vague and, honestly, applies to every aspect 
of computing.  Yes, things can go wrong. Software contains bugs.  
Simplicity is good.  But LVM is less complex than the vast majority of 
system components, and using a similar configuration on desktops and 
servers is, from the vendor's perspective, less complexity than 
different layouts.

--
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: submitted RPMs and awaiting action?

[Michael Schwendt]

On Tue, 1 Dec 2015 08:25:28 -0600, Ranjan Maitra wrote:

> My BZ account goes back in time -- I have been quite active in submitting and 
> testing bug reports for almost ten years -- so  it has a different e-mail 
> address (when more mailing lists plastered your e-mail address and name 
> unfiltered). I don't quite understand why this should be an issue, and I note 
> also that BZ makes the e-mail address widely available to everybody, 
> therefore I was reluctant to change it. I will think about what to do.
> 

???

How is that even relevant? Your real name in bugzilla is a separate field
in the preferences. You don't need to change the email address.

For your bugzilla account to work correctly with FAS, the email address
in bugzilla must be the same as in FAS. Or else your bugzilla account
doesn't receive privileges you gain via group membership in FAS.

-- 
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

[389-users] Re: upgrade to 389-ds-base-1.3.4 Q

[Rich Megginson]

On 12/01/2015 10:07 AM, ghiureai wrote:

Hi List,
we are tying to upgrade to 389-ds 1.3.4 from 1.2.2 , after rpm 
installed and update the server ,  when restarting the DS geting the 
following in DS errorlog, there is no such "entryallowWeakCipher" in 
cfg file , what should we dissable see entries for this cn


http://www.port389.org/docs/389ds/design/nss-cipher-design.html



 SSL alert: Cipher rsa_rc4_128_md5 is weak. It is enabled since 
allowWeakCipher is "on" (default setting for the backward 
compatibility). We strongly recommend to set it to "off".  Please 
replace the value of allowWeakCipher with "off" in the encryption 
config entry cn=encryption,cn=config and restart the server.


dn: cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionConfig
cn: encryption
nsSSLSessionTimeout: 0
nsSSLClientAuth: allowed
nsSSL2: off

nsSSL3: off ->>> This was on but turn to "off"

creatorsName: cn=server,cn=plugins,cn=config
modifiersName: 
uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoo

 t
createTimestamp: 
modifyTimestamp:
nsSSL3Ciphers: 
-rsa_null_md5,-rsa_null_sha,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+r
 sa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha 

 ,+fortezza,+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_ 


 56_sha,+tls_rsa_aes_128_sha,+tls_rsa_aes_256_sha


xxx
xxx

Thank you for your time
Isabella
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org 


--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

Re: encrypting /home partition post-install

[Roberto Ragusa]

On 12/01/2015 06:35 PM, Gordon Messmer wrote:
> On 12/01/2015 06:43 AM, Roberto Ragusa wrote:
>>> ... should note that you'll have to shrink at least one of your volumes, 
>>> though.  The encrypted PV that you create will be slightly smaller than it 
>>> was, before encryption.  As a result, there won't be enough extents to move 
>>> all of the volumes off and then back.
>> The PV is used in multiple of the segment size, so, depending on rounding 
>> errors you may
>> have some free blocks.
> 
> Sounds right.  "pvdisplay" will print information about unusable space in the 
> "PV Size" line.  As long as that's larger than the LUKS header (2MiB, I 
> believe) you should be able to do a live migration to an encrypted PV using a 
> second disk.
> 
> Interesting.

And one can do it on purpose:
- big segments (64MiB)
- partitions with a little overhead (100.01GiB, so there are 10MiB of extra 
room)
- PV, mdadm or luks headers will never be a problem


-- 
   Roberto Ragusamail at robertoragusa.it
-- 
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

Logwatch

[jarmo]

How I can get rid of this:
Redundant argument in sprintf
at /usr/share/logwatch/scripts/services/postfix line 1382, <> line 10

I see it every day in logwatch...

Jarmo

-- 
конец
-- 
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

After Mate upgrade panel disappears.

[Frank McCormick]

DNF upgraded my Fedora 22 machine tonightmostly the newest 1.12 
version of Mate.
Now my bottom panel has disappeared. HTOP says mate panel is loaded but 
nothing

is visible on the screen.

Any suggestion on how I can debug this latest improvement :)

Thanks
--
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: submitted RPMs and awaiting action?

[Ranjan Maitra]

I do not also agree that this ML is not appropriate for bringing up points of 
general interest to all Fedora users. But I think my comments will be becoming 
repetitive soon so unless something new pops up, there is not much point in 
rehashing the points. 

Thanks to Michael for the extended and animated discussion.

On Wed, 2 Dec 2015 00:00:23 +0100 Michael Schwendt  wrote:

> If at all, the bureaucracy that could be removed is the review process for
> packages from existing members of the packager group, who have demonstrated
> before that they know their stuff.
> 
> There are some, who could be highly productive and could pipe out a
> higher number of packages (e.g. needed dependencies), if they didn't need
> to wait for a second pair of eyes to check even trivial packages.
> 

:-)

I was not talking of removing the "bureaucracy", but making the process a bit 
less bureaucratic. But you are right: I am sure that these things have been 
thought over by people more experienced and knowledgeable than me. 

> "Could, could, could". That's always the same cheap talk. Over the years
> there have been various tools to automate RPM packaging *including*
> determining BuildRequires and explicit Requires. Where is the tool that's
> sufficiently complete and safe to use? It's still much easier for human
> packagers to do it right and use custom tools to automate some tasks.

Probably nothing, but perhaps could be a good starting point.
 
> > At the very least, have it suggest a skeleton.
> 
> A skeleton for what?
> Do you realize how much packages can differ? For example, packages for
> Java stuff vs. packages for Perl or Python?

Yes, but there would be skeletons for each of the different main types. Can be 
done perhaps, perhaps not. Just an  idea.
 
> There's the template generate "rpmdev-newspec" in the rpmdevtools
> package. It creates a spec file for building and packaging a typical
> Autotools based program.

I find python far more difficult to handle than any of the others.

> It's *so* simple to ignore those warnings (where rpmlint fails because
> of poor dictionaries or related issues). Why do you continue to blame
> rpmlint for some of its false positives?

Well, if we want to end up with a more automated process, then reducing false 
flags is a must.

> Have you run the fedora-review tool on your packages and/or bugzilla
> review tickets yet?

I have not run the fedora-review tool, but I did run the koji build tool (some 
time ago and even now, on f22, f23, rawhide) and it passed for both packages. 
Is this not adequate?

> There is much higher load for the submitters, provided that they really
> want to maintain the package and not only dump it into a repository.

OK.

> Anyone, who thinks that the review process is too high a hurdle, has never
> practised package maintainance before. Not with personal packages in some
> private repo, and not with a public personal repo either. Certainly not
> for a period of let's say a year or so. Or multiple years in RHEL/EPEL-style.

Agreed: I have no prior experience.

> > It sort of defeats the purpose of Linux.

> Please elaborate. What do you have in mind here?
Simply that niche packages are going to be in less demand and would hurt those 
users who have unusual likes. Not every one should have to be a programmer to 
want stuff that they would like to use. Sylfilter, for instance, is extremely 
lightweight, and does an extremely good job. I have packaged it for my use, but 
others may find the hurdle too high to compile from source or to evaluate a 
package submitted to BZ.

> 
> > Ideally, if only two people have need for a package, and if the first
> > person is the packager (say), then how likely is it for the second user
> > to actually be a member of BZ and the review set, rather than go off to
> > some other distribution (AUR, say) where things are easier to come by?
> 
> Pardon? Do you intend to play the "attempted blackmail" card here? That's
> quite common for so-called "distro-hoppers", who would switch back and
> forth between distributions for every pet peeve they come up with. ;-)

I have used and contributed to Fedora from the days of Fedora 1 (RH7 and RH9, 
actually). I don't think I can be accused of whatever you think you are 
accusing me of. I have come to, however, also appreciate Arch's fabulous 
documentation on, well, almost everything, and also like  its rolling-release 
model. But I have invested in and benefited too much from the community here to 
give it up. 

...
> Some of the plans may become fruitful, but require that the contributors
> are willing to leave the dumping ground level by offering a bit more than
> a src.rpm that seems to build. As soon as some packagers receive a first
> batch of bugzilla reports from frustrated package users that have started
> using a package, they hide somewhere.

It is a good point. But the packager is only responsible for the packaging, 
generally not for upstream 

Re: submitted RPMs and awaiting action?

[Michael Schwendt]

On Tue, 1 Dec 2015 09:56:39 -0600, Ranjan Maitra wrote:

> On Tue, 1 Dec 2015 15:37:15 + James Hogarth wrote:
> 
> > Although adjusting spec as per direction from others you don't appear to be
> > making an effort on the process/people side of things.  
> 
> But should a volunteer effort be so complicated? That is the question. Yes, 
> we can always point to voluminous, sometimes outdated, sometimes inconsistent 
> writeups, but therein lies the problem.
> 

To put it bluntly -- and the Fedora Project has done a good job at teaching
people to be more blunt -- if you're so reluctant with regard to many simple
things/tasks, one alternative is to sit and wait and offer your packages
somewhere else. Such as Fedora Copr. Or hope that Fedora leadership will
move away from current procedures more quickly -- if that still is what
they would like to do. Then, however, much will be different, and it is
hard to say whether "the distribution" will still be popular at all.

It cannot be repeated often enough: The package review queue is publicly
visible. If a package in the queue(s) is not evaluated by anyone at all
in the community, that means that there is no interest in the package
or no interest in maintaining the package with the package collection.
For quite some people it is less effort to run with selfmade packages
in a private local repo than becoming a volunteer package maintainer
with interest in team work (for example).

> > I laid out clear steps for you to follow - they are not complicated.  
> 
> Perhaps not to someone familiar with the process. But volunteer efforts, on 
> all sides, should be streamlined as far as possible. I certainly feel it is 
> not.
> 

A good first step would have been to discuss the unclear things then.
-- 
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: submitted RPMs and awaiting action?

[Michael Schwendt]

On Tue, 1 Dec 2015 08:20:45 -0600, Ranjan Maitra wrote:

> > The ticket has not even been visible in the needsponsor queue because the
> > fedora-review flag set to '?' means there is a reviewer working on it.  
> 
> OK, I missed this. But should this not be set as the default?
> What is the point of setting it as something else, when a review request
> means that it is looking for a sponsor/reviewer?

New packages don't need "sponsorship", but new contributors do.

It's step 3 here:
https://fedoraproject.org/wiki/Package_Review_Process#Contributor

There are many more new packages added to the queue than new contributors.

Btw, I'm not in any position to do anything about this process. If anyone
wants to suggest improvements, open a thread on devel@ list, for example.
-- 
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

[389-users] Re: upgrade to 389-ds-base-1.3.4 Q

[ghiureai]

Thank you Rich for reply one more related issues I see :

When need to run the  ds admin update  I do not see the  options for 
update,  seems goes back and asks all the Q's  as a new fresh 
installation ( ??)
What we are missing from this upgrade installation here is what is been 
installed

   grep 389-*
389-ds-console-1.2.12-000.x86_64
389-admin-1.1.42-000.x86_64
389-ds-base-1.3.4.4-000.x86_64
389-console-1.1.9-000.x86_64
389-admin-console-1.1.10-000.x86_64
389-adminutil-1.1.22-000.x86_64





On 12/01/2015 09:07 AM, ghiureai wrote:

Hi List,
we are tying to upgrade to 389-ds 1.3.4 from 1.2.2 , after rpm installed
and update the server ,  when restarting the DS geting the following in
DS errorlog, there is no such  "entryallowWeakCipher" in cfg file , what
should we dissable see entries for this cn

   SSL alert: Cipher rsa_rc4_128_md5 is weak. It is enabled since
allowWeakCipher is "on" (default setting for the backward
compatibility). We strongly recommend to set it to "off".  Please
replace the value of allowWeakCipher with "off" in the encryption config
entry cn=encryption,cn=config and restart the server.

dn: cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionConfig
cn: encryption
nsSSLSessionTimeout: 0
nsSSLClientAuth: allowed
nsSSL2: off

nsSSL3: off ->>> This was on but turn to "off"

creatorsName: cn=server,cn=plugins,cn=config
modifiersName:
uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoo
   t
createTimestamp: 
modifyTimestamp:
nsSSL3Ciphers:
-rsa_null_md5,-rsa_null_sha,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+r
   sa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha
   ,+fortezza,+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_
   56_sha,+tls_rsa_aes_128_sha,+tls_rsa_aes_256_sha


xxx
xxx

Thank you for your time
Isabella


--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

Re: It's 2015, and OOM handling still sucks

[Neal Becker]

Ian Malone wrote:

> On 1 December 2015 at 15:19, Neal Becker  wrote:
>> I have a pretty nice workstation, with 8 cores and 32G RAM.
>>
>> A stupid little python program just killed it by consuming all the
>> memory, driving it into swapping hell.
>>
>> I couldn't even ssh into it - I started up ssh and went for coffee.  On
>> return I still didn't have a prompt.  Had to power cycle it.
>>
>> This is F23, everything is setup default regarding kernel memory
>> policies, etc.
>>
>> So, can we configure things to give a better experience?  Can we make
>> this default?
>>
> 
> Maybe one for the devel list where they can do something about it. I
> haven't actually checked what the current Fedora policies are, since
> at work I use RHEL. I'd have thought the oom killer would get this.
> Really taking out all the memory with no swap available seems more
> likely to kill a system, possibly memory use can expand too fast, but
> on systems with some swap I've rarely seen things get to the point you
> can't get a virtual terminal up.
> cat /proc/meminfo 
MemTotal:   32902244 kB
MemFree:24712892 kB
MemAvailable:   28580148 kB
Buffers:2996 kB
Cached:  3769828 kB
SwapCached:0 kB
Active:  5229044 kB
Inactive:2420832 kB
Active(anon):3878352 kB
Inactive(anon):36628 kB
Active(file):1350692 kB
Inactive(file):  2384204 kB
Unevictable:  16 kB
Mlocked:  16 kB
SwapTotal:  16400376 kB
SwapFree:   16400376 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages:   3877468 kB
Mapped:   307056 kB
Shmem: 37928 kB
Slab: 295500 kB
SReclaimable: 218208 kB
SUnreclaim:77292 kB
KernelStack:9264 kB
PageTables:41680 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit:32851496 kB
Committed_AS:6566200 kB
VmallocTotal:   34359738367 kB
VmallocUsed:  190544 kB
VmallocChunk:   34359531516 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:  194712 kB
DirectMap2M: 6053888 kB
DirectMap1G:28311552 kB


-- 
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: It's 2015, and OOM handling still sucks

[Rick Stevens]

On 12/01/2015 07:19 AM, Neal Becker wrote:

I have a pretty nice workstation, with 8 cores and 32G RAM.

A stupid little python program just killed it by consuming all the memory,
driving it into swapping hell.

I couldn't even ssh into it - I started up ssh and went for coffee.  On
return I still didn't have a prompt.  Had to power cycle it.

This is F23, everything is setup default regarding kernel memory policies,
etc.

So, can we configure things to give a better experience?  Can we make this
default?


You can sure edit /etc/security/limits.conf and bugger values there
to limit it based on user IDs.
--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
- IGNORE that man behind the keyboard!   -
-- The Wizard of OS  -
--
--
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: encrypting /home partition post-install

[Tim]

Allegedly, on or about 30 November 2015, Gordon Messmer sent:
> Systems with simple, relatively static storage will, by the same
> token, not require users to interact with LVM.  So where is the case
> for not using it, exactly? 

Do we have file system recovery tools for it, yet?  (Assuming that a
problem might occur with LVM, itself, rather than an EXT3 filesystem
within it.)

That was always the kicker, before.


-- 
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64

All mail to my mailbox is automatically deleted, there is no point
trying to privately email me, I will only read messages posted to the
public lists.

ZNQR LBH YBBX!



-- 
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

It's 2015, and OOM handling still sucks

[Neal Becker]

I have a pretty nice workstation, with 8 cores and 32G RAM.

A stupid little python program just killed it by consuming all the memory, 
driving it into swapping hell.

I couldn't even ssh into it - I started up ssh and went for coffee.  On 
return I still didn't have a prompt.  Had to power cycle it.

This is F23, everything is setup default regarding kernel memory policies, 
etc.

So, can we configure things to give a better experience?  Can we make this 
default?

-- 
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: encrypting /home partition post-install

[Roberto Ragusa]

On 11/30/2015 11:24 PM, Ranjan Maitra wrote:
> On Mon, 30 Nov 2015 21:59:35 +0100 Roberto Ragusa  
> wrote:
> 
>> All of this can be done while the system is running
>> normally.
>> Before rebooting, fix your /etc/crypttab and initramfs
>> so you will be asked the passphrase at next boot.
> 
> Can you please give me a reference on how to fix /etc/cryptab or this 
> initramfs up?

I do not have a reference, I just discovered things with experience:

/etc/crypttab should contain something like:

luks----- 
UUID=---- none


/boot/grub/grub.conf should contain on your kernel line the part

rd.md=1 rd.dm=1 rd.luks=1

or at least the luks one


then I rebuild the initramfs; the way to do this is continuously changed so my
method is to run   rpm -q --scripts kernel   and look at the posttrans part:

posttrans scriptlet (using /bin/sh):
/sbin/new-kernel-pkg --package kernel --mkinitrd --dracut --depmod --update 
3.14.17-100.fc19.x86_64 || exit $?
/sbin/new-kernel-pkg --package kernel --rpmposttrans 3.14.17-100.fc19.x86_64 || 
exit $?

so I run those two commands.


Sorry for not giving an accurate procedure, but those are the points to 
consider.


Regards.


-- 
   Roberto Ragusamail at robertoragusa.it
-- 
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: encrypting /home partition post-install

[Ranjan Maitra]

On Tue, 1 Dec 2015 16:12:07 +0100 Roberto Ragusa  wrote:

> On 11/30/2015 11:24 PM, Ranjan Maitra wrote:
> > On Mon, 30 Nov 2015 21:59:35 +0100 Roberto Ragusa  
> > wrote:
> > 
> >> All of this can be done while the system is running
> >> normally.
> >> Before rebooting, fix your /etc/crypttab and initramfs
> >> so you will be asked the passphrase at next boot.
> > 
> > Can you please give me a reference on how to fix /etc/cryptab or this 
> > initramfs up?
> 
> I do not have a reference, I just discovered things with experience:
> 
> /etc/crypttab should contain something like:
> 
> luks----- 
> UUID=---- none
> 
> 
> /boot/grub/grub.conf should contain on your kernel line the part
> 
> rd.md=1 rd.dm=1 rd.luks=1
> 
> or at least the luks one
> 
> 
> then I rebuild the initramfs; the way to do this is continuously changed so my
> method is to run   rpm -q --scripts kernel   and look at the posttrans part:
> 
> posttrans scriptlet (using /bin/sh):
> /sbin/new-kernel-pkg --package kernel --mkinitrd --dracut --depmod --update 
> 3.14.17-100.fc19.x86_64 || exit $?
> /sbin/new-kernel-pkg --package kernel --rpmposttrans 3.14.17-100.fc19.x86_64 
> || exit $?
> 
> so I run those two commands.
> 
> 
> Sorry for not giving an accurate procedure, but those are the points to 
> consider.

No problem. Thank you. this is very helpful. Btw, isn't the recommended way to 
edit grub by changing /etc/defaults/grub and then running grub-mkconfig or is 
that for something else?

Best wishes,
Ranjan


FREE ONLINE PHOTOSHARING - Share your photos online with your friends and 
family!
Visit http://www.inbox.com/photosharing to find out more!


-- 
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: submitted RPMs and awaiting action?

[James Hogarth]

On 1 December 2015 at 14:25, Ranjan Maitra 
wrote:

> On Tue, 1 Dec 2015 14:21:59 +0100 Michael Schwendt 
> wrote:
>
> > On Tue, 1 Dec 2015 13:08:29 +, James Hogarth wrote:
> >
> > > The if you want to proceed take the following steps:
> > > 1. Fix up your bugzilla/FAS accounts
> >
> > Really do enter your real name in bugzilla and package %changelogs, too,
> > and avoid using pseudonyms/aliases even if you find them "cool" or
> > anything like that. There are enough fellow contributors, who are put
> > off by silly names like that.
>
> The changelog (in the spec file?) and the FAS account has my real name
> (and e-mail address, FWIW). My BZ account goes back in time -- I have been
> quite active in submitting and testing bug reports for almost ten years --
> so  it has a different e-mail address (when more mailing lists plastered
> your e-mail address and name unfiltered). I don't quite understand why this
> should be an issue, and I note also that BZ makes the e-mail address widely
> available to everybody, therefore I was reluctant to change it. I will
> think about what to do.
>
>
I pointed you to this:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

Have you read it yet?

Note that the mailing list bears no relation to the address in FAS ... this
is what we are talking about (ignoring the preference for real name over
pseudonym in bugzilla).

Although adjusting spec as per direction from others you don't appear to be
making an effort on the process/people side of things.

I laid out clear steps for you to follow - they are not complicated.

If you aren't willing to do the modicum amount of work to actually take
part in packagers group and seek a sponsor then I'm not willing to take
time out of my day to go through fedora-review on your packaging request.

Incidentally the 'EOL' notice you're expecting won't happen with a
packaging request as that's targeted against rawhide and not a specific
fedora revision.
-- 
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: encrypting /home partition post-install

[Roberto Ragusa]

On 12/01/2015 04:27 PM, Ranjan Maitra wrote:
> On Tue, 1 Dec 2015 16:12:07 +0100 Roberto Ragusa  
> wrote:

> No problem. Thank you. this is very helpful. Btw, isn't the recommended way 
> to edit grub by changing /etc/defaults/grub and then running grub-mkconfig or 
> is that for something else?
> 

Yes, in fact I said "/boot/grub/grub.conf should contain", not
"edit the file and add". ;-)
If you can make it to contain the stuff by using /etc/defaults/grub
it's perfect, but I never really understood how that flow
is supposed to work, as it seems that installing a new
kernel, options are just copied from the existing kernel to
the new one.
This could be different/fixed in recent Fedora versions...

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
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: submitted RPMs and awaiting action?

[Ranjan Maitra]

On Tue, 1 Dec 2015 15:37:15 + James Hogarth  wrote:

> I pointed you to this:
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
> 
> Have you read it yet?

I read it and other documents when I submitted, and then found that there were 
steps  (running rpmlint) that had to be taken which was not mentioned anywhere 
then.

> 
> Note that the mailing list bears no relation to the address in FAS ... this
> is what we are talking about (ignoring the preference for real name over
> pseudonym in bugzilla).

OK, I fixed this, I hope!

> 
> Although adjusting spec as per direction from others you don't appear to be
> making an effort on the process/people side of things.

But should a volunteer effort be so complicated? That is the question. Yes, we 
can always point to voluminous, sometimes outdated, sometimes inconsistent 
writeups, but therein lies the problem.

> I laid out clear steps for you to follow - they are not complicated.

Perhaps not to someone familiar with the process. But volunteer efforts, on all 
sides, should be streamlined as far as possible. I certainly feel it is not.

> 
> If you aren't willing to do the modicum amount of work to actually take
> part in packagers group and seek a sponsor then I'm not willing to take
> time out of my day to go through fedora-review on your packaging request.

But what did I not look into that you(?) or someone else asked me to?

> 
> Incidentally the 'EOL' notice you're expecting won't happen with a
> packaging request as that's targeted against rawhide and not a specific
> fedora revision.

I see, that is good to know. Incidentally, all these RPMs have been running on 
my systems for years (sylfilter)/months(pdf-stapler).

Thanks,
Ranjan


-- 
Important Notice: This mailbox is ignored: e-mails are set to be deleted on 
receipt. Please respond to the mailing list if appropriate. For those needing 
to send personal or professional e-mail, please use appropriate addresses.


FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your 
desktop!
Check it out at http://www.inbox.com/marineaquarium


-- 
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: submitted RPMs and awaiting action?

[James Hogarth]

On 1 December 2015 at 11:53, Ranjan Maitra 
wrote:

> Hi,
>
> Some time ago, circa May 2015, there was a long thread called "Biting the
> Bullet" [1] where some others complained about the lack of pdftk on F21 and
> later. (This complaint also manifested itself sometime later.)
>
> In response, and with both general and more specific help from those more
> experienced, I was able to put together an RPM for pdf-stapler as an
> alternative to pdftk. I submitted to a black hole called Fedora packaging
> where there was some churn, some more suggestions (a few contradicting the
> other) which I duly implemented but no one actually able to move the
> process forward. However, it sits here:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1234210
>
> unassigned. It has passed through rpmlint (no errors, only a few
> nonsensical spelling warnings) and whatever else it was supposed to pass as
> per packaging guidelines. So also is the case of sylfilter which I packaged
> separately, and no one has even bothered to comment on:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1265685
>
> Now, I understand that quality control is an important part of the Fedora
> packaging which is what makes it a good product (and I am no great
> RPM-maker, witness my questions on the subject), and there is a dearth of
> enough people eligible to assign to, but surely, there must be some better
> way to handle new proposed packages. For instance, if automated setups
> clear a package, perhaps it would be better to move it to the top of the
> list or even clear it for testing and see what happens? Otherwise, there
> will be frustration and the pool of packagers will not grow. Not to mention
> that if packages sit like this this for months before being acted upon,
> then the original packager will have lost context and memory and moved on
> (certainly it would be frustrating and more onerous on him/her than it
> would be if it were acted upon sooner). Otherwise, people will move on.
>
> I don't need these packages because I have them for myself. Indeed, I
> could be more sloppy in creating these rpms (or not even bothering to do
> so),  but the reason for putting this out is benefit to the community which
> has also benefited me/us. This is especially true for niche packages such
> as sylfilter, etc which may not even have much users who would be willing
> to test it.
>
> I have some experience with submitting packages for R. My experience there
> is that if it passes all the tests, it is by and large through, but if it
> does not (surprisingly, Macs are the killers in most cases), it is not, and
> feedback is fairly quick.
>
> Perhaps, it would be worthwhile to think about how to streamline the
> process. At this point, I am fully expecting the familiar notice for EOL
> eventually.
>
> Best wishes,
> Ranjan
>

 There has been recent discussion on this on the fedora-devel mailing list
(which if you want to be a packager you really should join).

I'd suggest catching up on this thread:
https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/message/JL7BKPIHNMVIL7ZSDCA7WB7NX7KQXF6I/

This was the FESCO ticket involved:
https://fedorahosted.org/fesco/ticket/1499

The short version is any current packager can now review your new package
rather than only a sponsor, but you still need to find a sponsor as pointed
out in comment #6 of your bug, in addition you don't appear to have
addressed the issue in comment #16 which will put off anyone getting
involved until FAS and bugzilla line up at the least.

As for your other package review request I'd suggest that given the state
of the first no one feels like diving into the second - for instance on the
second you have not blocked it against FE_NEEDSPONSOR or mention that you
need on in the bug.

Have a read through this doc on how to join the package maintainers again:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

The if you want to proceed take the following steps:
1. Fix up your bugzilla/FAS accounts
2. Join the fedora devel mailing list
3. Introduce yourself on fedora-devel - include that you need a sponsor.
4. Wait a little while and if you don't have any sponsors respond to you be
proactive - polite emails to those on the Fedora wiki indicating they are
sponsors willing to help bring in a new contributor... demonstrate what you
have done to get acquainted with packaging and that you understand what the
guidelines entail.

Please note that "it passes tests" is not sufficient to be approved to be
added to the fedora repositories.
-- 
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: Appending the file modified date to the file name

[Ian Malone]

On 1 December 2015 at 02:30, Gordon Messmer  wrote:
> On 11/30/2015 04:49 PM, Robert Moskowitz wrote:
>>>
>>> You could:
>>>  mv "$file" "$file-$(stat -c %y "$file")"
>>
>>
>> Not quite as the script:
>>
>> #!/bin/bash
>> for i in `seq 20 42`;
>>  do
>>  file="Voice "0${i}.m4a
>>  mv $file "$file-$(stat -c %y "$file")"
>>  done
>>
>> is producing:
>>
>> mv: target ‘Voice 036.m4a-2015-05-07 06:51:59.0 -0400’ is not a
>> directory
>
>
> That's why I quoted "$file" in both instances.
>
> Your file name has a space in it, so the command you ran is:
>
> "mv" "Voice" "036.m4a" "Voice 036.m4a-2015-05-07 06:51:59.0 -0400"
>
> And since "mv" got 3 arguments, it requires that the last one is a
> directory.
>
> If you had quoted "$file" after mv, it should have worked properly.
>

Though in general try to avoid adding whitespace when automatically
naming files, it's just a pain. (This doesn't mean you don't need to
be careful about your source files having whitespace, but no need to
inflict more on yourself.)

E.g. ISO time without white space:
date -d "$(stat -c %y "$file")" +"%Y-%m-%dT%H:%M:%S%z"

Substituting spaces in the target name:
echo "$outfile" | tr " " "-"

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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

submitted RPMs and awaiting action?

[Ranjan Maitra]

Hi,

Some time ago, circa May 2015, there was a long thread called "Biting the 
Bullet" [1] where some others complained about the lack of pdftk on F21 and 
later. (This complaint also manifested itself sometime later.) 

In response, and with both general and more specific help from those more 
experienced, I was able to put together an RPM for pdf-stapler as an 
alternative to pdftk. I submitted to a black hole called Fedora packaging where 
there was some churn, some more suggestions (a few contradicting the other) 
which I duly implemented but no one actually able to move the process forward. 
However, it sits here:

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

unassigned. It has passed through rpmlint (no errors, only a few nonsensical 
spelling warnings) and whatever else it was supposed to pass as per packaging 
guidelines. So also is the case of sylfilter which I packaged separately, and 
no one has even bothered to comment on:

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

Now, I understand that quality control is an important part of the Fedora 
packaging which is what makes it a good product (and I am no great RPM-maker, 
witness my questions on the subject), and there is a dearth of enough people 
eligible to assign to, but surely, there must be some better way to handle new 
proposed packages. For instance, if automated setups clear a package, perhaps 
it would be better to move it to the top of the list or even clear it for 
testing and see what happens? Otherwise, there will be frustration and the pool 
of packagers will not grow. Not to mention that if packages sit like this this 
for months before being acted upon, then the original packager will have lost 
context and memory and moved on (certainly it would be frustrating and more 
onerous on him/her than it would be if it were acted upon sooner). Otherwise, 
people will move on.

I don't need these packages because I have them for myself. Indeed, I could be 
more sloppy in creating these rpms (or not even bothering to do so),  but the 
reason for putting this out is benefit to the community which has also 
benefited me/us. This is especially true for niche packages such as sylfilter, 
etc which may not even have much users who would be willing to test it.

I have some experience with submitting packages for R. My experience there is 
that if it passes all the tests, it is by and large through, but if it does not 
(surprisingly, Macs are the killers in most cases), it is not, and feedback is 
fairly quick. 

Perhaps, it would be worthwhile to think about how to streamline the process. 
At this point, I am fully expecting the familiar notice for EOL eventually. 

Best wishes,
Ranjan


[1] https://lists.fedoraproject.org/pipermail/users/2015-May/460623.html
-- 
Important Notice: This mailbox is ignored: e-mails are set to be deleted on 
receipt. Please respond to the mailing list if appropriate. For those needing 
to send personal or professional e-mail, please use appropriate addresses.


FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth


-- 
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: encrypting /home partition post-install

[Patrick O'Callaghan]

On Mon, 2015-11-30 at 19:01 -0800, Gordon Messmer wrote:
> Systems with simple, relatively static storage will, by the same
> token, not require users to interact with LVM. 
> So where is the case for not using it, exactly?

Not so. If you have LVM you have to *know* you have LVM, otherwise your
disk partition names won't make any sense. Just doing a "df" requires
you to know this and understand what it means.

poc
-- 
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: encrypting /home partition post-install

[Roberto Ragusa]

On 11/30/2015 10:07 PM, Gordon Messmer wrote:
> On 11/30/2015 01:06 PM, Gordon Messmer wrote:
>> You can add a PV to encrypt the system without rebooting.
> 
> ... should note that you'll have to shrink at least one of your volumes, 
> though.  The encrypted PV that you create will be slightly smaller than it 
> was, before encryption.  As a result, there won't be enough extents to move 
> all of the volumes off and then back.

Not always.
The PV is used in multiple of the segment size, so, depending on rounding 
errors you may
have some free blocks.
For example, if you use 64MiB as segment, a 650MiB PV will contain 10 of them.
The same PV when encrypted will be 649.99MiB (just guessing...), but it will 
perfectly
contain 10 segments again.

This was very true when partition were very badly aligned (factors 63, 16, 255 
around);
nowadays because of 4k disks and SSD, things are better aligned so it may 
actually
happen that you miss one segment and one filesystem must be resized.
Again, if the PV goes up to the end of the disk, you have probably some
misaligned ending block, so you are lucky again (even SSD have kept the strange
habit of being sized in 10^3 instead that 2^10).

Regards.

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
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: submitted RPMs and awaiting action?

[Michael Schwendt]

On Tue, 1 Dec 2015 05:53:13 -0600, Ranjan Maitra wrote:

> Some time ago, circa May 2015, there was a long thread called "Biting the 
> Bullet" [1] where some others complained about the lack of pdftk on F21 and 
> later. (This complaint also manifested itself sometime later.) 
> 
> In response, and with both general and more specific help from those more 
> experienced, I was able to put together an RPM for pdf-stapler as an 
> alternative to pdftk. I submitted to a black hole called Fedora packaging 
> where there was some churn, some more suggestions (a few contradicting the 
> other) which I duly implemented but no one actually able to move the process 
> forward. However, it sits here:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1234210

No drama, please.

So many words in this mail of yours. The time could have been spent better
on swapping reviews, reading the process documentation and fixing the
bugzilla tickets, too. Waiting passively leads to something seldomly.

The ticket has not even been visible in the needsponsor queue because the
fedora-review flag set to '?' means there is a reviewer working on it.

> unassigned. It has passed through rpmlint (no errors, only a few nonsensical 
> spelling warnings) and whatever else it was supposed to pass as per packaging 
> guidelines. So also is the case of sylfilter which I packaged separately, and 
> no one has even bothered to comment on:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1265685

Here you could also have added the needsponsor flag as per the process guide.

The various review queues are quite crowded:
http://fedoraproject.org/PackageReviewStatus/

What else?

https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
-- 
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: submitted RPMs and awaiting action?

[Michael Schwendt]

On Tue, 1 Dec 2015 13:08:29 +, James Hogarth wrote:

> The if you want to proceed take the following steps:
> 1. Fix up your bugzilla/FAS accounts

Really do enter your real name in bugzilla and package %changelogs, too,
and avoid using pseudonyms/aliases even if you find them "cool" or
anything like that. There are enough fellow contributors, who are put
off by silly names like that.
-- 
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: submitted RPMs and awaiting action?

[Ranjan Maitra]

On Tue, 1 Dec 2015 14:18:38 +0100 Michael Schwendt  wrote:

> On Tue, 1 Dec 2015 05:53:13 -0600, Ranjan Maitra wrote:
> 
> > Some time ago, circa May 2015, there was a long thread called "Biting the 
> > Bullet" [1] where some others complained about the lack of pdftk on F21 and 
> > later. (This complaint also manifested itself sometime later.) 
> > 
> > In response, and with both general and more specific help from those more 
> > experienced, I was able to put together an RPM for pdf-stapler as an 
> > alternative to pdftk. I submitted to a black hole called Fedora packaging 
> > where there was some churn, some more suggestions (a few contradicting the 
> > other) which I duly implemented but no one actually able to move the 
> > process forward. However, it sits here:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1234210
> 
> No drama, please.

I am sorry, but whatever said is just my statement of fact. 

> 
> So many words in this mail of yours. The time could have been spent better
> on swapping reviews, reading the process documentation and fixing the
> bugzilla tickets, too. Waiting passively leads to something seldomly.

I don't know if I was waiting passively. But if a process is so intricate and 
involved, then it needs to be simplified.

> The ticket has not even been visible in the needsponsor queue because the
> fedora-review flag set to '?' means there is a reviewer working on it.

OK, I missed this. But should this not be set as the default? What is the point 
of setting it as something else, when a review request means that it is looking 
for a sponsor/reviewer? Anyway, I noticed that you have changed it now: thanks!!

Best wishes,
Ranjan


FREE ONLINE PHOTOSHARING - Share your photos online with your friends and 
family!
Visit http://www.inbox.com/photosharing to find out more!


-- 
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: submitted RPMs and awaiting action?

[Ranjan Maitra]

On Tue, 1 Dec 2015 14:21:59 +0100 Michael Schwendt  wrote:

> On Tue, 1 Dec 2015 13:08:29 +, James Hogarth wrote:
> 
> > The if you want to proceed take the following steps:
> > 1. Fix up your bugzilla/FAS accounts
> 
> Really do enter your real name in bugzilla and package %changelogs, too,
> and avoid using pseudonyms/aliases even if you find them "cool" or
> anything like that. There are enough fellow contributors, who are put
> off by silly names like that.

The changelog (in the spec file?) and the FAS account has my real name (and 
e-mail address, FWIW). My BZ account goes back in time -- I have been quite 
active in submitting and testing bug reports for almost ten years -- so  it has 
a different e-mail address (when more mailing lists plastered your e-mail 
address and name unfiltered). I don't quite understand why this should be an 
issue, and I note also that BZ makes the e-mail address widely available to 
everybody, therefore I was reluctant to change it. I will think about what to 
do.


Best wishes,
Ranjan


FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your 
desktop!
Check it out at http://www.inbox.com/marineaquarium


-- 
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: It's 2015, and OOM handling still sucks

[Ian Malone]

On 1 December 2015 at 15:19, Neal Becker  wrote:
> I have a pretty nice workstation, with 8 cores and 32G RAM.
>
> A stupid little python program just killed it by consuming all the memory,
> driving it into swapping hell.
>
> I couldn't even ssh into it - I started up ssh and went for coffee.  On
> return I still didn't have a prompt.  Had to power cycle it.
>
> This is F23, everything is setup default regarding kernel memory policies,
> etc.
>
> So, can we configure things to give a better experience?  Can we make this
> default?
>

Maybe one for the devel list where they can do something about it. I
haven't actually checked what the current Fedora policies are, since
at work I use RHEL. I'd have thought the oom killer would get this.
Really taking out all the memory with no swap available seems more
likely to kill a system, possibly memory use can expand too fast, but
on systems with some swap I've rarely seen things get to the point you
can't get a virtual terminal up.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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