Re: Ctl+Alt+F7 fails!

[Doug Newgard]

On Fri, 30 Aug 2024 19:51:14 +0200
Ralf Mardorf  wrote:

> Hi,
>
> Ctl+Alt+F7 fails!
>
> I need to restart the machine.
>
> $ pacman -Q linux
> linux 6.10.7.arch1-1
>
> 2fucktor auth fails as well ;), hence I cannot provide a bug report.
>
> I was able to log in https://gitlab.archlinux.org/

Explore groups · GitLab
GitLab Enterprise Edition
gitlab.archlinux.org
a few hours ago.
> I've had enough by now!
>
> I cannot report the issue against the bug tracker, maybe somebody is
> willing to care about the issue here.
>
> Consider to stop this 2fucktor auth crap!
>
> Regards,
> Ralf
>
>

There's no issue to create, ctl-alt-f7 isn't supposed to just magically do
anything specific, and you haven't actually shown an issue at all. Maybe take a
step back and put together a coherent thought before sending emails like this?

Re: this happens with pacman too

[Doug Newgard]

> From: Jude DaShiell 
>
> Time to reinstall system.

A quick scan through, I don't notice that many problems, certainly nothing that 
indicates the system needs reinstalled. Backup files being altered is normal, 
and permissions mismatches are not uncommon and don't necessarily indicate a 
problem. The mtree file issues are definitely a problem.

Re: this happens with pacman too

[Doug Newgard]

On Tue, 30 Jul 2024 14:09:07 -0400
Jude DaShiell  wrote:

> What I cannot figure out is why all of the ldconfig errors on empty files.
> Is something broken and if so what should be done to fix it?

It means filesystem corruption. All of those files will need reinstalled, and
you'll want to check your system with pacman -Qkk to see what other packages
might be corrupt. Good chance you'll need:
https://wiki.archlinux.org/title/Pacman#%22Failed_to_commit_transaction_(conflicting_files)%22_error

Re: libassuan 3.0.1-1 pulled from testing after crashing pacman

[Doug Newgard]

On Mon, 22 Jul 2024 12:15:26 -0400
Genes Lists  wrote:

> It does bring up a question and am interested how you think about it.
> 
> While pretty rare, there certainly can be occasions where an official
> static pacman could be pretty helpful to have.
> 

See the note at https://aur.archlinux.org/packages/pacman-static

It's from a PM and hosted on Arch infrastructure

Re: openssh 9.8p1-1

[Doug Newgard]

On Mon, 1 Jul 2024 20:57:31 +0200
mpan  wrote:

> > (…) If you don't restart sshd, and then attempt to ssh into the remote,
> > it may fail with: (…)  
>Note that one *must* restart sshd regardless. Updating the files 
> isn’t fixing the vulnerability. The old, vulnerable version of the 
> process is still running until the service is restarted.
> 
> Cheers
> 

That's outside the scope of the issue being discussed here, though. Not all ssh
servers are publicly accessible, making the vulnerability much less of a
concern.

Re: JDK/JRE and older Java versions

[Doug Newgard]

On Sun, 28 Apr 2024 12:44:03 +0200
Peter Nabbefeld  wrote:

> On 23.04.24 18:28, Doug Newgard wrote:
> > On Tue, 23 Apr 2024 08:49:21 +0200
> > Peter Nabbefeld  wrote:
> >  
> >> Hello,
> >>
> >> as a Java developer, I sometimes need to do compatibility checking using
> >> older versions, often using JRE, while I need a JDK for development.
> >>
> >> When I tried to update arch linux now, I found I cannot start any update
> >> because the update is blocked by setting JRE and JDK as conflicting
> >> packages. I tried to only install JDK 21, but the update is still being
> >> blocked because of my older versions of the JRE.
> >>
> >> Why do You block any software installation? I don't like the idea to
> >> enforce me to use any specific software, or to remove any specific one.
> >> Is there any possibility to remove the lock-in?
> >>
> >> Kind regards,
> >> Peter
> >>  
> > There is no blocking or lock-in. First off, see
> > https://archlinux.org/news/incoming-changes-in-jdk-jre-21-packages-may-require-manual-intervention/
> > which now applies to some of the older versions as well.  
> Yes, I've read this already before. It clearly states what I've written
> about: If I have a JRE installed, I cannot install a JDK any more.
> That's my problem: I do need different JDKs and JREs for testing purposes.
> 
> > Second, exact errors, always.  
> "jdk-openjdk and jre-openjdk are in conflict"
> 
> Kind regards,
> Peter

You didn't read very carefully then.
"The JDK variant package includes the runtime environment to execute Java
applications"

Re: JDK/JRE and older Java versions

[Doug Newgard]

On Tue, 23 Apr 2024 08:49:21 +0200
Peter Nabbefeld  wrote:

> Hello,
> 
> as a Java developer, I sometimes need to do compatibility checking using
> older versions, often using JRE, while I need a JDK for development.
> 
> When I tried to update arch linux now, I found I cannot start any update
> because the update is blocked by setting JRE and JDK as conflicting
> packages. I tried to only install JDK 21, but the update is still being
> blocked because of my older versions of the JRE.
> 
> Why do You block any software installation? I don't like the idea to
> enforce me to use any specific software, or to remove any specific one.
> Is there any possibility to remove the lock-in?
> 
> Kind regards,
> Peter
> 

There is no blocking or lock-in. First off, see
https://archlinux.org/news/incoming-changes-in-jdk-jre-21-packages-may-require-manual-intervention/
which now applies to some of the older versions as well.

Second, exact errors, always.

Re: PKGBUILD: nodejs

[Doug Newgard]

On Wed, 17 Apr 2024 13:01:11 -0400
Pocket  wrote:

> I am trying to build nodejs in a chroot using
> 
> pkgctl repo clone --protocol=https nodejs
> 
> pushd nodejs
> 
> makechrootpkg -c -u -r "$CHROOT" -- --skippgpcheck
> 
> popd
> 
> It fails at this point
> 
> ==> Entering fakeroot environment...  
> chmod: cannot access '/startdir/pkg': No such file or directory
> 
> 
> I don't have startdir defined in the makepkg.conf file nor have I 
> defined it anywhere
> 
> Why is this failing?
> 

And where did you make the chroot and define that variable?

Re: `makepkg` generates two packages

[Doug Newgard]

