[arch-general] GUFW start problem

[Alonzo Gomez via arch-general]

Hello.

Using Arch X86-64 up to date.  Gnome 3, with GDM.  UFW works fine.

Logging in (GDM) gives 3 choices:
- Gnome
- Gnome classic
- Gnome with xorg

If I log in as using the option "Gnome with xorg" at GDM, GUFW works fine.

But, if I log in choosing either "Gnome" or "Gnome classic", GUFW will
not start.  Instead, whether I click the gui icon, or do "gufw" or
"sudo gufw" in a terminal, the authentication dialog box appears
asking for the password.  After entering the password, the dialog box
disappears, and nothing further happens.

This is regardless of whether I use Linux, Linux-lts, or Linux-grsec.

Fwiw, I do have net-tools and python-gobject both installed.
Python-gi does not seem to be in the repos.

If necessary, I can reboot into either Gnome or Gnome classic, try
GUFW again, and post whatever error messages would be helpful.

BTW, no other application program exhibit this behavior.

Re: [arch-general] Weird reaction to pull request over at Arch Linux ARM

[Christopher Reimer]

On 27.01.2017 22:38, ProgAndy wrote:

Am 27.01.2017 um 21:41 schrieb Eli Schwartz via arch-general:

On 01/27/2017 01:27 PM, Christopher Reimer wrote:

I also noticed a few other pull request trying exactly that, which
were instantly closed by Kevin Mihelich without any reasonable
explanation. That's why I expected some resistance and prepared
myself to counterargument a few of his concerns.

And I think I did quite good. Good enough to make him ignore me.

Oh, he's ignoring you? I must be imagining this quote:


I am speaking specifically to what is or will be officially
supported.  The community is free to do whatever it wants outside of
official support, and many people do this already for a number of
boards.  Merely including the package here would imply official
support to the vast majority of users despite any 72pt blinking red
warnings we could put up state otherwise.  This then leads to said
users expecting us to fix their problems.

This position is no different than it's been throughout the life of
this project.  Official support means an active, contributing
developer has access to the hardware and can actively develop
packages and address issues for that target.  The hardware that we
choose to spend our time and money on is our own choice, not a
decision forced upon us.


That seems to be a very reasonable position. If the patch is so simple,
then why don't you maintain it and provide the necessary binary
packages? You should be able to create a custom user repository for your
modifications just like we do for Arch Linux for some kernels.

I expected something like this. And as a matter of fact I plan to 
provide all necessary parts on my webspace. I even plan to compile and 
provide at least all other sunxi based uboot variants.


http://c-reimer.de/alarm/

More will come in a few days. When I have time to write a script to make 
things easier.




--
Andreas

Re: [arch-general] Weird reaction to pull request over at Arch Linux ARM

[ProgAndy]

Am 27.01.2017 um 21:41 schrieb Eli Schwartz via arch-general:

On 01/27/2017 01:27 PM, Christopher Reimer wrote:

I also noticed a few other pull request trying exactly that, which
were instantly closed by Kevin Mihelich without any reasonable
explanation. That's why I expected some resistance and prepared
myself to counterargument a few of his concerns.

And I think I did quite good. Good enough to make him ignore me.

Oh, he's ignoring you? I must be imagining this quote:


I am speaking specifically to what is or will be officially
supported.  The community is free to do whatever it wants outside of
official support, and many people do this already for a number of
boards.  Merely including the package here would imply official
support to the vast majority of users despite any 72pt blinking red
warnings we could put up state otherwise.  This then leads to said
users expecting us to fix their problems.

This position is no different than it's been throughout the life of
this project.  Official support means an active, contributing
developer has access to the hardware and can actively develop
packages and address issues for that target.  The hardware that we
choose to spend our time and money on is our own choice, not a
decision forced upon us.


That seems to be a very reasonable position. If the patch is so simple, 
then why don't you maintain it and provide the necessary binary 
packages? You should be able to create a custom user repository for your 
modifications just like we do for Arch Linux for some kernels.



