Orphaned [community] packages

I was rummaging around AUR for orphaned packages (as one does on a sunday afternoon...), and noticed there are a few orphaned packages in [community]. I thought that one of the criteria for a package being in [community] was that it was maintained by a TU. Going by this, shouldn't such packages be moved back to unsupported until a TU adopts them?

WillySilly's packages have not been orphaned yet as we're still in the process of getting some of them adopted by the remaining TU. The current orphaned packages were orphaned because the TU left or didn't had the time/interest to maintain them anymore. The packages remains in the community repo because users expect that packages they install from community will be updated/fixed when they do their regular 'pacman -Syu'. Some packages don't need a lot of maintenance and they can be adopted later on. However, in the past, some community packages were moved back to unsupported and someone mentionned that perhaps some of willysilly's packages could be moved back to unsupported. If you're interested in an orphaned community package, you could always bring it up on the TUR ML and it could be moved back in unsupported if no TU is interested in it.

Similar Messages

Suggestion for a community package

I didn't find the way to sumit bug for community packages, so I put it here. Sorry if I came to the wrong place.
The package gtk-kde4 should add provides=gtk-qt-engine, so that it can replace gtk-qt-engine if you want (many packages depends on gtk-qt-engine).

The proper place to submit a bug in an AUR package is the AUR page for that package itself, in that case:
http://aur.archlinux.org/packages.php?ID=9631

Communication Package in portals

hi,
There is a Business Package Communication V50.4 for EP5.0. Its out of maintenance now for EP6.0.
Is there any other package currently available for EP6.0 which does the same function as Communication Package?
Has anyone implemented the same communication package in EP6.0?
Thanks in advance,
Answers will appropriately be rewarded.
Regards
Arunkumar Ravi.