On Sat, 9 Mar 2024 01:30:26 -0600
"David C. Rankin"  wrote:
> New features are generally something that can be enabled if wanted, not 
> something that is forced on an existing build system. For those building 
> packages, they are quite familiar with how to generate a debug package if 
> wanted -- I for one have no use for them and having my system suddenly start 
> generating unwanted debug packages in an unwelcomed surprise.
> 
> Granted, they are easy enough to disable, but the recent "surprise" changes 
> seem to fly in the face of the Arch "KISS" philosophy.

"forced on an existing build system" really? This is a simple config file and
the defaults changed, nothing has been 'forced on' anyone. This is also in the
backup array, so if the file has been modified at all, you would get a .pacnew.
You're seriously claiming that changing config file defaults isn't KISS? Do you
know what KISS even means for things like Arch?

Re: libblockdev split plugins

[Doug Newgard]

On Fri, 1 Mar 2024 23:04:59 +0100 (CET)
"Abraham S.A.H."  wrote:

> Hello everyone, 
> 
> Probably a little late, but I noticed that `plugins of libblockdev` package
> has been split out to a few individual, smaller packages, as optional
> dependencies. Probably, most of the users already noticed that.  

See https://gitlab.archlinux.org/archlinux/packaging/packages/udisks2/-/issues/1

Re: libjxl upgrade issue

[Doug Newgard]

On Thu, 25 Jan 2024 21:27:28 +0100 (CET)
Brian Allred  wrote:

> Actually, I updated again the next day and all was well. But it's funny you
> sent this message this morning, because now I'm experiencing the same issue
> with libvpx after today's update. Discord, Telegram, and xfreerdp all
> complain about missing the shared library "libvpx.so.8".
> 
> Brian

Let me guess, you're running a 3rd party ffmpeg? If you run out of repo
packages, it's up to you to rebuild them.

Re: boot partition expansion

[Doug Newgard]

On Wed, 17 Jan 2024 21:58:59 +
pete  wrote:

> Ok   
> 
> i use ATI Radeongave up on nouveau  
> 
> Pete 

But if you're using the kms hook, you still get nouveau in the fallback
initramfs.

Re: Python warnings still

[Doug Newgard]

On Sat, 6 Jan 2024 07:21:29 -0600
2qdxy4rzwzuui...@potatochowder.com wrote:

> I know that pete said that the question marks in the original post are
> artifacts, but I'm still hung up on the fact that in that original post,
> the filenames appear to be relative rather than absolute, as if some
> environment variable is unset, or perhaps mistakenly set to an empty
> string instead of being unset.
> 
> I admit that I haven't read every post in excruciating detail, but if
> something in pete's system is looking in usr/lib, but all the people
> helping are looking in /usr/lib, that might explain some of the
> apparently contradictory results.
> 
> Can pete please verify that the warnings name files in /usr/lib/... (an
> absolute path) and not usr/lib/... (a relative path)?  Or perhaps
> capture the output from commands that generate the warnnings in a file
> and post/attach that instead of (presubably) copying and pasing from a
> terminal program (which is evidently not a lossless copy)?

relatives paths are perfectly normal here. That's how pacman works.

Re: Python warnings still

[Doug Newgard]

On Sat, 6 Jan 2024 12:55:24 +
pete  wrote:

> the problem is if you manually  go into the directorys the files are there and
> are not zero length
> 
> i checked that

And yet both pacman and python say they are not there. What does
`ls -lR /usr/lib/python3.11/site-packages/gpg/` show?

Re: Python warnings still

[Doug Newgard]

On Sat, 6 Jan 2024 12:22:33 +
pete  wrote:

> On Fri, 5 Jan 2024 18:28:00 -0600
> Doug Newgard  wrote:
> 
> > On Sat, 6 Jan 2024 00:24:40 +
> > pete  wrote:
> >
> > > which gives me this
> > >
> > > "Traceback (most recent call last):
> > >   File "/usr/bin/torbrowser-launcher", line 29, in 
> > > import torbrowser_launcher
> > >   File
> > > "/usr/lib/python3.11/site-packages/torbrowser_launcher/__init__.py", line
> > > 36, in  from .common import Common, SHARE File
> > > "/usr/lib/python3.11/site-packages/torbrowser_launcher/common.py", line
> > > 37, in  import gpg ModuleNotFoundError: No module named 'gpg'
> >
> > Alright, so what does `pacman -Qkk python-gpgme` give you?
> 
> i have attached the generated listfrom  "
> 
> "pacman -Qkk python-gpgme  2>&1 | tee /tmp/war.log"
> 
> Pete

So virtually every file in that package is missing. Not altered, 0 length, or
anything, just flat out missing. This isn't a typical filesystem issue/power
loss or anything like that, then. Since pip hasn't been used and it appears to
be limited to python, this sounds more like a bad backup restore? Could also be
a manual deletion for some reason?

To fix it, since multiple packages are involved, you can get a list of all
python packages with `pacman -Qqo /usr/lib/python3.11/site-packages/`,
reinstall all of those.

It wouldn't hurt to check just `pacman -Qkk` to make sure there aren't other
packages involved.

Re: Python warnings still

[Doug Newgard]

On Sat, 6 Jan 2024 00:24:40 +
pete  wrote:

> which gives me this
> 
> "Traceback (most recent call last):
>   File "/usr/bin/torbrowser-launcher", line 29, in 
> import torbrowser_launcher
>   File "/usr/lib/python3.11/site-packages/torbrowser_launcher/__init__.py",
> line 36, in  from .common import Common, SHARE
>   File "/usr/lib/python3.11/site-packages/torbrowser_launcher/common.py", line
> 37, in  import gpg
> ModuleNotFoundError: No module named 'gpg'

Alright, so what does `pacman -Qkk python-gpgme` give you?

Re: Python warnings still

[Doug Newgard]

On Fri, 5 Jan 2024 21:45:25 +
pete  wrote:

> Hi folks .
> 
> 
> I am still getting plagued by  these Python  warnings
> 
> warning: could not get file information for
> usr/lib/python3.11/site-packages/pyr
> ate_limiter-3.1.0.dist-info/
> ??? warning: could not get file information for
> usr/lib/python3.11/site-packages/pyr
> ate_limiter-3.1.0.dist-info/LICENSE
> ? warning: could not get file information for
> usr/lib/python3.11/site-packages/pyr
> ate_limiter-3.1.0.dist-info/METADATA
> ? warning: could not get file information for
> usr/lib/python3.11/site-packages/pyr
> ate_limiter-3.1.0.dist-info/RECORD
> ? warning: could not get file information for
> usr/lib/python3.11/site-packages/pyr
> ate_limiter-3.1.0.dist-info/WHEEL
> 
> 
> 
> it seems every time there is something Python related i get around 150 lines
> of these warnings   any help anyone   before i loose it and rebuild the system
> that is a nightmare thought
> 
> 
> Pete
> 

