Re: [arch-general] Add wpa_supplicant to the Group 'Base'
On Sat, Apr 25, 2015 at 08:10:57PM +0200, Maarten de Vries wrote: I would say an editor is part of the bare minimum for any system. You can't do much on a system without an editor (of course you can still edit files using some basic tools that don't qualify as editors, but that's besides the point). I don't actually agree. Editing configs post install is not required for a bootable install (as made obvious by the fact that you can boot to it). Besides, once a user has booted, they can just install whatever editor they so choose anyway. Multiple bootloaders don't really make sense You are absolutely right, I don't know why I said that actually… They are two separate things already. The installation media comes with wpa_supplicant for one. Right. I'm not actually arguing for wpa_supplicant's inclusion in `base`, just pointing out that things like, `netctl` (and imho, the variety of text editors) might not make sense either if we assume `base` is exclusively for a bootable install. Kinds regards, And the same to you. All the best, -Sam
Re: [arch-general] Add wpa_supplicant to the Group 'Base'
This may just be my personal opinion, but I have always thought that `base` was supposed to be the absolute bare minimum to have a bootable installation. From that view, it makes sense that a few very small editors made sense in `base` back when Arch wasn't net-install only. Now, however, since Arch is only officially supported for netinstall only and getting an editor on your fresh new install is as simple as running `pacstrap -i /mnt youreditornamehere` from the installation medium. I am unconvinced that vi (or vim-minimal) or nano actually have a place in `base`. Honestly, I think an idea world would put pacman, linux, systemd, bash, a few bootloaders, efi-related utilities and their dependencies in `base` and essentially nothing else. Having said that, I think it makes perfect sense to have nano and vim-minimal on the installation media, but I think of “what is on the installation media” and “what is in `base`” as being two separate things. All the best, -Sam
Re: [arch-general] Add wpa_supplicant to the Group 'Base'
On Sat, 25 Apr 2015 17:51:10 +0200 Neven Sajko nsa...@gmail.com wrote: I agree that wpa_supplicant probably should not be in base, but it's worth mentioning that base already has many packages not useful to a lot of people - I for example don't have any of these installed: dhcpcd jfsutils reiserfstools xfsprogs cryptsetup lvm2 mdadm nano netctl My list is similar, with the addition of pcmciautils, s-nail, and vi.
Re: [arch-general] Add wpa_supplicant to the Group 'Base'
On 25 April 2015 at 19:36, Ralf Mardorf ralf.mard...@rocketmail.com wrote: On Sat, 25 Apr 2015 17:51:10 +0200, Neven Sajko wrote: nano IMO nano should be part of base. Other editors might have advantages over nano, but to set up config files, it's on of the most easiest to use editors. It's my default editor, because you don't get a tendonitis and you don't need to learn billions of shortcuts and a strange language to configure the editor, IOW it's not like Emacs and it's also not like the two modes Vi/m, beep repeatedly and break everything. Sure, for coders those editors have their advantages, but to set up an install nano is a good choice, because it can be used by everybody. Perhaps by default an improved nanorc should be provided. I didn't use nano much but I'm pretty sure you could edit text faster in MS Word, so I cannot imagine any scenario in which it should be used. If you don't know how to use anything better you should probably learn ASAP.
Re: [arch-general] Add wpa_supplicant to the Group 'Base'
On Sat, 25 Apr 2015 17:51:10 +0200, Neven Sajko wrote: nano IMO nano should be part of base. Other editors might have advantages over nano, but to set up config files, it's on of the most easiest to use editors. It's my default editor, because you don't get a tendonitis and you don't need to learn billions of shortcuts and a strange language to configure the editor, IOW it's not like Emacs and it's also not like the two modes Vi/m, beep repeatedly and break everything. Sure, for coders those editors have their advantages, but to set up an install nano is a good choice, because it can be used by everybody. Perhaps by default an improved nanorc should be provided.
Re: [arch-general] Add wpa_supplicant to the Group 'Base'
On Sat, 25 Apr 2015 23:55:32 +0200, Neven Sajko wrote: On 25 April 2015 at 19:36, Ralf Mardorf ralf.mard...@rocketmail.com wrote: On Sat, 25 Apr 2015 17:51:10 +0200, Neven Sajko wrote: nano IMO nano should be part of base. Other editors might have advantages over nano, but to set up config files, it's on of the most easiest to use editors. It's my default editor, because you don't get a tendonitis and you don't need to learn billions of shortcuts and a strange language to configure the editor, IOW it's not like Emacs and it's also not like the two modes Vi/m, beep repeatedly and break everything. Sure, for coders those editors have their advantages, but to set up an install nano is a good choice, because it can be used by everybody. Perhaps by default an improved nanorc should be provided. I didn't use nano much but I'm pretty sure you could edit text faster in MS Word, so I cannot imagine any scenario in which it should be used. If you don't know how to use anything better you should probably learn ASAP. Mentioning a Windows office suite is polemic. Even a lot of us *nix users nowadays are using GUI editors, Sublime text, Pluma, Atom editor, Gvim etc. for tasks an editor usually is used for, unlikely for editing office work. For some tasks a GUI isn't an option, usually for editing simple config files something as Nano can be used by nearly everybody. Most of us for sure are aware how to use Vi too. I prefer to get Nano when e.g. running visudo, but sure, I'm able to use Vi/m too. I'm not an editor war guy. There's nothing wrong with Emacs and Vi/m, but there's also nothing wrong with easy to use, self explaining editors such as Nano, mcedit etc., even while Vi is a standard. Why not providing an easy to use self explaining editor such as Nano? You don't benefit from a better editor for this task. Why should people learn how to use oldish editors, they never need for simple tasks, when we nowadays have much easier, self-explaining editors, such as nano? Do you seriously consider $ pacman -Qi nano | grep Size Installed Size : 2.05 MiB in base as an issue? 2.05 MiB that make live for many users much easier. Regards, Ralf
Re: [arch-general] Add wpa_supplicant to the Group 'Base'
On Sat, 25 Apr 2015 12:59:30 -0500, Sam Stuewe wrote: Honestly, I think an idea world would put pacman, linux, systemd, bash, a few bootloaders, efi-related utilities and their dependencies in `base` and essentially nothing else. I guess _core_ should be similar to FreeBSD's world, including the kernel, core system binaries, libraries, programming files, and built-in compiler. Basic software that gets more attention not to break by updates and more attention regarding security. Arch might not need a compiler for _base_, because building from ABS isn't needed, since we can install binaries using pacman. As somebody already pointed out, there are base and base-devel and even dash is exclude from both, so those groups already are very small. IMO base could include everything from core.
Re: [arch-general] Add wpa_supplicant to the Group 'Base'
On 25 April 2015 at 19:59, Sam Stuewe halosgh...@archlinux.info wrote: This may just be my personal opinion, but I have always thought that `base` was supposed to be the absolute bare minimum to have a bootable installation. From that view, it makes sense that a few very small editors made sense in `base` back when Arch wasn't net-install only. I would say an editor is part of the bare minimum for any system. You can't do much on a system without an editor (of course you can still edit files using some basic tools that don't qualify as editors, but that's besides the point). Honestly, I think an idea world would put pacman, linux, systemd, bash, a few bootloaders, efi-related utilities and their dependencies in `base` and essentially nothing else. Multiple bootloaders don't really make sense, and there are many bootloaders to choose from. Choosing one to install by default would probably be a very difficult discussion. It would also mean that users might not even be aware of what bootloader they're using and leave them unprepared when it breaks. Having said that, I think it makes perfect sense to have nano and vim-minimal on the installation media, but I think of “what is on the installation media” and “what is in `base`” as being two separate things. They are two separate things already. The installation media comes with wpa_supplicant for one. Kinds regards, Maarten
Re: [arch-general] Add wpa_supplicant to the Group 'Base'
On 25 April 2015 at 20:18, Sam Stuewe halosgh...@archlinux.info wrote: On Sat, Apr 25, 2015 at 08:10:57PM +0200, Maarten de Vries wrote: I would say an editor is part of the bare minimum for any system. You can't do much on a system without an editor (of course you can still edit files using some basic tools that don't qualify as editors, but that's besides the point). I don't actually agree. Editing configs post install is not required for a bootable install (as made obvious by the fact that you can boot to it). Besides, once a user has booted, they can just install whatever editor they so choose anyway. Fair enough, if you define minimal as it can boot, then you don't need an editor. I would interpret the system part in a minimal booting system as a system that can perform some basic tasks like editing files though. They are two separate things already. The installation media comes with wpa_supplicant for one. Right. I'm not actually arguing for wpa_supplicant's inclusion in `base`, just pointing out that things like, `netctl` (and imho, the variety of text editors) might not make sense either if we assume `base` is exclusively for a bootable install. Right, I don't really see a point in having netctl in base either, personally. I don't really mind either though. I do see a point for an editor in there. Then again, it's all very subjective anyway. Kinds regards, And the same to you. And you ;) Kind regards, Maarten
Re: [arch-general] pacman's Depends On
On Sat, 25 Apr 2015 10:01:57 +0200, Rodrigo Rivas wrote: [snip] The libvpx.so symbolic link [snip] is not needed in runtime. Thank you :).
Re: [arch-general] PATH variable not set in DE (GNOME)
On Sat, Apr 25, 2015 at 3:03 AM, Maximilian Kaul archli...@maxkaul.de wrote: So I checked in a terminal: $ which exiftool /usr/bin/vendor_perl/exiftool $ echo $PATH .../usr/bin/vendor_perl... BUT if I put the following code in a file #!/bin/sh env /tmp/env and execute it via GNOME (double click the file and select 'run') and then check the PATH variable in /tmp/env it does _not_ include the perl directory. What is the correct way to set this variable? I always thought it is set in /etc/profile.d/ but it is already there. Take a look at [1]. Basically the profile configuration files are for shell environments, but a DE is not a shell and is not run from one. According to that page, you can add the graphical environment in $HOME/.xinitrc. HTH [1]: https://wiki.archlinux.org/index.php/Environment_variables
Re: [arch-general] PATH variable not set in DE (GNOME)
/etc/environment is an option. This is used by pam_env, and applies to
all PAM-authenticated sessions.
However /etc/profile.d is used by most DEs. Did you export PATH?
On 2015年04月25日 09:03, Maximilian Kaul wrote:
Hello list,
I'm currently experiencing something weird on a (less than regularly,
but recently) updated Arch machine. After the last update some graphical
programs that rely on the path variable being properly set stopped
working. In particular one application uses exiftool, and works properly
if started from the command line. However, if I open an image, the
application complains that it can not find exiftool.
So I checked in a terminal:
$ which exiftool
/usr/bin/vendor_perl/exiftool
$ echo $PATH
.../usr/bin/vendor_perl...
BUT
if I put the following code in a file
#!/bin/sh
env /tmp/env
and execute it via GNOME (double click the file and select 'run') and
then check the PATH variable in /tmp/env it does _not_ include the perl
directory.
What is the correct way to set this variable? I always thought it is set
in /etc/profile.d/ but it is already there.
# grep -R vendor_perl /etc
grep: /etc/systemd/system/multi-user.target.wants/lm_sensors.service: No such
file or directory
grep: /etc/pacman.d/gnupg/S.gpg-agent: No such device or address
/etc/profile.d/perlbin.csh:[ -d /usr/bin/vendor_perl ] setenv PATH
${PATH}:/usr/bin/vendor_perl
/etc/profile.d/perlbin.csh:[ -d /usr/lib/perl5/vendor_perl/bin ] setenv PATH
${PATH}:/usr/lib/perl5/vendor_perl/bin
/etc/profile.d/perlbin.sh:[ -d /usr/bin/vendor_perl ]
PATH=$PATH:/usr/bin/vendor_perl
/etc/profile.d/perlbin.sh:[ -d /usr/lib/perl5/vendor_perl/bin ]
PATH=$PATH:/usr/lib/perl5/vendor_perl/bin
Is there some way I do not know about? Is this a GNOME problem, or is
something else causing this?
The program used to run and find exiftool. I checked with the developer
because my first thought was that they changed something about how they
detect exiftool. They did not.
Thank you for your help!
Maximilian
Re: [arch-general] pacman's Depends On
On Fri, Apr 24, 2015 at 8:06 AM, Ralf Mardorf ralf.mard...@rocketmail.com wrote: On Fri, 24 Apr 2015 06:41:27 +0200, Ralf Mardorf wrote: On Thu, 23 Apr 2015 22:56:56 +0300, Jesse Jaara wrote: What you need to do is to create a custom package for the specific version of libvpx that doesn't conflict with the one from repo, so you can have both the new version for repo packages and the old version for whatever reason Yes, I was thinking of simply installing the new package and copying /usr/lib/libvpx.so.1.3.0 from a backup and add the links /usr/lib/libvpx.so.1 /usr/lib/libvpx.so.1.3 manually, instead of building a package for the old version. However, I can't do this for /usr/lib/libvpx.so and the bins, that perhaps aren't needed from the old package. It works :). This is because of the so called SONAME. That is the name in a shared library that will be to look for it when it is used in a program. Usually, in standard linux packages the SONAME of a shared library includes only the major version number. For example, with the latest version: $ objdump -p /usr/lib/libvpx.so | grep SONAME SONAME libvpx.so.2 And with an old one, I assume: $ objdump -p /usr/lib/libvpx.so.1.3.0 | grep SONAME SONAME libvpx.so.1 You can check the SONAME used by VirtualBox with this command: $ objdump -p /usr/lib/virtualbox/components/VBoxC.so | grep vpx NEEDED libvpx.so.2 And check whether the file is found with: $ ldd /usr/lib/virtualbox/components/VBoxC.so | grep libvpx libvpx.so.2 = /usr/lib/libvpx.so.2 (0x7f095d9e8000) The bottom line is that if the conflict is between different major version of the library, no problem: just copy libvpx.so.1 to /usr/lib/ or /usr/local/lib/. The libvpx.so symbolic link exists because it will be the library name used to build new programs, but it is not needed in runtime. HTH -- Rodrigo
Re: [arch-general] Add wpa_supplicant to the Group 'Base'
I strongly disagree. wpa_supplicant is pretty huge and unnecessary for many people I for one have a couple of installations without wireless connections at all..
[arch-general] Add wpa_supplicant to the Group 'Base'
Hi I recently installed archlinux over the air (wifi) and after a reboot I realizied sh**t you forgot to install wpa_supplicant to get connect to the world (over wifi / wpa/wpa2) and install more packages. So I had to restart, boot to the live system, mount the whole crypt stuff, (arch-chroot) and install wpa_supplicant. In my opinion wpa_supplicant is an important tool, so is it possible to add it to the group 'base'? Cheers H8H
Re: [arch-general] Add wpa_supplicant to the Group 'Base'
In my opinion wpa_supplicant is an important tool, so is it possible to add it to the group 'base'? I strongly disagree. wpa_supplicant is pretty huge and unnecessary for many people, and it also introduces a large additional surface area for exploits. Bennett -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808 signature.asc Description: OpenPGP digital signature
Re: [arch-general] Add wpa_supplicant to the Group 'Base'
I agree that wpa_supplicant probably should not be in base, but it's worth mentioning that base already has many packages not useful to a lot of people - I for example don't have any of these installed: dhcpcd jfsutils reiserfstools xfsprogs cryptsetup lvm2 mdadm nano netctl
Re: [arch-general] Add wpa_supplicant to the Group 'Base'
On 25.04.2015 17:51, Neven Sajko wrote: I agree that wpa_supplicant probably should not be in base, but it's worth mentioning that base already has many packages not useful to a lot of people - I for example don't have any of these installed: dhcpcd jfsutils reiserfstools xfsprogs cryptsetup lvm2 mdadm nano netctl +1 for keeping wpa_supplicant out of the base group. And just a general reminder, because it fits into this discussion: Before complaining about missing (make) dependencies, remember that the base group is assumed to be installed on all Arch Linux systems. The group base-devel is assumed to be installed when building with makepkg or when using AUR helpers. [1] [1] https://wiki.archlinux.org/index.php/Makepkg#Usage
