Pacman wrapper to allow source builds (srcpac)

This is mostly just something that I did because I had never written a wrapper for pacman before and wanted to see if it worked with the current pacman feature set.
It's 1:30ish in the morning, so my eyes are a little blurry.
The wrapper is called srcpac.  It's version 0.1 at this point
The code is quite ugly because I threw it together in the past 3 hours, but my inital tests have been successes.
Now, for the pitch.  Imagine if you could use pacman to install binary packages as well as build those same packages from source (with your own optimizations).  Not only that, but upgrades remembered which packages were precompiled and which were compiled on the spot.
Now, imagine that pacman didn't actually handle that, because the hard-core KISS people would complain too much and you wouldn't be able to think while you watch gcc output flash by.  Imagine instead a wrapper around pacman that handled it for you.
Enter srcpac.  Lights brighten, music comes to a peak, close up!
srcpac acts exactly the same as pacman (well, it should anyway), except you get this little extra flag -b (or --build) tacked on to -S (--sync) to build from source instead of install from a binary package.
Let's see an example:
srcpac -Sb w3m
will compile w3m, install it, and remember that it was compiled
srcpac -Sybu
will upgrade all the packages that need upgrading by building them and remember that they were compiled (be careful with this one, it will include packages that weren't previously compiled).
srcpac -Syu
will upgrade all binary packages by installing binaries and upgrade all source packages by compiling from source.
srcpac -Qi w3m adds an extra line too, "Source", with a simple yes or no.
Which packages are source and which aren't are stored in /var/lib/srcpac just as files.  If the file exists, then the package was a source package (so it's easy to fix it if srcpac gets confused, also it doesn't touch anything pacman uses).
While I can guarantee that this wrapper won't break your packages (because it uses pacman and makepkg to do all of it's package related stuff), I can't guarantee it'll work 100% correctly (it's 1:45 now!).
If anyone is interested, the script is available here: http://xentac.net/svn/arch-tools/srcpac/tags/0.1/srcpac
Yes, it's in bash.
Feel free to tell me problems you run into using this tool.  Remember, if you use pacman instead of using srcpac, then all the packages will continue installing as binary packages.
BEWARE: the -r option isn't fully implemented and may install to / in some cases, I'm pretty sure I don't ever write to / when -r is specified, but I can't be sure.
.:edit - changed title to show srcpac name - dibble:.

rls wrote:ABS is fine, but unless I am mistaken, it does nothing to ensure the configure and make stages go smoothly. It is a good way to integrate "home-rolled" packages into the Arch system.
hmmmm... I could be wrong because I've never used Gentoo, but if you make a package that doesn't already exist for Gentoo, does it do anything to make sure the compilation goes smoothly?  If the package exists, then there is a way to build the package that has been tested by somebody else. This is how ABS works too; if a PKGBUILD exists, you can be reasonably sure it will work.
I can't imagine a program that can automatically fix or recover from compiler or Makefile errors. If it does, then... wow.
I assume that Gentoo has a larger package base than Arch, but let's not get into that discussiong again!
Xentacs script is basically designed to allow you to choose whether you are going to install from source or binary. Assuming the PKGBUILDS are in order (which for arch repository programs they are, because the binaries were built from them!), this should work as flawlessly as installing from binaries.
Dusty

Similar Messages

  • Screen Saver doesn't allow SOURCE SELECTION but automatically begins to download unknown files. I have to force quit, but it does the same thing each time I try to select a source.

    Screen Saver doesn't allow SOURCE SELECTION but automatically begins to download unknown files. I have to force quit, but it does the same thing each time I try to select a source.

    Do you realize that you're talking to yourself?
    iMac refurb (27-inch Mid 2011), OS X Mavericks (10.9.4), SL & ML, G4 450 MP w/Leopard, 9.2.2

  • [yaourt] Keep sources/build files only for specific AUR packages

    Hi,
    By default, packages are build in BUILDDIR=/tmp/makepkg, which itself usually is a virtual dir in RAM. I generally like this behaviour, so I don't wanna change the BUILDDIR variable to point to a dir on the harddisk, but for a few packages I'd welcome the sources/build dir to be kept, e.g. for *-git packages to reduce build time on consecutive updates. Is there a neat Arch-way to tell the makepkg system to use a different dir (i.e., one on the harddisk) for specific packages? It'd be even greater to be able to use wildcards as well, so I could just enable this option for all *-git packages.
    And as I said, I generally like the idea of building in RAM so the trick to just let BUILDDIR point to a dir on my hdd and put a command in some shutdown-script to delete all but the directories ending in -git wouldn't be perfect
    Cheers
    Last edited by epinephrine (2013-01-27 16:25:17)

    Oh you're right in that BUILDDIR isn't set by default. I use yaourt for building AUR packages, so this is a yaourt related question, oops. I'll ask in the appropriate forum...
    Some packages are only available as git packages, and that for a good reason. Some git repository maintainers follow the good working principle to always have their master branch stable and deployable and do development and testing in respective branches to keep master clean. E.g. I maintain 2 git packages on the AUR, and there are no other "stable" options, also as git makes sense for these packages.
    And sometimes you just need a more up2date version

  • Packer - New bash aur+pacman wrapper (replaces poorly written yaourt)

    There are some people who wish to keep aur and pacman separate. For those people there is aurget and slurpy.
    There are others who wish to integrate them  for certain tasks like myself. For those people there really is only yaourt which is excruciatingly slow and in many ways bloated. For instance, why would you need to use yaourt -R package ever? All that happens when you do that is it calls pacman. What a joke.
    I contend that an aur+pacman wrapper only need to perform 4 major functions.
    1) Search pacman and aur at the same time with one query (-Ss)
    2) Get info from packages in the repository (-Si)
    3) Install packages from either (especially be able to handle the dependencies of aur packages which can sometimes have other dependencies on aur which themselves might have dependencies on aur, etc.) (-S)
    4) Update packages at the same time (again with an interest of handling aur packages which might have new dependencies in newer versions and such) (-Su)
    If you agree with this or just are curious and want to test my program, please download the script from my github and leave feedback. This is a pretty early release (just began working on it 3 days ago), but all four of those functionalities are implemented. There will be cosmetic changes for sure to come and please comment on what you think those should be or any other bugs or problems you might have had.
    github link
    aur link
    packer wiki
    EDIT:
    I have forked pacdiffviewer from yaourt and modified it to work as a stand alone program due to many people saying they coud not switch from yaourt because it has pacdiffviewer. To avoid path conflicts, I have named it pacdiff.
    github link
    aur link
    forum post about pacdiff
    EDIT: Title edited due to gratuitous number of complaints.
    Last edited by bruenig (2010-04-22 02:04:13)

    keenerd wrote:This is fast. And fails even faster if you don't have sudo set up.  The one nice thing about yaourt is that if will check if you can sudo pacman, otherwise it asks for your root password.  I like this behavior.
    I don't understand what you mean. I can run packer as non-root, and when it needs root access it asks me for my password. As far as I can tell, this is the same thing that yaourt does. Are you expecting it to do something else?
    Mikko777 wrote:
    1: yaourt -Syu --aur --devel --noconfirm    (--devel is nice)
    2: on first install edit/ show pkgbuild
    3: yaourt -C  <-- list and edit .pacnew files
    4: vote for packages
    Those are all great ideas. I will add my opinion as another packer user.
    1. I've never used the "--devel" option. Does that mean, it will look for AUR packages that you installed that got the files out of a CVS repository, and download and install the super duper just-updated-at-two-in-the-morning version of it? If that's what it does, then I can imagine that being a nice feature, but it can also be done by doing "packer -S", right? As for "--noconfirm", packer seems pretty unobtrusive to me right now, so I don't really miss that option.
    2. I'm confused. Packer asks me if I want to see the PKGBUILD when I install a package from the AUR. You mean, show the PKGBUILD instead of asking? Or, only show PKGBUILD on the first install?
    3. I personally prefer to do "sudo updatedb && locate pacnew".
    4. I never liked the "vote" feature on yaourt. I think it's confusing. If I just finished installing a package from the AUR, how do I know if I want to vote for it if I haven't used it yet? I prefer to use the program for a while, then use "aurvote".

  • Slow and insecure but feature-rich pacman wrapper in bash

    This project of mine started because I want to compile my packages in a way that lets me delete gnome apps. Here's the problem: I see that evince depends on gnome-keyring, gnome-keyring depends on gconf and alltray depends on gconf. This leads me to think that if I recompile evince to not use gnome-keyring and recompile alltray to not use gconf, I can delete gconf.
    NO!
    I have to recompile evince to not use gconf as well because little do I know from pacman's dependency handling... gconf is a direct (but second level) dependency of evince as it's compiled as well.
    This is a pretty standard problem. It's the reason why debian dependency lists are so damn long. I don't want Arch to move to a system like that... well sort of. Here's what I did. I made a script that acts just like pacman but when you tell it to download and install a package, it tells pacman to only download that package into a separate cache, then it extracts the package, finds all dynamic executables in the package, uses ldd to determine their library dependencies, uses pacman -Qo to find packages that own these dependencies (and caches them in a file so they can be looked up more quickly in the future), applies some other enhancements that should be visible in the script, then adds the new dependencies to the depends array and makes sure that none are duplicated. It also formats the array so that it goes (original clean dependency list) kernel26 (new list). That way it can parse queries as well so -Qi will omit all the dependencies after kernel26 and the Required By section while -Qii shows everything. This is the perfect compromise for me. Not sure if it will be for you.
    Other things it does:
    * Checks if AUR packages need updating (but doesn't update them)
    * Takes out docs and gconf schemas
    * Cleans up man pages so there's no /usr/man and just /usr/share/man/man*
    * Convers /usr/share/man/locale/man1/whatever.1.gz to /usr/share/man/man1/whatever-locale.1.gz
    * Converts info pages to man pages with info2man and puts them in man9
    * Gzips all man pages
    * Allows replacing packages with -U
    * Package specific stuff like disabling the firefox error console.
    Regretably I had to make it play around with the md5sums. This essentially makes them useless but if I don't do this reinstalling a package that is in the main cache because this script put it there fails due to corruption. So you might want to get rid of this "feature" and probably the firefox / uvesafb /gstreamer / info2man stuff but this is cool so tell me what you think of it.
    #!/bin/bash
    function aur_check {
    STARTDIR=`pwd`
    cd /var/cache/pacman
    for r in `pacman -Qmq`; do
    wget "http://aur.archlinux.org/packages/$r/$r/PKGBUILD" >/dev/null 2>&1
    if [ $? -eq 0 ]; then
    LOCAL_VERSION_REL=`'pacman' -Q $r | awk '{print $2}'`
    LOCAL_VERSION=`echo $LOCAL_VERSION_REL| sed -e 's/-.*//g'`
    REMOTE_VERSION=`cat PKGBUILD | grep -E '^pkgver=' | sed -e 's/pkgver=//g' | sed -e 's/[ ]*//g'`
    REMOTE_REL=`cat PKGBUILD | grep -E '^pkgrel=' | sed -e 's/pkgrel=//g'`
    if [[ "$LOCAL_VERSION" < "$REMOTE_VERSION" ]]; then
    printf "warning: $r: ignoring package upgrade ($LOCAL_VERSION_REL => ${REMOTE_VERSION}-${REMOTE_REL})\n"
    fi
    rm PKGBUILD
    fi
    done
    cd $STARTDIR
    function sync_check {
    STARTDIR=`pwd`
    cd /var/cache/pacman
    IGNORED_PACKAGES=`cat /etc/pacman.conf | grep -E '^IgnorePkg' | sed -e 's/IgnorePkg[ ]*=[ ]*//g'`
    for s in $IGNORED_PACKAGES; do
    REMOTE_VERSION_STRING=`'pacman' -Si $s 2>/dev/null | grep -E '^Version'`
    if [ $? -eq 0 ]; then
    REMOTE_VERSION_REL=`echo $REMOTE_VERSION_STRING | awk '{print $3}'`
    LOCAL_VERSION_STRING=`'pacman' -Q $s 2>/dev/null`
    if [ $? -eq 0 ]; then
    LOCAL_VERSION_REL=`echo $LOCAL_VERSION_STRING | awk '{print $2}'`
    printf "warning: $s: ignoring package upgrade ($LOCAL_VERSION_REL => $REMOTE_VERSION_REL)\n"
    fi
    fi
    done
    cd $STARTDIR
    function remove_crap {
    # No docs or schemas.
    rm -rf 2>/dev/null ./usr/share/doc
    rm -rf 2>/dev/null ./usr/share/gtk-doc
    rm -rf 2>/dev/null ./etc/gconf
    # Please delete this file. It is not necessary for linking the library.
    find . -name "*.la" -exec rm {} \;
    # Only one man directory please.
    if [ -d ./usr/man ]; then
    if [ ! -d ./usr/share ]; then
    mkdir ./usr/share
    fi
    mv ./usr/man ./usr/share/man
    fi
    if [ -d ./usr/share/man ]; then
    cd ./usr/share/man
    ls | grep 'cat' | xargs rm -rf
    if [ -d ./man ]; then
    mv ./man/* .
    rm -rf ./man
    fi
    # Imposes what I consider to be a better naming convention for some reason.
    for t in `ls`; do
    if [ $t != 'man0' ] && [ $t != 'man1' ] && [ $t != 'man2' ] && [ $t != 'man3' ] && [ $t != 'man4' ] && [ $t != 'man5' ] && [ $t != 'man6' ] && [ $t != 'man7' ] && [ $t != 'man8' ] && [ $t != 'man9' ] && [ $t != 'mann' ] && [ $t != 'manm' ]; then
    cd $t
    for u in `ls`; do
    cd $u
    for v in `ls`; do
    SECOND_LAST_EXTENSION=`echo $v | sed -e 's/\.gz$//g' | rev | sed -e 's/\..*//g' | rev`
    PREFIX=`echo $v | sed -e 's/\.gz$//g' | sed -e "s/\.${SECOND_LAST_EXTENSION}//g"`
    SUFFIX=`echo $v | sed -e "s/$PREFIX//g"`
    if [ ! -h $v ]; then
    install -D $v ../../${u}/${PREFIX}-${t}${SUFFIX}
    else
    TARGET=`readlink $v`
    TARGET_SECOND_LAST_EXTENSION=`echo $TARGET | sed -e 's/\.gz$//g' | rev | sed -e 's/\..*//g' | rev`
    TARGET_PREFIX=`echo $TARGET | sed -e 's/\.gz$//g' | sed -e "s/\.${TARGET_SECOND_LAST_EXTENSION}//g"`
    TARGET_SUFFIX=`echo $TARGET | sed -e "s/${TARGET_PREFIX}//g"`
    install -d ../../${u}
    ln -s ${TARGET_PREFIX}-${t}${TARGET_SUFFIX} ../../${u}/${PREFIX}-${t}${SUFFIX}
    fi
    done
    cd ..
    done
    cd ..
    rm -rf $t
    fi
    done
    # Now that it is nicely organized we can gzip everything and add symlinks.
    for x in `ls`; do
    cd $x
    for y in `ls`; do
    echo $y | grep -q -E '\.gz$'
    if [ $? -ne 0 ]; then
    gzip $y >/dev/null 2>&1
    SECOND_LAST_EXTENSION=`echo $y | rev | sed -e 's/\..*//g' | rev`
    PREFIX=`echo $y | sed -e "s/\.${SECOND_LAST_EXTENSION}//g"`
    NEW_NAME=`echo $PREFIX | sed -e 's/\./-/g'`
    if [ $NEW_NAME != $PREFIX ]; then
    ln -s ${y}.gz ${NEW_NAME}.${SECOND_LAST_EXTENSION}.gz
    fi
    else
    SECOND_LAST_EXTENSION=`echo $y | sed -e 's/\.gz$//g' | rev | sed -e 's/\..*//g' | rev`
    PREFIX=`echo $y | sed -e 's/\.gz//g' | sed -e "s/\.${SECOND_LAST_EXTENSION}//g"`
    NEW_NAME=`echo $PREFIX | sed -e 's/\./-/g'`
    if [ $NEW_NAME != $PREFIX ]; then
    ln -s ${y} ${NEW_NAME}.${SECOND_LAST_EXTENSION}.gz
    fi
    fi
    done
    cd ..
    done
    cd ../../..
    fi
    # Converts info pages to man pages in the man9 directory
    if [ -d ./usr/share/info ]; then
    if [ -d ./usr/share/man ]; then
    mkdir ./usr/share/man/man9
    else
    mkdir ./usr/share/man
    mkdir ./usr/share/man/man9
    fi
    cd ./usr/share/info
    for z in `ls`; do
    echo $z | grep -q -E '\.gz$'
    if [ $? -eq 0 ]; then
    NAME=`echo $z | sed -e 's/\.gz$//g'`
    NEWNAME=`echo $NAME | sed -e 's/\./-/g'`
    gunzip $z
    info2man $NAME > ../man/man9/${NEWNAME}
    gzip ../man/man9/${NEWNAME} >/dev/null 2>&1
    else
    NEWNAME=`echo $z | sed -e 's/\./-/g'`
    info2man $z > ../man/man9/${NEWNAME}
    gzip ../man/man9/${NEWNAME} >/dev/null 2>&1
    fi
    done
    cd ../../..
    rm -rf ./usr/share/info
    fi
    function install_with_u {
    ULTIMATE_ANSWER="y"
    # Checks if there are package conflicts
    CONFLICTS=`cat .PKGINFO | grep 'conflict = ' | awk '{print $3}'`
    ACTUAL_CONFLICTS=""
    for p in $CONFLICTS; do
    VERSION_CHECK=0
    CONFLICTING_PACKAGE=`echo $p | sed -r 's/(>|=|<).*//g'`
    # Checks if these conflicts actually affect packages on the system
    'pacman' -Q $CONFLICTING_PACKAGE >/dev/null 2>&1
    if [ $? -eq 0 ]; then
    AFFECTED=1
    if [ ${#p} -gt ${#CONFLICTING_PACKAGE} ]; then
    AFFECTED=0
    # If a version is specified, finds it out and sees if we're affected
    CONFLICTING_VERSION_STRING=${p:${#CONFLICTING_PACKAGE}:${#p}-${#CONFLICTING_PACKAGE}}
    RELATION=${CONFLICTING_VERSION_STRING:1:2}
    if [ "$RELATION" = "=" ]; then
    RELATION=${CONFLICTING_VERSION_STRING:0:1}${RELATION}
    CONFLICTING_VERSION=${CONFLICTING_VERSION_STRING:2:${#CONFLICTING_VERSION_STRING}-2}
    else
    RELATION=${CONFLICTING_VERSION_STRING:0:1}
    CONFLICTING_VERSION=${CONFLICTING_VERSION_STRING:1:${#CONFLICTING_VERSION_STRING}-1}
    fi
    ACTUAL_VERSION=`pacman -Q $CONFLICTING_PACKAGE | awk '{print $2}'`
    if [ "$RELATION" = ">" ]; then
    if [[ "$ACTUAL_VERSION" > "$CONFLICTING_VERSION" ]]; then
    AFFECTED=1
    fi
    elif [ "$RELATION" = "<" ]; then
    if [[ "$ACTUAL_VERSION" < "$CONFLICTING_VERSION" ]]; then
    AFFECTED=1
    fi
    elif [ "$RELATION" = ">=" ]; then
    if [ "$ACTUAL_VERSION" >= "$CONFLICTING_VERSION" ]; then
    AFFECTED=1
    fi
    elif [ "$RELATION" = "<=" ]; then
    if [ "$ACTUAL_VERSION" <= "$CONFLICTING_VERSION" ]; then
    AFFECTED=1
    fi
    else
    if [ "$ACTUAL_VERSION" = "$CONFLICTING_VERSION" ]; then
    AFFECTED=1
    fi
    fi
    fi
    if [ $AFFECTED -ne 0 ]; then
    ACTUAL_CONFLICTS="$ACTUAL_CONFLICTS $CONFLICTING_PACKAGE"
    printf ":: ${1} conflicts with ${CONFLICTING_PACKAGE}. Remove ${CONFLICTING_PACKAGE}? [Y/n] "
    read ANSWER
    if [ $ANSWER != "Y" ] && [ $ANSWER != "y" ]; then
    ULTIMATE_ANSWER="n"
    break
    fi
    fi
    fi
    done
    if [ $ULTIMATE_ANSWER = "y" ]; then
    for q in $ACTUAL_CONFLICTS; do
    'pacman' -Rd ${q}
    done
    return 0
    fi
    return 1
    function get_deps {
    PACKAGE_NAME=`cat .PKGINFO | grep 'pkgname = ' | sed -e 's/pkgname = //g'`
    # Does a few package specific things
    if [ $PACKAGE_NAME = "kernel26" ]; then
    ln -s /etc/uvesafb.conf /etc/uvesafb
    elif [ $PACKAGE_NAME = "firefox" ]; then
    cd ./usr/lib
    FIREFOX_DIR=`ls | grep 'firefox'`
    if [ $? -eq 0 ]; then
    cd $FIREFOX_DIR/chrome
    jar -xf ./browser.jar
    rm ./browser.jar
    sed -i -e '/console.xul/s/^/\/\//g' ./content/browser/browser.js
    jar -cf browser.jar content
    rm -r content
    cd ../..
    fi
    cd ../..
    elif [ $PACKAGE_NAME = "gstreamer0.10-good-plugins" ]; then
    rm ./usr/lib/gstreamer0.10/libgstesd.so
    fi
    POSSIBLE_LIBS=`find . -type f | grep -E '(\.so\.|\.so$)'`
    POSSIBLE_BINS=`find . -type f | grep -v 'PKGINFO' | grep -v -E '\/.*\.[a-zA-Z0-9]+$' | grep -v 'LICENSE'`
    POSSIBLE_ELFS="$POSSIBLE_LIBS $POSSIBLE_BINS"
    DEPS=""
    # Makes a list of all the direct dependencies
    for i in $POSSIBLE_ELFS; do
    #echo "SCANNING: $i"
    ldd $i >/dev/null 2>&1
    if [ $? -eq 0 ]; then
    # Caches the shared libraries in a file to make it easier for everything else to look them up
    DIRNAME=`dirname ${i:1:${#i}}`
    echo "$i" | grep -q ".so"
    if [ $? -eq 0 ]; then
    if [ "$DIRNAME" = "/lib" ] || [ "$DIRNAME" = "/usr/lib" ]; then
    grep -q "${i:1:${#i}} $PACKAGE_NAME" /var/cache/pacman/quicklookup
    # If this package's library assigned to this package was not found...
    if [ $? -ne 0 ]; then
    grep -q "${i:1:${#i}}" /var/cache/pacman/quicklookup
    # It may have been assigned to another package so we change that
    if [ $? -eq 0 ]; then
    sed -i -e "/${i:1:${#i}}/d" /var/cache/pacman/quicklookup
    fi
    # Otherwise we just assign it to this package
    echo "${i:1:${#i}} $PACKAGE_NAME" >> /var/cache/pacman/quicklookup
    fi
    fi
    fi
    # Figures out what packages own the library dependencies
    POSSIBLE_DEPS=`ldd $i 2>/dev/null | grep '=> ' | grep -v '=> ' | sed -e 's/.* => //g' | sed -e 's/ (.*//g'`
    for j in $POSSIBLE_DEPS; do
    DIRNAME=`dirname $j`
    if [ "$DIRNAME" = "/lib" ] || [ "$DIRNAME" = "/usr/lib" ]; then
    OWNER=`grep "$j" /var/cache/pacman/quicklookup`
    # The owner of the dep is either already in the quicklookup file
    if [ $? -eq 0 ]; then
    OWNER=`echo $OWNER | awk '{print $2}'`
    DEPS="$DEPS $OWNER"
    else
    # Or it's part of the current package
    BASENAME=`basename $j`
    find . -name ${BASENAME} | grep -q "${BASENAME}"
    if [ $? -eq 0 ]; then
    echo "$j $PACKAGE_NAME" >> /var/cache/pacman/quicklookup
    else
    # Or we figure out its owner with pacman and put it in the quicklookup file
    OWNER=`'pacman' -Qoq $j 2>/dev/null`
    if [ $? -eq 0 ]; then
    echo "$j $OWNER" >> /var/cache/pacman/quicklookup
    DEPS="$DEPS $OWNER"
    fi
    fi
    fi
    fi
    done
    fi
    done
    # Sticks a "kernel26" between the old dependencies and the new dependencies
    CURRENT_DEPS=`cat .PKGINFO | grep -E '^depend = ' | sed -e 's/depend = //g'`
    DEPS="$CURRENT_DEPS kernel26a $DEPS"
    # Puts them into the PKGINFO file so that all depend lines are contiguous
    grep -q -E '^depend = ' .PKGINFO
    if [ $? -eq 0 ]; then
    FIRST_DEPEND_LINE_NUMBER=`grep -n -E '^depend = ' .PKGINFO | head -1 | sed -e 's/:.*//g'`
    LAST_DEPEND_LINE_NUMBER=`grep -n -E '^depend = ' .PKGINFO | tail -1 | sed -e 's/:.*//g'`
    LAST_LINE_NUMBER=`wc -l .PKGINFO | awk '{print $1}'`
    (( DIFFERENCE=$LAST_LINE_NUMBER-$LAST_DEPEND_LINE_NUMBER ))
    cat .PKGINFO | tail -${DIFFERENCE} > .PKGINFO-3
    touch .PKGINFO-2
    (( FIRST_DEPEND_LINE_NUMBER-- ))
    cat .PKGINFO | head -${FIRST_DEPEND_LINE_NUMBER} > .PKGINFO-1
    else
    cp .PKGINFO .PKGINFO-1
    touch .PKGINFO-2
    touch .PKGINFO-3
    fi
    for k in $DEPS; do
    echo "depend = $k" >> .PKGINFO-2
    done
    # This is all so we don't get mesa and mesa=7.5 in the same dep array
    cat .PKGINFO-2 | awk '{print $3}' | sed -r 's/(>=|>|=|<|<=)/ \1/g' > .RAW-DEPS
    cat .RAW-DEPS | awk '{print $1}' > .COL-1
    cat .RAW-DEPS | awk '{print $2}' > .COL-2
    # Got this from sed1line.txt... it removes duplicate lines
    sed -i -n 'G; s/\n/&&/; /^\([ -~]*\n\).*\n\1/d; s/\n//; h; P' .COL-1
    paste --delimiter="" .COL-1 .COL-2 > .RAW-DEPS
    sed -i -e "/${PACKAGE_NAME}/d" .RAW-DEPS
    sed -i -e 's/kernel26a/kernel26/g' .RAW-DEPS
    sed -e 's/^/depend = /g' .RAW-DEPS > .PKGINFO-2
    sed -i -e "/depend =[ ]*$/d" .PKGINFO-2
    cat .PKGINFO-1 .PKGINFO-2 .PKGINFO-3 > .PKGINFO
    rm .PKGINFO-1 .PKGINFO-2 .PKGINFO-3 .RAW-DEPS .COL-1 .COL-2
    function do_install {
    STARTDIR=`pwd`
    cd /var/cache/pacman/tmp
    for l in `ls -tr`; do
    TEMP_DIR=`echo $l | sed -r 's/(-i686|-x86_64|-any|)\.pkg\.tar\.gz//g'`
    # Extracts the package and makes the necessary modifications to it
    mkdir $TEMP_DIR
    mv $l $TEMP_DIR
    cd $TEMP_DIR
    tar -xf $l >/dev/null 2>&1
    rm $l
    remove_crap
    get_deps
    # Retars the package and installs it
    if [ -e .INSTALL ]; then
    tar -cf $l .INSTALL .PKGINFO * >/dev/null 2>&1
    else
    tar -cf $l .PKGINFO * >/dev/null 2>&1
    fi
    # Installs it and puts it in the cache
    install_with_u $l
    if [ $? -eq 0 ]; then
    'pacman' -Udf $l
    else
    mv $l ../../pkg
    cd ..
    rm -r $TEMP_DIR
    break;
    fi
    mv $l ../../pkg
    cd ..
    rm -r $TEMP_DIR
    done
    cd $STARTDIR
    function get_answer {
    read ANSWER
    echo $ANSWER > /var/cache/pacman/answer
    echo $ANSWER
    if [ "$1" = "-Syu" ]; then
    sync_check
    aur_check
    'pacman' --cachedir /var/cache/pacman/tmp -Syuw
    do_install
    elif [ "$1" = "-Su" ]; then
    sync_check
    aur_check
    'pacman' --cachedir /var/cache/pacman/tmp -Suw
    do_install
    elif [ "$1" = "-S" ]; then
    shift
    PACKAGE_ARRAY=""
    # If something we're installing is in the cache... move it to the temporary cache
    for n in $@; do
    if [ ${n:0:1} != "-" ]; then
    NUM_MATCHES=`ls -1 /var/cache/pacman/pkg | grep -E "^${n}-" | wc -l`
    for o in `seq 1 $NUM_MATCHES`; do
    POSSIBLE_MATCH=`ls /var/cache/pacman/pkg | grep -E "^${n}-" -m${o} | tail -1`
    HYPHENS=`echo $POSSIBLE_MATCH | sed -e "s/${n}//g" | grep -o "-" | wc -l`
    if [ $HYPHENS -le 3 ]; then
    mv /var/cache/pacman/pkg/${POSSIBLE_MATCH} /var/cache/pacman/tmp
    # Changes the stored md5sum temporarily - I don't know a better way to do this
    TEMP_DIR=`echo ${POSSIBLE_MATCH} | sed -r 's/(-i686|-x86_64|-any|)\.pkg\.tar\.gz//g'`
    find /var/lib/pacman/sync -name $TEMP_DIR | grep -q $TEMP_DIR
    if [ $? -eq 0 ]; then
    MD5SUM=`md5sum /var/cache/pacman/tmp/${POSSIBLE_MATCH} | awk '{print $1}'`
    REPOS=`find /var/lib/pacman/sync -name $TEMP_DIR | sed -e 's/\// /g' | awk '{print $5}'`
    sed -i '/%MD5SUM%/G' /var/lib/pacman/sync/$REPOS/$TEMP_DIR/desc
    MD5_LINE_NUMBER=`grep -n '%MD5SUM%' /var/lib/pacman/sync/$REPOS/$TEMP_DIR/desc | sed -e 's/:.*//g'`
    (( MD5_LINE_NUMBER++ ))
    sed -i -e "${MD5_LINE_NUMBER}s/.*/${MD5SUM}/" /var/lib/pacman/sync/$REPOS/$TEMP_DIR/desc
    PACKAGE_ARRAY="${PACKAGE_ARRAY} ${REPOS}/${TEMP_DIR}"
    fi
    break;
    fi
    done
    fi
    done
    # Pacman is run and then a function reads a y or an n from stdin and passes it to pacman's stdin
    get_answer | 'pacman' --cachedir /var/cache/pacman/tmp -Sw $@
    # The function also saves it in a file so we know whether to proceed or cancel because pacman was cancelled
    LETTER=`cat /var/cache/pacman/answer`
    if [ "$LETTER" != "y" ] || [ "$LETTER" != "Y" ]; then
    do_install
    else
    # If anything got moved to the temporary cache for this it is sent back to the main one
    FILES_IN_CACHE=`ls /var/cache/pacman/tmp | wc -l`
    if [ $FILES_IN_CACHE -ne 0 ]; then
    mv /var/cache/pacman/tmp/* /var/cache/pacman/pkg
    fi
    fi
    # Changes all the md5sums back
    for w in $PACKAGE_ARRAY; do
    MD5_LINE_NUMBER=`grep -n '%MD5SUM%' /var/lib/pacman/sync/$w/desc | sed -e 's/:.*//g'`
    (( MD5_LINE_NUMBER++ ))
    sed -i -e "${MD5_LINE_NUMBER}d" /var/lib/pacman/sync/$w/desc
    done
    elif [ "$1" = "-U" ]; then
    STARTDIR=`pwd`
    TEMP_DIR=`echo $2 | sed -r 's/(-i686|-x86_64|-any|)\.pkg\.tar\.gz//g'`
    mkdir /var/cache/pacman/$TEMP_DIR
    cp "$2" /var/cache/pacman/$TEMP_DIR
    cd /var/cache/pacman/$TEMP_DIR
    tar -xf $2 >/dev/null 2>&1
    rm $2
    get_deps
    # Retars the package and installs it
    if [ -e .INSTALL ]; then
    tar -cf $2 .INSTALL .PKGINFO * >/dev/null 2>&1
    else
    tar -cf $2 .PKGINFO * >/dev/null 2>&1
    fi
    install_with_u $2
    if [ $? -eq 0 ]; then
    'pacman' -U $2
    fi
    cd ..
    rm -r $TEMP_DIR
    cd $STARTDIR
    elif [ "$1" = "-Qi" ] || [ "$1" = "-Qii" ]; then
    INITIAL_ARG=$1
    shift
    if [ "$INITIAL_ARG" = "-Qi" ]; then
    'pacman' -Qi $@ > /var/cache/pacman/tempquery
    else
    'pacman' -Qii $@ > /var/cache/pacman/tempquery
    fi
    if [ $? -ne 0 ] || [ ! -e /var/cache/pacman/tempquery ]; then
    exit 1
    fi
    # Filters out all deps after kernel26 for a regular query
    # Filters out all deps before kernel26 for a verbose query
    if [ $? -eq 0 ]; then
    START_LINE_NUMBER=`cat /var/cache/pacman/tempquery | grep -n 'Depends On' | sed -e 's/:.*//g'`
    LINE_NUMBER=$START_LINE_NUMBER
    (( LINE_NUMBER=$LINE_NUMBER+1 ))
    cat /var/cache/pacman/tempquery | head -${LINE_NUMBER} | tail -1 | grep ':'>/dev/null 2>&1
    while [ $? -ne 0 ]; do
    (( LINE_NUMBER=$LINE_NUMBER+1 ))
    cat /var/cache/pacman/tempquery | head -${LINE_NUMBER} | tail -1 | grep ':'>/dev/null 2>&1
    done
    (( END_LINE_NUMBER=$LINE_NUMBER-1 ))
    (( DIFFERENCE=$LINE_NUMBER-$START_LINE_NUMBER ))
    OLD_DEP_LIST=`cat /var/cache/pacman/tempquery | head -${END_LINE_NUMBER} | tail -${DIFFERENCE} | sed -e 's/.* : //g' | sed -e 's/ //g'`
    for k in $OLD_DEP_LIST; do
    if [ "$INITIAL_ARG" = "-Qi" ]; then
    if [ "$k" != "kernel26" ]; then
    NEW_DEP_LIST="$NEW_DEP_LIST $k"
    else
    break
    fi
    else
    if [ "$k" != "kernel26" ]; then
    NEW_DEP_LIST="$NEW_DEP_LIST $k"
    fi
    fi
    done
    fi
    # Removes the old deps array and replaces it with the new one
    sed -i -e "${START_LINE_NUMBER},${END_LINE_NUMBER}d" /var/cache/pacman/tempquery
    (( START_LINE_NUMBER=$START_LINE_NUMBER-1 ))
    END_LINE_NUMBER=`wc -l /var/cache/pacman/tempquery | awk '{print $1}'`
    (( DIFFERENCE=$END_LINE_NUMBER-$START_LINE_NUMBER ))
    cat /var/cache/pacman/tempquery | head -${START_LINE_NUMBER} > /var/cache/pacman/tempquery-1
    cat /var/cache/pacman/tempquery | tail -${DIFFERENCE} > /var/cache/pacman/tempquery-3
    CURRENT_LINE=""
    CURRENT_LINE_NUMBER=1
    for m in $NEW_DEP_LIST; do
    if (( ${#CURRENT_LINE}+${#m}+1<=63 )); then
    CURRENT_LINE="$CURRENT_LINE $m"
    else
    if [ $CURRENT_LINE_NUMBER -eq 1 ]; then
    printf "Depends On :$CURRENT_LINE\n" >> /var/cache/pacman/tempquery-2
    else
    printf "\t\t$CURRENT_LINE\n" >> /var/cache/pacman/tempquery-2
    fi
    CURRENT_LINE=" $m"
    CURRENT_LINE_NUMBER=0
    fi
    done
    if [ $CURRENT_LINE_NUMBER -eq 1 ]; then
    printf "Depends On :$CURRENT_LINE\n" >> /var/cache/pacman/tempquery-2
    else
    printf "\t\t$CURRENT_LINE\n" >> /var/cache/pacman/tempquery-2
    fi
    cat /var/cache/pacman/tempquery-1 /var/cache/pacman/tempquery-2 /var/cache/pacman/tempquery-3 > /var/cache/pacman/tempquery
    # Removes the requirements array for a regular query
    if [ "$INITIAL_ARG" = "-Qi" ]; then
    START_LINE_NUMBER=`cat /var/cache/pacman/tempquery | grep -n 'Required By' | sed -e 's/:.*//g'`
    LINE_NUMBER=$START_LINE_NUMBER
    (( LINE_NUMBER=$LINE_NUMBER+1 ))
    cat /var/cache/pacman/tempquery | head -${LINE_NUMBER} | tail -1 | grep ':'>/dev/null 2>&1
    while [ $? -ne 0 ]; do
    (( LINE_NUMBER++ ))
    cat /var/cache/pacman/tempquery | head -${LINE_NUMBER} | tail -1 | grep ':'>/dev/null 2>&1
    done
    (( END_LINE_NUMBER=$LINE_NUMBER-1 ))
    sed -i -e "${START_LINE_NUMBER},${END_LINE_NUMBER}d" /var/cache/pacman/tempquery
    fi
    cat /var/cache/pacman/tempquery
    rm /var/cache/pacman/tempquery /var/cache/pacman/tempquery-1 /var/cache/pacman/tempquery-2 /var/cache/pacman/tempquery-3
    elif [ "$1" = "-Scc" ]; then
    LINE_NUMBER=0
    for z in `cat /var/cache/pacman/quicklookup | awk '{print $1}'`; do
    (( LINE_NUMBER++ ))
    if [ ! -e $z ]; then
    sed -i -e "${LINE_NUMBER}d" /var/cache/pacman/quicklookup
    (( LINE_NUMBER-- ))
    fi
    done
    'pacman' -Scc
    else
    'pacman' $@
    fi
    Last edited by ConnorBehan (2009-09-19 00:42:48)

    rls wrote:ABS is fine, but unless I am mistaken, it does nothing to ensure the configure and make stages go smoothly. It is a good way to integrate "home-rolled" packages into the Arch system.
    hmmmm... I could be wrong because I've never used Gentoo, but if you make a package that doesn't already exist for Gentoo, does it do anything to make sure the compilation goes smoothly?  If the package exists, then there is a way to build the package that has been tested by somebody else. This is how ABS works too; if a PKGBUILD exists, you can be reasonably sure it will work.
    I can't imagine a program that can automatically fix or recover from compiler or Makefile errors. If it does, then... wow.
    I assume that Gentoo has a larger package base than Arch, but let's not get into that discussiong again!
    Xentacs script is basically designed to allow you to choose whether you are going to install from source or binary. Assuming the PKGBUILDS are in order (which for arch repository programs they are, because the binaries were built from them!), this should work as flawlessly as installing from binaries.
    Dusty

  • SaveSyu - a pacman wrapper to savely upgrade your system

    This wrapper will evaluate the "upgrade level" of every packages that could be upgraded.
    The "upgrade level" is defined as follows:
    Assuming version number looks like x.y.z-p. And we consider that:
    x is a major version number, y is a normal version number, and z is a minor version number, and p is a packaging version number.
    If a version number looks like 1-2, we consider 1 is the major.
    And if it looks like 1.2-3, we consider 1 is the major, and 2 is the normal.
    And if it looks like 1.2.3.4-5, we consider 1 is the major, 2.3 is the normal, and 4 is the minor.
    And,
    level 19: packaging change
                 x1=x2 y1=y2 z1=z2, only p1 != p2
    level 25: minor upgrade
                 x1=x2 y1=y2, z1 != z2, but 1 week old
    level 29: minor upgrade
                 x1=x2 y1=y2, z1 != z2
    level 35: normal upgrade
                 x1=x2, y1!=y2, but 2 weeks old
    level 39: normal upgrade
                 x1=x2, y1!=y2
    level 45: major upgrade
                 x1!=x2, but 4 weeks old
    level 49: major upgrade, x1!=x2
    While invoking, you should specify a threshold that you think is save to upgrade, and the wrapper - saveSyu, will invoke pacman to upgrade only those packages under the threshold.
    Here comes...
    #!/bin/bash
    # save upgrade
    # we can create some upgrade policy, for example:
    # the package is one month old, or
    # the package is a "packaging upgrade" (which means "the same
    # software version", different "packaging version"), or
    # the package is a "minor upgrade", x.y.z -> x.y.?
    # the package is not in core (nor extra)
    # function(s)
    # assume version number looks like x.y.z-p
    # others include:
    # x.y.y.z-p
    # x.y-p
    # y-p
    # level 19: packaging change, x1=x2 y1=y2 z1=z2, only p1 != p2
    # level 25: minor upgrade, x1=x2 y1=y2, z1 != z2, but 1 week old
    # level 29: minor upgrade, x1=x2 y1=y2, z1 != z2
    # level 35: normal upgrade, x1=x2, y1!=y2, but 2 weeks old
    # level 39: normal upgrade, x1=x2, y1!=y2
    # level 45: major upgrade, x1!=x2, but 4 weeks old
    # level 49: major upgrade, x1!=x2
    # other criteria including:
    # which repository (not in core, in community, etc.)
    # minor upgrade, but packaging number is not 1 (which means it has been (bug) fixed)
    evaluate_upgrade_level() {
    # init
    ONE_WEEK=$((1 * 7 * 24 * 60 * 60))
    TWO_WEEKS=$((2 * $ONE_WEEK))
    FOUR_WEEKS=$((4 * $ONE_WEEK))
    old_ver=$1
    new_ver=$2
    repo=$3
    date=$(date -d "$4" +%s)
    now=$(date +%s)
    # parse
    old_tmp=${old_ver%-*}
    old_pkg=${old_ver#$old_tmp-}
    old_major=${old_tmp%%.*}
    old_minor=${old_tmp##*.}
    old_normal=${old_tmp#$old_major.}
    old_normal=${old_normal%.$old_minor}
    echo old_ver=$old_ver major=$old_major normal=$old_normal minor=$old_minor pkg=$old_pkg
    new_tmp=${new_ver%-*}
    new_pkg=${new_ver#$new_tmp-}
    new_major=${new_tmp%%.*}
    new_minor=${new_tmp##*.}
    new_normal=${new_tmp#$new_major.}
    new_normal=${new_normal%.$new_minor}
    echo new_ver=$new_ver major=$new_major normal=$new_normal minor=$new_minor pkg=$new_pkg
    age=$(($now - $date))
    echo date=$date now=$now age=$age
    if [ "$old_major" = "$new_major" -a "$old_normal" = "$new_normal" -a "$old_minor" = "$new_minor" ] ; then
    level=19
    elif [ "$old_major" = "$new_major" -a "$old_normal" = "$new_normal" ] ; then
    if [ $age -gt $ONE_WEEK ] ; then
    level=25
    else
    level=29
    fi
    elif [ "$old_major" = "$new_major" ] ; then
    if [ $age -gt $TWO_WEEKS ] ; then
    level=35
    else
    level=39
    fi
    else
    if [ $age -gt $FOUR_WEEKS ] ; then
    level=45
    else
    level=49
    fi
    fi
    echo level=$level
    return $level
    # init
    SUDO=sudo
    PACMAN=pacman
    ARCH=i686
    TMP_FILE=/tmp/$(basename $0).tmp
    if [ 0 -eq $# ] ; then
    echo usage: $0 threshold
    exit 4
    fi
    threshold=$1
    # get upgrade list
    "$SUDO" "$PACMAN" -Syu --print-uris | grep ".pkg.tar.gz$" >"$TMP_FILE"
    targets=""
    # analyse "upgrade level"
    while read uri ; do
    pkg=$(basename "$uri")
    pkg=${pkg%-$ARCH.pkg.tar.gz}
    pkg=${pkg%.pkg.tar.gz}
    name=${pkg%-*-*}
    new_ver=${pkg#$name-}
    old_ver=$("$PACMAN" -Qi "$name" | grep "^Version")
    old_ver=$(echo $old_ver)
    old_ver=${old_ver#Version : }
    repo=$(basename $(dirname $(dirname $(dirname "$uri"))))
    date=$("$PACMAN" -Si "$name" | grep "^Build Date")
    date=$(echo $date)
    date=${date#Build Date : }
    echo name=$name repo=$repo old_ver=$old_ver new_ver=$new_ver date=$date
    evaluate_upgrade_level "$old_ver" "$new_ver" "$repo" "$date"
    level=$?
    if [ $level -lt $threshold ] ; then
    echo save
    targets="$targets $name"
    fi
    echo
    done <"$TMP_FILE"
    # do it!
    echo $targets
    "$SUDO" "$PACMAN" -S $targets
    Last edited by bsdson.tw (2008-11-07 10:14:36)

    nice idea! but i like to live life on the edge
    will be useful for server stuff. will give it a spin when i set up my server with arch

  • License not present.  With the trial version only limited replays are allowed -- Flex builder 4.5 Premium eclipse plugin with SDK 3.5

    Hi ,
    We are using Flex SDK 3.5 and using eclipse to build the war in order to make it automation compatible , Right now we tried with Premium version of Flex Builder 4.5 eclipse plugging to build and make application automation capable. But we are facing issues in terms of license , After deploying the automation compatible build we are getting error message "License not present.  With the trial version only limited replays are allowed".
    Previously we are using Flex Builder 4.0 and everything was working fine .
    Is Flex Builder 4.5 doesn't support SDK 3.5 ?
    Please help .
    Thanks in advance
    Thanks and Regards
    Sunil Kumar

    with trial version (FB basic) you can record/replay only 30
    script lines. You need to buy FB pro license to remove this
    restriction

  • Open source builds on Sol10

    All,
    I am attempting to compile from source several different open source packages (Sudo, SSH, Apache) on systems running Solaris 10 on both the x86-64 and SPARC platforms.
    The prereq. packages from sunfreeware.com are installed (GCC 3.3.1 and GNU Make).
    Each attempt to build a source is resulting in the same error:
    During the execution of ./configure the following notices appear:
    configure: WARNING: signal.h: present but cannot be compiled
    configure: WARNING: signal.h: check for missing prerequisite headers?
    configure: WARNING: signal.h: see the Autoconf documentation
    configure: WARNING: signal.h: section "Present But Cannot Be Compiled"
    configure: WARNING: signal.h: proceeding with the preprocessor's result
    configure: WARNING: signal.h: in the future, the compiler will take precedence
    configure: WARNING: ## ------------------------------------------ ##
    configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ##
    configure: WARNING: ## ------------------------------------------ ##
    Then during the execution of make:
    In file included from /usr/include/sys/wait.h:24,
    from ../include/apr.h:124,
    from apr_cpystrn.c:17:
    /usr/include/sys/siginfo.h:259: error: parse error before "ctid_t"
    /usr/include/sys/siginfo.h:292: error: parse error before '}' token
    /usr/include/sys/siginfo.h:294: error: parse error before '}' token
    /usr/include/sys/siginfo.h:390: error: parse error before "ctid_t"
    /usr/include/sys/siginfo.h:392: error: conflicting types for `__proc'
    /usr/include/sys/siginfo.h:261: error: previous declaration of `__proc'
    /usr/include/sys/siginfo.h:398: error: conflicting types for `__fault'
    /usr/include/sys/siginfo.h:267: error: previous declaration of `__fault'
    /usr/include/sys/siginfo.h:404: error: conflicting types for `__file'
    /usr/include/sys/siginfo.h:273: error: previous declaration of `__file'
    /usr/include/sys/siginfo.h:420: error: conflicting types for `__prof'
    /usr/include/sys/siginfo.h:287: error: previous declaration of `__prof'
    /usr/include/sys/siginfo.h:424: error: conflicting types for `__rctl'
    /usr/include/sys/siginfo.h:291: error: previous declaration of `__rctl'
    /usr/include/sys/siginfo.h:426: error: parse error before '}' token
    /usr/include/sys/siginfo.h:428: error: parse error before '}' token
    /usr/include/sys/siginfo.h:432: error: parse error before "k_siginfo_t"
    /usr/include/sys/siginfo.h:437: error: parse error before '}' token
    In file included from /usr/include/sys/procset.h:24,
    from /usr/include/sys/wait.h:25,
    from ../include/apr.h:124,
    from apr_cpystrn.c:17:
    /usr/include/sys/signal.h:85: error: parse error before "siginfo_t"
    In file included from ../include/apr.h:124,
    from apr_cpystrn.c:17:
    /usr/include/sys/wait.h:86: error: parse error before "siginfo_t"
    In file included from ../include/apr_general.h:33,
    from ../include/apr_pools.h:39,
    from ../include/apr_strings.h:50,
    from apr_cpystrn.c:18:
    /usr/include/signal.h:111: error: parse error before "siginfo_t"
    /usr/include/signal.h:113: error: parse error before "siginfo_t"
    Has anyone encountered similar errors while trying to build from source?
    Thanks in advance for the information.

    All,
    After some additional testing I have found that the GCC 3.4.2 complier and GNU Make packages included in the Solaris 10 companion CD work OK.
    The build problem was related to the GCC 3.3.2 and GNU Make packages from sunfreeware.com.

  • Duplicate member names allowed dimension build

    I have turned on allow duplicate members in a current ASO essbase cube to test how much rework this will require to allow duplicate aliases.  After I switched the property on, I was recieving errors when attempting to associate an attribute to a dimension through a dimension build rule.  I realized that I needed to use qualified member names in the load file.  Here is an example of the file in Parent  Child  AttributeValue format
    [Domestic-PD].[Test_Comm-PD]     [Test_Comm-PD].[0001-PD]      [Test_Attr-MD].[Test1-MD]
    So I want to associate the attribue Test1-MD to product 0001-PD below.
    Domestic-PD
         Test_Comm-PD
              0001-PD
    What ends up happening is something like this
    Domestic-PD
         Test_Comm-PD
              0001-PD( [Test_Attr-MD].[Test1-MD]
              [Test_Comm-PD].[0001-PD]
    It attaches the attribute to the correct product but then adds an additional member.  I don't want it to add the additional member.  Any idea on what is happening?
    Thanks for any help!

    It ended up working in a different format.  I changed the data file to like below.  I also started over, recopying the outline, turning duplicate members on, so it is possible that there was just something off with the outline earlier.
    Test_Comm-PD     0001-PD      [Test_Attr-MD].[Test1-MD]
    It probably will have issues if there is a duplicate member but luckily I only will have duplicate aliases.

  • Merging R3D and Audio Doesn't Allow Source Settings Change

    Found a major issue in Premiere Pro CC that has put us behind a few days:
    If you select a .Wav audio file and then a red media r3d clip and merge clips, the merged file LOSES the ability to alter source settings, even if unlinked in the sequence.
    If you select the r3d clip file FIRST and THEN the .wav file and merge clips, the merged file works just fine, and source settings can be adjusted.
    I wish I knew that before merging hundreds of clips.
    Can you fix this one, Adobe?

    All the files I am merging are already WAV files, so I don't think that is a workaround.  Although it sounds like it seems to be working for you at the moment.  I worked with a support guy and tried ever conceivable troubleshooting option and we both came to the conclusion that it has nothing to do with the project file, etc. and it is definitely a bug in the software itself.  The question is, what is causing it?  Here are a few things I noticed:
    1. I have a WAV file and R3D file that was merged in my MAIN project, which I cannot access Source Settings on.  (about 3/4 of my merged files allow me to access the Source Settings)
    2. I tried taking these 2 original files (WAV and R3D) into a  new project.  I merged the files. I could not access the Source Settings on the merged file.  This was a brand new project. (I also tried all of this after removing all cache, temp, etc. files that Adobe has you clear out.  Still no luck)
    3. You would think that points to the files themselves.  However, then I went back to my MAIN project.  I still could not access the Source Settings on the originally merged file, but...I imported the WAV and R3D file again and merged them again.  This time I could access the Source Settings on the newly merged file, but still not the original.
    This is just a few of the tests, but this doesn't point to a Project File issue or an individual file issue.  It truly seems to be a random issue that is most likely linked to the program itself.
    This is a major issue for those of us working at this level.  Please address this issue immediately, Adobe.  Hopefully it is something that can be fixed and will not force us to re-merge files.  Thanks! 
    I'm still waiting for a response from Adobe as it was supposedly escalated.

  • Why does Muse not allow a .build domain in their contact us widget?

    The contact us widget does not allow me to use a .build domain. I am in the architecture and construction industry and use a .build domain for our website and emails. I hope this will be fixed soon.

    Working on it. Should be addressed in the next major update.

  • [GIVEAWAY] pacman-wrapper shell functions

    Hi all,
    under http://pastebin.com/vikWUQiK you can find a set of pacman command wrappers that I have found out to be usefull to me.
    I want to share and give other users the opportunity to benefit from it aswell as receiving some critics, ideas, comments and suggestions for improvement.
    Brief description:
    - upgrade only packages wanted by YOU with pacman-upgrade-explicit, else pacman-upgrade-all for system-wide upgrade (deps aswell)
    - all atomic actions log the installed packages, before and after the action (good for debugging, sometimes pkg-names change, etc.)
    - support for multithreaded and concurrent distfiles retrieval (requires aria2c to be installed, else wget is used by default)
    These are things that I (almost always) want to do when using pacman and upgrading packages, so I decided to work with these wrapper functions whenever applicable instead with the (real/backend) pacman.
    This is pretty much it for the beginning.
    Enjoy & Bye,
    Archytect.
    UPDATE 1:
        date: Wed, Oct 12, 2011 11:42:33 AM CEST
        url: http://pastebin.com/A2tQaJgF
        changes/notes:
    added *-preview functions for installs and upgrades
    fixed pacman-fetch not being executed in xargs, because it is a function
    Last edited by Archytect (2011-10-12 09:45:15)

    keenerd wrote:This is fast. And fails even faster if you don't have sudo set up.  The one nice thing about yaourt is that if will check if you can sudo pacman, otherwise it asks for your root password.  I like this behavior.
    I don't understand what you mean. I can run packer as non-root, and when it needs root access it asks me for my password. As far as I can tell, this is the same thing that yaourt does. Are you expecting it to do something else?
    Mikko777 wrote:
    1: yaourt -Syu --aur --devel --noconfirm    (--devel is nice)
    2: on first install edit/ show pkgbuild
    3: yaourt -C  <-- list and edit .pacnew files
    4: vote for packages
    Those are all great ideas. I will add my opinion as another packer user.
    1. I've never used the "--devel" option. Does that mean, it will look for AUR packages that you installed that got the files out of a CVS repository, and download and install the super duper just-updated-at-two-in-the-morning version of it? If that's what it does, then I can imagine that being a nice feature, but it can also be done by doing "packer -S", right? As for "--noconfirm", packer seems pretty unobtrusive to me right now, so I don't really miss that option.
    2. I'm confused. Packer asks me if I want to see the PKGBUILD when I install a package from the AUR. You mean, show the PKGBUILD instead of asking? Or, only show PKGBUILD on the first install?
    3. I personally prefer to do "sudo updatedb && locate pacnew".
    4. I never liked the "vote" feature on yaourt. I think it's confusing. If I just finished installing a package from the AUR, how do I know if I want to vote for it if I haven't used it yet? I prefer to use the program for a while, then use "aurvote".

  • New open-source build tool for CS Extensions

    I just released a new open-source tool for creating, compiling, debugging, packaging, and deploying extensions:
    https://github.com/creativemarket/csxs
    At a Glance:
    All project settings live in a single JSON file (not multiple XML files).
    Compiles CS5 & CS6 versions and packages them as a single ZXP. This is useful for supporting "DarkNormal" and "DarkHover" icons without ditching CS5 compatibility on your extension. It also supports other / more complicated configurations.
    Created projects contain boilerplate for re-skinning on UI change along with fixes for platform bugs.
    Generates aggregated changelogs.
    Automated deploys to S3.
    Automated git version tagging.
    Conditional compilation variables (CONFIG::debug, CONFIG::release, CONFIG::version).
    Usage:
    csxs create
    csxs debug --cs-product=photoshop --cs-version=5.5
    csxs package
    csxs deploy
    I'd love feedback, suggestions, forks, bug reports, etc!
    p.s. I really hope this doesn't come across as spammy—I mean it with the best intentions. I think it could be useful for some out there. More tools for the CS ecosystem is a win for all.
    "We encourage you to contribute content, answer questions, or comment with corrections, clarifications, tips, and more. Links to your favorite resources or expert videos could help other community members."
    http://forums.adobe.com/docs/DOC-2325

    Great tool, thanks a lot for sharing it.
    Installed it and built "Hello, world" extension, now trying to convert my existing extension project for this. Packaging CS5 / CS6 versions alone is priceless.
    Maybe a dumb question, but is it possible to switch .json and output name in command line? I have extension with 5 different versions, they have different licenses etc., so it would be great to type
    csxs package config1.json extension1.zxp
    csxs package config2.json extension2.zxp
    and so on? I'd put it all into one .sh script
    sorry if it's all already available and I just missed this part in documentation

  • BlazeDS locking $ProjectName-debug folder and not allowing flex builder to build project

    Hi all,
    Im new to Flex. I'm trying to setup my development environment. What I've noticed is that when blazeds is started and I run a flex project, it creates a folder in the blazeds root folder named $ProjectName-debug (replace $ProjectName with the actual project name). Once this folder is created, and the flash page is accessed, it cannot be deleted until blazeds is actually stopped. The files on that folder seem to be locked. While this folder is locked, eclipse cannot seem to re-build the project (specifically clean). Thus every small change I make to the project, I'm currently having to stop blazeds, clean the flex project, start blazeds, run the flex project.What makes things worse is that I have to start our application along with blazeds so it can retrieve the data from the app (which takes a few minutes).
    I'm wondering if other people are having to go through this pain or if they've figured out a way to get around this. I would ideally like to have a way where I'm able to rebuild the project and hit f5 and reload the page and see the changes. I understand this is not possible with debug.
    If anyone has figured out a way to incorporate blazeds to their development environment in a more practical way, please let me know. We just switched from tapestry/gwt to flex. We used to be able to update on the go thus development was much simpler.
    Regards,
    Udam

    if you see a red error in your "problems" tab inside
    flexbuilder, your project most likely will not be built fully, or
    correctly, in that case running that project does not makes sense
    at all, you need to make sure "problems" tab is clear of errors
    (you might see warnings, but they are not very harmful) .if ther is
    no errors, hitting ctrl+B builds the project and choosing Project
    --> Clean ... clears output folder and rebuilds the project P.S
    Unless you uncheck checkbox that says "automatically build project
    after clean".
    IMHO, turn off Auto Build and manualy build the project that
    will take care of most issues, plus use (project --> clean) when
    you need to make sure you have latest build .
    Kind Regards
    Levan.

  • WCF RIA wrapper for SOAP service that is compatible with Lightswitch Data Source

    I have a WCF RIA wrapper around a SOAP service and all the simple entities work just fine. Unfortunately Lightswitch does not like my represenation of complex entities like SalesInvoice that contains a list of SalesInvoiceLines. How should I represent
    such an entity in RIA so that Lightswitch can accept it? Do I use the AssociationAttribute? If so what format? What type of collection/list/entityset should the SalesInvoiceLines be? An Example would be very useful.

    HI,
    Welcome to Lightswitch forum.
    According to your description above, I researched this issue, I found that while both OData and RIA Services support complex types on entities, due to scheduling constraints LightSwitch will not. 
    If a complex type property is exposed on an entity, LightSwitch will import the entity, ignoring that property. Further information:
    How to create a RIA service wrapper for OData Source
    Please let me know if there is anything that I can do to help.
    Best regards,
    Angie
    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click
    HERE to participate the survey.

Maybe you are looking for