#ubuntu-toolchain 2005-07-25
<lamont> make[2] : Entering directory `/build/buildd/isdnutils-3.6.2005-01-03/xmonisdn'
<lamont> make[2] : xmkmf: Command not found
<lamont> doko: ^^^
<daniels> lamont: that's my problem
<daniels> xutils shouldn't, er, be empty
<daniels> but anyone using xmkmf deserves whatever they get
<fabbione> morning
<lamont> daniels: ah, ok
<fabbione> lamont: i am safe :)
<fabbione> it's only a binutils regression
<fabbione> libs are all ok
<lamont> i386 89.0
<lamont> powerpc 88.7
<lamont> amd64 87.9
<lamont> ia64 87.8
<lamont> sparc 75.0
<lamont> hppa 62.5
<lamont> fabbione: just fyi
* lamont heads to bed
<fabbione> lamont: pkg ratio?
<lamont> installed vs total
<fabbione> not too bad...
<fabbione> i have a stall in universe atm
<fabbione> and i need to recheck the c++ transition status
<fabbione> i think i miss something like 19 libs
<fabbione> that are FTBFS 
<fabbione> so i can't unleash the other 600 pkgs
<fabbione> i guess the same is for the other arches...
<fabbione> good night :)
<lamont> hppa has the advantage that if I can resolve build-deps using only breezy, then I only get transitioned libs.. :)
<lamont> and really g'night.
<fabbione> hehe good night
<fabbione> ah i can reproduce it in debian too!
<fabbione> hey doko
<doko> morning
<fabbione> https://bugzilla.ubuntu.com/show_bug.cgi?id=12822 <-
<fabbione> doko: please fix now. kthxbye.
<doko> hmm, interesting ...
<fabbione> doko: it's the one i have been bithing about for a while by now
<fabbione> except now we have a simple test case
<fabbione> doko: in how long are you going to upload the next gcc-4.0?
<fabbione> sparc is completling the test case of the 2ubuntu2
<doko> I can wait for that one to finish, if you want
<fabbione> doko: it depends how urgent is your upload.. i don't want to stall it
<fabbione> but i would also like to get the new gcc in :)
<fabbione> XPASS: 26_numerics/cmath/c99_classification_macros_c.cc (test for excess errors)
<fabbione> i am here now...
<fabbione> no idea how much is left
<doko> libjava
<fabbione> i mean in terms of time
<fabbione> the machine is not doing anything else.. so i expect not to take too long
<doko> hmm, about 4 hours?
<fabbione> probably
<fabbione> doko: let say that if it doesn't finish within 4 hours you upload?
<fabbione> would that be ok for you?=
<doko> I'll wait
<fabbione> thanks
<doko> fabbione: how's the 4.0 build going?
<fabbione> FAIL: libmudflap.cth/pass40-frag.c (-O3) (test for excess errors)
<fabbione> doko: still in the test suite...
<fabbione> but only 3 hours passed :)
<fabbione> if you need to upload just go
<fabbione> i will stop this one
<fabbione> but tell me now please.. so the buildd can go further with other stuff
<doko> no, go on
<fabbione> ok i will let it build...
<fabbione> Running /build/sparcbuildd/gcc-4.0-4.0.1/src/libjava/testsuite/libjava.lang/lang.exp ...
<fabbione> it's on java :)
<fabbione> doko: it finished the test suite...
<fabbione> it's doing something else :)
<fabbione> i guess installing
<fabbione> doko: i am going offline for one hour..
<fabbione> i really need to crash a bit
<fabbione> if when i am back sparc hasn't finished yet, just go and upload ..
<doko> yep, I'm not online tonight, will read my backlog
<fabbione> doko: it's building the debs now..
<doko> so I can upload?
<fabbione> no wait.. i need to be upload the debs
<fabbione> otherwise katie will REJECT the bin upload
<doko> ok
<fabbione> but we are there :)
<fabbione> dh_movefiles: Compatibility levels before 3 are deprecated.
<fabbione> doko: you need to check debian/rules*
<fabbione> you are still using old COMPACT levels
<doko> I know, I should copy the dh_movefiles code.
<fabbione> i think you can easily change level
<doko> no, not for dh_movefiles and wildcards on the command line
<fabbione> dude.. it's time to split gcc...
<fabbione> we did it for xorg...
<fabbione> you can do it for gcc :)
<daniels> yeah, and look how well it's going for xorg :P
<infinity> Shh, don't discourage him.
<daniels> doko: btw, we managed to get splitting gcc in as a BreezyGoal.  get to it.
<infinity> Much better.
<fabbione> Fix a typo in gjc translation.. 36 hours of build
<fabbione> daniels: look at the positive side..
<fabbione> nobody can complain about taking 45 minutes to build X anymore
<daniels> true dat
<fabbione> daniels: next.. you will split the kernel
<fabbione> actually..
<fabbione> i could do it :P
<fabbione> that's easy
<daniels> jbailey gets to split glibc
<daniels> fabbione: i expect the vm and the fs layers in totally different source packages
<daniels> and one binary package per module
<daniels> sometimes I get the feeling we've gone a little too far with xorg
<fabbione> daniels: i think you did a bit too much...
<fabbione> daniels: but packaging vm and fs in different layers.. that's easy :)
<fabbione> dpkg-deb: building package `lib64stdc++6' in `../lib64stdc++6_4.0.1-2ubuntu2_sparc.deb'.
<fabbione> COME ON!
<fabbione> ARE WE THERE YET?
<fabbione> 16128 -rw-r--r--  1 sparcbuildd sparcbuildd 16494216 Jul 20 16:19 libgcj6-dbg_4.0.1-2ubuntu2_sparc.deb
<fabbione> WTf
<fabbione> 16Mb to debug java....
* fabbione stops the torrents to upload faster
<doko> daniels: BreezyGoal? No, where?
<doko> must be a bounty :)
<fabbione> doko: seriously.. is it actually possible to split gcc?
<doko> I didn't look yet. problem is, that the gcc driver still needs to be able to understand the not-configured languages
<doko> so, basically, copy the source, and build different sets of compilers from the packages
<doko> but I didn't see that as a breezy goal ...
<daniels> ewwww
<daniels> copying source -> you lose
<doko> daniels: no, we do want to be able to keep the system compiler at a defined state, while updating the non-core compilers
<daniels> O----o
<daniels> that's your mouth on the left
<daniels> and a pipe coming out of it
<fabbione> ahahhaha
<daniels> unfortunately I can't represent the illicit substances within, in ASCII
<fabbione>   100 -rw-r--r--  1 sparcbuildd sparcbuildd    97348 Jul 20 16:27 lib64gfortran0_4.0.1-2ubuntu2_sparc.deb
<fabbione> now..
<fabbione> i mean...
<fabbione> who on earth still uses fortran...
<fabbione> 64 bit even!
<daniels> way of the future
<fabbione> let's rewrite X in fortran :)
<fabbione> i need to get a shower...
<doko> heh, it's not the old 28 years old f77, it's the brand new 10 years old f95 :-)
<fabbione> brb
<daniels> you first
<fabbione> doko: if you need to go, just put the source on rookery and i will ftp it to jackass as soon as i am done
<doko> I'm leaving in one hour
<fabbione> 24623 ?        RN     0:02 python /usr/bin/dput ubuntu gcc-4.0_4.0.1-2ubuntu2_sparc.changes
<fabbione> it's dputting... i guess 15 minutes and we are done
<fabbione> this is the moment in which IF you upload.. i am will hate you for the rest of my life :P
<fabbione> anyway fast shower and back
<fabbione> re
<fabbione> doko: 5 minutes and you should be ok to go
<fabbione> i am waiting the mail from katie to tell me she loves me a lot
<doko> fabbione: currently all runtime libs built from gcc-4.0 are linked using -O1. should I disable that for the next sparc build?
<fabbione> doko: go ahead
<fabbione> doko: i mean you can upload
<fabbione> doko: i just added info to the bug..
<fabbione> i can't see -O1 anywhere
<doko> fabbione: yes, you can't see it, the runtime libs itself are linked with -O1 at build time
<fabbione> doko: let's wait and see what upstream has to say about binutils
<fabbione> because i don't believe it's a gcc problem...
<fabbione> and i don't want to workaround it.. i want the fix :)
<fabbione> doko: or is this -O1 an ubuntu only thing?
<doko> no, debian/ubuntu only thing
<doko> not upstream
<fabbione> hm ok
<fabbione> doko: let's wait and see a couple of days
<fabbione> the amount of pkgs affected is relatively small
<fabbione> anyway.. i need to go offline..
<doko> ok, 4.0 uploaded
<fabbione> doko: danke for waiting :)
<fabbione> cool..
<fabbione>    * Update to CVS 20050720, taken from the gcc-4_0-branch.
<fabbione>      - Fix PR22278, volatile issues, seen when building xorg.
<fabbione> uh...
<fabbione> i guess we will expect a -44 :)
<fabbione> cya later
<doko> yep, that was the reason for the quick upload
<doko> daniels: ^^^
#ubuntu-toolchain 2005-07-26
<daniels> doko: thanks very much
<fabbione> morning
<jbailey> Split glibc?
* jbailey shudders
<jbailey> Actually, the sad part is that I'd love to split Locales out.
<doko> jbailey: splitting locales would be nice
* lamont looks around to bitchslap jbailey
<lamont> jbailey: Sid's /usr/include/rpc/xdr.h is ftbfs with gcc-4.0 (2.3.2-ds1-22)
#ubuntu-toolchain 2005-07-27
<fabbione> morning
<lamont> i386 90.2
<lamont> powerpc 89.6
<lamont> amd64 89.1
<lamont> ia64 88.7
<lamont> sparc 74.1
<lamont> hppa 64.8
<fabbione> ehhe
<fabbione> lamont: weren't you supposed to be sleeping?
<lamont> busted,
<fabbione> lamont: btw.. the info i gave you yesterday.. are they enough or you need more?
<lamont> btw, gcc-{3.3,3.4,4.0} are in the archive for hppa
<lamont> or will be tonight.. 4.0 is uploading
<fabbione> ok
<lamont> I think it's enough
<fabbione> do you still want hppa on 3.4 or 3.3?
<lamont> hppa will stay with the pack
<fabbione> (btw.. he is testing a "clean" linux kernel.. we don't patch for ipv6)
<lamont> so if you move everyone, move hppa.  otherwise, it does just fine with 3.4
<fabbione> ok
<fabbione> well i am more for keeping all in sync
<fabbione> so we have only 2 exceptions.. ppc64 needs 3.4 and ia64 needs 3.3
<lamont> and even the ia64 issue is quite likely not gcc-3.4, but rather something else...
<fabbione> i am waiting one guy to test sparc
<lamont> it would help my laziness if a daily d-i build picked up a 3.3-based kernel.  But that's just me being lazy...
<lamont> I can netboot to test it quite easily as well...
<fabbione> lamont: don't you have debian installed there?
<lamont> yep
<fabbione> well you can install our kernel there...
<lamont> it has a debian partition, and an ubuntu-hoary partition
<fabbione> at least it should be possible
<fabbione> so why do you need to netboot?
<lamont> because it's less steps to netboot than to boot, copy, reboot, curse, reboot, iterate
<fabbione> eheh
<lamont> but not many less, since that's also the build machine for me to do test builds on...
<fabbione> if i get the time i will build the kernel for you
<lamont> so not much diff
<fabbione> halley is pretty fast
<lamont> iz not a big deal - I just need to actually make time to start the build - it'll build faster on my machine than in the DC anyway, so ...
<fabbione> ah
<fabbione> ok :)
<lamont> but for now, back to bed.  binutils is chunking along, and I don't want to wait for it's build to finish just to see how dbus did
<fabbione> hehe
<fabbione> good night
<doko> lamont: the next gcc-defaults update to unstable can be synced, and will make gcc-4.0 the default again
<fabbione> doko: any news about the PPC ICE?
<doko> no, not yet.
<doko> btw, do you really need/want gcc-3.3 biarch? it looks doable, but it costs some time ...
<fabbione> doko: no.. don't worry
<fabbione> i will manage it in another way
<fabbione> if it will become an issue i will tell you per time
<fabbione> oh new gcc4 is almost done on sparc :)
<fabbione> doko: promise no more gcc4 upload for the week, ok? ;)
<doko> fabbione: next one will be needed, when seb128 uploads cairo 0.6
<fabbione> doko: yeah.. just not in the next 2 hours :)
<doko> fabbione: the ppc problem was 32bit?
<fabbione> both
<fabbione> 32 and 64
<doko> hmm, ok. I did prepare a new gcc-snapshot, but this one is not yet biarch. I'll try to reproduce it on davis, when it's built.
<fabbione> doko: if i have a dynamically linked binary.. what command should i use to make it static?
<doko> fabbione: link using gcc -static
<fabbione> gcc -static ld
<fabbione> ../sysdeps/i386/elf/start.S:115: undefined reference to `main'
<fabbione> collect2: ld returned 1 exit status
<fabbione>  gcc -static ld
<fabbione>  /usr/lib/gcc/i486-linux-gnu/4.0.1/../../../crt1.o: In function `_start':
<fabbione> i mean.. ld is already an elf binary
<fabbione> bah i hate to change build stuff
<doko> ehh, no you can't change an existing executable, AFAIK
<fabbione> so i guess i need to do 2 builds to get one shared and one static...
<doko> or just find the line, and call make explicitely to link ld statically
<fabbione> hmm yeah.. that would work too, but it needs to be multi-archaware i guess
<lamont> doko: re 4.0 defaults, I believe the current source already does that too.
<fabbione> hey lamont
<fabbione> i just uploaded 4.4
<fabbione> so you can give it a shot on ia64 + gcc-3.3
<fabbione> it builds fine on hppa.. so you don't need to babysit it
<infinity> doko : gcc-snapshot is FTBFS on amd64, whining about lib32 issues.
<desrt> fabbione; everything is working perfectly.  thank you very much for your efforts.
<doko> infinity: yes, seen it. the default is now to build biarch, so yo have to disable it explicitely
<doko> lamont: what's wrong with 4.0?
<lamont> ??
<lamont> doko: ECONTEXT
<doko> lamont: you were complaining about gcc-4.0, but people seem to consider this good style, so don't care ;-)
<lamont> doko: no.  I was complaining about glibc
<lamont> and how it's b0rked
* lamont uploads  gcc-4.0_4.0.1-2ubuntu3_hppa
<doko> infinity: I did close the "poor GCC install" report again
<doko> fabbione: elmo did install a biarch gcc-snapshot on davis/breezy-ppc64, please let me have some cpu time ...
#ubuntu-toolchain 2005-07-28
<fabbione> mornign
<infinity> fabbione : New kernel BUGs on my machine when hald runs.
<infinity> fabbione : Reproducible.
#ubuntu-toolchain 2005-07-29
<fabbione> morning
<fabbione> doko: ping?
<doko> fabbione: pong
<fabbione> doko: thanks.. i solved :)
<fabbione> btw i read the email about gcc-snap
<fabbione> it think you should just forward upstream
<fabbione> i see no point in you getting crazy to fix it
<doko> yep, don't build the current version on sparc, I need another upload to fix a FTBFS on hppa
<fabbione> doko: right now sparc is busy with main
<fabbione> it won't get to universe for a while
<doko> fabbione: could you reproduce the ICE in the kernel build on davis/breezy-ppc64?
<fabbione> again?
<doko> with gcc-snapshot
<fabbione> is it installed in the breezy chroot?
<doko> no, breezy-ppc64
<fabbione> will try
<fabbione> but you have all the info to reproduce the ICE
<doko> I have to search my email ...
<fabbione> so because you are lazy, i need to spend an hour building? :P
<fabbione> that's ok don't worry.. i will do it on monday
<fabbione> i am still working in the office today to clean up
#ubuntu-toolchain 2005-07-30
<fabbione> morning
<desrt> word.
<fabbione> hey desrt 
<fabbione> happy with your new headers?
<fabbione> desrt: btw i did look at that driver you requested
<fabbione> i might included it in the next kernel
<fabbione> (was too close to release for the previous)
<fabbione> but you need to get somebody to pkg the utilities
<desrt> fabbione; oh.  i didn't know you received those bugs :)
<desrt> and yes.  the headers are working flawlessly.  thank you very much :)
<fabbione> desrt: i get them automatically :)
<desrt> i love bugzilla :)
<fabbione> i don't
<fabbione> it tells me that i suck at maintaining the kernel :P
<desrt> oh.  why not?
<desrt> no.  it tells you that maintaining a kernel is a hard job
<fabbione> nah just kidding ;)
<desrt> btw... the first time i ever talked to you was at jdub's recommendation... almost 6 months ago
<desrt> i don't know if you remember why that was
<fabbione> hmmm i can't really remember...
<desrt> gamin.
<fabbione> probably.. gamin sucks :P
<desrt> and the reason i brought it up: still some cases where it stops working :/
<fabbione> ahhh yeah
<fabbione> now i reacall
<desrt> my desktop stopped updating again yesterday
<fabbione> there is probably nothing to update :)
<fabbione> it was sunday
<desrt> no.. i mean, i was saving files with firefox
<desrt> and i had to ctrl+r the desktop to get them to appear
<fabbione> what kernel?
<desrt> 2.6.12-whatever
<desrt> 3?
<fabbione> because the latest gamin needs the latest kernel
<desrt> -4
<desrt> oh hmmm
<fabbione> inotify did change from something to ioctl...
<fabbione> or whatever...
<desrt> maybe i installed a new gamin but had an old kernel
<fabbione> and they need to be synced
<desrt> and have only recently rebooted
<fabbione> mostlikely
<desrt> ok
<desrt> hm
<desrt> actually, it's broken right now
<desrt> Linux moonpix 2.6.12-4-686-smp #1 SMP Fri Jul 22 12:56:02 UTC 2005 i686 GNU/Linux
<desrt> i just touched a file on my desktop... nautilus doesn't show it until manual refresh
<fabbione> can you check if dmesg has comething?
<fabbione> something...
<desrt> what am i looking for?
<fabbione> dunno
<fabbione> anything ...
<desrt> [4294670.897000]  inotify syscall
<desrt> this is all, really
* fabbione sighs
<fabbione> ok i will need to check gamin source and our inotify patch
<fabbione> perhaps the syscalls aren't synced properly
* desrt checks a few more things here
<fabbione> i am pretty sure i have an idea of what's broken...
<desrt> btw: restart nautilus -> works fine again
<fabbione> hmm
<fabbione> i wonder if it is a nautilus issue
<fabbione> if the syscalls were not synced, it wouldn't work at all
<fabbione> desrt: there is a tutorial on the gnome/gain website
<fabbione> that explains how to debug gamin
<infinity> (Like when running a breezy kernel on hoary, for instance)
<infinity> God, my lack of updating desktop is irritating.
<desrt> infinity; you too?
<fabbione> iirc sending a kill -USR2 to the gamin process will enable and dump debugging info in /tmp
<desrt> oh.  that's useful.
<fabbione> infinity: yes.. you cannot run breezy kernels on hoary
<infinity> desrt : Yes, but I know why mine doesn't work. :)
<desrt> infinity; :)
<fabbione> desrt: but please check the website for the correct signals
<desrt> mine looks just like the same old bug that was a problem around hoary-prerelease time
<fabbione> and be sure to issue the command once again to stop it :)
<infinity> fabbione : Sure I can, I just have a few broken features.  On the other hand, my network works and my machine doesn't crash.  The machine's going breezy once I make X less suck.
<desrt> fabbione; produces fabulous amounts of output? :)
<fabbione> desrt: quite :)
<fabbione> infinity: yeah well.. broken features for you are show stoppers for users
<fabbione> infinity: you know that ;)
<infinity> ;)
<fabbione> fantastic..
<desrt> fyi, http://www.gnome.org/~veillard/gamin/debug.html
<fabbione> fresh breezy install.. X manages to hang my keyboard because fixed fonts are missing....
<fabbione> LOVELY
<desrt> fixed fonts aren't missing
<desrt> mkfontdir is missing
<desrt> X can't generate the fontdir cache... therefore can't find any fonts
<infinity> It's not "missing", it's just gone for a bit of a jaunt around the block.
<desrt> well... i'll be very happy when it gets back from its jaunt :)
<infinity> People get so upset about the smallest binaries...
<desrt> mkfontdir, xset, xkb*, xmodmap, ...
<infinity> desrt : It's all coming back in good time.
<desrt> i copied all of the stuff i needed (including fontdir caches) in from my laptop :)
<infinity> SOme of the xbk stuff already came back in xkbutils.
<fabbione> now.. where is daniels when i need to test my new dildo set?
<desrt> fabbione; those new USB-powered dildos?
<infinity> I'd be nice to him, if I were you.
<infinity> We still need to assing the "make sure X upgrades smoothly from hoary" task to someone.
<fabbione> desrt: yes.. with IRDA remote control support ;)
<fabbione> infinity: remember that i did Xfree86 -> Xorg
<fabbione> infinity: i know what we are talking about
<fabbione> and Xorg -> Xorg is simpler
<infinity> (Daniel's got the "make it modular and make it work" task, and I've got the "make sure the bloody thing builds in a deterministic and bootstrappable fashion" task...)
<fabbione> infinity: btw.. xkbdutils didn't enter the archive yet?
<infinity> Yeah, upgrading is the simplest of the bunch, but it's still going to nee a mess of testing, and soon.
<infinity> Oh, is it still NEW?  Or did I get the name wrong?
<fabbione> no idea.. you tell me :)
<infinity> Or... It's FTBFS, and I've been too busy to notice.
* infinity runs to fix that.
<fabbione> i got the new libxaw.. that's good
<fabbione> what pkg has mkfontdir now?
<fabbione> daniels: ?
<fabbione> modprobe -k dildo
<fabbione> USB: Detected sodomotron on port 1:1.1
<fabbione> USB: enabling /dev/sodomotron device for immediate access
* infinity uploads a new libxaw...
<desrt> one day... one day i will upload.
<fabbione> hmmm i can't remeber how i did fix the KBD problem...
<fabbione> AH RIGHT
<fabbione> xkbdutils :)
<fabbione> dpkg-deb: building package `xkbutils' in `./xkbutils_7.0-2_i386.deb'.
<daniels> fabbione: mkfontdir doesn't really exist right now
<daniels> i'll fix that tonight
<daniels> not at home at the moment
<daniels> and yeah, I'll be making sure upgrades work fine, but right now they're not even close
<fabbione> daniels: eheh dude... you know how much i love to tease you
<daniels> xkbutils got source ACCEPTED, but still needs its binaries NEWed
<fabbione> but i need to get a working breezy on one machine
<fabbione> and i am checking all the gotchas
<daniels> yeah, fair enough
<daniels> it's still a work in progress :) but gotta run now
<daniels> later
<fabbione> (EE) Couldn't load XKB keymap, falling back to pre-XKB keymap
<fabbione> (EE) Couldn't load XKB keymap, falling back to pre-XKB keymap
<fabbione> daniels: help me only one sec
<fabbione> i fixed it yesterday.. but i can't remember how
<fabbione> do you recall it?
<desrt> fabbione; you can just copy the fonts.cache-1 files from another box
<fabbione> desrt: i already fixed the fonts problem
<infinity> daniels : Binaries kinda had to build first.  *cough*
<desrt> :)
<infinity> daniels : I just uploaded a new libxaw that xkbutils is now build-dep on.
<desrt> you guys never dpkg-buildpackage, right?  you just upload the source package to the build farm....
<infinity> dpkg-buildpackage -S :)
<fabbione> i do
<infinity> But yes, I do binary builds before I upload.
<infinity> I just don't upload the binaries.
<infinity> I do "dpkg-buildpackage -uc -us -S ; dpkg-buildpackage -uc -us -b"... If the latter succeeds, I sign and upload the results of the former.
<desrt> is the ftp archive signing machine-generated?
<fabbione> desrt: ?
<desrt> the binary .deb's are signed by "ftpmaster@ubuntu.com"
<fabbione> the .deb are not signed
<infinity> The uploads are.
<desrt> but aren't the actual .deb's md5'd and then the list is signed?
<desrt> like, the actual binary debs
<fabbione> desrt: nope...
<fabbione> there is no need to
<infinity> Yes.  The binary .changes are signed.
<fabbione> desrt: only the sources are signed
<infinity> fabbione : The binaries are too, dude.
<desrt> then what's the point of apt-key and why does apt-get sometimes warn you about unauthenticated packages?
<fabbione> infinity: yeah but in the .changes
<infinity> fabbione : Yes, that's what he was talking about.
<fabbione> there is no signatures of the md5 inside the deb
<desrt> right.. i think it's in the Releases file
<fabbione> desrt: it's a chain
<fabbione> basically you verify that the Release file has a good signature
<fabbione> that means that the Packages.gz can be trusted via md5 check on top of the Release file
<infinity> desrt : That is the Releases file, which verifies the integrity of the Packages file, which verfies the integrity of the debs, which were verified by a signed .changes when they were uploaded.
<infinity> And yes, Releases.gpg is autosigned.
<desrt> infinity; gotcha.  thanks :)
<infinity> Release.gpg, even.
<fabbione> if the Contents of Packages is verified, it means that the md5 contained in it for the binary debs can be trusted
<desrt> makes sense
<desrt> i imagine that we can't be too far away, though, from someone being able to feasibly calculate MD5^-1(x)
<infinity> MD5 can be broken, but can you break it AND deliver data that does something useful (or malicious)?
<infinity> That's a much bigger challenge.
<desrt> well... you can write a bad package
<infinity> Collisions can happen.  Interesting collisions, I'm not so sure about.
<desrt> then add some useless padding bytes into the end of it to make the md5 match
<infinity> Harder than you'd think.
<infinity> Especially since the file size also has to match.
<desrt> difficult... but md5 is getting weaker by the day
<fabbione> desrt: that's why the Release contains also teh SHA1
<infinity> I suspect a picture of my cat probably has the same MD5 as libc6.deb, but I'm not sure how I can use this to take over the world.
<desrt> that i didn't know.
<fabbione> and mathing both md5 adn sha1 at the same time is impossible
<desrt> that makes it very much more difficult
<infinity> fabbione : It's the sha1 of the Packages file, we don't carry the sha1 of the debs.
<desrt> plus.. honestly
<infinity> fabbione : So you could still poision individual debs.  But really, I think the argument is moot.
<desrt> half the time it says "packages can't be authenticated" i just hit "yes, continue" anyway
<desrt> so who cares :)
<infinity> If I have access to poision you in such a sophisticated way, I can probably do something muhc simpler to you.
<fabbione> desrt: echo 'APT::Get::AllowUnauthenticated "1";' > /etc/apt/apt.conf
<fabbione> and you will forget even to press enter ;)
<desrt> nah... i'd at least like it to tell me :)
<infinity> It still tells you.
<infinity> It just doesn't pause for confirmation.
<infinity> "Foo bar baz are unauthenticated, but installing anyway, cause the override is on <zooom!>"
<jbailey> lamont: *poke*
<jbailey> lamont: I still need you to let me know if I can book you soonish for another biarch setup, or if infinity is capable of doing it.
<jbailey> lamont: doko is threatening to beat me...
<jbailey> And as interesting as that sounds, Angie is the jealous type.
<fabbione> doko: gcc-snapshot is running the testsuite here... on sparc
<doko> fabbione: it's not biarch, that's the reason it works
<fabbione> ah
<fabbione> ok
#ubuntu-toolchain 2005-07-31
<fabbione> morning
<jbailey> fabbione: ping?
<fabbione> jbailey: pong?
<jbailey> fabbione: Is that what you needed for binutils?
<fabbione> i didn't get there yet :( i am almost very close to it
<fabbione> but yes it's a static one.. so it's fine
<jbailey> 'k
<fabbione> we might have to check another thing, but it's not sure yet 100%
<fabbione> i will let you know asap
<jbailey> Cool.  I also wasn't sure which bfd targets you'd need, so I left it at the default.  I can reduce it to just the local architecture, but I figured I should do that once you had stuff to test with to make sure I'm  not brekaing it.
<fabbione> thanks.. 
<fabbione> i will let you know :)
<fabbione> i had to spend the morning figuring a lot of other bits still related to that
<fabbione> and i just landed at the step of using ld :)
<fabbione> but i need to go out for an hour or so
<fabbione> to buy a couple of video cards
<fabbione> and i will be back
<jbailey> Cool.
<doko> jbailey: the glibc biarch build for amd64 should be doable without ftp-master interaction?
<jbailey> doko: without elmo, yes.  Without lamont/infinity, I don't think so.
<jbailey> I'm buying an amd64 later today so that I can do this.
<doko> why? it currently builds, because there are still working ia32-libs-dev
<jbailey> Err.
<jbailey> Sorry, I was thinking on i386 for i386/amd64
<jbailey> Do you mean on amd64 for amd64/i386 ?
<doko> yep, that one doesn't work
<doko> I mean both :)
<jbailey> arch: amd64 should be Just doable, I think.
<jbailey> arch: i386 I think might need extra love.
<doko> it should be possible to make amd64-libs obsolete on i386 for breezy
<jbailey> right.
<jbailey> And all those changes will be easy to push into Debian.
#ubuntu-toolchain 2006-07-26
<rodarvus> hi there
<rodarvus> any hints on why this build failure happened? -> http://librarian.launchpad.net/3573913/buildlog_ubuntu-edgy-sparc.xorg-server_1%3A1.1.1-0ubuntu1_FAILEDTOBUILD.txt.gz
<rodarvus> I attempted to connect to faure to reproduce this myself, but my account can't connect there (even though faure is listed as a porter machine)
<rodarvus> this package builts successfully on i386 and amd64 at least (building on other platforms right now)
<rodarvus> (just for reference) asm/kbio.h is not found. This file is included on sparc only
<Keybuk> rodarvus: kernel-headers bug, I'd guess
<rodarvus> Keybuk, yeah, my guess too
<doko> $ dpkg -S kbio.h
<doko> dpkg: *kbio.h* not found.
<doko> looks so ...
<jbailey> rodarvus: faure falls over dead on a regular basis, I think.
<jbailey> rodarvus: Best to file an RT ticket to get it reset.
<doko> rodarvus: time to join #ubuntu-kernel ;-P
<rodarvus> :)
<doko> jbailey: now it's up and running
<jbailey> rodarvus: But it's entirely possible that some headers and such are still missing from the transition to the kernel taking over allof that.
<rodarvus> ah, faure is back, indeed - thanks jbailey!
<rodarvus> doko, I'll ask on #ubuntu-kernel, thanks for the help :)
#ubuntu-toolchain 2006-07-27
<jbailey> doko: Ran my box out of drive space last night, restarted the build this morning.
<doko> jbailey: ouch
<jbailey> rodarvus: Is there an #ubuntu-x channel where I should lurk before filing random bugs? =)
<rodarvus> yes, #ubuntu-x :)
<jbailey> Whee!
<jbailey> doko: Going into the testuite with 900MB Free this time.  SHould be much better. =)
<jbailey> doko: Remind me, are you doing gcj-4.2 for edgy, or sticking with 4.1?
<doko> jbailey: didn't look too careful ... FC seems to have a backport of the gcjwebplugin patches to the 4.1 branch. Maybe I'll look at that one.
<jbailey> Ah, interesting.
<jbailey> I know that gcjwebplugin is now integrated into classpath itself upstream.
<jbailey> doko: Starting glibc build with rebuilt gcc
<jbailey> doko: The solves the glibc build failure on ppc.
<doko> jbailey: so that was the a rebuilt gcc with ssp turned off?
<jbailey> Yeah, lemme debdiff for you.
<doko> hmm, strange
<pitti> hi
<doko> hi
<pitti> one minute, please
<jbailey> Heya Martin!
<doko> glibc on powerpc doesn't build anymore with the ssp enabled gcc
<pitti> argh argh
<pitti> hm, it built before, didn't it?
<jbailey> pitti: Haven't had a chance to go through and really debug why, but it's an interesting problem.
<jbailey> glibc itself does -fstack-protector when available.
<pitti> right
<pitti> so gcc falls over if you specify -fs-p explicitly?
<jbailey> glibc, but yes.
<jbailey> It seems to cause some sort of symbol leak resulting in a link error.
<pitti> oh, ok, so glibc must be fixed, not gcc?
<pitti> jbailey: interesting, I saw a similar bug when building postgresql on sid, remember?
* pitti actually looks at build log
<pitti> " edgy powerpc   Successfully built"
<pitti> hm, that won't help me
<jbailey> pitti: I'm not sure who's bug it is.  glibc is correct for an upstream gcc and DTRT for stack protection for itself.
<pitti> is there any build log somewhere?
<doko> jbailey: when calling gcc -E, I currently do not turn on -fstack-protector, resulting in a missing __SSP__ define. but that should be consistent across architectures
<pitti> ouch, SSP influences -E?
<pitti> I thought inline functions and such were only decorated with -fstack-protector-all or oso
<doko> I only say, that a macro is defined. 
<pitti> ah
<pitti> jbailey: so, it fails for you locally?
<jbailey> pitti: Yes.
<doko> jbailey: amd64 and i386 builds fail as well
<jbailey> doko: Thanks.
<jbailey> I didn't have much time to research it with the sprint last week.
<jbailey> I can try to look through it this weekend, I guess.  I'm behind on so many things right now.
<doko> gcc-4.1   -nostdlib -nostartfiles -r -o /home/packages/glibc/u/glibc-2.4/build-tree/amd64-libc/elf/librtld.map.o '-Wl,-(' /home/packages/glibc/u/glibc-2.4/build-tree/amd64-libc/elf/dl-allobjs.os /home/packages/glibc/u/glibc-2.4/build-tree/amd64-libc/libc_pic.a -lgcc '-Wl,-)' -Wl,-Map,/home/packages/glibc/u/glibc-2.4/build-tree/amd64-libc/elf/librtld.mapT
<doko> /home/packages/glibc/u/glibc-2.4/build-tree/amd64-libc/libc_pic.a(init-first.os):(.data+0x0): multiple definition of `__libc_multiple_libcs'
<doko> /home/packages/glibc/u/glibc-2.4/build-tree/amd64-libc/elf/dl-allobjs.os:(.bss+0xec): first defined here
<doko> /home/packages/glibc/u/glibc-2.4/build-tree/amd64-libc/libc_pic.a(_itoa.os): In function `_itoa':
<doko> _itoa.c:(.text+0xb0): multiple definition of `_itoa'
<doko> /home/packages/glibc/u/glibc-2.4/build-tree/amd64-libc/elf/dl-allobjs.os:(.text+0x13960): first defined here
<doko> /usr/bin/ld: Warning: size of symbol `_itoa' changed from 120 in /home/packages/glibc/u/glibc-2.4/build-tree/amd64-libc/elf/dl-allobjs.os to 432 in /home/packages/glibc/u/glibc-2.4/build-tree/amd64-libc/libc_pic.a(_itoa.os)
<pitti> jbailey: curious why it works on the buildds
<doko> collect2: ld returned 1 exit status
<doko> that is amd64 ...
<jbailey> pitti: It didn't.
<doko> pitti: we didn't try yet :)
<jbailey> pitti: The last glibc build on the buildds was before the forced ssp change.
<pitti> oh
<doko> gcc-4.1   -nostdlib -nostartfiles -shared -o /home/packages/tmp/glibc-2.4/build-tree/i386-libc/elf/ld.so                        \
<doko>                   -Wl,-z,combreloc -Wl,-z,relro -Wl,-z,defs     \
<doko>                   /home/packages/tmp/glibc-2.4/build-tree/i386-libc/elf/librtld.os -Wl,--version-script=/home/packages/tmp/glibc-2.4/build-tree/i386-libc/ld.map                \
<doko>                   -Wl,-soname=ld-linux.so.2 -T /home/packages/tmp/glibc-2.4/build-tree/i386-libc/elf/ld.so.lds
<doko> /home/packages/tmp/glibc-2.4/build-tree/i386-libc/elf/librtld.os: In function `process_dl_debug':
<doko> /home/packages/tmp/glibc-2.4/build-tree/glibc-2.4/elf/rtld.c:2452: undefined reference to `__stack_chk_fail_local'
<doko> /home/packages/tmp/glibc-2.4/build-tree/i386-libc/elf/librtld.os: In function `process_envvars':
<doko> /home/packages/tmp/glibc-2.4/build-tree/glibc-2.4/elf/rtld.c:2711: undefined reference to `__stack_chk_fail_local'
<doko> /home/packages/tmp/glibc-2.4/build-tree/i386-libc/elf/librtld.os: In function `dl_main':
<doko> /home/packages/tmp/glibc-2.4/build-tree/glibc-2.4/elf/rtld.c:2332: undefined reference to `__stack_chk_fail_local'
<doko> /home/packages/tmp/glibc-2.4/build-tree/i386-libc/elf/librtld.os: In function `print_search_path':
<doko> /home/packages/tmp/glibc-2.4/build-tree/glibc-2.4/elf/dl-load.c:1548: undefined reference to `__stack_chk_fail_local'
<doko> /home/packages/tmp/glibc-2.4/build-tree/i386-libc/elf/librtld.os: In function `open_verify':
<doko> /home/packages/tmp/glibc-2.4/build-tree/glibc-2.4/elf/dl-load.c:1762: undefined reference to `__stack_chk_fail_local'
<doko> /home/packages/tmp/glibc-2.4/build-tree/i386-libc/elf/librtld.os:/home/packages/tmp/glibc-2.4/build-tree/glibc-2.4/elf/dl-load.c:1917: more undefined references to `__stack_chk_fail_local' follow
<doko> collect2: ld returned 1 exit status
<pitti> hm, that's strange -- glibc itself is shipping __stack_chk_fail()
<pitti> so it should have _local as well...
<jbailey> Right, so I'm confused by this.
<jbailey> Also by the need to patch in libssp into gcc itself.
<jbailey> vacuum coming through, bbias.
#ubuntu-toolchain 2006-07-28
<pitti> hm, so it seems that glibc wants to build some parts of it without ssp
<doko> jbailey: no, libssp0 isn't really used, I should not build it, if we build on a glibc-2.4 based system
<pitti> doko: hm, am I right that using something like "CC=gcc-4.1 -fno-stack-protector" should be exactly equivalent to the state gcc-4.1 was when it built the current glibc?
<pitti> doko: then glibc would add -fstack-protector when it actually wants it, and for the cases it doesn't explicitly add it we would get the non-ssp behaviour again
<doko> pitti: yes, that should do it
<pitti> ok, worth a try in any case. I'll start a test build now, it should finish by the end of the meeting
<pitti> 'k, I modified debian/rules, running now
<doko> pitti: powerpc?
<pitti> no, amd64
<pitti> <doko> jbailey: amd64 and i386 builds fail as well
<pitti> ^ so testing on amd64 should be fine?
<pitti> my laptop still runs dapper, and would take ages anyway
<pitti> if I should test it on powerpc, I'll rather request the b-deps on davis
<doko> pitti, jbailey: amd64 build using -fno-stack-protector succeeded
<pitti> oh, they are there (the b-deps) on davis, how convenient
<pitti> doko: ok, then your build was way faster
<pitti> doko: I start a ppc test build now if you want me to
<pitti> doko: on my amd64, I changed CC, but changing {BUILD,HOST}_CFLAGS should work as well; what did you use?
<pitti> ok, ppc test build with 'CC=gcc-4.1 -fno-stack-protector' is running
<pitti> jbailey: indeed most of the files in glibc are *not* build with explicit -fstack-protector; only 48 of them
<pitti> so maybe upstream saw the same problem and is only gradually enabling it, who knows
<pitti> hm, amd64 failed for me
<pitti> when building the i386 version
<pitti> checking for forced unwind support... no
<pitti> configure: error: forced unwind support is required
<pitti> also,
<pitti> checking for -fstack-protector... no
<pitti> ^ for the i386 build
<pitti> the amd64 build worked fine
<pitti> jbailey: hm, powerpc fails as well, but due to a completely unrelated issue
<pitti> ../sysdeps/unix/sysv/linux/powerpc/sys/procfs.h:56: error: conflicting types for 'elf_vrreg_t'
<pitti> /home/pitti/glibc/glibc-2.4/debian/include/asm/elf.h:153: error: previous declaration of 'elf_vrreg_t' was here
<pitti> and similar errors before that
<doko> i386 works fine for me as well ...
<pitti> hmm
<doko> I have a slightly newer compiler version, but I doubt that changes anything
<pitti> certainly not wrt that double declaration
<pitti> maybe the davis chroot has an older compiler version
<doko> no, I asked for dist-upgrades this or last week
<pitti> hm, indeed it's the last version
<jbailey> pitti: Right, that's a conflict in lkh tha tI need to work around, but that's easy enough.
<jbailey> Sorry about the lag, had a meeting.
<doko> jbailey: both i386 and amd64 build with -fno-stack-protector. cannot check the powerpc build.
<doko> so it looks the outstanding issue is still long-double-128 ...
<jbailey> Right, ppc I can get to build base don what I've seen
<jbailey> I haven't looked much into the ldbl-128 stuff.  My understanding was that there were supposed to be compat symbols and handling for pre-stuff.
<jbailey> Is that not the case?
<doko> jbailey: no, take the libstlport4.6 from dapper, and try to link with it on a current edgy (I rebuilt libstlport4.6 this week, so you won't see it with the edgy stlport)
<jbailey> Cool, thanks.
<rodarvus> hi
<rodarvus> I just received a bug report on xserver-xorg-input-synaptics -> https://launchpad.net/distros/ubuntu/+source/xserver-xorg-input-synaptics/+bug/54357/
<rodarvus> dlopen: /usr/lib/xorg/modules/input/synaptics_drv.so: undefined symbol: __stack_chk_fail_local
<rodarvus> can this bug be somehow related to the stack protection changes which happened recently?
<pitti> hi
<rodarvus> hi pitti
<rodarvus> I just reported an (apparent) crash on xserver-xorg-input-synaptics here - do you want me to paste it to you in a private window?
<rodarvus> (there)
<doko> rodarvus: now you can try again ... ;-)
<pitti> yep, got it
<rodarvus> doko, thanks :)
<pitti> rodarvus: hm, I have no clue where __stack_chk_fail_local() is defined
<pitti> rodarvus: maybe the bst option is to build with -fno-stack-protector for now and keep a record of this in the SSP spec?
<rodarvus> sure, I'll do it
<rodarvus> I'll also ask ogra to test it to me before uploading, just to make sure all is fine
<jbailey> pitti: Do you know what order command line arguments take precidence?  I'm wondering if for glibc if I can do "gcc -fno-stack-protector", and still have it enabled on the files it wants by having it add it later in the command line itself.
<jbailey> I'll try it a bit later.  I have a couple urgent things first.
<pitti> jbailey: yes, last one wins
<doko> jbailey: you could check, if the __SSP__ macro is defined. but IIRC the last one wins
<jbailey> Nice.  I'll try that for the glibc builds then.
<pitti> jbailey: yesterday's test build went well with 'CC=gcc-4.1 -fno-stack-protector'
<pitti> jbailey: apart from the duplicate symbol on powerpc that I pasted
<pitti> rodarvus: ok, I add it to the wiki page so that we have a reference
<pitti> rodarvus: is there an LP bug for it?
<jbailey> Duplicate symbol?
<jbailey> You mean the elf_vrrg_reg thing?
<pitti> might be, yes
<rodarvus> pitti, yes bug 54357
<rodarvus> pitti -> https://launchpad.net/distros/ubuntu/+source/xserver-xorg-input-synaptics/+bug/54357/
<pitti> rodarvus: ok, I added it to https://wiki.ubuntu.com/GccSsp
<jbailey> pitti: 'kay.  I'll run it...
<jbailey> or maybe I won't since my machine at home isn't on.
<jbailey> X bug that I filed earlier this morning.  *sigh*
<rodarvus> pitti, nice, thanks!
<jbailey> So it'll be tonight when I get home to roll back X.
<pitti> jbailey: use a DC porter machine?
<rodarvus> jbailey, I didn't saw this bug
<rodarvus> let me check
<rodarvus> jbailey, apparently x-swat was not subscribed to this bug
<jbailey> pitti: I could try, but in case I need to twiddle build-deps on something, I'd prefer to not half-start work in place and have to move it.
<rodarvus> jbailey, what # is it?
<jbailey> rodarvus: 54352
<pitti> rodarvus, doko: ah, interesting reading on http://linuxfromscratch.org/pipermail/hlfs-dev/2006-June/003031.html
<rodarvus> jbailey, thanks, I'll have a look at it later today, hopefully
<jbailey> rodarvus: Thanks, it appears to lock the machine solid, so I'm not sure how to get a bug report out of it.
<jbailey> rodarvus: Any suggestions on how to debug this would be good - I'm sure we'll run up against this type of bug in support occasionally.
<rodarvus> this kind of stuff is hard to debug, really -> a good start is the output of lspci -vv, Xorg.log.0 (if it is created) and if possible, Xorg.log.0.old (which should be from the previous version of the driver)
<rodarvus> knowing what board exactly is installed is helpful to track related changes in upstream git repository, and also to contact upstream authors
<jbailey> I'll see what I can drag up from the log files, but becaus eof the version skew on the ATI driver, I might not be able to get it.
<rodarvus> indeed
<jbailey> I upgraded the rest of X a day or so ago, but -ati- hadn't gone in, so X failed to load before.
<rodarvus> jbailey, appreciated!
<jbailey> Thanks.  It'll be tonight.  I'll also probably roll my machine back to the old version of X so I have it running, so I might get it for you that way ;)
<rodarvus> :)
<rodarvus> jbailey, you can probably also get the machine into a usable state by using the 'vesa' driver
<rodarvus> (instead of returning all of the X libraries and drivers to the previous version
<jbailey> Hmm.  For some reason I thoguht the R300s didn't have a working vesa mode.
<jbailey> Thanks for the reminder =)
<rodarvus> oh, its a R300
<rodarvus> that might explain a few things :D
<jbailey> Certainly ;)
<jbailey> R300 on ppc64 is generally known to be.. special.
<jbailey> But this is the first solid-hang on initialisation that I've seen with t.
<jbailey> I already have the hardware acceleration disabled, which usually solves most of the problems.
<rodarvus> hmm
* rodarvus takes notes
#ubuntu-toolchain 2007-07-23
<doko> infinity: any lpia news? else I would assume no news are good news =)
<Mithrandir> doko: he's in transit.
<doko> ahh, ok.
#ubuntu-toolchain 2015-07-20
<zaytsev> doko: hi, just a short question and specifically, any plans for toolchain test build of gcc 5.2 for precise?
<zaytsev> doko: i'm enjoying the gcc 5.1 builds from the toolchain ppa, simply indispensable
<doko> zaytsev, sure, but lack of time currently
<zaytsev> doko: awesome, many thanks, i'll wait
