- Arch-general - lists.archlinux.org

[arch-general] Delete the package magicassistant-gtk-multi 1.2.5.2-0
by Tanguy ALEXIS 24 Jul '12

24 Jul '12

Hi, Since the package I was maintening (magicassistant-gtk-multi 1.2.5.2-0) is now a doublon of (magicassistant-gtk 1.2.5.2-2), can you please merge the comment and delete it. Thanks,

2 1

[arch-general] Arch's move to systemd integration
by Myra Nelson 23 Jul '12

23 Jul '12

I've followed this discussion closely and, as can be seen in one of the posts below, I initially objected to it. I had previously tried systemd with little success. Next I carefully re-read all the objections, complaints, rants, raves, etc, and decided to try systemd again. This isn't the place for personal info but I think it's relevant here. I suffer from early onset dementia so it takes me more time to understand documentation and retain information. Most of the time I have to start over everytime I work on something because no matter how many times I've done it, it doesn't stick. That's one reason I prefer the rc.conf file and initscipts, it's easy to understand and keep track off. I posted last night that it took me around 30 minutes reading and editing to get my system booted properly. I was wrong. I still have a couple of minor glitches, but nothing that breaks my system. I firmly believe part of the problem is perception. Previously rc.conf held all the information. On my system rc.conf is 716 B. The three files (hostname 8 B, vconsole.conf 47 B, and locale.conf 30 B) take up less space. Granted at the moment it's more but that will be offset when the move to systemd can be completed. If I understand everything correctly the conf.d and rc.d directorys will no longer be needed as everything will be in /etc/systemd. The amount of disk space taken up should, major caveat, be less because most of the files in /etc/systemd/system/??? are soft links to the acutal files in /usr/lib/systemd/system. Yes, apparently, this changes(?) some of Arch's KISS principle, but maybe it doesn't. Maybe it actually makes it easier in the long run. If you keep /etc backed up, you do don't you, it's a simple matter to set everything up whenever where ever. I think the biggest problems here are "perception", resistance to change - me, possibly some FUD, and no one likes being told what to do. My main motivation for trying systemd again stemmed from realizing I was using the same arguments I fought in another industry for years "We've done it that way for 30 years and it works, why change now". Don't think of it as change, think of it as "evolution". Everyone believes in evolution, don't you? If this provides better integration with upstream developers might that mean less breakage, patched software, less complaints, and less bug reports to deal with for the Arch Devs. I'm proof even old dogs can learn new tricks. I'm open to discussion on any points I made about assumptions of what will and won't be necessary when the systemd integration is completed, ie conf.d and rc.d etc. Links to previous discussions. https://mail.google.com/mail/?shva=1#label/archlinux%2Fgeneral/138ad0e07444… https://mail.google.com/mail/?shva=1#label/archlinux%2Fgeneral/138ab21f72d9… https://mail.google.com/mail/?shva=1#label/archlinux%2Fdev-public/138a6cee4… Myra -- Life's fun when your sick and psychotic!

9 17

[arch-general] Why was wv2 dropped from extra? wv does _not_ provide the wv2 headers
by David C. Rankin 23 Jul '12

23 Jul '12

Guys, Why was wv2 dropped from extra? Nothing else provides the headers: wv2 /usr/include/wv2/associatedstrings.h wv2 /usr/include/wv2/convert.h wv2 /usr/include/wv2/dllmagic.h wv2 /usr/include/wv2/fields.h wv2 /usr/include/wv2/fonts.h wv2 /usr/include/wv2/functor.h wv2 /usr/include/wv2/functordata.h wv2 /usr/include/wv2/global.h wv2 /usr/include/wv2/handlers.h wv2 /usr/include/wv2/lists.h wv2 /usr/include/wv2/olestorage.h wv2 /usr/include/wv2/olestream.h wv2 /usr/include/wv2/paragraphproperties.h wv2 /usr/include/wv2/parser.h wv2 /usr/include/wv2/parserfactory.h wv2 /usr/include/wv2/sharedptr.h wv2 /usr/include/wv2/styles.h wv2 /usr/include/wv2/textconverter.h wv2 /usr/include/wv2/ustring.h wv2 /usr/include/wv2/utilities.h wv2 /usr/include/wv2/word95_generated.h wv2 /usr/include/wv2/word97_generated.h wv2 /usr/include/wv2/word_helper.h wv2 /usr/include/wv2/wv2version.h wv2 /usr/include/wv2/wvlog.h It still builds fine (one glib fix to olestream.h - filed upstream). I was surprised when I went to install dependencies in a new chroot only to find that install failed due to no wv2. Can you guys put it back in extra? -- David C. Rankin, J.D.,P.E.

