On Thu, 2024-08-29 at 18:43 +, Lucie Scarlet wrote:
> Hi,
1) makepkg fail:
the PKGBUILD had unused line
So sorry about that - the downside of "cleaning up" before pushing
... and not testing 😞
Remove the line "install=iwd.install"
or copy the updated version of PKGBUILD
1) gi
On 8/29/24 3:14 PM, Łukasz Michalski wrote:
Hi,
Anyone has a working gitlab installation that uses relative url
(https://host/gitlab) ?
I am new to gitlab and tried to install and configure it using wiki
instructions[1]
Then I followed gitlab instruction how to setup subpath[2]
[...]
[2]
Hi,
So it turns out that I'm still having some issues, so I'm trying this
method.
I'm having quite some trouble with this though.
Firstly, I can't get the sparse-checkout to work.
[lucie@koumakan blog]$ git sparse-checkout init
[lucie@koumakan blog]$ git sparse-checkout set arch-package/iwd-git
Nextcloud does not care about your permissions.
You can try this by creating a file, doing chmod 777 on it and then
syncing on another machine, it will be synced with 644.
Synchronizing permissions "would be bad for security", if you track
down the relevant bug report.
Yes, this is stupid.
Mart
Hello,
I use Nextcloud to keep important files synchronised between my
computers. This works without any problems,
but the folder on the desktop is treated as 777 after every file change.
It affects all folders that are below Public/fr4, which is strange, it
is kept in sync with a second machine
Hi,
Anyone has a working gitlab installation that uses relative url
(https://host/gitlab) ?
I am new to gitlab and tried to install and configure it using wiki
instructions[1]
Then I followed gitlab instruction how to setup subpath[2]
Web interface works. I created empty project and tried t
On Thu, 29 Aug 2024 at 11:09, Edward Toroshchyn
wrote:
>
> Instead, the modern recommendation is to use two-factor authentication and
> to implement password blacklists.
>
> Of course, this is primarily important for managing multiple user
> environments, and if you feel like you should change yo
All,
Sorry for hijacking the thread, just want to make a small correction.
On 29/08/2024 10:53, David C. Rankin wrote:
> I changed my password [...] (as you should do
> every so often).
It is no longer recommended to enforce any periodic password changes. See, e.g.
NIST recommendation[1]:
>
On 8/29/24 4:25 AM, Shulhan wrote:
29 Aug 2024 15:54:17 David C. Rankin :
All,
I changed my password for my username on my Arch server (as you should do
every so often). Now everything has gone to hell.
I changed the password accordingly in Th
29 Aug 2024 15:54:17 David C. Rankin :
All,
I changed my password for my username on my Arch server (as you
should do every so often). Now everything has gone to hell.
I changed the password accordingly in Thunderbird, but it cannot get
mail.
On 8/29/24 3:53 AM, David C. Rankin wrote:
All,
I changed my password for my username on my Arch server (as you should do
every so often). Now everything has gone to hell.
I changed the password accordingly in Thunderbird, but it cannot get mail.
I've restarted sshd, and I still can
Hi David,
> debug1: Connecting to valkyrie [192.168.6.14] port 6661.
...
> debug1: connect to address 192.168.6.14 port 6661: Connection refused
Is sshd listening on that interface and port?
As root, say by using sudo, run:
lsof -i @192.168.6.14:6661
You can drop the :6661 to remove the fil
All,
I changed my password for my username on my Arch server (as you should do
every so often). Now everything has gone to hell.
I changed the password accordingly in Thunderbird, but it cannot get mail.
I've restarted sshd, and I still cannot even connect:
debug3: ssh_connect_direct:
13 matches
Mail list logo
