On Fri, Nov 15, 2019 at 8:31 AM Hongyi Zhao via arch-general <
arch-general@archlinux.org> wrote:
> Hongyi Zhao 于2019年11月15日周五 下午9:13写道：
> >
> > Ralph Corderoy 于2019年11月15日周五 下午8:57写道：
> >
> > >
> > > Hi Hongyi,
> > >
> > > > I noticed that for many distro's install iso, there are some efi
> fil
> I will go through the links guys, thanks a lot..
>
> And Yi Zheng, me neither like UEFI, but what to do, nowadays all laptops
> comes as UEFI.. and to change it to MBR i have to wipe the entire drive :(
>
It's actually much easier to dual boot with UEFI once you become familiar
with it. If your
If you're going to use automatic login, why not cut out the middle man and
ditch the display manager entirely?
Relevant wiki articles/sections:
Getty#Automatic_login_to_virtual_console
Xinit#Autostart_X_at_login
KDE#Manual
On Tue, Jul 18, 2017 at 10:08 AM, Junayeed Ahnaf via arch-general <
arch-g
>
> So what? Is linux now about restricting user choice?
>
Arch is a pragmatic distribution, both for the users and developers.
Upstream decided to make pulseaudio a hard dependency specifically to
reduce maintenance costs on their end. Arch devs really aren't in the
business of adopting such main
>
> Not about systemd, but about your request. This is the wrong list for
> such a request and apart from this, it's the wrong time to ask those
> questions. You are years too late with those questions.
>
I agree. This would be better suited for the Arch forums. We have a section
for general GNU/L
>
> How can I get rid of this annoying flashing line.
>
> This is the currently used xorg.conf:
>
Does the problem persist if you remove your X config so it just runs the
defaults? In my experience Intel generally requires little to no
configuration to work well with X.
>
> All those distros, everyone except arch has decided at some point to no
> longer restrict the use of unprivileged user namespaces.
>
In no way whatsoever does Arch restrict the use of unprivileged user
namespaces. Rebuilding your kernel with them enabled is a trivial task for
any user familiar
>
> I get an error about a conflict between .SRCINFO and PKGBUILD - how can I
> resolve this problem?
>
I'm not getting that error, have you tried cloning a fresh copy from AUR?
Regardless, you don't need to care about .SRCINFO unless you're the
maintainer. Just delete it.
Max
>
> CVE / ASA logging or however you call it is now officially hosted on
> https://security.archlinux.org
>
> The wiki is dead, long live the new awesome tracker :)
>
I will archive the old wiki articles in about a week. Get your arguments in
now if you want them to stick around.
>
> Allan has already declared that he will not change the default
> makepkg.conf, on the grounds that #2 is the most likely scenario for
> people getting malicious packages.
> He also wants everyone to know that updpkgsums and makepkg are perfectly
> okay with maintainers changing the defaults, pe
>
> So what do you guys think if we make our implicit standards available
> somewhere on the wiki. This would make it more transparent on how we
> build stuff, how TUs should package and give a guideline for AUR
> maintainers, as they might not know about some details like this.
>
The best way to
>
> You mean the source files that you downloaded and then hashed...
>
Yes. If the source files are being modified via a MITM attack (which is
trivial if the host uses HTTP) the checksum is still useful.
>
> I agree that we should use a strong hash by default where it makes
> sense. But in the absense ob effective validation of upstream packages,
> this is meaningless.
>
It would at least indicate that the source file has been tampered with in
some way. Even though there would be no way to know th
> Morning. Try this, sudo pacman -Syu --force.
Please do not run that command unless the Arch site specifically recommends
it. Forcing a full system upgrade is extremely dangerous.
The safe solution is to force only ttf-dejavu.
>
> Do you Have any pointer to good opensource hardware ?
Not exactly open-source/FSF-endorsed but https://system76.com/ sells
laptops with Ubuntu-preinstalled so those are also guaranteed to run Arch.
On Thu, Sep 22, 2016 at 7:12 AM, mike lojkovic via arch-general <
arch-general@archlinux.org> wrote:
> I'm in favor of the merge as well. For beginners there are plenty of
> Youtube videos that cover common desktop setups. That should be more than
> enough for users who are first learning how to s
I think the tool is great Florian, but I do not think that it warrants
official support. Consider examples like pacgem or pip2pkgbuild. These
tools help integrate Ruby/Python packages (which are usually managed via a
separate package manager) into pacman. They are great for users who want
pacman to
>
> Arch is what you make it (TM)
>
> It's best at finding bugs before they get into Ubuntu.
>
Also check
https://wiki.archlinux.org/index.php/Frequently_asked_questions#Why_would_I_not_want_to_use_Arch.3F
Other than those points you should be able to reasonably adapt it to
whatever situation you
>
> Under what criteria does this take place? It has gotten to the point
> where you
> just get tired of helping -- why bother?
The main criterion is this:
https://wiki.archlinux.org/index.php/Help:Style#Hypertext_metaphor
Specifically, "Before writing a specific procedure in an article or
des
>
> I followed https://wiki.archlinux.org/index.php/Asus_x205ta
> from start to #Install_Arch and i'm now stuck:
>
> I'm booting on a menu with 3 choices:
>
> * Arch iso install
> * EFI v1
> * EFI v2
>
> none of them is working: if i select one, the screen turns black 'til i
> reboot. i don't even
On Tue, Mar 8, 2016 at 3:57 AM, Garmine 42 wrote:
>
> On 8 March 2016 at 03:49, Maxwell Anselm wrote:
> > I had the same issue in xterm. Changing fonts didn't fix it, but switching
> > to urxvt (with the same font) did. It seems like there's something screwy
>
I had the same issue in xterm. Changing fonts didn't fix it, but switching
to urxvt (with the same font) did. It seems like there's something screwy
with xterm's unicode support.
On Mon, Mar 7, 2016 at 12:12 AM, Grady Martin
wrote:
> On 2016年02月17日 00時06分, Garmine 42 wrote:
>
>> It was indeed a
It seems we've come to an understanding in this thread, which is great. But
I would recommend further OpenRC development be discussed elsewhere
(perhaps aur-general or the PKGBUILD requests subforum?).
Thanks,
Max
> Though I don't see how a repository officially trusted by
> Manjaro is less trusted than the AUR.
They are completely different. An unofficial repository of non-AUR packages
is for installing binary packages that have no affiliation with Arch Linux.
I think it's pretty obvious why that would not
> There are 4 mirrors for an unnoficial user repository with packages that
> are officially used in Manjaro.
> > 3. Work on 1 and 2 until you feel like you have a clearly superior
method
> The method already existed, I just wanted to make it visible.
I think you misunderstood. I was not suggesting
> Someone already talked about putting it back in the forums. They were
> turned down because of those points («no reason for 2 methods», etc.).
> This among other things (which are evident in any discussion in Arch
> about OpenRC) signals a bad community.
When it comes to Linux there are often ma
I also recommend rEFInd for a similar reason. It's much simpler to install
than grub and it will probably autodetect both Arch and Windows.
On Thu, Aug 27, 2015 at 8:00 AM, wrote:
>
> I never bothered with grub on EFI, especially now that a UEFI boot loader
> comes bundled into systemd. So why bo
Respecting backwards compatibility is more complicated than just never
removing features from software. Sometimes less is more: extra features can
be bad for maintenance, a source of bugs, or a source of vulnerabilities.
Sometimes features are added as workarounds or hacks in lieu of a proper
solut
> What is the name/URL of this app?
It's the GURPS character sheet: http://gurpscharactersheet.com/
I have a github repo for my WIP AUR package:
https://github.com/silverhammermba/gcs
> If building on a box where multiple JVM can be installed: build
> scripts for Java apps usually provide a "--wit
I'm working on a PKGBUILD for a Java app that must be built and run using
Java 8, but I couldn't find any guidelines on best practices for such a
situation.
The easy part is including 'java-environment=8' and 'java-runtime=8' in
makedepends and depends respectively, but how to ensure the right ver
30 matches
Mail list logo
