AUR Package Maintainer

Hi Everyone!
I got into Arch recently just after Ubuntu 9.10 was released and I'm lovin it! I want to give back to the community, but not being a programmer, my options are kinda limited... So i figure that maybe I can become a package maintainer in the AUR? But I don't know what I am supposed to do, so I'm kinda wary as I dont want to end up doing anything stupid >.>
So what exactly is required of a package maintainer? What will I have to do? I couldn't really find anything from google and the article in the wiki is... well... pointless
I'm enlisting in the USAF next year so I dont know how long i'll be able to do it for but I'm gonna try and give what I can while I can!
Thanks!

The maintainer keeps the package up-to-date and provides support for people who can't build the package for whatever reason. So basically, if I whine to you that your stuff doesn't work on my computer, you'll have to do what it takes to make it run. That's rarely a problem, though, because people give helpful comments and sometimes provide updated PKGBUILDS by themselves.
Also, when you don't have time for a package anymore, you can always orphan it (so it is without a maintainer again). It's not too much work if you have just one to maintain, so just go ahead.
Edit: Hm... After a rant like that, I should probably adopt a package as well...
Last edited by Runiq (2009-11-27 15:20:36)

Similar Messages

AUR package maintainer guide?

Sorry for noob question, but I can't seem to find any guidelines on that here.
I adopted a package; it's not broken, but I am poking around, trying to figure out how to post an update when needed. I can't figure out how to do that!

tomk wrote:
How exactly did you try to figure it out?
Did you maybe go to the wiki, find the "AUR User Guidelines" page, go to section 6.2 "Maintaining packages", and read the first line?
AUR User Guidelines wrote:If you maintain a package and want to update the PKGBUILD for your package just resubmit it.
I guess not...
I did mention I'm a noob, didn't I?..

Aur packages should be maintained by multiple user

just like wiki............
the reason you can think out.

As Allan said, you don't want this. There are plenty of messy AUR packages already - you don't want to make that worse .
Useless topic > lock.

AUR package interface - sort criteria out of action

