Re: [arch-general] Bind - working directory not writeable issue - a possible fix?
Hello Mike,
Le samedi 9 à 12:01, Mike Cloaked a écrit :
So doing:
[root@lapmike3 ~]# chmod 770 /var/named
But the question is whether or not this is a good thing to do? Does
anyone know if there are any bad consequences to resolving this
problem by changing the permissions of /var/named as I have done
above? If this is a good solution shouldn't that permission be set
that way when the bind package (bind 9.9.2.P1-1) is initially
installed, so that it does not then need changing after the install?
I'm not familiar with Arch's bind installation, but if /var/named
contains anything not generated by bind as part of its operation you
probably don't want to do that. The only reference to the necessity of a
writable directory I've found is in chapter 6 of the Admin Manual :
The managed-keys statement, like trusted-keys, defines DNSSEC security
roots. The difference is that managed-keys can be kept up to date
automatically, without intervention from the resolver operator.
...
So, whenever named is using automatic key maintenance, those two files
[managed-keys.bind and managed-keys.bind.jnl] can be expected to exist
in the working directory. (For this reason among others, the working
directory should be always be writable by named.)
I've not find those amongst others.
For the record, under FreeBSD that I'm more familiar with, the default
config file contains:
options {
directory /etc/namedb/working;
// more options...
http://svnweb.freebsd.org/base?view=revisionrevision=200563
And /etc/namedb/working belongs to used bind, is 0755 and empty until
named writed its key files. Note that with an explicite directory
option, you will want to have fully-qualified paths for the other
directives that specify paths.
--
Fred
Re: [arch-general] How do I uncomment a locale?
On 14.12.2011 01:02, Sébastien Leblanc wrote: In your case it would be the Australian English locale (en_AU, I think). What is the difference between en_GB, en_US and en_AU ? Is the motd updated to tell you Good morning, Sir, Hi guy or Good day, mate? -- Fred
Re: [arch-general] Localization issues (Attention Developers)
Le vendredi 25 à 13:51, atilla ontas a écrit : You see, how variables reversed? So if you, developers, mind to and if it is possible use only one %s in a string it will be much appreciated. The strings that you find in a .po file are (almost always) fed to printf(3). In such a string, the first %s will be replaced with the next argument given to printf(3) (in the example you give, that would be a command name), the second %s with the following argument, and so on. However, instead of %s, you may use %m$s in order to point to the m-th following argument. This means the following string: Try using the %s environment by\nplacing %s in the %s array in %s. ┃ ┗▶ could have been %2$s ┗▶ could have been written %1$s Could be translated as: %4$s dosyası içindeki %3$s satırına %2$s değerini yerleştirerek %1$s ortamını kullanmayı deneyin. (My apologies if I got the Turkish sentence wrong, but you get the idea.) Also, if you, developers, mind to add comments what is %s (a command, an application, what??) it will be great help to translators. Greetings... When I did translations, I used po-mode in emacs that could jump me from a string to the corresponding source code. That would give quite a lot more context. I'm sure your $EDITOR for po file has a similar feature. -- Fred pgpGUw2QCgujq.pgp Description: PGP signature
Re: [arch-general] Ye Olde Package Manager
Le dimanche 16 à 2:01, Allan McRae a écrit : There has been low interest in a real database solution due to potential issues recovering from corrupt databases and with the additional dependencies. A question from a random user (one that won't submit more patches than the average user): Why would a database be more subject to corruption than a tar file, and harder to recover? -- Frédéric Perrin -- http://tar-jx.bz
Re: [arch-general] umask gnome
Le dimanche 16 à 7:22, Evangelos Foutras a écrit : On Sat, Jan 15, 2011 at 10:11 PM, Béla Vizer bela.vi...@gmail.com wrote: I put .bashrc and /etc/profiles the follwoing line: umask 077 I tried to put it to /etc/gdm/Xsession, I created .gnomerc but nothing. Is it even possible to set a system-wide umask settings? Put it in ~/.bashrc, before the following line: [ -z $PS1 ] return GNOME is launched from a user shell, and one that wouldn't read /etc/profile ? Sounds strange... Béla: have you looked into pam_umask? -- Frédéric Perrin -- http://tar-jx.bz
Re: [arch-general] Ye Olde Package Manager
Le dimanche 16 à 13:52, Ng Oon-Ee a écrit : On Sun, 2011-01-16 at 12:22 +0100, Frédéric Perrin wrote: Why would a database be more subject to corruption than a tar file, and harder to recover? An answer from an average user: I believe in tar files corruption would only affect the files stored at that 'place' in the tar files. So for example if there's a failing HD and 20 sections are affected, 'only' that information is lost. tar files are stored with a header (a 512-bytes block) that describes the file name, the size of the file, etc., then (filesize / 512) blocks of data, then 2 blocks of \0, and repeat for the next file. If one file header is corrupted and the file size can't be read or is wrong, everything after can't be read. Now, in our case, two blocks of \0 are unlikely in a text file, so this can be used to detect this case. Hum, maybe you're right, but still tar files seem rather bad prepared to deal with corruption. -- Frédéric Perrin -- http://tar-jx.bz
Re: [arch-general] xdg autostart files.
Hello, Le jeudi 13 à 22:58, Peter Lewis a écrit : I don't know much about XDG, but I was trying to figure out why every time I started up a desktop session (KDE) wicd-tray was being loaded, when I didn't want it to be. I couldn't find any reference to it in any of the KDE autostart directories. Then I noticed that it has a .desktop file in /etc/xdg/autostart, which is owned by wicd. I guess that I can delete the file, but that's a bit messy and it'll just get replaced when wicd gets upgraded anyway. GNOME has a thingy for stopping such applications to start with the user's session. It seems to mainly copy the .desktop file to ~/.config/autostart and add a line with X-GNOME-Autostart-enabled=false. Surely KDE has a similar feature (both a dialog box for choosing which applications to start, and a custom property to overrid the autostart). HTH, -- Frédéric Perrin http://tar-jx.bz
Re: [arch-general] PulseAudio in [testing]
Le mercredi 8 à 0:55, Brendan Long a écrit : Have you seen the PulseAudio volume control applet (for Gnome)? My favorite two parts are being able to control sound for each application separately (Pidgin doesn't need to be as loud as Banshee), and being able to switch output while things are playing (makes using a headset much nicer). I actually stopped using PulseAudio to try OSS, and I'm thinking of going back just for those two things. In OSS, ossxmix gives a per-application mixer, and also allows you to switch on/off outputs. NB: just launching ossxmix will both start the mixer and create a small applet in GNOME's panel; use ossxmix -S to not place an icon in the panel. -- Fred
Re: [arch-general] Spell Checking in Emacs
Le mercredi 20 à 22:47, Rthoreau a écrit : What would be ideal is to get Hunspell working if you follow the emacswiki I still do not have a valid Hunspell working on two operating systems. One being Arch, the other OpenIndiana so I had to resort back to aspell for both. Is the problem that you are sharing you .emacs between the two OSs, but Hunspell is available on only one? In that case, what about: (if (string-match -ARCH operating-system-release) (use hunspell) (fallback to aspell)) Or: (if (executable-find hunspell) (use hunspell...) (fallback to aspell)) -- Fred
[arch-general] audacious segfaults; can debug because of dependencies
Hello list, I tried audacious for a change this morning, but it segfaulted on visualisation change[1]. From the look of the backtrace[2], and seeing that glib was updated a couple of days ago, a simple rebuild of the package should be sufficient. I would normally have submitted that to the bug tracker, but didn't as : - it requires login to a web interface; - I can't test the suggested fix as audacious' PKGBUILD has a depends on audacious-plugins, and audacious-plugins has a makedepends on audacious. 1. - Steps to reproduce : - start playing a webradio, it happened with the MP3 flux from frequence3.fr - right click on the interface, select Visualisation / Type de visualisation, try each one in order then back to the first one, Analyseur. 2. % gdb audacious [...snip...] (gdb) run Starting program: /usr/bin/audacious [Thread debugging using libthread_db enabled] [New Thread 0xb718ab70 (LWP 12470)] [New Thread 0xb5f4fb70 (LWP 12471)] [New Thread 0xb492bb70 (LWP 12472)] [New Thread 0xb3fffb70 (LWP 12473)] [Thread 0xb3fffb70 (LWP 12473) exited] [New Thread 0xb3fffb70 (LWP 12474)] [Thread 0xb3fffb70 (LWP 12474) exited] [New Thread 0xb3fffb70 (LWP 12475)] [New Thread 0xb373fb70 (LWP 12476)] [New Thread 0xb2f1eb70 (LWP 12477)] [Thread 0xb2f1eb70 (LWP 12477) exited] [Thread 0xb373fb70 (LWP 12476) exited] [Thread 0xb3fffb70 (LWP 12475) exited] [New Thread 0xb3fffb70 (LWP 12478)] [New Thread 0xb373fb70 (LWP 12479)] [New Thread 0xb2f1eb70 (LWP 12480)] [Thread 0xb492bb70 (LWP 12472) exited] Program received signal SIGSEGV, Segmentation fault. 0xb618d444 in ui_vis_expose () from /usr/lib/audacious/General/skins.so (gdb) bt #0 0xb618d444 in ui_vis_expose () from /usr/lib/audacious/General/skins.so #1 0xb7c6d1f4 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #2 0xb7a55b99 in g_type_class_meta_marshal () from /usr/lib/libgobject-2.0.so.0 #3 0xb7a57252 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #4 0xb7a66b75 in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0 #5 0xb7a6f593 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #6 0xb7a6f9b6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #7 0xb7d9ec46 in gtk_widget_event_internal () from /usr/lib/libgtk-x11-2.0.so.0 #8 0xb7c6ba41 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #9 0xb7ae1d51 in _gdk_window_process_updates_recurse () from /usr/lib/libgdk-x11-2.0.so.0 #10 0xb7ae1cfd in _gdk_window_process_updates_recurse () from /usr/lib/libgdk-x11-2.0.so.0 #11 0xb7b13a04 in _gdk_windowing_window_process_updates_recurse () from /usr/lib/libgdk-x11-2.0.so.0 #12 0xb7add63c in gdk_window_process_updates_internal () from /usr/lib/libgdk-x11-2.0.so.0 #13 0xb7adf3f7 in gdk_window_process_all_updates () from /usr/lib/libgdk-x11-2.0.so.0 #14 0xb7adf47b in gdk_window_update_idle () from /usr/lib/libgdk-x11-2.0.so.0 #15 0xb7abcbc8 in gdk_threads_dispatch () from /usr/lib/libgdk-x11-2.0.so.0 #16 0xb7f3b041 in g_idle_dispatch () from /usr/lib/libglib-2.0.so.0 #17 0xb7f3ef72 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #18 0xb7f3f750 in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0 #19 0xb7f3fdfb in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #20 0xb7c6a439 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #21 0xb618323e in skins_init () from /usr/lib/audacious/General/skins.so #22 0x08056e3c in ?? () #23 0xb786cb96 in __libc_start_main () from /lib/libc.so.6 #24 0x08050a21 in ?? () -- Fred
Re: [arch-general] A question about Arch Sixty Four
Le lundi 24 à 0:29, C Anthony Risinger a écrit : On Mon, May 24, 2010 at 12:02 AM, Keith Hinton keithint1...@gmail.com wrote: I had a question about the sixty four bit port of Arch in general so figured this would be an okay place besides IRC to obtain any help I needed. I wanted to find out ruffly how much memory Arch sixty four will use for any program in general, regardless of GUI/console? i really don't think there is a way to answer this. i'm not an expert on hardware, but 64bit applies to the CPU, nothing else. a larger bottom level cache allows the CPU to view/consume more data/bits at once, and to perform better on precision mathematics like heavy floating point operations. i don't see it having much-to-any effect on RAM usage, but again maybe i'm missing something and then someone will surely correct me :-) On a 64 bit machine, in « char *p; », p will use 64 bits (8 bytes), instead of 4 bytes in a 32 bits machine [I'm talking about p, not about *p which doesn't look like it exists]. Gary Wright seems to be saying that the impact is negligible. Nicky726 seems to be saying that there is a difference of up to 80%. I am surprised by such a claim, but there seems to be anecdotes on Google of people seeing the same thing. As I don't have a 64 bits machine, I can't test for myself. -- Fred signature.asc Description: PGP signature
[arch-general] audacious segfaults; can debug because of dependencies
Hello list, I tried audacious for a change this morning, but it segfaulted on visualisation change[1]. From the look of the backtrace[2], and seeing that glib was updated a couple of days ago, a simple rebuild of the package should be sufficient. I would normally have submitted that to the bug tracker, but didn't as : - it requires login to a web interface; - I can't test the suggested fix as audacious' PKGBUILD has a depends on audacious-plugins, and audacious-plugins has a makedepends on audacious. 1. - Steps to reproduce : - start playing a webradio, it happened with the MP3 flux from frequence3.fr - right click on the interface, select Visualisation / Type de visualisation, try each one in order then back to the first one, Analyseur. 2. % gdb audacious [...snip...] (gdb) run Starting program: /usr/bin/audacious [Thread debugging using libthread_db enabled] [New Thread 0xb718ab70 (LWP 12470)] [New Thread 0xb5f4fb70 (LWP 12471)] [New Thread 0xb492bb70 (LWP 12472)] [New Thread 0xb3fffb70 (LWP 12473)] [Thread 0xb3fffb70 (LWP 12473) exited] [New Thread 0xb3fffb70 (LWP 12474)] [Thread 0xb3fffb70 (LWP 12474) exited] [New Thread 0xb3fffb70 (LWP 12475)] [New Thread 0xb373fb70 (LWP 12476)] [New Thread 0xb2f1eb70 (LWP 12477)] [Thread 0xb2f1eb70 (LWP 12477) exited] [Thread 0xb373fb70 (LWP 12476) exited] [Thread 0xb3fffb70 (LWP 12475) exited] [New Thread 0xb3fffb70 (LWP 12478)] [New Thread 0xb373fb70 (LWP 12479)] [New Thread 0xb2f1eb70 (LWP 12480)] [Thread 0xb492bb70 (LWP 12472) exited] Program received signal SIGSEGV, Segmentation fault. 0xb618d444 in ui_vis_expose () from /usr/lib/audacious/General/skins.so (gdb) bt #0 0xb618d444 in ui_vis_expose () from /usr/lib/audacious/General/skins.so #1 0xb7c6d1f4 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #2 0xb7a55b99 in g_type_class_meta_marshal () from /usr/lib/libgobject-2.0.so.0 #3 0xb7a57252 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #4 0xb7a66b75 in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0 #5 0xb7a6f593 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #6 0xb7a6f9b6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #7 0xb7d9ec46 in gtk_widget_event_internal () from /usr/lib/libgtk-x11-2.0.so.0 #8 0xb7c6ba41 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #9 0xb7ae1d51 in _gdk_window_process_updates_recurse () from /usr/lib/libgdk-x11-2.0.so.0 #10 0xb7ae1cfd in _gdk_window_process_updates_recurse () from /usr/lib/libgdk-x11-2.0.so.0 #11 0xb7b13a04 in _gdk_windowing_window_process_updates_recurse () from /usr/lib/libgdk-x11-2.0.so.0 #12 0xb7add63c in gdk_window_process_updates_internal () from /usr/lib/libgdk-x11-2.0.so.0 #13 0xb7adf3f7 in gdk_window_process_all_updates () from /usr/lib/libgdk-x11-2.0.so.0 #14 0xb7adf47b in gdk_window_update_idle () from /usr/lib/libgdk-x11-2.0.so.0 #15 0xb7abcbc8 in gdk_threads_dispatch () from /usr/lib/libgdk-x11-2.0.so.0 #16 0xb7f3b041 in g_idle_dispatch () from /usr/lib/libglib-2.0.so.0 #17 0xb7f3ef72 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #18 0xb7f3f750 in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0 #19 0xb7f3fdfb in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #20 0xb7c6a439 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #21 0xb618323e in skins_init () from /usr/lib/audacious/General/skins.so #22 0x08056e3c in ?? () #23 0xb786cb96 in __libc_start_main () from /lib/libc.so.6 #24 0x08050a21 in ?? () -- Fred
Re: [arch-general] A universal Operating System API - why don't we have it?
Le lundi 21 à 18:57, Laurie Clark-Michalek a écrit : And on the anal sex point... actually, I think it'd be better for the convocation as a whole if we dropped that analogy. Is that what they call a Freudian slip? -- Fred
Re: [arch-general] Good press at distrowatch.com
Le jeudi 17 à 20:35, Dieter Plaetinck a écrit : On Thu, 17 Dec 2009 13:33:22 -0500 Denis Kobozev d.v.kobo...@gmail.com wrote: On Thu, Dec 17, 2009 at 11:55 AM, Dieter Plaetinck die...@plaetinck.be wrote: did that guy actually say that point and click visual installers are a time *saver* ?? is he out of his mind? It seems that most reviews on distrowatch.com come from the standpoint that Ubuntu is the ultimate user-friendly system. Arch, Gentoo and Slackware users beg to differ, but I guess the most typical Linux user agrees and that's who they are catering to. it's not about userfriendliness, which is a very subjective topic. it's about time duration, which is scientifically measurable. I'm pretty sure a scripted automatic installation goes faster then one where you need to point and click to make it do things. You've never installed Debian/Ubuntu with a preseed.cfg file that answer all the questions for you (or, at your option, as many or as few questions as you wish)? You've never used FAI (Fully Automated Installed) either? (Well, I haven't, but a friend of mine, an Arch user, did, and he has only good things to say about its flexibility and the ease of setup.) I love to hate Ubuntu as much as the next guy, but the installer is not somewhere where Arch has an advantage. If you want an easy to use installer, as David pointed out in further in the thread, you go it; if you want to build an ISO that answers all the installer questions, you got it; if you want a setup where you can plug a machine, tell it to boot over the network, go drink a coffee and go back to a system completly installed, you got it. -- Fred
Re: [arch-general] A universal Operating System API - why don't we have it?
Le vendredi 18 à 10:24, RedShift a écrit : Things like enumerating all hardware devices, configuring a network interface, drawing a window, ejecting the CD-ROM drive, getting notified about new hardware plugged in, etc... It's different on every operating system. Isn't it one of the goals of hal ? It does exist outside of Linux (in FreeBSD for instance: http://www.freebsd.org/gnome/docs/halfaq.html). You cannot write a driver for Linux and expect it to work on FreeBSD. You cannot write an application for windows and expect it to work on Linux. When you buy a piece of hardware you usually hope for the best that it'll work out-of-the-box including all extra features. If OS internals are to be so similar that they expose the same API to hardware drivers, where is there room for differentiation between two OSes? FreeBSD, to continue with the unkwown giant, prides itself with writing a very well designed OS, whereas Linux (kernel userland) does not have the same quality standards. As a result, things evolve less quickly in FreeBSD, but are usually more stable. I'm talking about the architecture of the code; when was the last time a major subsystem of FreeBSD was rewritten? (I mean, except the USB stack in 8). -- Fred
Re: [arch-general] Good press at distrowatch.com
Le samedi 19 à 22:59, Dieter Plaetinck a écrit : You've never installed Debian/Ubuntu with a preseed.cfg file that answer all the questions for you (or, at your option, as many or as few questions as you wish)? You've never used FAI (Fully Automated Installed) either? I have used FAI extensively to mass-install servers. Don't put words in my mouth: my point was that point and click installers are not necessarily faster then what we have. Oh, I understood your original post as with all its shiny dialogs, Ubuntu won't let me install a damn OS with minimal human interaction. Sorry for that. Still, I keep on thinking that debian-install[1] is a nifty piece of software that does everything you can expect from an installer. BTW: debian/ubuntu installers are complex (in lines of code), especially if you add fai on top of that, which re-implements a lot of things. Dieter [1] The last time I installed Ubuntu, but that was long ago, it used a glorified d-i. Make a s/Ubuntu/Debian/ if they no longer use d-i. -- Fred
Re: [arch-general] Script for finding and moving older duplicate packages from /var/cache/pacman/pkg
Le mardi 25 à 17:03, Patrick Brisbin a écrit : tar -xf on a 3 GB cache - 1m 42s bsdtar -qxf on the same cache - 0m 9s If you ran both of them on the same set of files, BSD tar was certainly quicker because it took advantage of the files being cached thanks to the first run of GNU tar. Now, it may also be that BSD tar /is/ faster --we all know that GNU programs are crippled with too much features for their own good ;-). Do you get the same results if you run the same commands a couple of times in succession, discarding the first run ? -- Fred
Re: [arch-general] which package provides ifup ifdown command ?
Le mardi 25 à 10:05, Jeff Horelick a écrit : As Sven-Hendrik said, you need to use ifconfig $interface up and ifconfig $interface down. If you really need ifup and ifdown, put this in your .bashrc: alias 'ifup eth0'='ifconfig eth0 up' alias 'ifdown eth0'='ifconfig eth0 down You *do* realise that ifup does slightly more than ifconfig up ? -- Fred
Re: [arch-general] Emacs 23 window resize on startup
Le jeudi 30 à 15:15, Edgar Kalkowski a écrit : I just updated to Emacs 23 which has new fancy font code with antialiasing etc. However the default font of 12pt is way too big for my taste. So I changed it to 10pt and saved the configuration to my ~/.emacs file. Everything works fine -- the font is smaller now -- but: Every time I start Emacs now the window first resizes to the dimensions that would be needed by the old (bigger) font. I am not familiar enough with emacs' start-up process, but I would venture that the initial frame is created before your init file is read. Try specifying the font with a --font argument. And kudos to Jürgen Hötzel for having made emacs23 available hours after its release :-) -- Fred
Re: [arch-general] Openbox - great lightweight desktop, similar to icewm, but better in several regards
Le Mercredi 10 à 9:46, David C. Rankin a écrit : Listmates, After reading the newsletter article about old boxes with minimal hardware collecting dust in a closet, I thought about the openbox desktop I had just given a run-through and thought I would pass it along. You have several lightweight desktops to choose from, icewm, fluxbox, etc.., but also add openbox to the list. As a minimal desktop, it is pretty cool. I'm surprised that in this thread, nobody mentionned FVWM yet. It's a bit the great old one, one upon which quite a number of other WM are based, but it is still actively developped. It is maybe a bit bigger that other WM mentionned, but we are far from KDE / GNOME / XFCE. A great strength of FVWM is its configurability (don't forget it is coming from someone who uses emacs ;-). The default desktop is rather rough. Instead, you are expected to configure it to your linking. The behaviour of the WM is completely definable. You can have titlebars with ten buttons bind to any mouse button doing any action you wish, dynamic menu that fetch there contents over the Net, panels that swallow arbitrary applications. It supports UTF-8, PNG transparency and blending, binding actions to mouse motion (haven't tried this one yet...), Xft2 fonts, etc. It can be as silent or as intrusive as you like, just giving you a frame around windows to move them or a full environment that doesn't pity some DE's ones. There is quite a diversity of shots in fvwm.org's screenshots section (but the artistic taste of some is sometimes lacking :). -- Fred
Re: [arch-general] Fix or not fix? install scriptlets with user handling.
Hello, Le Vendredi 29 à 0:03, Daenyth Blank a écrit : On Thu, May 28, 2009 at 17:33, Attila att...@invalid.invalid wrote: But -1 for don't restarting because it is the job of a package management to guarantee that an upgrade is safe and if a daemon needs to restart than doing this is better as doing nothing. -1. Restarting it automatically is also bad. If it's currently stopped, restarting it will still start it, and the user may not want it stopped at all (which restarting it would do). I'm just an user, but... if I ask the service to be restarted when it is not started yet, I would expect the rc script to fail as early and loudly as possible, no ? Somebody suggested interactively asking the user about restarting the service, it means more babysitting of the upgrade process which is bad. A big warning message You should restart service $FOO when you are done updating is good. Even better, all such messages could be displayed at the end of the upgrade process, so that they are not lost in the middle of the normal progress indicators. Juste my €0.02. -- Fred
Re: [arch-general] How do we handle sudo or kdesu in Archlinux?
Le Jeudi 14 à 23:03, Attila a écrit : I prefer to use gpasswd because for me the big advantage is that you don't have to log out than. But i don't know too what speak against editing /etc/group by hand if you can live with it that you have to log out. You don't have to log out / log back in for a new group to take effect. There is the adequately named newgrp(1) that spawns a new shell with a different real and effective GID. -- Fred
Re: [arch-general] New vi/vim/gvim in testing requires intervention
Le Mercredi 6 à 13:07, Jan de Groot a écrit :
On Wed, 2009-05-06 at 07:54 -0300, André Ramaciotti wrote:
Just a question about this new vi package. Am I the only one having
problems when openning UTF-8 files? I can't even type words with
diacritics or vi will abort. For example, try to create a file with
the following and then open it with the new vi package:
This line will render fine
Mas essa aqui não (but this one won't in Portuguese).
[...]
If you want support for non-ASCII charsets and other things offered by
vim, just install vim.
I have a system whose users' real names can't be written in ASCII, and
this being the 21st century, not the 70's, I have the real name (with
accents) in the GECOS field in /etc/passwd. Not being a vi{,m} user, I
just have whatever the default package for vi is installed.
Then for whatever reason, /etc/passwd is b0rked, and I have to boot into
single usermode to repair that, and all I can use is vi. vi crashes when
I open /etc/passwd. Now what ? Or, $config_file has comments in my native
language, and vi crashes when I open it.
FreeBSD's vi (actually nvi) can't manage non-ASCII characters, but at
least it doesn't crash.
(Actually :
1. I'm an emacs user, so I would use emacs ;-p ;
2. cut -d: -f -4,6- /etc/passwd /etc/passwd.no-real)
--
Fred
Re: [arch-general] Starting gpg-agent on X login (gdm)
Le Lundi 27 à 5:12, Shridhar Daithankar a écrit :
Hmm.. I use kde and there is nothing for ssh-agent in /etc. I think it
should go in shell startup so that even non-gui session have ssh-agent
too.
I would agree with that. Having it enabled for everyone, I'm not sure.
You should consider adding it to /etc/skel if you have several users and
you want it to be pre-configured for every user you wall add.
#Start ssh-agent. Don't want to use agent from last session if it persits at
all.
Should I look into using seahorse instead of {ssh,gpg}-agent?
and I got to find a KDE equivalent too. :)
Choose a desktop agnostic one : keychain will automagically start
{ssh,gpg}-agent or use one if it is available. I find it nice to log in
into my desktop computer on the morning, unlock my SSH keys, and then
when later I'm moving, I can log back to my desktop and from there use
my SSH key to login to further machines. I guess it depends on your
computing habits. And well, I you really want only one daemon, you can
still tell keychain ot use gpg-agent's --enable-ssh-support (I never
tried).
Just add to your .${SHELL}login :
keychain
. ~/.keychain/chameau-sh
. ~/.keychain/chameau-sh-gpg
http://www.gentoo.org/proj/en/keychain/index.xml
--
Fred
Re: [arch-general] Understanding permissions
Le Jeudi 16 à 17:45, kludge a écrit : Dieter Plaetinck wrote: On Thu, 16 Apr 2009 14:36:36 +0200 Johannes Held m...@hehejo.de wrote: Maurício briqueabra...@yahoo.com: stat(/home/mauricio/public_html, 0x7fffceb2dcb0) = -1 EACCES (Permission denied) Is your ~ r-x for others? actually only x is needed to traverse directories. and, iirc, if the user in question needs to traverse a higher level directory for which they do not have the 'x' bit set, they won't be able to access the lower level directories or any files in them. Well, in this case, the higher directories being / and /home, I guess it can safely be assumed that they are +x for everybody :-). More serioulsy, I find that GNU info files about permissions are rather well done. info File permissions, assuming info is installed. -- Fred
Re: [arch-general] xscreensaver broken?
Le Mardi 6 à 19:46, Guus Snijders a écrit : Well, removing glib didn't make a difference, so i tried recompiling it (with yaourt -Sb xscreensaver). But alas, compiling ended with: galaxy.c: In function 'draw_galaxy': galaxy.c:462: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [galaxy.o] Error 1 make[1]: Leaving directory `/tmp/yaourt-tmp-ghs/abs-xscreensaver/src/xscreensaver-5.08/hacks' make: *** [default] Error 5 == ERROR: Build Failed. Aborting... Error: Makepkg was unable to build xscreensaver package. Well, a C source that make GCC segfaults is a sign of a bug in GCC rather than in the code, isn't it ? -- Fred
[arch-general] Dealing with Info documentation
Hello Archlinux, I like reading documentation in the Info format (especially when it is the prefered / only form of documentation). However, Archlinux decides to strip by default the Info documentation from its packages. I am not going to contest that decision, but I'd like to install Info docs. Now, what would be the good way to do it ? Installing mannually Info packages ? Patching and locally rebuilding the packages for which I want the documentation ? Creating a PKGBUILD that will install a bunch of docs ? It seems this is the way to go. But what will happen if Arch ever decides to include Info files, how are conflicting files going to be handled ? -- Fred
Re: [arch-general] Dealing with Info documentation
Hello, Alessio Bolognino [EMAIL PROTECTED] writes: I recall a recent thread in arch-dev-public about a new policy about info docs; I think devs decided to include info docs in the new packages, but I'm not 100% sure. After some manual searching, I found the following thread : [arch-dev-public] OMG info pages Aaron Griffin aaronmgriffin at gmail.com Tue Apr 22 13:05:12 EDT 2008 -- Fred
Re: [arch-general] Dealing with Info documentation
Hello, Oops, I accidently hit the send button... Sorry for the previous almost empty message. Alessio Bolognino [EMAIL PROTECTED] writes: I recall a recent thread in arch-dev-public about a new policy about info docs; I think devs decided to include info docs in the new packages, but I'm not 100% sure. After some manual searching, I found the following thread : [arch-dev-public] OMG info pages Aaron Griffin aaronmgriffin at gmail.com Tue Apr 22 13:05:12 EDT 2008 The conclusion seemed to be, indeed, to include info pages, but there wasn't a clear let's change the default. Well, the texinfo package (last updated on May 22nd) still doesn't include its own documentation. Ryan Sims suggested that I rebuilt packages in order to get the doc, is that really the way to go? -- Fred