1 1

[arch-general] Install scripts
by Fons Adriaensen 23 Jul '12

23 Jul '12

On Sun, Jul 22, 2012 at 11:01:02AM -0000, Arch Linux: Recent news updates: Pierre Schmitz wrote: > New iso images containing a current Arch Linux snapshot have been released and > can be found on our [Download][1] page. I have not used the install scripts so far (probably will in a few days) but been reading the wiki pages, and I think I'm going to like this way of doing things. But it *definitely* goes against anything 'upstream' or 'mainstream'. So if the Arch devs/maintainers are invoking 'upstream' or some general tendencies in the Linux world as arguments for introducing changes, that has to be taken with some grains of salt. You can't say 'A' and '~A' as seems fit without undermining your credibility. Ciao, -- FA Do you know what is on the bottom of the mainstream ? Mediocrity. (T. Mann / L. Visconti).

2 1

Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
by Mateusz Loskot 23 Jul '12

23 Jul '12

On 22 Jul 2012 20:53, "Leonid Isaev" <lisaev(a)umail.iu.edu> wrote: > I wonder why everyone thinks that Archlinux is about a single config file... > It is the same myth as "Arch is faster than distro XYZ" or the "simple BSD init". No myth it is! "Arch's simple init system is heavily inspired by the *BSD way of incorporating calls from a single file (rc.conf) rather than the SysVinit directory structure containing dozens of symlinks for each runlevel." https://wiki.archlinux.org/index.php/Arch_Linux -- Mateusz Loskot (Sent from phone, apology for any top-posting or broken quoting)

1 0

[arch-general] Grub2 config file needs to be tweaked with last official ISO
by fredbezies 23 Jul '12

23 Jul '12

Hello. I've done today an install of archlinux in a virtualbox session. When I installed grub2 using pacstrap /mnt grub2-bios, I noticed that generated grub.cfg is not usable easily. As a workaround, I installed syslinux, and after first boot, I tweaked grub.cfg file. First, I removed "/boot" from both kernel and initramfs lines. After that, I copied the correct UUID from /etc/fstab file. I used my real box grub2 config file to fix this issue. Any idea to get a directly working grub.cfg file ? Thanks. -- Frederic Bezies fredbezies(a)gmail.com

6 7

[arch-general] Install Scripts
by Nicholas MIller 22 Jul '12

22 Jul '12

I just looked over the install script wiki page, and was curious if there was any plan on adding something similiar to AIF where you could browse the avalible packages, I know for me at least during install I may know what i need to install but don't think about it until i read it.

3 5

Re: [arch-general] Still Glibc problems
by John Briggs 22 Jul '12

22 Jul '12

