[00:34] <Noskcaj> ahoneybun, Did you package aisleriot for ubuntu or just for the ppa?
[00:34] <Noskcaj> I though you and tim were talking about it a few weeks ago
[00:35] <ahoneybun> Noskcaj, tbh I never got to it as I did not want to really bother tim with question after question
[00:35] <Noskcaj> Feel free to ask me if you need help with packaging
[00:36] <Noskcaj> www.debian.org/doc/manuals/maint-guide/ is also a good place for answers
[00:36] <ahoneybun> it is just I was asking questions that tim helped me with already
[00:38] <ahoneybun> darkxst, how do I renew my membership to the packaging team?
[00:40] <ahoneybun> Noskcaj, it seems a lot of people use different ways of packaging
[00:41] <Noskcaj> Yeah. many different build systems and VCSes can make things confusing
[00:43] <ahoneybun> Noskcaj, would you take me though your process of packaging >
[00:44] <ahoneybun> seems I have no mouse icon on the screen now
[00:44] <Noskcaj> I assume you mean merges, both from debian and upstream
[00:44] <Noskcaj> And having a mouse is usually good ;)
[00:44] <ahoneybun> um maybe
[00:45] <ahoneybun> ok so my mousepad does not work now
[00:47] <Noskcaj> To "package" things, you have a debian/ folder which contains copyright info, what depends the package has, what patches it needs, and instruction for a machine to build the package
[00:48] <ahoneybun> yea
[00:49] <Noskcaj> The instructions we use nowdays are either debhelper (lots of text, advised against), cdbs (few commands, but i find it confusing, and what gnome often uses), and dh (short debhelper, often only a three line file)
[00:50] <Noskcaj> And patches can be either quilt (good), dpatch (bad), or manually done (bad and rare-ish)
[00:51] <ahoneybun> ok back
[01:00] <Noskcaj> ahoneybun, And patches can be either quilt (good), dpatch (bad), or manually done (bad and rare-ish)
[01:01] <Noskcaj> We'll work on merging the new upstream release of clutter-gst-2.0 , so i've got something i can walk you through
[01:02] <Noskcaj> I found it at<EMAIL_ADDRESS>, where all gnome packages in debian are, and saw our version was not the current one
[01:03] <Noskcaj> First, run bzr branch lp:ubuntu/clutter-gst-2.0 to get the source as it is in ubuntu
[01:05] <Noskcaj> k den
[01:58] <Noskcaj> darkxst, Do you get australian cities in the wrong place in ubiquity?
[01:59] <Noskcaj> Sydney's marker points to canberra for me
[05:24] <darkxst> Noskcaj, thats an old old bug
[05:31] <darkxst> Noskcaj, there was https://bugzilla.gnome.org/show_bug.cgi?id=702194, which would help a lot rather than various apps using various forks of the timezone map!
[06:27] <Noskcaj> darkxst, i'm pretty sure i'd seen an ubuntu bug for it too. thanks for the link
[06:28] <darkxst> Noskcaj, yes there is an ubuntu bug too somewhere, but that is the root cause, the same code has been cut+paste into numerous locations with different changes in each location
[06:28] <Noskcaj> ok
[06:28] <darkxst> ubiquity forked the code from gnome-control-center
[06:29] <darkxst> then indicator-datetime forked the code from ubiquity
[06:29] <darkxst> its just a complete mess
[07:28] <Noskcaj> darkxst, Do you know if we're swapping to systemd this cycle? kde seem to need if for upower 0.99
[07:30] <darkxst> Noskcaj, unlikely Ubuntu will, we might if it works well
[07:30] <Noskcaj> ok
[07:30] <darkxst> Phillip's comments don't seem to make sense though
[07:30] <darkxst> device management is pretty independent of systemd
[07:32]  * darkxst wonders if there is some unported code floating around in kde
[07:51] <Noskcaj> darkxst, do we want metacity 3.12?
[07:52] <darkxst> Noskcaj, we don't use that, but edubuntu guys might so check with mitya57 or alberts
[07:52] <Noskcaj> ok
[07:52] <Noskcaj> it seems to be seeded in all flavours
[07:53] <darkxst> Noskcaj, its kinda  a fail-over backup
[07:53] <darkxst> for when compositing doesnt work
[07:53] <Noskcaj> ok
[07:53] <darkxst> gnome-flashback however uses it as the default WM


[12:38] <zul> gcc 3.4 hasnt been touched in breezy has it?
[12:42] <zul> sorry dumb question
[04:50] <fabbione> morning
[05:41] <desrt_> hello.