The "search by" field on the main AUR package list (http://aur.archlinux.org/packages.php) now only contains name and maintainer. There used to be at least 5 options, one of which was the ability to search by age. Searches in reverse order are also no longer possible.
Problem exists regardless of logged in status.
Can this be corrected please.

Snowman wrote:
tomk wrote:
Probably something to do with this.
Post it on Flyspray.
No. It's due to an AUR update: http://www.archlinux.org/blog/2005/10/21/aur-127/
You need to click on the column headers to sort.
So how are we supposed to sort by age? It seems like that's the only really important sorting need, to see the latest packages in aur (aside from the 10 listed on the front page).

New binutils 2.22 causing havoc on many AUR packages

Many posts around here showing that this is a common problem. ld has changed behaviour and has broken some packages that don't explicitly link to libraries.
My example: Minutor
gcc -Wl,--as-needed -o minutor minutor.o mapviewer.o colorschemes.o `pkg-config --libs gtk+-2.0` MinutorMap/MinutorMap.a
/usr/bin/ld: MinutorMap/MinutorMap.a(nbt.o): undefined reference to symbol 'gzopen'
/usr/bin/ld: note: 'gzopen' is defined in DSO /usr/lib/libz.so.1 so try adding it to the linker command line
/usr/lib/libz.so.1: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make: *** [minutor] Error 1
Related info I found on the Fedora Wiki
All posts so far suggest adding things to LDFLAGS but none of them have worked for me yet. Found on thread "EMC2 Simulator (CNC) PKGBUILD":
falconindy wrote:
--as-needed isn't the problem here, it's transitive linking. See the first item in the ld changelog for binutils 2.22. There's two options:
- add "-Wl,--copy-dt-needed-entries" to LDFLAGS
- add "-lXt" to LDFLAGS
Either way, this should be fixed upstream. You should explicitly link against any library you depend on.
This didn't work for me whether I put it in the PKGBUILD or /etc/makepkg.conf
Any ideas?
EDIT: It appears that the LDFLAGS are not being added to the gcc line shown above no matter where I put the additional LDFLAGS. Perhaps I'm doing it wrong.
Last edited by quantumphaze (2012-02-08 07:32:11)

ngoonee wrote:P.S. - OT - I've got 99 AUR packages installed and this problem doesn't show up on any of them, so I'm not sure what 'common' means in your case
I maintain one package in AUR and it hit this issue. From this I extrapolate that every AUR package is broken
Anyway, patch for minutor:
--- minutor.orig/Makefile 2011-05-21 08:34:22.000000000 +0200
+++ minutor/Makefile 2012-02-08 11:15:13.682083948 +0100
@@ -16,7 +16,7 @@
all: $(EXEC)
$(EXEC): $(OBJS) maplib
- $(CC) -Wl,--as-needed -o $(EXEC) $(OBJS) $(LIBS) MinutorMap/MinutorMap.a
+ $(CC) -Wl,--as-needed -o $(EXEC) $(OBJS) $(LIBS) MinutorMap/MinutorMap.a -lz
install: $(EXEC)
install -d $(BIN) $(DESKTOP) $(PIXMAP)
Last edited by Gusar (2012-02-08 10:14:44)

How to inspect AUR package PKBUILD and .install files

Hi,
Linux and arch newbie here. I was reading the wiki article about the AUR and noticed this bit:
Warning: Carefully check all files. cd to the newly created directory and carefully check the PKGBUILD and any .install file for malicious commands. PKGBUILDs are bash scripts containing functions to be executed by makepkg: these functions can contain any valid commands or Bash syntax, so it is totally possible for a PKGBUILD to contain dangerous commands through malice or ignorance on the part of the author. Since makepkg uses fakeroot (and should never be run as root), there is some level of protection but you should never count on it. If in doubt, do not build the package and seek advice on the forums or mailing list.
This is something that have not been doing at all in the past, but I am trying to improve my practices managing my system.
The problem is, I do not know what exactly I am looking at or for in these files. If I give these files a look over before installing the package, can I honestly expect to spot something malicious? What would I need to learn to notice if something was fishy?
Anyway, I am not to worried about this practically, because I only use a handful of AUR packages and I usually install ones based on recommendations, not just at random. But it still seemed interesting for the wiki to stress this so strongly. How important is this guidline anyway?
Thanks!
[EDIT: spelling]
Last edited by supernerd (2014-06-25 10:41:13)

I scan the whole PKGBUILD. I start by ensuring that the source link to the original source looks accurate. For example, take the source line for gmusicbrowser-git:
source=("${pkgname}::git+http://github.com/squentin/gmusicbrowser.git")
I know this is the correct link to the source, and so it passes my check. But suppose it had said:
source=("${pkgname}::git+http://youvebeenhackedhub.com/1337haxorz/gmusicbrowser.git")
I would become suspicious. Of course this is an exaggeration, but common sense goes a long ways here. At least check the first time..
With the source verified, I ensure that the md5sum or sha256sum block has a sum. This way, if a download is compromised at the source, the sha256 or md5sum can catch it before you installed (this assumes that the PKGBUILD is not "bad" and has the sum number of a package that wasnt compromised). Note that with git this isnt necessary (the git process protects against such problems). Anytime a tarball is downloaded and extracted however, the sums should be present in the PKGBUILD. If I go to install an AUR package that has 'SKIP' for the md5sum/sha256sum block, I will double or triple check the source of the tarball (or of the patch files enclosed in the build directory, etc..)
I also look for any "dangerous" commands in the build and install sections. For example, if I see "rm -rf" I had better see something like $pkgdir to start the directory path or be VERY sure the path is "safe". Since makepkg is not run as root this should theoretically not be a problem, but imagine if someone put "rm -rf /home/*" (warning: do not run that command on your system!) in there! This is mostly common sense; in time as you get more comfortable with bash and various linux commands it will make more and more sense and you will be able to spot mistakes.
Also, consider the user posting the pkgbuild. "Trusted Users" are selected as trustworthy members of the community, so obviously you can feel much more comfortable with PKGBUILDS they have made (Xyne comes to mind..). For people you may not know, check what other PKGBUILDs they have available. After awhile, you develop a trust for certain people whos PKGBUILDs or software you have used. For example, I wouldnt hesitate to build/install using a PKGBUILD put up by BurntSushi since I use some of his software, have personally corresponded with him, and find him to be responsible. You might "develop" such rapport with other AUR users I dont even know about.
Consider the vote count of a package as an approximate metric. Dont discount a package because it has 0 votes- it may just be that not many people have use for that particular software. Ive considered hosting a PKGBUILD for "xfce4-terminal-nowindowhints"; consider that tilers generally ignore them anyway, and that my package would only be useful for someone literally using xfce4-terminal with pytyle. How high do you think the vote count would be (even if the PKGBUILD had 0 errors)? On the other hand, you at least have a good chance the PKGBUILD is solid if the package has 354 people voting for it.. That said, the package could have been well-maintained before (when it received a ton of votes), and the quality has dropped since- just be mindful of these trends.
Finally, adding all of these things together will leave the odds of a malicious PKGBUILD affecting your system pretty slim, though its certainly not impossible. I have never (to my knowledge to be fair) encountered a malicious PKGBUILD, though I have found a few that had errors or outdated sources, etc.
Last edited by GSF1200S (2014-06-29 10:13:50)

Developer Opening: Package Maintainer

Hey guys.
It's time to get a couple more maintainers on the dev team. Eric Johnson (farphel) is leaving, so we'll need some people to pick up his packages. There are also quite a few orphan packages that need some love.
http://www.archlinux.org/jobs/maintainer.html
If you're interested and you've got the goods, lemme know. Preference will be given to long-standing community members and people that have proven they can get things done.
Thanks!

If "package maintainer" wouldn't imply "Arch dev" but simply what it says then the problem is sort of gone. Assuming that packages follow Arch guidelines and don't have a big influence like e.g. the rc scripts and init. But enough about this.
Voting for quality of packages is good, but it won't really help a lot because it isn't organized. The exact purpose of the current vote system is already vague, let alone the confusion of the new one. It also doesn't help to verify that the binary package is alright (build with the given pkgbuild), nor does it help getting an AUR repo with safe packages. But if done right it could work I suppose, though the chance that AUR is polluted with comments about the security aspect of a package instead of about the package itself is high. I expect communication between the auditors more suited for a dedicated mailinglist.
We'll always need different repo's, as one repo can't fulfil all functionality. More or less what there's now and could be:
1) official repo's: can be trusted and expected high quality.
2) TUR/community: same as official, but made by other people.
3) AUR: high chance of being safe, but no quality guarantees other than that it builds and installs.
4) bare binaries from the AUR site: use at your own risk.
EDIT:
I fixed the url in your post Dusty, if you don't mind. Also, this voting system is good to have independend of the active auditing thing, and should go both ways: you should be able to vote that a package is alright, but one vote that it isn't should invalidate the whole package, so to speak, until the matter is resolved. Now only what's missing is that all packages with a certain goodness score are automatically build and added to an AUR repo which people can use (say 5 positive votes and none negative). Also if a new version is uploaded then the whole process needs to start again; perhaps if only the versions changed it could be automated so that it isn't needed. In most other cases it should.

