Like the summary says, attempting an ebuild of ical on AMD64 hardware (opteron) fails with the following error: ... make[1]: Entering directory `/var/tmp/portage/ical-2.2.1/work/ical-2.2.1a/calendar' c++ -O -I.. -I. -I./../types -I./../time -c arrays.C c++ -O -I.. -I. -I./../types -I./../time -c calendar.C c++ -O -I.. -I. -I./../types -I./../time -c calfile.C c++ -O -I.. -I. -I./../types -I./../time -c dateset.C c++ -O -I.. -I. -I./../types -I./../time -c item.C c++ -O -I.. -I. -I./../types -I./../time -c lexer.C c++ -O -I.. -I. -I./../types -I./../time -c misc.C c++ -O -I.. -I. -I./../types -I./../time -c options.C c++ -O -I.. -I. -I./../types -I./../time -c smallintset.C c++ -O -I.. -I. -I./../types -I./../time -c uid.C uid.C:16: error: declaration of C function `int gethostname(char*, unsigned int)' conflicts with /usr/include/gentoo-multilib/amd64/unistd.h:791: error: previous declaration `int gethostname(char*, size_t)' here make[1]: *** [uid.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/ical-2.2.1/work/ical-2.2.1a/calendar' make: *** [calendar/libcalendar.a] Error 2 ---------------------------- Begin 'emerge --info' ---------------------------- Portage 2.0.54 (default-linux/amd64/2006.0, gcc-3.4.5, glibc-2.3.5-r2, 2.6.15-ge ntoo-r7 x86_64) ================================================================= System uname: 2.6.15-gentoo-r7 x86_64 AMD Opteron(tm) Processor 252 Gentoo Base System version 1.6.14 dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share /config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib6 4/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/ share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/ tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.gtlib.gatech.edu/pub/gentoo http://www.gtlib.gatech.ed u/pub/gentoo ftp://mirror.iawnet.sandia.gov/pub/gentoo/ ftp://ftp.ussg.iu.edu/pu b/linux/gentoo ftp://ftp.ucsb.edu/pub/mirrors/linux/gentoo/ http://ftp.ucsb.edu/ pub/mirrors/linux/gentoo/ http://cudlug.cudenver.edu/gentoo/ http://mirror.usu.e du/mirrors/gentoo/ ftp://mirror.usu.edu/mirrors/gentoo/ http://mirror.phy.olemis s.edu/mirror/gentoo http://gentoo.cites.uiuc.edu/pub/gentoo/ ftp://gentoo.cites. uiuc.edu/pub/gentoo/ " MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="amd64 X alsa apache2 audiofile avi berkdb bitmap-fonts bzip2 cdr cli crypt ctype cups curl dba dbus dri dvdr eds emboss encode esd exif expat fam fastbuild ffmpeg foomaticdb force-cgi-redirect fortran ftp gd gif glut gnome gpm gstreame r gtk gtk2 hal howl idn imlib ipv6 isdnlog jpeg kde lcms libwww lzw lzw-tiff mad memlimit mng mozilla mp3 mpeg ncurses nls nptl nvidia opengl pam pcre pdflib pe rl png posix pppd python qt quicktime readline samba sdl session simplexml soap sockets spell spl ssl tcltk tcpd tetex tiff tokenizer truetype truetype-fonts ty pe1-fonts udev usb xinerama xml xml2 xpm xsl xv zlib userland_GNU kernel_linux e libc_glibc" Unset: ASFLAGS, CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_ OVERLAY
Keywords for app-office/ical: | a a a h i m m p p p s s s x x | l m r p a 6 i p p p 3 h p 8 8 | p d m p 6 8 p c c c 9 a 6 6 | h 6 a 4 k s 6 - 0 r - | a 4 4 m c f | a b | c s | o d | s ------+------------------------------ 2.2.1 | + + Not keyworded for amd64, reopen if you have a patch.
I was under the impression that not being keyworded meant no one had tried it, so this was an experience report, I guess. In any case, the following seems to work: 1. Download the version found here: http://www.annexia.org/freeware/ical/ 2. Emerge tcl and tk 3. Follow the instructions on the same page for compiling on SuSE 9, x86_64. They work exactly the same on Gentoo AMD64. Sorry, but I'm not familiar enough with the ebuild system to submit a formal patch for this.
Well, unless you have a patch, please report this upstream. We cannot support stuff that's not keyworded for the relevant arch.
I don't understand - what am I expected to report upstream? The source code compiles and runs fine on AMD64, so there is nothing to report to the application developer. This package (actually a newer version) can be keyworded for AMD64 on a test branch, simply by creating an appropriate ebuild for the referenced source code. As a general user, not developer, of gentoo *I do not know how to do this*. Are users who determine that a package works successfully on a previously untested architecture (as encouraged to by the gentoo documentation) expected to know how to create or patch an ebuild themselves for the contribution to be of interest? How do ebuilds get created or keyworded for new architectures if success reports cannot be submitted here? I quote verbatim from http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1: "missing keyword means that the application has not been tested on your architecture yet. Ask the architecture porting team to test the package or test it for them and report your findings on our bugzilla* website." *a link to this bug tracking system
Created attachment 84192 [details] ical source - compiles and runs on amd64 Compile instructions (to implement in ebuild): ./configure --with-tclsh=/usr/bin/tclsh \ --with-tclconfig=/usr/lib64 \ --prefix=/usr/local \ --with-tclscripts=/usr/lib64/tcl8.4 \ --with-tkscripts=/usr/lib64/tk8.4 make && make install
(In reply to comment #4) > I don't understand - what am I expected to report upstream? The source code > compiles and runs fine on AMD64, so there is nothing to report to the > application developer. This package (actually a newer version) can be keyworded > for AMD64 on a test branch, simply by creating an appropriate ebuild for the > referenced source code. Right, so by submitting a bug about unkeyworded stuff, with a summary like "ebuild for ical on amd64 does *not* work" and a bunch of compile errors, you obviously are telling us that this compiles and runs just fine and can be keyworded on amd64. Hmmm, that indeed makes a lot of sense... ZOMG!
the ebuild include a few patches. one obviously breaks it on amd64. you should have a ical-2.2.1a.patch-0.1.tar.bz2 in you /usr/portage/distfiles. It contains a patch called ical-2.2.1a-ia64.patch, which changes the failing line in uid.C. However, from a quick look it seems the package would need some multilib-strict fixes too (it installs libraries to /usr/lib instead of /usr/lib64). So, if you provide a fix, we might keyword the package ~amd64. Sorry, we have to concentrate on packages that are already ~amd64 or amd64 and broken neverthelese :/
Okay, that's fine and I understand that. I would just like to clarify, I am not trying to be difficult: What I would like to point out is that gentoo documentation says that an unkeyworded ebuild is one that users should consider trying on the unkeyworded arch if they are interested and adventurous. It then suggests that users post their reports here, on bugzilla. My original bug submission was nothing more that exactly that (information): I tried it, it didn't work, and it gives some feedback on exactly why, in case anyone wants to try to fix it. I wasn't actually expecting support, or a resolution, though I would have expected something more considered than "invalid: unkeyworded". I know that already. If anything, I would have figured you might consider hard masking the package for amd64. I followed up with code that does work on the arch, and based on the instructions with it, probably at least all the architectures for which ical is currently supported, with (simple) instructions on how to make it build outside of an ebuild environment. Again, I'm not expecting anything - you can do with it what you want (which I would have figured is to create a new ebuild pretty easily). But telling me to take it upstream is does not make sense as it is purely a portage issue, not an application issue. I feel this last response is what should have been posted in the first place, as I'm content to consider this settled now. I've spoken my bit. Peace.
hm, can you tell me which documentation? it really needs to be changed. Generally, we only would like to hear about the result if it is positive.
(In reply to comment #9) > hm, can you tell me which documentation? it really needs to be changed. > Generally, we only would like to hear about the result if it is positive. > Sure, it's on this page: 'http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1' under section 1.d ("When Portage is Complaining..."). It suggests reporting findings, but doesn't offer any qualifications as to positive or negative. My apologies for any misunderstanding.
Alright, it indeed says what you read. Sorry. At least you could help us find a real bug in the end ;) I'll get someone to change the docs. Nevertheless, this bug should be closed. Feel free to reopen it with a fix. Thanks!