After you finished the update, those files were put into place so you no longer
have an issue with that package. You either need to cancel the update, or use
pacman -Qkk on all of your python packages to identify which ones are missing
files. Are you using pip at all? Any cleaners like bleachbit?

There's no need to rebuild the system because of a few warnings.

Re: how to correctly create dbus-broker service and allow bus system service to start correctly

[Doug Newgard]

Simplest approach is to simply wait a bit.

https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/25

Re: Potential conflict with icu package?

[Doug Newgard]

On Sun, 17 Dec 2023 15:46:21 +
WinFan3672  wrote:

> Dear all,
> 
> I was recently performing my system's scheduled maintenance and went to 
> upgrade my packages, as you do. When I attempted to do so, this happened:
> 
> |$ sudo pacman -Syu
> [sudo] password for winfan3672:
> :: Synchronizing package databases...
> ...
> :: Starting full system upgrade...
> resolving dependencies...
> looking for conflicting packages...
> error: failed to prepare transaction (could not satisfy dependencies)
> :: unable to satisfy dependency 'libicuuc.so =73-64' required by freerdp
> :: installing icu (74.2-1) breaks dependency 'libicuuc.so=73-64'
> required by brltty
> :: installing icu (74.2-1) breaks dependency 'libicuuc.so=73-64'
> required by gspell
> :: installing icu (74.2-1) breaks dependency 'libicuuc.so=73-64'
> required by harfbuzz-icu
> :: installing icu (74.2-1) breaks dependency 'libicuuc.so=73-64'
> required by libphonenumber
> :: installing icu (74.2-1) breaks dependency 'libicui18n.so=73-64'
> required by libphonenumber
> :: installing icu (74.2-1) breaks dependency 'libicuuc.so=73-64'
> required by raptor
> :: installing icu (74.2-1) breaks dependency 'libicuuc.so=73-64'
> required by scribus
> :: installing icu (74.2-1) breaks dependency 'libicui18n.so=73-64'
> required by thunderbird
> :: installing icu (74.2-1) breaks dependency 'libicuuc.so=73-64'
> required by thunderbird|
> 
> This piqued my interest as it appears to be a package conflict outside 
> of my control. I performed the upgrade excluding the |icu| package, and 
> (almost) everything is fine now.
> 
> However, I would like to know:
> 
>   * Is this an issue with the |icu| package?
>   o In this case, this is an issue that needs attention and the
> relevant maintainer should probably look into it.
>   * Is it an issue with me?
>   o If so, what do I do, aside from ignoring it?
> 
> I look forward to hearing your response(s).
> 
> Yours truly,
> 

It appears there was a slight delay, 5 minutes or so, between icu getting moved
to Core and the rest of the rebuild getting moved to Extra. If your mirror
synced in that window, you'll run into this. It'll be fixed next time your
mirror syncs, or pick a different mirror.

Re: extra/surge-xt-common 1.3.0-1 breaks extra/surge-xt-lv2 1.2.3-2

[Doug Newgard]

On Tue, 12 Dec 2023 16:28:22 +0100
Ralf Mardorf  wrote:

> Hi,
> 
> I don't know where to report this issue, since 2FA for "ralf" at
> https://gitlab.archlinux.org/ fails with "Invalid authentication code"
> [1].
> 
> extra/surge-xt-common 1.3.0-1 breaks extra/surge-xt-lv2 1.2.3-2, see
> 
> https://archlinux.org/packages/extra/x86_64/surge-xt-lv2/
> https://archlinux.org/packages/extra/x86_64/surge-xt-common/
> 
> Regards,
> Ralf
> 

Looks like the maintainer just forgot to delete surge-xt-lv2, but that's kind
of a non-issue; you'll still have to deal with the old, no-longer-supported
package yourself.

Re: Arch Linux release 2023.12.01 comes with Linux Kernel 6.6.3

[Doug Newgard]

On Sat, 09 Dec 2023 14:51:37 +
Turritopsis Dohrnii Teo En Ming  wrote:

> I am confused.
> 
> On the Arch Linux download page https://archlinux.org/download/ , it clearly
> says Current Release 2023.12.01 with Linux Kernel 6.6.3.

Yes, that is the release of the ISO, not of Arch Linux. And it doesn't actually
matter what ISO you use. You could use the ISO from 2-3 months ago and the
installed system will be the same, because as I said, it always downloads the
latest packages to install. There are no packages on the ISO.

Re: Arch Linux release 2023.12.01 comes with Linux Kernel 6.6.3

[Doug Newgard]

On Fri, 08 Dec 2023 15:06:58 +
Turritopsis Dohrnii Teo En Ming  wrote:

> Subject: Arch Linux release 2023.12.01 comes with Linux Kernel 6.6.3
> 
> Good day from Singapore,
> 
> After I have downloaded and installed Arch Linux release 2023.12.01, can I
> upgrade the Linux Kernel from 6.6.3 to 6.6.5 easily?
> 
> Is the Linux Kernel 6.6.5 package available in the repository?
> 

There are no Arch Linux releases. You downloaded the ISO, but the ISO doesn't
really have any bearing on what gets installed when you set up the system, it
always downloads and installs the latest packages. 6.6.5 was just released
hours ago and isn't in the repos yet, 6.6.4 is.

If you're asking if you can update the ISO, no you cannot.

Re: vlc for command line users

[Doug Newgard]

On Sun, 26 Nov 2023 20:56:47 -0500
Jude DaShiell  wrote:

> The package installs and is not functional.  Why it's not functional is
> the package is missing .config/vlc/vlcrc so vlc has no clue how to do
> anything on a linux system.

Assuming you're talking in your home dir, the program has to do this itself at
runtime. Pacman cannot do this for you.

> For whatever reason I couldn't get vlc-nox to install on
> this system error exit 4 manual intervention is needed.  Was this manual
> intervention documented on arch-announce?

If you didn't confuse your AUR helper for pacman, you'd realize that that error
wasn't from pacman and has nothing to do with the repos or arch-announce.