[SOLVED] What are Git-type AUR packages?

I read the ArchWiki Entry on Git, but I still don't really understand what it is in terms of Aur packages.
I've seen this a couple of times, where there's a second git version of a package in AUR. For example, when I type 'prey' into Yaourt, I get a couple of results, among them:
3 aur/prey-git 20100424-1 (5)
Prey is a lightweight application that will help you track and find your laptop if it ever gets stolen.
4 aur/prey-tracker 0.6.0-1 (100)
Remote tracking and monitoring application for laptops, smartphones, and other electronic devices
Either would install Prey on my computer, right? What are the differences and/or benefits of either?
Last edited by Winston-Wolfe (2013-06-06 11:11:27)

https://aur.archlinux.org/
Statistics
Packages 42851
Orphan Packages 9729
Packages added in the past 7 days 126
Packages updated in the past 7 days 1052
Packages updated in the past year 17219
Packages never updated 10679
Registered Users 46348
Trusted Users 34
x33a wrote:As someone mentioned on the forums recently, people should at least abandon the packages so others can take over.
You can always e-mail the maintainer and if you don't get a response in two weeks, ask on the AUR ML to take that package over.
In the meantime you can post a link to the updated PKGBUILD etc. in comments on the AUR page of that package.
As with my posts, quantity != quality ;P

