March 2006 - Arch-ports - lists.archlinux.org

[arch-ports] developing the (arch64) port
by Andreas Radke 05 Apr '06

05 Apr '06

On the port side: - All arch64 developers should read this: http://dev.gentoo.org/~plasmaroo/devmanual/archs/amd64/ "Applying |-fPIC| on all objects will slow down the binaries in a drastic way." So I will drop it again from the default CFLAGS. A new pacman package is needed. I'll do this later when we are sure how the future development will be. - So we need to review all packages for sorting out packages that will build *.so files. That's how I understand the Gentoo rule. Am I right? We can use a script crawling through /* for *.so | pacman -Qo to get the packages we need to patch with CFLAGS="$CFLAGS -fPIC" ??? Who can do this first? Then check the result against Gentoo and Fedora. - Then a recompile of the whole distro will be needed. makeworld will be my friend :) I hope this will solve our last problems with the iso(mkfs.ext3, lilo, grub) What I expect from the official archlinux developers side: - Jason, I've come to the conclusion that a common cvs and common pkgbuilds are not good for getting the ports accepted. It would take us a long time until i686 developers will accept bloated pkgbuilds and preparing the "arch" tag would take its time. I still don't know why we should need the "arch" tag. I think it would be only to declare if the pkgbuild builds on a certain architecture. But as long as the packages are build by a packager and not automatically we don't really need it. - I disagree to your opinion that i686 packagers will ever be able to build packages for the ports using pacbuild. Every package needs a check and real installation on the destination architecture before you can upload it to the repos. So you always will need to have a few packagers more for each port to check packages and play with bugfixes. - So I would prefer a separate svn/cvs for each port. Every port should be free to decide what packages to include into the port. This may not be as elegant as common cvs+pkgbuild but it's much easier to handle. - No changes would be need to pacman/makepkg. Less work and less learning for all - more KISS for everyone. And it will not take more space on the servers or something like that. So setup a separate svn for arch64 and create new subrepos for x86_64 and give a few of us access - we could start tomorrow! I know some arch64 devs dying to do real productiv stuff. Otherwise as I told you more packagers will leave the port. AndyRTR

4 7

[arch-ports] [arch64] fPIC affected packages
by Andreas Radke 31 Mar '06

31 Mar '06

Thanks to Notz - this is the list with fPIC affected packages: PDL-2.4.2.ebuild:2 PerlQt-3.008-r1.ebuild:1 allegro-4.2.0.ebuild:1 alltray-0.60.ebuild:1 arj-3.10.18.ebuild:1 asis-3.44.ebuild:1 asterisk-1.0.8-r2.ebuild:1 asterisk-addons-1.2.0.ebuild:1 attal-0.9.3.ebuild:1 audacity-1.2.4b-r1.ebuild:1 bestcrypt-1.6_p1-r2.ebuild:2 biew-5.6.1.ebuild:1 bitchx-1.1-r1.ebuild:4 blas-19980702-r2.ebuild:1 c-client-2004a-r1.ebuild:2 capi4k-utils-20050718-r1.ebuild:2 ccmath-2.2.1.ebuild:1 cdk-4.9.10.20020809-r1.ebuild:1 charm-5.9.ebuild:1 cinelerra-cvs-20060219.ebuild:1 cl-gd-0.4.7.ebuild:1 cl-imho-1.3.2.ebuild:1 cl-tclink-3.3.1-r1.ebuild:1 clearsilver-0.10.1.ebuild:1 clibpdf-202_p1.ebuild:1 cmigemo-1.2.ebuild:1 cryptlib-3.2.2.ebuild:2 ctrlproxy-2.6.ebuild:1 cyrus-imap-admin-2.2.12.ebuild:1 dcetest-2.0.ebuild:1 dirdiff-1.6.ebuild:1 djbfft-0.76.ebuild:1 drscheme-301-r1.ebuild:1 eclipse-sdk-3.0.0-r3.ebuild:1 em8300-libraries-0.15.0.ebuild:1 evolution-2.4.2.ebuild:1 ffcall-1.9.ebuild:1 filelight-1.0_beta6.ebuild:1 florist-3.15p.ebuild:2 freeradius-1.1.0-r1.ebuild:1 freewrl-1.16.1.ebuild:2 fung-calc-1.3.2b.ebuild:1 gaim-latex-0.3.ebuild:1 gaim-otr-1.0.3.ebuild:1 garlic-3.15p-r1.ebuild:2 gcl-2.6.7.ebuild:1 gcl-cvs-2.7.0.ebuild:1 geoip-1.3.14.ebuild:1 ghc-6.4.1-r3.ebuild:1 ghostscript-esp-8.15.1.ebuild:1 gkrellm-hddtemp-0.1.ebuild:1 gkrelltop-2.2.2.ebuild:1 glib-1.2.10-r5.ebuild:3 gmetadom-0.2.2-r1.ebuild:2 gnat-3.15p-r3.ebuild:2 golem-0.0.5-r1.ebuild:2 gpac-0.4.1_pre20060122.ebuild:1 gplflash-0.4.10-r3.ebuild:1 graphlcd-base-0.1.3.ebuild:3 gst-plugins-0.8.9-r2.ebuild:1 gst-plugins-bad-0.10.0.ebuild:1 gst-plugins-base-0.10.0.ebuild:1 gst-plugins-ffmpeg-0.8.7-r1.ebuild:1 gst-plugins-good-0.10.0.ebuild:1 gst-plugins-ugly-0.10.2.ebuild:1 gtkscintilla2-0.1.0.ebuild:2 hdf-4.2.0-r3.ebuild:1 heimdal-0.7.2.ebuild:1 hugs98-2003.11.ebuild:1 icecream-0.6.20040829.ebuild:2 imaging-1.1.4-r1.ebuild:1 ircservices-5.0.53.ebuild:2 jbigkit-1.4.ebuild:2 jusb-0.4.4.ebuild:1 kbear-2.1.1-r1.ebuild:1 kdevelop-3.1.2.ebuild:1 kemistry-0.7.ebuild:1 kgcc-2.95.3.ebuild:1 kickpim-0.5.3.ebuild:1 knob-1.2-r1.ebuild:1 kth-krb-1.2.2-r2.ebuild:1 ladspa-cmt-1.15.ebuild:1 ladspa-sdk-1.12-r2.ebuild:1 lapack-3.0-r1.ebuild:1 lib3ds-1.2.0.ebuild:2 libapreq2-2.04.03.ebuild:1 libcdaudio-0.99.9.ebuild:2 libebml-0.7.3.ebuild:2 libgeotiff-1.2.1-r1.ebuild:1 libgii-0.9.0.ebuild:1 libhash-1.0.3.ebuild:1 libhttpd-persistent-1.3p-r8.ebuild:2 libident-0.22.ebuild:1 libjsw-1.5.5.ebuild:1 libmatroska-0.7.3-r1.ebuild:2 libmemcache-1.2.4.ebuild:1 libmix-2.05.ebuild:1 libmoe-1.5.8-r1.ebuild:1 libmpeg2-0.4.0b.ebuild:1 libmpeg3-1.5.2-r2.ebuild:3 libpcap-0.8.3-r1.ebuild:2 libpcap-ringbuffer-1.0.20041001.ebuild:2 libpcre-6.1.ebuild:1 libperl-5.8.7.ebuild:1 libsamplerate-0.1.1-r1.ebuild:1 libselinux-1.28-r1.ebuild:1 libtermcap-compat-2.0.8-r1.ebuild:1 libtlen-20040912.ebuild:1 libusb-0.1.8.ebuild:1 libvorbis-1.1.2.ebuild:2 live-2004.07.20.ebuild:4 lives-0.9.1.ebuild:1 lua-5.0.2.ebuild:1 lufs-0.9.7-r3.ebuild:1 matrixssl-1.2.4.ebuild:1 mcl-0.53.00.ebuild:1 mesa-6.4.2-r2.ebuild:1 mesa-progs-6.4.2.ebuild:1 misdnuser-0.1_pre20060203.ebuild:1 mjpegtools-1.6.2-r4.ebuild:3 mod_perl-2.0.1-r2.ebuild:1 mod_python-3.1.4-r1.ebuild:1 mplayer-1.0_pre7-r1.ebuild:1 mupen64-0.5.ebuild:2 mupen64-glN64-0.4.1_rc2-r1.ebuild:1 museseq-0.6.2-r1.ebuild:1 mwcollect-3.0.0.ebuild:1 mysql-4.1.14.ebuild:1 mythtv-0.18.1-r1.ebuild:1 ncurses-5.4-r5.ebuild:3 netpbm-10.26.25.ebuild:1 ode-0.5-r4.ebuild:1 openafs-1.2.13-r2.ebuild:1 openh323-1.13.2-r2.ebuild:1 openldap-2.3.18.ebuild:1 openssl-0.9.7e-r2.ebuild:1 p7zip-4.20.ebuild:1 paklib-0.3.ebuild:1 pam-0.78-r3.ebuild:2 pam_krb5-2.2.6.ebuild:1 pam_pwdfile-0.99.ebuild:1 pam_ssh_agent-0.2.ebuild:1 pari-2.1.6.ebuild:3 pciutils-2.1.11-r5.ebuild:2 pd-cyclone-0.1_alpha54.ebuild:1 perl-5.8.7.ebuild:1 pilot-mailsync-0.8.3.ebuild:1 planeshift-0.3.011.ebuild:1 plib-1.6.0.ebuild:1 ppp-2.4.2-r10.ebuild:2 ptabtools-0.3.1-r2.ebuild:1 pump-0.8.21-r7.ebuild:1 pyparted-1.6.9-r1.ebuild:2 python-2.2.3-r6.ebuild:2 qhull-3.1-r1.ebuild:1 reiserfsprogs-3.6.17.ebuild:1 rpm-4.0.4-r5.ebuild:1 rrdtool-1.0.50.ebuild:2 rss-glx-0.8.0-r2.ebuild:1 ser-0.9.0.ebuild:2 sexypsf-0.4.7.ebuild:1 silc-server-1.0-r1.ebuild:1 skey-1.1.5-r4.ebuild:1 snns-4.2-r7.ebuild:1 soapbox-0.3.1.ebuild:1 sourcenav-5.1.1.ebuild:1 speech-tools-1.2.3-r2.ebuild:1 squeak-3.4.1-r1.ebuild:1 staden-1.5.3-r1.ebuild:4 svgalib-1.9.21-r1.ebuild:1 swh-plugins-0.4.14.ebuild:3 syck-0.55.ebuild:1 systray4j-2.4.ebuild:1 szip-1.1-r1.ebuild:1 tclperl-3.1.ebuild:1 tclpython-3.1.ebuild:1 tclx-8.3-r1.ebuild:2 tvbrowser-2.1.ebuild:1 ucl-1.01-r1.ebuild:1 udunits-1.12.3.ebuild:1 util-linux-2.12i-r1.ebuild:1 uw-imap-2004g-r2.ebuild:3 uw-mailutils-2004g.ebuild:1 valgrind-2.2.0-r2.ebuild:1 vimap-2002c-r3.ebuild:3 vlevel-0.5.ebuild:1 vmd-1.8.3.ebuild:2 vnc-4.0-r1.ebuild:1 wvstreams-4.2.2.ebuild:1 wxhaskell-0.9.4.ebuild:1 xchat-systray-2.4.5-r2.ebuild:1 xchatosd-5.19.ebuild:1 xmms-mp3cue-0.94-r1.ebuild:1 xmms-speex-0.9.1.ebuild:1 xsim-0.3.9.4-r3.ebuild:1 zlib-1.2.3.ebuild:3 As you can see we have made a grep for fPIC in Gentoo's ebuilds. This list should help where to add a (Gentoo) fPIC fix. AndyRTR

1 0

[arch-ports] What's needed for an official port
by Jason Chu 26 Mar '06

26 Mar '06

I've been asked a couple of times about what the port people can do to make their ports official. What I'm trying to do here is list all of the things that must be done before we can have our first official port. A few things need to happen on the Arch Linux developer side: - makepkg needs support for arch=() - the db-* scripts need to be updated for multiple architectures - we need more CVS tags* - the pkgrel-<arch> changes need to be implemented in makepkg and gensync** A few things need to happen on the port side as well: - a good number of packages that can be easily integrated into the official PKGBUILDs (which means changes are marked). I'd even go so far as to say that most packages have to be rebuilt against the merged PKGBUILDs. - a working install cd - pacbuild nodes*** Is there anything I've missed? Jason *: We don't need to make them, just figure out what they will be **: Should this one be in there? Strictly speaking, it's not necessary, but it would really help cut down on unnecessary updates for other arches ***: Also not strictly necessary, but I think it'd help for non-x86_64 developers to try building their changes on x86_64. -- If you understand, things are just as they are. If you do not understand, things are just as they are.

3 5

[arch-ports] Fw: Arch64 installation and xfce4 icons
by Michael Krauss 18 Mar '06

18 Mar '06

On Sat, 18 Mar 2006 Andreas Radke <a.radke(a)arcor.de> wrote: > Michael Krauss schrieb: > > XFCE4 icons: > > ------------ > > > > After installing xfce4, include /opt/xfce4/bin in $PATH and > > put 'exec startxfce4' into .xinitrc, xfce4 works fine. But > > there are no icons in the panel. The buttons are there and work, > > but they are grey like the background. The same problem in firefox > > and epiphany. At the login console I get the following message > > many times: > > > > GdkPixbuf-WARNING **: cannot open pixbuf loader module file > > '/etc/gtk-2.0/gdk-pixbuf.loaders': No such file or directory > > When I'm right the file is beeing created while installit the gtk2 package. > > So try to pacman -Sy gtk2 again and watch the output. On my system the > file has a timestamp from my last update gtk2 2.8.11 -> 2.8.12. Happily you are right. Although pacman says, that the version of gtk2, gtk2-2.8.12-1, is up to date, the problem disappeared after reinstalling :-) Michael Krauss