Re: "xrefactory" AUR-package submission request to "extra" repository

[Doug Newgard]

On Wed, 15 Nov 2023 00:57:31 +0100
Sergei Litvin  wrote:

> Good afternoon,
> 
> I propose to add the following AUR-package, which I currently maintain,
> to the “extra” repository:
> https://aur.archlinux.org/packages/xrefactory
> 
> It is a code browser tool, similar to the following tools, but more
> precise because it works on grammar level:
> https://archlinux.org/packages/extra/x86_64/cscope/
> https://archlinux.org/packages/extra/x86_64/ctags/
> https://archlinux.org/packages/extra/x86_64/global/
> 
> The "upstream" is no longer maintained, but I have learned the
> internals and have already made about 30 patches.
> So, I can fix possible bugs, including parsing C, YACC and Java
> grammar.
> 
> This tool could be useful for Linux kernel developers (personally I use
> it along with cscope).
> And perhaps if it was in the "extra" repository, it could increase user
> interest in it.
> 
> 
> Best regards,
> Sergei Litvin
> 
> Tel: +49 176 85283820

You're kidding right? Software that's been dead for nearly 17 years upstream,
has been in the AUR for more than 5 years with no votes, requires a bunch of
downstream patches, and has a license that's very ambiguous about
redistribution? How in the world would anyone consider this a candidate to
package in Extra?

Re: pacman via pacstrap

[Doug Newgard]

On Fri, 10 Nov 2023 08:40:35 +0100
lacsaP Patatetom  wrote:
> # pacstrap -c -C target/etc/pacman.conf -U target/
> pkg/numix-gtk-theme-git-2.6.7.r55.ad4b345-1-any.pkg.tar.zst --overwrite '*'
> 
> thank you for this tip from the bowels of pacstrap because this
> option-passing method is not specified in the pacstrap man.
> 
> have a good day, regards, lacsaP.

Why aren't you just using pacman --sysroot here?

Re: Issues with Electron Apps

[Doug Newgard]

On Sat, 7 Oct 2023 19:12:31 +0200
Christian  wrote:

> So my suspicion is that electron was not rebuilt for the new dav1d
> version.

Except it was.
https://gitlab.archlinux.org/archlinux/packaging/packages/electron25/-/commit/c1e450809ccf7cbe0c65d9c997a51ef0a419b600

What version do you have? You should always include complete version
information when asking questions like this. If you have the latest version,
run lddtree from the pax-utils package on the electron binary and see exactly
what's linked to the old version.

Re: archinstall mystery

[Doug Newgard]

On Thu, 5 Oct 2023 22:58:53 +0200
Markus Schaaf  wrote:

> Am 04.10.23 um 21:00 schrieb Jude DaShiell:
> > I now have a disk with two partitions on it first one being fat32 esp.
> > The machine is uefi 64 capable.  For that reason I can't figure out how to
> > run grub-install on the latest update of grub.  
> 
> Why do you want to run grub-install again? Pacman is able to 
> update Grub. No manual fiddling needed.

This is incorrect. Pacman will not update GRUB on the ESP, which is what's
being used.

Re: Linux 6.4.12 Breaks Virtualbox 6.1.46 DKMS Build

[Doug Newgard]

On Fri, 25 Aug 2023 18:53:07 -0500
"David C. Rankin"  wrote:

> On 8/25/23 18:30, Doug Newgard wrote:
> > On Fri, 25 Aug 2023 17:49:03 -0500
> > "David C. Rankin"  wrote:
> >   
> >> All,
> >>
> >> This shouldn't happen, but the linux-6.4.11 to linux-6.4.12 broke the
> >> dkms build of virtualbox 6.1.46 modules. Specifically from the log:  
> > 
> > Pretty normal, actually. If you want to run an old version, it's your
> > responsibility to make it work. Kernels breaking compatibility happens all
> > of the time.
> >   
> >> Should I open a bug with Arch?  
> > 
> > No, this is not an Arch issue, as Arch doesn't ship virtualbox 6.1.46
> > modules.
> > 
> > Doug  
> 
> True but was that a kernel change or an Arch change to the kernel that broke
> it?
> 

What do you think Arch does to the kernel? But really, does it even matter?
Arch keeps the modules in the repo up to date, including patching them when
necessary for newer kernels. Again, if you want to run an old version that Arch
doesn't maintain, that part is up to you. Maybe check what Arch does? Or see if
upstream has patches?

> Additionally,
> 
>This is not an old version. 6.1.46 was released July 31, 2023, less than
> 30 days ago.

Nobody cares if its lts/still supported, 6.1 is an old version; end of story.
Even upstream lists it under "Old Builds". Arch is on 7.0 and maintains that. If
you don't want to use that, it's on you.

And 6.1.46 was July 18th, not 31st, and is only supported for a few more months.

Doug

Re: Linux 6.4.12 Breaks Virtualbox 6.1.46 DKMS Build

[Doug Newgard]

On Fri, 25 Aug 2023 17:49:03 -0500
"David C. Rankin"  wrote:

> All,
> 
>This shouldn't happen, but the linux-6.4.11 to linux-6.4.12 broke the dkms 
> build of virtualbox 6.1.46 modules. Specifically from the log:

Pretty normal, actually. If you want to run an old version, it's your
responsibility to make it work. Kernels breaking compatibility happens all of
the time.

>Should I open a bug with Arch?

No, this is not an Arch issue, as Arch doesn't ship virtualbox 6.1.46 modules.

Doug

Re: Install a package to alternative location

[Doug Newgard]

On Fri, 18 Aug 2023 15:31:21 +0900
"lain."  wrote:

> Could you at the very least test it yourself unstead of just assuming 
> it will "likely" not work?
> I wouldn't be doing it myself this way if it wouldn't work.
> The only time it won't find libraries is if you don't set your
> LD_LIBRARY_PATH approprietely:
> export LD_LIBRARY_PATH=~/.local/lib:$LD_LIBRARY_PATH
> Again, we have .bashrc or .zshrc for that.
> 
> The other possibility is that header files are hardcoded to something like
> "#include " rather than "#include ", but you
> really have to be the dumbest developer on the face of the Earth to even
> do that.
> 

And when it has to load images, icons, config files, etc? No, it's extremely
unlikely to work. Do not do this.

And stop top posting.

Re: Install a package to alternative location

[Doug Newgard]