--
Andreas

Re: [arch-general] Weird reaction to pull request over at Arch Linux ARM

[Yaro Kasear]

On Fri, Jan 27, 2017 at 12:27 PM, Christopher Reimer 
wrote:

> Hello list,
>
> I'd like to get some feedback on this pull request discussion over at Arch
> Linux ARM: https://github.com/archlinuxarm/PKGBUILDs/pull/1444 (Backup:
> http://pastebin.com/x8H0mNiE)
>
> Short summary: I wanted to contribute a simple patch to enable support for
> Banana Pi hardware. I tried that a few years back and got besides some
> other concerns the answer that it cannot be added, because at this time
> there were no upstream support and I accepted that.
>
> This is no longer the case, so I thought it must be possible to add
> support now.
>
> I also noticed a few other pull request trying exactly that, which were
> instantly closed by Kevin Mihelich without any reasonable explanation.
> That's why I expected some resistance and prepared myself to
> counterargument a few of his concerns.
>
> And I think I did quite good. Good enough to make him ignore me.
>
> Why am I writing this to the Arch Linux mailing list? Well, for quite some
> time I thought Arch Linux ARM is Arch Linux. And I think there are a lot
> more out there who think so.
> Therefore I think behavior like this could hurt the overall reputation of
> Arch Linux. Especially if a future goal of Arch Linux might be ARM support
> and Kevin Mihelich somehow joins the team.
>
> Did I miss something? Do I expect too much? I don't know.
>
> Thanks
>
> Christopher Reimer
>

This really has nothing to do with the Arch community.

Arch ARM is its own project. Now, I'm not a TU or a developer, but in my
view trying to complain to an upstream project when downstream doesn't do
what a contributor wants reflects more badly on Arch's reputation.

Even if people on Arch cared, what could they even do about it? Are you
expecting the Arch developers to somehow pull some imaginary authority over
the Archlinux ARM project? That'd be even worse to Arch's reputation if
they though they could just boss around forks of Arch.

The maintainer of a project has zero obligation to take on pull requests.
Complaining to Archlinux users about it won't change it, especially when
his response to your whining on his GitHub page was reasonable.

If you don't like it, feel free to fork Archlinux ARM. Nothing's stopping
you. But stopping filling this list with nonsense and your personal
problems with the developers of projects Arch has nothing to do with.

Yaro

Re: [arch-general] Weird reaction to pull request over at Arch Linux ARM

[Eli Schwartz via arch-general]

On 01/27/2017 01:27 PM, Christopher Reimer wrote:
> I also noticed a few other pull request trying exactly that, which
> were instantly closed by Kevin Mihelich without any reasonable
> explanation. That's why I expected some resistance and prepared
> myself to counterargument a few of his concerns.
> 
> And I think I did quite good. Good enough to make him ignore me.

Oh, he's ignoring you? I must be imagining this quote:

> I am speaking specifically to what is or will be officially
> supported.  The community is free to do whatever it wants outside of
> official support, and many people do this already for a number of
> boards.  Merely including the package here would imply official
> support to the vast majority of users despite any 72pt blinking red
> warnings we could put up state otherwise.  This then leads to said
> users expecting us to fix their problems.
> 
> This position is no different than it's been throughout the life of
> this project.  Official support means an active, contributing
> developer has access to the hardware and can actively develop
> packages and address issues for that target.  The hardware that we
> choose to spend our time and money on is our own choice, not a
> decision forced upon us.

And I see nowhere that you have answered this IMO highly reasonable
objection.

> Why am I writing this to the Arch Linux mailing list? Well, for quite
>  some time I thought Arch Linux ARM is Arch Linux. And I think there
> are a lot more out there who think so. Therefore I think behavior
> like this could hurt the overall reputation of Arch Linux. Especially
> if a future goal of Arch Linux might be ARM support and Kevin
> Mihelich somehow joins the team.