[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

Did I install the AUR packages correctly and safely ?

Hello
I'm interested in several packages in AUR, but to be honest, it's the first time that I install an AUR pkg without using the yaourt frontend.
I just installed archey, I tried to follow the wiki but I would like to know if I followed all the steps correctly or not...
I've done:
sudo pacman -S fakeroot
wget http://aur.archlinux.org/packages/archey/archey.tar.gz
wget http://aur.archlinux.org/packages/archey/archey/PKGBUILD
makepkg -s
[makepkg -s installed git, and perl-error through pacman I supposed]
sudo pacman -U archey-20100704-1-x86_64.pkg.tar.xz
My questions are:
1] I've done "sudo pacman -U archey-20100704-1-x86_64.pkg.tar.xz" but the wiki said "$ pacman -U /path/to/pkg.tar.gz" => because the prompt said something like "only root can perform this action" when I was not using sudo
2] After the installation, I've done "pacman -Qdt" and it appeared that git, and perl-error were not longer used, so I removed them => Is it a mistake ?
3] How can I update the AUR packages when a newer version will be released ?
Sorry for my english, and thank you for helping me understanding
Last edited by Lowra (2010-07-04 11:34:03)

Lowra wrote:
Thank you Allan:
"3) there are many helpers to keep AUR packages up to date. See the wiki." => Sorry that was not that I wanted to say, I hope I will do this things in the future, but I have not enough experience for that now ^^
In fact, I wanted to say: How can I update the packages installed in my computer from AUR (example: archey) when the maintainer will update his program ?
Thanks again, it's nice to learn news things about Arch, AUR, and Linux ^^
Read what Allan said again.
You want an AUR helper, like packer, clyde or bauerbill, for example. ;)

[SOLVED]Weird conflict with official packages and aur packages

Hi. I have enchant-zemberek installed on my system. It is my package that i'm maintaining at AUR. Yesterday i tried to install poedit which depends on enchant. Weirdly altoguh enchant-zemberek provides enchant; pacman tried to remove enchant-zemberek and instead install enchant. Otherwise it won't let me install poedit. I have updated enchant-zemberek PKGBUILD and pacman let me install poedit without forcing me to install enchant. Here is what i have in my first PKGBUILD before update:
replaces=("enchant")
provides=("enchant")
conflicts=('enchant')
And after updating;
replaces=("enchant=${pkgver}")
provides=("enchant=${pkgver}")
conflicts=('enchant')
Now, i'm wondering while an AUR package have different package name than the official one why pacman tries to replace it? Why PKGBUILD needs package version in provides tag? Say, if i want to keep my own my-abc-1.0-1.i686.pkg.tar.xz but official package abc-1.1-1.i686.pkg.tar.xz released; must i keep my package only in Ignores array? Should i report this as a bug?
Last edited by tarakbumba (2011-04-07 09:52:41)

No, its not a bug. poedit depends on gtkspell which depends on enchant>=1.5.0 - your original custom enchant package did not provide any specific version of enchant, so pacman pulled in the repo package instead to satisfy the versioned dependency. As you have built your package with replaces=enchant, pacman also honours that.

Rewrite of aur package tor-browser-en

Hi,
some months ago I packaged tor-browser-en [1] and, until now, just bumped the package version. Today I tried to rewrite it's PKGBUILD and wrapper script to increase security. I want tor-browser to be installed in ~/ instead of /opt (where it's installed currently). I do not want tor-browser to store it's data and temporary files somewhere else than my encrypted home directory.
To clarify: tor-browser's files need to be owned by the user running it, otherwise it won't work. Adjusting permissions for group-writing did not work.
I borrowed the wrapper script from the jdownloader package and customized it to fit tor-browser's needs. There are still some issues and I'm still trying to get automatic signature checking to work (especially automatic key fetching).
Did I miss anything? Is there anything absolutely wrong? Please, if possible, test and tell me what you found:
http://khg-08.de/max/tor-browser-en-2.2 … src.tar.gz
Just the wrapper script on pastebin: http://pastebin.com/HMEBJua1
[1] https://aur.archlinux.org/packages.php?ID=53169 (old version)
Last edited by Maxr (2012-03-10 21:23:28)

