Hi,

Lately, I've been updating out-of-date orphans. So far I did the ones
that were easy to update/test so this is a status report on the
remaining ones. The purpose here is, ideally, to find maintainers for
them or at least testers (devs or users).

BTW, make sure that you are listed as maintainer for both arches of
the packages you maintain even if you can't build the package for that
architecture. Several packages have only one of their arch adopted.
This clutters the list of orphaned and it spams the dev ML with
out-of-date notifications.

Here the commented list:

lirc :
Hugo maintains lirc-utils so I guess he should adopt it too.

gmpc:
Needs an updated libmpd to build. I'll email Tobias if he doesn't answer here.

gnash-common:
gnash-gtk:
Andy has started a thread for these. I'll wait where it goes.

guile-gtk:
Needs gtkglarea 2.X to build. Best way to handle this is to add a
gtkglarea2 in the repo instead of updating gtkglarea as they changed
the library name.
Other alternative, moving guile-gtk to community/AUR

happy:
One of the Haskell guy should pick it up.

libgda:
libgnomedb:
Major version bump. Might have an soname bump. I'll need to check.

lshwd:
Package in the repo is at the latest stable (few years old). There's a
newer rc release but : do we still need this? It's still popular
(25.39 %) though so I could always update it to the rc release.

lzo:
We have lzo2 in core.Only a community pkg depends on it so it could be
moved to community.

junit:
I believe there was a reason why it wasn't at the latest version. Is
it still the case?


evms:
exim:
gphoto2:
libgphoto2:
pdns:
user-mode-linux:
userui:
I can't really test the rest. Is there anyone able/willing to test
updated packages for them? In fact, I didn't really checked them out.
evms and exim seems important so I'm not confortable to push them even
in testing without any good testing. For the rest, if noone comes
forward, I could test them as good as I can and push them to testing
then as for testers on the arch-general ML much like I did for the
scim stuff. Moving some of them to AUR is always a possibility.

Eric

> Lately, I've been updating out-of-date orphans. So far I did the ones
> that were easy to update/test so this is a status report on the
> remaining ones. *The purpose here is, ideally, to find maintainers for
> them or at least testers (devs or users).
>
> BTW, make sure that you are listed as maintainer for both arches of
> the packages you maintain even if you can't build the package for that
> architecture. *Several packages have only one of their arch adopted.
> This clutters the list of orphaned and it spams the dev ML with
> out-of-date notifications.
>
> Here the commented list:
...
> userui:
> I can't really test the rest. Is there anyone able/willing to test
> updated packages for them? *In fact, I didn't really checked them out.
> evms and exim seems important so I'm not confortable to push them even
> in testing without any good testing. For the rest, if noone comes
> forward, I could test them as good as I can and push them to testing
> then as for testers on the arch-general ML much like I did for the
> scim stuff. Moving some of them to AUR is always a possibility.

I use userui (since I use a TuxOnIce patched kernel) .. and I'm
updateing this package myself too.

Recently /usr/sbin/tuxoniceui_fbsplash can't be compiled on Arch since
the Arch freetype package doesn't include the static (.a) library.

So I can test an updated package.



--
damjan

> gmpc:
> Needs an updated libmpd to build. I'll email Tobias if he doesn't answer here.
I'll take care of it.

-T

Damjan Georgievski schrieb:

I use userui (since I use a TuxOnIce patched kernel) .. and I'm
updateing this package myself too.

Recently /usr/sbin/tuxoniceui_fbsplash can't be compiled on Arch since
the Arch freetype package doesn't include the static (.a) library.

So I can test an updated package.


The name of the package is wrong anyway, it should be tuxonice-userui.
As we don't provide a tuxonice kernel anymore, we should move this to AUR.