I fail to see how the actions of an unaffiliated dev of a different
project could hurt the Arch Linux reputation, moreso when said actions
are reasonable actions. I especially don't see why you feel the need to
malign the good name of Mr. Mihelich against the future *possibility* of
him joining an official Arch Linux port (which shows far more "ulterior
motives" and "weird reactions" in your own actions than in his).

On the other hand, you are busy giving this mailing list a reputation
for spam. :( We don't care how he slighted you or which neighbor's dog
he may or may not have killed, please direct your personal campaigns
against the person of Mr. Mihelich ELSEWHERE.

> /dev/null

-- 
Eli Schwartz



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Weird reaction to pull request over at Arch Linux ARM

[Bartłomiej Piotrowski]

On 2017-01-27 19:27, Christopher Reimer wrote:
> Therefore I think behavior like this could hurt the overall reputation
> of Arch Linux. Especially if a future goal of Arch Linux might be ARM
> support and Kevin Mihelich somehow joins the team.

Even if, it is an independent project and Kevin has every right to
decide what he wants to spend his time on. Nothing to do there from Arch
perspective.

Bartłomiej

[arch-general] Weird reaction to pull request over at Arch Linux ARM

[Christopher Reimer]

Hello list,

I'd like to get some feedback on this pull request discussion over at 
Arch Linux ARM: https://github.com/archlinuxarm/PKGBUILDs/pull/1444 
(Backup: http://pastebin.com/x8H0mNiE)


Short summary: I wanted to contribute a simple patch to enable support 
for Banana Pi hardware. I tried that a few years back and got besides 
some other concerns the answer that it cannot be added, because at this 
time there were no upstream support and I accepted that.


This is no longer the case, so I thought it must be possible to add 
support now.


I also noticed a few other pull request trying exactly that, which were 
instantly closed by Kevin Mihelich without any reasonable explanation.
That's why I expected some resistance and prepared myself to 
counterargument a few of his concerns.


And I think I did quite good. Good enough to make him ignore me.

Why am I writing this to the Arch Linux mailing list? Well, for quite 
some time I thought Arch Linux ARM is Arch Linux. And I think there are 
a lot more out there who think so.
Therefore I think behavior like this could hurt the overall reputation 
of Arch Linux. Especially if a future goal of Arch Linux might be ARM 
support and Kevin Mihelich somehow joins the team.


Did I miss something? Do I expect too much? I don't know.

Thanks

Christopher Reimer

Re: [arch-general] MariaDB not starting

[Jude DaShiell]

I got the tables built and mariadb.service started but running 
mysql_secure_installation and hitting enter where it asks for the 
password I get error 1045 and there is no root password set for mysql on 
this installation yet.


On Fri, 27 Jan 2017, Peter Nabbefeld wrote:


Date: Fri, 27 Jan 2017 08:07:45
From: Peter Nabbefeld 
Reply-To: General Discussion about Arch Linux 
To: arch-general@archlinux.org
Subject: Re: [arch-general] MariaDB not starting

Am 27.01.2017 um 13:18 schrieb Paul Gideon Dann via arch-general:
On 27 January 2017 at 12:12, Peter Nabbefeld  
wrote:



I've got problems with MariaDB not working.



I think you might want to read the "Installation" section on the Wiki:

https://wiki.archlinux.org/index.php/MySQL#Installation

In particular, I think you forgot to run mysql_install_db.

Cheers,
Paul



Hi Paul,

Thank You - the problem is, that some installation details are missing in the 
German wiki, or just at the wrong place:
I've found what I've been missing in the installation as a hint for possible 
problem solution, not as a necessary install step ...


Kind regards
Peter



--

Re: [arch-general] MariaDB not starting

[Peter Nabbefeld]

Am 27.01.2017 um 13:18 schrieb Paul Gideon Dann via arch-general:

On 27 January 2017 at 12:12, Peter Nabbefeld  wrote:


I've got problems with MariaDB not working.



I think you might want to read the "Installation" section on the Wiki:

https://wiki.archlinux.org/index.php/MySQL#Installation

In particular, I think you forgot to run mysql_install_db.

Cheers,
Paul



Hi Paul,

Thank You - the problem is, that some installation details are missing 
in the German wiki, or just at the wrong place:
I've found what I've been missing in the installation as a hint for 
possible problem solution, not as a necessary install step ...


Kind regards
Peter

[arch-general] command line spreadsheet

[Jude DaShiell]

neoleo is now in the aur and it builds and works as near as I can tell. 
That can be used on command line with the -x option starting it as well as 
in graphical user environments.  It may be an improvement over libreoffice 
calc under orca I'm going to find out about that later.
In the neoleo changelog a pointer to oleo documentation on the web on the 
official gnu site is provided but documentation doesn't yet come packaged 
with this spreadsheet.




--

[arch-general] community/centerim findings

[Jude DaShiell]

1) the key needed to get to the accounts screen after configuration is 
super-d or windows-d for those that don't know what super key is in Linux. 
That is the equivalent of the done button.  It may be necessary to hit 
super-c to change the default configuration and actually write a 
configuration file to your home directory too before hitting super-d.  I'm 
still researching that one.  The man page doesn't describe what files 
centerim creates to support operation but I'll find that one out too.




--

Re: [arch-general] MariaDB not starting

[Jude DaShiell]

Was this start attempt just after mariadb install where the archwiki 
page got used or a start attempt after successful setup?  If the former, 
I had the same bad luck and went with postgresql and got postgresql up 
and running.


On Fri, 27 Jan 2017, Peter Nabbefeld wrote:


Date: Fri, 27 Jan 2017 07:12:20
From: Peter Nabbefeld 
Reply-To: General Discussion about Arch Linux 
To: arch-general@archlinux.org
Subject: [arch-general] MariaDB not starting

Hello,

I've got problems with MariaDB not working.


1) "systemctl status mariadb.service":

? mariadb.service - MariaDB database server
  Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled; vendor 
preset: disabled)
  Active: failed (Result: exit-code) since Fri 2017-01-27 13:04:10 CET; 13s 