Maxr wrote:That's what the wrapper script does. It will download the source archive and copy its contents to ~/... upon first call. The aur package contains the wrapper script, desktop entry & icon, etc. Until now, tor-brower is installed to /opt/tor-browser and has to be chmodded to USER:USER by a non-root user afterwards. It's only usable for this single user. I don't like both ways ... not really sure what's better, yet.
As long as nothing gets copied into a user's home directory before that user has run a script, that's fine.
Maxr wrote:Correct me if I'm wrong, but isn't there any other way than fetching the public key from a public keyserver to check the signature? Surely, comparing fingerprints would be good, but I think most users won't do this. Automatic checking would at least ensure technical integrity of the archive, just to replace md5/shaX which would be more complex to maintain. But I'll think about it, maybe that should be solved differently.
Usually public keys are made available in several places so that the user can compare different sources to establish (probable) authenticity. My only point is that it should be left up to the user to accept the key. In a worst-case scenario, maybe the user can't trust his own connection and will have to rely on confirmation through other sources, such as calling a friend to have him check on a completely independent connection. Sure, this is unlikely to come up in most cases, but if the whole point of this is rigorous security, you may as well be rigorous.
This is mostly a devil's advocate argument. A user who really needs that level of security will either know enough to check it independently, or will eventually get caught through some other mistake anyway.

[SOLVED] How to set the packager name for an AUR package?

Hi,
I'm maintaining an AUR package (fspcc), but I don't know how to set the name of the "packager" for that package.
E.g. when you request info about some package
$ pacman -Qi somepkg
there is a line
Packager: Unknown Packager
that specifies the packager.
How do I set this "Packager" info so that any user installing my package will see what I want?
Last edited by lisztinf (2014-04-13 13:39:43)

Thanks for the answer.
I guess that when I run
$ makepkg
in my local build directory, then "mkpkg" will build a package with the "Packager" info set accordingly to my local makepkg.conf.
However, I would like another user - with his own makepkg.conf - to see what I want when installing the package. How can I achieve this?
If I install an official package - say pacman itself - through ABS, I see the "Packager" field properly set for that official package. But certainly this info doesn't come from my local makepkg.conf. I would like the same behaviour for my package. Is it possible?

AUR package for konica minolta laser printer (CUPS)

Hi there,
currently I'm writing a AUR package for the Konica Minolta Magicolor 5430 Desklaser.
I have a question to put the ICC profiles files and special KM files to the cups tree.
The Konica Minolta makefile put the binary "rstertokm5430" to the directory "/usr/lib/cups/filter/" which is completely correct but the *.ppd file and *.icm files are going by default to /usr/share/KONICA_MINOLTA/mc5430DL/Profiles (icm files) and to
/usr/share/cups/model/KONICA_MINOLTA/km5430dl.ppd.gz (ppd file)
The directory in my running archlinux is
usrsharecupsmodel*.ppd and
usrsharecupsprofiles*.icm
Additionally there are "Halftones" files (*.bmp)
usrshareKONICA_MINOLTAmc5430DLHalftones*.bmp
I think about to put the Konica Minolta files in to this (new) directory tree:
usrsharecupskm5430dlmodel*.ppd
usrsharecupskm5430dlprofiles*.icm
usrsharecupskm5430dlhalftones*.bmp
How do I have to copy these files to be archlinux compliant ?
best regards,
Frank

