From somenxavier at posteo.net Thu Nov 16 21:18:25 2017 From: somenxavier at posteo.net (Xavier) Date: Thu, 16 Nov 2017 19:18:25 +0000 Subject: [artix-general] package icu upgrade causes errors Message-ID: I upgraded to icu 60.1-1 which causes errors with gnome-calendar and nodejs-tiddlywiki (in Arch AUR). I think it is because icu is in previous version in stable. And just 60.1-1 in testing (arch). Can you please wait until they migrate to 60 or fix this issue somehow Thanks, From somenxavier at posteo.net Thu Nov 16 21:19:20 2017 From: somenxavier at posteo.net (Xavier) Date: Thu, 16 Nov 2017 19:19:20 +0000 Subject: [artix-general] Re: package icu upgrade causes errors In-Reply-To: References: Message-ID: <5d4d03fb0634a761a48e3524028cfdcc@posteo.net> A 16.11.2017 19:18, Xavier escrigu?: > I upgraded to icu 60.1-1 which causes errors with gnome-calendar and > nodejs-tiddlywiki (in Arch AUR). I think it is because icu is in > previous version in stable. And just 60.1-1 in testing (arch). Can you > please wait until they migrate to 60 or fix this issue somehow > > Thanks, Sorry. The exact error is: $ gnome-calendar gnome-calendar: error while loading shared libraries: libicui18n.so.59: cannot open shared object file: No such file or directory From rafliakmaltejakusuma at gmail.com Thu Nov 16 21:29:40 2017 From: rafliakmaltejakusuma at gmail.com (Rafli Akmal) Date: Fri, 17 Nov 2017 03:29:40 +0800 Subject: [artix-general] Re: package icu upgrade causes errors In-Reply-To: <5d4d03fb0634a761a48e3524028cfdcc@posteo.net> References: <5d4d03fb0634a761a48e3524028cfdcc@posteo.net> Message-ID: Enable arch's testing repo then update them On Fri, Nov 17, 2017 at 3:19 AM, Xavier wrote: > > > A 16.11.2017 19:18, Xavier escrigu?: > > I upgraded to icu 60.1-1 which causes errors with gnome-calendar and >> nodejs-tiddlywiki (in Arch AUR). I think it is because icu is in >> previous version in stable. And just 60.1-1 in testing (arch). Can you >> please wait until they migrate to 60 or fix this issue somehow >> >> Thanks, >> > > Sorry. The exact error is: > > $ gnome-calendar > gnome-calendar: error while loading shared libraries: libicui18n.so.59: > cannot open shared object file: No such file or directory > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From somenxavier at posteo.net Fri Nov 17 18:44:52 2017 From: somenxavier at posteo.net (Xavier) Date: Fri, 17 Nov 2017 16:44:52 +0000 Subject: [artix-general] Re: package icu upgrade causes errors In-Reply-To: References: <5d4d03fb0634a761a48e3524028cfdcc@posteo.net> Message-ID: <155921f145083e724e169fa74b7c1041@posteo.net> I prefer to be in stable. I prefer stability. But I think it's a kind of bug from a user perspective. Can you please be synchronize with critical packages (in core) from Arch? This will not cause troubles with non-system packages in Artix. Thanks, A 16.11.2017 19:29, Rafli Akmal escrigu?: > Enable arch's testing repo then update them > > On Fri, Nov 17, 2017 at 3:19 AM, Xavier > wrote: > >> A 16.11.2017 19:18, Xavier escrigu?: >> >>> I upgraded to icu 60.1-1 which causes errors with gnome-calendar >>> and >>> nodejs-tiddlywiki (in Arch AUR). I think it is because icu is in >>> previous version in stable. And just 60.1-1 in testing (arch). >>> Can you >>> please wait until they migrate to 60 or fix this issue somehow >>> >>> Thanks, >> >> Sorry. The exact error is: >> >> $ gnome-calendar >> gnome-calendar: error while loading shared libraries: >> libicui18n.so.59: cannot open shared object file: No such file or >> directory From fungilife at protonmail.com Sun Nov 26 20:35:10 2017 From: fungilife at protonmail.com (Fungi4All) Date: Sun, 26 Nov 2017 13:35:10 -0500 Subject: [artix-general] Forum pw reset? Message-ID: I somehow had logged in eternally and somehow I managed to forget the pw Sending back an email for resetting it seems to not be working. I tried it 2 days ago and then again today and never received an email Kz -------------- next part -------------- An HTML attachment was scrubbed... URL: From nous at artixlinux.org Mon Nov 27 14:59:51 2017 From: nous at artixlinux.org (Christos Nouskas) Date: Mon, 27 Nov 2017 14:59:51 +0200 Subject: [artix-general] Forum pw reset? In-Reply-To: References: Message-ID: Still no local MX I'm afraid, with all these VPS outages and moves. Your new pass is 'parekoumpare', please change it to something reasonable. On 26 November 2017 at 20:35, Fungi4All wrote: > I somehow had logged in eternally and somehow I managed to forget the pw > Sending back an email for resetting it seems to not be working. I tried it > 2 days ago and then again today and never received an email > > Kz From fungilife at protonmail.com Mon Nov 27 21:44:35 2017 From: fungilife at protonmail.com (Fungi4All) Date: Mon, 27 Nov 2017 14:44:35 -0500 Subject: [artix-general] Forum pw reset? In-Reply-To: References: Message-ID: ?? ???? ?????? ?? ???????? ??? ?????? username ????? ????? ??? ???? ????? ????. ???????? ?? ??? default pass ?? ????? eidafwskaimphka ??'? ???? ???????'?? ??? ??????? ????? ???????, ?????? ??? ?????, ???? ???'?? ????? ?? ???? ?????? ?? ??????? ? ???????'? ?????'?? > From: nous at artixlinux.org > To: Fungi4All > > Still no local MX I'm afraid, with all these VPS outages and moves. > Your new pass is 'parekoumpare', please change it to something > reasonable. > > On 26 November 2017 at 20:35, Fungi4All fungilife at protonmail.com wrote: > >> I somehow had logged in eternally and somehow I managed to forget the pw >> Sending back an email for resetting it seems to not be working. I tried it >> 2 days ago and then again today and never received an email >> Kz -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungilife at protonmail.com Thu Nov 9 08:10:17 2017 From: fungilife at protonmail.com (Fungi4All) Date: Thu, 09 Nov 2017 01:10:17 -0500 Subject: [artix-general] A ton of signature errors Message-ID: To some of us it takes a long time to download all this and after the download you realize it is not the last time. Isn't there a way to prevent this from happening? Is this happening by rsync taking too long to feed new packages to the mirror? This is the first time I see a buildbot signature failure. error: expat: signature from "Artix Buildbot " is marginal trust :: File /var/cache/pacman/pkg/expat-2.2.5-1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] n error: gtk-update-icon-cache: signature from "Artix Buildbot " is marginal trust :: File /var/cache/pacman/pkg/gtk-update-icon-cache-3.22.26-1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] n error: gtk3: signature from "Artix Buildbot " is marginal trust :: File /var/cache/pacman/pkg/gtk3-3.22.26-1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] n error: libuv: signature from "Artix Buildbot " is marginal trust :: File /var/cache/pacman/pkg/libuv-1.16.0-1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] n error: linux-ck: signature from "Artix Buildbot " is marginal trust :: File /var/cache/pacman/pkg/linux-ck-4.13.12-2-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] n error: linux-ck-headers: signature from "Artix Buildbot " is marginal trust :: File /var/cache/pacman/pkg/linux-ck-headers-4.13.12-2-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] n error: linux-lts: signature from "Artix Buildbot " is marginal trust :: File /var/cache/pacman/pkg/linux-lts-4.9.61-1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] n error: failed to commit transaction (invalid or corrupted package) Errors occurred, no packages were upgraded. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruben at mrbrklyn.com Thu Nov 9 09:55:43 2017 From: ruben at mrbrklyn.com (Ruben Safir) Date: Thu, 9 Nov 2017 02:55:43 -0500 Subject: [artix-general] A ton of signature errors In-Reply-To: References: Message-ID: <20171109075543.GA2327@www.mrbrklyn.com> iwish I knew what that is On Thu, Nov 09, 2017 at 01:10:17AM -0500, Fungi4All wrote: > To some of us it takes a long time to download all this and after the download you realize it > is not the last time. Isn't there a way to prevent this from happening? > Is this happening by rsync taking too long to feed new packages to the mirror? > This is the first time I see a buildbot signature failure. > > error: expat: signature from "Artix Buildbot " is marginal trust > :: File /var/cache/pacman/pkg/expat-2.2.5-1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). > Do you want to delete it? [Y/n] n > error: gtk-update-icon-cache: signature from "Artix Buildbot " is marginal trust > :: File /var/cache/pacman/pkg/gtk-update-icon-cache-3.22.26-1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). > Do you want to delete it? [Y/n] n > error: gtk3: signature from "Artix Buildbot " is marginal trust > :: File /var/cache/pacman/pkg/gtk3-3.22.26-1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). > Do you want to delete it? [Y/n] n > error: libuv: signature from "Artix Buildbot " is marginal trust > :: File /var/cache/pacman/pkg/libuv-1.16.0-1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). > Do you want to delete it? [Y/n] n > error: linux-ck: signature from "Artix Buildbot " is marginal trust > :: File /var/cache/pacman/pkg/linux-ck-4.13.12-2-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). > Do you want to delete it? [Y/n] n > error: linux-ck-headers: signature from "Artix Buildbot " is marginal trust > :: File /var/cache/pacman/pkg/linux-ck-headers-4.13.12-2-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). > Do you want to delete it? [Y/n] n > error: linux-lts: signature from "Artix Buildbot " is marginal trust > :: File /var/cache/pacman/pkg/linux-lts-4.9.61-1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). > Do you want to delete it? [Y/n] n > error: failed to commit transaction (invalid or corrupted package) > Errors occurred, no packages were upgraded. -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 From damnwidget at gmail.com Thu Nov 9 19:31:05 2017 From: damnwidget at gmail.com (Oscar Campos) Date: Thu, 9 Nov 2017 17:31:05 +0000 Subject: [artix-general] A ton of signature errors In-Reply-To: <20171109075543.GA2327@www.mrbrklyn.com> References: <20171109075543.GA2327@www.mrbrklyn.com> Message-ID: Do a: pacman-key --lsign Buildbot On 9 November 2017 at 07:55, Ruben Safir wrote: > iwish I knew what that is > > On Thu, Nov 09, 2017 at 01:10:17AM -0500, Fungi4All wrote: > > To some of us it takes a long time to download all this and after the > download you realize it > > is not the last time. Isn't there a way to prevent this from happening? > > Is this happening by rsync taking too long to feed new packages to the > mirror? > > This is the first time I see a buildbot signature failure. > > > > error: expat: signature from "Artix Buildbot " > is marginal trust > > :: File /var/cache/pacman/pkg/expat-2.2.5-1-x86_64.pkg.tar.xz is > corrupted (invalid or corrupted package (PGP signature)). > > Do you want to delete it? [Y/n] n > > error: gtk-update-icon-cache: signature from "Artix Buildbot < > buildbot at artixlinux.org>" is marginal trust > > :: File /var/cache/pacman/pkg/gtk-update-icon-cache-3.22.26-1-x86_64.pkg.tar.xz > is corrupted (invalid or corrupted package (PGP signature)). > > Do you want to delete it? [Y/n] n > > error: gtk3: signature from "Artix Buildbot " > is marginal trust > > :: File /var/cache/pacman/pkg/gtk3-3.22.26-1-x86_64.pkg.tar.xz is > corrupted (invalid or corrupted package (PGP signature)). > > Do you want to delete it? [Y/n] n > > error: libuv: signature from "Artix Buildbot " > is marginal trust > > :: File /var/cache/pacman/pkg/libuv-1.16.0-1-x86_64.pkg.tar.xz is > corrupted (invalid or corrupted package (PGP signature)). > > Do you want to delete it? [Y/n] n > > error: linux-ck: signature from "Artix Buildbot " > is marginal trust > > :: File /var/cache/pacman/pkg/linux-ck-4.13.12-2-x86_64.pkg.tar.xz is > corrupted (invalid or corrupted package (PGP signature)). > > Do you want to delete it? [Y/n] n > > error: linux-ck-headers: signature from "Artix Buildbot < > buildbot at artixlinux.org>" is marginal trust > > :: File /var/cache/pacman/pkg/linux-ck-headers-4.13.12-2-x86_64.pkg.tar.xz > is corrupted (invalid or corrupted package (PGP signature)). > > Do you want to delete it? [Y/n] n > > error: linux-lts: signature from "Artix Buildbot < > buildbot at artixlinux.org>" is marginal trust > > :: File /var/cache/pacman/pkg/linux-lts-4.9.61-1-x86_64.pkg.tar.xz is > corrupted (invalid or corrupted package (PGP signature)). > > Do you want to delete it? [Y/n] n > > error: failed to commit transaction (invalid or corrupted package) > > Errors occurred, no packages were upgraded. > > -- > So many immigrant groups have swept through our town > that Brooklyn, like Atlantis, reaches mythological > proportions in the mind of the world - RI Safir 1998 > http://www.mrbrklyn.com > > DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 > http://www.nylxs.com - Leadership Development in Free Software > http://www2.mrbrklyn.com/resources - Unpublished Archive > http://www.coinhangout.com - coins! > http://www.brooklyn-living.com > > Being so tracked is for FARM ANIMALS and and extermination camps, > but incompatible with living as a free human being. -RI Safir 2013 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungilife at protonmail.com Thu Nov 9 19:50:29 2017 From: fungilife at protonmail.com (Fungi4All) Date: Thu, 09 Nov 2017 12:50:29 -0500 Subject: [artix-general] A ton of signature errors In-Reply-To: References: <20171109075543.GA2327@www.mrbrklyn.com> Message-ID: Thank you this worked, > UTC Time: November 9, 2017 5:31 PM > From: damnwidget at gmail.com > To: artix-general at artixlinux.org > Fungi4All > > Do a: pacman-key --lsign Buildbot sudo pacman-key --lsign Buildbot -> Locally signing key Buildbot... ==> Updating trust database... gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: depth: 0 valid: 1 signed: 14 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: depth: 1 valid: 14 signed: 78 trust: 2-, 0q, 0n, 12m, 0f, 0u gpg: depth: 2 valid: 71 signed: 12 trust: 71-, 0q, 0n, 0m, 0f, 0u gpg: next trustdb check due at 2018-06-25 But where is everybody today, the forum is down for 12hrs or so? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruben at mrbrklyn.com Thu Nov 9 23:20:49 2017 From: ruben at mrbrklyn.com (Ruben Safir) Date: Thu, 9 Nov 2017 16:20:49 -0500 Subject: [artix-general] A ton of signature errors In-Reply-To: References: <20171109075543.GA2327@www.mrbrklyn.com> Message-ID: <20171109212049.GA7773@www.mrbrklyn.com> do you have a name? On Thu, Nov 09, 2017 at 12:50:29PM -0500, Fungi4All wrote: > Thank you this worked, > > > UTC Time: November 9, 2017 5:31 PM > > From: damnwidget at gmail.com > > To: artix-general at artixlinux.org > > Fungi4All > > > > Do a: pacman-key --lsign Buildbot > > sudo pacman-key --lsign Buildbot > -> Locally signing key Buildbot... > ==> Updating trust database... > gpg: marginals needed: 3 completes needed: 1 trust model: pgp > gpg: depth: 0 valid: 1 signed: 14 trust: 0-, 0q, 0n, 0m, 0f, 1u > gpg: depth: 1 valid: 14 signed: 78 trust: 2-, 0q, 0n, 12m, 0f, 0u > gpg: depth: 2 valid: 71 signed: 12 trust: 71-, 0q, 0n, 0m, 0f, 0u > gpg: next trustdb check due at 2018-06-25 > > But where is everybody today, the forum is down for 12hrs or so? -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 From fungilife at protonmail.com Fri Nov 10 00:25:05 2017 From: fungilife at protonmail.com (Fungi4All) Date: Thu, 09 Nov 2017 17:25:05 -0500 Subject: [artix-general] A ton of signature errors In-Reply-To: <20171109212049.GA7773@www.mrbrklyn.com> References: <20171109075543.GA2327@www.mrbrklyn.com> <20171109212049.GA7773@www.mrbrklyn.com> Message-ID: > UTC Time: November 9, 2017 9:20 PM > From: ruben at mrbrklyn.com > To: artix-general at artixlinux.org, Fungi4All > > do you have a name? Yes, it is Gus -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruben at mrbrklyn.com Wed Nov 22 17:35:56 2017 From: ruben at mrbrklyn.com (Ruben Safir) Date: Wed, 22 Nov 2017 10:35:56 -0500 Subject: [artix-general] elongind and X Message-ID: <20171122153556.GA6304@www.mrbrklyn.com> How do I get rid of loginctl and elongd and keep X? -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 From artoo at cromnix.org Wed Nov 22 18:34:54 2017 From: artoo at cromnix.org (artoo) Date: Wed, 22 Nov 2017 17:34:54 +0100 Subject: [artix-general] elongind and X In-Reply-To: <20171122153556.GA6304@www.mrbrklyn.com> References: <20171122153556.GA6304@www.mrbrklyn.com> Message-ID: <12aff545-8f33-ed5b-bb50-64fe9488f53a@cromnix.org> I love these one liners. Simple answer, you can't, you would need to rebuild xorg. Are you sure your special requirements are met with any binary distro? Such stuff is easy on gentoo for example, but your needs are not really well addressed with a binary package distro. Packages on binary distros are compromises, how much of its compile features to enable. Simply speaking, gentoo allows you to customize to very high degree, since you compile the packages from source yourself. Artoo On 22.11.2017 16:35, Ruben Safir wrote: > How do I get rid of loginctl and elongd and keep X? > > From ruben at mrbrklyn.com Wed Nov 22 19:08:26 2017 From: ruben at mrbrklyn.com (Ruben Safir) Date: Wed, 22 Nov 2017 12:08:26 -0500 Subject: [artix-general] elongind and X In-Reply-To: <12aff545-8f33-ed5b-bb50-64fe9488f53a@cromnix.org> References: <20171122153556.GA6304@www.mrbrklyn.com> <12aff545-8f33-ed5b-bb50-64fe9488f53a@cromnix.org> Message-ID: <20171122170826.GA6842@www.mrbrklyn.com> On Wed, Nov 22, 2017 at 05:34:54PM +0100, artoo wrote: > I love these one liners. > What else would be needed aside from one line. I discovered that loginctl allows regular users to shutdown the system. I can't have that. Such behavior does an end around the core unix security. I tried to remove elongd and it said X was a dependendcy. > > Simple answer, you can't, you would need to rebuild xorg. > can I do that and make it a package to admin with pacman? > Are you sure your special requirements are met with any binary distro? Its been nearly a decade since I tore through gentoo. Its not relaistic. What I need is a distro that is systemd free, and new options are always looked at. things look like they will get worse with wayland barking at the door. for the momemnt I chmod 0000 loginctl, but the underlining design flaw continues of giving root access to normal users though polykit etc continues. > > Such stuff is easy on gentoo for example, but your needs are not > really well addressed with a binary package distro. > > Packages on binary distros are compromises, how much of its compile > features to enable. > > Simply speaking, gentoo allows you to customize to very high degree, > since you compile the packages from source yourself. > Maybe I can compile an x package that doesn't hook into councilkit et al through gentoo. > > Artoo > > > On 22.11.2017 16:35, Ruben Safir wrote: > >How do I get rid of loginctl and elongd and keep X? > > > > -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 From artoo at cromnix.org Wed Nov 22 19:41:28 2017 From: artoo at cromnix.org (artoo) Date: Wed, 22 Nov 2017 18:41:28 +0100 Subject: [artix-general] elongind and X In-Reply-To: <20171122170826.GA6842@www.mrbrklyn.com> References: <20171122153556.GA6304@www.mrbrklyn.com> <12aff545-8f33-ed5b-bb50-64fe9488f53a@cromnix.org> <20171122170826.GA6842@www.mrbrklyn.com> Message-ID: <26908265-a4be-3311-d502-703bc3dba0a4@cromnix.org> chmod of loginctl is not really good idea. Why don't you simply set up a polkit rule that does not allow user shutdown? I don't iget it, you you seem to have a talent to shoot yourself in the foot? On 22.11.2017 18:08, Ruben Safir wrote: > On Wed, Nov 22, 2017 at 05:34:54PM +0100, artoo wrote: >> I love these one liners. >> > What else would be needed aside from one line. I discovered that > loginctl allows regular users to shutdown the system. I can't have > that. Such behavior does an end around the core unix security. I tried > to remove elongd and it said X was a dependendcy. > >> Simple answer, you can't, you would need to rebuild xorg. >> > can I do that and make it a package to admin with pacman? > > >> Are you sure your special requirements are met with any binary distro? > Its been nearly a decade since I tore through gentoo. Its not > relaistic. What I need is a distro that is systemd free, and new > options are always looked at. > > things look like they will get worse with wayland barking at the door. > > for the momemnt I chmod 0000 loginctl, but the underlining design flaw > continues of giving root access to normal users though polykit etc > continues. > > >> Such stuff is easy on gentoo for example, but your needs are not >> really well addressed with a binary package distro. >> >> Packages on binary distros are compromises, how much of its compile >> features to enable. >> >> Simply speaking, gentoo allows you to customize to very high degree, >> since you compile the packages from source yourself. >> > Maybe I can compile an x package that doesn't hook into councilkit et > al through gentoo. > > > >> Artoo >> >> >> On 22.11.2017 16:35, Ruben Safir wrote: >>> How do I get rid of loginctl and elongd and keep X? >>> >>> From ruben at mrbrklyn.com Wed Nov 22 21:05:59 2017 From: ruben at mrbrklyn.com (Ruben Safir) Date: Wed, 22 Nov 2017 14:05:59 -0500 Subject: [artix-general] elongind and X In-Reply-To: <26908265-a4be-3311-d502-703bc3dba0a4@cromnix.org> References: <20171122153556.GA6304@www.mrbrklyn.com> <12aff545-8f33-ed5b-bb50-64fe9488f53a@cromnix.org> <20171122170826.GA6842@www.mrbrklyn.com> <26908265-a4be-3311-d502-703bc3dba0a4@cromnix.org> Message-ID: <20171122190559.GA7815@www.mrbrklyn.com> On Wed, Nov 22, 2017 at 06:41:28PM +0100, artoo wrote: > chmod of loginctl is not really good idea. I agree > > Why don't you simply set up a polkit rule that does not allow user shutdown? > > I don't iget it, you you seem to have a talent to shoot yourself in > the foot? I understand. You vew this from the prespective of creating the os with arch packages being imported but from my prespective on my server I don't want that hairball free desktop crap as a wrapper to the Linux kernel granting rights of any kind. My laptop is one thing by my mail server and ssh and apache server is another. It is just a big rich attack vector and on my workstation it is a huge complex hairball of dependencies where I've lost control of my hardware. I can't be the only expereinced user here to have looked at polkit and said, "What the fuck do I need that for" > > On 22.11.2017 18:08, Ruben Safir wrote: > >On Wed, Nov 22, 2017 at 05:34:54PM +0100, artoo wrote: > >>I love these one liners. > >> > >What else would be needed aside from one line. I discovered that > >loginctl allows regular users to shutdown the system. I can't have > >that. Such behavior does an end around the core unix security. I tried > >to remove elongd and it said X was a dependendcy. > > > >>Simple answer, you can't, you would need to rebuild xorg. > >> > >can I do that and make it a package to admin with pacman? > > > > > >>Are you sure your special requirements are met with any binary distro? > >Its been nearly a decade since I tore through gentoo. Its not > >relaistic. What I need is a distro that is systemd free, and new > >options are always looked at. > > > >things look like they will get worse with wayland barking at the door. > > > >for the momemnt I chmod 0000 loginctl, but the underlining design flaw > >continues of giving root access to normal users though polykit etc > >continues. > > > > > >>Such stuff is easy on gentoo for example, but your needs are not > >>really well addressed with a binary package distro. > >> > >>Packages on binary distros are compromises, how much of its compile > >>features to enable. > >> > >>Simply speaking, gentoo allows you to customize to very high degree, > >>since you compile the packages from source yourself. > >> > >Maybe I can compile an x package that doesn't hook into councilkit et > >al through gentoo. > > > > > > > >>Artoo > >> > >> > >>On 22.11.2017 16:35, Ruben Safir wrote: > >>>How do I get rid of loginctl and elongd and keep X? > >>> > >>> -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 From nous at artixlinux.org Wed Nov 22 22:15:24 2017 From: nous at artixlinux.org (Christos Nouskas) Date: Wed, 22 Nov 2017 22:15:24 +0200 Subject: [artix-general] elongind and X In-Reply-To: <20171122190559.GA7815@www.mrbrklyn.com> References: <20171122153556.GA6304@www.mrbrklyn.com> <12aff545-8f33-ed5b-bb50-64fe9488f53a@cromnix.org> <20171122170826.GA6842@www.mrbrklyn.com> <26908265-a4be-3311-d502-703bc3dba0a4@cromnix.org> <20171122190559.GA7815@www.mrbrklyn.com> Message-ID: On 22 November 2017 at 21:05, Ruben Safir wrote: > My laptop is one thing by my mail server and ssh and apache server is > another. It is just a big rich attack vector and on my workstation it > is a huge complex hairball of dependencies where I've lost control of my > hardware. Not defending systemd/elogind crap, but you could just disable the elogind and/or polkit daemons on your servers. Problem solved. On a relevant note, I just tested and found out that any logged-on user (even remotely connected via ssh and regardless of group membership) can issue loginctl power-related commands in a true fuck-me-plenty-with-a-chainsaw fashion. It's not a bug, it's a feature. From ruben at mrbrklyn.com Sat Nov 25 17:15:27 2017 From: ruben at mrbrklyn.com (Ruben Safir) Date: Sat, 25 Nov 2017 10:15:27 -0500 Subject: [artix-general] ALSA permisions Message-ID: <20171125151527.GA6360@www.mrbrklyn.com> It seems that alsamixer can only access the alsa devices as root umm - how can I fix that through system tool? Ruben -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 From chris at cromer.cl Sun Nov 26 03:54:30 2017 From: chris at cromer.cl (Chris Cromer) Date: Sat, 25 Nov 2017 22:54:30 -0300 Subject: [artix-general] ALSA permisions In-Reply-To: <20171125151527.GA6360@www.mrbrklyn.com> References: <20171125151527.GA6360@www.mrbrklyn.com> Message-ID: You have to be part of the audio group to do that without root permission. Chris Cromer On Sat, Nov 25, 2017 at 12:15 PM, Ruben Safir wrote: > It seems that alsamixer can only access the alsa devices as root > > umm - how can I fix that through system tool? > > Ruben > -- > So many immigrant groups have swept through our town > that Brooklyn, like Atlantis, reaches mythological > proportions in the mind of the world - RI Safir 1998 > http://www.mrbrklyn.com > > DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 > http://www.nylxs.com - Leadership Development in Free Software > http://www2.mrbrklyn.com/resources - Unpublished Archive > http://www.coinhangout.com - coins! > http://www.brooklyn-living.com > > Being so tracked is for FARM ANIMALS and and extermination camps, > but incompatible with living as a free human being. -RI Safir 2013 > From ruben at mrbrklyn.com Tue Nov 21 07:30:43 2017 From: ruben at mrbrklyn.com (Ruben Safir) Date: Tue, 21 Nov 2017 00:30:43 -0500 Subject: [artix-general] icu - run both versions Message-ID: wget https://mirror.netcologne.de/archlinux/core/os/x86_64/icu-59.1-2-x86_64.pkg.tar.xz sudo tar -C / -Jxvf icu-59.1-2-x86_64.pkg.tar.xz usr and done when they fix it in the packages, great you can have both libraries and let ld.so do its magic For some reason arch never has multiple libraries for this kind of problem don't remove either version of icu -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 From fungilife at protonmail.com Tue Nov 21 08:32:45 2017 From: fungilife at protonmail.com (Fungi4All) Date: Tue, 21 Nov 2017 01:32:45 -0500 Subject: [artix-general] icu - run both versions In-Reply-To: References: Message-ID: From: ruben at mrbrklyn.com > To: artix-general at artixlinux.org > > wget https://mirror.netcologne.de/archlinux/core/os/x86_64/icu-59.1-2-x86_64.pkg.tar.xz > sudo tar -C / -Jxvf icu-59.1-2-x86_64.pkg.tar.xz usr > and done > > when they fix it in the packages, great > you can have both libraries and let ld.so do its magic > For some reason arch never has multiple libraries for this kind of problem > don't remove either version of icu Are you responding to someone or a specific problem? On the artix rep. there is icu 60.1-1, why should someone pick 59.1-2 from Arch? Is it possible that in Arch-testing there is the same? -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at cromer.cl Tue Nov 21 12:10:58 2017 From: chris at cromer.cl (Chris Cromer) Date: Tue, 21 Nov 2017 07:10:58 -0300 Subject: [artix-general] icu - run both versions In-Reply-To: References: Message-ID: Please do not follow this advice. By untarring another version into the system, pacman cannot track the changes. This can cause conflicts and errors in future upgrades. He temporarily fixed it, but this can cause even more problems in the future. Chris Cromer On Nov 21, 2017 3:32 AM, "Fungi4All" wrote: > From: ruben at mrbrklyn.com > > To: artix-general at artixlinux.org > > wget https://mirror.netcologne.de/archlinux/core/os/x86_64/icu- > 59.1-2-x86_64.pkg.tar.xz > sudo tar -C / -Jxvf icu-59.1-2-x86_64.pkg.tar.xz usr > and done > > > when they fix it in the packages, great > you can have both libraries and let ld.so do its magic > For some reason arch never has multiple libraries for this kind of problem > don't remove either version of icu > > Are you responding to someone or a specific problem? On the artix rep. > there is icu 60.1-1, why should someone > pick 59.1-2 from Arch? Is it possible that in Arch-testing there is the > same? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xancorreu at gmail.com Tue Nov 21 12:14:11 2017 From: xancorreu at gmail.com (Xan) Date: Tue, 21 Nov 2017 11:14:11 +0100 Subject: [artix-general] icu - run both versions In-Reply-To: References: Message-ID: <20171121111411.6999223bd9e3ddf9fae5a85a@gmail.com> +1 Always use packages. It's my experience On Tue, 21 Nov 2017 07:10:58 -0300 Chris Cromer ha escrit: > Please do not follow this advice. By untarring another version into the > system, pacman cannot track the changes. This can cause conflicts and > errors in future upgrades. He temporarily fixed it, but this can cause even > more problems in the future. > > Chris Cromer > > On Nov 21, 2017 3:32 AM, "Fungi4All" wrote: > > > From: ruben at mrbrklyn.com > > > > To: artix-general at artixlinux.org > > > > wget https://mirror.netcologne.de/archlinux/core/os/x86_64/icu- > > 59.1-2-x86_64.pkg.tar.xz > > sudo tar -C / -Jxvf icu-59.1-2-x86_64.pkg.tar.xz usr > > and done > > > > > > when they fix it in the packages, great > > you can have both libraries and let ld.so do its magic > > For some reason arch never has multiple libraries for this kind of problem > > don't remove either version of icu > > > > Are you responding to someone or a specific problem? On the artix rep. > > there is icu 60.1-1, why should someone > > pick 59.1-2 from Arch? Is it possible that in Arch-testing there is the > > same? > > > > From ruben at mrbrklyn.com Wed Nov 22 00:18:05 2017 From: ruben at mrbrklyn.com (Ruben Safir) Date: Tue, 21 Nov 2017 17:18:05 -0500 Subject: [artix-general] icu - run both versions In-Reply-To: <20171121111411.6999223bd9e3ddf9fae5a85a@gmail.com> References: <20171121111411.6999223bd9e3ddf9fae5a85a@gmail.com> Message-ID: <20171121221805.GA31815@www.mrbrklyn.com> On Tue, Nov 21, 2017 at 11:14:11AM +0100, Xan wrote: > +1 > Always use packages. It's my experience Its wrong in this case because the packages are broken. There isno place for absolutes in IT In this case, what I wrote is correct and it will NEVER create a problem, however, when you inisist on downgrading icu ou break one set of applications, and when you run the current version you break another set of programs. The ICU library is a font library. It has no impact on the core stability but it did screw up a litney of programs including postfix. If the packages were built correctly to begin with, the ICU upgrade would had triggered a litney conflicts, and it didn't. It is common, especially for developers to have multiple versions of libraries. I have three versions of GCC alone in order tocompile different AI projects that I wrote. There are mutple perl versions as well because of different tools needing versions which had depaciated calls. Same with Glib and gnome. Additionally, package management completely fails wen you are doing development work. > > On Tue, 21 Nov 2017 07:10:58 -0300 > Chris Cromer ha escrit: > > > Please do not follow this advice. By untarring another version into the > > system, pacman cannot track the changes. This can cause conflicts and > > errors in future upgrades. He temporarily fixed it, but this can cause even > > more problems in the future. > > > > Chris Cromer > > > > On Nov 21, 2017 3:32 AM, "Fungi4All" wrote: > > > > > From: ruben at mrbrklyn.com > > > > > > To: artix-general at artixlinux.org > > > > > > wget https://mirror.netcologne.de/archlinux/core/os/x86_64/icu- > > > 59.1-2-x86_64.pkg.tar.xz > > > sudo tar -C / -Jxvf icu-59.1-2-x86_64.pkg.tar.xz usr > > > and done > > > > > > > > > when they fix it in the packages, great > > > you can have both libraries and let ld.so do its magic > > > For some reason arch never has multiple libraries for this kind of problem > > > don't remove either version of icu > > > > > > Are you responding to someone or a specific problem? On the artix rep. > > > there is icu 60.1-1, why should someone > > > pick 59.1-2 from Arch? Is it possible that in Arch-testing there is the > > > same? > > > > > > -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 From ruben at mrbrklyn.com Wed Nov 22 20:43:09 2017 From: ruben at mrbrklyn.com (Ruben Safir) Date: Wed, 22 Nov 2017 13:43:09 -0500 Subject: Fwd: Re: [artix-general] icu - run both versions In-Reply-To: References: Message-ID: <41dff7c5-43f2-31de-8941-c3c631e2feb5@mrbrklyn.com> Chris Cromer On Wed, Nov 22, 2017 at 12:52 PM, Ruben Safir wrote: > On Wed, Nov 22, 2017 at 12:23:21AM -0300, Chris Cromer wrote: >> I admit that ICU getting pushed too soon was a problem. But the problem was >> not because of a broken package. All those other packages needed to be >> recompiled against the new libs since the ABI is incompatible in the new >> lib. An unfortunate situation yes, but sometimes these things happen on a >> rolling release distro. >> > > > That is incorrect. I was talking to Rick Moen about this last night and > the packages are broken and were always broken and will continue to be > broken. ICU is not a declared dependency in the packages although they > are in the source files. Packages don't have to have "depends" declcared for every single possible thing in the packages to link against them, it is enough that they are installed by a dependency of a dependency. So if package C depends on package B and package A, and package B depends on package A, it is enough to make package C only depend on package B which forms a chain of dependencies. There is not need to put package A as dependency in package C because B will already pull it in as one of its dependencies. The fact that you don't realize this means that you have very limited knowledge of how packaging actually works. And frankly I don't care what "Rick Moen" says, the truth is that those supposedly broken packages as you call them are linked to ICU when they were compiled and had to be recompiled to link against the new version of ICU. They were not "broken", they needed to be updated for the new ICU version. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hello Chris. For major libraries this is commonly not necessary as they are linked as stdc++ ect It is the smaller libraries that pose this problem and they should be 100% listed with all there dependencies. Understand, tumbleweed, which is the opensuse rolling release I had for years rarely if ever had this problem. Now maybe that is a manpower issue, and you folks are working your tushas off to get artix up to speed, but I have SEEN library dependencies cause package management systems retain libraries in rolling releases, and with Manjaro, that was an issue with gtk3 where there was no upgrade path without removing needed packages ... which was a PIA. But I don't feel compelled, and neither should you, to chose between 100% package management and 100% code base. Of course, once one goes off the package management system, its on you, not the artix core developers or the arch people. But OTOH, in this instance, what are you gonna lose? The benefits are greater than the losses. Show me how having a spare unmonitored icu library from ARCH presents a problem and be specific. It over writes NOTHING. It lives in its own space. From ruben at mrbrklyn.com Wed Nov 22 21:10:28 2017 From: ruben at mrbrklyn.com (Ruben Safir) Date: Wed, 22 Nov 2017 14:10:28 -0500 Subject: Fwd: Re: [artix-general] icu - run both versions In-Reply-To: <41dff7c5-43f2-31de-8941-c3c631e2feb5@mrbrklyn.com> References: <41dff7c5-43f2-31de-8941-c3c631e2feb5@mrbrklyn.com> Message-ID: <20171122191028.GB7815@www.mrbrklyn.com> On Wed, Nov 22, 2017 at 01:43:09PM -0500, Ruben Safir wrote: > > > > Chris Cromer > > > On Wed, Nov 22, 2017 at 12:52 PM, Ruben Safir wrote: > > On Wed, Nov 22, 2017 at 12:23:21AM -0300, Chris Cromer wrote: > >> I admit that ICU getting pushed too soon was a problem. But the problem was > >> not because of a broken package. All those other packages needed to be > >> recompiled against the new libs since the ABI is incompatible in the new > >> lib. An unfortunate situation yes, but sometimes these things happen on a > >> rolling release distro. > >> > > > > > > That is incorrect. I was talking to Rick Moen about this last night and > > the packages are broken and were always broken and will continue to be > > broken. ICU is not a declared dependency in the packages although they > > are in the source files. > > Packages don't have to have "depends" declcared for every single > possible thing in the packages to link against them, it is enough that > they are installed by a dependency of a dependency. So if package C > depends on package B and package A, and package B depends on package > A, it is enough to make package C only depend on package B which forms > a chain of dependencies. BTW - yeah what you describe here seems to have failed. There should be a cascade of dependencies and they were broken. A is udate that should have caused B to be update which should have triggered C to be in conflict. or A is updated and then B and C needs to be updated which should have caused a conflict with E and F through B and G and H through C. If it fails in autoconf it should fail in the binary package. From chris at cromer.cl Wed Nov 22 23:12:20 2017 From: chris at cromer.cl (Chris Cromer) Date: Wed, 22 Nov 2017 18:12:20 -0300 Subject: [artix-general] icu - run both versions In-Reply-To: <41dff7c5-43f2-31de-8941-c3c631e2feb5@mrbrklyn.com> References: <41dff7c5-43f2-31de-8941-c3c631e2feb5@mrbrklyn.com> Message-ID: First of all tumbleweed has not been around that many years. It showed up in 2015. Which means that either you are lying, or that you are mistaken and were using standard opensuse which is not rolling release. And looking at their packages on their website, they only have 1 version of libraries. For example in tumbleweed they have ICU 59. And in opensuse 42.3 they only have ICU 52. They do not retain multiple versions of libraries like you claim. The only time a rolling distro has more than one version of a library is during a transition, once the transition is over the old library then gets removed. As far as how a problem happens with pacman. During a pacman upgrade, if it finds conflicting files, symlinks, or directories that it does not manage, it stop the whole upgrade. Basically the system cannot be upgraded until those conflicts are fixed. Since those files were not installed by pacman, they can't be touched by pacman causing pacman to be unable to continue an upgrade. This is a safety feature to prevent overwriting files that could cause issues or even loss of data. And in the case of ICU which is a critical library(needed by many packages including pacman), if they try to fix the conflict by hand and screw up they could be left with a broken system. You are free to fix your system in your way, I really don't care what you do with your system. But do not give your bad advice to others through public channels, especially since you are not responsible for fixing the consequences of said advice. > BTW - yeah what you describe here seems to have failed. There should > be a cascade of dependencies and they were broken. > > A is udate that should have caused B to be update which should have > triggered C to be in conflict. > > or A is updated and then B and C needs to be updated which should have > caused a conflict with E and F through B and G and H through C. > > If it fails in autoconf it should fail in the binary package. It failed for a very specific reason. Artix pushed ICU 60 before Arch Linux pushed ICU 60. In this case we were faster than arch linux to get the new packages pushed. The packages in arch's repos "extra" and "community" were not built against ICU 60 yet. The failure here is that we don't have 100% of arch forked yet. We are still working on compiling everything, but until the fork is at 100% completion these problems will happen from time to time. Once arch linux repos are 100% removed, this should not happen anymore. It's not the chain that is broken, it isn't the packages that are broken, it's the mixing of artix and arch linux repos. We already eliminated the "core" repo from arch linux. Next step is to eliminate "extra". And then sometime in the distant future eliminate "community". This is not an overnight process, this will take many months or even years, so stop complaining because it doesn't help anyone. Chris Cromer On Wed, Nov 22, 2017 at 3:43 PM, Ruben Safir wrote: > > > > Chris Cromer > > > On Wed, Nov 22, 2017 at 12:52 PM, Ruben Safir wrote: >> On Wed, Nov 22, 2017 at 12:23:21AM -0300, Chris Cromer wrote: >>> I admit that ICU getting pushed too soon was a problem. But the problem was >>> not because of a broken package. All those other packages needed to be >>> recompiled against the new libs since the ABI is incompatible in the new >>> lib. An unfortunate situation yes, but sometimes these things happen on a >>> rolling release distro. >>> >> >> >> That is incorrect. I was talking to Rick Moen about this last night and >> the packages are broken and were always broken and will continue to be >> broken. ICU is not a declared dependency in the packages although they >> are in the source files. > > Packages don't have to have "depends" declcared for every single > possible thing in the packages to link against them, it is enough that > they are installed by a dependency of a dependency. So if package C > depends on package B and package A, and package B depends on package > A, it is enough to make package C only depend on package B which forms > a chain of dependencies. There is not need to put package A as > dependency in package C because B will already pull it in as one of > its dependencies. The fact that you don't realize this means that you > have very limited knowledge of how packaging actually works. And > frankly I don't care what "Rick Moen" says, the truth is that those > supposedly broken packages as you call them are linked to ICU when > they were compiled and had to be recompiled to link against the new > version of ICU. They were not "broken", they needed to be updated for > the new ICU version. > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Hello Chris. For major libraries this is commonly not necessary as they > are linked as stdc++ ect > > It is the smaller libraries that pose this problem and they should be > 100% listed with all there dependencies. > > Understand, tumbleweed, which is the opensuse rolling release I had for > years rarely if ever had this problem. Now maybe that is a manpower > issue, and you folks are working your tushas off to get artix up to > speed, but I have SEEN library dependencies cause package management > systems retain libraries in rolling releases, and with Manjaro, that was > an issue with gtk3 where there was no upgrade path without removing > needed packages ... which was a PIA. > > > But I don't feel compelled, and neither should you, to chose between > 100% package management and 100% code base. Of course, once one goes > off the package management system, its on you, not the artix core > developers or the arch people. But OTOH, in this instance, what are you > gonna lose? The benefits are greater than the losses. > > Show me how having a spare unmonitored icu library from ARCH presents a > problem and be specific. It over writes NOTHING. It lives in its own space. > From artoo at cromnix.org Wed Nov 22 23:22:48 2017 From: artoo at cromnix.org (artoo) Date: Wed, 22 Nov 2017 22:22:48 +0100 Subject: [artix-general] icu - run both versions In-Reply-To: References: <41dff7c5-43f2-31de-8941-c3c631e2feb5@mrbrklyn.com> Message-ID: To explain further, we have not and had not broken icu packages. What we had, is that arch linux had some of their rebuild in their testing repo, which wasn't listed by default in pacman.conf as commented. I fixed that, pacman got a rebuild with updated pacman.conf after icu was bumped and built. All correct. The problems occurred, if people had our testing repos enabled, but not the arch testing repo. since we are still in the process to have a complet set of build dependencies in our repos, such things may happen, until we can disable arch repos one by one and remove the arch repo dependency. On 22.11.2017 22:12, Chris Cromer wrote: > First of all tumbleweed has not been around that many years. It showed > up in 2015. Which means that either you are lying, or that you are > mistaken and were using standard opensuse which is not rolling > release. And looking at their packages on their website, they only > have 1 version of libraries. For example in tumbleweed they have ICU > 59. And in opensuse 42.3 they only have ICU 52. They do not retain > multiple versions of libraries like you claim. The only time a rolling > distro has more than one version of a library is during a transition, > once the transition is over the old library then gets removed. > > As far as how a problem happens with pacman. During a pacman upgrade, > if it finds conflicting files, symlinks, or directories that it does > not manage, it stop the whole upgrade. Basically the system cannot be > upgraded until those conflicts are fixed. Since those files were not > installed by pacman, they can't be touched by pacman causing pacman to > be unable to continue an upgrade. This is a safety feature to prevent > overwriting files that could cause issues or even loss of data. And in > the case of ICU which is a critical library(needed by many packages > including pacman), if they try to fix the conflict by hand and screw > up they could be left with a broken system. > > You are free to fix your system in your way, I really don't care what > you do with your system. But do not give your bad advice to others > through public channels, especially since you are not responsible for > fixing the consequences of said advice. > >> BTW - yeah what you describe here seems to have failed. There should >> be a cascade of dependencies and they were broken. >> >> A is udate that should have caused B to be update which should have >> triggered C to be in conflict. >> >> or A is updated and then B and C needs to be updated which should have >> caused a conflict with E and F through B and G and H through C. >> >> If it fails in autoconf it should fail in the binary package. > It failed for a very specific reason. Artix pushed ICU 60 before Arch > Linux pushed ICU 60. In this case we were faster than arch linux to > get the new packages pushed. The packages in arch's repos "extra" and > "community" were not built against ICU 60 yet. The failure here is > that we don't have 100% of arch forked yet. We are still working on > compiling everything, but until the fork is at 100% completion these > problems will happen from time to time. Once arch linux repos are 100% > removed, this should not happen anymore. It's not the chain that is > broken, it isn't the packages that are broken, it's the mixing of > artix and arch linux repos. We already eliminated the "core" repo from > arch linux. Next step is to eliminate "extra". And then sometime in > the distant future eliminate "community". This is not an overnight > process, this will take many months or even years, so stop complaining > because it doesn't help anyone. > Chris Cromer > > > On Wed, Nov 22, 2017 at 3:43 PM, Ruben Safir wrote: >> >> >> Chris Cromer >> >> >> On Wed, Nov 22, 2017 at 12:52 PM, Ruben Safir wrote: >>> On Wed, Nov 22, 2017 at 12:23:21AM -0300, Chris Cromer wrote: >>>> I admit that ICU getting pushed too soon was a problem. But the problem was >>>> not because of a broken package. All those other packages needed to be >>>> recompiled against the new libs since the ABI is incompatible in the new >>>> lib. An unfortunate situation yes, but sometimes these things happen on a >>>> rolling release distro. >>>> >>> >>> That is incorrect. I was talking to Rick Moen about this last night and >>> the packages are broken and were always broken and will continue to be >>> broken. ICU is not a declared dependency in the packages although they >>> are in the source files. >> Packages don't have to have "depends" declcared for every single >> possible thing in the packages to link against them, it is enough that >> they are installed by a dependency of a dependency. So if package C >> depends on package B and package A, and package B depends on package >> A, it is enough to make package C only depend on package B which forms >> a chain of dependencies. There is not need to put package A as >> dependency in package C because B will already pull it in as one of >> its dependencies. The fact that you don't realize this means that you >> have very limited knowledge of how packaging actually works. And >> frankly I don't care what "Rick Moen" says, the truth is that those >> supposedly broken packages as you call them are linked to ICU when >> they were compiled and had to be recompiled to link against the new >> version of ICU. They were not "broken", they needed to be updated for >> the new ICU version. >> >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> Hello Chris. For major libraries this is commonly not necessary as they >> are linked as stdc++ ect >> >> It is the smaller libraries that pose this problem and they should be >> 100% listed with all there dependencies. >> >> Understand, tumbleweed, which is the opensuse rolling release I had for >> years rarely if ever had this problem. Now maybe that is a manpower >> issue, and you folks are working your tushas off to get artix up to >> speed, but I have SEEN library dependencies cause package management >> systems retain libraries in rolling releases, and with Manjaro, that was >> an issue with gtk3 where there was no upgrade path without removing >> needed packages ... which was a PIA. >> >> >> But I don't feel compelled, and neither should you, to chose between >> 100% package management and 100% code base. Of course, once one goes >> off the package management system, its on you, not the artix core >> developers or the arch people. But OTOH, in this instance, what are you >> gonna lose? The benefits are greater than the losses. >> >> Show me how having a spare unmonitored icu library from ARCH presents a >> problem and be specific. It over writes NOTHING. It lives in its own space. >> From ruben at mrbrklyn.com Wed Nov 22 23:53:35 2017 From: ruben at mrbrklyn.com (Ruben Safir) Date: Wed, 22 Nov 2017 16:53:35 -0500 Subject: [artix-general] icu - run both versions In-Reply-To: References: <41dff7c5-43f2-31de-8941-c3c631e2feb5@mrbrklyn.com> Message-ID: <20171122215335.GC8880@www.mrbrklyn.com> On Wed, Nov 22, 2017 at 06:12:20PM -0300, Chris Cromer wrote: > First of all tumbleweed has not been around that many years. It showed > up in 2015. FWIW: For the opensuse site: On November 4th 2014 the Tumbleweed rolling release and Factory rolling release merged, leaving the single openSUSE Tumbleweed rolling release we have today Its been around way before 2014, but don't ask me the complete history. > Which means that either you are lying, or that you are > mistaken and were using standard opensuse which is not rolling > release. And looking at their packages on their website, they only > have 1 version of libraries. For example in tumbleweed they have ICU > 59. And in opensuse 42.3 they only have ICU 52. They do not retain > multiple versions of libraries like you claim. The only time a rolling > distro has more than one version of a library is during a transition, > once the transition is over the old library then gets removed. I only have one opensuse server left with the conversions to artix /usr/lib/gcc/i586-suse-linux/4.8/libstdc++.a /usr/lib/gcc/i586-suse-linux/4.8/libstdc++.so /usr/lib/gcc/i586-suse-linux/4.9/libstdc++.a /usr/lib/gcc/i586-suse-linux/4.9/libstdc++.so I'm actually suprised how clean it is. > > As far as how a problem happens with pacman. During a pacman upgrade, > if it finds conflicting files, symlinks, or directories that it does > not manage, it stop the whole upgrade. That doesn't seem to stop it from rewriting my mysql configuation repeatedly. I would need to have a clearer understanding of the rules because at the moment, my workstation is a chock ful of such things, including multiple perl, pythons, netbeans, and other non-pacman aps and libraries and pacman doesn't seem to care less. It would be somewhat helpful if it did do that. Then it would stop rewriting my netbeans configs. [www3 ~]# pacman -S icu warning: icu-60.1-1 is up to date -- reinstalling resolving dependencies... looking for conflicting packages... Packages (1) icu-60.1-1 Total Installed Size: 34.98 MiB Net Upgrade Size: 0.00 MiB :: Proceed with installation? [Y/n] Y (1/1) checking keys in keyring [####################################################] 100% (1/1) checking package integrity [####################################################] 100% (1/1) loading package files [####################################################] 100% (1/1) checking for file conflicts [####################################################] 100% (1/1) checking available disk space [####################################################] 100% :: Processing package changes... (1/1) reinstalling icu [www3 ~]# ls -al /usr/lib/libicu* lrwxrwxrwx 1 root root 18 Nov 13 05:40 /usr/lib/libicudata.so -> libicudata.so.60.1 lrwxrwxrwx 1 root root 18 Aug 22 05:51 /usr/lib/libicudata.so.59 -> libicudata.so.59.1 -rwxr-xr-x 1 root root 26292888 Aug 22 05:51 /usr/lib/libicudata.so.59.1 lrwxrwxrwx 1 root root 18 Nov 13 05:40 /usr/lib/libicudata.so.60 -> libicudata.so.60.1 -rwxr-xr-x 1 root root 26825368 Nov 13 05:40 /usr/lib/libicudata.so.60.1 lrwxrwxrwx 1 root root 18 Nov 13 05:40 /usr/lib/libicui18n.so -> libicui18n.so.60.1 lrwxrwxrwx 1 root root 18 Aug 22 05:51 /usr/lib/libicui18n.so.59 -> libicui18n.so.59.1 -rwxr-xr-x 1 root root 2599040 Aug 22 05:51 /usr/lib/libicui18n.so.59.1 lrwxrwxrwx 1 root root 18 Nov 13 05:40 /usr/lib/libicui18n.so.60 -> libicui18n.so.60.1 -rwxr-xr-x 1 root root 2762816 Nov 13 05:40 /usr/lib/libicui18n.so.60.1 lrwxrwxrwx 1 root root 16 Nov 13 05:40 /usr/lib/libicuio.so -> libicuio.so.60.1 lrwxrwxrwx 1 root root 16 Aug 22 05:51 /usr/lib/libicuio.so.59 -> libicuio.so.59.1 -rwxr-xr-x 1 root root 55056 Aug 22 05:51 /usr/lib/libicuio.so.59.1 lrwxrwxrwx 1 root root 16 Nov 13 05:40 /usr/lib/libicuio.so.60 -> libicuio.so.60.1 -rwxr-xr-x 1 root root 55056 Nov 13 05:40 /usr/lib/libicuio.so.60.1 lrwxrwxrwx 1 root root 18 Nov 13 05:40 /usr/lib/libicutest.so -> libicutest.so.60.1 lrwxrwxrwx 1 root root 18 Aug 22 05:51 /usr/lib/libicutest.so.59 -> libicutest.so.59.1 -rwxr-xr-x 1 root root 64616 Aug 22 05:51 /usr/lib/libicutest.so.59.1 lrwxrwxrwx 1 root root 18 Nov 13 05:40 /usr/lib/libicutest.so.60 -> libicutest.so.60.1 -rwxr-xr-x 1 root root 64616 Nov 13 05:40 /usr/lib/libicutest.so.60.1 lrwxrwxrwx 1 root root 16 Nov 13 05:40 /usr/lib/libicutu.so -> libicutu.so.60.1 lrwxrwxrwx 1 root root 16 Aug 22 05:51 /usr/lib/libicutu.so.59 -> libicutu.so.59.1 -rwxr-xr-x 1 root root 203288 Aug 22 05:51 /usr/lib/libicutu.so.59.1 lrwxrwxrwx 1 root root 16 Nov 13 05:40 /usr/lib/libicutu.so.60 -> libicutu.so.60.1 -rwxr-xr-x 1 root root 203288 Nov 13 05:40 /usr/lib/libicutu.so.60.1 lrwxrwxrwx 1 root root 16 Nov 13 05:40 /usr/lib/libicuuc.so -> libicuuc.so.60.1 lrwxrwxrwx 1 root root 16 Aug 22 05:51 /usr/lib/libicuuc.so.59 -> libicuuc.so.59.1 -rwxr-xr-x 1 root root 1763088 Aug 22 05:51 /usr/lib/libicuuc.so.59.1 lrwxrwxrwx 1 root root 16 Nov 13 05:40 /usr/lib/libicuuc.so.60 -> libicuuc.so.60.1 -rwxr-xr-x 1 root root 1799952 Nov 13 05:40 /usr/lib/libicuuc.so.60.1 > Basically the system cannot be > upgraded until those conflicts are fixed. Well, it hasn't yet discovered them then. > Since those files were not > installed by pacman, they can't be touched by pacman causing pacman to > be unable to continue an upgrade. This is a safety feature to prevent > overwriting files that could cause issues or even loss of data. And in > the case of ICU which is a critical library(needed by many packages > including pacman), if they try to fix the conflict by hand and screw > up they could be left with a broken system. > Nous, you do know that people WILL try to fix their boxes when they are broken and rational information is better than the clueless pulling ideas out of umbuntu's forum and break there boxes. You also are aware that breaking systems is not the exclussive domain of people downloading source code. Package management systems are very capable of doing this on a routine basis. There simply is no wall of perfection and a great and powerful OZ behind the package maintainers. There is just bright, honest, hard working people doing their level best without enough resources You don't want to encourage these guys to flood the forum complaining that the artix developers aren't moving fast enough and are sloppy. This is a result of not just the dark side of human nature, but also by creating an expectation of dependency. > You are free to fix your system in your way, I really don't care what > you do with your system. But do not give your bad advice to others > through public channels, especially since you are not responsible for > fixing the consequences of said advice. > > > BTW - yeah what you describe here seems to have failed. There should > > be a cascade of dependencies and they were broken. > > > > A is udate that should have caused B to be update which should have > > triggered C to be in conflict. > > > > or A is updated and then B and C needs to be updated which should have > > caused a conflict with E and F through B and G and H through C. > > > > If it fails in autoconf it should fail in the binary package. > > It failed for a very specific reason. Artix pushed ICU 60 before Arch > Linux pushed ICU 60. Yeah that should have caused a whole cascade of pacman errors and warning right there... however... > In this case we were faster than arch linux to > get the new packages pushed. The packages in arch's repos "extra" and > "community" were not built against ICU 60 yet. The failure here is > that we don't have 100% of arch forked yet. We are still working on > compiling everything, but until the fork is at 100% completion these > problems will happen from time to time. That is really cool to hear! Do we have the manpwoer to pull that off over the long haul? Can I help? Package management problems are common and often on ALL distros, although some are better than others. You are never going to put an end to them and there will always be programs and projects, many on github now, which are outside of normal package channels, so one needs to learn to use the system and tell folks they are rescricted blindly to the package manager for the rest of their lives is counter productive and violates rule one of Free Software, which is that we empower the end user and strengthen them with knowledge. I'll make you a gentlemans bet right now that for Junior Cheese cakes that in 5 years that iuc59 sitting on the system will cause ZERO admin problems for pacman. > Once arch linux repos are 100% > removed, this should not happen anymore. It's not the chain that is > broken, it isn't the packages that are broken, it's the mixing of > artix and arch linux repos. We already eliminated the "core" repo from > arch linux. Next step is to eliminate "extra". And then sometime in > the distant future eliminate "community". This is not an overnight > process, this will take many months or even years, so stop complaining > because it doesn't help anyone. There hasn't been a __single word__ of complaint about the project by me ... kid :) This has been the best thing I've been able to evaluate which is currently developing. > Chris Cromer > > > On Wed, Nov 22, 2017 at 3:43 PM, Ruben Safir wrote: > > > > > > > > Chris Cromer > > > > > > On Wed, Nov 22, 2017 at 12:52 PM, Ruben Safir wrote: > >> On Wed, Nov 22, 2017 at 12:23:21AM -0300, Chris Cromer wrote: > >>> I admit that ICU getting pushed too soon was a problem. But the problem was > >>> not because of a broken package. All those other packages needed to be > >>> recompiled against the new libs since the ABI is incompatible in the new > >>> lib. An unfortunate situation yes, but sometimes these things happen on a > >>> rolling release distro. > >>> > >> > >> > >> That is incorrect. I was talking to Rick Moen about this last night and > >> the packages are broken and were always broken and will continue to be > >> broken. ICU is not a declared dependency in the packages although they > >> are in the source files. > > > > Packages don't have to have "depends" declcared for every single > > possible thing in the packages to link against them, it is enough that > > they are installed by a dependency of a dependency. So if package C > > depends on package B and package A, and package B depends on package > > A, it is enough to make package C only depend on package B which forms > > a chain of dependencies. There is not need to put package A as > > dependency in package C because B will already pull it in as one of > > its dependencies. The fact that you don't realize this means that you > > have very limited knowledge of how packaging actually works. And > > frankly I don't care what "Rick Moen" says, the truth is that those > > supposedly broken packages as you call them are linked to ICU when > > they were compiled and had to be recompiled to link against the new > > version of ICU. They were not "broken", they needed to be updated for > > the new ICU version. > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Hello Chris. For major libraries this is commonly not necessary as they > > are linked as stdc++ ect > > > > It is the smaller libraries that pose this problem and they should be > > 100% listed with all there dependencies. > > > > Understand, tumbleweed, which is the opensuse rolling release I had for > > years rarely if ever had this problem. Now maybe that is a manpower > > issue, and you folks are working your tushas off to get artix up to > > speed, but I have SEEN library dependencies cause package management > > systems retain libraries in rolling releases, and with Manjaro, that was > > an issue with gtk3 where there was no upgrade path without removing > > needed packages ... which was a PIA. > > > > > > But I don't feel compelled, and neither should you, to chose between > > 100% package management and 100% code base. Of course, once one goes > > off the package management system, its on you, not the artix core > > developers or the arch people. But OTOH, in this instance, what are you > > gonna lose? The benefits are greater than the losses. > > > > Show me how having a spare unmonitored icu library from ARCH presents a > > problem and be specific. It over writes NOTHING. It lives in its own space. > > -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 From rick at linuxmafia.com Thu Nov 23 05:27:23 2017 From: rick at linuxmafia.com (Rick Moen) Date: Wed, 22 Nov 2017 19:27:23 -0800 Subject: [artix-general] Re: [Hangout - NYLXS] [artix-general] icu - run both versions In-Reply-To: References: <41dff7c5-43f2-31de-8941-c3c631e2feb5@mrbrklyn.com> Message-ID: <20171123032722.GA12588@linuxmafia.com> Quoting Chris Cromer (chris at cromer.cl): > And frankly I don't care what "Rick Moen" says, the truth is that > those supposedly broken packages as you call them are linked to ICU > when they were compiled and had to be recompiled to link against the > new version of ICU. For what it's worth, the gentleman is _not_ correctly paraphrasing what I told him, when he consulted me in private mail. The greater part of what I said to him was: I advised him that he should listen to your good advice about package management and you were correct on that point. Moreover, I cited where I've been giving that same advice for decades, such as when I was a technical editor for _Linux Gazette_, over many long years: http://linuxmafia.com/~rick/weatherwax.html#1 He persists in arguing against the need for packaging for particular system software. I said I was not going to repeat myself, but wished him good luck. (Which I wholeheartedly do.) Thank you for Artix, a distribution I don't (yet) use, but do admire and support. -- Cheers, Rick Moen "So, every time a new iPhone's about to come out, rick at linuxmafia.com one will get left in a bar? Apple's like a clumsy, McQ! (4x80) alcoholic Easter Bunny." -- Rex Huppke From chris at cromer.cl Thu Nov 23 12:01:55 2017 From: chris at cromer.cl (Chris Cromer) Date: Thu, 23 Nov 2017 07:01:55 -0300 Subject: [artix-general] Re: [Hangout - NYLXS] [artix-general] icu - run both versions In-Reply-To: References: <41dff7c5-43f2-31de-8941-c3c631e2feb5@mrbrklyn.com> <20171123032722.GA12588@linuxmafia.com> Message-ID: Thanks for chiming in to let us know, it is appreciated. And thank you for the support. Chris Cromer On Nov 23, 2017 12:27 AM, "Rick Moen" wrote: Quoting Chris Cromer (chris at cromer.cl): > And frankly I don't care what "Rick Moen" says, the truth is that > those supposedly broken packages as you call them are linked to ICU > when they were compiled and had to be recompiled to link against the > new version of ICU. For what it's worth, the gentleman is _not_ correctly paraphrasing what I told him, when he consulted me in private mail. The greater part of what I said to him was: I advised him that he should listen to your good advice about package management and you were correct on that point. Moreover, I cited where I've been giving that same advice for decades, such as when I was a technical editor for _Linux Gazette_, over many long years: http://linuxmafia.com/~rick/weatherwax.html#1 He persists in arguing against the need for packaging for particular system software. I said I was not going to repeat myself, but wished him good luck. (Which I wholeheartedly do.) Thank you for Artix, a distribution I don't (yet) use, but do admire and support. -- Cheers, Rick Moen "So, every time a new iPhone's about to come out, rick at linuxmafia.com one will get left in a bar? Apple's like a clumsy, McQ! (4x80) alcoholic Easter Bunny." -- Rex Huppke -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick at linuxmafia.com Thu Nov 23 12:31:37 2017 From: rick at linuxmafia.com (Rick Moen) Date: Thu, 23 Nov 2017 02:31:37 -0800 Subject: [artix-general] Re: [Hangout - NYLXS] [artix-general] icu - run both versions In-Reply-To: References: <41dff7c5-43f2-31de-8941-c3c631e2feb5@mrbrklyn.com> <20171123032722.GA12588@linuxmafia.com> Message-ID: <20171123103137.GA25363@linuxmafia.com> Quoting Chris Cromer (chris at cromer.cl): > Thanks for chiming in to let us know, it is appreciated. And thank you for > the support. I should also hasten to add that I'm certain the mis-paraphrasing was inadvertent. Ruben is a valued and well-intended friend who is passionate about maintainable (and non-systemd-based) Linux systems and about open source / free software. He's blunt and direct (like the fellow I see in the mirror), doesn't always do all of his homework, is stubborn (like the fellow I see in the mirror), and does his absolute best for the cause of software freedom. Please read what he says in a spirit of good will and friendship. You won't regret it. (Much. ;-> ) From nous at artixlinux.org Thu Nov 23 12:57:38 2017 From: nous at artixlinux.org (Christos Nouskas) Date: Thu, 23 Nov 2017 12:57:38 +0200 Subject: [artix-general] icu - run both versions In-Reply-To: <20171122215335.GC8880@www.mrbrklyn.com> References: <41dff7c5-43f2-31de-8941-c3c631e2feb5@mrbrklyn.com> <20171122215335.GC8880@www.mrbrklyn.com> Message-ID: On 22 November 2017 at 23:53, Ruben Safir wrote: > On Wed, Nov 22, 2017 at 06:12:20PM -0300, Chris Cromer wrote: >> As far as how a problem happens with pacman. During a pacman upgrade, >> if it finds conflicting files, symlinks, or directories that it does >> not manage, it stop the whole upgrade. > > That doesn't seem to stop it from rewriting my mysql configuation > repeatedly. I would need to have a clearer understanding of the rules > because at the moment, my workstation is a chock ful of such things, > including multiple perl, pythons, netbeans, and other non-pacman aps and > libraries and pacman doesn't seem to care less. It would be somewhat > helpful if it did do that. Then it would stop rewriting my netbeans > configs. Something is not right here. Read pacman(8), section "HANDLING CONFIG FILES". What _might_ be happening is that some install script is doing this, not pacman itself. From fungilife at protonmail.com Fri Nov 24 07:43:52 2017 From: fungilife at protonmail.com (Fungi4All) Date: Fri, 24 Nov 2017 00:43:52 -0500 Subject: [artix-general] Re: [Hangout - NYLXS] [artix-general] icu - run both versions In-Reply-To: <20171123032722.GA12588@linuxmafia.com> References: <41dff7c5-43f2-31de-8941-c3c631e2feb5@mrbrklyn.com> <20171123032722.GA12588@linuxmafia.com> Message-ID: <2ZTN9ltB7C2ylJpgfBeqh4uStt60CzVpgIWq_knApx9uv6E8ep0uLmQw2XhX8IsYBmg9ykOnLzhzdrRhvsWeht-3HwiKyt4CY6LOPwss_h8=@protonmail.com> qt5-sensors-5.9.3-1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). -------------- next part -------------- An HTML attachment was scrubbed... URL: From p3d3f at riseup.net Fri Nov 24 12:12:32 2017 From: p3d3f at riseup.net (P3d3.F.) Date: Fri, 24 Nov 2017 11:12:32 +0100 Subject: [artix-general] DELL Inspiron 5767 Installation In-Reply-To: References: <41dff7c5-43f2-31de-8941-c3c631e2feb5@mrbrklyn.com> <20171122215335.GC8880@www.mrbrklyn.com> Message-ID: Hi Nous, while waiting that the website come back operational, and the wiki too), I tryed to install Artix on a DELL Inspiron 5767 (CPU Kaby Lake 3,1Ghz, 8Gb RAM, GPU Intel integrated, HD 1Tb) and I'm having some VERY strange behaviours. ARTIX last ISO: no way to start the installation from the USB Key. I controlled everything (md5, sha, etc...) and used the same key to install another notebook, without problems. The error: no way to read the data from the USB and pushed in the root emergency environment ARTIX august ISO: it work perfectly and I'm able to use the LXQT environment and to start calamares without any problems ARCHBANG: last iso 021117, all work perfectly and the openbox environment start in a while Do you have any idea of what is different between the new and old Artix ISO? I suspect something linked with the Kernel (ARCHBANG use a 4.13 kernel). Trying some parameters before to start, if I use the noapic the startup step arrive till the tty activation, before to crash. Should be interesting to discover the why, just to avoid that other people, with a similar machine (Kaby Lake CPU are widely used) have the same problem. I tryed both in legacy and UEFI mode, and the error is the same. Obviously I deactivate, from the BIOS, the Secure Boot Option and also the Fastboot. If you have any idea, I can do some tests. Ciao Francesco -- P3d3f Mobile1: +39-366-4xxxxxx Mail: p3d3f at riseup.net From damnwidget at gmail.com Fri Nov 24 13:00:45 2017 From: damnwidget at gmail.com (Oscar Campos) Date: Fri, 24 Nov 2017 11:00:45 +0000 Subject: [artix-general] DELL Inspiron 5767 Installation In-Reply-To: References: <41dff7c5-43f2-31de-8941-c3c631e2feb5@mrbrklyn.com> <20171122215335.GC8880@www.mrbrklyn.com> Message-ID: Weird, that ISO works for me in my laptop model name : Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz We should create a new ISO soon anyway On 24 November 2017 at 10:12, P3d3.F. wrote: > Hi Nous, > while waiting that the website come back operational, and the wiki too), I > tryed to install Artix on a DELL Inspiron 5767 (CPU Kaby Lake 3,1Ghz, 8Gb > RAM, GPU Intel integrated, HD 1Tb) and I'm having some VERY strange > behaviours. > > ARTIX last ISO: no way to start the installation from the USB Key. I > controlled everything (md5, sha, etc...) and used the same key to install > another notebook, without problems. The error: no way to read the data from > the USB and pushed in the root emergency environment > > ARTIX august ISO: it work perfectly and I'm able to use the LXQT > environment and to start calamares without any problems > > ARCHBANG: last iso 021117, all work perfectly and the openbox environment > start in a while > > Do you have any idea of what is different between the new and old Artix > ISO? I suspect something linked with the Kernel (ARCHBANG use a 4.13 > kernel). Trying some parameters before to start, if I use the noapic the > startup step arrive till the tty activation, before to crash. > > Should be interesting to discover the why, just to avoid that other > people, with a similar machine (Kaby Lake CPU are widely used) have the > same problem. I tryed both in legacy and UEFI mode, and the error is the > same. Obviously I deactivate, from the BIOS, the Secure Boot Option and > also the Fastboot. > > If you have any idea, I can do some tests. > > Ciao Francesco > > -- > P3d3f > > Mobile1: +39-366-4xxxxxx > Mail: p3d3f at riseup.net > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nouskas at gmail.com Fri Nov 24 14:13:55 2017 From: nouskas at gmail.com (=?UTF-8?B?zqfPgeG/hs+Dz4TOv8+CIM6dzr/Pjc+DzrrOsc+CIChDaHJpc3RvcyBOb3Vza2FzKQ==?=) Date: Fri, 24 Nov 2017 14:13:55 +0200 Subject: [artix-general] DELL Inspiron 5767 Installation In-Reply-To: References: <41dff7c5-43f2-31de-8941-c3c631e2feb5@mrbrklyn.com> <20171122215335.GC8880@www.mrbrklyn.com> Message-ID: We're back online! On the ISO issue, I had boot problems with a kabylake desktop too, linux-ck-4.13 kernel. Booted fine on our lts though. ???? 24 ??? 2017 12:12 ?.?., ? ??????? "P3d3.F." ??????: > Hi Nous, > while waiting that the website come back operational, and the wiki too), I > tryed to install Artix on a DELL Inspiron 5767 (CPU Kaby Lake 3,1Ghz, 8Gb > RAM, GPU Intel integrated, HD 1Tb) and I'm having some VERY strange > behaviours. > > ARTIX last ISO: no way to start the installation from the USB Key. I > controlled everything (md5, sha, etc...) and used the same key to install > another notebook, without problems. The error: no way to read the data from > the USB and pushed in the root emergency environment > > ARTIX august ISO: it work perfectly and I'm able to use the LXQT > environment and to start calamares without any problems > > ARCHBANG: last iso 021117, all work perfectly and the openbox environment > start in a while > > Do you have any idea of what is different between the new and old Artix > ISO? I suspect something linked with the Kernel (ARCHBANG use a 4.13 > kernel). Trying some parameters before to start, if I use the noapic the > startup step arrive till the tty activation, before to crash. > > Should be interesting to discover the why, just to avoid that other > people, with a similar machine (Kaby Lake CPU are widely used) have the > same problem. I tryed both in legacy and UEFI mode, and the error is the > same. Obviously I deactivate, from the BIOS, the Secure Boot Option and > also the Fastboot. > > If you have any idea, I can do some tests. > > Ciao Francesco > > -- > P3d3f > > Mobile1: +39-366-4xxxxxx > Mail: p3d3f at riseup.net > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p3d3f at riseup.net Fri Nov 24 14:17:54 2017 From: p3d3f at riseup.net (P3d3.F.) Date: Fri, 24 Nov 2017 13:17:54 +0100 Subject: [artix-general] DELL Inspiron 5767 Installation In-Reply-To: References: <41dff7c5-43f2-31de-8941-c3c631e2feb5@mrbrklyn.com> <20171122215335.GC8880@www.mrbrklyn.com> Message-ID: <93d5b31a-a601-e8b2-72bc-f712ee6d8123@riseup.net> I've seen that the site is back :) About the Kaby Lake, its really strange that something work and something not (I tried also with LinuxMint: no way; and Antergos: errors but charge). The old ISO go smooth, the new Archbang too, maybe that that is the direction to verify. If you need I can test. On 24/11/2017 13:13, ??????? ??????? (Christos Nouskas) wrote: > We're back online! On the ISO issue, ?I had boot problems with a > kabylake desktop too, linux-ck-4.13 kernel. Booted fine on our lts though. > > ???? 24 ??? 2017 12:12 ?.?., ? ??????? "P3d3.F." > ??????: > > Hi Nous, > while waiting that the website come back operational, and the wiki > too), I tryed to install Artix on a DELL Inspiron 5767 (CPU Kaby > Lake 3,1Ghz, 8Gb RAM, GPU Intel integrated, HD 1Tb) and I'm having > some VERY strange behaviours. > > ARTIX last ISO: no way to start the installation from the USB Key. > I controlled everything (md5, sha, etc...) and used the same key > to install another notebook, without problems. The error: no way > to read the data from the USB and pushed in the root emergency > environment > > ARTIX august ISO: it work perfectly and I'm able to use the LXQT > environment and to start calamares without any problems > > ARCHBANG: last iso 021117, all work perfectly and the openbox > environment start in a while > > Do you have any idea of what is different between the new and old > Artix ISO? I suspect something linked with the Kernel (ARCHBANG > use a 4.13 kernel). Trying some parameters before to start, if I > use the noapic the startup step arrive till the tty activation, > before to crash. > > Should be interesting to discover the why, just to avoid that > other people, with a similar machine (Kaby Lake CPU are widely > used) have the same problem. I tryed both in legacy and UEFI mode, > and the error is the same. Obviously I deactivate, from the BIOS, > the Secure Boot Option and also the Fastboot. > > If you have any idea, I can do some tests. > > Ciao Francesco > > -- > P3d3f > > Mobile1: +39-366-4xxxxxx > Mail: p3d3f at riseup.net > -- P3d3f Mobile1: +39-366-4xxxxxx Mail: p3d3f at riseup.net -------------- next part -------------- An HTML attachment was scrubbed... URL: