- Arch-dev-public - lists.archlinux.org

[arch-dev-public] opencdk, gnutls and libtasn1 in testing
by Jan de Groot 12 Sep '07

12 Sep '07

A few minutes ago I pushed gnutls 2.0.0, OpenCDK 0.6.4 and libtasn 1.1 to testing. Though all of them have a new major version number, only OpenCDK has had a so-bump. It seems that GNUTLS is the only package that depends directly on opencdk, and running lddd.sh on my system shows no possible rebuilds for this upgrade. Please give these libraries some testing, as they're an important part of your system. Report bugs to flyspray so we can rebuild these broken applications.

1 0

[arch-dev-public] Away 9/9-9/15
by Paul Mattal 09 Sep '07

09 Sep '07

I will be on vacation and relatively offline 9/9 through 9/15. Feel free to feed and care for my packages in my absence. I plan to kick mythtv out of testing on my return, and tackle the new version of eclipse and eclipse-cdt. - P

1 0

[arch-dev-public] Xorg dummy package removal
by Travis Willard 07 Sep '07

07 Sep '07

Hi everyone, As recently pointed out in http://bbs.archlinux.org/viewtopic.php?id=37062&p=1 the xorg dummy package has been removed. While this could have been done a bit more elegantly and with warning, it's been done, and I'm post-emptively giving warning now I guess. Anyone maintaining packages with the dependency on 'xorg' please update your packages. Nothing should EVER depend on 'xorg' - use namcap to find out what the true deps to your package are and add them. Some packages in extra, community, and AUR-unsupported probably need fixes. To preserve convenience of installing Xorg, we're considering doing an xorg group between the packages previously pulled by the xorg metapackage. I'll follow up to this email when that's done. Thanks. -- Travis

4 3

[arch-dev-public] Do we like the same books?
by Aaron Griffin 07 Sep '07

07 Sep '07

I just joined Shelfari to connect with other book lovers. Come see the books I love and see if we have any in common. Then pick my next book so I can keep on reading. Click below to join my group of friends on Shelfari! http://www.shelfari.com/Register.aspx?ActivityId=9198203&InvitationCode=a14… Aaron Griffin Shelfari is a free site that lets you share book ratings and reviews with friends and meet people who have similar tastes in books. It also lets you build an online bookshelf, join book clubs, and get good book recommendations from friends. You should check it out. -------- You have received this email because Aaron Griffin (aaronmgriffin(a)gmail.com) directly invited you to join his/her community on Shelfari. It is against Shelfari's policies to invite people who you don't know directly. Follow this link (http://www.shelfari.com/actions/emailoptout.aspx?email=arch-dev-public@arch…) to prevent future invitations to this address. If you believe you do not know this person, you may view (http://www.shelfari.com/phrakture) his/her Shelfari page or report him/her in our feedback (http://www.shelfari.com/Feedback.aspx) section. Shelfari, 616 1st Ave #300, Seattle, WA 98104

1 0

Re: [arch-dev-public] [arch-dev] Package listing color offset update
by Travis Willard 06 Sep '07

06 Sep '07

> > Good idea, but the colour is wrong IMO. Try the background colour from > > the header row. > > Sure. Find me the hex color code and send it to me, and I will make the > change. I think the colour you're looking for is #EEE4CB. -- Travis

1 1

[arch-dev-public] X.Org 7.3 pre-release testing repo
by Alexander Baldeck 06 Sep '07

06 Sep '07

Hey all, X.Org 7.3's release is about to happen in the next few days/weeks. For that reason I've built the latest xorg-server snapshot which is at version 1.3.99.2 and most of the drivers and newly introduced packages. A lot has changed, primarily in the area of driver ABI. For example nvidia is broken, it does build but xorg-server rejects it when starting up with an API mismatch error. Forcing it leads to hardlocks. I am using xf86-video-nv for now but this issue needs to be addressed. I have no idea how well fglrx & unichrome-dri plays with the new server. So I'd like to hear about it. Anyone wanting to take part in testing, should add this repo: http://kth5.telekommunisten.net/xorg/ The PKGBUILs will soon be available with the same URL, just need to clean them up a bit. Cheers, -F