Hi VIjay,
please turn off the Accessibility option in your portal personalization options (upper right corner, Personalize -> User Profile -> Activate Accessibility Features:
(Screen reader required) -> turn it off.
Does it work now as expected ?
regards.
Laszlo.

No way to view changes with PKGBUILD for community packages

I noticed that you can't view PKGBUILD changes for new community packages. I thought we move community to svn so it should be viewable.
Example:
http://repos.archlinux.org/viewvc.cgi/c … nity-i686/
Just my 2 cents.

Everything that is need for the transition is still a work in progress... This a known issues. As a workaround you can use ABS or check out the SVN for the packages you are interested in.

Help! How to get the Java Communication Package work in JDK1.3.1?

I downloaded a Java Communications API Win32 ver 2.0 from java.sun.com, and try to use it to do some programming to communication ports with JDK1.3.1.
I failed. When I tested with the samples (BlackBox, SimpleRead) coming with the javax.comm. It showed "no serial port found", something like that. I check the installation Instructions of the comm. package, it only described the installation under JDK1.1 and the pre-release version of JDK1.2. (and the installation of the same package in JDK1.1 and JDK1.2 are totally different.)I tried the specification with my JDK1.3, but it doesn't work.
Who knows how to install the Javax.comm package in JDK1.3.1? Please let me know as soon as possible. Thanks a lot.

This comes straight out of the FAQ that you got with your download:
Q: My application does not find any ports when it enumerates available ports.
Q: BlackBox gives me a message that says "No serial ports found!"
A: In order for the Java communications API to find ports the file
javax.comm.properties must be in the correct place. The preferred location
is in <jdk>/lib. See the installation instructions for alternate locations
and further information.
Installation is very simple. Comm is a standard extension, so copy comm.jar to %JAVA_HOME%\jre\lib\ext
This is all in the docs....

Java Communications Package

I have download the commapi file and load the files to the place in my current version. I am running J2SE 1.5.0_04. I have run the blackbox program and have found no serial ports. I have also tired running the SimpleRead.java. This comes up with this error message:
Exception in thread "main" java.lang.NoClassDefFoundError; SimpleRead
What does this mean?
Why do I find no serial ports with the black box program?
thanks

Go to www.java.sun.com and type commapi on the search text box. You will find the Java Communication API for dowload.

Pacman seldom upgrades community packages.

i am in a college so connect to the net through a proxy.
i use rankmirror to rank my top 10 mirrors but still pacman upgrades or installs packages with a success rate of about only 20% .
it genrally dounloads and upgrades the small "core pacages" but fails when it comes to opgrading big files...
Someone please help... what is the reason of this flickering nature?

tried the alternative Xfer command, i.e uncommented this line and now it's working fine.
XferCommand = /usr/bin/wget -4 --passive-ftp -c -O %o %u
but still i wanna know why it wasn't working earlier..
Last edited by Pratgeek (2011-02-14 21:25:28)

Does Java Communication package support Windows2000 Professional?

as title
Any one can tell me?

Yes, it does. I'm coding a robot with Lego Dacta over an serial port with only standard user permission and it works great. So there should be no problem.
Just follow the installation instructions (where to place your files I mean) and it should work great.
I heard you could even place the files in you source-code dir, but I'm not sure how this works. Maybe you should check that out if you're not the system admin.
Kind regards,
Bart

[community] repo: Movement of orphaned packages to unsupported.

Hi fellow Archers,
With time, the number of orphaned packages in the community repo has steadily increased because of various reasons: TUs no longer had time/interest to maintain a package, TUs leaving the group, etc. Currently there's about 300 orphans in [community] and the TU group doesn't have currently the time or interest to maintain all of them. We finally came to the conclusion that it would be better to have maintained PKGBUILD in AUR than stale packages in community. So, in the next weeks, we'll gradually move some (all?) of them to unsupported. To ensure that these PKGBUILD get adopted by regular users, we'll be handing out orphaned community packages to users who are willing to maintain them. So if you are interested in one or more orphaned community packages, request it in this thread and it'll be moved to unsupported for you to adopt it. We'll be accepting requests until April 4th but it could be extended if necessary. Hopefully, this will drop the number of orphans to a manageable amount. If not, more orphans will be moved to unsupported.
Once a package is moved to unsupported, I can't guaranty that someone else browsing the AUR will adopt it. So you should adopt it as soon as it's moved to unsupported. If someone else request a package that you want before you, as a matter of courtesy, please give that person a few days to adopt the PKGBUILD. After that, you can adopt it. Also, once you adopt a package, you'll probably need to update it as some of these packages are out-of-date or the arch and license fields are missing.
"Reserved" orphans: DaNiMoTh is currently a TU candidate and, if he gets voted in, is willing to adopt the following orphans: mozplugger, sportstracker, gobby and rsnapshot. You may request them but they'll remain in the community repo until the end of the voting period to minimize package movement.
Snowman

The community repo cleanup is completed.
The current orphans will remain in community and have been fixed/updated.
I've added myself to the notification list so I'll be aware of any
comments.
Some packages were completely removed from community/AUR:
schism: obsoleted by schismtracker
gst-plugins-png: Arch no longer support gstreamer 0.8
mysql-administrator: obsoleted by mysql-gui-tools
mysql-query-browser: obsoleted by mysql-gui-tools
multisync: This app has been actually splitted in two other apps
(multisync-gui and msynctool) whose PKGBUILDs are in
unsupported.
Other packages that were also in current/extra were removed.
Packages that were moved to unsupported:
If you want to browse the list with the AUR interface, do a search with me
(Snowman) as submitter and look for the orphaned packages. Several of them
have found a new maintainer in unsupported.
Here's the list:
adns-python
alac_decoder
alex
anubis
arc
asterisk-addons
asterisk-sounds
asterisk-webvmail
atlascpp
bioapi
cal3d
ccid
cherrypy
chicken
cohoba
contacts
cyphesis
daap-sharp
dirac
e-uae
echelon
editobj
eds-feed
entagged-sharp
expresskeys
fantasdic
flamerobin
flumotion
gaim-xmms
galago-gtk-sharp
galago-sharp
gap
gaupol
gcursor
gizmod
gnelib
gnome-ppp
gnome-subtitles
gnomeradio
gpixpod
gpodder
grism
gsoap
gstreamer0.10-pulse
gyrus
hawknl
ifolder
ifolder-server
imapfilter
incollector
invest-applet
io-vm
iwar
joscar
ketchup
krb5-auth-dialog
lbdb
ldtp
leaftag-gnome
liban
libannodex
libao-pulse
libatomic_ops
libccc
libchipcard2
libcmml
libfakekey
libfishsound
libflaim
libgconf-java
libggigcp
libggiwmh
libglade-java
libgnome-java
libharu
libiaxclient
libleaftag
libmatchbox
libmodelfile
libmusclecard
liboggz
libomxil
libopensync-plugin-evolution2
libp11
libphish
libprelude
libpreludedb
libpri
libptp2
librasc
libsexymm
libsirius
libupnp
log4cxx
log4j
log4net
logjam
matchbox-common
matchbox-desktop
matchbox-keyboard
matchbox-panel
matchbox-panel-manager
matchbox-themes-extra
matchbox-window-manager
mediatomb
mercator
ming
mt-daapd
mudmagic
mugshot
muscletool
nautilus-burn-sharp
nautilus-ifolder
nemerle
nepenthes
netatalk
nihongobenkyo
olsrd
ontv
openct
openproducer
opensc
openscenegraph
openvpn-admin
osgedit
outguess
pam_bioapi
pam_p11
pcsclite
prelude-manager
prewikka
pureadmin
py2play
pyao
pygmy
pygopherd
pykanjicard
pymusepack
pyopenal
python-axon
python-dvb3
python-empy
python-gammu
python-kenosis
python-leaftag
python-nattraverso
python-pyalsaaudio
python-pyannodex
python-pygoocanvas
python-pyicu
python-pylucene
python-renderpm
python-scw
python-sexy
python-tofu
python-vobject
python-xlrd
pyzor
rugg
ruli
rvm
sabbu
sage
sharpmusique
shn2make
simias
skstream
slune
sobby
soya
straw
synbak
synfig-core
synfig-etl
synfigstudio
tagutils
tangerine
unicap
varconf
vazaar
wammu
wfmath
wmradio
xmltv
xmltv-druid

Question about "BUSINESS PACKAGE FOR COMMUNICATION"

We want to configure "BUSINESS PACKAGE FOR COMMUNICATION_50_4_5" for EP 6.0 SP2. We have imported mentioned package in our EP 6.0. There are no errors in logfile.
In document "Transfer Collaboration Rooms from EP 5.0 to EP 6.0" (item 3.8) is described how we can create and configure systems for "Communication Framework", "Address Book Component", "Java Mail Connector" and "Mail Server", that was mentioned in documentation to "BUSINESS PACKAGE FOR COMMUNICATION_50_4_5".
But we can't create those systems because portal's archives: "com.sapportals.pct.comm.systems" and "com.sapportals.pct.col.sync.systems" are absent in our system (System Administration > System Configuration > System > Portal Content. Right click on directory and select "New From Portal Archive").
What we can do in this situation?

Hi Slava,
the Communication Package has been discontinued, it it not supported with EP6.
For the Coll.Rooms you have to configure the Groupware Connector according to the Admin Guide.
Hope this helps.
Bye
Christoph Schulz
Freudenberg IT

Adopt, refresh, orphan package: bad style or legit?

Hi guys,
i got a question. Sometimes i stumble across packages which are out of date and orphaned, but i want to test/ temporarly use. So i create my own working PKGBUILD (with minor patches/updates). But i wouldn't be a long term user/maintainer of the package. Is it considered bad style to adopt, refresh and instantly orphan a package, like beeing an unreliable packager? Or is it legit to do so?
Some of my own thoughts so far:
Pro(adopt, refresh, orphan):
Better to have a working but unmaintained PKGBUILD than a broken, unmaintained package
Contra:
Packages become more unreliable/unstable. Afaik there is no version control for AUR packages. Maybe there was a 'deeper' reason for orphaning and ood'ing the package, so a quick and dirty update makes things worse.
Looking forward to your opinions.

ewaller wrote:
Mr.Elendig wrote:since noone ever responds when you email them asking for them to orphan the package
I guess I am a no one

[Solved] Yaourt says that alacarte-xfce is an orphan

This is my output
[fallon ~]$ yaourt -Syua
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
multilib is up to date
alacarte-xfce : Orphan
Foreign packages: / 49 / 49
Alacarte-xfce is highlighted in red
I have re-installed it multiple times, refreshing yaourt in between, lots of things. I have searched the interwebs and found nothing.
Why am I getting this, I thought orphaned packages were ones that I didn't mean to install and are no longer needed.
note: Originally I wouldn't have installed alacarte myself, it would have come in an XFCE bundle.
Any advice on if this is normal/how to disable or how to correct would be appreciated.
(I have used GNU/Linux for a year, Arch for a few months, so I'm a little bit noobish ;P )
Last edited by Fallon911 (2013-03-08 21:10:10)

WonderWoofy wrote:
Learning to install AUR packaged by hand is a very good thing to learn. Though, AUR helpers can be convenient, they often keep users from fully understanding what is happening, and like most things with Arch, a lack of understanding can lead to breakage far beyond what Allan can accomplish.
I like cower because it searches fast, and does nothing more than download the tarball and unpack it in my directory of choice. I also keep pacaur on my machine for those times when I am feeling really really lazy.
I am fully capable of downloading and installing by hand actually
I just like to use it so that I know I'm up to date wit hinstaled software

Howto submit package (i repaired an out-of-date package)

I read the stuff on AUR on the wiki but it is not at all clear to me how I should submit a package. I repaired an out-of date package and it seems to be working now. I would like to give back to the community by submitting the package.

You can only submit new versions for packages for which you are the maintainer/contributor.
- In case the package is an orphan (no one owns it) then you should adopt the package and become the new maintainer.
If the package is owned by another user, mail them your new pkgbuild.
If they haven't responded after a few weeks, you can use the tur-users maling list to ask AUR Trusted Users to orphan the package so you can become the new maintainer.
- Many people post new pkgbuilds in the comments, but giving the maintainer a chance to update the package is normal behaviour (or should be).
Note : Your forum account doesn't work on AUR, you need a separate account for that (most people use the same username in forum and AUR).

Vote on the bleepin packaging/incoming debate

In this post: http://bbs.archlinux.org/viewtopic.php?p=25032#25032 rasat and I have described a simple method that could alleviate some of the problems with the incoming stuff immediately. I vote that we implement this as a first step while further discussion continues.
Basically, this is my plan, though it might need some changes:
* ditch incoming in ftp
* post all new packages to New Packages forum. Author or mod should add a "do you think this package should be added to the official repositories" poll.
* If the yes count becomes high enough, add the package to extra (go through TUR, staging, testing, however the devs decide this should be done)
* allow the devs to slowly prune some not-often-used packages from extra on their own time.
can we start with something like this and then move onto other questions, like whether TURs are necessary, or how many repos there should be? We're trying to solve too many probs at once.
Dusty

Ok, I know I'm coming into this discussion late. Mainly because I feel this is mostly a decision to be decided by the devs. But I have a few ideas related to the two threads raging over package management that I thought I would contribute.
My first idea involves testing and staging and requires some modifications to pacman. Instead of having a testing and staging repo, make it a level of confidence for each repository. So the layout of the repos would be something like this:
current
stable
testing
staging
extra
stable
testing
staging
unstable
stable
testing
staging
then in pacman.conf you would specify the level of confidence in the repo name, for example [current level=testing]. If no level was specified, then stable would be used by default. Package resolution would be staging->testing->stable, so that a newer version of a package in testing would be chosen before stable if the level of confidence chosen was testing. When a package is deemed stable, it is just copied over from testing to stable, and the index is regenerated.
This way each class of packages has it's own stable/testing/staging path.
My other idea has to do with packages making it into the arch repositories. I also think incoming is a bad idea, because it provides a built package. Packages in incoming probably are looked over by a dev, then rebuilt using the package build. There really isn't any good thing about taking built packages from untrusted users.
So instead of incoming, I've heard some sort of forum or system be set up to provide package builds. I think this is a good idea. Then if someone wants to maintain an official Arch version of that package, whether it be the submitter of the package build or not, can volunteer. If the devs trust that person, then they become the official maintainer. If that person decides to orphan that package, then the package is removed from the offical repository, until someone else decides to volunteer to maintain it.
This way, there are no orphaned packages in the system. Also, if a package is wanted by someone to be offically maintained by someone bad enough, then they will volunteer. I think this will remove the cruft out of the package management system. I also think this model scales well with more packages, because it only supports that packages that the community are willing to maintain.
Sorry if I'm kicking a dead horse.
-wd

Install package as dependency of another package

Suppose you want to install Package X, which depends on Package Y. You also want to install Package Z, which augments Package X, but is not a dependency of Package X. You run:
pacman -S X Z
Now suppose that you no longer want Package X on your system. You run:
pacman -R X
Package X is removed. Now you can run:
pacman -Qdt
To clean up packages orphaned by Package X. Provided nothing else depends on Package Y, Package Y will be removed.
All is well and good, except Package Z was not orphaned by Package X. Even though Package Z is (in this hypothetical example) useless without Package X, it won't be removed automatically because it was installed with pacman -S.
So... is there a way to install Package Z as a dependency of Package X such that, when Package X is removed, Package Z will be orphaned if no other packages depend on it?

Thank you, rwd, that does the trick. Editing the PKGBUILD is quite reasonable when Package X is in AUR, and for official packages, editing /var/lib/pacman/local/X/depends (not Z/depends) works. The downside is that I have to remember that I want Package Z to behave as a dependency of Package X and tweak Package X every time it is updated. So yes, an --asdepof option would be really swell.
For venky80 and anyone else who may be interested in this, here's a real-world example. Suppose you want to install loudmouth for use with amarok. If you later decide to uninstall amarok, you would like for loudmouth to be automatically uninstalled as well (unless some other package depends on it). loudmouth is not a depedency of amarok (incidentally it is an optional dependency, but this will work with any package that is not a dependency).
1. Install amarok
$ pacman -S amarok
2. Install loudmouth with --asdeps
$ pacman -S --asdeps loudmouth
3. Edit amarok's depends file to make it depend on loudmouth
3a. Open the file in a text editor
$ nano /var/lib/pacman/local/amarok*/depends
3b. Add "loudmouth" under the DEPENDS section; e.g.
%DEPENDS%
loudmouth
mysql>=5.1.34
kdebase-runtime>=4.2
taglib
3c. If loudmouth is an optional dependency of amarok (and it is), remove it from the OPTDEPENDS section.
3d. Save and close the depends file.
4. Test to see if it worked
$ pacman -Qtd
$ # loudmouth should not be listed
$ pacman -Rs amarok
$ # loudmouth should be listed

Orphaned [community] packages

Similar Messages

Maybe you are looking for