On Sat, Mar 7, 2009 at 6:19 PM, Thomas Bächler <thomas@archlinux.org> wrote:
> Damjan Georgievski schrieb:
>>
>> I use userui (since I use a TuxOnIce patched kernel) .. and I'm
>> updateing this package myself too.
>>
>> Recently /usr/sbin/tuxoniceui_fbsplash can't be compiled on Arch since
>> the Arch freetype package doesn't include the static (.a) library.
>>
>> So *I can test an updated package.
>
> The name of the package is wrong anyway, it should be tuxonice-userui. As we
> don't provide a tuxonice kernel anymore, we should move this to AUR.
>
>

I was just thinking the same thing.

Eric Bélanger schrieb:

lshwd:
Package in the repo is at the latest stable (few years old). There's a
newer rc release but : do we still need this? It's still popular
(25.39 %) though so I could always update it to the rc release.


We should really drop this hwd stuff. Apparently some howtos still
recommend using "hwd -xa" to generate xorg.conf, but this command will
generate a bloated configuration file that is probably not even
compatible to the latest xorg-server versions.

On Sun, Mar 8, 2009 at 12:29 PM, Thomas Bächler <thomas@archlinux.org> wrote:
> Eric Bélanger schrieb:
>>
>> lshwd:
>> Package in the repo is at the latest stable (few years old). There's a
>> newer rc release but : do we still need this? *It's still popular
>> (25.39 %) though *so I could always update it to the rc release.
>
> We should really drop this hwd stuff. Apparently some howtos still recommend
> using "hwd -xa" to generate xorg.conf, but this command will generate a
> bloated configuration file that is probably not even compatible to the
> latest xorg-server versions.
>
>

lshwd hasnt been used by hwd since version 5.0
ChangeLog says:
21-Nov-2007, version 5.0
- lshwd replaced with pciutils and usbutils
27-Nov-2007, version 5.1.2
- fixed mkxcfg, no lshwd dependency

--
Greg

On Sat, 7 Mar 2009 17:38:00 -0500
Eric Bélanger <snowmaniscool@gmail.com> wrote:

> Hi,
>
> Lately, I've been updating out-of-date orphans. So far I did the ones
> that were easy to update/test so this is a status report on the
> remaining ones. The purpose here is, ideally, to find maintainers for
> them or at least testers (devs or users).
>
> BTW, make sure that you are listed as maintainer for both arches of
> the packages you maintain even if you can't build the package for that
> architecture. Several packages have only one of their arch adopted.
> This clutters the list of orphaned and it spams the dev ML with
> out-of-date notifications.
>
> Here the commented list:

> userui:

I think I have forgotten this package after I have removed tuxonice
kernel from the extra repo long time ago. This can be moved to
AUR/community, I think. You and Thomas suggested it on the arch-ML
already. Feel free to move it from my side.

Cheers,
Daniel

On Sun, 2009-03-08 at 11:29 +0100, Thomas Bächler wrote:
>
> We should really drop this hwd stuff. Apparently some howtos still
> recommend using "hwd -xa" to generate xorg.conf, but this command
> will
> generate a bloated configuration file that is probably not even
> compatible to the latest xorg-server versions.

I would like to get rid of both lshwd and hwd packages. I don't consider
them useful anymore, as there's better autodetection methods available
in archlinux.

Removing hwd will fix bug 13448, 13447 and 13630.

On Sun, Mar 8, 2009 at 3:55 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
> On Sun, 2009-03-08 at 11:29 +0100, Thomas Bächler wrote:
>>
>> We should really drop this hwd stuff. Apparently some howtos still
>> recommend using "hwd -xa" to generate xorg.conf, but this command
>> will
>> generate a bloated configuration file that is probably not even
>> compatible to the latest xorg-server versions.
>
> I would like to get rid of both lshwd and hwd packages. I don't consider
> them useful anymore, as there's better autodetection methods available
> in archlinux.
>
> Removing hwd will fix bug 13448, 13447 and 13630.
>
>

http://bugs.archlinux.org/task/9589 & http://bugs.archlinux.org/task/12886
as ddcxinfo-arch is only used for hwd.
Also see http://bbs.archlinux.org/viewtopic.php?pid=507530#p507530

--
Greg