Re: [arch-general] pacman.conf: can I use wildcards?
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. 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.-) See you, Attila
Re: [arch-general] pacman.conf: can I use wildcards?
On Wed, Feb 17, 2010 at 7:13 PM, Dan McGee wrote: > On Wed, Feb 17, 2010 at 3:51 PM, clemens fischer > wrote: >> 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.* > > No, we don't support globbing in these options. Question to the list- > does it make sense to do so? Yes, but it would also be nice to support recursion here as well. For instance: NoExtract = /usr/share/doc/* should disable ALL doc extraction, no matter how deep it's nested
Re: [arch-general] pacman.conf: can I use wildcards?
On 02/17/2010 10:13 PM, Dan McGee wrote: On Wed, Feb 17, 2010 at 3:51 PM, clemens fischer wrote: 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.* No, we don't support globbing in these options. Question to the list- does it make sense to do so? -Dan Yes, sure! In many times, this will be really usefull. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Re: [arch-general] pacman.conf: can I use wildcards?
Am Wed, 17 Feb 2010 19:13:26 -0600 schrieb Dan McGee : > No, we don't support globbing in these options. Question to the list- > does it make sense to do so? Yes, because I usually edit many of the .desktop files in /usr/share/applications due to a missing menu editor in Xfce and a terrible menu editor in KDE (bloated XML file and just marking entries as deleted instead of deleting them). And adding every single .desktop file to /etc/pacman.conf makes this file pretty long and complex. So it was nice, if one could either add a complete directory (e.g. usr/share/applications) or such a path with a wildcard for the files (e.g. usr/share/applications/*) to NoUpgrade. Greetings, Heiko
Re: [arch-general] pacman.conf: can I use wildcards?
On 18 February 2010 09:13, Dan McGee wrote: > On Wed, Feb 17, 2010 at 3:51 PM, clemens fischer > wrote: >> 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.* > > No, we don't support globbing in these options. Question to the list- > does it make sense to do so? For those two, yes; we assume more users are likely to have a number of files there. -- GPG/PGP ID: B42DDCAD
Re: [arch-general] pacman.conf: can I use wildcards?
On Wed, Feb 17, 2010 at 8:13 PM, Dan McGee wrote: > On Wed, Feb 17, 2010 at 3:51 PM, clemens fischer > wrote: >> 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.* > > No, we don't support globbing in these options. Question to the list- > does it make sense to do so? I think so. There could be enough files that listing them would be tedious, or it could be that one wants to exclude any future files of a given pattern, even though one doesn't know what they might be called.
Re: [arch-general] EEE 1000H - control of Wifi device
On Wed, Feb 17, 2010 at 05:36:31PM -0600, Aaron Griffin wrote: > Isn't this what rfkill is for? > http://linuxwireless.org/en/users/Documentation/rfkill You're right: /sys/devices/platform/eeepc/rfkill/rfkill0/state controls the wifi device. Problem solved. Thanks ! -- FA O tu, che porte, correndo si ? E guerra e morte !
Re: [arch-general] pacman.conf: can I use wildcards?
On Wed, Feb 17, 2010 at 3:51 PM, clemens fischer wrote: > 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.* No, we don't support globbing in these options. Question to the list- does it make sense to do so? -Dan
Re: [arch-general] EEE 1000H - control of Wifi device
On 02/17/2010 06:03 PM, f...@kokkinizita.net wrote:
>> is it safe to presume you installed acpi-eeepc-generic? because it has
>> a configuration file that let's you customize every key combination.
>
> If that is a package name, no. Everything seems to work
> without it, including e.g. the display brightness keys.
> This is a 1000H which apparently needs less specific
> support.
>
>>> - a way to re-enable the wireless device from a script.
> All they do is to click some desktop icons, one of them
> to select the wireless network. It calls a script using
> netcfg. What I'd want to do is to make that script enable
> the wireless device as well, if it was disabled. Or make
> sure it never get disabled.
ah. apologies for my snappish attitude.
do try acpi-eeepc-generic. the following is from my
/etc/conf.d/acpi-eeepc-generic (on a 1000HE):
# On some models, calling the script can prevent the card from being
re-enabled. If
# you have that problem, just don't call the script and let the BIOS
dis/enable the card.
# See http://code.google.com/p/acpi-eeepc-generic/wiki/Wireless
COMMANDS_WIFI_TOGGLE=("/etc/acpi/eeepc/acpi-eeepc-generic-toggle-wifi.sh")
COMMANDS_WIFI_UP=()
COMMANDS_WIFI_DOWN=()
COMMANDS_WIFI_PRE_UP=()
COMMANDS_WIFI_POST_UP=("/etc/rc.d/wicd start" "@wicd-client")
COMMANDS_WIFI_PRE_DOWN=("pkill wicd-client" "/etc/rc.d/wicd stop" "pkill
wpa_supplicant" "pkill dhcpcd")
COMMANDS_WIFI_POST_DOWN=()
Re: [arch-general] EEE 1000H - control of Wifi device
On Wed, Feb 17, 2010 at 05:40:44PM -0600, kludge wrote: > On 02/17/2010 05:16 PM, f...@kokkinizita.net wrote: > > Today I discovered one possible problem. > > > > The key combination 'Fn + F2' enables or disables the > > wireless network device. If you hit it accidentally there's > > no more wifi. > > that's expected behavior, as indicated by the 'wifi' icon in blue on the > 'f2' key. Yes. > > No big deal for me, but the end users of this machine are > > less technically inclined. So I'm looking for either > > > > - a way to disable the action of this key combination > > (while leaving the other F-keys intact), or > > is it safe to presume you installed acpi-eeepc-generic? because it has > a configuration file that let's you customize every key combination. If that is a package name, no. Everything seems to work without it, including e.g. the display brightness keys. This is a 1000H which apparently needs less specific support. > > - a way to re-enable the wireless device from a script. > > ummm... did you try hitting fn+f2 again? if that didn't work, file a > bug against big-gie's script package. You've been reading too fast :-) As I wrote, hitting Fn+F2 again and then restarting the profile works. I just don't expect my end users to remember that. They get Arch because it enables me to deliver exacly what is required, which turned out to be very problematic with the more bloated distros. All they do is to click some desktop icons, one of them to select the wireless network. It calls a script using netcfg. What I'd want to do is to make that script enable the wireless device as well, if it was disabled. Or make sure it never get disabled. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !
Re: [arch-general] EEE 1000H - control of Wifi device
On Wed, Feb 17, 2010 at 05:36:31PM -0600, Aaron Griffin wrote: > Isn't this what rfkill is for? > http://linuxwireless.org/en/users/Documentation/rfkill There are rfkill entries in /sys I'll try, but AFAIK rfkill is for bluetooth. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !
Re: [arch-general] EEE 1000H - control of Wifi device
On 02/17/2010 05:16 PM, f...@kokkinizita.net wrote: > Today I discovered one possible problem. > > The key combination 'Fn + F2' enables or disables the > wireless network device. If you hit it accidentally there's > no more wifi. that's expected behavior, as indicated by the 'wifi' icon in blue on the 'f2' key. > No big deal for me, but the end users of this machine are > less technically inclined. So I'm looking for either > > - a way to disable the action of this key combination > (while leaving the other F-keys intact), or is it safe to presume you installed acpi-eeepc-generic? because it has a configuration file that let's you customize every key combination. > - a way to re-enable the wireless device from a script. ummm... did you try hitting fn+f2 again? if that didn't work, file a bug against big-gie's script package. a more cutting question might be: why are you saddling end-users who can't figure out the function keys with archlinux? the ubuntu netbook remix runs beautifully on the 1000h. -kludge
Re: [arch-general] EEE 1000H - control of Wifi device
On Wed, Feb 17, 2010 at 5:16 PM, wrote: > Hello all, > > A few days ago I installed Arch on an EEE-1000H. Things > work very well and I'm sort of impressed by how easy it > worked out to be (there were a few hickups but nothing > serious). > > Today I discovered one possible problem. > > The key combination 'Fn + F2' enables or disables the > wireless network device. If you hit it accidentally there's > no more wifi. Using netcfg (I'm using the version from > testing) doesn't bring it back, as the wlan0 device doesn't > exist. The solution is hitting again 'Fn + F2', then netcfg > the wireless profile. > > No big deal for me, but the end users of this machine are > less technically inclined. So I'm looking for either > > - a way to disable the action of this key combination > (while leaving the other F-keys intact), or > > - a way to re-enable the wireless device from a script. > > The trick mentioned on the EEE-901 wiki > > echo 1 > /sys/.../wlan0 > > doesn't work - there's no such file on the 1000H > > Any hints will be appreciated ! Isn't this what rfkill is for? http://linuxwireless.org/en/users/Documentation/rfkill
Re: [arch-general] new libdrm breaks nouveau
On Wed, Feb 17, 2010 at 6:13 PM, Xavier Chantry wrote: > On Thu, Feb 18, 2010 at 12:00 AM, Ray Kohler wrote: >> >> Downgrading libdrm makes X work again. Is this already being worked >> on, or should I open a bug? If so, against which package, libdrm or >> xf86-video-nouveau? >> > > You need to upgrade and rebuild both xf86-video-nouveau and nouveau-drm. > File a bug against these two packages requesting a rebuild bump. Done: http://bugs.archlinux.org/task/18378
[arch-general] EEE 1000H - control of Wifi device
Hello all, A few days ago I installed Arch on an EEE-1000H. Things work very well and I'm sort of impressed by how easy it worked out to be (there were a few hickups but nothing serious). Today I discovered one possible problem. The key combination 'Fn + F2' enables or disables the wireless network device. If you hit it accidentally there's no more wifi. Using netcfg (I'm using the version from testing) doesn't bring it back, as the wlan0 device doesn't exist. The solution is hitting again 'Fn + F2', then netcfg the wireless profile. No big deal for me, but the end users of this machine are less technically inclined. So I'm looking for either - a way to disable the action of this key combination (while leaving the other F-keys intact), or - a way to re-enable the wireless device from a script. The trick mentioned on the EEE-901 wiki echo 1 > /sys/.../wlan0 doesn't work - there's no such file on the 1000H Any hints will be appreciated ! Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !
Re: [arch-general] new libdrm breaks nouveau
On Thu, Feb 18, 2010 at 12:00 AM, Ray Kohler wrote: > > Downgrading libdrm makes X work again. Is this already being worked > on, or should I open a bug? If so, against which package, libdrm or > xf86-video-nouveau? > You need to upgrade and rebuild both xf86-video-nouveau and nouveau-drm. File a bug against these two packages requesting a rebuild bump.
[arch-general] new libdrm breaks nouveau
After upgrading to the just-released libdrm 2.4.18-1 (and the new xorg-server), I can no longer start X: drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci::01:00.0 (EE) [drm] failed to open device (EE) No devices detected. Fatal server error: no screens found I tried rebuilding xf86-video-nouveau against this new libdrm, but it doesn't compile: nouveau_xv.c: In function ‘nouveau_xv_bo_realloc’: nouveau_xv.c:251: error: ‘NOUVEAU_BO_TILED’ undeclared (first use in this function) nouveau_xv.c:251: error: (Each undeclared identifier is reported only once nouveau_xv.c:251: error: for each function it appears in.) make: *** [nouveau_xv.lo] Error 1 make: *** Waiting for unfinished jobs nv_accel_common.c: In function ‘NVAccelInitImageBlit’: nv_accel_common.c:273: error: ‘NV04_IMAGE_BLIT_DMA_NOTIFY’ undeclared (first use in this function) nv_accel_common.c:273: error: (Each undeclared identifier is reported only once nv_accel_common.c:273: error: for each function it appears in.) nv_accel_common.c:275: error: ‘NV04_IMAGE_BLIT_COLOR_KEY’ undeclared (first use in this function) nv_accel_common.c:279: error: ‘NV04_IMAGE_BLIT_CLIP_RECTANGLE’ undeclared (first use in this function) nv_accel_common.c:283: error: ‘NV04_IMAGE_BLIT_OPERATION’ undeclared (first use in this function) nv_accel_common.c:284: error: ‘NV04_IMAGE_BLIT_OPERATION_ROP_AND’ undeclared (first use in this function) nv_accel_common.c: In function ‘NVAccelInitScaledImage’: nv_accel_common.c:327: error: ‘NV04_SCALED_IMAGE_FROM_MEMORY_DMA_NOTIFY’ undeclared (first use in this function) nv_accel_common.c:337: error: ‘NV04_SCALED_IMAGE_FROM_MEMORY_COLOR_CONVERSION’ undeclared (first use in this function) nv_accel_common.c:338: error: ‘NV04_SCALED_IMAGE_FROM_MEMORY_COLOR_CONVERSION_DITHER’ undeclared (first use in this function) nv_accel_common.c:340: error: ‘NV04_SCALED_IMAGE_FROM_MEMORY_OPERATION’ undeclared (first use in this function) nv_accel_common.c:341: error: ‘NV04_SCALED_IMAGE_FROM_MEMORY_OPERATION_SRCCOPY’ undeclared (first use in this function) nv_accel_common.c: In function ‘NVAccelInitImageFromCpu’: nv_accel_common.c:436: error: ‘NV05_IMAGE_FROM_CPU_BETA4’ undeclared (first use in this function) nv_accel_common.c:439: error: ‘NV05_IMAGE_FROM_CPU_SURFACE’ undeclared (first use in this function) make: *** [nv_accel_common.lo] Error 1 Downgrading libdrm makes X work again. Is this already being worked on, or should I open a bug? If so, against which package, libdrm or xf86-video-nouveau?
[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 tex
Re: [arch-general] Kde upgrade ?phonon/qt?
On Wed, 17 Feb 2010 16:28:40 +0100 Michael Schaefer wrote: > On 17.02.2010 10:09, richard terry wrote: > > # pacman -Sy --asdeps qt > > error: failed to prepare transaction (could not satisfy > > dependencies) :: qtscriptgenerator: requires phonon > > pacman -Rd qtscriptgenerator (and possibly amarok) will do the job. > > regards > michael IMO this is better: # pacman -S --asdeps qt phonon
Re: [arch-general] Kde upgrade ?phonon/qt?
On 17.02.2010 10:09, richard terry wrote: > # pacman -Sy --asdeps qt > error: failed to prepare transaction (could not satisfy dependencies) > :: qtscriptgenerator: requires phonon pacman -Rd qtscriptgenerator (and possibly amarok) will do the job. regards michael
Re: [arch-general] Kde upgrade ?phonon/qt?
On 02/17/2010 11:55 AM, Shridhar Daithankar wrote: On Wednesday 17 February 2010 14:39:53 richard terry wrote: # pacman -Sy --asdeps qt :: qtscriptgenerator: requires phonon How about removing qtscriptgenerator before doing this? You can install it after your upgrade is complete. HTH I had to do this yesterday to get the update to proceed, works fine after that (make sure the repo you use is up to date). One thing that bothered me was that the "update" installed all of kde again. Even kdegames, that I removed ages ago. Anyone else also had this? Manne
Re: [arch-general] unit test generator for shared C/C++ library API
Thanks,
PKGBUILD is correct, except for the last line in the "install" section.
I suppose script should be installed without ".pl" suffix:
install $srcdir/$pkgname-$pkgver/api-sanity-autotest.pl
$pkgdir/usr/bin/api-sanity-autotest
Brendan Long wrote:
> I looked at the download to see how hard this would be, and all it is is
> the license (GPL) and a perl script. Does the package just need to copy
> the perl script to /usr/bin? If so, I've attached a PKGBUILD and I can
> upload it to the AUR if it's correct.
>
> On 02/16/2010 10:21 AM, kludge wrote:
>
>> d.i.y: http://wiki.archlinux.org/index.php/Creating_Packages
>>
>> On 02/16/2010 11:03 AM, Andrey Ponomarenko wrote:
>>
>>
>>> Dear colleagues,
>>>
>>> Linux Verification Center at the Institute for System Programming of RAS
>>> and the Linux Foundation have released a free unit test generator for
>>> shared C/C++ library API. It helps to quickly generate simple ("sanity"
>>> or "shallow"-quality) tests for all functions from the library API using
>>> their signatures and data type definitions straight from the library
>>> header files. The quality of generated tests allows to check absence of
>>> critical errors in simple use cases and can be improved by involving of
>>> highly reusable specialized types for the library.
>>>
>>> This tool can execute generated tests and detect all kinds of emitted
>>> signals,
>>> early program exits, program hanging and specified requirement failures.
>>> It can be considered as a tool for low-cost sanity checking of library API
>>> or as a powerful test development framework. Also it supports universal
>>> Template2Code format of tests, random test generation mode and other useful
>>> features. This tool is free software: you can redistribute it and/or modify
>>> it under the terms of the GNU GPLv2.
>>>
>>> We suppose this tool can be very useful for shared library developers
>>> and recommend it for including to Arch Linux.
>>>
>>> For more information, please see:
>>> http://ispras.linux-foundation.org/index.php/API_Sanity_Autotest
>>>
>>> Andrey Ponomarenko
>>> Linux Verification Center at the Institute for System Programming of RAS
>>>
>>>
>>>
>>>
>>
>>
>
>
Re: [arch-general] Kde upgrade ?phonon/qt?
On Wednesday 17 February 2010 14:39:53 richard terry wrote: > > # pacman -Sy --asdeps qt > :: qtscriptgenerator: requires phonon How about removing qtscriptgenerator before doing this? You can install it after your upgrade is complete. HTH -- Regards Shridhar
Re: [arch-general] Kde upgrade ?phonon/qt?
On Wednesday 17 February 2010 16:40:52 you wrote: > On 17/02/10 15:31, richard terry wrote: > > :: phonon conflicts with qt. Remove qt? [Y/n] > > http://www.archlinux.org/news/483/ > Thanks, Yes I did read that before I posted. I can see no mention of this problem in that article, as you see from my post I did exactly as shown below. The phonon conflict come up after I tried to install phonon as the failure seemed to suggest it was needed. Could you explain my error further. thanks. Richard # pacman -Sy --asdeps qt :: Synchronizing package databases... archlinuxfr 24.9K 25.0K/s 00:00:01 [##] 100% core 35.9K 133.0K/s 00:00:00 [##] 100% extra449.0K 157.1K/s 00:00:03 [##] 100% community358.0K 156.8K/s 00:00:02 [##] 100% resolving dependencies... looking for inter-conflicts... error: failed to prepare transaction (could not satisfy dependencies) :: qtscriptgenerator: requires phonon # pacman -S phonon resolving dependencies... warning: provider package was selected (phonon-gstreamer provides phonon- backend) looking for inter-conflicts... :: phonon conflicts with qt. Remove qt? [Y/n]