On Fri, 18 Aug 2023 11:00:37 +0900
"lain."  wrote:

> This is how I have set it up:
> /usr/bin = systemwide binaries
> /usr/lib = systemwide libraries
> ~/.local/bin = user binaries
> ~/.local/lib = user libraries
> 
> I don't really like to use /usr/local/* on Linux, because it's not as
> portable as just /usr.
> I use it only in FreeBSD and OpenBSD, simply because it's the default
> behavior there.
> 
> If you compile from source (includes AUR):
> ./configure --prefix="~/.local"
> make DESTDIR="~/.local" install
> 
> If directly from the pacman repo's:
> pacman -S android-ndk -r ~/.local -b /var/lib/pacman
> The one downside of that is that it'll install for example
> "android-tools" under ~/.local/usr/bin rather than ~/.local/bin though,
> but with a bit of manual labor, you can correct that.
> 
> Then in your .bashrc or .zshrc:
> export PATH=~/.local/bin:$PATH
> 
> This way you can install multiple versions of software, and binaries in
> ~/.local will take preference over those in /usr, and you can always
> just run /usr/bin/whatever if you want to run the systemwide version
> instead.

And none of them are likely to work. It'll have no way to find it's libraries
or other resources. You CANNOT use pacman for something like this.

Re: gui network icon not connected

[Doug Newgard]

On Sat, 25 Mar 2023 21:55:57 +0800
rino1...@gmail.com wrote:

> it's a wireless connection.
> 
> using plasma DE.
> 
> how do you tell the type or kind of network manager? i remember 
> installing "plasma-nm" so that could be it?
> 
> the thing is if i disable this networking icon, i lose connectivity. if 
> i let it enabled showing no connections, i have connectivity.

What did you enable? What did you configure? YOU did all of this, right? You
should be able to tell us what you did, not the other way around.

https://wiki.archlinux.org/title/Network_configuration

Re: Driver for Nvidia Geforce GTX 760

[Doug Newgard]

On Sat, 18 Mar 2023 14:27:49 +
Andy Pieters  wrote:

> Hi
> 
> I'm trying to upgrade my 5.18.10 system and the DKMS build is failing for
> my NVIDIA driver.
> 
> To debug it I have tried to compile the driver separately out of DKMS, but
> the issue that keeps coming up with the new kernel (6.2.6) is [1]
> 
> Sadly, though, my card cannot run a more recent version of the driver. When
> I compile e.g. the 5xx driver I get a message:
> 
> NVRM: The NVIDIA GeForce GTX 760 GPU installed in this system is
> NVRM:  supported through the NVIDIA 470.xx Legacy drivers. Please
> NVRM:  visit http://www.nvidia.com/object/unix.html for more
> 
> So it seems that I am stuck on having to use the 470x drivers, the latest
> one available from Nvidia is 470.161.03, which fails to compile on Kernel
> >=6  
> 
> So what can I do? Stay on Kernel 5.18.10 or is it likely that NVidia or the
> community will provide a fix for the issue in [1]?
> 
> Many thanks

They have already provided a fix for the issue, the patch for 6.2 was applied
to the AUR package almost a month ago. Please don't tell me you're trying to
install directly from nvidia's website?

Re: libmysofa-1.3.1-2 hidden and breaks pipewire - with fix

[Doug Newgard]

On Mon, 20 Feb 2023 20:32:08 -0500
Genes Lists  wrote:

> Problem:
> This package is available in community, but pacman cannot find it - 
> which breaks pipewire-audio due to missing soname depends.
> pacman only finds 1.3.1-1 which is missing the needed provides.
> 
> Cause:
> The reason appears to be that while the package is available, it was not 
> added to the repo database - effectively hiding the package.
> 
> I've heard of quite a few folks who've been bitten by this.
> 
> Fix:
> add this to the repo
> Anyway fix should be quick and easy :)
> 
> thanks.
> 
> gene

Sounds like you have a bad mirror. Pick a different one.

Re: cannot resolve "libxml"

[Doug Newgard]

On Thu, 16 Feb 2023 19:23:55 +0100
Ralf Mardorf  wrote:

> Hi,
> 
> isn't the issue shown below worth a comment on "Latest News" and on
> arch-announce?

No, it's a simple packaging bug. It's worth a bug report.

Re: [arch-announce] Switch to the base-devel meta package requires manual intervention

[Doug Newgard]

On Mon, 13 Feb 2023 11:45:57 +0300
Greg Minshall  wrote:

> hi.  after doing this `pacman -Syu base-devel` (and re-booting), a number of
> executables can't find some (out dated?) dynamic libraries.
> 
> below are two lists:
> - one shows the affected binaries;
> - the other, just the list of un-found dynamic libraries.
> 
> any thoughts?  (sorry for e-mail formatting; my editor/e-mail program of
> choice is among the victims! :) (and, sorry for spurious sending to announce
> list; presumably that was squashed.)
> 
> cheers, Greg
> 
> bash archlinux (master): {49544} find /bin/ -type f -perm /a+x -print -exec
> ldd {} \; 2>&1 | awk 'NF == 1 { bin=$1; next } {print bin " ", $0}' | grep
> "not found" /bin/bggen  libtiff.so.5 => not found /bin/bggen
> libjasper.so.6 => not found /bin/hb-viewlibchafa.so.0 => not found
> /bin/tiffdiff   libtiff.so.5 => not found
> /bin/links  libtiff.so.5 => not found
> /bin/xv libtiff.so.5 => not found
> /bin/xv libjasper.so.6 => not found
> /bin/dec265 libSDL-1.2.so.0 => not found
> /bin/emacs-28.1.91  libtiff.so.5 => not found
> /bin/r  libopenblas.so.3 => not found
> /bin/tifficclibtiff.so.5 => not found
> /bin/makemhrlibmysofa.so.1 => not found
> /bin/system76-firmware-cli  libssl.so.1.1 => not found
> /bin/system76-firmware-cli  libcrypto.so.1.1 => not found
> /bin/sensordlibrrd.so.8 => not found
> /bin/xcmap  libtiff.so.5 => not found
> /bin/xcmap  libjasper.so.6 => not found
> /bin/mpeg2dec   libSDL-1.2.so.0 => not found
> bash archlinux (master): {49545} find /bin/ -type f -perm /a+x -print -exec
> ldd {} \; 2>&1 | awk 'NF == 1 { bin=$1; next } {print bin " ", $0}' | grep
> "not found" | awk '{print $2}' | sort -ulibSDL-1.2.so.0 libchafa.so.0
> libcrypto.so.1.1 libjasper.so.6
> libmysofa.so.1
> libopenblas.so.3
> librrd.so.8
> libssl.so.1.1
> libtiff.so.5
> 