ago
 Process: 4574 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER 
$_WSREP_START_POSITION (code=exited, status=1/FAILURE)
 Process: 4519 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && 
VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl 
set-environment _WSREP_START_POSITION=$VAR
 Process: 4517 ExecStartPre=/bin/sh -c systemctl unset-environment 
_WSREP_START_POSITION (code=exited, status=0/SUCCESS)

Main PID: 4574 (code=exited, status=1/FAILURE)

Jan 27 13:04:10 tuchola mysqld[4574]: 2017-01-27 13:04:10 140214454369792 
[Note] Starting crash recovery...
Jan 27 13:04:10 tuchola mysqld[4574]: 2017-01-27 13:04:10 140214454369792 
[Note] Crash recovery finished.
Jan 27 13:04:10 tuchola mysqld[4574]: 2017-01-27 13:04:10 140214454332160 
[Warning] Failed to load slave replication state from table 
mysql.gtid_slave_pos: 1146: Table 'mysql.gtid_slave_pos'
Jan 27 13:04:10 tuchola mysqld[4574]: 2017-01-27 13:04:10 140214454369792 
[ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't 
exist
Jan 27 13:04:10 tuchola mysqld[4574]: 2017-01-27 13:04:10 140214454369792 
[Note] Server socket created on IP: '::'.
Jan 27 13:04:10 tuchola mysqld[4574]: 2017-01-27 13:04:10 140214454369792 
[ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.user' 
doesn't exist
Jan 27 13:04:10 tuchola systemd[1]: mariadb.service: Main process exited, 
code=exited, status=1/FAILURE

Jan 27 13:04:10 tuchola systemd[1]: Failed to start MariaDB database server.
Jan 27 13:04:10 tuchola systemd[1]: mariadb.service: Unit entered failed 
state.
Jan 27 13:04:10 tuchola systemd[1]: mariadb.service: Failed with result 
'exit-code'.



2) "journalctl -xe":

-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel



--

Re: [arch-general] MariaDB not starting

[Paul Gideon Dann via arch-general]

On 27 January 2017 at 12:12, Peter Nabbefeld  wrote:

> I've got problems with MariaDB not working.
>

I think you might want to read the "Installation" section on the Wiki:

https://wiki.archlinux.org/index.php/MySQL#Installation

In particular, I think you forgot to run mysql_install_db.

Cheers,
Paul

Re: [arch-general] MariaDB not starting

[Ismael Bouya]

Hello,

> 1) "systemctl status mariadb.service":
(...)
> Jan 27 13:04:10 tuchola mysqld[4574]: 2017-01-27 13:04:10 140214454369792
> [ERROR] Fatal error: Can't open and lock privilege tables: Table
> 'mysql.user' doesn't exist
(...)