1 0

[arch-ports] Arch64 installation and xfce4 icons
by Michael Krauss 18 Mar '06

18 Mar '06

Hi to all, hopefully this is the right mailing list for problems and annotations on arch64, if not, you can put me into your kill file. Installation: ------------- When I have installed Arch64 on my AMD64, I had some prolbems: 1. I tried to install with the arch64 7.1 Beta 6 CD. Partitioning worked well and the packages had been installed, but I was naot able to boot, because the was no initrd26.img just a diag1.img that didn't work. 2. Then I tried the arch64 7.0 CD, but this didn't work either. Unfortunately there is no wget at the CD, so one can't use it to install by hand. 3. Now I used a gentoo Live CD, which has wget on board, and did the installation following: http://wiki.archlinux.org/index.php/Arch64_Install_page Beside of some inconsistent paths the installation worked very well, until the pacman.static command. I don't know, what is ment with "I've only mentioned base packages", but pacman want to install quite many packages. Is abiword a base package? Some packages like tin and wvstreams have unsolved dependencies, while others exclude each other, like pcmcia-cs <---> pcmciautils, udev <---> hotplug, xf86...unicrome <---> xf86...via, font...ethiopic <---> font...meltho. After deleting the packages on the right side, pacman was able to install the rest. The rest of the installation worked well and arch boots to console login. XFCE4 icons: ------------ After installing xfce4, include /opt/xfce4/bin in $PATH and put 'exec startxfce4' into .xinitrc, xfce4 works fine. But there are no icons in the panel. The buttons are there and work, but they are grey like the background. The same problem in firefox and epiphany. At the login console I get the following message many times: GdkPixbuf-WARNING **: cannot open pixbuf loader module file '/etc/gtk-2.0/gdk-pixbuf.loaders': No such file or directory Maybe this is a bug, but I can't write a bug report to flyspray http://www.arch64.org/bugs/ so I dropped it here. Maybe that's the reason, why it's still empty ;-) I hope, not wasted too much of your time. <put a closing here, when i find one> Michael Krauss