This is a partial update issue, one way or another. Instead of using ldd, which
is recursive, check some of those binaries with lddtree from the pax-utils
package. It'll reveal where the actual problems are. If you want to check in a
script, you need to be using something like objdump or readelf that will show
you just what the binary is linked to, not everything in the entire tree.

Re: Where can I get last source pkg for hylafax before it was dropped in 2021?

[Doug Newgard]

On Thu, 26 Jan 2023 20:16:35 -0600
"David C. Rankin"  wrote:

> On 1/26/23 17:35, Markus Schaaf wrote:
> > 
> > https://github.com/archlinux/
> > 
> > It is either in svntogit-packages or svntogit-community. Find the commit
> > that dropped the package and checkout the predecessor.  
> 
> I must not know how to search old packages. I've search both, hylafax does
> not appear. I even searched Rojas' packages (the maintainer before it was
> dropped) and nothing appears.
> 
> Did the "extra" repository packages end up in either svntogit-packages or 
> svntogit-community? Seems like there would be an svntogit-extra repo?
> 

It was removed with commit ace51d8c13e1539ccf71a6e83894d47e957ffc5f

Re: Pacman returns error 404

[Doug Newgard]

On Thu, 27 Oct 2022 17:47:13 +0200
Zero  wrote:

> Hi Justin,
> 
> Indeed that worked pacman --sync --refresh nodejs
> 
> Thank you!
> ~Zero

You need to read the whole message, specifically where they said not to
actually do that. You need to update your entire system.

> 
> On 10/27/22 17:41, Justin Kromlinger wrote:
> > Please use `pacman --sync --refresh` (or `pacman -Sy`). Your local package
> > database is out of date, you are trying to download the old 19.0.0-1 (which
> > gives 404) instead of the new 19.0.0-2.
> >
> > Also, partial updates are not supported. You should always run `pacman
> > --sync --refresh --sysupgrade` (or `pacman -Syu`).
> >
> > Best Regards
> > hashworks
> >
> > On Thu, 27 Oct 2022 17:37:02 +0200
> > Zero  wrote:
> >  
> >> Hi all,
> >>
> >> Trying to install nodejs with pacman I do experience errors:
> >>
> >>
> >> pacman --sync nodejs
> >>
> >> Packages (1) nodejs-19.0.0-1
> >> ...
> >>
> >> :: Proceed with installation? [Y/n] Y
> >>
> >> :: Retrieving packages... nodejs-19.0.0-1-x86_64.pkg.tar.zst failed to
> >> downloaderror:
> >> failed retrieving file 'nodejs-19.0.0-1-x86_64.pkg.tar.zst' from
> >> geo.mirror.pkgbuild.com :
> >> The requested URL returned error: 404
> >>
> >>
> >> When accessing https://geo.mirror.pkgbuild.com/archlinux with a browser
> >> I can download the files nodejs-19.0.0-2-x86_64.pkg.tar.zst  and
> >> nodejs-19.0.0-2-x86_64.pkg.tar.zst.sig.
> >>
> >> But when accessing https://mirror.rackspace.com/archlinux with a browser
> >> it gives a http error 503 or after a long wait the packages show up.
> >>
> >>
> >> Is there a problem with the pacman mirrors ?
> >>
> >> ~Zero  
> 
> 

Re: [arch-general] QEMU Networking

[Doug Newgard via arch-general]

On Fri, 2 Sep 2022 17:12:35 -0400
Dan Sommers via arch-general  wrote:

> On 2022-09-02 at 10:01:15 -0400,
> Dan Sommers via arch-general  wrote:
> 
> > On 2022-09-02 at 09:41:21 -0400,
> > Dan Sommers via arch-general  wrote:  
> 
> > > [Then I found .]  
> 
> > FYI:  QEMU is just like drill:  it doesn't work with systemd-resolved's
> > default resolv.conf.  When I added a nameserver line to resolv.conf, my
> > virual machines gained internet access.  
> 
> FWIW:  https://gitlab.com/qemu-project/qemu/-/issues/1189
> 

If you resolv.conf was empty, you didn't set up systemd-resolved correctly. See
the wiki, it should be a symlink.

Re: [arch-general] Qemu 7 can not be upgraded on my machine.

[Doug Newgard via arch-general]

On Sat, 14 May 2022 10:55:13 -0400
Matthew Dyer via arch-general  wrote:

> Hi all,
> 
> 
> I have 2 machines 1 of wich is x86 and the other is arm based. On On the 
> arm machine I am using stormux which is based on arch arm.
> 
> 
> Here is the issue.  On my stormux/arm pi400 machine which btw I I am 
> writing this message on, I am unabble to upgrade or for thart mater 
> remove     qemu.  Upgrading qemu or installing qemu-desktop tells me 
> that there are broken dependencys.  I for the time being, have added the 
> following packages to be ignored in my pacman.conf.  qemu-headless and 
> qemu-img.
> 
> 
> I am not sure if this should be posted on the list, but could not find a 
> way to resaulved this and would to get this problem.  Is there a flag 
> such as allow or force of sore sort which can be used in some cases?  On 
> my main x86 machine this upgrade went without a problem.  If there is a 
> way to remove qemu since I don't really use it that would be wonderfull 
> as well since I don't use it.
> 
> 
> Matthew

Please see:
https://terms.archlinux.org/docs/code-of-conduct/#arch-linux-distribution-support-only

ArchARM is even a different distro, so you're way off base.

Re: [arch-general] Link libutil.so not in glibc 2.35-2.

[Doug Newgard via arch-general]

On Sat, 19 Feb 2022 19:16:17 +0100
SET via arch-general  wrote:

> Hi,
> 
> I ran into an issue building an application that complained libutil.so was
> not found. It's not in /usr/lib indeed with glibc 2.35-2, while it was a link
> to libutil.so.1 -> libutil-2.32.so in glibc 2.32. Just creating the link
> fixed the build issue.
> 
> I'm wondering if it's a new library deployment scheme, or it the link was 
> missed during packaging.
> 
> Regards.

If you're wondering if upstream did something, the first thing you should do is
check the release notes.

https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html

