Re: [arch-general] ldconfig -> Aborted.
C Anthony Risinger wrote: > # ldconfig -v > ldconfig: Can't stat /usr/lib64: No such file or directory > /usr/lib/libfakeroot: >libfakeroot-0.so -> libfakeroot.so > /usr/lib/perl5/core_perl/CORE: >libperl.so -> libperl.so > /lib: > Aborted I think there's no harm in "mkdir /usr/lib64". To me this sounds as if the VM balloons out of memory. How much RAM is allocated to the VM's? clemens
Re: [arch-general] getaddrinfo
Myra Nelson wrote: > After some more searching, work, and this email from the libc help > list [ http://sourceware.org/ml/libc-help/2011-12/msg0.html > ] , I've attempted the code from Ulrich Dreppers page at > http://www.akkadia.org/drepper/userapi-ipv6.html . The newer version > of the code (on the right ) which is supposed to be protocol > independent returns getaddrinfo: Servname not supported for > ai_socktype, while the older version ( on the left ) seg faults. Also try another, more practical program (which works here): http://linux-hacks.blogspot.com/2008/04/default-address-selection-part-1.html> (linked from http://www.wtfm.org/ip6to4>) clemens
Re: [arch-general] Linking issue, glibc weirdness?
Allan McRae wrote: > On 10/12/11 07:29, Ionut Biru wrote: > >> On 12/09/2011 09:25 PM, Philipp wrote: >> >>> Hi there, I have linking issues with one of the programs I maintain >>> in AUR and I don't quite understand the issue. Here's the output: >>> >>> g++ -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu >>> -L/usr/X11R6/lib -o jmeters jmeters.o styles.o mainwin.o jclient.o >>> mkimage.o meterwin.o -lsndfile -lclxclient -lclthreads -ljack >>> -lpng -lXft -lX11 -lrt /usr/bin/ld: jmeters.o: undefined reference >>> to symbol 'pthread_mutex_trylock@@GLIBC_2.2.5' /usr/bin/ld: >>> note: 'pthread_mutex_trylock@@GLIBC_2.2.5' is defined in DSO >>> /lib/libpthread.so.0 so try adding it to the linker command line >>> /lib/libpthread.so.0: could not read symbols: Invalid operation >>> collect2: ld returned 1 exit status make: *** [jmeters] Error 1 >>> >>> The program is jmeters >>> (https://aur.archlinux.org/packages.php?ID=25711). >>> >>> It depends on clthreads >>> (https://aur.archlinux.org/packages.php?ID=3627) which handles the >>> threading stuff. >>> >>> I wonder where this problem comes from. Needles to say that it >>> worked fine in the past. Any ideas? >> >> sounds like you don't have a fully up to date toolchain > > Actually, it sounds like he does have a fully up-to-date toolchain: > http://fedoraproject.org/wiki/UnderstandingDSOLinkChange > > The output also gives the fix... >>> /usr/bin/ld: note: 'pthread_mutex_trylock@@GLIBC_2.2.5' is defined in >>> DSO /lib/libpthread.so.0 so try adding it to the linker command line I think you're both wrong 8-) The ld(8) output seems to indicate that libpthread is pulled in, but points to something else than a fully functioning library. $ ls -l /lib/libpthread* -rwxr-xr-x 1 root root 135326 Dec 2 19:28 /lib/libpthread-2.14.1.so lrwxrwxrwx 1 root root 20 Dec 2 19:28 /lib/libpthread.so.0 -> libpthread-2.14.1.so $ nm /lib/libpthread.so.0 |g mutex.try -:9f40 T __pthread_mutex_trylock -:9f40 T pthread_mutex_trylock Philipp, what's the output of these commands at your place? clemens
[arch-general] partition sizes and filesystems (Re: Install Arch in stages?)
Leonid Isaev wrote: > I think it's a better idea to have either /var/lib or entire /var on > reiserfs. > > /ext4 30Gb > /var ext4 10Gb > /bootext4 100Mb > /var/lib reiserfs 500Mb > /homeext4 85Gb > /tmp ext2 2Gb Interesting! Why do you think that? Me, I used my ears to determine the best filesystem for my workloads on the PC. Ext4 is the one with least head movement: the disks stay silent for long periods of time, then they have hectic fits and go quiet again. Compare this with freebsd's UFS2+soft-updates, XFS and JFS. I didn't dare to use ZFS on freebsd and I think I never tried reiserfs, fearing it isn't on active development currently. Oh, one other thing: my swap and home partitions are LUKS encrypted. The swap uses etc/crypttab with a random key, the key for home is on an USB dongle, so I can physically lock out people taking possession of the PC by keeping that dongle safely stashed away some place. clemens
Re: [arch-general] getaddrinfo
Myra Nelson wrote: > After some more searching, work, and this email from the libc help > list [ http://sourceware.org/ml/libc-help/2011-12/msg0.html > ] , I've attempted the code from Ulrich Dreppers page at > http://www.akkadia.org/drepper/userapi-ipv6.html . The newer version > of the code (on the right ) which is supposed to be protocol > independent returns getaddrinfo: Servname not supported for > ai_socktype, while the older version ( on the left ) seg faults. Read the manual page getaddrinfo(3). I presume the error in the newer version is: EAI_SERVICE The requested service is not available for the requested socket type. It may be available through another socket type. For example, this error could occur if service was "shell" (a service only available on stream sockets), and either hints.ai_protocol was IPPROTO_UDP, or hints.ai_socktype was SOCK_DGRAM; or the error could occur if service was not NULL, and hints.ai_socktype was SOCK_RAW (a socket type that does not support the concept of services). How did you run the program? If you use "http" instead of "echo", does it work with some www host? With the older version, did you perhaps forget some vital "&" or "*"? clemens
Re: [arch-general] getaddrinfo
Myra Nelson wrote: > I have a static ip address set up in rc.conf and my internet > connections work, ftp clients work, ip addrlabel produces > > prefix ::1/128 label 0 > prefix :::0.0.0.0/96 label 4 > prefix ::/96 label 3 > prefix 2001::/32 label 7 > prefix 2002::/16 label 2 > prefix fec0::/10 label 5 > prefix fc00::/7 label 6 > prefix ::/0 label 1 That's odd. I get: 0 6 # ip addrlabel prefix ::1/128 label 0 prefix ::/96 label 3 prefix :::0.0.0.0/96 label 4 prefix 2001::/32 label 6 prefix 2001:10::/28 label 7 prefix 2002::/16 label 2 prefix fc00::/7 label 5 prefix ::/0 label 1 You can see that the IP ranges have differing labels (classes). What _uncommented_ lines are in your etc/gai.conf? egrep -v '^#|^[[:space:]]*$' /etc/gai.conf The output of this command is empty on my machine. clemens
Re: [arch-general] Install Arch in stages?
Grant McDuling wrote: > Hi, I am new to Arch, being a Mint user until now. I have the iso on > CD now and ready to install. Can I do this is stages or is it best to > do the complete basic install in one sitting? Regarding disk partitioning: Arch wants to have /usr on the same partition as "/" (the root), as long as some programs needed around boot time reside on /usr. With my setup (which has no desktop environment), my disks would need (spacewise): / + /usr ext4 9G /opt ext4 9G /boot ext2 1G /var ext4 9G /rest ext4 77G /home ext4 9G with plenty of room left. The numbers don't add up to eg. 250GB because I keep several linux installations, one of which is a "hot spare" synced daily _before_ doing "pacman -Su" to upgrade the main system. What disk space do other people on this list need? clemens
Re: [arch-general] Deleting packages
Guillermo Leira wrote: > I'm not a programmer, so I can't submit code, but it would be nice if > pacman would say "Installed as a dependency of: package-name", or > something similar. It's just a suggestion. If a package is removed without its dependencies, those dependencies also lose the pointer to the package that once pulled them in. Note that this relation is not hardcoded, which makes sense: packages may depend on others with a lower bound on the version needed, but any version thereafter will do. Nonetheless storing the "original" package name+version could be done, maybe in an additional field to avoid the need of updating the "dep: name+version" field each time a new version is installed. > Hummm... I'm seeing some pacman -R options that can be very useful to > keep the system clean. Maybe I should have used it, and now I wouldn't > have these "orphan" packages in my disk. pacman -Rs $(pacman -Qtdq) The "s" means (from the man page): Remove each target specified including all of their dependencies, provided that (A) they are not required by other packages; and (B) they were not explicitly installed by the user. This operation is recursive and analogous to a backwards --sync operation, and helps keep a clean system without orphans. If you want to omit condition (B), pass this option twice. You can make this even more aggressive by using "pacman -Rcs". I used for i in $(pacman -Qtdq); do pacman -Rs $i;done because there are packages I want to keep. Without the for loop, pacman will remove the whole bunch, with it I get the confirmer question one by one. clemens
Re: [arch-general] provide with version
Christian Hesse wrote: > Hmm... Did not notice the typo as well... > I used the correct syntax automatically. Being a human can be bad and > good. :D Right. But people consulting mailinglists might not know all the ins and outs. Therefore writing precise statements and citing without cut&paste errors might - for somebody else unbeknownst to the writer(!) - be the difference between "Ah! works! Nice!" and "Oh well, this is like micro$oft/apple, gotta live with it afterall". And it is about taking risks: Do I get hurt by slipping on the bar of soap I myself dropped earlier, or do I hurt somebody else I do not even know or care about by driving drunk? People will call it an accident either way. clemens
Re: [arch-general] provide with version
Alex Ferrando wrote:
> Use provides(xz=5.0.0), more info on [1]
>
> [1]= https://wiki.archlinux.org/index.php/Pkgbuild#provides
Shouldn't this be "provides=('xz=5.0.0')"? Afterall, this is an array
variable? Or is there a bash function provides() of the same name?
clemens
Re: [arch-general] pacman/libalpm/libfetch do not honor TMPDIR
Tom Gundersen wrote:
> 2011/11/29 "Jérôme M. Berger" :
>
>> And if your machine only boots very rarely (because it runs
>> continuously or because you hibernate it instead of rebooting) then
>> your "temporary" folder is never cleaned up. The solution that makes
>> the most sense is to have /tmp on a disk and to use tmpwatch [1][2]
>> in a cron job to clean it up regularly.
>>
>> Jerome
>>
>> [1] http://fedorahosted.org/tmpwatch/
>> [2] http://aur.archlinux.org/packages.php?ID=23510
>
> You should also be able to use /usr/lib/initscripts/arch-tmpfiles,
> which is what we use at boot, and which should have a similar
> functionality to tmpwatch (if you are using systemd you'll get a
> similar functionality for free).
With tmpwatch one gets to choose files not accessed or modified for
a certain period, and it needs no config file. Arch-tmpfiles, OTOH,
would require such a thing.
Then again, a simple "find -atime + -exec /bin/rm
'{}' +" does about the same as tmpwatch.
clemens
Re: [arch-general] alsa start (Re: Fwd: udev events and /usr not mounted)
Myra Nelson wrote:
> Alsa is in my daemons array and starts. The problem is the udev
> rule to restore the volume levels fails as it is run before /usr
> is mounted. That's why I was asking about udev rules and why [
> /usr/bin/alsactl restore ] works from the console after I've
> booted. After reading through the initscripts, rc.d, and mkinitcpio
> code I think it may be possible to run:
>
> [
> run_hook sysinit_postmount
>
> udevam control --reload-rules
>
> run_hook single_end
> ]
>
> in rc.local.
The hooks don't work like this, rc.local might run too late.
You'd make a file eg. /etc/rc.d/functions.d/my-hooks.sh:
my_sysinit_postmount_udevadm()
{
udevadm control --reload-rules ||
echo "my_sysinit_postmount_udevadm: udevadm err $?"
return 0
}
add_hook sysinit_postmount my_sysinit_postmount_udevadm
Putting the file into etc/rc.d/functions.d/ will let the hooks system
see and source it, and add_hook() will put your function into the array
of functions to run at a specific point. The list of hooks is in
etc/rc.d/functions and a custom hook function is a regular shell
function. No special error handling or sandboxing is done on them, so
you want to make sure they don't block or kill the shell. This is why
I'd recommend to use the "|| ..." clause after some user command and to
return a zero at the end, though ATM neither seems strictly necessary.
It will make a hook funtion future proof, I presume.
clemens
Re: [arch-general] Automatic File Associations Alloting
Jayesh Badwaik wrote: > Yeah. I too have my personal stuff for that. I have a script actually > which uses a file and from that creates the default.list file which is > then used by anyone who cares to use it (Firefox, KDE etc). But I am > now tired of the custom stuff. I just wanted to explore. And XML > seemed quiet universal in the sense. > > And I have heard a lot but I still don't get it. Why is XML a beast? > I have read everything from every source where people have even given > point wise listings. But I am not able to appreciate anything. XML is > just a way of writing data, right? Instead of parsing text you parse > tags and their values. The only difference and advantage is that the > stuff is more human readable. I was talking from the viewpoint of the task you were trying to solve. You want a way to handle mimetype associations for file objects. There's not much info needed. XML is not the best format to parse without bloaty libs. If you want a script, a simpler (oneline) format might be more practical. It is also easier to have a simple format when you later need to write adapters in case you still want XML. Whatever. You still might consider using two or more databases if you want a hierarchy: user-choices -> program-choices -> system-choices. No need to merge into one database if the later choices are fallbacks. clemens
[arch-general] alsa start (Re: Fwd: udev events and /usr not mounted)
Myra Nelson wrote: > Currently I don't want to try to migrate /usr to /. / is only 4 GB and > /usr is 8+ GB and everything works to well so I'll just do a fresh > install later. Otherwise sudo /usr/bin/alsactl start works well. You could also put a line into etc/rc.local : /etc/rc.d/alsa start || echo "cannot '/etc/rc.d/alsa start': $?" clemens
Re: [arch-general] pacman/libalpm/libfetch do not honor TMPDIR
Myra Nelson wrote: > The .install files are contained in the package. I know. I wanted to know where they go before the entire package with all transactions is considered "done". The warning indicated that the first, preliminary extraction step went wrong. > Might I ask what you were compiling that threw the error? I was just doing a system update installing new binary packages. clemens
Re: [arch-general] Automatic File Associations Alloting
Jayesh Badwaik wrote:
> Now whenever a new package is installed. It will contain an XML file
> containing description of the mimetype in the same manner. When the
> package is installed, the file will be transferred to a folder. The
> main file which contains the descriptions of the mime type will be
> somewhere else. This folder will contain the mime files which have not
> yet been incorportated into the main file.
>
> Now, a program would run which will take this folder and the original
> file as the default arguments and then update the file types. If there
> is a conflict, especially if the priority of the application for the
> mime type is already taken, then there can be a ncurses based
> resolution window, letting window resolve the conflict (modeled on the
> file association selectors in Windows applications). The priority in
> the package files can be -1 if the file wants to go to the last
> priority if possible. (like the nice factor of the processes)
>
> But no one can occupy the priority zero. Suppose a user opens an app
> using open with command and then checks the box, then automatically an
> entry is created in the folder with priority zero and then it is
> updated. This way, automatic software will never trump the user set
> defaults under any circumstances and the conflict management would
> prevent the irritation at the file open time. I am sure people are
> more careful during install than they are during file opening.
>
> Now the final XML file is created. This file can be then modified into
> whatever is demanded by any DE etc etc. What do you think?
XML is such a nasty beast to handle, especially for such a simple
application. I'm using a custom lessopen command as a companion to
less(1). My lessopen keeps a simple textfile with one
mimetype/extension/open-helper per line. Each file is checked against
this "database" with "file -Lsbz --mime-type" or "file -Lsb
--mime-type". If a specific mimetype/extension/open-helper tuple cannot
be found, the user is queried for it.
In your case you want a unified database, because new programs may
suggest some entry. This requires merging and conflict resolution.
I wouldn't go this way, I'd just use two different databases, where the
user supplied one is checked first and a distribution one second (or
last, in case the searching stops here).
Database entries look like this (mimetype "_:_" extension ":::" helper):
application/vnd.ms-cab-compressed_:_CAB:::7z l
# an entry with a catchall (wildcard)
application/x-executable_:_*:::readelf -d "${FILE}"; strings -a <
If a filename contains several dots, the last few are taken to be the
extension unless a catchall entry exists. Using extensions for
additional differentiation lets one use different programs in special
cases. The variable "$FILE" can be used in case the helper wants a real
file, the "<" redirection operator lets the shell handle the readonly
case.
If lessopen isn't used by less, it can equally well be used for
interactive, even GUI programs.
I wrote the script because I was not at all satisfied with the official
version, which is very complicated, doesn't let me configure my own
programs and doesn't use a separate database, everything is needlessly
hardcoded. My version is simpler and more versatile.
clemens
Re: [arch-general] pacman/libalpm/libfetch do not honor TMPDIR
clemens fischer wrote: > Gaetan Bisson wrote: > >> If that's easy then it shouldn't be too hard for you to open a bug >> report on the tracker and submit a patch. > > Then what component does the actual extracting? Is it libfetch? That > would be an upstream moving target, because it comes from netbsd. Do > you guys accept patches against libfetch in this case? Seems libarchive is used to handle packages. pacman.git lib/libalpm/add.c::perform_extraction() is hard to understand. It should be the place the warning I cited came from. If that is the case, ENOSPC wasn't the cause of it. I don't understand two things: - where exactly are files extracted to? If they go to /, how would people use pacman when root is mounted ro (in the case of eg. /.INSTALL)? If I can freely determine where files go via archive_entry_set_pathname(), where's the problem in using the value of TMPDIR as a prefix and move the file into its final position when libalpm declares the transaction ok? - the file causing the warning was ".INSTALL". It contains upgrade/install scriptlets. How can a problem extracting an important file like this be considered a warning? clemens
Re: [arch-general] pacman/libalpm/libfetch do not honor TMPDIR
Leonid Isaev wrote: > On Fri, 25 Nov 2011 18:07:18 +0100 > Geert Hendrickx <...> wrote: > >> On Fri, Nov 25, 2011 at 10:55:55 -0600, Leonid Isaev wrote: >> >> > Actually, what is stupid is keeping /tmp in RAM. It is an important >> > dir, where you might have an valuable info in case of a system >> > crash. I could never understand the logic behind this choice. /tmp is important, yes, but it is for _temporary_ files. If they should be preserved across a system crash, use another directory for them! Haven't you ever wondered about /var/tmp and the like? >> Reducing disk i/o. > > I find this a very weak excuse, because the normal desktop operation > is not I/O bound, and the dafaults must be safest. If you compile a > lot/use a lot of DB stuff, just mount /tmp to RAM in fstab but this is > a special case. Well, I do a lot of compiles on my desktop system. I sencerely hope you accept this excuse. I consider pacman installs important enough to warrent the users choice as to where extracted temp files go. clemens
Re: [arch-general] pacman/libalpm/libfetch do not honor TMPDIR
Allan McRae wrote: > On 25/11/11 09:18, clemens fischer wrote: > >> would it be possible to let pacman, libalpm and libfetch honor the >> environment variable TMPDIR? > > File a bug report or at least post to the pacman-dev list. Then > relevant people might actually see your request. I'm not "relevant" enough to post to any dev lists. > But I do not get it... what is the point of having /tmp in RAM and > then setting TMPDIR elsewhere? This has been answered by Hector Martinez-Seara. Sometimes, there's not enough space in /tmp ... clemens
Re: [arch-general] pacman/libalpm/libfetch do not honor TMPDIR
Gaetan Bisson wrote: > If that's easy then it shouldn't be too hard for you to open a bug > report on the tracker and submit a patch. Then what component does the actual extracting? Is it libfetch? That would be an upstream moving target, because it comes from netbsd. Do you guys accept patches against libfetch in this case? clemens
[arch-general] pacman/libalpm/libfetch do not honor TMPDIR
Hi, would it be possible to let pacman, libalpm and libfetch honor the environment variable TMPDIR? I mean, this is stupid. Many people keep /tmp in RAM, on a tmpfs, and make it big enough, but not too big, as it takes away RAM when getting loaded. #define TMP_LOC "TMPDIR" #include /* getenv(3) */ #include /* strncat(3) */ td = getenv(TMP_LOC); /* cleanup for safety: td = cleanup(td); */ tmpdir = strncat(td, "/", 1); What can be so difficult about this? I got this pesty "warning: warning given when extracting .INSTALL (Write failed)" today, and when looking at pacman, libalpm and libfetch with strings(1), none of them seem to check TMPDIR! clemens
Re: [arch-general] Display issues with Linux 3.1
hollunder@... wrote: >> hollunder@..., Sat 2011-11-12 @ 22:42:57-0500: >> [1] https://bugs.freedesktop.org/show_bug.cgi?id=22674#c11 > > Thanks Taylor, > I still consider this a bug because this didn't happen for years but > seems to happen every time I boot since 3.1. > > Another workaround is to disable kms by booting with the nomodeset > option. > > Another new issue is that my mousepointer frequently > flickers/disappears and that xv video out in smplayer doesn't work > anymore, but both of those are with the nomodeset option, have yet to > test with kms enabled again. FWIW, KMS never worked for me (on a desktop, though). The board has a nvidia chipset. All the characters on the screen were displayed "giant mode", ie. I could see only the first few of them, but they were inches wide, with large pixels. So I had to append "nouveau.modeset=0" to the append line of the etc/lilo.conf. clemens
Re: [arch-general] /usr is not mounted. This is not supported.
Thomas Bächler wrote: > Your system has two versions of libc.so.6: A 32 bit and a 64 bit version > (/usr/lib32/libc.so.6 vs. /lib/libc.so.6), and your script cannot > distinguish them. Actually, using readelf, this is not so easy to solve: > > 1) A 64 bit binary always loads only 64 bit libraries, so the ELF class > of the library can help. > 2) The length of the address at the beginning of the line is 64 bit > here, not 32 bit. I used the ELF "Class:" line of "readelf -h". Missing-libs.sh works now. clemens
Re: [arch-general] SOLVED: udev-174-1 problem (Re: [arch-dev-public] [signoff] udev-174-1)
Auguste Pop wrote: > On Thu, Oct 27, 2011 at 4:24 PM, clemens fischer <...> wrote: > >> Yesterday I compiled the new 3.0.8 stable kernel, and the script also >> invoked mkinitcpio(8), which eventually puts the new udev-174 into >> the initramfs image. Thereafter the udev in the image and on the >> full system match, and my problem was gone 8-). > > have you tried manually run mkinitcpio? Yes, like I said: the builder script did that. I wonder why this has to be done, though. The initramfs runs udevd, and etc/rc.sysinit does, too, after switch_root. So I thought at least the latter invocation would find and execute my rule irrespective of the version used. clemens
Re: [arch-general] /usr is not mounted. This is not supported.
Karol Blazewicz wrote: > On Thu, Oct 27, 2011 at 9:18 PM, clemens fischer <...> wrote: > >> Mkinitcpio already seems to be smart enough: >> >> BINARIES="/usr/sbin/minilogd" >> >> in etc/mkinitcpio.conf should do the trick. > > Sorry if I'm terribly mixing things up, but isn't minilogd dead? > http://mailman.archlinux.org/pipermail/arch-projects/2011-October/001982.html Ok, so if bootlogd is superior to minilogd, and minilogd is buggy, why are both started right next to each other in etc/rc.sysinit? Anyway, I took out minilogd out of BINARIES. Bootlogd does better. clemens
Re: [arch-general] /usr is not mounted. This is not supported.
Thomas Bächler wrote:
> Am 27.10.2011 10:38, schrieb clemens fischer:
>
>> minilogd requires the following libs:
>>
>> -rwxr-xr-x 1 root root 11K Oct 18 18:34 /usr/sbin/minilogd lrwxrwxrwx
>> 1 root root 12 Sep 9 01:23 /usr/lib32/libc.so.6 -> libc-2.14.so
>> -rwxr-xr-x 1 root root 1.4M Sep 9 01:23 /usr/lib32/libc-2.14.so
>> /usr/lib32/libc.so.6: lrwxrwxrwx 1 root root 26 Sep 9 01:23
>> /lib/ld-linux.so.2 -> ../usr/lib32/ld-linux.so.2 -rwxr-xr-x 1 root
>> root 141K Sep 9 01:23 /usr/lib32/ld-2.14.so
>>
>> I don't know why it asks for libs out of usr/lib32, this output is
>> from (the recursive use of) readelf(1). This is on a 64bit PC.
>
> Where do you get that from?
>
> $ ldd /usr/sbin/minilogd
>linux-vdso.so.1 => (0x7fff09d0c000)
>libc.so.6 => /lib/libc.so.6 (0x7f9c3fc9b000)
>/lib/ld-linux-x86-64.so.2 (0x7f9c40022000)
> $ readelf -d /usr/sbin/minilogd | grep library
> 0x0001 (NEEDED) Shared library: [libc.so.6]
I'm really glad you asked! I have a script called "missing-libs.sh",
and quite a number of self compiled programs. Whenever pacman upgrades
my system, some libs required by my programs may vanish, so
"missing-libs.sh" is used to scan my entire
usr/local/{{s,}bin,lib,libexec} recursively to check that the programs
get to keep their dependencies. It uses "readelf -d" instead of ldd(1),
because the latter actually runs any binary, which I can't afford for
security reasons. Readelf prints a "NEEDED" entry for dependencies
besides other info, but (normally) without a path, so the script has an
init stage where all libs reported by "ldconfig -p" are cashed in an
array to have path info at hand. I have to do this, because some lib
may require further libs which have to be checked recursively.
$ readelf -d /usr/sbin/minilogd
Dynamic section at offset 0x1e50 contains 20 entries:
TagType Name/Value
0x0001 (NEEDED) Shared library: [libc.so.6]
...
$ readelf -d /lib/libc.so.6
Dynamic section at offset 0x159b40 contains 27 entries:
TagType Name/Value
0x0001 (NEEDED) Shared library: [ld-linux-x86-64.so.2]
...
"ld-linux-x86-64.so.2" had no entry "NEEDED", so my script stops there.
Now your question points out a bug: the first lib found is displayed,
and this may be a 32bit lib! I'll have to come up with a fix for that
that avoids ldd(1). My system was converted from 32 bit to 64 bit not
long ago, the script had been working for so long, it just didn't cross
my mind that the caching was at fault.
I just see that:
$ readelf -h /usr/sbin/minilogd
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
...
So I'll have to account for that "Class" attribute of binaries. Oh
well, I need to avoid ldd, so it has to be done. Hmm, unless I can
efficiently sandbox ldd, entire directories need to be scanned afterall
...
clemens
Re: [arch-general] /usr is not mounted. This is not supported.
clemens fischer wrote: > Dwight Schauer wrote: > >> My root= on my kernel boot line is using /dev/by-uuid/ so if the >> initramfs can find the root device, I'm sure it can find the /usr >> device from the rootfs /etc/fstab. >> >> I've not noticed any breakage on all my system's that have a seperate >> /usr, apart from the message doing boot. > > Don't you have a boot message saying "minilogd not found" or somesuch? > > $ which minilogd -> /usr/sbin/minilogd > > By the time /etc/rc.sysinit starts minilogd, /usr is not available, so > there's no minilogd and hence, no log of early boot messages. > > I'm thinking of solving this particular problem like this: > > minilogd requires the following libs: > > -rwxr-xr-x 1 root root 11K Oct 18 18:34 /usr/sbin/minilogd > lrwxrwxrwx 1 root root 12 Sep 9 01:23 /usr/lib32/libc.so.6 -> libc-2.14.so > -rwxr-xr-x 1 root root 1.4M Sep 9 01:23 /usr/lib32/libc-2.14.so > /usr/lib32/libc.so.6: > lrwxrwxrwx 1 root root 26 Sep 9 01:23 /lib/ld-linux.so.2 -> > ../usr/lib32/ld-linux.so.2 > -rwxr-xr-x 1 root root 141K Sep 9 01:23 /usr/lib32/ld-2.14.so > > I don't know why it asks for libs out of usr/lib32, this output is from > (the recursive use of) readelf(1). This is on a 64bit PC. > > So I could "mount -B / /mnt/root" and copy the needed file hierarchy to > /mnt/root/usr/. Mkinitcpio already seems to be smart enough: BINARIES="/usr/sbin/minilogd" in etc/mkinitcpio.conf should do the trick. clemens
Re: [arch-general] /usr is not mounted. This is not supported.
Tom Gundersen wrote: > On Wed, Oct 26, 2011 at 12:57 PM, clemens fischer <...> wrote: > >> Thomas Bächler wrote: >> >>> Am 25.10.2011 20:12, schrieb clemens fischer: >>> >>>>> Mounting /usr needs to go to the initramfs. It is possible to >>>>> implement a mount handler for this. At this stage, the by-label >>>>> symlinks exist already. >>>> >>>> AFAIU udevd(8) is responsible for setting up those symlinks. How >>>> can they exist _before_ udevd(8) is started? >>> >>> I'll let you go back and read everything again, what you are saying >>> makes no sense whatsoever, and I have no idea how to reply to it. >> >> Lucky you, I have a way to explain it: There are udev rules >> referencing stuff in /usr. If people mount /usr by-label or by-uuid, >> udev must have completed to setup those symlinks. Catch-22. > > If you want to understand this I suggest you look at the udev hook in > initramfs. There is no problem. I think I have to take back what I said about a catch-22. I didn't have a clear understanding about the switch over from the initramfs to the full system. Correct me if I'm wrong: 1. The initramfs provides what's necessary to run a full system. It loads the needed modules and lets udev install the systems devices. 2. See switch_root(8): "switch_root moves already mounted /proc, /dev and /sys to newroot and makes newroot the new root filesystem and starts init process." 3. The full system is made operational by eg. etc/rc.sysinit and friends. So indeed a carefully crafted "mount /usr" can rely on labels and uuids of filesystems to be available very early. clemens
Re: [arch-general] /usr is not mounted. This is not supported.
Dwight Schauer wrote: > My root= on my kernel boot line is using /dev/by-uuid/ so if the > initramfs can find the root device, I'm sure it can find the /usr > device from the rootfs /etc/fstab. > > I've not noticed any breakage on all my system's that have a seperate > /usr, apart from the message doing boot. Don't you have a boot message saying "minilogd not found" or somesuch? $ which minilogd -> /usr/sbin/minilogd By the time /etc/rc.sysinit starts minilogd, /usr is not available, so there's no minilogd and hence, no log of early boot messages. I'm thinking of solving this particular problem like this: minilogd requires the following libs: -rwxr-xr-x 1 root root 11K Oct 18 18:34 /usr/sbin/minilogd lrwxrwxrwx 1 root root 12 Sep 9 01:23 /usr/lib32/libc.so.6 -> libc-2.14.so -rwxr-xr-x 1 root root 1.4M Sep 9 01:23 /usr/lib32/libc-2.14.so /usr/lib32/libc.so.6: lrwxrwxrwx 1 root root 26 Sep 9 01:23 /lib/ld-linux.so.2 -> ../usr/lib32/ld-linux.so.2 -rwxr-xr-x 1 root root 141K Sep 9 01:23 /usr/lib32/ld-2.14.so I don't know why it asks for libs out of usr/lib32, this output is from (the recursive use of) readelf(1). This is on a 64bit PC. So I could "mount -B / /mnt/root" and copy the needed file hierarchy to /mnt/root/usr/. On the other hand, rc.sysinit also invokes /sbin/bootlogd, which leaves most of the interesting stuff in var/log/boot, so this would be an academic exercise ... clemens
[arch-general] SOLVED: udev-174-1 problem (Re: [arch-dev-public] [signoff] udev-174-1)
On Tue-2011/10/25-14:56 clemens fischer wrote: > My system broke with udev-174-1. I have rules renaming eth* according > to their MACs for consistency, guarding against dependency on > order-of-detection, plus rules to customize a wlan running on an USB > device. These rules didn't run. The initcpio (mkinitcpio(8)) on my homegrown initramfs image was udev-173, which didn't match the udev-174 in the "full" system. I didn't expect this, because I don't have any custom hooks or udev rules besides my "simple-atomatics" one, which is only one rule not interfering with anything else. The initramfs is all archlinux, so to speak. Yesterday I compiled the new 3.0.8 stable kernel, and the script also invoked mkinitcpio(8), which eventually puts the new udev-174 into the initramfs image. Thereafter the udev in the image and on the full system match, and my problem was gone 8-). clemens
Re: [arch-general] update
Cédric Girard wrote:
> On Wed, Oct 26, 2011 at 3:07 PM, clemens fischer wrote:
>
>> On Tue-2011/10/11-07:12 C Anthony Risinger wrote:
>>
>> > On Oct 10, 2011 7:41 PM, "Martin" <...> wrote:
>> >
>> >> [spanish] ... [/spanish]
>> >
>> > ... and then no one else can benefit or contribute to this
>> > out-of-band conversation?
>>
>
> Clemens, what's the link between the text you're quoting and your
> answer?
"... benefit or contribute ...": the thread had to do with slow
mirrors. So I mentioned rankmirrors (@ pacman).
> Mirror status provided by ArchLinux may be filtered by country. They
> have freshness status included thus making them more useful (if the
> fastest mirror has not been updated for a week it is not the best
> mirror to choose).
That is true. I didn't think of this. By the way: using
community/jshon it is possible to script something up with a more generic
tool, eg.
$ wget -q -O '/dl/linux-archlinux.org-mirrors.json' \
'https://www.archlinux.org/mirrors/status/json/'
$ for i in {0..555};do echo $(
jshon -e urls -e $i -e score -u -p -e country -u -p -e url -u \
< /dl/linux-archlinux.org-mirrors.json
) || break;done |
egrep -v '^(undef|null)' |
egrep '[[:space:]]Germany[[:space:]]' |
sort -k1,1n |
uniq |
head -n7
1.087776 Germany http://ftp5.gwdg.de/pub/linux/archlinux/
1.128424 Germany http://archlinux.limun.org/
1.206714 Germany http://mirror.devnu11.net/archlinux/
1.281882 Germany http://arch.mirrors.tuxdroid.org/
1.663009 Germany http://mirror.selfnet.de/archlinux/
1.714045 Germany http://mirrors.n-ix.net/archlinux/
1.893226 Germany ftp://arch.mirrors.tuxdroid.org/
I take it the object member "score" combines freshness.
clemens
Re: [arch-general] update
On Tue-2011/10/11-07:12 C Anthony Risinger wrote: > On Oct 10, 2011 7:41 PM, "Martin" <...> wrote: > >> [spanish] ... [/spanish] > > ... and then no one else can benefit or contribute to this out-of-band > conversation? Why yes! instead of "reflector", pacman's own "rankmirrors" script provides a speed ranking of mirrors _as seen from the ocal site_ instead of the archlinux json interface, which runs server-side and seems to favour japanese and american mirrors. eg. rankmirrors -t /etc/pacman.d/mirrorlist clemens
Re: [arch-general] /usr is not mounted. This is not supported.
Thomas Bächler wrote: > Am 25.10.2011 20:12, schrieb clemens fischer: > >>> Mounting /usr needs to go to the initramfs. It is possible to >>> implement a mount handler for this. At this stage, the by-label >>> symlinks exist already. >> >> AFAIU udevd(8) is responsible for setting up those symlinks. How can >> they exist _before_ udevd(8) is started? > > I'll let you go back and read everything again, what you are saying > makes no sense whatsoever, and I have no idea how to reply to it. Lucky you, I have a way to explain it: There are udev rules referencing stuff in /usr. If people mount /usr by-label or by-uuid, udev must have completed to setup those symlinks. Catch-22. clemens
Re: [arch-general] no ACPI estimate in powertop with latest kernels
On Tue-2011/10/11-13:06 Neal Haslam wrote: > @Tom > Thankyou for pointing out powertop2. It allows for more control than > the original powertop. The URL in the PKGBUILD is not correct because > of kernel.org's changes. Googling for a new location was easy enough. If it was so easy, what was so difficult about posting the link here? clemens
Re: [arch-general] [arch-dev-public] [signoff] udev-174-1
Tom Gundersen wrote:
> On Tue, Oct 25, 2011 at 2:56 PM, clemens fischer <...> wrote:
>
>> My system broke with udev-174-1. I have rules renaming eth*
>> according to their MACs for consistency, guarding against dependency
>> on order-of-detection, plus rules to customize a wlan running on an
>> USB device. These rules didn't run.
>
> Could you have a look in your logs (dmesg in particular) for any
> messages? Make sure that logging is turned on in /etc/udev.conf. If a
> rule does not work, a warning/error should be printed to dmesg.
Nothing wrong with any rules (sigh).
>> Basically, there is one rule file[1] calling out to a number of local
>> "simple" rules. These in turn are very short, containing only
>> (LOCAL_) "RUN"/"NAME" commands. The main rule assembles a name out
>> of subsystem, addresses, interfaces etc. This name points into
>> a separate directory "/etc/udev-local" where the appropriate one- or
>> two liners live, and there's a logging rule telling me what file
>> names to use if there's anything missing. All this is less complex
>> than eg. udisks and relies only on udevd.
>
> I can't see what is wrong off-hand, so please file a bug report about
> this so it is not forgotten. (I didn't figure out how your rules are
> supposed to work, so there might be something obvious that
> I missed...).
Example:
# /etc/udev-local/99-local-simple-net-00:11:22:33:44:55-add
# _date: 20091003-2228_
LOCAL_NAME=nicX
LOCAL_OPT_last_rule=yes
My rule file sees an "add" event for the "net" device with MAC
"00:11:22:33:44:55" and calls up the short thing above.
Another one:
# /etc/udev-local/99-local-simple-net-00:1f:1f:55:99:33-add
# _date: 20100520-0032_
#
#LOCAL_RUN="/bin/sh -c '{ /usr/bin/env; echo 00-done; } >> /tmp/netif.txt'"
LOCAL_RUN="/root/bin/wlan-dev.sh add"
The script wlan-dev.sh does the setup for an adhoc wlan (that USB thing
cannot be used as a WPA2 AP).
-or-
# /etc/udev-local/99-local-simple-block-partition-vfat-7000-F3A3-add
# _date: 20100104-1948_
LOCAL_RUN=/bin/mount -t vfat -o defaults,nodev,noexec
/dev/disk/by-uuid/7000-F3A3 /home/ino/Desktop/usb-stick-7000-F3A3
# /etc/udev-local/99-local-simple-block-partition-vfat-7000-F3A3-remove
# _date: 20100104-1950_
LOCAL_RUN=/bin/umount -v /home/ino/Desktop/usb-stick-7000-F3A3
As mentioned, no dependencies other than udevd(8) to get all sorts of
automatix without ever touching udev-rules. This was way easier to
setup and use then any of the chubby gimmix like ifplugd(8), udisks(1)
etc.
Of course the magic lies in the file names in etc/udev-local/, so the
main rule file gives a warning mentioning the precise file name it
cooked up to find it.
>> Are rules in /etc/udev ever called in the new version?
>
> Yes, /etc/udev/rules.d/ are called and take precedence over
> /lib/udev/rules.d/ as always.
Stupid me, the udev log tells whenever any rule files are touched, so
I could have seen this myself.
clemens
Re: [arch-general] /usr is not mounted. This is not supported.
Tom Gundersen wrote: > On Tue, Oct 25, 2011 at 2:12 PM, clemens fischer ... wrote: (Removed email. No need to atract spammers!) >> What patch would that be? THE-FAVOURITE-SEARCH-ENGINE didn't pull >> anything useful for "patch Thomas-Bächler busybox". Can somebody point >> us to the relevant code, please? > > Thomas is right, that is not strictly speaking needed (but see below). > >> A hook to mount the users /usr would presumably go right before >> >> "if [ -x /lib/udev/udevd ]; then" >> >> in "/lib/initcpio/init"? > > This is what I had in mind: > <https://github.com/teg/mkinitcpio/commit/76dacf8b9de9cc0409741840b1d8e449862fc846>. But what is this? 10 +In order for this to work, /usr needs to be in your /etc/fstab and it 11 +should be marked for not being fsck'ed (the last option should be 0). This is getting weird. Who/what is going to fsck(8) /usr then? > To make it work nicely, we should also add the dual logic to shutdown: > <https://github.com/teg/mkinitcpio/commit/42610beb5a317d63dc76dabb72a9061a799b280b>, > which will pivot back to the initramfs and unmount /usr cleanly. This > is where we need some busybox work, and I guess this patch should be > discussed a bit more, maybe it is not the best way to do it. Pardon me, but I'm not sure I want to keep all of the initramfs around after regular operation of the system commences. >> Are the symlinks in "/dev/disk/by-label/" by then? I guess not, since >> udevd rules are responsible for setting them up, right? I object to prohibit the use of LABEL/UUID to identify /usr (or any other fs for that matter) if that's what all this boils down to. I keep a backup and a rescue system around, with some filesystems shared between them. Sometimes I shuffle them around, eg. for testing alternatives like btrfs etc. For consistently identifying them they get labels, and I'm sure other people rely on labels as well. >> So how do the boot-loaders do this? My first thought was to have >> a kernel command line parameter >> "mnt_usr_from=/dev/disk/by-label/my-usr" or whatever and then use >> busybox' ``mount "$mnt_usr_from" /usr''. >> >> I do find it annoying to have /usr with all the bulky GUI crap, >> audio-tools and whatnot in "/". FreeBSD has a clean separation >> between what's needed to bring up, build and run a basic system ( -> >> /usr ) and user-toys, including all the GUI and multimedia stuff ( -> >> /usr/local ). >> >> I always regret linux cramming everything into /usr. Some vital >> programs needed at startup are in /[s]bin, some in /lib, but look at >> the rules in /lib/udev/rules.d/: while vboxdrv and alsa-restore could >> equally well run when /usr is finally up, the device-mapper rules >> check for dmsetup residing in usr/sbin, although they are needed >> early! > > It is currently a mess. I agree with the people advocating putting > everything in /usr (and symlink /bin, /sbin and /lib for > compatibility). That obviously requires being able to mount /usr from > initramfs. ... which is more complicated than I thought. We should agree on a clean future-proof concept. clemens
Re: [arch-general] /usr is not mounted. This is not supported.
Thomas Bächler wrote: > Am 25.10.2011 14:12, schrieb clemens fischer: >>> We are currently working on adding support for the second approach, >>> but we are not there yet (I have some patches against mkinitcpio to >>> add this, but they rely on a patch by Thomas against busybox that has >>> not yet landed upstream). >> >> What patch would that be? THE-FAVOURITE-SEARCH-ENGINE didn't pull >> anything useful for "patch Thomas-Bächler busybox". Can somebody point >> us to the relevant code, please? > > I am not sure which patch he means. I wrote something recently, but I > only shared that with Tom in private conversations and it is not related > to this issue. > >> A hook to mount the users /usr would presumably go right before >> >> "if [ -x /lib/udev/udevd ]; then" >> >> in "/lib/initcpio/init"? >> >> Are the symlinks in "/dev/disk/by-label/" by then? I guess not, since >> udevd rules are responsible for setting them up, right? > > Mounting /usr needs to go to the initramfs. It is possible to implement > a mount handler for this. At this stage, the by-label symlinks exist > already. AFAIU udevd(8) is responsible for setting up those symlinks. How can they exist _before_ udevd(8) is started? clemens
Re: [arch-general] [arch-dev-public] [signoff] udev-174-1
'uname -rms' -> "Linux 3.0.7-spott x86_64"
On Thu-2011/10/20-09:41 Myra Nelson wrote:
> Error messages yes, but no warning about problems with the image and
> the image is created and boots fine. Keeping up with the mailing list
> makes all the difference in the world.
My system broke with udev-174-1. I have rules renaming eth* according
to their MACs for consistency, guarding against dependency on
order-of-detection, plus rules to customize a wlan running on an USB
device. These rules didn't run.
Basically, there is one rule file[1] calling out to a number of local
"simple" rules. These in turn are very short, containing only (LOCAL_)
"RUN"/"NAME" commands. The main rule assembles a name out of subsystem,
addresses, interfaces etc. This name points into a separate directory
"/etc/udev-local" where the appropriate one- or two liners live, and
there's a logging rule telling me what file names to use if there's
anything missing. All this is less complex than eg. udisks and relies
only on udevd. Are rules in /etc/udev ever called in the new version?
Do I need some compatibility to make this happen?
I didn't have the old udev package to downgrade to, but a backup from
where the old binaries and lib/udev stuff could be restored. Otherwise
I couldn't even post this.
clemens
[1] /etc/udev/rules.d/99-local-simple.rules
# /root/udev-rules/99-local-simple.rules
# == /etc/udev/rules.d/99-local-simple.rules
# _date: 20091002-1615_
# see
ENV{iam} = "99-local-simple"
ENV{LOCAL_LOGG} = "/usr/bin/logger -p daemon.info --"
ACTION == "add", ENV{.cmd} = "add", GOTO = "local_simple_check_subsys"
ACTION == "change", ENV{.cmd} = "change", GOTO = "local_simple_check_subsys"
ACTION == "remove", ENV{.cmd} = "remove", GOTO = "local_simple_check_subsys"
GOTO = "local_simple_end"
LABEL = "local_simple_check_subsys"
SUBSYSTEM == "block", ENV{DEVTYPE} == "partition", GOTO =
"local_collect_disk_args"
SUBSYSTEM == "bluetooth", ENV{.subsystem} = "bluetooth", GOTO =
"local_collect_if_args"
SUBSYSTEM == "net", ENV{.subsystem} = "net", GOTO = "local_collect_if_args"
SUBSYSTEM == "rfkill", ENV{.subsystem} = "rfkill", GOTO =
"local_collect_if_args"
GOTO = "local_simple_end"
LABEL = "local_collect_disk_args"
# should anybody have setup site specific values, get them
IMPORT{parent} = "SPOTT_*"
#IMPORT{parent} = "PCI_*"
#IMPORT{parent} = "HID_*"
IMPORT{parent} = "ID_*"
ENV{.devtype} = "partition"
ENV{.subsystem} = "block"
ENV{ID_FS_TYPE} == "", ENV{LOCAL_EX} = "no filesystem", GOTO =
"local_simple_exerr"
ENV{ID_FS_UUID} == "", ENV{ID_FS_LABEL} == "", ENV{LOCAL_EX} = "neither label
nor uuid", GOTO = "local_simple_exerr"
ENV{ID_FS_UUID} == "?*", ENV{.fs} = "$env{ID_FS_TYPE}-$env{ID_FS_UUID}"
ENV{ID_FS_LABEL} == "?*", ENV{.fs} = "$env{ID_FS_TYPE}-$env{ID_FS_LABEL}"
ENV{.devid} = "$env{.devtype}-$env{.fs}"
ENV{LOCAL_EX} = "$env{.cmd} $env{.subsystem} $env{.devid}"
ENV{LOCAL_LOGG} == "?*", RUN += "$env{LOCAL_LOGG} $env{iam}: msg:
$env{LOCAL_EX}"
GOTO = "local_get_controls"
LABEL = "local_collect_if_args"
# should anybody have setup site specific values, get them
IMPORT{parent} = "SPOTT_*"
#IMPORT{parent} = "PCI_*"
#IMPORT{parent} = "HID_*"
IMPORT{parent} = "ID_*"
ENV{.devtype} = "unknown"
ATTR{address} == "?*", ENV{.devtype} = "$attr{address}"
ENV{.devtype} == "unknown", ATTR{name} == "?*", ENV{.devtype} = "$attr{name}"
#ENV{.devtype} == "unknown", ENV{PRODUCT} == "?*", ENV{.devtype} =
"$env{PRODUCT}"
ENV{.devtype} == "unknown", ENV{.devtype} = "$kernel"
ENV{.devid} = "$env{.devtype}"
ENV{LOCAL_EX} = "$env{.cmd} $env{.subsystem} $env{.devid}"
ENV{LOCAL_LOGG} == "?*", RUN += "$env{LOCAL_LOGG} $env{iam}: msg:
$env{LOCAL_EX}"
#GOTO = "local_get_controls"
LABEL = "local_get_controls"
# to make all this configurable, either an external program or the
# "test-trick" is necessary, because the "==" operator can only match on
# literals!
ENV{LOCAL_DEV} =
"/etc/udev-local/$env{iam}-$env{.subsystem}-$env{.devid}-$env{.cmd}"
TEST != "$env{LOCAL_DEV}", ENV{LOCAL_EX} = "no $env{LOCAL_DEV}", GOTO =
"local_simple_exerr"
IMPORT = "$env{LOCAL_DEV}"
ENV{LOCAL_LOGG} == "?*", RUN += "$env{LOCAL_LOGG} LOCAL_DEV:$env{LOCAL_DEV}
LOCAL_RUN:$env{LOCAL_RUN}"
ENV{LOCAL_OPT_last_rule} == "?*", GOTO = "local_simple_lastrule"
ENV{LOCAL_GROUP} == "?*", GROUP = "$env{LOCAL_GROUP}"
ENV{LOCAL_MODE} == "?*", MODE = "$env{LOCAL_MODE}"
ENV{LOCAL_NAME} == "?*", NAME = "$env{LOCAL_NAME}"
ENV{LOCAL_OWNER} == "?*", OWNER = "$env{LOCAL_OWNER}"
ENV{LOCAL_PROGRAM} == "?*", PROGRAM = "$env{LOCAL_PROGRAM}", ENV{.result} = "%c"
ENV{LOCAL_LOGG} == "?*", ENV{.result} == "?*", RUN += "$env{LOCAL_LOGG}
LOCAL_DEV:$env{LOCAL_DEV} RESULT:$env{.result}"
ENV{LOCAL_RUN} == "?*", RUN += "$env{LOCAL_RUN}"
ENV{LOCAL_SYMLINK} == "?*", SYMLINK += "$env{LOCAL_SYMLINK}"
GOTO = "local_simple_end"
LABEL = "local_simple_lastrule"
ENV{LOCAL_GROUP} == "?*", GROUP = "$env{LOCAL_GROUP}", OPTIONS="last_rule"
ENV{LOCAL_MODE} == "?*", MODE = "$env{LOCAL_MODE}", OPTIONS="last_rule"
ENV{LOC
Re: [arch-general] /usr is not mounted. This is not supported.
Thomas Bächler wrote: > No. Even if things fail entirely, we will provide a hook for > mkinitcpio that mounts /usr before switching to the real root > filesystem. This will eliminate all your potential bugs. However > - this hook hasn't been written yet. Imagine somebody with a desktop arch-linux. For some reason his system "fails entirely". Should he or she now mess with a live-CD to backport the yet unwritten hook once it is finished and doodle on his thumbs waiting for it? Reinstall everything? clemens
Re: [arch-general] /usr is not mounted. This is not supported.
Tom Gundersen wrote: > From time to time we get bug reports that are really difficult to > debug, and that eventually turn out to be due to a separate /usr. Once > we figure out the cause, we usually end up having to say, sorry, there > is nothing we can do about that, but in the meantime we have wasted a > lot of time. Therefore, we really want to get the message out there > that at the moment things simply don't work as they should with a > separate /usr. Then people will at least know that this is a likely > cause of any weird problems they experience. > > There are two ways to solve this: either merge your / and your /usr > partitions, or make your initramfs mount /usr so init won't even know > that /usr is separate. > > We are currently working on adding support for the second approach, > but we are not there yet (I have some patches against mkinitcpio to > add this, but they rely on a patch by Thomas against busybox that has > not yet landed upstream). What patch would that be? THE-FAVOURITE-SEARCH-ENGINE didn't pull anything useful for "patch Thomas-Bächler busybox". Can somebody point us to the relevant code, please? A hook to mount the users /usr would presumably go right before "if [ -x /lib/udev/udevd ]; then" in "/lib/initcpio/init"? Are the symlinks in "/dev/disk/by-label/" by then? I guess not, since udevd rules are responsible for setting them up, right? So how do the boot-loaders do this? My first thought was to have a kernel command line parameter "mnt_usr_from=/dev/disk/by-label/my-usr" or whatever and then use busybox' ``mount "$mnt_usr_from" /usr''. I do find it annoying to have /usr with all the bulky GUI crap, audio-tools and whatnot in "/". FreeBSD has a clean separation between what's needed to bring up, build and run a basic system ( -> /usr ) and user-toys, including all the GUI and multimedia stuff ( -> /usr/local ). I always regret linux cramming everything into /usr. Some vital programs needed at startup are in /[s]bin, some in /lib, but look at the rules in /lib/udev/rules.d/: while vboxdrv and alsa-restore could equally well run when /usr is finally up, the device-mapper rules check for dmsetup residing in usr/sbin, although they are needed early! clemens
[arch-general] (linux-stable.git) Re: netcfg wlan connection renewal
On Wed-2011/10/12-23:55 Philipp Überbacher wrote: > Excerpts from scrat's message of 2011-10-12 22:44:14 +0200: >> The problem is I can't get the firmware for the new driver because >> git.kernel.org is down so I am unable to test. :( > > It's up for me :) You might try[1]. It should have the stable releases and is updated whenever a new stable comes out. [1] git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git clemens
[arch-general] maintainer keyring (Re: [arch-dev-public] Pacman 4.0.0 RC1 "release")
On Mon-2011/08/22-00:40 Allan McRae wrote: > On 22/08/11 03:10, Myra Nelson wrote: > >> Works like a charm. Thanks again for the assistance. I missed #GPGDir >> = /etc/pacman.d/gnupg/ in the new pacman.conf file or I would have >> investigated further. I only had one other problem, importing Andreas >> Radke's key. I get a key not found error both when I click the >> link on the developers page and when I try to import the key with >> pacman-key. > > You can get it from: > https://wiki.archlinux.org/index.php/DeveloperWiki:Signing_Packages/Packager_Keys Could the dev's and package maintainer keys be put into a (signed) keyring, please? Much easier to handle than downloading and "gpg --import"ing them one by one. clemens
Re: [arch-general] no desktop: howto change default browser?
Mantas M. wrote: > On Sun, Sep 11, 2011 at 08:26:53PM +0200, clemens fischer wrote: > >> I have used "gconf-editor", added the directory chain > > Very few programs still use the GConf settings. Most follow the XDG > configuration at ~/.local/share/applications/mimeapps.list: > >[Default Applications] >x-scheme-handler/http=firefox.desktop >x-scheme-handler/https=firefox.desktop >text/html=firefox.desktop > > The "x-scheme-handler/*" entries are for "http:" and "https:" URLs > respectively, and "text/html" is for opening local HTML files. Bingo-Bongi! You get to wear the masters hat and here's the cookie O! clemens
Re: [arch-general] no desktop: howto change default browser?
F.Gr. wrote: > Uli Armbruster [2011-09-11T21:50 CEST]: > >> Put >> >> export BROWSER=your_browser >> >> into your bashrc, zshrc or into a file you put into /etc/profile.d, >> depending on what you want. > > some application (in my case e.g. google earth) doesn't work > correctly by putting BROWSER variable into ~/.zshrc. I've solved by > putting the following into ~/.xprofile: > > BROWSER='/usr/bin/firefox' > export BROWSER That's odd. I tried "env BROWSER=firefox evince ", but evince would continue to use epiphany. But thanks for the hint! I wonder why the "$BROWSER standard" isn't honoured by evince. clemens
[arch-general] no desktop: howto change default browser?
Hi,
when using eg. "evince" to view a PDF document, links open in
"epiphany", which seems to be a gnome default browser.
I need to change this, but all the links the comes up
with hint at using menus like "system -> ... -> browser". I only run
a window-manager, no desktop, so there's no such thing as a "system"
menu entry.
I have used "gconf-editor", added the directory chain
"~/.gconf/desktop/gnome/url-handlers/{http,https}" with keys "command"
-> 'firefox "%s"', "enabled" -> ticked, "needs_terminal" -> not-ticked,
but these settings don't help.
Does somebody know how to change the setting for default-browser when no
desktop is used?
clemens
Re: [arch-general] Something Broken with Perl!
clemens fischer wrote: > % urxvt > urxvt: symbol lookup error: > /usr/lib/perl5/site_perl/auto/List/Util/Util.so: undefined > symbol: Perl_Istack_sp_ptr > > I moved Util.so elsewhere and urxvt started working again. > > But: > > # cpanp > Data::Dumper object version 2.130_02 does not match > $Data::Dumper::VERSION 2.126 at /usr/lib/perl5/core_perl/DynaLoader.pm line > 213. > Compilation failed in require at /usr/share/perl5/core_perl/Params/Check.pm > line 8. > BEGIN failed--compilation aborted at > /usr/share/perl5/core_perl/Params/Check.pm line 8. > Compilation failed in require at /usr/share/perl5/core_perl/Log/Message.pm > line 5. > BEGIN failed--compilation aborted at > /usr/share/perl5/core_perl/Log/Message.pm line 5. > Compilation failed in require at > /usr/share/perl5/core_perl/CPANPLUS/Error.pm line 5. > BEGIN failed--compilation aborted at > /usr/share/perl5/core_perl/CPANPLUS/Error.pm line 5. > Compilation failed in require at /usr/share/perl5/core_perl/CPANPLUS.pm line > 6. > BEGIN failed--compilation aborted at /usr/share/perl5/core_perl/CPANPLUS.pm > line 6. > Compilation failed in require at /usr/bin/core_perl/cpanp line 11. > BEGIN failed--compilation aborted at /usr/bin/core_perl/cpanp line 11. > > out of curiosity, I did: > > # mmv /usr/lib/perl5/core_perl/ /usr/lib/perl5/core_perl-old > `/usr/lib/perl5/core_perl/' -> `/usr/lib/perl5/core_perl-old' > ~ > 0 3 # cpanp > /usr/bin/perl: error while loading shared libraries: libperl.so: > cannot open shared object file: No such file or directory > ~ > # locate -i libperl.so > (no output) > ~ > # find /usr/bin/core_perl/ -type f ( -name *libperl* ) > (no output) thanks for looking into this. I had to rename /usr/lib/perl5/site_perl (to /usr/lib/perl5/site_perl-old) to make things like automake and cpanplus work again. clemens
Re: [arch-general] Something Broken with Perl!
John K Pate wrote: > I had a breakage (with the same error message) with > rxvt-unicode-chinese from the AUR, but it was resolved upon upgrading > to the new version. I don't know if the fix was due to recompiling or > the new version, however. Note that I don't have any foreign, ie. non ARCH perl packages. (line breaks by me) % urxvt urxvt: symbol lookup error: /usr/lib/perl5/site_perl/auto/List/Util/Util.so: undefined symbol: Perl_Istack_sp_ptr I moved Util.so elsewhere and urxvt started working again. But: # cpanp Data::Dumper object version 2.130_02 does not match $Data::Dumper::VERSION 2.126 at /usr/lib/perl5/core_perl/DynaLoader.pm line 213. Compilation failed in require at /usr/share/perl5/core_perl/Params/Check.pm line 8. BEGIN failed--compilation aborted at /usr/share/perl5/core_perl/Params/Check.pm line 8. Compilation failed in require at /usr/share/perl5/core_perl/Log/Message.pm line 5. BEGIN failed--compilation aborted at /usr/share/perl5/core_perl/Log/Message.pm line 5. Compilation failed in require at /usr/share/perl5/core_perl/CPANPLUS/Error.pm line 5. BEGIN failed--compilation aborted at /usr/share/perl5/core_perl/CPANPLUS/Error.pm line 5. Compilation failed in require at /usr/share/perl5/core_perl/CPANPLUS.pm line 6. BEGIN failed--compilation aborted at /usr/share/perl5/core_perl/CPANPLUS.pm line 6. Compilation failed in require at /usr/bin/core_perl/cpanp line 11. BEGIN failed--compilation aborted at /usr/bin/core_perl/cpanp line 11. out of curiosity, I did: # mmv /usr/lib/perl5/core_perl/ /usr/lib/perl5/core_perl-old `/usr/lib/perl5/core_perl/' -> `/usr/lib/perl5/core_perl-old' ~ 0 3 # cpanp /usr/bin/perl: error while loading shared libraries: libperl.so: cannot open shared object file: No such file or directory ~ # locate -i libperl.so (no output) ~ # find /usr/bin/core_perl/ -type f ( -name *libperl* ) (no output) clemens
Re: [arch-general] A suggestion for the devs regarding rebuilds
Nathan Wayde wrote: > On 10/03/10 20:03, clemens fischer wrote: > >> Ironically, if pacman was such a tidy package manager and devs were >> so keen to keep things that way, why is there ever any output in >> "pacman -Qdt"? > > Could it be because you explicitly requested that? i.e `pacman -R > pkgname` which removes that pkg and that pkg only, see `pacman -Rh`. I always use "pacman -Rs". It's a wrapper script, I normally don't use a bare "pacman", so there's not even neglect at play. clemens
Re: [arch-general] A suggestion for the devs regarding rebuilds
f...@... wrote: > But then doing a full system upgrade (as advised on this list) > completely locked up the machine - frozen screen, dead capslock led > etc. No other choice but a power cycle, broken filesystems, and hours > of work repairing them and putting bits and pieces back in place. > I still have a about 700 files in lost+found, most of them seem *.pyc > and man pages, so probably no big losses. "lost+found" is a filesystem thing: it's the place where files are put that cannot be linked up eg. in the fsck phase. Other than that: if you need old libs or headers, you will have to save them some place, the arch goods will not help you with this. Ironically, if pacman was such a tidy package manager and devs were so keen to keep things that way, why is there ever any output in "pacman -Qdt"? clemens
Re: [arch-general] CDROM cannot mount
On Mon-2010/02/01-11:26 Thanos Zygouris wrote: > P.S.1 : Most of the CDs are bootable ones, writen with "cdrecord -v > speed=8 dev=/dev/scd0 -data -tao -multi". They boot normally though. I thought multi-session CDs must be "finished" or "finalized" before they can be fully used? clemens
Re: [arch-general] pacman.conf: can I use wildcards?
Attila wrote: > At Donnerstag, 18. Februar 2010 02:13 Dan McGee wrote: > >> No, we don't support globbing in these options. Question to the list- >> does it make sense to do so? > > Instead this makes something easier i must say that this could be > dangerous too because it could end in some strange questions in the > support area. Not likely. Files named like something/other*, with the star being a literal instead of a glob are very, very rare. On the contrary, people have provided good examples where wildcards are useful. > Perhaps it could helps if you makes it possible to use a include file > for this because than appending a file in this file is easier as to > edit pacman.conf. This "harder way" for NoUpgrade has the advantage > that you even know which file is the reason why you edit it because > sometimes i don't know weeks or months later what i have done ... but > this be more my self-critical 2c.-) That's what comments are for. Remember the '#' hash mark? clemens
[arch-general] pacman.conf: can I use wildcards?
I could not find any decisive answer in either the man page or on the web. Here's my question: in etc/pacman.conf, can I use entries such as: NoExtract = usr/share/man/man1/mkisofs* NoExtract = etc/logrotate.d/* or: NoUpgrade = etc/cron.daily/logrotate etc/logrotate.* clemens
Re: [arch-general] Pacman Error: upgrading to same package version?again & again
Gaurish Sharma wrote:
> On Tuesday 16 Feb 2010 6:31:52 pm Nagy Gabor wrote:
>
>> Check /var/lib/pacman/local/, you will probably find many duplicated
>> entries there. Then you should manually remove the older entries.
>>
>> (This is probably caused by backup or buggy third party scripts. Next
>> major pacman release will catch duplicated database entries and warn
>> the user.)
>
> Hi, you are right, there were duplicated entries(which I removed). I
> think which were caused while taking backups via rsync. I wonder, how
> could I advoid such problems in future.
I've got this little script:
#
#! /bin/bash
# /root/bin/arch-linux-local-dup-packages.sh _date: 20100217-2244_
iam="${0##*/}"
match="${1}"
ex=0
declare -A pkg_local
pkg_local_dir="/var/lib/pacman/local"
pkg=""
_pkg=""
pkg_name=""
pkg_entry=""
for pkg in "${pkg_local_dir}"/*
do
_pkg="${pkg##*/}"
pkg_name="${_pkg%-*-*}"
pkg_entry=${pkg_local["${pkg_name}"]}
[ -z "${pkg_entry}" ] && {
pkg_local["${pkg_name}"]="${_pkg}"
:
} || {
pkg_local["${pkg_name}"]="${pkg_entry} ${_pkg}"
echo "${iam}: duplicate: ${pkg_local[${pkg_name}]}"
((ex++))
:
}
done
shopt -s extglob
[ -n "${match}" ] &&
for pkg in "${!pkg_loc...@]}"
do
pkg_entry=${pkg_local["${pkg}"]}
[ -z "${pkg}" ] && {
echo "${iam}: zero entry: ${pkg} -> ${pkg_entry}"
((ex++))
continue
}
case "${pkg}" in
${match})
echo "${iam}: match: ${pkg} -> ${pkg_entry}"
;;
esac
case "${pkg_entry}" in
${match})
echo "${iam}: match: ${pkg} <- ${pkg_entry}"
;;
esac
done
exit ${ex}
#
clemens
[arch-general] howto trace userland startup
It may so happen that one wants to know what's wrong with some
configuration, but it is handled at boot time and the initscripts don't
provide enough info. An alternative is to use the hook functions
scattered about the initscripts, which may or may not be better for your
needs.
This is my trick to have certain scripts set to bash's trace mode and
leave output in a file. It needs one configuration line in etc/rc.conf
and a file in etc/rc.d/functions.d/:
Example:
# /etc/rc.conf - Main Configuration for Arch Linux
...
only_info_pls="*@(/network|/iptables)*:::/root/system/boot/questions/!0-!1-!2.txt"
...
This will "trigger" when the name of the script executed matches either
*/network* or */iptables*, set them to trace mode "-x" and collect their
output in files named after the script's name, with "/" replaced by ":".
Each of "!0", "!1" .. "!5" undergo this substitution. I get the
following files:
$ ls -l /root/system/boot/questions/
total 32K
-rw-r--r-- 1 root root 1235 Feb 17 20:38 :etc:rc.d:iptables-start-.txt
-rw-r--r-- 1 root root 4699 Feb 17 20:37 :etc:rc.d:iptables-stop-.txt
-rw-r--r-- 1 root root 8802 Feb 17 20:39 :etc:rc.d:network-start-.txt
-rw-r--r-- 1 root root 4827 Feb 17 20:37 :etc:rc.d:network-stop-.txt
The syntax of the variable $only_info_pls is like this:
:::
where is matched against the scripts name with bash option
extglob set before going to work and reset to its previous state
afterwards. defines a file on a filesystem that must be
mounted when the monitored script starts. Occurrences of ! with
from "0" ... "5" are expanded with the appropriate script arguments, and
directory separators are replaced with colons.
etc/rc.d/functions.d/only_info_pls.sh is too small to make anything more
than this post of it, but it proved very useful so far. I tried to make
it safe to use even with matchers such as "*/rc.sysinit*" in that the
existence of logger(1) and /dev/null are checked before use, and
a missing declaration defaults to "only_info_pls.sh-!0", which
dumps the trace into the current directory if its writable.
clemens
# /etc/rc.d/functions.d/only_info_pls.sh
# _date: 20100217-2035_
#
# to be sourced by bash(1).
# see /etc/rc.conf
# see /etc/rc.d/functions
_iam="/etc/rc.d/functions.d/only_info_pls.sh"
# global: ${only_info_pls} ${_only_info_pls_out}, ${_only_info_pls_trig},
# ${_only_info_pls_extglob}, ${_only_info_pls_logger}
# initscripts colors from /etc/rc.d/functions:
# global: $C_MAIN, $C_OTHER, $C_SEPARATOR, $C_BUSY, $C_FAIL, $C_DONE,
# $C_BKGD, $C_H1, $C_H2, $C_CLEAR, $SAVE_POSITION, $RESTORE_POSITION,
# $DEL_TEXT, $STAT_COL, $SECOLOR
_only_info_pls_prep()
{
local out0="${0//\//:}"
local cmd="${1:-prep}"
local devnull="/dev/null"
local out1
local out2
local out3
local out4
local out5
shift
#
case "-${cmd}" in
-prep)
out1="${1//\//:}"
out2="${2//\//:}"
out3="${3//\//:}"
out4="${4//\//:}"
out5="${5//\//:}"
_only_info_pls_trig="${only_info_pls%%:::*}"
_only_info_pls_out="${only_info_pls##*:::}"
: ${_only_info_pls_logger:="logger -s"}
: ${_only_info_pls_out:="${_iam##*/}-!0"}
_only_info_pls_out="${_only_info_pls_out/!0/${out0}}"
_only_info_pls_out="${_only_info_pls_out/!1/${out1}}"
_only_info_pls_out="${_only_info_pls_out/!2/${out2}}"
_only_info_pls_out="${_only_info_pls_out/!3/${out3}}"
_only_info_pls_out="${_only_info_pls_out/!4/${out4}}"
_only_info_pls_out="${_only_info_pls_out/!5/${out5}}"
[ -w "${devnull}" ] && {
type -t "${_only_info_pls_logger%% *}" > ${devnull} ||
_only_info_pls_logger="echo"
:
} || {
type -t "${_only_info_pls_logger%% *}" ||
_only_info_pls_logger="echo"
:
}
_only_info_pls_extglob="-u"
shopt -q extglob && _only_info_pls_extglob="-s"
;;
-colors)
C_MAIN="" # main text
C_OTHER="" # prefix & brackets
C_SEPARATOR="-" # separator
C_BUSY="" # busy
C_FAIL="" # failed
C_DONE="" # completed
C_BKGD="" # backgrounded
C_H1=""# highlight text 1
C_H2=""# highlight text 2
C_CLEAR=""
SAVE_POSITION=""; RESTORE_POSITION=""; DEL_TEXT=""
STAT_COL=80; SECOLOR="neee"
;;
esac
return 0
}
# local hack: info instead of colors!
# implemented via /etc/rc.d/functions.d/only_info_pls.sh
# see /etc/rc.conf
#only_info_pls=""
#only_info_pls="*@(/network|/iptables)*:::/root/system/boot/questions/!0-!1-!2.txt"
#only_info_pls="*@(/network|/iptables)*:::/root/system/boot/questions/rc.d-network-!1.txt"
#only_info_pls="*/network*:::/root/system/boot/question
Re: [arch-general] (solved) Re: pacman message: "too much happens::" ...
clemens fischer wrote: > ... After switching to tmux, I increased the rate at which these > messages are dequeued and displayed, so the queues filled up. Actually, I _decreased_ the dequeuing rate, and that's why they filled up. Sigh. clemens
[arch-general] (solved) Re: pacman message: "too much happens::" ...
clemens fischer wrote:
> "too much happens:: Synchronizing package databases..."
It was my fault after all. Maybe you'd have found it, if I had posted
the entire fcrontab command:
@mail(1),first(5) 8h ${tellit} "pacman sync"; \
{ pacman --noprogressbar -Sy && pacman --noprogressbar -Qu || :; } 2>&1
and ${tellit} is:
tellit="/root/bin/screen_backtick.sh -u root -b0"
and screen_backtick.sh calls my very own eventlogger, which is a shell
interface to mq_overview(7), the posix message queues. There are
a number of writers in my systems sending status messages to be
displayed in the screen/tmux status line. After switching to tmux,
I increased the rate at which these messages are dequeued and displayed,
so the queues filled up. There's resource limiter in eventlogger: if
too many messages are queued, the STORM pseudo-message is shown to
indicate an error. It so happens that STORM is set to "too much
happens".
I should have known better: If I am the only person with some problem,
it just might be my fault ...
clemens
Re: [arch-general] pacman message: "too much happens::" ...
Aaron Griffin wrote: > Could it be a message from cron itself? No, you might have read in my original post that I grepped for the string in fcron, pacman and libalpm, as well as the libc. clemens
Re: [arch-general] pacman message: "too much happens::" ...
Daenyth Blank wrote: > Maybe it's an error from your download agent if you're not using > libfetch in pacman? Not that, either. I'm using no download agent. I wonder why it went away a few days ago. Does anybody else use "http://ftp.tu-chemnitz.de/pub/linux/archlinux/"; or "http://ftp.uni-bayreuth.de/linux/"; as pacman mirrors? Might well be that it is a message from their servers putting me off for overload. But its funny that everything worked, except for this message ... clemens
Re: [arch-general] pacman message: "too much happens::" ...
Daenyth Blank wrote:
> On Fri, Feb 5, 2010 at 18:07, clemens fischer
> wrote:
>> Sorry. It's an fcrontab entry:
>>
>> { pacman --noprogressbar -Sy && pacman --noprogressbar -Qu || :; } 2>&1
>
> Try it with --debug for more info?
No chance. 'Cause it went away by itself. How about checking the
servers? Does any component of them contain that string "too much
happens"? I can imagine many people accessed the package servers due to
the libpng* updates.
clemens
Re: [arch-general] pacman message: "too much happens::" ...
Dan McGee wrote:
> On Fri, Feb 5, 2010 at 4:08 PM, clemens fischer wrote:
>
>> I'm updating the pacman database about once a day. For the last few
>> days I always get this message:
>>
>> "too much happens:: Synchronizing package databases..."
>>
>> but everything works fine. I checked usr/bin/pacman,
>> /usr/lib/libalpm.so.4 and usr/sbin/fcron using strings(1) for the text
>> "much", but no hits.
>>
>> What's happening here?
>
> Showing the command you are actually running might be a good first
> start...
Sorry. It's an fcrontab entry:
{ pacman --noprogressbar -Sy && pacman --noprogressbar -Qu || :; } 2>&1
clemens
[arch-general] pacman message: "too much happens::" ...
Hi, I'm updating the pacman database about once a day. For the last few days I always get this message: "too much happens:: Synchronizing package databases..." but everything works fine. I checked usr/bin/pacman, /usr/lib/libalpm.so.4 and usr/sbin/fcron using strings(1) for the text "much", but no hits. What's happening here? clemens
Re: [arch-general] dd and bash_completion
On Thu-2009/09/24-22:24 Aaron Griffin wrote: > And this appears to be fixed in git > > http://code.phraktured.net/cgit.cgi/bash-completion/commit/?id=f733e71e1f8d63c072a402346d8162f9c6b63ae2 > http://code.phraktured.net/cgit.cgi/bash-completion/commit/?id=f871fe4101ed89cb98e201aed8c975fd3061905b How come the ABS package says http://bash-completion.alioth.debian.org/, and you clone from phraktured.net? The alioth.debian.org repo mentioned on the url website has a different IP, but the same commit. clemens
Re: [arch-general] '*' in PKGBUILD for the conflicts array
On Thu-2009/08/13-07:06 Allan McRae wrote: > conflicts=$(pacman -Ssq kdebase-) conflicts=($(pacman -Ssq kdebase-)) If "conflicts" is supposed to be an array. clemens
[arch-general] IPv6 firewall, same as IPv4?
Can I put IPv6 rules into the regular etc/iptables/iptables.rules file containing only IPv4 rules otherwise? I noticed that both /usr/sbin/iptables and /usr/sbin/ip6tables depend on the same .so libs, so me thinks these libs need to have IPv6 support and all is well. Also, to make IPv6 work I put a rule to pass IPv6 protocol traffic outbound on eth+. Inbound packets are propably handled by the customary "-A INPUT -i eth+ -m state --state ESTABLISHED,RELATED -j ACCEPT", as they get into the machine somehow. I didn't check packet counters, though. clemens
Re: [arch-general] C-> and C<- does not work in urxvt in tabbed?mode - archlinux specific
On Mon-2009/08/10-19:58 Daenyth Blank wrote: > On Mon, Aug 10, 2009 at 12:24, Aaron Griffin wrote: > >> If you like these, you can stick them in ~/.inputrc for your user >> account. It works for any app using readline. > > I added those to my ~/.inputrc, but it's still not working. Is there > anything I have to do aside from opening a new terminal? Of course you have to find out which keys to bind in the first place, and if they are rebound some place else. Do "cat" and type the keys you want, they should display as "funny" strings. "^[" is an escape, readline wants "\e" or "\M" or "Meta" for that. "man 3 readline". clemens
Re: [arch-general] Regression in PC Beep when updating to 2.6.30
On Tue-2009/07/28-09:37 Roman Kyrylych wrote: > On Tue, Jul 28, 2009 at 04:15, Flavio Costa wrote: > >> Muting the "PC Beep" in "alsamixer" mutes the beep, but the internel >> speaker doesn't come back to life > > I think that is because of CONFIG_SND_HDA_INPUT_BEEP=y If it is really > important to you - try rebuilding your kernel with the option turned > off. This can't be the end of the story! There must be, or should be a way to enable the PC-speaker. I see that other distributions turn of "CONFIG_SND_HDA_INPUT_BEEP" in .config, and IMO arch-linux should do the same. I do rely heavily on various sounds to indicate mail arrival, completion of some task etc. Meanwhile Takashi Iwai wrote in [1]: To avoid someone misunderstanding: the beep routed through HD-audio can also go to the built-in speaker. It's just mixed up with the normal audio output, and the volume is controlled via ALSA mixer volume element. But, once after it's hooked up to the codec, the beep can't be output separately to the speaker. It's always with other audio signal to the same output target. Or, on some systems (mostly laptops), the beep is hooked up to the codec automatically no matter whether you set CONFIG_SND_HDA_INPUT_BEEP once when the codec chip is initialized. So, the behavior depends pretty much on the hardware implementation. So there must be a way to configure HDA to route beeps to the speaker, but how is this done? I remember HDA being able to wire specific sound sources to specific jacks. If you employ The Search Engine[2] you'll see that there must be even another way using some asound.conf setting, but again, I cannot find a definitive guide. [1] http://bugzilla.kernel.org/show_bug.cgi?id=13651> [2] http://www.google.com/search?q=etc%2fasound.conf> clemens
Re: [arch-general] Xorg broken after last update
On Mon-2009/08/03-16:52 clemens fischer wrote: > I don't run a customary desktop, just screen(1) in urxvt(1) on > Xorg(7), all applications being ncurses driven. Doing: > > pacman -U /var/cache/pacman/pkg/xorg-server-1.6.2-1-i686.pkg.tar.gz > > fixed it. xorg-server-1.6.3-2 has not failed me for hours now, after torturing it with "x11perf -all" and all the apps from xorg-apps. clemens
Re: [arch-general] Xorg broken after last update
On Sat-2009/08/01-23:58 Lu?s Moreira wrote: > The last update broke my Xorg, the screen just goesn black and hangs > there, CTRL+ALT+F1 (etc) doesn't do anything. > > I'm using X86_64, *without* [testing]. > > The updated packages were > > kernel26 > nvidia > xorg-server > (and some others, less important) > > If I change the driver in xorg.conf from nvidia to vesa X works again. I'm running i686. The nVIDIA GeForce 6100/nFORCE 430 chipset (AMD64) exhibits segfaults in xorg-server-1.6.3-1 X(1): Backtrace: 0: /usr/bin/X(xorg_backtrace+0x3b) [0x813177b] 1: /usr/bin/X(xf86SigHandler+0x9e) [0x80caf6e] 2: [0xb7f79400] 3: /usr/lib/libdbus-1.so.3 [0xb7e884c9] 4: /usr/bin/X [0x80ab683] 5: /usr/bin/X(WakeupHandler+0x52) [0x8090b42] 6: /usr/bin/X(WaitForSomething+0x1a2) [0x812f2b2] 7: /usr/bin/X(Dispatch+0x80) [0x808c530] 8: /usr/bin/X(main+0x395) [0x8072065] 9: /lib/libc.so.6(__libc_start_main+0xe6) [0xb7b45a36] 10: /usr/bin/X [0x8071511] Fatal server error: Caught signal 11. Server aborting This error occurs often, but today another one showed up: Backtrace: 0: /usr/bin/X(xorg_backtrace+0x3b) [0x813177b] 1: /usr/bin/X(xf86SigHandler+0x9e) [0x80caf6e] 2: [0xb7f96400] 3: /usr/lib/libdbus-1.so.3 [0xb7ea54c9] 4: /usr/bin/X [0x80ab683] 5: /usr/bin/X(WakeupHandler+0x52) [0x8090b42] 6: /usr/bin/X(WaitForSomething+0x1a2) [0x812f2b2] 7: /usr/bin/X(Dispatch+0x80) [0x808c530] 8: /usr/bin/X(main+0x395) [0x8072065] 9: /lib/libc.so.6(__libc_start_main+0xe6) [0xb7b62a36] 10: /usr/bin/X [0x8071511] Fatal server error: Caught signal 4. Server aborting Signal 4 is an illegal instruction. The log also contained, for the sigsegv case: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" after 27 requests (26 known processed) with 0 events remaining. XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" after 103 requests (103 known processed) with 0 events remaining. XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" after 508 requests (508 known processed) with 0 events remaining. urxvt: X connection to ':0.0' broken, unable to recover, exiting. xinit: connection to X server lost. In my case, the error appeared after various intervals of normal operation, but I think I could provoke it by opening more windows. As several components went into the last upgrade, I couldn't tell which one caused the problem. The X11-related packages were: [2009-08-02 16:04] upgraded hal-info (0.20090414-1 -> 0.20090716-1) [2009-08-02 16:04] upgraded inputproto (1.5.0-1 -> 1.5.1-1) [2009-08-02 16:05] upgraded kernel26 (2.6.30.2-1 -> 2.6.30.4-1) [2009-08-02 16:05] upgraded xcb-proto (1.4-1 -> 1.5-1) [2009-08-02 16:05] upgraded libxcb (1.2-1 -> 1.4-1) [2009-08-02 16:05] upgraded libx11 (1.2.1-1 -> 1.2.2-1) [2009-08-02 16:05] upgraded pciutils (3.1.2-1 -> 3.1.3-1) [2009-08-02 16:05] upgraded xcb-util (0.3.4-2 -> 0.3.5-1) [2009-08-02 16:05] upgraded xf86-input-evdev (2.2.2-1 -> 2.2.3-1) [2009-08-02 16:05] upgraded xorg-server (1.6.2-1 -> 1.6.3-1) I don't run a customary desktop, just screen(1) in urxvt(1) on Xorg(7), all applications being ncurses driven. Doing: pacman -U /var/cache/pacman/pkg/xorg-server-1.6.2-1-i686.pkg.tar.gz fixed it. BTW: except for one instance where neither mouse nor keyboard worked, I was dropped back to the console and didn't loose any work, because I could resurrect everything with "screen -R". It is even possible to experiment within X11, detach that screen and resume it in the console, switching back and forth between X11-grafix and console. A wonderful thing, this screen(1) program! One last thing should be mentioned, though: a few days ago, with "xorg-server-1.6.2-1" running, Xorg froze on me, indicating that the problem might not be caused by the hal-debug-patch mentioned in the forum. The more so because I don't have hald(8) running at all, and my /etc/X11/xorg.conf contains: Section "ServerFlags" ... Option "AutoAddDevices" "False" # stop HAL Option "AutoEnableDevices" "false" # stop HAL EndSection The DBUS daemon is up, if that is of interest. clemens
Re: [arch-general] archboot stills depends of portmap
Tobias Powalowski wrote: > archboot depends are designed to generate a working image, vi on > archboot is vim, as long as this is not fixed it cannot move in. could that editor be made pico(1), then? clemens
Re: [arch-general] archboot stills depends of portmap
On Sun-2009/07/26-17:36 Tobias Powalowski wrote: > As long as vim is not fixed this cannot move in, install the version > from testing or use latest git version. Sorry to sound ignorant: what has an editor got to do with archboot?? clemens
Re: [arch-general] lddd from devtools rewritten
I wrote:
> Environment variables:
>
> $LDDD_LIB_IGNORE: globs of missing lib-names to ignore[2].
> $LDDD_DONT_CHECK: globs of file names to completely ignore[2].
As a usage example, I don't have but the most basic qt stuff, and no
rrd-data-graphing, no ruby etc., ie. typical household optional
dependencies. This is in my bash environment:
export LDDD_LIB_IGNORE=''
export LDDD_DONT_CHECK=''
LDDD_LIB_IGNORE="${LDDD_LIB_IGNORE} *libruby*"
LDDD_LIB_IGNORE="${LDDD_LIB_IGNORE} *libtk8.5*"
LDDD_LIB_IGNORE="${LDDD_LIB_IGNORE} *libqt-mt*"
LDDD_LIB_IGNORE="${LDDD_LIB_IGNORE} *libbonobo*"
LDDD_LIB_IGNORE="${LDDD_LIB_IGNORE} *libpanel-applet*"
LDDD_LIB_IGNORE="${LDDD_LIB_IGNORE} *libgnome*"
LDDD_LIB_IGNORE="${LDDD_LIB_IGNORE} *librrd*"
LDDD_DONT_CHECK="${LDDD_DONT_CHECK} *lib/nautilus/extensions*"
LDDD_DONT_CHECK="${LDDD_DONT_CHECK} *lib/firefox-3.5/components*"
LDDD_DONT_CHECK="${LDDD_DONT_CHECK} *lib/qt/plugins/sqldrivers*"
LDDD_DONT_CHECK="${LDDD_DONT_CHECK} *lib/xine/plugins*"
You might also want to put settings like this into per-subsystem files
sourced in a little three line script for cron.
Every once in a while and after "risky" updates I run:
time lddd-c.sh -v
which should produce no list of broken packages. It takes about
a minute on my system[1], a little less than the original lddd, but
without the irritating false positives.
[1] double that for empty filesystem caches.
clemens
[arch-general] lddd from devtools rewritten
I rewrote lddd from extra/devtools. The intent was to make it faster
and remove false positives, as well as support for ignoring certain
files completely, filtering the list of missing libs to handle optional
dependencies, take /etc/ld.so.conf into account and in general make it
more usable. NB: uses bash-4 features.
URL: http://ino-waiting.gmxhome.de/files/lddd-c.sh
Here's the help screen:
$ lddd-c.sh -h
Use lddd-c.sh [options] [paths]
Default-paths: $PATH,
/lib:/usr/lib:/opt/qt/lib:/opt/kde/lib:/usr/lib/libfakeroot:/opt/NX/lib:/usr/local/lib:/usr/local/libexec
options:
-d : do not check glob , can be given multiple times.
-l : ignore missing library glob , multiple times.
-L:do not use LD_LIBRARY_PATH running ldd(1)[1].
-v:be more and more chatty.
-D : trigger tracing on meeting , debugging aid.
Environment variables:
$LDDD_LIB_IGNORE: globs of missing lib-names to ignore[2].
$LDDD_DONT_CHECK: globs of file names to completely ignore[2].
[1] risks false positives, but finds all broken ELF dependencies.
[2] space separated list of globs, needs to be quoted to the shell.
NB: A broken ELF file will be reported unless it is ignored ('-d' option
or $LDDD_DONT_CHECK) or _ALL_ of its missing libs are ignored ('-l'
or $LDDD_LIB_IGNORE)!
_version: 20090727-2016_
The "new and improved" algorithm goes like this:
1. All files executable by the user or matching the customary *.so
patterns are collected after verifying their ELFness.
2. The file paths are checked to see if their base directories contain
any libraries and these directories are collected into
LD_LIBRARY_PATH.
3. In a third loop, the files from step one are checked by ldd(1)
prefixed with this LD_LIBRARY_PATH to see if any prerequisites are
missing. This step is repeated without the path to check the odd
customer.
4. Suspects aquired this way are sent to a co-process to determine the
packages they belong to.
5. Results are collected into files in /tmp/lddd-c.sh-$UID and
a summary listed to stdout. This makes it easy to use in cron-jobs.
Detail is controlled by the number of '-v' options.
Step four was intended to speed up the process, but as it turns out it
doesn't help all that much. The pacman call is indeed expensive and can
be done in parallel, but it obviously competes for disk access.
Therefore the co-process caches the file list of any broken package
expecting to find more broken files in it, but this only helps big
packages with several broken executables.
All in all lddd-c.sh is an improvement over the simpler lddd and the
terribly hacked findbrokenpkgs[1]. As there should be no false
positives, it should report b0rked packages after botched or incomplete
updates in a reliable way.
Valuable testing was done by Allan McRae and AttilaH. Some nasty bugs
would still stink the code without their patience.
[1] http://bbs.archlinux.org/viewtopic.php?id=13882
clemens
Re: [arch-general] /etc/resolv.conf continuously wiped since?yesterday
On Fri-2009/07/10-21:53 Caleb Cushing wrote: > the problem is it's ending up with no values. If you prefer to have your own settings in etc/resolv.conf, you can do this: create "/etc/dhcpcd.enter-hook" with example contents: # what is supposed to be in /etc/resolv.conf: new_domain_name="." new_domain_name_servers="127.0.0.53" exit_status=0 clemens
Re: [arch-general] [arch-dev-public] [signoff] vc/* -> tty*?transition
Gerardo Exequiel Pozzi wrote: > __ > / \ ___ > | | / \ > @ @ | It looks like you are | > || ||| trying to update your | > || || <--| system, are you sure? | > |\_/|\___/ > \___/ The ASCII-art is by far the best post in this thread. And I am for installing a .pacnew on meeting a changed inittab and a big message. And I'm sort of against packages doing out-of-bailiwick business for me. clemens
Re: [arch-general] Mirror not updating
On Thu-2009/07/09-19:17 Gerhard Brauer wrote:
> for arch in ${ARCHES}; do
>for repo in ${REPOS}; do
>echo -e -n "$arch-$repo:\t"
>date +"%x %X" -u -d @$(wget -q -O - $1/$repo/os/$arch/lastsync)
>done
> done
please don't post anything like this: apart from being barely
comprehendable, it is _unsafe_! you are using _outside info_ in a shell
script _without validation_! it poses the risk of privilege escalation!
and don't say security issues should be handled by remote admins!
how about:
# uses bash features
shopt -s extglob
iam="${0##*/}"
tmp=""
ex=0
tmpfile="${TMPDIR:-/tmp}/${iam}.tmp"
wget="/usr/bin/wget -q"
# risk: race
rm -rf "${tmpfile}" && touch "${tmpfile}" || exit 9
for arch in ${ARCHES}; do
for repo in ${REPOS}; do
# risk: backquote execution, better use unpriv script
${wget} -O "${tmpfile}" "${1}/${repo}/os/${arch}/lastsync" || {
ex=$?
echo "${iam}: $1/${repo}/os/$arch/lastsync wget exits: ${ex}"
continue
}
tmp="$(< ${tmpfile})"
# remove all punctuation characters, check for numbers
tmp="${tmp//[[:punct:]]}"
case ".${tmp}" in
.+([[:digit:]])) ;; # ok
*)
echo "${iam}: $1/${repo}/os/$arch/lastsync not number: ${tmp}"
continue
;;
esac
echo -e -n "${arch}-${repo}:\t"
date +"%x %X" -u -d "@${tmp}"
done
done
not much longer, but a little safer. the least one should do in this
situation.
clemens
Re: [arch-general] AUR Search
On Wed-2009/06/24-00:02 Loui Chang wrote: > I'm going to try to take time to think up and work out a prototype for > a robust system that will run the next generation of AUR. Right now > I have some measly shell script to help me flesh out my ideas hah. Whatever you do, please don't loose that JSON interface! It is so much more convenient than the web-interface, I use it all the time. clemens
Re: [arch-general] SIGSEGV in getopt, libc-problem?
On Tue-2009/07/07-22:17 clemens fischer wrote:
> (gdb) bt
> incomplete CFI data; unspecified registers (e.g., eax) at 0xb7fa838a...#0
> 0xb7fa84dc in _getopt_internal_r ()
> from /lib/libc.so.6
> #1 0xb7fa946e in _getopt_internal () from /lib/libc.so.6
> #2 0xb7fa96b9 in getopt_long () from /lib/libc.so.6
> #3 0x0804980d in parse_real ()
> #4 0x08049a07 in args_parse ()
> #5 0x0804b18e in main ()
A much simpler way to get at the same info is by using extra/ltrace:
$ ltrace -Sif -A9 -n4 /usr/bin/xz
...
[0x804a020] sysconf(76, 0, 3, 0, 0) = -1
[0x8049c63] strrchr("/usr/bin/xz", '/') = "/xz"
[0x8049c7b] strstr("xz", "lz") = NULL
[0x8049c96] strstr("xz", "cat") = NULL
[0x8049e94] strstr("xz", "un") = NULL
[0x8049cbb] getenv("XZ_OPT") = "-9"
[0x804e097] strlen("-9") = 2
[0x804e058] realloc(NULL, 3) =
0x09f92868
[0x804e0ba] memcpy(0x09f92868, "-9", 3) =
0x09f92868
[0x8049ce4] __ctype_b_loc() =
0xb7d5a68c
[0x804e058] realloc(NULL, 12)=
0x09f92878
[0x8049d6e] __ctype_b_loc() =
0xb7d5a68c
[0x80495b4] getopt_long(2, 0x09f92878,
"cC:defF:hHlkM:qrS:tT:vVz01234567"..., 0x0804e520, NULL) = 57
[0x80495b4] getopt_long(2, 0x09f92878,
"cC:defF:hHlkM:qrS:tT:vVz01234567"..., 0x0804e520, NULL) = -1
[0x8049de4] free(0x09f92878) =
[0x8049def] free(0x09f92868) =
[0x80495b4] getopt_long(1, 0xbfdb4004,
"cC:defF:hHlkM:qrS:tT:vVz01234567"..., 0x0804e520, NULL
[0xb7e0e3cc] --- SIGSEGV (Segmentation fault) ---
[0x] +++ killed by SIGSEGV +++
I left out a lot of cruft, but it shows where the program busts.
clemens
Re: [arch-general] SIGSEGV in getopt, libc-problem?
Daenyth Blank wrote: > Are you using [testing]? When is the last time you updated those > programs and/or libraries? I had [testing] for a while, only for testing some X11 libs back when I had a problem with a trackball. I stopped using it about a week ago, but I think there's no package left on my system. BTW: what's the pacman command to list the packages one has installed from a certain repo? The closest I can think of is: $ pacman -Qm csup 20060318-5 ddcxinfo-arch 0.8-2 dstat 0.6.9-1 libfetch 2.20-1 lshwd 1.1.3-5 opera 9.64-1 ttf-code2000 1.171-1 yaourt 0.9.2.4-1 I badly miss the repo-origin in the "pacman -Qi ..." output. Do you think one of these packages could influence my "xz" problem? clemens
Re: [arch-general] SIGSEGV in getopt, libc-problem?
Gerardo Exequiel Pozzi wrote: > Compare with me > > $ md5sum /usr/lib/liblzma.so.0 /lib/libpthread.so.0 /lib/libc.so.6 > /lib/ld-linux.so.2 /usr/bin/xz > 72cd526ea4ee299f5c9eb1b49180d163 /usr/lib/liblzma.so.0 > e12a37058b6360660658ad2bd26c2b57 /lib/libpthread.so.0 > 2a1cf98f035403805ae860b95fd8e995 /lib/libc.so.6 > 5db9051e70520777209f5368fb5d975b /lib/ld-linux.so.2 > 6f9d136415196e8547d3366d5f1d6139 /usr/bin/xz > > $ pacman -Qo /usr/lib/liblzma.so.0 /lib/libpthread.so.0 /lib/libc.so.6 > /lib/ld-linux.so.2 /usr/bin/xz > /usr/lib/liblzma.so.0 is owned by xz-utils 4.999.8beta-4 > /lib/libpthread.so.0 is owned by glibc 2.10.1-2 > /lib/libc.so.6 is owned by glibc 2.10.1-2 > /lib/ld-linux.so.2 is owned by glibc 2.10.1-2 > /usr/bin/xz is owned by xz-utils 4.999.8beta-4 Thank's for checking. The info on my system matches yours. clemens
[arch-general] SIGSEGV in getopt, libc-problem?
For a few days now I noticed some programs not working, like "lzma" or
"xz" from the "xz-utils". They segfault and "xz --help" says:
$ /usr/bin/xz --help
/usr/bin/xz: unrecognized option '--'
/usr/bin/xz: Try `/usr/bin/xz --help' for more information.
So I went to compile the original source, and the gdb(1) backtrace shows
them to die in "_getopt_internal()". I thought my system to be
inconsistent somehow, because a friend reports these programs working.
I already re-installed the package. It gets its libs from archlinux
package locations:
$ ldd /usr/bin/xz
linux-gate.so.1 => (0xb80a4000)
liblzma.so.0 => /usr/lib/liblzma.so.0 (0xb806e000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb8056000)
libc.so.6 => /lib/libc.so.6 (0xb7f0e000)
/lib/ld-linux.so.2 (0xb80a5000)
It is possibly a problem with getopt_long(). Most programs work(!), ie.
I only noticed this with "xz", "lzma" and friends, both the packages and
hand-compiled versions. I use the bash commandline all the time with
many programs calling getopt_long(), they all work. Backtrace:
(gdb) run
Starting program: /home/src/bulk/lzma/xz/src/xz/xz
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Reading symbols from system-supplied DSO at 0xb8069000...(no debugging
symbols found)...done.
Reading symbols from /lib/libpthread.so.0...(no debugging symbols
found)...done.
[Thread debugging using libthread_db enabled]
Reading symbols from /lib/libc.so.6...
(no debugging symbols found)...done.
[New Thread 0xb7ef36c0 (LWP 32015)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7ef36c0 (LWP 32015)]
0xb7fa84dc in _getopt_internal_r () from /lib/libc.so.6
(gdb) bt
incomplete CFI data; unspecified registers (e.g., eax) at 0xb7fa838a...#0
0xb7fa84dc in _getopt_internal_r ()
from /lib/libc.so.6
#1 0xb7fa946e in _getopt_internal () from /lib/libc.so.6
#2 0xb7fa96b9 in getopt_long () from /lib/libc.so.6
#3 0x0804980d in parse_real ()
#4 0x08049a07 in args_parse ()
#5 0x0804b18e in main ()
$ pac o /lib/libc.so.6
/lib/libc.so.6 is owned by glibc 2.10.1-2
$ ll /lib/libc[.-]*
393476 -rwxr-xr-x 1 root root ? 1.6M 2009-05-23 05:54 /lib/libc-2.10.1.so*
393470 lrwxrwxrwx 1 root root ? 14 2009-05-23 05:54 /lib/libc.so.6 ->
libc-2.10.1.so*
Did somebody else observe something like this? I already searched the
web ("_getopt_internal_r SIGSEGV"), but there's nothing specific,
although other programs had problems like this years ago.
Any pointers appreciated.
clemens
Re: [arch-general] pacman version string regex?
Xavier wrote:
> On Fri, Jul 3, 2009 at 6:58 PM, clemens fischer wrote:
>
>> is there a regular expression describing the version comparison
>> algorithm in pacman/lib/libalpm/package.c::alpm_pkg_vercmp()?
>
> Could you give an example of what you are trying to do?
simple example, looking for the details of "ratpoison" (window-manager):
$ pacman -Qs rat|wc
44 2511977
(44 lines of mostly irrelevant output)
$ pac sL rat
pac: local/ratpoison
which is the one line i need when part of the package name is known.
There are other options to search descriptions. I am currently using
the following pattern to exclude version suffixes:
local vers_glob="-?([nN][gG][_-])+([[:digit:]])+([[:alnum:][:punct:]])"
It is used lateron like this:
eval tmp=\"\${tmp%%\${vers_glob}}\"
I got bitten by the "-NG_*" suffix just today, and every once in a while
I notice some package isn't found or properly listed. If there is
a regex or a bash-snippet, I could massage it into proper bash extended
globbing syntax.
The bash script is too big to post it, but you'll find it here[1].
[1] http://freenet-homepage.de/inode/pac.sh
clemens
[arch-general] pacman version string regex?
Hi, is there a regular expression describing the version comparison algorithm in pacman/lib/libalpm/package.c::alpm_pkg_vercmp()? I have a pacman wrapper (bash script) that needs to determine the package name to give to pacman given a directory name, because it is possible to give globs to filenames, but not to pacman. I cannot use "pacman -[QS]s ", because sometimes I want to glob just package names, not descriptions. So basically I don't want the actual version comparison, only the removal of the version suffix including our release number. clemens
Re: [arch-general] install packages using links?
Andrei Thorp wrote: > Okay, but how do those links get to the places they're supposed to be > if you don't update packages to put them there? Currently all files are there, no need to change that, it works. If any package is updated, the files would have to be replaced anyway, so put links to the actual places there. This is what I'm doing in /usr/local for self installed and local stuff. I have non-symlinked packages there and the newer symlink-style. There is no service disruption. > Anyway, I think there is a widely echoed polite "decent idea if we > didn't already have all we need. No thank you". Yes, I somehow came to the same conclusion 8-) There are many archlinux packages I don't care changing and I can use them as they are, for others, I have my symlinked installs in /usr/local. No problem. clemens
Re: [arch-general] install packages using links?
Andrei Thorp wrote: > Well, as far as I can tell, the problem is that this requires the > updating of the 4050 packages we have at the moment. All of them. By > hand. For rather limited gain. Well, you don't get it as far as I can tell. As all paths stay the same, _not one single package_ has to be updated. That's what I mean with "compatible". "/usr/bin/file" is still "/usr/bin/file", but it could be a symlink instead of a file. Look at the .so libraries: /lib/libcap.so -> libcap.so.2 /lib/libcap.so.2 -> libcap.so.2.16 /lib/libcap.so.2.16 Programs are already doing this all the time: /bin/bunzip2 -> bzip2 /bin/bzcat -> bzip2 /bin/bzip2 The symlinking itself is obviously not a problem. And having easier package management is a big gain. For many users, their linux distribution is a kernel plus the packages they like. I for one can appreciate not having to use "pacman" to find out what package some file belongs to. I even wrote my own wrapper giving it package globs just because "pacman" doesn't have them everywhere, using "ls" and "find" for some of the "-Q" and "-S" tasks would be a big plus IMO. clemens
Re: [arch-general] install packages using links?
Daenyth Blank wrote: > -1. It's really not needed, pacman does plenty. And we should stick to > the FHS when possible. Keeping with norms is almost always good, but putting package files into their own directories and linking to them from the standard FHS places doesn't violate the FHS. Unless the FHS rules out symlinks. I cannot believe it does, though. clemens
Re: [arch-general] install packages using links?
Andrei Thorp wrote: > Also, remaking all packages in the repos to do this? Where's the problem? The symlinking can be done at leisure, on routine updates. They are compatible. clemens
Re: [arch-general] install packages using links?
Gerardo Exequiel Pozzi wrote: > clemens fischer wrote: >> /usr/local/bin/gpp -> /opt/gpp/2.24/bin/gpp* >> /usr/local/man/man1/gpp.1 -> /opt/gpp/2.24/man/man1/gpp.1 >> ... >> >> [1] http://www.rpcurnow.force9.co.uk/spill/ > > Maybe GoboLinux is for you http://es.wikipedia.org/wiki/GoboLinux Ah, I had forgotten about this distribution. Thanks for the pointer. clemens
[arch-general] install packages using links?
Hi,
Whenever I install autotools-aware programs from source, they don't go
into /usr/local as is customary, but into their own directory called
/opt//, and then files in
/opt///{{s,}bin,man} etc. get symlinked into their
counterparts in /usr/local. I am using spill[1] for this.
Thus, for gpp-2.24, which is a preprocessor like cpp(1) sporting
modifiable syntax, the result is:
/usr/local/bin/gpp -> /opt/gpp/2.24/bin/gpp*
/usr/local/man/man1/gpp.1 -> /opt/gpp/2.24/man/man1/gpp.1
The advantage is easy to see: you can always see what package some file
belongs to, and removing a package is as simple as removing matching
links and the installation directory. All files belonging to a package
are in one place. spill(8) automates package installation and
management, but this can be done manually as well.
Would going this route for arch-linux packages be seen as an
improvement?
[1] http://www.rpcurnow.force9.co.uk/spill/
clemens
PS: I originally sent this to arch-dev-public@, but obviously I can
subscribe to that list while not qualified to post.