On Sat, Jul 21, 2012 at 02:11:00PM -0700, David Benfell wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/20/12 15:34, John Briggs wrote: > > General Discussion about Arch Linux <arch-general(a)archlinux.org> > > > > > > On Fri, Jul 20, 2012 at 03:41:08PM -0600, D. R. Evans wrote: > >>> pacman -Su > >>> > >> > >> Not OK: > >> > >>> [root@shack n7dr]# pacman -Su :: Starting full system > >>> upgrade... resolving dependencies... looking for > >>> inter-conflicts... > >>> > >>> Targets (1): glibc-2.16.0-2 > >>> > >>> Total Installed Size: 33.94 MiB Net Upgrade Size: 0.83 > >>> MiB > >>> > >>> Proceed with installation? [Y/n] (1/1) checking package > >>> integrity > >>> [##########################################################################################] > >>> 100% (1/1) loading package files > >>> [##########################################################################################] > >>> 100% (1/1) checking for file conflicts > >>> [##########################################################################################] > >>> 100% error: failed to commit transaction (conflicting files) > >>> glibc: /lib exists in filesystem Errors occurred, no packages > >>> were upgraded. [root@shack n7dr]# > > > > After much investigation the only workaround for this problem I > > could discover and I have used on my three computers this week is: > > > > system reboot : updates system with new packages. This : step is > > critical or you could end up with : a borked system > > > > # pacman -Sfu : This forces the loading of glibc-2.16.0-2 : but > > errors out because /lib directory exists ignore errors : on the > > system. > > > > # /usr/lib/ld-2.16.0.so /bin/rm -r /lib /usr/lib/ld-2.16.so > > > > # /usr/lib/ld-2.16.0.so /bin/ln -s /usr/lib /lib /usr/lib/ld-2.16.so > > > > system reboot > > > > DANGER: If the above procedure is not followed exactly you can bork > > your system and it will need a complete rebuild. An other > > workaround is: > > > > # system reboot > > > > # pacman -Sfu > > > > Ignore errors use a live CD/USB and boot Linux. # mkdir /archroot > > > > # mount /dev/xxxx /archroot : where xxxx is the root partition > > > > # cd /archroot > > > > /archroot]# rm -r lib > > > > /archroot]# ln -s usr/lib ./lib > > > > system reboot > > > > HTH > > > > John > > > > PS: I have not read the complete thread so I do not know if someone > > else has already offered these solutions. JEB > > > > You're using some tricks I didn't know about (there are, I'm sure, > lots in that category), but I don't see how this procedure addresses > the problem of other packages having files in /lib. > It doesn't I didn't have other packages having files in /lib. One of my machines uses wifi and I had to update the carl9170-fw package so it was installed to /usr/lib. The residual entries in /lib was the modules and firmware directories. I was only seeking to get these systems working not on why they weren't according to the news. I followed the links to manual installation and got most of my information from there and I followed most of the sublinks too. I made an error in the above procedures: all instance of /usr/lib/ld-2.26.0.so should be replaced with /usr/lib/ld-2.16.so The system reboot is the critical step as it sets the system into a known configuration and prevent it from borking on the next step. If it is critical to know what packages are causing the problems use # pacman -Sfu and see whats left in the /lib directory or subdirectories. You'll probably find its the proprietary drivers that you use. Regards John

1 0

Re: [arch-general] [arch-dev-public] [ANNOUNCE] initscripts-2012.07.3
by Sam Mulvey 22 Jul '12

22 Jul '12

On Jul 21, 2012, at 2:40 PM, Pierre Schmitz wrote: > Did you even bother to read what Tom wrote? You can still use your old > rc.conf. It is just recommend to use the new config files instead. This > makes using initscripts and systemd in parallel easier. And there are > not 9k config files but three. I've read what Tom wrote both here and in the man page, and he's talking about the ArchLinux /etc/rc.conf as "the old way" and people being "gently pushed" toward using the new configuration files. In my experience, that's a step on the road toward deprecation and non-support. For those of us who are well served by the rc.conf way of doing things, this could be a cause of concern, and now seems like an appropriate time to speak up. I would prefer to run systemd as little as possible. A central config file and reasonably transparent init system fit my case much better. -Sam

1 0

[arch-general] Was [arch-dev-public] [ANNOUNCE] initscripts-2012.07.3
by Myra Nelson 21 Jul '12

21 Jul '12