I'm not ssure about what you tried, but your installation seems
incomplete.
Did you run the 
mysql_install_db --user=mysql --basedir=/usr --datadir=/var/lib/mysql
before starting it?

Did you follow the installation instructions there
https://wiki.archlinux.org/index.php/MySQL ?
If not, you should start there maybe :)

Kind regards,
-- 
Ismael


signature.asc
Description: PGP signature

[arch-general] MariaDB not starting

[Peter Nabbefeld]

Hello,

I've got problems with MariaDB not working.


1) "systemctl status mariadb.service":

● mariadb.service - MariaDB database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled; 
vendor preset: disabled)
   Active: failed (Result: exit-code) since Fri 2017-01-27 13:04:10 
CET; 13s ago
  Process: 4574 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS 
$_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE)
  Process: 4519 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery 
] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && 
systemctl set-environment _WSREP_START_POSITION=$VAR
  Process: 4517 ExecStartPre=/bin/sh -c systemctl unset-environment 
_WSREP_START_POSITION (code=exited, status=0/SUCCESS)

 Main PID: 4574 (code=exited, status=1/FAILURE)

Jan 27 13:04:10 tuchola mysqld[4574]: 2017-01-27 13:04:10 
140214454369792 [Note] Starting crash recovery...
Jan 27 13:04:10 tuchola mysqld[4574]: 2017-01-27 13:04:10 
140214454369792 [Note] Crash recovery finished.
Jan 27 13:04:10 tuchola mysqld[4574]: 2017-01-27 13:04:10 
140214454332160 [Warning] Failed to load slave replication state from 
table mysql.gtid_slave_pos: 1146: Table 'mysql.gtid_slave_pos'
Jan 27 13:04:10 tuchola mysqld[4574]: 2017-01-27 13:04:10 
140214454369792 [ERROR] Can't open and lock privilege tables: Table 
'mysql.servers' doesn't exist
Jan 27 13:04:10 tuchola mysqld[4574]: 2017-01-27 13:04:10 
140214454369792 [Note] Server socket created on IP: '::'.
Jan 27 13:04:10 tuchola mysqld[4574]: 2017-01-27 13:04:10 
140214454369792 [ERROR] Fatal error: Can't open and lock privilege 
tables: Table 'mysql.user' doesn't exist
Jan 27 13:04:10 tuchola systemd[1]: mariadb.service: Main process 
exited, code=exited, status=1/FAILURE

Jan 27 13:04:10 tuchola systemd[1]: Failed to start MariaDB database server.
Jan 27 13:04:10 tuchola systemd[1]: mariadb.service: Unit entered failed 
state.
Jan 27 13:04:10 tuchola systemd[1]: mariadb.service: Failed with result 
'exit-code'.