Re: [arch-general] Problems updating wine 6.9-1 -> 6.10-1

[Doug Newgard via arch-general]

On Sun, 6 Jun 2021 23:29:56 +0200
Uwe Sauter via arch-general  wrote:

> Hi all,
> 
> I'm hitting update problems with wine. Seems like uninstalling 6.9-1 and 
> installing 6.10-1 or advanced usage of "pacman 
> -Su --overwrite " is needed.
> 
> Pacman shows 4253 conflicting files in a lot of directories.

https://wiki.archlinux.org/title/Pacman#%22Failed_to_commit_transaction_(conflicting_files)%22_error

This is database corruption.

Re: [arch-general] Can't login to flyspray

[Doug Newgard via arch-general]

On Fri, 16 Apr 2021 13:54:37 -0300
Giancarlo Razzolini via arch-general  wrote:

> Em abril 16, 2021 13:45 Doug Newgard via arch-general escreveu:
> > On Fri, 16 Apr 2021 18:28:31 +0200
> > Markus Schaaf via arch-general  wrote:
> >   
> >> My account exists and I've even reset my password, just in case. But
> >> still can't login. Could someone please have a look at it? E-mail is the
> >> same I'm posting from and username is the local part.  
> > 
> > Is your password really long? There's an issue with flyspray and passwords 
> > over
> > a certain number of chars (24? I don't really remember).
> > 
> > Account is not disabled and email is correct.
> >   
> 
> My password is bigger than 24 chars and I don't have any issues. However, 
> it's alphanum only, no
> spaces and no special characters.
> 
> Regards,
> Giancarlo Razzolini

That's why I said I didn't really remember what the limit is. Looks like it's
30. https://bugs.archlinux.org/task/39816

Re: [arch-general] Can't login to flyspray

[Doug Newgard via arch-general]

On Fri, 16 Apr 2021 18:28:31 +0200
Markus Schaaf via arch-general  wrote:

> My account exists and I've even reset my password, just in case. But
> still can't login. Could someone please have a look at it? E-mail is the
> same I'm posting from and username is the local part.

Is your password really long? There's an issue with flyspray and passwords over
a certain number of chars (24? I don't really remember).

Account is not disabled and email is correct.

Re: [arch-general] aom upgrade brakes funktionality of several video applications

[Doug Newgard via arch-general]

On Sun, 11 Apr 2021 16:37:32 +0200
Friedrich Strohmaier via arch-general  wrote:

> Hi Doug, *,
> 
> Am 11.04.21 um 16:19 schrieb Doug Newgard via arch-general:
> > On Sun, 11 Apr 2021 16:16:03 +0200
> > Friedrich Strohmaier via arch-general  
> > wrote:  
> 
> >> Hi archers,  
> 
> [..]
> 
> >> I'm not able to play videos in my firefox browser (ok. this one ist from
> >> mozilla).  
> 
> [..]
> 
> >> I filed a bug:
> >> https://bugs.archlinux.org/index.php?do=details&task_id=70411  
> 
> [..]
> 
> >> How to proceed?  
> 
> > For those that aren't starting at all, check the binaries with lddtree (from
> > the pax-utils package), see what's linked to the old version.  
> 
> O.K. here they are:
> 
> jami:
> ~]$ lddtree /usr/lib/ring/dring | grep aom
> libaom.so.2 => /usr/lib/libaom.so.2
> 
> chromium:
> ~]$ lddtree /usr/bin/chromium | grep -i aom
> ~]$
> 
> Friedrich
> 

I said binary, /usr/bin/chromium is not a binary. And the grep makes the whole
thing useless.

Re: [arch-general] aom upgrade brakes funktionality of several video applications

[Doug Newgard via arch-general]

On Sun, 11 Apr 2021 16:16:03 +0200
Friedrich Strohmaier via arch-general  wrote:

> Hi archers,
> 
> after one of the last upgrades aom was upgraded to version 3.0.0 several
> applications stopped working (properly).
> 
> I'm not able to play videos in my firefox browser (ok. this one ist from
> mozilla).
> 
> chromium and jami not starting at all, gnome-mplayer stops playing videos,
> handbrake is complains not finding gstreamer plugin for h264 and so forth.
> Downgrading to version 2.0.2 makes everything running as expected.
> 
> Anyone else seeing alike?
> 
> I filed a bug:
> https://bugs.archlinux.org/index.php?do=details&task_id=70411
> which was closed immediately.
> 
> Reason: Not a bug
> Additional comments about closing:  Use the forums or mailing lists for 
> support
> 
> How to proceed?

For those that aren't starting at all, check the binaries with lddtree (from the
pax-utils package), see what's linked to the old version.

Re: [arch-general] Mirror not synchronized since January

[Doug Newgard via arch-general]

On Tue, 9 Mar 2021 18:16:17 +0100
Henry-Joseph Audéoud via arch-general  wrote:

> On 09/03/2021 18:01, David Rosenstrauch via arch-general wrote:
> > This page can show you how up to date various mirrors are:
> > 
> > https://archlinux.org/mirrors/status/
> > 
> > If you're using one that's getting out of date, you can switch to another.  
> 
> OK, many thanks.
> 
> For curiosity.  Pacman reports the package `pacman-mirrorlist` (from a 
> up-to-date mirror ;-) ) was recompiled at 2 March, far after the last 
> sync of this out-of-date repo.  When will that mirror be finally dropped 
> from pacman-mirrorlist?
> 

It probably won't be; if you look, the issue is that the Tier 1 mirror it syncs
from is out of date. This mirror itself is doing the right thing.

Re: [arch-general] PAM 1.3.1 -> 1.5.1 did pam_tally get removed?

[Doug Newgard via arch-general]

On Mon, 22 Feb 2021 13:58:36 +0100
Anton Hvornum via arch-general  wrote:

> What dictates if something is worthy of being put on the bulletin
> board on the main website?

Something out of the ordinary. Merging .pacnew files is a normal, standard part
of system updates.

Re: [arch-general] About package guidelines

[Doug Newgard via arch-general]

On Sun, 21 Feb 2021 17:03:10 +0100
Óscar García Amor via arch-general  wrote:

> Hi,
> 
> When a user submit a package to AUR must follow package guidelines.
> There is an interesting point that says that in the top of PKGBUILD
> you must respect the previous contributors [1] and credit them (if
> any).
> 
> I'm surprised that this is not respected by the trusted users when
> they pick an arbitrary package that is maintained in AUR and upload it
> to the community repository without crediting anyone of past
> maintainers. I saw this course of acting in several packages and don't
> like to me. It seems to me a total lack of respect towards the person
> or people who have been keeping the package so far.
> 
> If users of the AUR are required to have a minimum of netiquette, more
> should be required of TUs.
> 
> Greetings.
> 
> [1]: https://wiki.archlinux.org/index.php/AUR_submission_guidelines
> 

Specifics? I know there's quite a few cases where TUs don't even look at the
AUR and just write their own PKGBUILDs from scratch, in which case there aren't
any previous contributors.

Re: [arch-general] [arch-announce] Moving to Zstandard images by default on mkinitcpio

[Doug Newgard via arch-general]

On Fri, 19 Feb 2021 19:13:09 +
Piscium via arch-general  wrote:

> On Fri, 19 Feb 2021 at 13:37, Arch Linux: Recent news updates:
> Giancarlo Razzolini via arch-announce
>  wrote:
> >
> > As linux-lts moved to the 5.10 version, all official kernels of Arch Linux 
> > now support zstd compressed
> > initramfs images, so mkinitcpio is switching to zstd compressed images by 
> > default with version 30,
> > which is currently on [testing].
> >
> > If, for any reason, you are using a kernel version prior to 5.9, make sure 
> > to change mkinitcpio.conf
> > COMPRESSION to use one of the compressors supported, like gzip, otherwise 
> > you **will not** be able to
> > boot images generated by mkinitcpio.  
> 
> I am not sure I understand this. If someone has the default
> mkinitcpio.conf it won't boot?
> 
> In my case I set it to lz4 over a year ago for speed.

If someone has the default mkinitcpio.conf AND a kernel older than any Arch
ships, then yes, it may not boot.

Re: [arch-general] DKMS problem with the latest linux-ck kernel

[Doug Newgard via arch-general]

On Sat, 6 Feb 2021 10:04:46 -0600
Randy DuCharme via arch-general  wrote:

> Greetings,
> 
> Seems the latest linux-ck kernel and DKMS don't play well together.  The
> post-install goes something like this:
> 
> :: Running post-transaction hooks...
> (1/4) Arming ConditionNeedsUpdate...
> (2/4) Updating module dependencies...
> (3/4) Install DKMS modules
> ==> dkms install --no-depmod -m openrazer-driver -v 2.9.0 -k 5.10.13-3-ck  
> Error! Bad return status for module build on kernel: 5.10.13-3-ck (x86_64)
> Consult /var/lib/dkms/openrazer-driver/2.9.0/build/make.log for more
> information.
> ==> Warning, `dkms install --no-depmod -m openrazer-driver -v 2.9.0 -k  
> 5.10.13-3-ck' returned 10
> ==> dkms install --no-depmod -m nvidia -v 390.138 -k 5.10.13-3-ck  
> Error! Bad return status for module build on kernel: 5.10.13-3-ck (x86_64)
> Consult /var/lib/dkms/nvidia/390.138/build/make.log for more information.
> ==> Warning, `dkms install --no-depmod -m nvidia -v 390.138 -k  
> 5.10.13-3-ck' returned 10
> ==> depmod 5.10.13-3-ck  
> (4/4) Updating linux initcpios...
> ==> Building image from preset: /etc/mkinitcpio.d/linux-ck.preset: 'default'  
>     -> -k /boot/vmlinuz-linux-ck -c /etc/mkinitcpio.conf -g
> /boot/initramfs-linux-ck.img
> ==> Starting build: 5.10.13-3-ck  
>     -> Running build hook: [base]
>     -> Running build hook: [udev]
>     -> Running build hook: [autodetect]
>     -> Running build hook: [modconf]
>     -> Running build hook: [block]
>     -> Running build hook: [filesystems]
>     -> Running build hook: [keyboard]
>     -> Running build hook: [fsck]
> ==> ERROR: module not found: `nvidia'
> ==> ERROR: module not found: `nvidia_modeset'
> ==> ERROR: module not found: `nvidia_uvm'
> ==> ERROR: module not found: `nvidia_drm'  
> .
> 
> .
> 
> .
> 
> The pertinent lines in the DKMS logs complain about my GLIBC  - mine's
> at 2.35.
> 
> 
>     CC [M]  /var/lib/dkms/nvidia/390.138/build/nvidia/nv-cray.o
>     CC [M]  /var/lib/dkms/nvidia/390.138/build/nvidia/nv-dma.o
> scripts/basic/fixdep: /usr/lib/libc.so.6: version `GLIBC_2.33' not found
> (required by scripts/basic/fixdep)
> make[2]: *** [scripts/Makefile.build:279:
> /var/lib/dkms/nvidia/390.138/build/nvidia/nv-cray.o] Error 1
> make[2]: *** Deleting file
> '/var/lib/dkms/nvidia/390.138/build/nvidia/nv-cray.o'
> make[2]: *** Waiting for unfinished jobs
> scripts/basic/fixdep: /usr/lib/libc.so.6: version `GLIBC_2.33' not found
> (required by scripts/basic/fixdep)
> make[2]: *** [scripts/Makefile.build:279:
> /var/lib/dkms/nvidia/390.138/build/nvidia/nv-instance.o] Error 1
> make[2]: *** Deleting file
> '/var/lib/dkms/nvidia/390.138/build/nvidia/nv-instance.o'
> .
> 
> .
> 
> .
> 
> 
> I spent some time scratching around looking for where/how this is
> configured but so far I haven't figured it out.  Can someone point the
> way?  Where is this set?
> 
> I looked into the kernel fixdep code a little and tried tweaking it some
> just to see if I could coax it into installing but haven't yet been able
> to spend a bunch of time on it.
> 
> 
> Thanks in advance!
> 

This was already fixed. Update your system from an up-to-date mirror.


pgpZgrotJy3WL.pgp
Description: OpenPGP digital signature

Re: [arch-general] LIB glew-wayland is broken

[Doug Newgard via arch-general]

On Tue, 5 Jan 2021 14:58:20 +0100
Nathan Dacunha via arch-general  wrote:

> glew-wayland does not provide "glew" and we cannot install glew-wayland
> because all the dependencies on it get uninstalled!
> 
> please add this "Provides : [glfw=3.3.2]" on the package glew-wayland thank

Since it's not binary-compatible with glew, it can't satisfy that dep.