On Sat, Jul 21, 2012 at 4:51 AM, Tom Gundersen <teg(a)jklm.no> wrote: > On Sat, Jul 21, 2012 at 8:48 AM, Evangelos Foutras > <evangelos(a)foutrelis.com> wrote: > > I find removing most of the variables to be confusing and would > > suggest that [1] and [2] get reverted. > > I'm not going to revert them outright, but we can discuss individual > options (some clearly must go, others are a matter of taste). > > > My counterargument is the nonexistence, in the previous rc.conf, of > > default options that would need to be changed in a way that is > > transparent to the user. > > I guess I should have pointed out that I'd like a way to update the > comments about each of the options frequently (mainly to add warnings > or explanations as we realise them), but when the comments were in > rc.conf that would create .pacnew files, which is annoying. I'd also > like new users to have to read the manpage before they decide to use > any of the discouraged options, so they will at least know the > alternatives. > > > Moreover, stuff like TIMEZONE, LOCALE and MODULES should be included > > in rc.conf; nobody really wants to run their system with the default > > LOCALE=C, and quite a few people will want to load extra modules (in > > my case vboxnetflt), without messing around with other files > > (/etc/locale.conf) or adding variables back into rc.conf, > > respectively. > > I agree that most people would want to configure /etc/locale.conf and > /etc/vconsole.conf (or their equivalents in /etc/rc.conf). This is a > matter of taste, but I'd really rather we start only using the two > former files for this purpose. A benefit I did not mention yet is that > they allow a lot more options than what rc.conf ever did. > > As to modules: This should really not me necessary these days, and in > the cases it is, it is something we should consider fixing. With > kernel 3.5 the last of the mainline modules that I'm aware of (kvm) no > longer needs to be specified manually. > > In the case of virtualbox, I think the simplest solution here would be > to load the needed modules whenever virtualbox is installed. I.e., > ship a file with the virtualbox package > (/usr/lib/modules-load.d/virtualbox.conf) containing > > vboxnetadp > vboxnetflt > > (and whatever else is needed) > > > In conclusion, a) the existing rc.conf is already stripped down to the > > essential system configuration options, b) I like having a default > > structure of these options in rc.conf instead of adding them back in > > at random places (in rc.conf), c) if we want to shift the task of > > configuring the hostname/locale/keymap/etc to external files, it might > > be preferable to remove them completely from rc.conf instead of having > > multiple points of truth. > > a) this is not the case. The current rc.conf contains several > redundant and at least one harmful setting (HARDWARECLOCK). > > b) fair enough, though does not seem like a major issue. > > c) I'd like to do this in the long-run, but we can't just rip out the > old support over night (see the old network settings or the crypttab > changes for how I'd like these things to be done). > > > (The above is my view on this change after spending 10 minutes trying > > to figure out how I can load modules through /etc/modprobe.d, after I > > noticed that MODULES was removed from rc.conf. In my defense, I > > thought it could be similar to the time MOD_BLACKLIST was dropped. :p) > > rc.conf(5) points to modules-load.d(5)[0]. > > -t > > [0]: <http://0pointer.de/public/systemd-man/modules-load.d.html> > Tom: The concerns expressed by Evangelos and Tobias were some of the concerns I had when the push towards systemd started. Systemd is great if you are managing a large number of computers, but excessive overkill for one or two desktops with no server. The network setup is probably great for laptops also, but not in my instance. I get to learn to do it with iproute2. The simplest possible configuration for that setup is rc.conf. I'm not attempting to be a luddite, but something about this seems to violate the Arch KISS policy. Users of desktop systems shouldn't be forced into something like this. One of the reasons I chose Arch was the simplicity of setting up my system and not having some built in utility bork it for me. I find Arch much easier to set up and maintain than Fedora, Suse, Debian, Ubuntu, etc, etc, etc, and I wasn't forced in to their philosophy of setting up a "CORPORATE", yes I'm screaming, desktop. Currently Arch provides simple control mechanisms in central locations, and IMHO should stay that way. Please pardon my intrusion on a developer discussion, as I truly have no say in the matter. Just thought I'd toss in my 2 cents. Myra -- Life's fun when your sick and psychotic!

2 2