8 20

[arch-dev-public] Fwd: [arch] WWW Root dir
by Aaron Griffin 04 Sep '07

04 Sep '07

Can we revisit this please? http://www.archlinux.org/mailman/private/arch-dev/2007-March/004700.html for reference ---------- Forwarded message ---------- From: Sergej Pupykin <ps(a)lx-ltd.ru> Date: Sep 4, 2007 8:29 AM Subject: [arch] WWW Root dir To: arch(a)archlinux.org Hi, I see /srv in filesystem package. What about www root? What decision was reached? _______________________________________________ arch mailing list arch(a)archlinux.org http://archlinux.org/mailman/listinfo/arch

1 0

Re: [arch-dev-public] Stellarium 0.9.0 and repo considerations
by Damir Perisa 04 Sep '07

04 Sep '07

Hi Corrado, Tuesday 04 September 2007, you wrote: | I wrote a PKGBUILD for the new stellarium, and added my .desktop | file to it (there even was a bug report about that, nobody added | it in the new version but I'm going to send it to the stellarium | team, too). I also noticed that the new version depends on qt4, | which is in community, while stellarium is in extra, so either we | move qt4 to extra (I don't think many people would like it) or we | move stellarium to community. If you think the latter is a good | idea I can take care of it and maintain the package there, just | let me know what you think about it. qt4 is going to [extra] "soon". kde4 will need it and also other pkgs are waiting for update for it (qtiplot, qsynth, speedcrunch... just to mention a few). also the scim/skim qt-immodules are qt4 and not available in qt3. so once qt4 is in [extra] the input system SCIM will finally work in kde :) the problem with qt4 not yet being official is that for making it clean we need to make 3 pkgs: * the core libs (without any dependency on xorg) - for qt4 server apps * the qt4 everything else except the core and qt3 compatibility (legacy) libs * the qt3compatibility libs other distros are separating it exactly the same way. the splitting of the thing in 3 pkgs is a little bit tricky if we want to make it nice (not e.g. by building it and then just removing the files from the target pkg that do not belong to this pkg)... this is still work in progress and actually the only thing holding us back. no dev has yet time to digg in qt4 build system to make the 3 pkgs yet. qt4 will be placed in /usr and not in /opt as qt3 and qt4 can coexist, no big migration is needed, once qt4 is in [extra] => i do not want to update stellarium in [extra] yet. the qt4 waiting is exactly the reason. i also do not want to move it to community just to move it back in a few months. | Attached to this message you'll find the new build with the | .desktop file. if you want, i can backport it. however it would mean triggering a update and stellarium is a big pkg for up/download :) | The only thing I didn't take care of is the | license, which at a first glance seems a bit complex (I think it's | two or three licenses). You can find a summary of the various | licensed materials in $startdir/src/stellarium-0.9.0/README. pacman can handle multiple licenses. the license=() is an array. stellarium is at least GPL for sure, IIRC. :) if you want to take over and maintain it in community, feel free. but consider that it will soon have to be rebuilt against a qt4 in /usr anyway. thanx + greetings, Damir

1 0

[arch-dev-public] fixed checkpkg
by Paul Mattal 03 Sep '07

03 Sep '07

I fixed checkpkg to also look for new makepkg3-style package names, and rolled that into the makepkg3 patch in the devtools package. - P

1 0

[arch-dev-public] perl modules in archlinux
by Jan de Groot 03 Sep '07

03 Sep '07

Hi all, I've been busy modifying all perl packages today to follow the same installation method. I think I'm past halfway now, only 20-25 packages to go. I added some dependencies for modules which I retrieved from the META.yml and/or Makefile.PL files. Things I did: - make all build() functions the same - add !emptydirs to options to get rid of empty perl directories - add md5sums - update to newest versions - add licenses (used PerlArtistic for anything that doesn't have an official license) Please watch out carefully when adding new perl packages to the repository, we don't want these things to become bad again.

5 6