2) "journalctl -xe":

-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit mariadb.service has begun starting up.
Jan 27 13:04:09 tuchola mysqld[4574]: 2017-01-27 13:04:09 
140214454369792 [Note] /usr/sbin/mysqld (mysqld 10.1.21-MariaDB) 
starting as process 4574 ...
Jan 27 13:04:09 tuchola mysqld[4574]: 2017-01-27 13:04:09 
140214454369792 [Note] InnoDB: Using mutexes to ref count buffer pool pages
Jan 27 13:04:09 tuchola mysqld[4574]: 2017-01-27 13:04:09 
140214454369792 [Note] InnoDB: The InnoDB memory heap is disabled
Jan 27 13:04:09 tuchola mysqld[4574]: 2017-01-27 13:04:09 
140214454369792 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
Jan 27 13:04:09 tuchola mysqld[4574]: 2017-01-27 13:04:09 
140214454369792 [Note] InnoDB: GCC builtin __atomic_thread_fence() is 
used for memory barrier
Jan 27 13:04:09 tuchola mysqld[4574]: 2017-01-27 13:04:09 
140214454369792 [Note] InnoDB: Compressed tables use zlib 1.2.11
Jan 27 13:04:09 tuchola mysqld[4574]: 2017-01-27 13:04:09 
140214454369792 [Note] InnoDB: Using Linux native AIO
Jan 27 13:04:09 tuchola mysqld[4574]: 2017-01-27 13:04:09 
140214454369792 [Note] InnoDB: Using SSE crc32 instructions
Jan 27 13:04:09 tuchola mysqld[4574]: 2017-01-27 13:04:09 
140214454369792 [Note] InnoDB: Initializing buffer pool, size = 128.0M
Jan 27 13:04:09 tuchola mysqld[4574]: 2017-01-27 13:04:09 
140214454369792 [Note] InnoDB: Completed initialization of buffer pool
Jan 27 13:04:09 tuchola mysqld[4574]: 2017-01-27 13:04:09 
140214454369792 [Note] InnoDB: Highest supported file format is Barracuda.
Jan 27 13:04:09 tuchola mysqld[4574]: 2017-01-27 13:04:09 
140214454369792 [Note] InnoDB: The log sequence numbers 0 and 0 in 
ibdata files do not match the log sequence number 1600749 in the
Jan 27 13:04:09 tuchola mysqld[4574]: 2017-01-27 13:04:09 
140214454369792 [Note] InnoDB: Database was not shutdown normally!
Jan 27 13:04:09 tuchola mysqld[4574]: 2017-01-27 13:04:09 
140214454369792 [Note] InnoDB: Starting crash recovery.
Jan 27 13:04:09 tuchola mysqld[4574]: 2017-01-27 13:04:09 
140214454369792 [Note] InnoDB: Reading tablespace information from the 
.ibd files...
Jan 27 13:04:09 tuchola mysqld[4574]: 2017-01-27 13:04:09 
140214454369792 [Note] InnoDB: Restoring possible half-written data pages
Jan 27 13:04:09 tuchola mysqld[4574]: 2017-01-27 13:04:09 
140214454369792 [Note] InnoDB: from the doublewrite buffer...
Jan 27 13:04:09 tuchola mysqld[4574]: 2017-01-27 13:04:09 
140214454369792 [Note] InnoDB: 128 rollback segment(s) are active.
Jan 27 13:04:09 tuchola mysqld[4574]: 2017-01-27 13:04:09 
140214454369792 [Note] InnoDB: Waiting for purge to start
Jan 27 13:04:09 tuchola mysqld[4574]: 2017-01-27 13:04:09 
140214454369792 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 
5.6.34-79.1 started; log sequence number 1600749
Jan 27 13:04:10 tuchola mysqld[4574]: 2017-01-27 13:04:10 
140214454369792 [Note] Plugin 'FEEDBACK' is disabled.
Jan 27