2 1

[arch-ports] PKGBUILD and package release thoughts
by Jason Chu 11 Mar '06

11 Mar '06

Alright, here's some discussion about PKGBUILDs and multiple architecture support. We already talked about adding an arch= array to PKGBUILDs. The array would list all the architectures a PKGBUILD is known to build on. I don't think makepkg should stop a package from building on an architecture that isn't listed, but it should at least display a really annoying message warning the user that the package probably won't build properly. The second thing I wanted to talk about is pkgrels. We have a problem in that some releases will only affect one architecture and we don't want people using other architectures to have to download packages that haven't changed. My proposal goes something like this: We continue using the pkgrel variable the same way. Each time an update (that isn't a version update) happens to a package, its pkgrel is increased. We also add support to makepkg for a couple more variables. Let's call them pkgrel_i686, pkgrel_amd64, etc. If one of these variables exists, makepkg (and gensync, and updatesync...) will us that pkgrel for the architecture, instead of the pkgrel. What this lets us do is something like this: Package foo is at version 1.2.3-1. A change that only affects i686 happens, so the package maintainer makes the changes (marking them with [ "$CARCH" = "i686" ] && ), updates the pkgrel to 2, and sets pkgrel_i686=2 and leaves all the other variables (pkgrel_amd64, etc) set to 1. When you build the package on i686, it comes out as 1.2.3-2. If you build it on any of the other listed architectures, it comes out as 1.2.3-1. This does mean that if there's a release for all architectures, it becomes -3 everywhere and amd64 users see a jump from -1 to -3. We already have a similar situation with the testing repo. Using this method we can target changes for different architectures all while keeping a single PKGBUILD. There are very few changes needed in makepkg and the other tools to cover all the upgrade cases that I can think of. Thoughts? Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.

7 17

Re: [arch-ports] Arch64 - call for a website maintainer
by eliott 10 Mar '06

10 Mar '06

I would be more than willing to help with such a project. My design skills leave some to be desired as far as layout goes (I have no artistic sense at all), but from a structural and design standpoint, I am probably not the worst out there. ;) >On Thu, Mar 02, 2006 at 11:29:46AM -0500, Dusty Phillips wrote: >> I don't think its a good idea. Have you looked at the sources for the >> existing page? Its got crazy spans, tables, hard to read, I don't >> know how Judd manages to maintain it. :-D I think its actually time >> for the main archlinux.org site to be rewritten in nice clean XHTML >> 1.0 and CSS... > >That would super duper. (yea that's right, I said "super duper") > >The arch page was originally slapped together for me back in 2002 (or >was it 2003?) by a fellow co-worker who had more free time than I. If >someone were inclined to re-design the thing, I'd be a happy geek. The >PHP portions should be re-coded too, perhaps in a proper framework. >They're all pretty adhoc right now, and it's ugly. > > >- J > > >_______________________________________________ >arch-ports mailing list >arch-ports(a)archlinux.org >http://www.archlinux.org/mailman/listinfo/arch-ports

6 6

[arch-ports] New pacman package in testing
by ganja.guru 03 Mar '06

03 Mar '06

The latest pacman in testing has "csup" as a dependency. csup is in the community repo. After you "mkdir /var/abs32" you will be able to run abs in arch64 (no need to chroot to arch32 to run abs) ganja_guru

2 1

Re: [arch-ports] Arch64 - call for a website maintainer
by Daniel Isenmann 02 Mar '06

02 Mar '06

Hi, I have follow the discussion since it has began. I have a suggestion, I would copy the whole design of archlinux.org, if Judd give me a tarball of the exisiting webpage. So, there is the same design and it would be easy to merge it in the future... There is a place where information can be post or new packages will appear, since it will be merge... So, what do you think?? I would do the job, if you say yes. So think about it.. Bye, Daniel -- Echte DSL-Flatrate dauerhaft f�r 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl

7 8