[05:45] <lamont> moo
[05:53] <desrt_> oow
[05:54] <lamont> doko: on amd64, gnome-media Depends: libnautilus-burn1, not 2.
[05:54] <lamont> so gnome-media needs another upload, since the build-deps were clearly wrong on the last upload...
[05:55] <lamont> Updating the gdk-pixbuf loaders list for GTK+-2.4.0.../usr/sbin/update-gdkpixbuf-loaders: line 25: 27053 Killed                  /usr/bin/gdk-pixbuf-query-loaders >$TMPFILE
[05:55] <lamont> dpkg: error processing libgtk2.0-bin (--configure):
[05:55] <lamont>  subprocess post-installation script returned error exit status 137
[05:55] <lamont> so I shouldn't be killing that 14 hours after it started running, eh?
[05:55] <lamont> hppa hateses gdk-pixbuf
[05:56] <lamont> well, libgtk2.0-bin_2.6.7-1ubuntu1
[06:02] <jbailey> lamont!
[06:03] <jbailey> lamont: You around tomorrow?
[06:03] <lamont> yeah
[06:03] <jbailey> Cool.  Looks like we have ppc64 ready to go.
[06:03] <fabbione> rocking!
[06:03] <lamont> oh joy.  Just tell me the dance
[06:04] <jbailey> Lemme get the requirements from you:  You require that anything installed into the buildd chroot be built by you, and then we upload binaries that use those, right?
[06:04] <lamont> jbailey: it's easier to phrase it in the negative...
[06:04] <jbailey> lamont: Well, I'm looking for an afirmative set of steps to give you.
[06:04] <lamont> binaries not built by the buildd in a chroot containing only things built by the buildd are not uploaded
[06:05] <jbailey> I'm less worried about what's uploaded than I am by what you're willing to install in that chroot to build what's going to be uploaded.
[06:05] <lamont> binaries built by the buildd using binaries built by the buildd using binaries built by $UBUNTU_GOD are ok
[06:05] <fabbione> haha
[06:06] <lamont> the end-state requirement is that what's in the archive must be able to build what's in the archive.
[06:06] <jbailey> Okay, so you need one iteration pass.  I wonder if what I have on rookery is signed.
[06:06] <lamont> hence, if we have the trivial case of A Build-Depends B Build-Depends A, then we build A using random B binaries, build B using the A binaries just built, upload B, and let A just get built
[06:07] <lamont> fabbione: s/$UBUNTU_GOD/baby jesus/ ??
[06:07] <fabbione> ehhee
[06:08] <fabbione> btw.. do we have a way to determine when all c++ libs are built for arch $foo ?
[06:08] <fabbione> so that we can unban the apps?
[06:08] <lamont> fabbione: doko tells me. :-)
[06:08] <fabbione> lamont: good point :)
[06:08] <lamont> and no, I don't believe that they are, even for the big-3.
[06:09] <lamont> that is, all 5 arch's that I have still have the banlist.  although I did remove the 3 libs packages that were called apps packages, yesterday or the day before.
[06:09] <fabbione> yup
[06:10] <fabbione> so did i
[06:10] <lamont> hrm... maybe by morning my mirror-sync from yesterday will finish. (new kernel *2, new xorg - sigh.)
[06:10] <lamont> and maybe even my uploads will catch up with the builds.  that'd be cool
[06:11] <lamont> jbailey: you know cdbs is ftbfs, yes?
[06:11] <jbailey> lamont: ocaml's busted.
[06:11] <lamont> doh.  I remember now
[06:11] <jbailey> lamont: I should remember to look at that tomorrow.
[06:12] <jbailey>  /msg jbailey jbailey: look at ocaml
[06:12] <jbailey> bah
[06:12] <lamont> hehe
[06:12] <jbailey> lamont: The binaries I have on rookery aren't signed.  I'll fix that in the morning and give you some basic step-by-steps.
[06:12] <lamont> thansk
[06:13] <jbailey> And since Fabio's here, I know that it must be bed time.
[06:13] <jbailey> g'n all!
[06:13] <lamont> and yeah, signed debs is kinda the requirement for installing in the buildd
[06:13] <fabbione> jbailey: i woke up earlier today :)
[06:13] <jbailey> fabbione: =)
[06:13] <jbailey> fabbione: Earlier than 5am?
[06:13] <jbailey> sick
[06:13] <jbailey> Zzzz
[06:14] <fabbione> jbailey: unfortunatly one of the side effects of living in dk is that during the summer the sun is up in the sky at 3am
[06:14] <fabbione> and it woke me up at 4:something
[06:14] <fabbione> i need to put some curtains in the bedroom
[07:27] <svenl> jbailey, doko: with the patch, ugly as it is, the build succeeded.
[11:20] <Kamion> doko: there's no libwpd8 any more; abiword-plugins needs to move to libwpd8c2
[11:22] <Kamion> doko: libintl-perl promoted
[11:23] <Kamion> elmo: any idea why teri seems to want to promote stuff in hoary even though I said -s breezy?
[11:27] <elmo> Kamion: because it's shared ?
[11:27] <Kamion> elmo: is that good?
[11:28] <elmo> no, but it's a natural consequence of how pools work
[11:28] <Kamion> oh, it's the same version
[11:28] <elmo> just run hilaries once you've finished running teri
[11:28] <Kamion> right, but I thought it could be in dists/hoary/universe/*/Packages.gz and dists/breezy/main/*/Packages.gz simultaneously
[11:28] <elmo> only via the magic symlinks
[11:28] <Kamion> ok, I wasn't sure I could safely run that and wanted to check first
[11:29] <Kamion> libintl-perl |     1.11-1 |         hoary | source, all
[11:29] <Kamion> still says that though
[11:29] <elmo> it will madison looks at the database
[11:30] <elmo> the symlinks only help for things which treat the Packages file as canonical
[11:32] <Kamion> I guess the fact that the component is set in the database for (package,version) rather than (package,version,suite) is inherited from Debian then
[11:32] <Kamion> but ok, as long as I didn't break the archive :)
[11:33] <elmo> (package,version,suite) being unique is a fairly fundamental katie thing ...
[12:27] <doko> lamont: I disagree, gnome-media's build log on amd64 shows me the libnautilus-burn2 dependency
[01:21] <fabbione> jbailey, doko: pthread_rwlock_wrlock <- any idea where this one should come from?
[01:21] <fabbione>  /home/sparcbuildd/rhcluster-0.20050527/magma-64/lib/global.c:536: undefined reference to `pthread_rwlock_wrlock'
[01:21] <fabbione> this is building a 64 bit version of a library.
[01:21] <fabbione> it's ok at 32 bit
[01:21] <fabbione>  /home/sparcbuildd/rhcluster-0.20050527/magma-64/lib/plugin.c:411: undefined reference to `dlopen'
[01:21] <fabbione> HMMMM
[01:21] <fabbione> this smell so much of libc6 borkage
[01:22] <doko> definitely
[01:25] <fabbione> ld: warning: sparc:v9 architecture of input file `plugin.o' is incompatible with sparc output
[01:25] <fabbione> it happens with all kind of gcc
[01:25] <fabbione> so it's not just gcc the problem
[01:33] <fabbione> jbailey: see above :)
[01:33] <fabbione> i am checking with older glibc right now
[01:33] <jbailey> Are you running the buildd in a sparc32 jail?
[01:34] <fabbione> it's just a chroot
[01:34] <fabbione> i didn't execute anything like sparc32 or sparc64
[01:34] <fabbione> just added -m64 to the gcc call
[01:35] <jbailey> Without it I can seee occasionally having problems.
[01:35] <fabbione> (like Debian does)
[01:35] <jbailey> afk a sec.
[01:35] <fabbione> yeah no rush
[01:37] <jbailey> back
[01:37] <fabbione> hmm nope..
[01:37] <fabbione> same story in hoary...
[01:37] <fabbione> hmmmmmmm
[01:37] <jbailey> Try building it after sparc32'ing.
[01:37] <jbailey> I've seen problems like that before. =(
[01:37] <fabbione> i did try:
[01:38] <fabbione> sparc{32,64} make CC="gcc-3.{3,4} -m64"
[01:38] <fabbione> in all combinations
[01:38] <fabbione> same error both in hoary and breezy...
[01:38] <fabbione> i wonder..
[01:39] <jbailey> sparc32 -m64 doesn't make much sense...
[01:39] <jbailey> Why would it have -m64 on it?
[01:40] <fabbione> jbailey: because you need to build both 32 and 64 bit?
[01:40] <fabbione> so basically the source is copied in 2 dirs
[01:40] <fabbione> one for 32 bit build
[01:40] <fabbione> and one 64
[01:40] <jbailey> I'd have to see the build log to guess.  IT sounds like it's just gotten confused and mixed the two along the way somewhere.
[01:41] <fabbione> jbailey: in glibc or this program?
[01:41] <jbailey> this program.
[01:41] <fabbione> sure.. one second
[01:41] <jbailey> It's ld detecting the mismatch.
[01:41] <fabbione> do you want the full build log?
[01:41] <jbailey> IF it were glibc, I'd expect everything to fail.
[01:41] <fabbione> or just the 64 bit part?
[01:41] <jbailey> Yes please.
[01:41] <jbailey> full
[01:41] <fabbione> ok
[01:50] <fabbione> jbailey: http://people.ubuntu.com/~fabbione/buildlog
[01:59] <jbailey> Your link line is at least missing -ldl -lpthread
[02:02] <jbailey> fabbione: This buildlog is only half there...
[02:03] <jbailey> fabbione: It looks like you did a debuild -nc and sent me that. =)
[02:04] <fabbione> ops
[02:04] <fabbione> sorry about that
[02:05] <jbailey> =)
[02:05] <jbailey> doko: l?
[02:09] <doko> hi
[02:10] <jbailey> doko: svenl provided a patch do chew libstdc++ configure such that it assumes that we're cross compiling.  I don't understand all the implications of the patch - are you comfortable with it for upload as gcc-3.4?
[02:11] <jbailey> (I'm assuming that I need to make the patch ppc-only)
[02:11] <fabbione> jbailey: relaod the log now :)
[02:12] <jbailey> fabbione: Right, this is terribly confused.  -m32 and -m64 code don't play together.
[02:13] <jbailey> It's building the modules, but it's never built a -m64 libmagma.so
[02:13] <doko> yes, I'm merging it now, so that it get's only applied, if we cannot run 64bit binaries. when we can run 64bit binaries, I'm enableing the -m64 tests as well
[02:13] <fabbione> jbailey: the first part of the log is all 32 bits
[02:13] <fabbione> the first failure is when i attempt to build the first 64bit module
[02:13] <fabbione> module = subdirs that needs 64
[02:13] <jbailey> doko: Sweet, thanks.  When you have that ready, I've already booked LaMont for part of today.
[02:14] <fabbione> make[2] : Entering directory `/home/sparcbuildd/rhcluster-0.20050527/magma-64/lib'
[02:14] <fabbione> ^^^note that it is building the same module in another dir :)
[02:14] <jbailey> doko: I can at least get him with a bootstrap glibc and C-only gcc, after that we only need this for the upload.
[02:14] <jbailey> fabbione: Right, but it's not actually building the libmagma again.  It's building stuff to go with it without having build a 64bit libmagma.
[02:15] <fabbione> i don't understand...
[02:15] <fabbione> magma build is at the top of the file
[02:15] <fabbione> magma-64 is at the bottom
[02:15] <fabbione> don't take into account magma-plugins.. that's another story
[02:16] <jbailey> fabbione: The first -m64 stuff I see is in magma-64/lib
[02:17] <jbailey> Oh, bah.
[02:17] <jbailey> My bad, sorry.  I read the ld line wrong.
[02:17] <fabbione> ehe no problem :)
[02:17] <fabbione> nothing to be sorry about
[02:17] <fabbione> that piece of code is a mess :)
[02:17] <fabbione> now.. the point is that debian does exactly the same way
[02:17] <fabbione> and it builds
[02:17] <doko> jbailey: I do have a complete set of packages built with you glibc
[02:17] <doko> needs copying to chinstrap
[02:18] <jbailey> Do you prefer chinstrap to rookery?
[02:18] <doko> lamont must be cheap if he can be booked that easily ;-)
[02:18] <jbailey> I usually use rookery so that people can wget them.
[02:19] <jbailey> doko: I promised him oral pleasure...
[02:19] <jbailey> ... I'm buying him a pack of gum.
[02:19] <jbailey> =)
[02:19] <fabbione> ahaha
[02:25] <lamont> jbailey: say in about 4 hours work for you?
[02:25] <jbailey> fabbione: Humour me a sec.  ar -v lists sparc64 in the list of emulations at the bottom, right? =)
[02:26] <jbailey> lamont: Yeah, should be fine.
[02:26] <lamont> cool.
[02:26] <fabbione> ar: supported targets: elf32-sparc a.out-sparc-linux elf64-sparc a.out-sunos-big elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex
[02:26] <fabbione> hey lamont
[02:26] <jbailey> fabbione: Okay, good. =)
[02:26] <fabbione> jbailey: :)
[02:30] <jbailey> fabbione: Gcc sets -m elf64_sparc, can you try adding that to the ld line?
[02:30] <fabbione> jbailey: sure thing
[02:31] <fabbione> ld -m elf64_sparc -shared -soname libmagma.so.0 -o libmagma.so.0.0 global.o plugin.o localinfo.o ip_lookup.o memberlist.o clist.o -lc
[02:31] <fabbione> ld: skipping incompatible /usr/bin/../lib/libc.so when searching for -lc
[02:31] <fabbione> ld: skipping incompatible /usr/bin/../lib/libc.a when searching for -lc
[02:32] <fabbione> starts to look MUCH MUCH better!
[02:32] <fabbione> no idea why it's searching crap in /usr/bin
[02:32] <fabbione> but the build system is kinda borked :)
[02:32] <jbailey> gcc does things through relative paths.
[02:33] <fabbione> hmm
[02:33] <jbailey> fabbione: Can you redefine ld there?
[02:33] <fabbione> yeps
[02:33] <fabbione> make CC="gcc-3.4 -m64" LD="ld -m elf64_sparc"
[02:33] <fabbione> that's what i used just now
[02:33] <jbailey> fabbione: If yes, just define it to "gcc-3.4 -m64" and see what happens, please.
[02:33] <fabbione> that's what i did already
[02:34] <jbailey> If the compiler notices that it's being used as a linker, hopefully it'll just do the right thing.
[02:34] <fabbione> or you mean ld?
[02:34] <jbailey> I mean ld.
[02:34] <fabbione> ah ok
[02:35] <fabbione> gcc-3.4: libmagma.so.0: No such file or directory
[02:35] <fabbione> gcc-3.4: unrecognized option `-soname'
[02:35] <fabbione> nope...
[02:35] <fabbione> it didn't like it
[02:35] <jbailey> Ugh, yeah.  That stuff has to be wrapped in -Wl, magic.
[02:36] <doko> jbailey, lamont: chinstrap:~doko/powerpc64
[02:36] <jbailey> doko: Nice, thanks.
[02:37] <fabbione> doko: rocking :)
[02:37] <jbailey> doko: And I think all I have to do is produce for him a libc6 that he can work with and this can be just uploaded.
[02:37] <jbailey> fabbione: Care to share a screen session on vultus5?
[02:38] <fabbione> jbailey: sure i can do that :)
[02:38] <fabbione> just one sec :)
[02:38] <doko> jbailey, yes, integrating svenl's patch
[02:38] <fabbione> jbailey: just hook up in my session :)
[02:39] <fabbione> ehehhe
[02:40] <fabbione> if it's too big, i can resize mine :)
[02:40] <jbailey> That's one for the quotefile.
[02:41] <fabbione> btw.. screen is clever enough to show you the borders if you set a size bigger than the original
[02:42] <jbailey> Really?  Cool.
[02:42] <jbailey> Thinking about sparc64 makes me need to listen to Nirvana, CD now playing. =)
[02:44] <fabbione> ahha
[02:44] <fabbione> it's a chroot.. there is nothing installed .)
[02:44] <fabbione> or just the minimum
[02:44] <jbailey> Hmm.
[02:45] <jbailey> I would've thought that gcc or glibc would pull in libgcc_s_64 automatically.
[02:45] <fabbione> oh
[02:45] <fabbione> what do you want me to install?
[02:46] <jbailey> Well, I'd like to know whose assumption is broken first.  libgcc_s_64 is something brought in by gcc/the linker in this case, not the user, so the user shouldn't have to know to install it.
[02:46] <jbailey> doko: ^^ ?
[02:49] <doko> we don't have dependencies for the non-default arch in gcc
[02:51] <jbailey> doko: What ought to pull that in?  I don't think the user should have to, but I could do it as part of libc6-dev-sparc64
[02:51] <fabbione> libc6-dev-sparc64 is installed btw
[02:52] <jbailey> Yup, it's just figuring out what should pull in lib64gcc1
[02:52] <doko> jbailey: yes, that might be a good place
[02:52] <fabbione> oh so if i install that package...
[02:52] <fabbione> it should build...
[02:52] <jbailey> No, the last command I ran will work.
[02:52] <jbailey> We still need to fix the package to do better than it's doing now. =)
[02:53] <fabbione> yeah the package SUCKS BIG BIG BIG BIG BIG TIME
[02:53] <fabbione> well the last interesting commands still return error
[02:54] <jbailey> Are you packaging this for Ubuntu, or is this something we're importing from Debian?
[02:55] <fabbione> jbailey: for ubuntu
[02:55] <fabbione> part of it is already in debian
[02:55] <fabbione> and i did check the build-dep
[02:55] <fabbione> the point is that debian didn't build this crap in months
[02:56] <fabbione> so with a very old toolchain
[02:56] <jbailey> I don't think it would've worked months ago on sparc64 then...
[02:57] <fabbione> jbailey: no idea if it works.. but it was builded
[02:58] <Kamion> hmm, binutils bugs come flooding in
[02:58] <jbailey> For now, let's make this work.
[02:58] <jbailey> fabbione: Please install lib64gcc1 in this chroot.
[02:58] <fabbione> sure
[02:58] <fabbione> jbailey: meh.. it's installed :)
[02:59] <jbailey> doko: Thinking of which, I saw drow mention that he was busy because of travelling.  Would you prefer to wait for that update?
[03:01] <doko> lamont: why is screem_0.12.1-1ubuntu3 not built?
[03:02] <doko> jbailey: yes I did look at the ml today, maybe I just fetch a cvs update from the branch
[03:02] <jbailey> Ah, I haven't read it today.  He mentioned it in the #debian-glibc a couple days ago.
[03:12] <jbailey> doko: I might have another gcc-3.4 packaging bug.  Still time to get it to you?
[03:16] <jbailey> fabbione: See that ifeq ($(with_shared_libgcc),yes) bit ?
[03:16] <fabbione> jbailey: yes
[03:16] <fabbione> btw.. i installed less :)
[03:16] <doko> jbailey: yes
[03:17] <jbailey> fabbione: That's not firing for some reason, so the libgcc is being left in /usr/lib64 instead of being moved to /lib64
[03:17] <jbailey> fabbione: We need to figure out what it didn't fire and get the patch for it to doko. =)
[03:17] <fabbione> jbailey: a gcc-3.4 build without checks can take sometimes...
[03:17] <fabbione> i can stop the buildd to make it faster
[03:17] <fabbione> otherwise we can fix it in another upload
[03:17] <fabbione> sparc won't build gcc- automatically anyway
[03:18] <jbailey> I'd rather not hold up the ppc64 stuff for it.
[03:18] <fabbione> installing gcc-3.4 build-deps now
[03:18] <fabbione> yeah sure.. it works for me to wait the next upload
[03:19] <jbailey> fabbione: There should be no reason why it didn't fire...
[03:19] <fabbione> i can see that....
[03:19] <fabbione> but i have no idea....
[03:20] <jbailey> Oh right.
[03:20] <fabbione> ahhh
[03:20] <jbailey> I see. =)
[03:20] <fabbione> gcc-4.0!
[03:20] <jbailey> Right. =)
[03:20] <fabbione> so gcc-3.4 has nothing to do with this problem
[03:20] <jbailey> Right.
[03:21] <doko> jbailey, should libgcc1 be installed in /lib64 or /usr/lib64?
[03:21] <fabbione> do you want gcc-4.0 builddep?
[03:21] <jbailey> doko: /lib64, in case it's needed for some reason to bring up /usr (encrypted filesystem or whatnot)
[03:22] <jbailey> doko: The gcc-3.4 packaging appears to have it that way, but the gcc-4 packaging moves it to /usr/lib64.  (Or rather, doesn't include the code snippet that moves it from $(d)/$(PF)/lib64 to $(d)/lib64
[03:24] <fabbione> jbailey: do you need gcc-4.0 build-deps?
[03:24] <fabbione> to do a test build?
[03:24] <jbailey> fabbione: I think it's funny that the Nirvana CD ended just as we figured it out.  I should label it sparc64. =)
[03:24] <fabbione> ahahaha
[03:25] <jbailey> fabbione: Umm.  No - I don't think I want to dive into that now.  If we put a symlink in /lib64 for you so that you can hack on this, it'll be overwritten when the package is updated.
[03:25] <jbailey> fabbione: It won't do you any good for uploading, but it will let you finish testing the build.
[03:26] <fabbione> jbailey: yeah that's fine
[03:26] <fabbione> doko: did you understand what you need to do to gcc-4.0?
[03:29] <doko> hmm, didn't read ... the /lib64 stuff?
[03:30] <fabbione> doko: yeps
[03:51] <fabbione> ok
[03:51] <fabbione> jbailey: it works perfectly!
[03:52] <fabbione> thanks a lot!
[03:55] <jbailey> fabbione: Any time. =)
[03:58] <jbailey> lamont: ocaml is current FTBFS I think from the X transition, I'll poke at it next week.
[04:00] <infinity> Kamion : I've bitchslapped pitti, and a new upload is on its way.
[04:01] <Kamion> cool, thanks
[04:02] <infinity> A little education about why testsuite output should be read and compared, and we're on our way. :)
[04:02] <jbailey> infinity: Aren't you just the FormatTestPlans bitch now... ;)
[04:03] <infinity> Well, this does remind me that you should properly XPASS/XFAIL all of binutils' tests and actually error on suite failure.
[04:03] <infinity> s/you/we/
[04:03] <infinity> Or me, even.
[04:04] <infinity> If I had a spare month, I'd do it with gcc too...
[04:06] <infinity> It was a bit shocking to come home, open up ubuntu-bugs, and see "nothing compiles on hoary anymore".   :-P
[04:49] <doko> ok, forgot about the Reverse-Build-Depends ...
[04:49] <doko> let's see if I can build it with gcj-4.0
[05:04] <doko> elmo: please could you dist-upgrade davis/breezy-ppc64 and then install the packages from davis:~doko/gcc/install/ ?
[05:05] <elmo> I can't dist-upgrade without a fixed glibc packae set
[05:05] <elmo> are the ones in ~doko safe to install first?
[05:07] <doko> hmm, they have the same version as the ones in the archives
[05:10] <elmo>   libc6-dev: Depends: linux-kernel-headers (<= <IP_ADDRESS>-0) but <IP_ADDRESS>-0ubuntu1 is installed
[05:11] <doko> elmo: hmm, maybe just install the *64 packages then, the rest from breezy
[05:11] <jbailey> What are you guys doing?
[05:11] <doko> jbailey: rebuilding 3.4 in the breezy-ppc64 chroot
[05:12] <doko> just want to check, that I don't have any new build bugs introduced
[05:12] <jbailey> doko: Ah, you really probably want the glibc from my directory on rookery.
[05:12] <doko> jbailey: yes, that's what I copied
[05:13] <jbailey> Really?  =(  It shouldn't have that lkh bug...
[05:13] <elmo> it doesn't
[05:13] <jbailey> Then I'm just confused.
[05:29] <elmo> Unpacking bison-doc (from .../bison-doc_1%3a2.0-1ubuntu2_all.deb) ...
[05:29] <elmo> dpkg: error processing /var/cache/apt/archives/bison-doc_1%3a2.0-1ubuntu2_all.deb (--unpack):
[05:29] <elmo>  trying to overwrite `/usr/share/info/bison.info.gz', which is also in package bison
[05:29] <elmo> DUDE
[05:29] <elmo>  Conflicts: bison (<< 2.0)
[05:29] <doko> hmm, I thought I fixed it ...
[05:30] <elmo>  Version: 1:2.0-1ubuntu2
[05:30] <elmo> epochs'r'us
[05:31] <doko> argh
[05:33] <elmo> anyway, breezyt-ppc64 done
[05:33] <doko> thanks
[05:33] <doko> bison supposed to be fixed now
[05:37] <doko> elmo: sorry, still need autoconf2.13 automake1.4 automake1.7
[05:38] <elmo> installed
[05:39] <doko> jbailey: when did you book lamont?
[05:40] <jbailey> doko: The 4 hours he quoted would be about 45 minutes from now.
[05:40] <jbailey> I do need food, though, so I'd be happier if it were a bit later.
[05:41] <jbailey> And I have a rental car to return over lunch.
[05:42] <lamont> hrm...
[05:43] <lamont> could start now, if you want...
[05:43] <lamont> doko: screem was d-w, will see how it does now
[05:44] <jbailey> lamont: You will need to install a new binary glibc into the buildd.  A source upload of gcc after that is enough to build gcc, and a source upload of glibc after that is enough to get glibc in.
[05:44] <jbailey> lamont: What's first? =)
[05:45] <doko> lamont: let's start now
[05:45] <lamont>  /usr/include/sys/procfs.h:57: error: parse error before 'elf_vrreg_t'
[05:45] <lamont> go lkh!  kill gdb.
[05:46] <lamont> (gdb is ftbfs on ppc)
[05:48] <lamont> jbailey: so what I'm most likely to do is:  (1) glibc binary install, (2) build gcc, install that binary, (3) build/upload glibc, (4) build/upload gcc
[05:49] <lamont> hrm.. actually, (3) is build, install glibc. :-)
[05:49] <lamont> (5) is build/upload glibc
[05:49] <elmo> lamont: what's this?
[05:49] <lamont> bootstrapping biarch
[05:49] <jbailey> lamont: Okay.  So for version numbers, glibc 2.3.5-1ubuntu3 is in the archive now, gcc-3.4 3.4.4-0ubuntu3 is in the archive now.
[05:50] <jbailey> lamont: What binary version do you want the first glibc to be?
[05:50] <lamont> jbailey: if you want to be kind, something between -1ubuntu3 and -1ubuntu4 :-)
[05:50] <lamont> or even -1ubuntu4, and the actual source upload be -1ubuntu5 is fine with me
[05:51] <elmo> lamont: biarch of what?
[05:51] <jbailey> elmo: ppc/ppc64
[05:51] <doko> elmo: ppc64
[05:51] <elmo> I thought you needed a 64 bit kernel?
[05:51] <doko> no, only for a "sanity" check and running the testsuite
[05:51] <lamont> jbailey: and this is on ppc only, or which architectures am I bootstrapping? :-)
[05:52] <Kamion> as binutils recently demonstrated, the testsuite is for wimps ;-)
[05:52] <doko> lamont: I thought jbailey booked you for i386 as well?
[05:53] <doko> Kamion: to be more precise, testsuite for -m64 is not run
[05:54] <lamont> doko: i386 was my recollection... ppc64 was the news item... :-)
[05:54] <jbailey> doko: No, fabio and svenl seemed to be in a rush for ppc.  I can do i386 at the same time I think.  Just need to make sure I have everything merged together for it.
[05:55] <jbailey> doko: Is the gcc-3.4 source package on chinstrap already tweaked for that too?
[05:57] <jbailey> doko: Oh wait, I remember.  I also did the ppc stuff first since it's a simple biarch setup without needing Tollef's multiarch stuff at all.
[06:00] <lamont> jbailey: and remember to disable the gcc- testsuite on hppa, please
[06:00] <jbailey> lamont: gcc or glibc?
[06:00] <lamont> gcc-3.4, most notably
[06:01] <lamont> although 4.0 wouldn't hurt either... :-(
[06:03] <doko> lamont: please get it from chinstrap:~doko/uploads again
[06:04] <jbailey> doko: What do you want to have happen?  Mostly the last couple days I've been testing ppc64 and planning to do the proper multiarch path thing after.
[06:04] <doko> lamont: gcc-3.4 as well?
[06:05] <doko> jbailey: I don't care that much about biarch on i386, as you like it.
[06:06] <jbailey> 'kay, I'll ignore it for now, we can do the ppc stuff, and I'll get the rest of it next round.
[06:06] <lamont> doko: 3.4 either needs tk love, or a hammer.
[06:07] <doko> lamont: please could you find out, why gnome-panel is not built on amd64?
[06:07] <doko>    * On hppa, build-depend on expect-tcl8.3 instead of expect.
[06:08] <lamont> doko: bug #11024
[06:08] <lamont> (gnome-panel)
[06:09] <lamont> build-dep (and therefore dep-wait) on libwnck
[06:10] <doko> thanks
[06:14] <lamont> elmo: if libqscintilla5c2 migrated universe->main, python-qt3 et al would be happier.
[06:15] <doko> lamont: these should leave main, not needed anymore
[06:15] <lamont> really?
[06:16] <lamont> as of 1649 today (london), that was the cause of the failure...
[06:16] <jbailey> Hmm, this should probably grow a build-dep on a particular gcc-3.4 version, shouldn't it...
[06:16] <lamont> The following packages have unmet dependencies:
[06:16] <lamont>   libqscintilla-dev: Depends: libqscintilla5c2 (= 1.5.1-1ubuntu1) but it is not installable
[06:16] <Kamion> lamont: he means that python-qt3's scheduled for demotion to universe
[06:16] <lamont> ah.  that works too
[06:16] <fabbione> hmmmmm
[06:17] <fabbione> guys did you made an estimate of how many pkgs will need ppc64 love?
[06:17] <fabbione> like libncurses-5 ?
[06:17] <fabbione> or do you plan to modify the same that are actually built for sparc64?
[06:17] <jbailey> fabbione: ncurses, zlib, I think maybe procps
[06:17] <jbailey> fabbione: Right. =)
[06:17] <fabbione> :)
[06:18] <jbailey> doko: What should I put as the build-dep version of gcc-3.4 for ppc64?
[06:18] <doko> 3.4.4-0ubuntu4 should be ok
[06:19] <jbailey> Tx.
[06:22] <jbailey> Lovely, glibc build is running
[06:23] <jbailey> One of these days I have to figure out how to make ccache happier.  I have 3188 cache hits, and 24527 cache misses.  The only thing I compile with ccache is glibc...
[06:26] <doko> jbailey: I have 0 hits compiling gcc =)
[06:27] <fabbione> doko: clearly.. gcc sucks
[06:28] <doko> fabbione: ppc64 kernel ready?
[06:28] <fabbione> doko: not without toolchain
[06:28] <fabbione> you will get it either monday or tuesday
[06:30] <doko> toolchain is on davis/breezy-ppc64. happy weekend ;-)
[06:36] <doko> infinity: you did remove the gcc4 changes to grub, when merging ...
[06:39] <fabbione> doko: welcome to the kernel team. kthxbye
[06:40] <fabbione> jbailey: i found another weird case :)
[06:40] <fabbione>  /usr/bin/ld: cannot find -lgcc_s_64
[06:40] <fabbione> and i didn't update the chroot ;)
[06:41] <fabbione> anyway.. this is monday stuff :))
[06:55] <jbailey> fabbione: On gcc-3.4 or gcc-4?
[06:55] <jbailey> s/On/Using/
[06:55] <fabbione> jbailey: never mind..  :P
[06:56] <fabbione> since you have a G5 you are going to test kernel and userland :)
[06:56] <fabbione> anyway it's really we time for me now :)
[06:56] <fabbione> cya tomorrow
[06:57] <jbailey> Yup.  Dunno if I'll be around much this weekend, but I Should be a little bit.
[06:57] <jbailey> First real sunny one this year. =)
[06:57] <fabbione> i will be tomorrow (my morning) and probably a bit of sunday
[06:57] <fabbione> ehhe
[06:57] <fabbione> enjoy :)
[06:58] <jbailey> 2u2!
[06:58] <fabbione> merci'
[06:58] <lamont> jbailey: anything for me yet?
[06:58] <fabbione> (poor mispelled french ;))
[06:58] <jbailey> lamont: TEstsuite finished, it's just running the install bits.
[06:58] <jbailey> fabbione: You spelt it right. =)
[06:58] <lamont> ok
[06:59] <lamont> jbailey: is this ppc only? or which architectures are we playing with?
[07:00] <doko> lamont: ppc
[07:00] <lamont> cool
[07:02] <lamont> jbailey: you're going to give me a nice repository on rookery or something, right?
[07:02] <jbailey> lamont: Define nice repository...
[07:03] <lamont> jbailey: a deb line I can drop into sources.list. :-)
[07:03] <lamont> from somewhere wget-able on rookery
[07:03] <lamont> hrm... without a Release.gpg is OK, I suppose
[07:03] <lamont> it is
[07:04] <jbailey> Good, debhelper phase going now.
[07:04] <jbailey> I have to leave in the next few minutes to get the car back on time.
[07:10] <jbailey> lamont: I gotta run, I have this copying onto rookery, but it'll have to wait until I come back for me to wave apt-ftparchive over it.
[07:10] <lamont> hrm... where on rookery?
[07:11] <jbailey> http://people.ubuntu.com/~jbailey/ppc64/
[07:11] <lamont> ok.  any easy way to tell the copy is done?
[07:11] <jbailey> There's a signed changes file in there.
[07:11] <lamont> ok
[07:12] <jbailey> Restarted the command as:
[07:12] <jbailey> scp * people.ubuntu.com:public_html/ppc64/; ssh people.ubuntu.com touch ppc64/done
[07:12] <lamont> chmod g+w public_html/ppc64
[07:12] <lamont> that'll be easiest.. :-)
[07:13] <jbailey> Done.
[07:13] <lamont> ok. /me waits for done to exist
[07:14] <jbailey> glibc_2.3.5-1ubuntu4.diff.gz glibc_2.3.5-1ubuntu4.dsc glibc_2.3.5-1ubuntu4_powerpc.changes glibc-doc_2.3.5-1ubuntu4_all.deb libc6_2.3.5-1ubuntu4_powerpc.deb libc6-dbg_2.3.5-1ubuntu4_powerpc.deb libc6-dev_2.3.5-1ubuntu4_powerpc.deb libc6-dev-ppc64_2.3.5-1ubuntu4_powerpc.deb libc6-pic_2.3.5-1ubuntu4_powerpc.deb libc6-ppc64_2.3.5-1ubuntu4_powerpc.deb libc6-prof_2.3.5-1ubuntu4_powerpc.deb libc6-udeb_2.3.5-1u
[07:14] <jbailey> buntu4_powerpc.udeb libnss-dns-udeb_2.3.5-1ubuntu4_powerpc.udeb libnss-files-udeb_2.3.5-1ubuntu4_powerpc.udeb locales_2.3.5-1ubuntu4_all.deb nscd_2.3.5-1ubuntu4_powerpc.deb zoneinfo-udeb_2.3.5-1ubuntu4_all.udeb
[07:14] <jbailey> Is the order of the files.
[07:14] <jbailey> bbiab.
[07:14] <lamont> while [ ! -f done ] ; do sleep 60; done
[07:14] <lamont> :-)
[07:27] <lamont> Suggested packages:
[07:27] <lamont>   locales glibc-doc
[07:27] <lamont> The following packages will be REMOVED:
[07:27] <lamont>   build-essential* g++* g++-3.3* g++-4.0* libc6-dev* libstdc++5-3.3-dev*
[07:27] <lamont>   libstdc++6-4.0-dev*
[07:27] <lamont> The following packages will be upgraded:
[07:27] <lamont>   libc6
[07:27] <lamont> 1 upgraded, 0 newly installed, 7 to remove and 1 not upgraded.
[07:28] <lamont> lunchtime.  back online in a while
[07:41] <doko> lamont: just only install the lib64* parts
[09:00] <jbailey> back
[09:04] <jbailey> lamont-away: I don't understand why libc6-dev and g++-3.3 would've been removed in there...
[09:12] <doko> found another bug in 3.4 ... will update the files
[09:12] <jbailey> packaging bug or source code bug?
[09:12] <doko> packaging
[09:13] <doko> elmo: please install on davis/breezy-ppc64 the updated packages in ~doko/gcc/install2
[09:14] <jbailey> Is that where lamont is working?
[09:15] <elmo> while you're building stuff?
[09:15] <doko> sure, testsuite is just running
[09:16] <doko> I'll try to rebuild jbailey's glibc packages on that machine. if you are still there, if they finish, then please install them as well
[09:17] <elmo> installed
[09:18] <doko> thanks
[09:21] <doko> nice, upstream generated libstdc++-v3/testsuite/Makefile.in with automake 1.9, libstdc++-v3/Makefile.in with 1.7
[09:22] <doko> the install fails after running the testsuite for both -m32/-m64 ...
[09:58] <doko> jbailey: did you see the gdb build failure in lkh
[09:58] <doko> powerpc
[09:58] <jbailey> doko: Ah, nope, lemme look in a sec.
[09:59] <doko> In file included from /build/buildd/gdb-6.3/bfd/elf.c:6591:
[09:59] <doko> /usr/include/sys/procfs.h: At top level:
[09:59] <doko> /usr/include/sys/procfs.h:57: error: parse error before 'elf_vrreg_t' /usr/include/sys/procfs.h:58: error: parse error before 'elf_vrregset_t'
[09:59] <doko> make[4] : *** [elf.lo]  Error 1
[09:59] <jbailey> Joy.
[10:39] <jbailey> Had a brownout and my box lost power.  X isn't really interested in starting right now.
[10:56] <jbailey> There we go...
[11:14] <doko> elmo: please install on davis/breezy-ppc64 the updated packages in ~doko/gcc/install2/*2.3.5*deb
[11:16] <elmo> doko: done
[11:17] <doko> thanks! have a nice weekend
[11:29] <doko> lamont: deb http://people.ubuntu.com/~doko/ppc64 ./
[11:34] <jbailey> doko: Does that have glibc and gcc both in there?
[11:35] <doko> these are the updated packages, both glibc & gcc-3.4. I didn't modify jbailey's sources, updated gcc-3.4 sources can be found at chinstrap:~doko/uploads
[11:35] <doko> jbailey: yes
[11:36] <jbailey> doko: Cool, thanks.