frigg, my apologies for overlooking an important point in my last post. The three magicolor drivers have different version numbers, unlike the other examples of multiple printer drivers in one PKGBUILD. This means you will need one PKGBUILD for each driver, in order to have the correct Arch version number. There is still value in doing them together, since they have many common elements.
As a consequence of this change, I think it might be best to put the single PPD file in /usr/share/cups/model/, rather than have a directory with one ppd file in it. It appears that the KM_PPDDIR variable in the configure script controls this location, so I have added a sed command to the build script accordingly.
As another consequence, the package names need to be changed. I would suggest cups-mc2430dl, etc. This uses the short internal names used by the drivers, and Arch package names are supposed to be lower-case. This means that your awk script no longer works for all three drivers. Rather than write three different awk scripts, I have ported your directory change to a sed command. When you package a stand-alone script with the PKGBUILD, you have to also maintain its md5sum, so it is simpler to do everything inside the build script if you can.
Following are the three incomplete PKGBUILD scripts incorporating these changes. They are complete enough that when you run makepkg, they will download the tarball (if it isn't already present), check its md5sum, copy it into the src directory, uncompress it, and modify the configure script. One way for you to proceed from here is to add lines to the build script, run makepkg, check that the right things happen in the src directory, and then that the correct things are put into the correct place in the pkg directory. The next line in the build script runs configure, which won't finish on my system due to the lack of libjbig.
# Contributor: Frank Ickstadt (frank dot ickstadt at gmail dot com)
# For Konica Minolta magicolor 2430 Desklaser
pkgname=cups-mc2430dl
pkgver=1.6.0
pkgrel=1
pkgdesc="CUPS driver for Konica Minolta magicolor 2430 Desklaser printer"
url="http://konicaminolta.com/"
license="GPL"
depends=('cups' 'gcc')
source=(http://www.linuxprinting.org/download/printing/konicaminolta/magicolor2430DL-$pkgver.tar.gz)
md5sums=('a97b4ee5c949ca791764457ead3a5b9c')
build() {
cd $startdir/src/magicolor2430DL-$pkgver
sed -i '/KM_PPDDIR/s//KONICA_MINOLTA//' ./configure
sed -i "/KM_DATADIR/s/KONICA_MINOLTA/$pkgname/" ./configure
#./configure --prefix=/usr
#make || return 1
#make prefix=$startdir/pkg/usr install
# Contributor: Frank Ickstadt (frank dot ickstadt at gmail dot com)
# For Konica Minolta magicolor 5430 Desklaser
pkgname=cups-mc5430dl
pkgver=1.8.0
pkgrel=1
pkgdesc="CUPS driver for Konica Minolta magicolor 5430 Desklaser printer"
url="http://konicaminolta.com/"
license="GPL"
depends=('cups' 'gcc')
source=(http://www.linuxprinting.org/download/printing/konicaminolta/magicolor5430DL-$pkgver.tar.gz)
md5sums=('1460477f2dd195c301e961a6cbfe1f54')
build() {
cd $startdir/src/magicolor5430DL-$pkgver
sed -i '/KM_PPDDIR/s//KONICA_MINOLTA//' ./configure
sed -i "/KM_DATADIR/s/KONICA_MINOLTA/$pkgname/" ./configure
#./configure --prefix=/usr
#make || return 1
#make prefix=$startdir/pkg/usr install
# Contributor: Frank Ickstadt (frank dot ickstadt at gmail dot com)
# For Konica Minolta magicolor 5440 Desklaser
pkgname=cups-mc5440dl
pkgver=1.2.0
pkgrel=1
pkgdesc="CUPS driver for Konica Minolta magicolor 5440 Desklaser printer"
url="http://konicaminolta.com/"
license="GPL"
depends=('cups' 'gcc')
source=(http://www.linuxprinting.org/download/printing/konicaminolta/magicolor5440DL-$pkgver.tar.gz)
md5sums=('abd54f32517ebeb7a56f902b159c7dea')
build() {
cd $startdir/src/cups-mc5440DL-$pkgver
sed -i '/KM_PPDDIR/s//KONICA_MINOLTA//' ./configure
sed -i "/KM_DATADIR/s/KONICA_MINOLTA/$pkgname/" ./configure
#./configure --prefix=/usr
#make || return 1
#make prefix=$startdir/pkg/usr install

[solved] have to update my aur package

One of my aur package, lib32-libva, was in the need to be be updated.
I've already uploaded my aur packages to aur4 some days ago, so now, has long as i understood, if i update the old "aur" domain package, the change will never be reflected to the new aur4.
So i've updated it via git only to aur4, but the change is not visible to the "old" aur domain.
Is this supposed to happen?
Did i do it right?
Am i supposed to update the old aur packages manually?
Thanks and sorry if those questions has already been answered.
Last edited by kokoko3k (Today 09:31:26)

I think It is supposed to be so, you have to update the packages on both domains. From this email announcing the AUR 4.0.0 pre-alpha release
AUR package maintainers are then asked to upload their packages
to aur-dev.archlinux.org and co-maintain them on aur.archlinux.org and
the Git repository on aur-dev.archlinux.org for some time (roughly four
weeks).

AUR Package Maintainer

Similar Messages

Maybe you are looking for