Re: [arch-general] glibc 2.15 - glibc 2.16 New Build Failures (scope primarily) Expected??
On 20 July 2012 22:34, David C. Rankin drankina...@suddenlinkmail.com wrote: Guys, After going though the usrlib/glibc update and creating a new archroot for building, I am getting build failures in trinity k3b and k9copy. Both packages built without error on 7/14 prior to my update. Following update I experience the following: k3b: summary: k3bffmpegwrapper.cpp:131:63: error: 'dump_format' was not declared in this scope k9copy: summary: k9avidecode.h:35:91: error: 'AVFormatParameters' has not been declared Two questions (1) are new build failures expected as the result of glibc 2.15 - 2.16 update that require source updates; (2) is anyone else experiencing this on project they are working with? -- David C. Rankin, J.D.,P.E. These two are not caused by glibc update but ffmpeg 0.11.
Re: [arch-general] TeXlive 2012 packages
On 2012/6/26 Rémy Oudompheng remyoudomph...@gmail.com wrote: Hello, I am going to put Texlive 2012 packages in [testing]. Texlive 2012 is not yet released, but it is frozen, so I do not expect changes to these packages except to fix packaging errors. Please try them and complain on mailing lists. Don't hesitate to compile your own theses, memoirs or books. The packages will move today. Rémy.
Re: [arch-general] python needs /usr/include/?
Rodrigo Rivas rodrigorivasco...@gmail.com on Sat, 2012/07/21 00:36:
On Sat, Jul 21, 2012 at 12:25 AM, Rodrigo Rivas rodrigorivasco...@gmail.com
wrote:
On Fri, Jul 20, 2012 at 8:32 PM, Christian Hesse l...@eworm.de wrote:
Hello everybody,
I am creating live media and want to reduce size. After
removing /usr/include/ wicd fails to start because of a missing header
file.
Do you know which one is trying to read?
If not, you could try running it with `strace` to see what it is looking
for:
Replying to myself, the file it reads is
`/usr/include/python2.7/pyconfig.h` (for python2).
You can see the relevant code in the deeps of the initialization routines
of the python library, sysconfig.py:
# load the installed pyconfig.h:
config_h = get_config_h_filename()
try:
with open(config_h) as f:
parse_config_h(f, vars)
except IOError, e:
msg = invalid Python installation: unable to open %s % config_h
if hasattr(e, strerror):
msg = msg + (%s) % e.strerror
raise IOError(msg)
It seems to be used to discover the configuration of the current python
installation.
Just copying this file to your live media should be enough to make it
happy. Or alternatively, you might modify the sysconfig.py to read the file
from other place (`/usr/lib/python2.7` for example).
At the moment I do this
find /usr/include/ -type f -and -name -not pyconfig.h -delete
find /usr/include/ -type d -empty -delete
instead of a simple rm -r /usr/include/.
However the question is whether or not Arch should move the file
to /usr/lib/python2.7/. As said before, my understanding is that files with
configuration data used for runtime should not live in /usr/include/.
--
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c ./sig*/b/42*2-3)*42);}
Re: [arch-general] pm-hibernate not working since update to 3.4.5-1-ARCH
Hello Ike, On Fri, Jul 20, 2012 at 10:15:48PM +0200, Ike Devolder wrote: Op vrijdag 20 juli 2012 22:06:31 schreef Arvid Warnecke: On Fri, Jul 20, 2012 at 03:52:34PM -0400, Daniel Wallace wrote: On Fri, Jul 20, 2012 at 09:53:01PM +0200, Arvid Warnecke wrote: Is there an ideal way of replacing nvidia by nvidia-ll? I build the utils, but am not able to install it, because the actually installed nvidia requires the other nvidia-utils. remove the ones that are already installed, and then finish building and installing the new ones That results in removing 41 packages depending on nvidia and nvidia-utils. Any better way? or follow the following steps without rebooting: 1) build 'nvidia-utils-ll' 2) remove 'nvidia' 3) install 'nvidia-utils-ll' 4) build 'nvidia-ll' 5) install 'nvidia-ll' and that should do it and not get you to remove many packages Worked well. But did not solve the problem. Hibernation still seems to work at first, but when I start the laptop it boots normally, fscks disks because of unclean unmount and leaves me with a freshly rebooted machine. What does work now with 295.59 for me is pm-suspend. I read a lot about people having issues with nvidia from official, too. But with vbetool dpms on in my handler.sh it seems to work pretty well. Cheers, Arvid -- [ Arvid Warnecke ][ arvid (at) nostalgix (dot) org ] [ IRC/OPN: madhatter ][ http://www.nostalgix.org ] ---[ ThreePiO was right: Let the Wookiee win. ]--- pgpSj0JijuZey.pgp Description: PGP signature
Re: [arch-general] Still Glibc problems
General Discussion about Arch Linux arch-general@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.0.so /bin/ln -s /usr/lib /lib 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/ /archroot : where 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
Re: [arch-general] pm-hibernate not working since update to 3.4.5-1-ARCH
Op zaterdag 21 juli 2012 13:30:24 schreef Arvid Warnecke: Hello Ike, On Fri, Jul 20, 2012 at 10:15:48PM +0200, Ike Devolder wrote: Op vrijdag 20 juli 2012 22:06:31 schreef Arvid Warnecke: On Fri, Jul 20, 2012 at 03:52:34PM -0400, Daniel Wallace wrote: On Fri, Jul 20, 2012 at 09:53:01PM +0200, Arvid Warnecke wrote: Is there an ideal way of replacing nvidia by nvidia-ll? I build the utils, but am not able to install it, because the actually installed nvidia requires the other nvidia-utils. remove the ones that are already installed, and then finish building and installing the new ones That results in removing 41 packages depending on nvidia and nvidia-utils. Any better way? or follow the following steps without rebooting: 1) build 'nvidia-utils-ll' 2) remove 'nvidia' 3) install 'nvidia-utils-ll' 4) build 'nvidia-ll' 5) install 'nvidia-ll' and that should do it and not get you to remove many packages Worked well. But did not solve the problem. Hibernation still seems to work at first, but when I start the laptop it boots normally, fscks disks because of unclean unmount and leaves me with a freshly rebooted machine. What does work now with 295.59 for me is pm-suspend. I read a lot about people having issues with nvidia from official, too. But with vbetool dpms on in my handler.sh it seems to work pretty well. Cheers, Arvid and for the hibernation, do you have the resume=/my/swap' and do you have the resume hook in your mkinitcpio.conf ? personally i dont use hiberantion since that or fresh boot are both taking approx the same time so then i prefer fresh boot :p. --Ike signature.asc Description: This is a digitally signed message part.
Re: [arch-general] Still Glibc problems
Norbert Zeh said the following at 07/20/2012 05:34 PM : 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. I got the same error at that point. What this means is that you either have some unowned (by any package) files in /lib (/lib/modules/* is a good candidate) or you have some other packages (most likely from AUR) owning files under /lib. The wiki page explains well how to look for them. At least, I followed those instructions and managed to identify the packages that blocked the upgrade. The key here really seems to be to make sure that glibc is the only package which at this point owns anything under /lib. I think in my case it also helped to uninstall some packages and reinstall them after the glibc upgrade. Keep pushing, you're almost there ;) The instructions (as so often) are not clear. If after this the pacman -Su still has conflicts with /lib, this is likely because a package on your system other than glibc owns files in /lib. Such packages can be detected using: $ grep '^lib/' /var/lib/pacman/local/*/files So this gives: root@shack tmp]# grep '^lib/' /var/lib/pacman/local/*/files /var/lib/pacman/local/glibc-2.15-10/files:lib/ /var/lib/pacman/local/glibc-2.15-10/files:lib/ld-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/ld-linux.so.2 /var/lib/pacman/local/glibc-2.15-10/files:lib/libBrokenLocale-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libBrokenLocale.so.1 /var/lib/pacman/local/glibc-2.15-10/files:lib/libSegFault.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libanl-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libanl.so.1 /var/lib/pacman/local/glibc-2.15-10/files:lib/libc-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libc.so.6 /var/lib/pacman/local/glibc-2.15-10/files:lib/libcidn-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libcidn.so.1 /var/lib/pacman/local/glibc-2.15-10/files:lib/libcrypt-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libcrypt.so.1 /var/lib/pacman/local/glibc-2.15-10/files:lib/libdl-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libdl.so.2 /var/lib/pacman/local/glibc-2.15-10/files:lib/libm-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libm.so.6 /var/lib/pacman/local/glibc-2.15-10/files:lib/libmemusage.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libnsl-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libnsl.so.1 /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_compat-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_compat.so.2 /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_db-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_db.so.2 /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_dns-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_dns.so.2 /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_files-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_files.so.2 /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_hesiod-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_hesiod.so.2 /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_nis-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_nis.so.2 /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_nisplus-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_nisplus.so.2 /var/lib/pacman/local/glibc-2.15-10/files:lib/libpcprofile.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libpthread-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libpthread.so.0 /var/lib/pacman/local/glibc-2.15-10/files:lib/libresolv-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/libresolv.so.2 /var/lib/pacman/local/glibc-2.15-10/files:lib/librt-2.15.so /var/lib/pacman/local/glibc-2.15-10/files:lib/librt.so.1 /var/lib/pacman/local/glibc-2.15-10/files:lib/libthread_db-1.0.so
Re: [arch-general] Still Glibc problems
Maybe I'm missing an instruction somewhere, but I don't see it.
Doc
My reading comprehension may be lacking, but did you check to see if
there are any files in /lib that are *not* owned by any package?
find /lib -exec pacman -Qo -- {} +
Commonly there are some directories like /lib/modules or in my case a
stray udev file that didn't get cleaned up automatically.
Ariel
Re: [arch-general] Still Glibc problems
On Sat, Jul 21, 2012 at 4:57 PM, D. R. Evans doc.ev...@gmail.com wrote: I *think* that this means that in fact glibc owns all the files. It means that no other package owns any files. It might still be that there are files in /lib that are not owned by any package. pacman -Qo /lib/* should tell you (or simply ls /lib and compare with the list you pasted in your previous email). -t
Re: [arch-general] Still Glibc problems
Ariel Popper said the following at 07/21/2012 09:24 AM :
My reading comprehension may be lacking, but did you check to see if
there are any files in /lib that are *not* owned by any package?
find /lib -exec pacman -Qo -- {} +
Commonly there are some directories like /lib/modules or in my case a
stray udev file that didn't get cleaned up automatically.
Ariel
I concluded that I should just cross my fingers and delete /lib/modules. That
worked. Thank you to everyone for helping me with this. Sorry it took so long.
Doc
--
Web: http://www.sff.net/people/N7DR
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] Still Glibc problems
On 07/21/2012 11:24 AM, Tom Gundersen wrote:
On Sat, Jul 21, 2012 at 4:57 PM, D. R. Evans doc.ev...@gmail.com wrote:
I *think* that this means that in fact glibc owns all the files.
It means that no other package owns any files. It might still be that
there are files in /lib that are not owned by any package. pacman -Qo
/lib/* should tell you (or simply ls /lib and compare with the list
you pasted in your previous email).
-t
find /lib -exec pacman -Qo -- {} + 21 | grep 'No package'
Re: [arch-general] pm-hibernate not working since update to 3.4.5-1-ARCH
On Sat, Jul 21, 2012 at 04:27:41PM +0200, Ike Devolder wrote: Op zaterdag 21 juli 2012 13:30:24 schreef Arvid Warnecke: Worked well. But did not solve the problem. Hibernation still seems to work at first, but when I start the laptop it boots normally, fscks disks because of unclean unmount and leaves me with a freshly rebooted machine. What does work now with 295.59 for me is pm-suspend. I read a lot about people having issues with nvidia from official, too. But with vbetool dpms on in my handler.sh it seems to work pretty well. and for the hibernation, do you have the resume=/my/swap' and do you have the resume hook in your mkinitcpio.conf ? No. But I never had and it worked until last week. I will look into that then. personally i dont use hiberantion since that or fresh boot are both taking approx the same time so then i prefer fresh boot :p. I agree, but because I still loose battery capacity while suspended, I prefered hibernation. Cheers, Arvid -- [ Arvid Warnecke ][ arvid (at) nostalgix (dot) org ] [ IRC/OPN: madhatter ][ http://www.nostalgix.org ] ---[ ThreePiO was right: Let the Wookiee win. ]--- pgpoRmSTNSG68.pgp Description: PGP signature
[arch-general] Was [arch-dev-public] [ANNOUNCE] initscripts-2012.07.3
On Sat, Jul 21, 2012 at 4:51 AM, Tom Gundersen t...@jklm.no wrote: On Sat, Jul 21, 2012 at 8:48 AM, Evangelos Foutras evange...@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!
Re: [arch-general] Was [arch-dev-public] [ANNOUNCE] initscripts-2012.07.3
On Sat, Jul 21, 2012 at 3:02 PM, Myra Nelson myra.nel...@hughes.net wrote: 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. this is accurate/fair -- `systemd` is sort of an umbrella term for many tools at this point -- even udev -- and no one is being forced to use systemd proper. developers are merely leveraging the many small, *independent* tools it provides: # pacman -Qql systemd-tools |grep -E 'systemd[-a-z]+$' ... will show you these tools -- all generic and useful in their own right -- highly relevant to the [near identical] duties tasked to initscripts. [...] 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. i don't think there is an obscene number of files to manage, and, at least IMO, using them simply means ones step closer to upstream. at the end of the day, one must acknowledge that we exist within a greater ecosystem, and resisting one's nature/environment rarely lends greater success. many upstream developers critical to Arch's basic operations are funded by distro's such as those you list ... it's only natural that their ideas and practices become intermixed and applied locally, no matter how much one resists otherwise. everyone is working towards the better, even if they appear -- or even literally *are* -- in conflict with each other or the status quo ... the greatest enemy, however, is that of stagnation, and perpetual good enough, as that only takes you where you've already been. -- C Anthony
Re: [arch-general] Still Glibc problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/20/12 15:34, John Briggs wrote: General Discussion about Arch Linux arch-general@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.0.so /bin/ln -s /usr/lib /lib 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/ /archroot : where 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. - -- David Benfell benf...@parts-unknown.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQCxrjAAoJELT202JKF+xpmCEP+wTlt5/a3ZRgtZT+1/ZsBT97 XNFK4QTOaq3bb+kHO1pMkarvq3e52GoSIMGysqRSWAhiqeZ40aOwqDcpUmdpB7VM fqLeY/0izJmR9lsbSAKiyH3JvjzdcLUdR/qJnTkihOY+MzO9QwOtNrn+QzoT26yo +SJvoDGPjOisgL+sPuK8QfZP1ET4Avu4xxI7bv+kGAJj6QNLvMf5Kj30GF1d8a0/ F0cxKRV55cR9pthTx9SLceOhyB/IPMWQBfj7Ng2ONXoJpkQF5+/3BahDBjXV5h9R c5zlNt0nC8ckucyGcstVq9eKCIAfrBxtq+k995Ty6ZQEJfwUnTRYkU61YeN4NZxT olMIWMbqyF5YnaEDEsQ75x1m/9BwVz4c2HDs7Exe6yCk3+HNGN4opTjyU7n62zvl CWu/UFzoU+TcmsqBK7tklE1R7JdwjY8z/zVRHl8cL+kw/PM2yJqZxnuVjTv2vGDL x0fc8MFGpa0HGdBmOP0IqglbW6AzqY89TXiG1prhGAzUZFAsqSgAAkK1isIwKa1P 4msQz/9KGftEjIEtUTXJ4GqCc02HTHYM4bJno0d47EA2bJNnkoFGvNkYKc00eFxE Zf6I+pkd/6RQTa3vixMsFTVV+TgZb1CIqg91rrDYfdxv/ICKqoGSUTsLuEt7QSXd yf6dLhAvtCh4cH2dRiqK =R7sP -END PGP SIGNATURE-
Re: [arch-general] Was [arch-dev-public] [ANNOUNCE] initscripts-2012.07.3
On Sat, Jul 21, 2012 at 3:59 PM, C Anthony Risinger anth...@xtfx.me wrote: On Sat, Jul 21, 2012 at 3:02 PM, Myra Nelson myra.nel...@hughes.net wrote: 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. this is accurate/fair -- `systemd` is sort of an umbrella term for many tools at this point -- even udev -- and no one is being forced to use systemd proper. developers are merely leveraging the many small, *independent* tools it provides: # pacman -Qql systemd-tools |grep -E 'systemd[-a-z]+$' ... will show you these tools -- all generic and useful in their own right -- highly relevant to the [near identical] duties tasked to initscripts. [...] 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. i don't think there is an obscene number of files to manage, and, at least IMO, using them simply means ones step closer to upstream. at the end of the day, one must acknowledge that we exist within a greater ecosystem, and resisting one's nature/environment rarely lends greater success. many upstream developers critical to Arch's basic operations are funded by distro's such as those you list ... it's only natural that their ideas and practices become intermixed and applied locally, no matter how much one resists otherwise. everyone is working towards the better, even if they appear -- or even literally *are* -- in conflict with each other or the status quo ... the greatest enemy, however, is that of stagnation, and perpetual good enough, as that only takes you where you've already been. -- C Anthony C Anthony: In fairness to your rebuttal, you are absolutely correct and moving Arch toward mainstream is probably a good idea. My hesitation is removing choices users are able to make. The choice for simplicity or complexity. As for stagnation, I've fought stagnation in the oil and gas service industry for 30 years and the we've always done it this way so why change. It's not change that bothers me, it's change for changes sake. I don't consider it change, it's evolution. I surprise most of the younger generation in the area I live in, under 50, because I've been using and repairing computers since 1987, building them since 1993, and online since 1998. I'm also one of the old timers who rebels against any system that forces me to do something I don't like or think is necessary. I've never believed that the PTB's are always right, they just happen to be in the drivers seat. As John Cougar Mellencamp once stated I fought authority and authority won IMHO opinion the option should remain to keep both solutions and let the user choose which way the wish to use. In all fairness to the developers, I realize that solution entails more work for them and I apologize for making such a request. Myra -- Life's fun when your sick and psychotic!
Re: [arch-general] [arch-dev-public] [ANNOUNCE] initscripts-2012.07.3
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
[arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Hello. I've read all the arguments of Tom and Ionut. Here is my own $0.02 on it. When I started using archlinux back in end of 2008, the winning point was this file. A centralized one where you can set up a lot of single options. It is *far* simpler to edit /etc/rc.conf to load daemons or modules than editing 2 or 3 files. Killing /etc/rc.conf can't be do so soon. Or you'll see a lot of old users moving their on other distributions. For me it will be a one way ticket to fedora. And I *do hate* this idea. But developpers must know better than users what is the best for the distro. Killing /etc/rc.conf ? Why not. But for me, it is more KISS oriented than /etc/locale.conf, /etc/vconsole.conf, /etc/modprobe.d/*.conf files. As I said, it is my $0.02. Excuse my bad english, I'm no really awake ! -- Frederic Bezies fredbez...@gmail.com
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Hello. I've read all the arguments of Tom and Ionut. Here is my own $0.02 on it. When I started using archlinux back in end of 2008, the winning point was this file. A centralized one where you can set up a lot of single options. It is *far* simpler to edit /etc/rc.conf to load daemons or modules than editing 2 or 3 files. Killing /etc/rc.conf can't be do so soon. Or you'll see a lot of old users moving their on other distributions. For me it will be a one way ticket to fedora. And I *do hate* this idea. But developpers must know better than users what is the best for the distro. Killing /etc/rc.conf ? Why not. But for me, it is more KISS oriented than /etc/locale.conf, /etc/vconsole.conf, /etc/modprobe.d/*.conf files. As I said, it is my $0.02. Excuse my bad english, I'm no really awake ! -- Frederic Bezies fredbez...@gmail.com That's exactly my thoughts ... *BSD will be next, if rc.conf been deprecated. Sorry for my English too
