From somenxavier at posteo.net Sat May 11 01:14:42 2019 From: somenxavier at posteo.net (Xavier B.) Date: Sat, 11 May 2019 00:14:42 +0200 Subject: [artix-general] wpa_supplicant 2.8 causes non-daemon netcfg Message-ID: <20190511001442.8930e279704521c760bc41b2@posteo.net> Hi, I use artix and I have some custom script [1] based on netcfg [2] for connect wlan0 to wifi networks at *background*. All is perfect with wpa_supplicant 2.6-2 package. But when I upgrade to 2.8, I have to wait at boot until wpa_supplicant connects to any of my networks. This annoys obvioysly. Is there any way to know exactly what lines cause this? Thanks in advance, Xavier [1] https://bbs.archlinux.org/viewtopic.php?pid=1489283#p1489283 [2] https://projects.archlinux.org/netcfg.git/ [3] https://wiki.archlinux.org/index.php?title=Netcfg&oldid=243178 PS: Yeah, I know the references are form arch but I migrated from arch to artix a long time ago (I used arch-openrc then) From nous at artixlinux.org Sat May 11 23:36:37 2019 From: nous at artixlinux.org (Christos Nouskas) Date: Sat, 11 May 2019 23:36:37 +0300 Subject: [artix-general] wpa_supplicant 2.8 causes non-daemon netcfg In-Reply-To: <20190511001442.8930e279704521c760bc41b2@posteo.net> References: <20190511001442.8930e279704521c760bc41b2@posteo.net> Message-ID: <20190511233637.a508a7f1720b57f68784d7aa@artixlinux.org> On Sat, 11 May 2019 00:14:42 +0200 "Xavier B. via artix-general" wrote: > I use artix and I have some custom script [1] based on netcfg [2] for connect wlan0 to wifi networks at *background*. All is perfect with wpa_supplicant 2.6-2 package. But when I upgrade to 2.8, I have to wait at boot until wpa_supplicant connects to any of my networks. # rc-service -d -v net-auto-wireless restart It should show you which part causes the delay, if you watch the output. -- Christos Nouskas https://systemd-free.artixlinux.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From somenxavier at posteo.net Mon May 13 18:35:55 2019 From: somenxavier at posteo.net (Xavier) Date: Mon, 13 May 2019 15:35:55 +0000 Subject: [artix-general] =?utf-8?q?wpa=5Fsupplicant_2=2E8_causes_non-daem?= =?utf-8?q?on_netcfg?= In-Reply-To: <20190511233637.a508a7f1720b57f68784d7aa@artixlinux.org> References: <20190511001442.8930e279704521c760bc41b2@posteo.net> <20190511233637.a508a7f1720b57f68784d7aa@artixlinux.org> Message-ID: <9c62c172e8f56946ef63973c896d0707@posteo.net> They are identical: I run # rc-service -d -v net-auto-wireless restart > output.wpa_supplicant.2.6.txt # rc-service -d -v net-auto-wireless restart 2> output.wpa_supplicant.errors.2.6.txt pacman -S wpa_suplicant (installing 2.8) # rc-service -d -v net-auto-wireless restart > output.wpa_supplicant.2.8.txt # rc-service -d -v net-auto-wireless restart 2> output.wpa_supplicant.errors.2.8.txt and the diff gets me nothing relevant: $ diff output.wpa_supplicant.errors.2.6.txt output.wpa_supplicant.errors.2.8.txt 425d424 < ++ printf '%s\n' 426a426 > ++ printf '%s\n' 486c486 < + grep -qx 5083 /sys/fs/cgroup/unified/net-auto-wireless/cgroup.procs --- > + grep -qx 5490 /sys/fs/cgroup/unified/net-auto-wireless/cgroup.procs 699c699 < + grep -qx 5259 /sys/fs/cgroup/unified/net-auto-wireless/cgroup.procs --- > + grep -qx 5665 /sys/fs/cgroup/unified/net-auto-wireless/cgroup.procs 958c958 < + grep -qx 5328 /sys/fs/cgroup/unified/netmount/cgroup.procs --- > + grep -qx 5736 /sys/fs/cgroup/unified/netmount/cgroup.procs [xan at argonia ~]$ diff output.wpa_supplicant.2.6.txt output.wpa_supplicant.2.8.txt [xan at argonia ~]$ So, what's the point here? Thanks in advance, Xavier A 11.05.2019 20:36, Christos Nouskas escrigu?: > On Sat, 11 May 2019 00:14:42 +0200 > "Xavier B. via artix-general" wrote: > >> I use artix and I have some custom script [1] based on netcfg [2] for >> connect wlan0 to wifi networks at *background*. All is perfect with >> wpa_supplicant 2.6-2 package. But when I upgrade to 2.8, I have to >> wait at boot until wpa_supplicant connects to any of my networks. > > # rc-service -d -v net-auto-wireless restart > > It should show you which part causes the delay, if you watch the > output. From nous at artixlinux.org Tue May 14 22:09:24 2019 From: nous at artixlinux.org (Christos Nouskas) Date: Tue, 14 May 2019 22:09:24 +0300 Subject: [artix-general] wpa_supplicant 2.8 causes non-daemon netcfg In-Reply-To: <9c62c172e8f56946ef63973c896d0707@posteo.net> References: <20190511001442.8930e279704521c760bc41b2@posteo.net> <20190511233637.a508a7f1720b57f68784d7aa@artixlinux.org> <9c62c172e8f56946ef63973c896d0707@posteo.net> Message-ID: <20190514220924.77289b2106f4461136cb5f91@artixlinux.org> On Mon, 13 May 2019 15:35:55 +0000 Xavier wrote: > They are identical: > I run > # rc-service -d -v net-auto-wireless restart > > output.wpa_supplicant.2.6.txt > # rc-service -d -v net-auto-wireless restart 2> > output.wpa_supplicant.errors.2.6.txt MAybe I wasn't clear; I suggested you *watch* net-auto-wireless restart in debug mode and note which part causes the delay. That way it (should) be easier to track down the problem. -- Christos Nouskas https://systemd-free.artixlinux.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From somenxavier at posteo.net Wed May 15 19:57:08 2019 From: somenxavier at posteo.net (Xavier) Date: Wed, 15 May 2019 16:57:08 +0000 Subject: [artix-general] =?utf-8?q?wpa=5Fsupplicant_2=2E8_causes_non-daem?= =?utf-8?q?on_netcfg?= In-Reply-To: <20190514220924.77289b2106f4461136cb5f91@artixlinux.org> References: <20190511001442.8930e279704521c760bc41b2@posteo.net> <20190511233637.a508a7f1720b57f68784d7aa@artixlinux.org> <9c62c172e8f56946ef63973c896d0707@posteo.net> <20190514220924.77289b2106f4461136cb5f91@artixlinux.org> Message-ID: How can I do that? If there is no difference between two "watches": one with 2.6 and another with 2.8? Many thanks A 14.05.2019 19:09, Christos Nouskas escrigu?: > On Mon, 13 May 2019 15:35:55 +0000 > Xavier wrote: > >> They are identical: >> I run >> # rc-service -d -v net-auto-wireless restart > >> output.wpa_supplicant.2.6.txt >> # rc-service -d -v net-auto-wireless restart 2> >> output.wpa_supplicant.errors.2.6.txt > > MAybe I wasn't clear; I suggested you *watch* net-auto-wireless > restart in debug mode and note which part causes the delay. That way > it (should) be easier to track down the problem. From nous at artixlinux.org Sat May 18 13:32:27 2019 From: nous at artixlinux.org (Christos Nouskas) Date: Sat, 18 May 2019 13:32:27 +0300 Subject: [artix-general] wpa_supplicant 2.8 causes non-daemon netcfg In-Reply-To: References: <20190511001442.8930e279704521c760bc41b2@posteo.net> <20190511233637.a508a7f1720b57f68784d7aa@artixlinux.org> <9c62c172e8f56946ef63973c896d0707@posteo.net> <20190514220924.77289b2106f4461136cb5f91@artixlinux.org> Message-ID: <20190518133227.9a90ee1e21a30d6079d0ce10@artixlinux.org> On Wed, 15 May 2019 16:57:08 +0000 Xavier wrote: > How can I do that? If there is no difference between two "watches": one > with 2.6 and another with 2.8? > > > MAybe I wasn't clear; I suggested you *watch* net-auto-wireless > > restart in debug mode and note which part causes the delay. That way > > it (should) be easier to track down the problem. Sorry for the late response, extremely busy here. Starting the service in debug mode shows which part of the netcfg script is run. Since netcfg with wpa_supp-2.8 causes delay, I suppose you could just see with your own eyes the exact part that causes the delay. With 2.6, service start is instantaneous and you'll only see debug text fly along the screen; with 2.8 however, the output will stop for some time at the problematic part and you can make a note of it (or press a few times to make space and find it easily at the terminal's scrollback buffer). HTH. -- Christos Nouskas https://systemd-free.artixlinux.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From nous at artixlinux.org Sun May 19 11:16:47 2019 From: nous at artixlinux.org (Christos Nouskas) Date: Sun, 19 May 2019 11:16:47 +0300 Subject: [artix-general] New KDE Plasma / LXQt ISO Message-ID: <20190519111647.94ca5e642db6288822882c04@artixlinux.org> Hi, everyone, A new community ISO featuring the KDE Plasma and LXQt desktops is available for download and testing. The calamares installer has been updated and seems to correctly install a fully encrypted system (/boot included). This release features a uniform dark QT/GTK look, a switch to connman instead of networkmanager, a pacman frontend (octopi), an iptables helper (gufw), multimedia and office apps. By default it boots into LXQt, you have to logout and relogin to Plasma (user: artix - pass: artix). Known issues: some widgets (like digital clock in plasma), have got hardcoded colours in their settings windows and can't be configured as they are; one has to change the theme to a lighter one first and revert. Please test and report any errors, omissions or wishes. If no major ones are reported, we'll make a broader announcement at the site. An updated MATE/LXDE image is also approaching. http://andromeda.artixlinux.org:55555/artix-plasma-lxqt-openrc-20190519-x86_64.iso http://andromeda.artixlinux.org:55555/artix-plasma-lxqt-openrc-20190519-x86_64.sha256 (sha256sum 613677cda469bf6591c9474e234cf555063366b5794ef925783df4b099d031d57) -- Christos Nouskas https://systemd-free.artixlinux.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From fungilife at protonmail.com Mon May 20 08:28:48 2019 From: fungilife at protonmail.com (Fungi4All) Date: Mon, 20 May 2019 05:28:48 +0000 Subject: [artix-general] New KDE Plasma / LXQt ISO In-Reply-To: <20190519111647.94ca5e642db6288822882c04@artixlinux.org> References: <20190519111647.94ca5e642db6288822882c04@artixlinux.org> Message-ID: On Sunday, May 19, 2019 11:16 AM, Christos Nouskas via artix-general wrote: > Hi, everyone, > > A new community ISO featuring the KDE Plasma and LXQt desktops is available for download and testing. The calamares installer has been updated and seems to correctly install a fully encrypted system (/boot included). > This release features a uniform dark QT/GTK look, a switch to connman instead of networkmanager, a pacman frontend (octopi), an iptables helper (gufw), multimedia and office apps. By default it boots into LXQt, you have to logout and relogin to Plasma (user: artix - pass: artix). > > Known issues: some widgets (like digital clock in plasma), have got hardcoded colours in their settings windows and can't be configured as they are; one has to change the theme to a lighter one first and revert. > > Please test and report any errors, omissions or wishes. If no major ones are reported, we'll make a broader announcement at the site. An updated MATE/LXDE image is also approaching. Congrats, for whatever you do. Just don't expect any cheering for Gnome/Cinnamon editions :D 1 Some of those complicated desktops seem to want dbus running at the user level to work well. I never got too familiar with OpenRC to know how to do this but if there is a way I'd like to know. 2 Are those DE setups functional if you switch to Runit? 3 My previous announcement of your community MATE edition seemed to stimulate some interest in sysdfree.wordpress.com and also in the reddit communities. I hope you don't mind the publicity. One redditor said he installed Mate and liked it for a daily runner. rust From p3d3f at riseup.net Mon May 20 10:44:25 2019 From: p3d3f at riseup.net (P3d3.F.) Date: Mon, 20 May 2019 09:44:25 +0200 Subject: [artix-general] New KDE Plasma / LXQt ISO In-Reply-To: <20190519111647.94ca5e642db6288822882c04@artixlinux.org> References: <20190519111647.94ca5e642db6288822882c04@artixlinux.org> Message-ID: <200e6374-1020-83ce-e3ce-d61c2626675f@riseup.net> Hi, I'm trying to install the new version, but I'm stopped in a terminal session with the system asking me username and password. I use 'artix' 'artix' but nothing, login incorrect, is the system answer. DELL 5770, i7, 16 GB RAM, AMD 350GPU plus the integrated Intel. Now installed with Artix-KDE. I retry on another Notebook. On 5/19/19 10:16 AM, Christos Nouskas via artix-general wrote: > Hi, everyone, > > A new community ISO featuring the KDE Plasma and LXQt desktops is available for download and testing. The calamares installer has been updated and seems to correctly install a fully encrypted system (/boot included). > This release features a uniform dark QT/GTK look, a switch to connman instead of networkmanager, a pacman frontend (octopi), an iptables helper (gufw), multimedia and office apps. By default it boots into LXQt, you have to logout and relogin to Plasma (user: artix - pass: artix). > > Known issues: some widgets (like digital clock in plasma), have got hardcoded colours in their settings windows and can't be configured as they are; one has to change the theme to a lighter one first and revert. > > Please test and report any errors, omissions or wishes. If no major ones are reported, we'll make a broader announcement at the site. An updated MATE/LXDE image is also approaching. > > http://andromeda.artixlinux.org:55555/artix-plasma-lxqt-openrc-20190519-x86_64.iso > http://andromeda.artixlinux.org:55555/artix-plasma-lxqt-openrc-20190519-x86_64.sha256 > (sha256sum 613677cda469bf6591c9474e234cf555063366b5794ef925783df4b099d031d57) > > -- P3d3f Mail: p3d3f at riseup.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From p3d3f at riseup.net Mon May 20 11:21:31 2019 From: p3d3f at riseup.net (P3d3.F.) Date: Mon, 20 May 2019 10:21:31 +0200 Subject: [artix-general] New KDE Plasma / LXQt ISO In-Reply-To: <20190519111647.94ca5e642db6288822882c04@artixlinux.org> References: <20190519111647.94ca5e642db6288822882c04@artixlinux.org> Message-ID: <4d409f82-412a-1a71-8fcf-099b0a02b0bb@riseup.net> To be sure I verified also the sha256sum of the iso: correct, remastered the USB key (Imagewriter), and booted on another notebook. The effect is the same: stopped in a terminal with "login incorrect" using 'artix' 'artix'. This Notebook use a pre UEFI boot system, its a DELL 9400, Intel core Due Duo, 4 Gb RAM, SSD 256Gb, Nvidia GEForce 7950 GTX and work correctly with Artix LXQT or MXLinux (it depends from the booting HD, to change the boot HD is very simple with this "old" notebook). On 5/19/19 10:16 AM, Christos Nouskas via artix-general wrote: > Hi, everyone, > > A new community ISO featuring the KDE Plasma and LXQt desktops is available for download and testing. The calamares installer has been updated and seems to correctly install a fully encrypted system (/boot included). > This release features a uniform dark QT/GTK look, a switch to connman instead of networkmanager, a pacman frontend (octopi), an iptables helper (gufw), multimedia and office apps. By default it boots into LXQt, you have to logout and relogin to Plasma (user: artix - pass: artix). > > Known issues: some widgets (like digital clock in plasma), have got hardcoded colours in their settings windows and can't be configured as they are; one has to change the theme to a lighter one first and revert. > > Please test and report any errors, omissions or wishes. If no major ones are reported, we'll make a broader announcement at the site. An updated MATE/LXDE image is also approaching. > > http://andromeda.artixlinux.org:55555/artix-plasma-lxqt-openrc-20190519-x86_64.iso > http://andromeda.artixlinux.org:55555/artix-plasma-lxqt-openrc-20190519-x86_64.sha256 > (sha256sum 613677cda469bf6591c9474e234cf555063366b5794ef925783df4b099d031d57) > > -- P3d3f Mail: p3d3f at riseup.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From nous at artixlinux.org Mon May 20 16:25:32 2019 From: nous at artixlinux.org (Christos Nouskas) Date: Mon, 20 May 2019 16:25:32 +0300 Subject: [artix-general] New KDE Plasma / LXQt ISO In-Reply-To: <4d409f82-412a-1a71-8fcf-099b0a02b0bb@riseup.net> References: <20190519111647.94ca5e642db6288822882c04@artixlinux.org> <4d409f82-412a-1a71-8fcf-099b0a02b0bb@riseup.net> Message-ID: <20190520162532.6089919c3fa0ccfdc97a8efb@artixlinux.org> On Mon, 20 May 2019 10:21:31 +0200 "P3d3.F. via artix-general" wrote: > To be sure I verified also the sha256sum of the iso: correct, remastered > the USB key (Imagewriter), and booted on another notebook. My local copy has got a different checksum, damn it. Pulling it down and re-uploading. Sorry, everyone. -- Christos Nouskas https://systemd-free.artixlinux.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From nous at artixlinux.org Wed May 22 00:22:05 2019 From: nous at artixlinux.org (Christos Nouskas) Date: Wed, 22 May 2019 00:22:05 +0300 Subject: [artix-general] New KDE Plasma / LXQt ISO In-Reply-To: <20190520162532.6089919c3fa0ccfdc97a8efb@artixlinux.org> References: <20190519111647.94ca5e642db6288822882c04@artixlinux.org> <4d409f82-412a-1a71-8fcf-099b0a02b0bb@riseup.net> <20190520162532.6089919c3fa0ccfdc97a8efb@artixlinux.org> Message-ID: <20190522002205.6c7482bd50b45ff37b155f1a@artixlinux.org> http://andromeda.artixlinux.org:55555/artix-plasma-lxqt-openrc-20190519-x86_64.iso sha256sum: af3dd4d79e0a2534442c4b7be86a639e92c7e4a1269a6191ba18c9bc24349987 -- Christos Nouskas https://systemd-free.artixlinux.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From p3d3f at riseup.net Wed May 22 17:29:45 2019 From: p3d3f at riseup.net (P3d3.F.) Date: Wed, 22 May 2019 16:29:45 +0200 Subject: [artix-general] New KDE Plasma / LXQt ISO In-Reply-To: <20190522002205.6c7482bd50b45ff37b155f1a@artixlinux.org> References: <20190519111647.94ca5e642db6288822882c04@artixlinux.org> <4d409f82-412a-1a71-8fcf-099b0a02b0bb@riseup.net> <20190520162532.6089919c3fa0ccfdc97a8efb@artixlinux.org> <20190522002205.6c7482bd50b45ff37b155f1a@artixlinux.org> Message-ID: Hi All, I tried this iso, only one test by now, and all is almost fine. After some hours of use I found only 4 points (The first, IMHO critical). Obviously I installed an encrypted disk (btrfs). 1) After the system update mkinitcpio started and there wasn't the "encrypt" in the mkinitcpio.conf hooks list. Without this parameter the system boot but don't open the encrypted disk; 2) in systemsettings Regional Settings --> Spell Check --> is defined the Hebrew language and is not possible to Add other languages. I think its Hebrew, my son know Hebrew... :-) 3) I'm not able to connect to Samba devices on the network with Plasma/Dolphin, while all work perfectly with LXQT/PCMAN; obviously the same smb.conf. After some tests (all the Samba components are installed and running) I discover that writing the address of the smb device in the command bar of Dolphin, for me smb://nas/, all work fine. Don't work the "click and point" connections 4) I'm not able to configure Dolphin to work with a single click of the mouse. All is setted to use a single click but nothing... Dolphin resist. This is really a new behaviour for me: never seen before. That's all by now. I tested all on a Core Due Duo Notebook (DELL Inspiron 9400) and it works like a charms, without problem also with hard activities: to look a H265 Video. I hope to be able, later or tomorrow morning, to do a second test installation on a different PC with UEFI boot. GREAT Work and Compliments!!! Frank On 5/21/19 11:22 PM, Christos Nouskas via artix-general wrote: > http://andromeda.artixlinux.org:55555/artix-plasma-lxqt-openrc-20190519-x86_64.iso > sha256sum: af3dd4d79e0a2534442c4b7be86a639e92c7e4a1269a6191ba18c9bc24349987 > > > -- P3d3f Mobile1: +39-366-4xxxxxx Mail: p3d3f at riseup.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From p3d3f at riseup.net Thu May 23 12:55:45 2019 From: p3d3f at riseup.net (P3d3.F.) Date: Thu, 23 May 2019 11:55:45 +0200 Subject: [artix-general] New KDE Plasma / LXQt ISO In-Reply-To: References: <20190519111647.94ca5e642db6288822882c04@artixlinux.org> <4d409f82-412a-1a71-8fcf-099b0a02b0bb@riseup.net> <20190520162532.6089919c3fa0ccfdc97a8efb@artixlinux.org> <20190522002205.6c7482bd50b45ff37b155f1a@artixlinux.org> Message-ID: Hi All, I continue the test and I confirm the "problems" of the previous mail, with the exclusion of the number 3). I think its not a problem of the installation, but something related with Dolphin. Adding the connection to the Nas in the left bar of Dolphin and editing the correct address (for me smb://nas/) all work correctly. I did a test also on other 2 PCs (up and running with KDE/Plasma) and the result is the same. On 5/22/19 4:29 PM, P3d3.F. via artix-general wrote: > > Hi All, > > I tried this iso, only one test by now, and all is almost fine. After > some hours of use I found only 4 points (The first, IMHO critical). > Obviously I installed an encrypted disk (btrfs). > > 1) After the system update mkinitcpio started and there wasn't the > "encrypt" in the mkinitcpio.conf hooks list. Without this parameter > the system boot but don't open the encrypted disk; > > 2) in systemsettings Regional Settings --> Spell Check --> is defined > the Hebrew language and is not possible to Add other languages. I > think its Hebrew, my son know Hebrew... :-) > > 3) I'm not able to connect to Samba devices on the network with > Plasma/Dolphin, while all work perfectly with LXQT/PCMAN; obviously > the same smb.conf. After some tests (all the Samba components are > installed and running) I discover that writing the address of the smb > device in the command bar of Dolphin, for me smb://nas/, all work > fine. Don't work the "click and point" connections > > 4) I'm not able to configure Dolphin to work with a single click of > the mouse. All is setted to use a single click but nothing... Dolphin > resist. This is really a new behaviour for me: never seen before. > > That's all by now. I tested all on a Core Due Duo Notebook (DELL > Inspiron 9400) and it works like a charms, without problem also with > hard activities: to look a H265 Video. > > I hope to be able, later or tomorrow morning, to do a second test > installation on a different PC with UEFI boot. > > GREAT Work and Compliments!!! > > Frank > > On 5/21/19 11:22 PM, Christos Nouskas via artix-general wrote: >> http://andromeda.artixlinux.org:55555/artix-plasma-lxqt-openrc-20190519-x86_64.iso >> sha256sum: af3dd4d79e0a2534442c4b7be86a639e92c7e4a1269a6191ba18c9bc24349987 >> >> >> > -- > P3d3f > > Mobile1: +39-366-4xxxxxx > Mail:p3d3f at riseup.net > -- P3d3f Mobile1: +39-366-4xxxxxxMail: p3d3f at riseup.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ovf at mm.st Thu May 23 13:19:08 2019 From: ovf at mm.st (ovf) Date: Thu, 23 May 2019 11:19:08 +0100 Subject: [artix-general] CONFIG_USERFAULTFD Message-ID: The userfaultfd mechanism? has been around for a while and though enabled in rhel/centos? and others, is disabled both in arch? and artix kernels. Is there a particular reason it isn't? If not, I'd like to request enabling CONFIG_USERFAULTFD for the artix kernel. Thanks 0 https://www.kernel.org/doc/Documentation/vm/userfaultfd.txt 1 https://git.centos.org/rpms/kernel/blob/c7/f/SOURCES/kernel-3.10.0-x86_64.config#_225 2 https://git.archlinux.org/svntogit/packages.git/tree/trunk/config?h=packages/linux#n223 From nous at artixlinux.org Thu May 23 23:29:24 2019 From: nous at artixlinux.org (Christos Nouskas) Date: Thu, 23 May 2019 23:29:24 +0300 Subject: [artix-general] New KDE Plasma / LXQt ISO In-Reply-To: References: <20190519111647.94ca5e642db6288822882c04@artixlinux.org> <4d409f82-412a-1a71-8fcf-099b0a02b0bb@riseup.net> <20190520162532.6089919c3fa0ccfdc97a8efb@artixlinux.org> <20190522002205.6c7482bd50b45ff37b155f1a@artixlinux.org> Message-ID: <20190523232924.268a7bc0daecf3cf4e1a67ed@artixlinux.org> On Thu, 23 May 2019 11:55:45 +0200 "P3d3.F. via artix-general" wrote: > Hi All, > > I continue the test and I confirm the "problems" of the previous mail, > with the exclusion of the number 3). I think its not a problem of the > installation, but something related with Dolphin. Adding the connection > to the Nas in the left bar of Dolphin and editing the correct address > (for me smb://nas/) all work correctly. I did a test also on other 2 PCs > (up and running with KDE/Plasma) and the result is the same. > > On 5/22/19 4:29 PM, P3d3.F. via artix-general wrote: > > > > Hi All, > > > > I tried this iso, only one test by now, and all is almost fine. After > > some hours of use I found only 4 points (The first, IMHO critical). > > Obviously I installed an encrypted disk (btrfs). > > > > 1) After the system update mkinitcpio started and there wasn't the > > "encrypt" in the mkinitcpio.conf hooks list. Without this parameter > > the system boot but don't open the encrypted disk; > > > > 2) in systemsettings Regional Settings --> Spell Check --> is defined > > the Hebrew language and is not possible to Add other languages. I > > think its Hebrew, my son know Hebrew... :-) > > > > 3) I'm not able to connect to Samba devices on the network with > > Plasma/Dolphin, while all work perfectly with LXQT/PCMAN; obviously > > the same smb.conf. After some tests (all the Samba components are > > installed and running) I discover that writing the address of the smb > > device in the command bar of Dolphin, for me smb://nas/, all work > > fine. Don't work the "click and point" connections > > > > 4) I'm not able to configure Dolphin to work with a single click of > > the mouse. All is setted to use a single click but nothing... Dolphin > > resist. This is really a new behaviour for me: never seen before. > > > > That's all by now. I tested all on a Core Due Duo Notebook (DELL > > Inspiron 9400) and it works like a charms, without problem also with > > hard activities: to look a H265 Video. > > > > I hope to be able, later or tomorrow morning, to do a second test > > installation on a different PC with UEFI boot. > > > > GREAT Work and Compliments!!! Thanks for your extensive testing and reporting! The hebrew default in spellchecking is probably a fallback default, set by the respective module developer, when no dictionary is installed in the system (I haven't planted any, perhaps I should put a few). Try installing "hunspell-it" and you should see 'Italiano' in KDE spellchecking. To set single-click-to-open use qt5ct -> tab "Interface" -> "Activate item on single click". You might need to exit dolphin and relaunch it. I couldn't make dolphin auto-discover samba shares (MATE guy here). Perhaps someone more versed in Plasma could lend a helping hand. I'll be updating the ISO configuration soon to fix the crypt setup issue. In the meantime, you should add the 'encrypt' to HOOKS and /crypto-keyfile.bin to FILES in /etc/mkinitcpio.conf and (to avoid inputting the passphrase twice) 'cryptkey=rootfs:/crypto_keyfile.bin' to /boot/grub/grub.cfg's linux kernel line, or to /etc/defaults/grub -> GRUB_CMDLINE_LINUX array and re-run grub-mkconfig. Again, thanks for your testing and reporting. -- Christos Nouskas https://systemd-free.artixlinux.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From p3d3f at riseup.net Fri May 24 09:48:32 2019 From: p3d3f at riseup.net (P3d3.F.) Date: Fri, 24 May 2019 08:48:32 +0200 Subject: [artix-general] New KDE Plasma / LXQt ISO In-Reply-To: <20190523232924.268a7bc0daecf3cf4e1a67ed@artixlinux.org> References: <20190519111647.94ca5e642db6288822882c04@artixlinux.org> <4d409f82-412a-1a71-8fcf-099b0a02b0bb@riseup.net> <20190520162532.6089919c3fa0ccfdc97a8efb@artixlinux.org> <20190522002205.6c7482bd50b45ff37b155f1a@artixlinux.org> <20190523232924.268a7bc0daecf3cf4e1a67ed@artixlinux.org> Message-ID: <9c9e6895-887a-735b-4f03-bb8fafb2a0b9@riseup.net> Thank's for the advice, specially for qt5ct. Now I want to understand why it work, now dolphin behaviour is fine, and systemsettings don't. I never used it since now, but now I must understand :-) About the encrypt hook, I added it manually, obviously. I'll wait the iso with the correction, to start the remote installation on user's notebook. About Samba and Dolphin, no problem, I found a workaround and, in my opinion,m its a Dolphin issue: all work fine with other file manager (I tried LXQT and XFCE). Forgive me about the vocabularies, I forget that before I must install vocabularies :-) I find other little issue, mainly related with the aesthetical aspect, but before I must test better how it work. Note: Dolphin, in LXQT, worked perfectly, with a single click, before any qt5ct intervention: strange :-) Another time my compliments: great work!? Frank PS: when the new iso will be ready, maybe a good idea to send a bip to Distrowatch and to get a little advertising... :-)))))) On 5/23/19 10:29 PM, Christos Nouskas wrote: > On Thu, 23 May 2019 11:55:45 +0200 > "P3d3.F. via artix-general" wrote: > >> Hi All, >> >> I continue the test and I confirm the "problems" of the previous mail, >> with the exclusion of the number 3). I think its not a problem of the >> installation, but something related with Dolphin. Adding the connection >> to the Nas in the left bar of Dolphin and editing the correct address >> (for me smb://nas/) all work correctly. I did a test also on other 2 PCs >> (up and running with KDE/Plasma) and the result is the same. >> >> On 5/22/19 4:29 PM, P3d3.F. via artix-general wrote: >>> Hi All, >>> >>> I tried this iso, only one test by now, and all is almost fine. After >>> some hours of use I found only 4 points (The first, IMHO critical). >>> Obviously I installed an encrypted disk (btrfs). >>> >>> 1) After the system update mkinitcpio started and there wasn't the >>> "encrypt" in the mkinitcpio.conf hooks list. Without this parameter >>> the system boot but don't open the encrypted disk; >>> >>> 2) in systemsettings Regional Settings --> Spell Check --> is defined >>> the Hebrew language and is not possible to Add other languages. I >>> think its Hebrew, my son know Hebrew... :-) >>> >>> 3) I'm not able to connect to Samba devices on the network with >>> Plasma/Dolphin, while all work perfectly with LXQT/PCMAN; obviously >>> the same smb.conf. After some tests (all the Samba components are >>> installed and running) I discover that writing the address of the smb >>> device in the command bar of Dolphin, for me smb://nas/, all work >>> fine. Don't work the "click and point" connections >>> >>> 4) I'm not able to configure Dolphin to work with a single click of >>> the mouse. All is setted to use a single click but nothing... Dolphin >>> resist. This is really a new behaviour for me: never seen before. >>> >>> That's all by now. I tested all on a Core Due Duo Notebook (DELL >>> Inspiron 9400) and it works like a charms, without problem also with >>> hard activities: to look a H265 Video. >>> >>> I hope to be able, later or tomorrow morning, to do a second test >>> installation on a different PC with UEFI boot. >>> >>> GREAT Work and Compliments!!! > Thanks for your extensive testing and reporting! > > The hebrew default in spellchecking is probably a fallback default, set by the respective module developer, when no dictionary is installed in the system (I haven't planted any, perhaps I should put a few). Try installing "hunspell-it" and you should see 'Italiano' in KDE spellchecking. > > To set single-click-to-open use qt5ct -> tab "Interface" -> "Activate item on single click". You might need to exit dolphin and relaunch it. > > I couldn't make dolphin auto-discover samba shares (MATE guy here). Perhaps someone more versed in Plasma could lend a helping hand. > > I'll be updating the ISO configuration soon to fix the crypt setup issue. In the meantime, you should add the 'encrypt' to HOOKS and /crypto-keyfile.bin to FILES in /etc/mkinitcpio.conf and (to avoid inputting the passphrase twice) 'cryptkey=rootfs:/crypto_keyfile.bin' to /boot/grub/grub.cfg's linux kernel line, or to /etc/defaults/grub -> GRUB_CMDLINE_LINUX array and re-run grub-mkconfig. > > Again, thanks for your testing and reporting. > -- P3d3f Mobile1: +39-366-4xxxxxx Mail: p3d3f at riseup.net From nous at artixlinux.org Fri May 24 16:51:36 2019 From: nous at artixlinux.org (Christos Nouskas) Date: Fri, 24 May 2019 16:51:36 +0300 Subject: [artix-general] New KDE Plasma / LXQt ISO In-Reply-To: <9c9e6895-887a-735b-4f03-bb8fafb2a0b9@riseup.net> References: <20190519111647.94ca5e642db6288822882c04@artixlinux.org> <4d409f82-412a-1a71-8fcf-099b0a02b0bb@riseup.net> <20190520162532.6089919c3fa0ccfdc97a8efb@artixlinux.org> <20190522002205.6c7482bd50b45ff37b155f1a@artixlinux.org> <20190523232924.268a7bc0daecf3cf4e1a67ed@artixlinux.org> <9c9e6895-887a-735b-4f03-bb8fafb2a0b9@riseup.net> Message-ID: <20190524165136.78a16a05c3d97eaa8ccc8a4e@artixlinux.org> On Fri, 24 May 2019 08:48:32 +0200 "P3d3.F." wrote: > Thank's for the advice, specially for qt5ct. Now I want to understand > why it work, now dolphin behaviour is fine, and systemsettings don't. I > never used it since now, but now I must understand :-) It's used as a layer for uniform QT/GTK look. It seems to override some KDE settings. > Forgive me about the vocabularies, I forget that before I must install > vocabularies :-) I put en_US in the ISO, to give a hint about that. > I find other little issue, mainly related with the aesthetical aspect, > but before I must test better how it work. An ISO with the fixes will be uploaded and announced in the weekend, hopefully. Another anonymous tester made very insightful suggestions and I tried to implement most of them. One I particularly liked was creating udev rules that set the kernel I/O scheduler according to the disk type (rotational or solid state), as per the Arch wiki article. However, I believe we're reaching Ubuntu levels of intervention to users' systems, even for community ISOs, and we should not tweak any further. Artix branding with a few sane defaults ought to be enough for our intended audience. -- Christos Nouskas https://systemd-free.artixlinux.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From p3d3f at riseup.net Fri May 24 18:08:26 2019 From: p3d3f at riseup.net (P3d3.F.) Date: Fri, 24 May 2019 17:08:26 +0200 Subject: [artix-general] New KDE Plasma / LXQt ISO In-Reply-To: <20190524165136.78a16a05c3d97eaa8ccc8a4e@artixlinux.org> References: <20190519111647.94ca5e642db6288822882c04@artixlinux.org> <4d409f82-412a-1a71-8fcf-099b0a02b0bb@riseup.net> <20190520162532.6089919c3fa0ccfdc97a8efb@artixlinux.org> <20190522002205.6c7482bd50b45ff37b155f1a@artixlinux.org> <20190523232924.268a7bc0daecf3cf4e1a67ed@artixlinux.org> <9c9e6895-887a-735b-4f03-bb8fafb2a0b9@riseup.net> <20190524165136.78a16a05c3d97eaa8ccc8a4e@artixlinux.org> Message-ID: <83316b41-ed9d-57d4-9a89-1335743ead43@riseup.net> About the udev rules and HD, there is another udev rules that I implement, specially with the WD hd and generally with the SMART HD (not for SSD), to avoid an excessive use of the disk and to broke it: the <193 Load_Cycle_Count> SMART capabilities. If active it "overwork" the HD and the risk is to have it to crash in a year... I use this parameters: ACTION=="add", SUBSYSTEM=="block", KERNEL=="sdX", RUN+="/usr/bin/hdparm -B 255 -S 200 /dev/sdX" created into the files: /etc/udev/rules.d/50-hdparm.rules. Obviously with hdparm installed I found also another "small" problem with old PC using old NVIDIA card, I've also a notebook with a GEForce 7950. These old graphics card are no longer supported in Arch (304xx driver) and with nouveau there are a lot of problems with Plasma (!!!) and its practically unusable. I solved all adding the file a.sh in .config/plasma-workspace/env, adding it to the startup with the option Before the system startup with the parameters: export KWIN_COMPOSE=O1 export KWIN_EXPLICIT_SYNC=0 export KWIN_TRIPLE_BUFFER=1 export KWIN_DIRECT_GL=1 and all work like a charms: I'm able to see H265 movie with a so old Notebook (Dell Inspiron 9400). Anyway: I appreciate a lot the work, very well done, and Artix must do more advertising ;-) On 5/24/19 3:51 PM, Christos Nouskas wrote: > On Fri, 24 May 2019 08:48:32 +0200 > "P3d3.F." wrote: > >> Thank's for the advice, specially for qt5ct. Now I want to understand >> why it work, now dolphin behaviour is fine, and systemsettings don't. I >> never used it since now, but now I must understand :-) > It's used as a layer for uniform QT/GTK look. It seems to override some KDE settings. > >> Forgive me about the vocabularies, I forget that before I must install >> vocabularies :-) > I put en_US in the ISO, to give a hint about that. > >> I find other little issue, mainly related with the aesthetical aspect, >> but before I must test better how it work. > An ISO with the fixes will be uploaded and announced in the weekend, hopefully. > > Another anonymous tester made very insightful suggestions and I tried to implement most of them. One I particularly liked was creating udev rules that set the kernel I/O scheduler according to the disk type (rotational or solid state), as per the Arch wiki article. However, I believe we're reaching Ubuntu levels of intervention to users' systems, even for community ISOs, and we should not tweak any further. Artix branding with a few sane defaults ought to be enough for our intended audience. > > -- P3d3f Mobile1: +39-366-4xxxxxx Mail: p3d3f at riseup.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From je-vv at e.email Sun May 26 21:07:35 2019 From: je-vv at e.email (Javier) Date: Sun, 26 May 2019 12:07:35 -0600 Subject: [artix-general] Is there a side or experimental repo for GNU Shepherd? Message-ID: Hi, I like pretty much the idea of non systemd Arch. Thanks a lot for your effort. However I was looking for a GNU Shepherd init system based and Arch based distro. So far no luck. The init system is somehow pervasive, since all SW providing daemons need to have init scripts and such, and there's also a learning curve to learn how to create such scripts, how start/stop them and how to enable/disable them. Is there any effort turning Shepherd support on Artix? Are there any side/experimental repos? If one would like to add side support, how big would the effort be to keep it up while the distro goes only openRC? Thanks a lot ! -- Javier -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From je-vv at e.email Sun May 26 21:21:23 2019 From: je-vv at e.email (Javier) Date: Sun, 26 May 2019 12:21:23 -0600 Subject: [artix-general] netcfg support Message-ID: Hi ! The predecessor of current netctl on Arch was netcfg. It was neat, providing profiles support as currently netctl on Arch does. By quickly reading [1] and [2] I see references to networkmanager (I've always stayed away from it) and netifrc. But if netcfg is available that might be the option for someone so familiar with netcfg/netctl profiles. But most importantly, if netcfg is available, is it actually maintained? If available but without being maintained it might a bad idea actually to even install it... Greetings ! -- Javier [1] https://wiki.artixlinux.org/Main/Installation [2] https://wiki.artixlinux.org/Main/Migration -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From nous at artixlinux.org Sun May 26 21:33:05 2019 From: nous at artixlinux.org (Christos Nouskas) Date: Sun, 26 May 2019 21:33:05 +0300 Subject: [artix-general] Is there a side or experimental repo for GNU Shepherd? In-Reply-To: References: Message-ID: <20190526213305.2222c07c8e7bda0f47e62ac1@artixlinux.org> On Sun, 26 May 2019 12:07:35 -0600 Javier via artix-general wrote: > Is there any effort turning Shepherd support on Artix? Are there any side/experimental repos? If one would like to add side support, how big would the effort be to keep it up while the distro goes only openRC? Short answer, no. Long answer, it would need a dedicated developer that actually used shepherd to port and maintain it for Artix. It's actually how Artix got runit support, thanks to the efforts of a competent and dedicated developer. -- Christos Nouskas https://systemd-free.artixlinux.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From nous at artixlinux.org Sun May 26 21:40:06 2019 From: nous at artixlinux.org (Christos Nouskas) Date: Sun, 26 May 2019 21:40:06 +0300 Subject: [artix-general] netcfg support In-Reply-To: References: Message-ID: <20190526214006.c9eead1c86fda6d4ab87e527@artixlinux.org> On Sun, 26 May 2019 12:21:23 -0600 Javier via artix-general wrote: > Hi ! > > The predecessor of current netctl on Arch was netcfg. It was neat, providing profiles support as currently netctl on Arch does. By quickly reading [1] and [2] I see references to networkmanager (I've always stayed away from it) and netifrc. But if netcfg is available that might be the option for someone so familiar with netcfg/netctl profiles. But most importantly, if netcfg is available, is it actually maintained? If available but without being maintained it might a bad idea actually to even install it... You can install netcfg from the AUR and use it (I do). I too dislike networkmanager and opted for connman in our community ISOs, which is simpler and elegant. You can also use OpenRC itself for creating network profiles (they call it "stacked runlevels"[0]). [0] https://wiki.gentoo.org/wiki/OpenRC/StackedRunlevel -- Christos Nouskas https://systemd-free.artixlinux.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From je-vv at e.email Sun May 26 23:49:49 2019 From: je-vv at e.email (Javier) Date: Sun, 26 May 2019 14:49:49 -0600 Subject: [artix-general] netcfg support In-Reply-To: <20190526214006.c9eead1c86fda6d4ab87e527@artixlinux.org> References: <20190526214006.c9eead1c86fda6d4ab87e527@artixlinux.org> Message-ID: On 5/26/19 12:40 PM, Christos Nouskas wrote: > You can install netcfg from the AUR and use it (I do). I too dislike networkmanager and opted for connman in our community ISOs, which is simpler and elegant. You can also use OpenRC itself for creating network profiles (they call it "stacked runlevels"[0]). > > > [0] https://wiki.gentoo.org/wiki/OpenRC/StackedRunlevel > I'll explore connman then (available on Arch as well), and actually LXQt (what I use as DE) integrates a widget for it. If it takes time for making myself comfortable with it, netcfg is available, though not sure how maintained (definitely not officially supported by Artix). Thanks a lot ! -- Javier -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From somenxavier at posteo.net Sun May 26 23:59:52 2019 From: somenxavier at posteo.net (Xavier B.) Date: Sun, 26 May 2019 22:59:52 +0200 Subject: [artix-general] netcfg support In-Reply-To: References: <20190526214006.c9eead1c86fda6d4ab87e527@artixlinux.org> Message-ID: <20190526225952.2f3b5916edc2b1ea47b484ae@posteo.net> If you run non-graphical interface, I recommend it. I have been using it until I install Arch + OpenRC until now with Artix. [See https://github.com/somenxavier/falco/wiki/Events-log if you want to know how I did it] Xavier On Sun, 26 May 2019 14:49:49 -0600 Javier via artix-general ha escrit: > On 5/26/19 12:40 PM, Christos Nouskas wrote: > > You can install netcfg from the AUR and use it (I do). I too dislike networkmanager and opted for connman in our community ISOs, which is simpler and elegant. You can also use OpenRC itself for creating network profiles (they call it "stacked runlevels"[0]). > > > > > > [0] https://wiki.gentoo.org/wiki/OpenRC/StackedRunlevel > > > > I'll explore connman then (available on Arch as well), and actually LXQt (what I use as DE) integrates a widget for it. If it takes time for making myself comfortable with it, netcfg is available, though not sure how maintained (definitely not officially supported by Artix). > > Thanks a lot ! > > -- > Javier > From je-vv at e.email Mon May 27 00:25:44 2019 From: je-vv at e.email (Javier) Date: Sun, 26 May 2019 15:25:44 -0600 Subject: [artix-general] Does pulseaudio work? Message-ID: <7155a404-8b98-898a-ae6b-28e234d2769f@e.email> Hi, By reading the FAQ [1], it seems pulseaudio is discouraged, but I'm not sure if really discouraged or unsupported at all. Does it actually work on Artix? For many years I was refusing to use pulseaudio, but then when Firefox moved to pulseaudio, and apulse not being able to solve (at least by the time FF announced to only support the pulse backend), then I finally got into pulse. I have to recognize that the multiple audio devices support through pulse makes life really easy, as opposed to alsa, which makes it really cumbersome to manage different audio devices (embedded audio + USB audio devices like headsets + ...). Not that without pulse I can't live, just trying to understand what the FAQ means: > Q. What about pulseaudio? > A. Technically, pulseaudio is not part of systemd. Use alsa. Or oss4. I've never explored oss4 to be honest. From the oss times (prior to alsa), it was sort of madness, whether audio worked or not, particularly due to devices support. Then alsa showed up, and made audio generally work... Then pulse, which made things even easier. I have no clue what oss4 brings compared to everything else. But definitely I liked the way pulse made things easier in general. I guess to me alsa is lacking something pulse provides, :). Greetings ! -- Javier [1] https://artixlinux.org/faq.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From je-vv at e.email Mon May 27 00:41:41 2019 From: je-vv at e.email (Javier) Date: Sun, 26 May 2019 15:41:41 -0600 Subject: [artix-general] netcfg support In-Reply-To: <20190526225952.2f3b5916edc2b1ea47b484ae@posteo.net> References: <20190526214006.c9eead1c86fda6d4ab87e527@artixlinux.org> <20190526225952.2f3b5916edc2b1ea47b484ae@posteo.net> Message-ID: <2a803451-279c-89c1-82e6-224c2d13607b@e.email> On 5/26/19 2:59 PM, Xavier B. wrote: > If you run non-graphical interface, I recommend it. I have been using it until I install Arch + OpenRC until now with Artix. [See https://github.com/somenxavier/falco/wiki/Events-log if you want to know how I did it] Oh, there you talk about: > Network: based on this thread, I create the equivalent of net-auto-wireless of > netctl for netcfg. Thanks Lone_Wolf!. I enable it: rc-update add net-auto-wireless > default. As aaditya suggested, I simply enable ntp-client (rc-update add ntp-client > default). Finally, I remove the POST_UP and PRE_DOWN options in netcfg profiles I set > previously. So one need to make some special tweaks for wireless? The thread referenced there is no longer available [1] BTW. And although it seems openRC integrates several things like network itself, and then NTP client, I'd rather stick with the external apps as I'm doing right now on Arch. For NTP I'm still using old ntp package (I used before openntpd, but I remember at some point it was consider insecure, not sure even when that happened). For network I'd like to use netcfg, and it seems to work, but it also seems like it's missing some functionality for wireless... I don't remember if the wifi-menu is something new to netctl, I thought it was there on netcfg... -- Javier [1] https://bbs.archlinux.org/viewtopic?pid=1489283#p1489283 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From damnwidget at gmail.com Mon May 27 02:24:08 2019 From: damnwidget at gmail.com (Oscar Campos) Date: Mon, 27 May 2019 00:24:08 +0100 Subject: [artix-general] Does pulseaudio work? In-Reply-To: <7155a404-8b98-898a-ae6b-28e234d2769f@e.email> References: <7155a404-8b98-898a-ae6b-28e234d2769f@e.email> Message-ID: Hi Javier, Pulseaudio works perfectly in Artix it is well supported by the most widely used desktop environments and can be used as well with lightweight window managers like i3. Basically, what we are trying to say with that about pulseaudio is that, technically it is not part of systemd, Artix is a non systemd distribution so, technically pulseaudio is supported. Said that, pulseaudio has been designed and created by the same person that designed and created systemd and using kind of the same philosophies so use at your discretion. Regards. On Sun, 26 May 2019 at 22:25, Javier via artix-general < artix-general at artixlinux.org> wrote: > Hi, > > By reading the FAQ [1], it seems pulseaudio is discouraged, but I'm not > sure if really discouraged or unsupported at all. Does it actually work on > Artix? > > For many years I was refusing to use pulseaudio, but then when Firefox > moved to pulseaudio, and apulse not being able to solve (at least by the > time FF announced to only support the pulse backend), then I finally got > into pulse. I have to recognize that the multiple audio devices support > through pulse makes life really easy, as opposed to alsa, which makes it > really cumbersome to manage different audio devices (embedded audio + USB > audio devices like headsets + ...). > > Not that without pulse I can't live, just trying to understand what the > FAQ means: > > > Q. What about pulseaudio? > > A. Technically, pulseaudio is not part of systemd. Use alsa. Or oss4. > > I've never explored oss4 to be honest. From the oss times (prior to > alsa), it was sort of madness, whether audio worked or not, particularly > due to devices support. Then alsa showed up, and made audio generally > work... Then pulse, which made things even easier. I have no clue what > oss4 brings compared to everything else. But definitely I liked the way > pulse made things easier in general. I guess to me alsa is lacking > something pulse provides, :). > > Greetings ! > > -- > Javier > > [1] https://artixlinux.org/faq.php > > -- > artix-general mailing list > artix-general at artixlinux.org > https://lists.artixlinux.org/listinfo/artix-general > -------------- next part -------------- An HTML attachment was scrubbed... URL: From je-vv at e.email Mon May 27 02:52:17 2019 From: je-vv at e.email (Javier) Date: Sun, 26 May 2019 17:52:17 -0600 Subject: [artix-general] Does pulseaudio work? In-Reply-To: References: <7155a404-8b98-898a-ae6b-28e234d2769f@e.email> Message-ID: On 5/26/19 5:24 PM, Oscar Campos wrote: > Hi Javier, > > Pulseaudio works perfectly in Artix it is well supported by the most widely used desktop environments and can be used as well with lightweight window managers like i3. Basically, what we are trying to say with that about pulseaudio is that, technically it is not part of systemd, Artix is a non systemd distribution so, technically pulseaudio is supported. Said that, pulseaudio has been designed and created by the same person that designed and created systemd and using kind of the same philosophies so use at your discretion. > > Regards. Understood. TIL FF can work without the pulse backend, which might help me get back to alsa without pulse: > just add this: > user_pref("security.sandbox.content.syscall_whitelist", "16"); > to your user.js/prefs.js in the profile directory. It can also be found in "about:config", though I have no clue if FF will keep supporting that for longer (I understood they wouldn't some time back). I'll try out getting back to no pulse on Arch and see how it works. As mentioned, apulse was of no use when FF transitioned its default backend... But I got pulse is supported. As mentioned, I myself tried avoiding it as well until FF made its move... Thanks, -- Javier -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From je-vv at e.email Tue May 28 23:21:27 2019 From: je-vv at e.email (Javier) Date: Tue, 28 May 2019 14:21:27 -0600 Subject: [artix-general] Is console autologin possible to start X automatically on Artix? Message-ID: <2e34d1bc-5666-c003-beb3-ce6cc3a987f8@e.email> Hi, I'm using on Arch console autologin [1] to then auto start X at login [2]. The auto login is mentioned on Arch to be possible due to systemd, however it seems more like a getty + logind artifact. I'm wondering, as elogind is part of Artix, if autologin is also possible on Artix. Not that one can't live without it, just that it's really convenient to me. If you're wondering, I'm always starting with the screen blocked prior to calling the DE/WM on xinitrc... Thanks ! -- Javier [1] https://wiki.archlinux.org/index.php/Getty#Automatic_login_to_virtual_console [2] https://wiki.archlinux.org/index.php/Xinit#Autostart_X_at_login -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From je-vv at e.email Wed May 29 10:21:25 2019 From: je-vv at e.email (Javier) Date: Wed, 29 May 2019 01:21:25 -0600 Subject: [artix-general] Is console autologin possible to start X automatically on Artix? In-Reply-To: <2e34d1bc-5666-c003-beb3-ce6cc3a987f8@e.email> References: <2e34d1bc-5666-c003-beb3-ce6cc3a987f8@e.email> Message-ID: On 5/28/19 2:21 PM, Javier via artix-general wrote: > Hi, > > I'm using on Arch console autologin [1] to then auto start X at login [2]. The auto login is mentioned on Arch to be possible due to systemd, however it seems more like a getty + logind artifact. I'm wondering, as elogind is part of Artix, if autologin is also possible on Artix. > > Not that one can't live without it, just that it's really convenient to me. If you're wondering, I'm always starting with the screen blocked prior to calling the DE/WM on xinitrc... > > Thanks ! > > Some one suggested just starting X automatically on VT1 [2], without autologin, and with that I no longer need to block the screen at the very beginning, prior to calling the WM/DE on xinitrc, but there's a non graphical interface in the middle. Sounds good enough to me, as long as at init the system lands on VT1 at 1st, and not any random VT. Some time back it used to be that the VT finally showed at init was any (random?). Not sure if there's a way to make sure it's always VT1. If that can be configured, it's good enough, and there's no need for a DM at all... Thanks ! -- Javier [1] https://wiki.archlinux.org/index.php/Getty#Automatic_login_to_virtual_console [2] https://wiki.archlinux.org/index.php/Xinit#Autostart_X_at_login -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From fungilife at protonmail.com Wed May 29 13:02:47 2019 From: fungilife at protonmail.com (Fungi4All) Date: Wed, 29 May 2019 10:02:47 +0000 Subject: [artix-general] Is console autologin possible to start X automatically on Artix? In-Reply-To: References: <2e34d1bc-5666-c003-beb3-ce6cc3a987f8@e.email> Message-ID: > Some one suggested just starting X automatically on VT1 [2], without autologin, and with that I no longer need to block the screen at the very beginning, prior to calling the WM/DE on xinitrc, but there's a non graphical interface in the middle. Sounds good enough to me, as long as at init the system lands on VT1 at 1st, and not any random VT. Some time back it used to be that the VT finally showed at init was any (random?). Not sure if there's a way to make sure it's always VT1. If that can be configured, it's good enough, and there's no need for a DM at all... > > Thanks ! > > Javier > > [1] https://wiki.archlinux.org/index.php/Getty#Automatic_login_to_virtual_console > [2] https://wiki.archlinux.org/index.php/Xinit#Autostart_X_at_login > I am not very sure what you are referring to. You want to login at tty and have the wm/desktop open up right away, you don't want to see the tty and have a DM show you a login screen or you want to boot and go straight into the DE without any login involved? The last is what you commonly find on a live image. Since it works on MATE-OpenRC iso it should be able to work on an installed system as well. Fungalnet From je-vv at e.email Wed May 29 22:15:37 2019 From: je-vv at e.email (Javier) Date: Wed, 29 May 2019 13:15:37 -0600 Subject: [artix-general] Is console autologin possible to start X automatically on Artix? In-Reply-To: References: <2e34d1bc-5666-c003-beb3-ce6cc3a987f8@e.email> Message-ID: On 5/29/19 4:02 AM, Fungi4All via artix-general wrote: > I am not very sure what you are referring to. You want to login at tty and have the wm/desktop open up right away, you don't want to see the tty and have a DM show you a login screen or you want to boot and go straight into the DE without any login involved? The last is what you commonly find on a live image. Since it works on MATE-OpenRC iso it should be able to work on an installed system as well. > > Fungalnet > I'd like to autologin, and auto start X, both things. This has the effect of starting up on your session at once, just blocked by password in my case given I block the screen on the very beginning. To answer your question, yes, that's what you asked I believe. What you suggested in another email, on just auto starting X, after the login on VT1 is good enough to me (no auto login). Actually I like it, and I'm already migrating from auto login to that. My only concern with it, is whether there's a chance for any other virtual console where the init lands, other the the 1st one, since it's for the 1st one that one regularly performs the X auto start. At some point I remember starting on any VT, not just the 1st one, but I don't know if that has changed, and for sure the 1st one is always the one available after init. Thanks ! -- Javier [1] https://wiki.archlinux.org/index.php/Getty#Automatic_login_to_virtual_console [2] https://wiki.archlinux.org/index.php/Xinit#Autostart_X_at_login -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: