[12:07] <siretart> looking at configure.ac, it seems just a matter of droppen build-deps. I'm checking that
[12:07] <mdz> i386 got lucky and built totem before the new xine-lib
[12:07] <Kamion> mdz: http://people.ubuntu.com/~cjwatson/livefs-build-logs/edgy/ubuntu/current/livecd-20060713-i386.out
[12:07] <Kamion> FYI, seems to have worked
[12:07] <mdz> Kamion: nice; if you want to roll a CD I'll give it a whirl
[12:07] <Kamion> I've kicked off an i386-only CD build
[12:07] <mdz> for giggles
[12:07] <Kamion> good luck :)
[12:08] <Kamion> I'm off to bed
[12:08] <mdz> night
[12:08] <Kamion> mdz: there are amd64 and i386 alternate CD builds up already, BTW
[12:08] <Kamion> they sort of work if you fudge the localechooser bug I fixed earlier today
[12:08] <Kamion> (edit /usr/bin/localechooser, put || true after all the db_unregister commands)
=== licio [n=licio@ubuntu/member/licio]  has joined #ubuntu-devel
[12:08] <mdz> Kamion: report.html is not very encouraging
[12:09] <Kamion> it seems to manage to install anyway; I tried it in vmware
[12:09] <Kamion> not exactly sure how
[12:09] <Kamion> though that was i386
[12:09] <mdz> ooh, hierarchical cdimage logs
[12:09] <Kamion> I assume X has managed to hit a corner case that confuses britney and not apt
[12:09] <Kamion> yeah, got bored of the mess and did that today
[12:10] <mdz> Kamion: X or python*
[12:10] <mdz> python* is confusing apt right now in many situations
[12:11] <Kamion> right, really bed
=== gnomefreak [n=gnomefre@ubuntu/member/gnomefreak]  has joined #ubuntu-devel
=== beeblebrox [n=chatzill@mg376.wolfson.cam.ac.uk]  has joined #ubuntu-devel
[12:25] <siretart> mdz: ok, I have now a xine-lib package prepared, which builds fine in my main/restricted only sbuild/amd64. vcd support is unclear, but at least it builds!
[12:25] <siretart> mdz: okay to upload? (I read in topic that uploads are restricted)
[12:28] <beeblebrox> hi, i was looking at the edgy repository and it seems that there is no trace of xorg 7.1 and gnome 2.15. any reason? isn't edgy supposed to be released in just 2.5 months with state-of-art packages?
=== theCore [n=alex@modemcable240.218-70-69.mc.videotron.ca]  has joined #ubuntu-devel
[12:30] <msw> beeblebrox: rodarvus is doing testing before uploading updated xorg stuff
[12:30] <slomo> beeblebrox: and gnome 2.15 is there
[12:34] <mdz> siretart: yes, please
=== _kylem [n=kyle@cabal.ca]  has joined #ubuntu-devel
[12:40] <jbailey_> _kylem: Heya kyle.
[12:40] <kylem> hi.
[12:40] <kylem> pay no attention to the man with the underscore.
[12:40] <jbailey_> kylem: That's one way to tell me you're going to ignore me ;)
[12:40] <kylem> heh.
[12:41] <kylem> not quite what i meant... :)
[12:43] <siretart> Hello kylem!
[12:43] <kylem> hi reinhard
=== human_blip [n=mike@220.157.65.29]  has joined #ubuntu-devel
[12:46] <siretart> mdz: xine-lib (main) and xine-extracodecs (multiverse) accepted
[12:46] <siretart> gn8 folks
[12:46] <mdz> thanks, night
[12:46] <slomo> siretart: gn8 and thanks for xine :)
=== elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk]  has joined #ubuntu-devel
=== Arrogance [n=aks@ottawa-hs-64-26-167-180.d-ip.magma.ca]  has joined #ubuntu-devel
[01:02] <rodarvus> beeblebrox: GNOME 2.15.4 is already in Edgy
[01:02] <rodarvus> XOrg 7.1 will (very likely) start being uploaded after Knot 1 is released
[01:03] <rodarvus> (but please don't take this as an official statement :) )
=== epx [n=Elvis@20150215070.user.veloxzone.com.br]  has joined #ubuntu-devel
[01:03] <bluefoxicy> Knot?  wtf isa knot
[01:03] <beeblebrox> rodarvus: thanks :)
[01:03] <jbailey_> bluefoxicy: The rodents are into bondage, apparently. =)
[01:03] <rodarvus> bluefoxicy: Edgy development milestones
[01:03] <sivang> heh
[01:03] <rodarvus> same as "flight" for Dapper
[01:04] <bluefoxicy> jbailey_:  err.. yeah you could say a LOT worse if you want to go that route.
=== jdub hugs jbailey_ 
[01:04] <bluefoxicy> but we won't go into that.
[01:04] <jbailey_> bluefoxicy: True.  I'm really looking forward to the openning quotation for the milestone releases.  I have some I could offer, but I think they might not be accepted... ;)
[01:04] <rodarvus> haha
[01:05] <bluefoxicy> I'm sure if I said anything about it they would change the name.
[01:05] <sivang> jbailey_: anything close to the lymmrick would be cool :)
[01:05] <bluefoxicy> just because the devs would not be able to look at it without cringing.
[01:06] <jbailey_> sivang: My limerick was pure angst.  I'm feeling much better now that I'm at home. =)
[01:06] <sivang> jbailey_: maybe, but it's driven *hours* of pure un adolterated laughter =)
[01:06] <sivang> jbailey_: and I'm glad you're feeling better.
[01:07] <jbailey_> sivang: hours?  Oh dear.
=== epx [n=Elvis@20150215070.user.veloxzone.com.br]  has joined #ubuntu-devel
[01:07] <sivang> jbailey_: oh well, hours is too much, but certainly some parts of some hours :)
[01:09] <bluefoxicy> jbailey_:  This is humorous.
=== jsgotangco [n=jsg123@ubuntu/member/jsgotangco]  has joined #ubuntu-devel
=== LaserJock chuckles for a while
=== hunger [n=tobias@p54A63FCF.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[01:10] <bluefoxicy> sivang:  limmerick?  I missed this.  Rafb please.
[01:11] <LaserJock> jbailey_: I think that was definately one of the highlights of the trip ;-)
[01:11] <jsgotangco> ahhh
[01:11] <LaserJock> made a long week of specs seem a whole lot better
[01:12] <bluefoxicy> jbailey_:  what are they talking about?
[01:12] <jsgotangco> i agree
[01:12] <sivang> LaserJock+++++
[01:12] <jbailey_> bluefoxicy: I had a brief moment where I forgot that I was an introvert at the UDS-Paris final dinner.
[01:12] <bluefoxicy> jbailey_:  and this is funny how?
[01:13] <jbailey_> bluefoxicy: When this sort of thing happens, it's apparently worthy of attention.
[01:13] <jbailey_> bluefoxicy: I'm not exactly objective, I'm not the right person to ask.
[01:13] <jsgotangco> you have to know/meet jbailey_ personally
[01:13] <LaserJock> bluefoxicy: sorry, I think you had to be there
=== jsgotangco remembers the scenes at the hotel lobby at dawn
[01:14] <LaserJock> bluefoxicy: jbailey_ had a wonderful limmerick full of angst, amongst other things :-)
=== gnomefreak [n=gnomefre@ubuntu/member/gnomefreak]  has joined #ubuntu-devel
[01:14] <bluefoxicy> LaserJock:  it's not something I can google for is it?  :>
[01:14] <LaserJock> nope
[01:14] <sivang> jbailey_: you're use of words...oh man, it is a master piece, what made it so funny for me , was, that I couldn't have put it better. It had much of the truth in it :)
[01:14] <bluefoxicy> also jeff
[01:15] <sivang> bluefoxicy: and better not find it there :)
[01:15] <bluefoxicy> do you have any relation to Justin Bailey?
[01:15] <bluefoxicy> (this guy on another channel's real name was that!)
[01:16] <jsgotangco> oh goodie no email for me
=== j_ack [n=nico@p508D9AE4.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[01:22] <sivang> anywya, slipping out from my timezone again, night all
[01:22] <slomo> sivang: gn8 :)
[01:25] <sivang> night slomo :) 
=== Toadstool is now known as ToadZzZztool
=== freeflying|away [n=freeflyi@ubuntu/member/freeflying]  has joined #ubuntu-devel
=== rpedro_ [n=rpedro@87-196-103-156.net.novis.pt]  has joined #ubuntu-devel
=== kintaro [n=ad0lf@203.177.212.164]  has joined #ubuntu-devel
=== RadiantFire [n=ryan@c-69-180-43-27.hsd1.ga.comcast.net]  has joined #ubuntu-devel
=== zul [n=chuck@ubuntu/member/zul]  has joined #ubuntu-devel
=== zenrox [n=zenrox@71.115.198.118]  has joined #ubuntu-devel
=== TheMuso [n=luke@ubuntu/member/themuso]  has joined #ubuntu-devel
=== lloydinho [n=andreas@rosinante.egmont-kol.dk]  has joined #ubuntu-devel
=== Huahua [n=hua_@123.49.238.139]  has joined #ubuntu-devel
=== j_ack [n=nico@p508D9AE4.dip0.t-ipconnect.de]  has joined #ubuntu-devel
=== FunnyLookinHat [n=funnyloo@71.57.11.218]  has joined #ubuntu-devel
=== AlinuxOS [n=alinux@d83-176-125-188.cust.tele2.it]  has joined #ubuntu-devel
=== DB2 [n=icebreak@l85-130-147-50.broadband.actcom.net.il]  has joined #ubuntu-devel
[02:55] <DB2> hi, can anybody explani me gaim-dev?
[02:55] <tseng> whats to explain?
[02:56] <DB2> if i wanna make a gaim plugin, what do i need ?
[02:56] <tseng> gaim-dev, and possibly others.
[02:56] <tseng> depending on the package
[02:56] <DB2> is there a documentation on how do i use it ?
[02:57] <jsgotangco>  If you are creating a gaim plugin package, please be sure to read
[02:57] <jsgotangco>  /usr/share/doc/gaim-dev/README.Debian.dev after installing gaim-dev.
[02:57] <jsgotangco> aptitude show gaim-dev
[02:57] <DB2> yeah, it doesnt say anything
[02:57] <jsgotangco> DB2: ^^
[02:57] <jsgotangco> ahh
[02:57] <DB2> i've seen that
[02:58] <jsgotangco> gaim site doesn't have documentation?
[02:58] <DB2> pretty useless of instruction of how to compile a plugin
[03:00] <zul> have you checked gaims website?
[03:01] <DB2> trying
[03:04] <DB2> where do i d/l the gaim source used in ubuntu?
=== rodarvus [n=rodarvus@ubuntu/member/rodarvus]  has joined #ubuntu-devel
[03:07] <DB2> nm
=== thunderstruck [n=thunders@ubuntu/member/gnomefreak]  has joined #ubuntu-devel
=== Burgundavia [n=corey@ubuntu/member/burgundavia]  has joined #ubuntu-devel
=== asac_ [n=asac@debian/developer/asac]  has joined #ubuntu-devel
=== Ubugtu [n=bugbot@ubuntu/bot/ubugtu]  has joined #ubuntu-devel
=== asac_ is now known as asac
=== Hobbsee [n=Hobbsee@ubuntu/member/hobbsee]  has joined #ubuntu-devel
[03:42] <Hobbsee> hi all
=== human_blip [n=mike@220.157.65.29]  has joined #ubuntu-devel
[04:25] <theCore> vuntz: do you know where the script for the logout dialog is located?
=== human_blip [n=mike@220.157.65.29]  has joined #ubuntu-devel
=== mattw [i=[U2FsdGV@opal.cat.pdx.edu]  has joined #ubuntu-devel
=== dAndy [i=[U2FsdGV@opal.cat.pdx.edu]  has joined #ubuntu-devel
=== whiprush [n=jorge@64.62.190.212]  has joined #ubuntu-devel
=== ubuntulog [i=ubuntulo@trider-g7.fabbione.net]  has joined #ubuntu-devel
=== Topic for #ubuntu-devel: Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | It's Merge Time! http://merges.ubuntu.com/ | Knot-1 freeze in effect - uploads to main frozen, ask Mithrandir for exceptions
=== Topic (#ubuntu-devel): set by Mithrandir at Thu Jul 13 08:28:56 2006
=== licio [n=licio@ubuntu/member/licio]  has joined #ubuntu-devel
=== bmonty_away [n=bmonty@ubuntu/member/bmonty]  has joined #ubuntu-devel
=== jlj [n=agp@adsl-69-104-244-209.dsl.pltn13.pacbell.net]  has joined #ubuntu-devel
=== CarlFK [n=carl@c-67-163-39-124.hsd1.il.comcast.net]  has joined #ubuntu-devel
=== Seveas [n=seveas@ubuntu/member/seveas]  has joined #ubuntu-devel
=== sharms [n=mindwarp@cpe-24-208-242-169.twmi.res.rr.com]  has joined #ubuntu-devel
=== imbrandon_ [n=brandon@ubuntu/member/pdpc.active.imbrandon]  has joined #ubuntu-devel
=== eggauah [n=daniel@150233.cps.virtua.com.br]  has joined #ubuntu-devel
=== troy_s [n=aphorism@d206-116-6-170.bchsia.telus.net]  has joined #ubuntu-devel
=== jamesh [n=james@203-59-20-109.dyn.iinet.net.au]  has joined #ubuntu-devel
=== kermitX_ [n=kermit@unaffiliated/cxg]  has joined #ubuntu-devel
=== doko [n=doko@dslb-088-073-103-221.pools.arcor-ip.net]  has joined #ubuntu-devel
=== marcin_ant [n=marcin@194.114.146.122]  has joined #ubuntu-devel
=== nekohayo [n=jeff@ip216-239-74-27.vif.net]  has joined #ubuntu-devel
=== bluefoxicy [n=bluefox@c-68-33-112-13.hsd1.md.comcast.net]  has joined #ubuntu-devel
=== spacey [n=herman@ubuntu/member/spacey]  has joined #ubuntu-devel
=== deleric [n=eric@5354FB39.cable.casema.nl]  has joined #ubuntu-devel
=== jdong [n=jdong@ubuntu/member/jdong]  has joined #ubuntu-devel
=== LeeJunFan [n=junfan@cpe-24-94-53-197.stny.res.rr.com]  has joined #ubuntu-devel
=== zenrox [n=zenrox@71.115.198.118]  has joined #ubuntu-devel
=== fimbulvetr [n=danv@24.220.28.74]  has joined #ubuntu-devel
=== FliesLikeABrick [n=Ryan@about/rpi/rawdor]  has joined #ubuntu-devel
=== mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net]  has joined #ubuntu-devel
=== elkbuntu [n=melissa@203-206-255-153.dyn.iinet.net.au]  has joined #ubuntu-devel
=== floam [n=nnaaron@sh.nu]  has joined #ubuntu-devel
=== theCore [n=alex@modemcable240.218-70-69.mc.videotron.ca]  has joined #ubuntu-devel
=== Burgwork [n=corey@ubuntu/member/burgundavia]  has joined #ubuntu-devel
=== jsgotangco [n=jsg123@ubuntu/member/jsgotangco]  has joined #ubuntu-devel
=== Burgundavia [n=corey@ubuntu/member/burgundavia]  has joined #ubuntu-devel
=== dark [i=deviled_@microsoft.gotrooted.com]  has joined #ubuntu-devel
=== FunnyLookinHat [n=funnyloo@71.57.11.218]  has joined #ubuntu-devel
=== whiprush [n=jorge@64.62.190.212]  has joined #ubuntu-devel
=== dAndy [i=[U2FsdGV@opal.cat.pdx.edu]  has joined #ubuntu-devel
=== mattw [i=[U2FsdGV@opal.cat.pdx.edu]  has joined #ubuntu-devel
=== segfault [i=segfault@cerberus.softwarelivre.net]  has joined #ubuntu-devel
=== evand [n=evan_d@72.20.218.20]  has joined #ubuntu-devel
=== Naked [i=naked@naked.iki.fi]  has joined #ubuntu-devel
=== bytee_ [n=byte@pentafluge.infradead.org]  has joined #ubuntu-devel
=== marsu [n=user@c83-248-241-49.bredband.comhem.se]  has joined #ubuntu-devel
=== haggai [n=halls@i-83-67-59-194.freedom2surf.net]  has joined #ubuntu-devel
=== crimsun [n=crimsun@dargo.trilug.org]  has joined #ubuntu-devel
=== dooglus [n=dooglus@rincevent.net]  has joined #ubuntu-devel
=== siretart [i=siretart@ubuntu/member/siretart]  has joined #ubuntu-devel
=== tseng [n=tseng@unaffiliated/tseng]  has joined #ubuntu-devel
=== Laser_away [n=mantha@ubuntu/member/laserjock]  has joined #ubuntu-devel
=== Naked is now known as Hadaka
=== saispo [n=saispo@ryu.zarb.org]  has joined #ubuntu-devel
=== ThunderStruck [n=thunders@ubuntu/member/gnomefreak]  has joined #ubuntu-devel
=== sfllaw [i=sfllaw@debian/developer/coleSLAW]  has joined #ubuntu-devel
=== mako [i=mako@bork.hampshire.edu]  has joined #ubuntu-devel
=== EdgyEft [n=seveas@ubuntu/member/seveas]  has joined #ubuntu-devel
=== maswan [i=maswan@kennedy.acc.umu.se]  has joined #ubuntu-devel
=== iwj [n=ian@xenophobe.extern.relativity.greenend.org.uk]  has joined #ubuntu-devel
=== jvw [i=jeroen@220pc220.sshunet.nl]  has joined #ubuntu-devel
=== hendry [n=hendry@222.106.128.198]  has joined #ubuntu-devel
=== Hobbsee [n=Hobbsee@ubuntu/member/hobbsee]  has joined #ubuntu-devel
=== trappist [i=trappist@tra.ppi.st]  has joined #ubuntu-devel
=== Trewas [n=ilonen@raato.lut.fi]  has joined #ubuntu-devel
=== lool [i=lool@pig.zood.org]  has joined #ubuntu-devel
=== vvl [i=vvl@leviathan.hellfish.org]  has joined #ubuntu-devel
=== dieman [n=dieman@3.14159265358979323846264338327950288419716939937510582097.org]  has joined #ubuntu-devel
=== Chipzz [n=chipzz@ace.ulyssis.student.kuleuven.be]  has joined #Ubuntu-Devel
=== sladen [i=paul@starsky.19inch.net]  has joined #ubuntu-devel
=== RadiantFire [n=ryan@c-69-180-43-27.hsd1.ga.comcast.net]  has joined #ubuntu-devel
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-devel
=== Robot101 [n=robot101@light.bluelinux.co.uk]  has joined #ubuntu-devel
=== HrdwrBoB [n=matt@bob.is.teh.admin.at.vicnet.net.au]  has joined #ubuntu-devel
=== G0SUB [i=ghoseb@unaffiliated/gnulinuxer]  has joined #ubuntu-devel
=== lionelp [n=lionel@ip-128.net-82-216-65.rev.numericable.fr]  has joined #ubuntu-devel
=== Kamion [n=cjwatson@83-216-156-196.colinw664.adsl.metronet.co.uk]  has joined #ubuntu-devel
=== thom [n=thom@amnesiac.heapspace.net]  has joined #ubuntu-devel
=== Lutany [i=aba@redruth.greenbean.org]  has joined #ubuntu-devel
=== Gerrath [n=Shane_@unaffiliated/gerrath]  has joined #ubuntu-devel
=== holycow [n=a@mail.wjsgroup.com]  has joined #ubuntu-devel
=== tepsipakki [n=tjaalton@replicant.hut.fi]  has joined #ubuntu-devel
=== stub [n=stub@ppp-58.8.1.197.revip2.asianet.co.th]  has joined #ubuntu-devel
=== hendry [n=hendry@222.106.128.198]  has left #ubuntu-devel [] 
=== robertj [n=robertj@66-188-77-153.dhcp.athn.ga.charter.com]  has joined #ubuntu-devel
=== Huahua [n=hua_@123.49.238.139]  has joined #ubuntu-devel
=== Naked [i=naked@naked.iki.fi]  has joined #ubuntu-devel
=== dooglus [n=dooglus@rincevent.net]  has joined #ubuntu-devel
=== Naked is now known as Hadaka
=== infinity1 [n=adconrad@loki.0c3.net]  has joined #ubuntu-devel
=== ctd [i=ctd@incubus.progsoc.uts.edu.au]  has joined #ubuntu-devel
[05:40] <bluefoxicy> http://www.killernic.com/KillerNic/  Edgy should have drivers for this
[05:40] <zul> open up a bug in lp
[05:41] <Hobbsee> hi zul 
=== Hobbsee wonders why it's so quiet
[05:41] <jdub> zomg that is the dumbest crack ever
[05:42] <bluefoxicy> zul:  take some advice from jdub, go actually look ;)
[05:42] <_ion> Haha, funny.
=== lifeless [n=robertc@dsl-28.7.240.220.rns01-kent-syd.dsl.comindico.com.au]  has joined #ubuntu-devel
[05:43] <zul> im too tired to
=== tritium [n=tritium@ubuntu/member/tritium]  has joined #ubuntu-devel
=== LeeJunFan [n=junfan@cpe-24-94-53-197.stny.res.rr.com]  has joined #ubuntu-devel
=== mdke [n=matt@ubuntu/member/mdke]  has joined #ubuntu-devel
=== bronson [n=bronson@209-221-203-148.dsl.qnet.com]  has joined #ubuntu-devel
=== \sh_away [n=nnnsherm@server3.servereyes.de]  has joined #ubuntu-devel
=== Hwyvar [n=Ferdinan@cp106356-c.tilbu1.nb.home.nl]  has joined #ubuntu-devel
=== didymo [n=ashley@CPE-61-9-197-223.nsw.bigpond.net.au]  has joined #ubuntu-devel
=== Gman [n=gman@nwkea-socks-1.sun.com]  has joined #ubuntu-devel
=== rpedro [n=rpedro@87-196-103-156.net.novis.pt]  has joined #ubuntu-devel
=== Kinnison [n=dsilvers@spoo.flarn.net]  has joined #ubuntu-devel
=== vuntz [n=vuntz@fennas.vuntz.net]  has joined #ubuntu-devel
=== _kylem [n=kyle@cabal.ca]  has joined #ubuntu-devel
=== Mithrandir [n=tfheen@c5100BC63.inet.catch.no]  has joined #ubuntu-devel
=== Naked [i=naked@naked.iki.fi]  has joined #ubuntu-devel
=== dooglus [n=dooglus@rincevent.net]  has joined #ubuntu-devel
=== Naked is now known as Hadaka
=== Znarl [n=znarl@dark.roundabout.org]  has joined #ubuntu-devel
=== mat|work [n=mat@igoan/mat]  has joined #ubuntu-devel
=== Yvonne [n=01101110@pdpc/supporter/active/Yvonne]  has joined #ubuntu-devel
=== asw [n=asw@karuna.med.harvard.edu]  has joined #ubuntu-devel
=== _TomB [n=ownthebo@ACBDD4D5.ipt.aol.com]  has joined #ubuntu-devel
=== TomB| [n=ownthebo@ACBDD4D5.ipt.aol.com]  has joined #ubuntu-devel
=== troy_s [n=aphorism@d206-116-6-170.bchsia.telus.net]  has joined #ubuntu-devel
=== ozamosi [n=ozamosi@ubuntu/member/ozamosi]  has joined #ubuntu-devel
=== mjg59 [n=mjg59@cavan.codon.org.uk]  has joined #ubuntu-devel
=== nekohayo is now known as nekohayo-sleep
=== pitti [n=pitti@ubuntu/member/pitti]  has joined #ubuntu-devel
=== pygi [n=pygi@83-131-235-188.adsl.net.t-com.hr]  has joined #ubuntu-devel
=== pitti [n=pitti@ubuntu/member/pitti]  has joined #ubuntu-devel
[07:02] <pitti> Hi everyone
[07:02] <crimsun> 'morning pitti
[07:03] <Burgundavia> morning pitti
[07:05] <Hobbsee> hey pitti!
[07:05] <Hobbsee> hi Burgr
[07:05] <Hobbsee> hi Burgundavia 
[07:05] <Hobbsee> gah, cant spell
[07:05] <Burgundavia> Hobbsee: comes from using KDE :)
=== theCore [n=alex@modemcable240.218-70-69.mc.videotron.ca]  has joined #ubuntu-devel
[07:05] <Hobbsee> Burgundavia: heh
[07:06] <Burgundavia> I guess I should say "It komes from using KDE"
[07:06] <Hobbsee> heh
=== Gerrath [n=Shane_@unaffiliated/gerrath]  has joined #ubuntu-devel
=== Burgundavia turns his troll mode off
[07:08] <crimsun> err, someone in #ubuntu thinks that having /root mode 0755 is a security hole.
[07:09] <bluefoxicy> crimsun:  depends on what's stored in /root
[07:10] <bluefoxicy> crimsun:  in general there is no reason to have /root world readable though
[07:10] <bluefoxicy> arguments made for world-readable /home aside
[07:10] <crimsun> I think arguing for it to be mode 000 is hardly a preventive measure.
[07:11] <bluefoxicy> yeah
[07:11] <bluefoxicy> 700 I would more say
[07:11] <Laser_away> I guess if you put all your passwords in clear text in /root you might have a problem ;-)
[07:11] <bluefoxicy> theoretically there's nothing sensitive in root though
[07:11] <bluefoxicy> I mean it has what, synaptic's configuration?
[07:12] <crimsun> yep, but that's mode 700.
[07:12] <bluefoxicy> nothing sensitive really.  You don't browse the web from /root
[07:13] <bluefoxicy> crimsun:  ~/.mozilla is 700 right?
[07:13] <Laser_away> oh heck, how do you do the numbers again? I've never been able to remember
[07:13] <bluefoxicy> 4 read 2 write 1 execute
[07:13] <Laser_away> 7 is rwx, right?
[07:13] <crimsun> bluefoxicy: yes
[07:13] <bluefoxicy> Laser_away:  they're bits
[07:13] <bluefoxicy> r w and x are all 1
[07:13] <bluefoxicy> and - is 0
[07:13] <bluefoxicy> so rwx is 111 is 7
[07:13] <Laser_away> ah makes sens
[07:13] <bluefoxicy> r-x is 101 is 5
[07:13] <Laser_away> e
[07:14] <Hobbsee> ah...now that is clever.  requires people to be able to count in binary though.
[07:14] <bluefoxicy> the guys who wrote this thing were all hackers, read into it a bit, the design makes programmatic sense if you know C and assembly.
=== kintaro [n=ad0lf@203.177.212.164]  has joined #ubuntu-devel
[07:15] <Laser_away> Hobbsee: well, I had an instrumental analysis class were we had to get decent with binary
[07:15] <Laser_away> so I can do ok
[07:15] <bluefoxicy> crimsun:  I still want a power user's applet that lets me change things like that 8)
[07:15] <Hobbsee> Laser_away: same here, i topped those yr 11 info processes and technology exams without any study at all - which included binary/octal/decimal/hex conversions
=== bluefoxicy should fix his pam.d so that his session gets 0077 umask
[07:16] <bluefoxicy> octal dec hex is easy.
[07:16] <bluefoxicy> err.  octal bin hex
[07:16] <bluefoxicy> decimal is not related.
[07:16] <Chipzz> Hobbsee: octal, actually :)
[07:16] <Laser_away> ack, what the 4 number, ugo and ?
[07:16] <bluefoxicy> 2 8 16
[07:17] <bluefoxicy> Laser_away:  what are you asking?
[07:17] <Laser_away> in 0077 what is the 4th number for?
[07:18] <bluefoxicy> Chipzz: counting in octal is not meaningful.  Convenient since each set of permissions is 3 bits, but not meaningful
[07:18] <Laser_away> I always use ugo etc
[07:18] <bluefoxicy> Laser_away:  the last one is for setuid, setgid, sticky, etc.
[07:18] <Laser_away> ah yes
[07:18] <bluefoxicy> I don't know what bits those are.
[07:18] <bluefoxicy> I know sticky is 1
[07:18] <Laser_away> I don't understand what exactly setuid is used for
[07:19] <bluefoxicy> the file is owned by a user yes?
=== Laser_away is showing his lack of CS training
[07:19] <bluefoxicy> and it's in a group
[07:19] <bluefoxicy> ls -l a file and it has like "Laser users"
[07:19] <StevenK> setuid is used to exec a file as the owner.
[07:19] <bluefoxicy> well if the file is executable, the user owning it is the effective UID of the process when the file is execve()'d
[07:19] <Laser_away> so what happens if it is 0? and 1?
[07:19] <bluefoxicy> su is setuid, so is sudo.  Run those, they're root.
[07:20] <bluefoxicy> Laser_away:  if setuid is set, then when you run the program the user owning the file is the user it's run as.
[07:20] <bluefoxicy> when you run sudo, it's run as root.
[07:20] <bluefoxicy> this gets it permission to transition to a different user :P
[07:20] <bluefoxicy> setgid does the same thing for egid
[07:20] <StevenK> setuid is set on the highest order bits of the permissions.
[07:20] <StevenK> 4755 is setuid
[07:20] <Laser_away> so if it isn't set then it is run as the user how excecuted it?
[07:21] <bluefoxicy> StevenK:  figured as much.  User, Group, Other... SetUID, SetGID, sticky
[07:21] <bluefoxicy> Laser_away:  if it's not set then the user running it is the one that the EUID is set to
[07:22] <bluefoxicy> that's why people should go to great lengths to reduce the number of setuid programs on the system
[07:23] <bluefoxicy> for example in Ubuntu's init scripts we could have a wrapper script in the networking script that drops capabilities except for CAP_NET_ADMIN, switches users to nobody, and then executes the relevent networking configuration.
[07:23] <bluefoxicy> hmm.. I don't know if dhcp needs CAP_NET_RAW.  It may need that as well.
[07:23] <bluefoxicy> Anyway
[07:23] <bluefoxicy> this would allow dhclient to be run as not root... and this has nothing to do with setuid.
[07:23] <bluefoxicy> come on
[07:24] <bluefoxicy> I know I've seen a handfull of setuid programs go to thin wrappers that drop caps
[07:24] <bluefoxicy> Laser_away:  ANYWAY
[07:25] <bluefoxicy> MOST programs on the system are owned by root
[07:25] <bluefoxicy> (pretty much ALL of them)
[07:25] <bluefoxicy> so every time you run a setuid program you get free root access for a very short time, in a very specific code path
[07:26] <bluefoxicy> why am I talking about this
[07:26] <bluefoxicy> does anyone care anymore
[07:26] <bluefoxicy> my screen is 85% my own text, I'm getting lonely.
[07:26] <Burgundavia> bluefoxicy: blah
[07:27] <bluefoxicy> Burgundavia:  New topic.  What's going on in Edgy tomorrow.
[07:27] <Burgundavia> no idea, I don't code
[07:27] <Hobbsee> Burgundavia: you dont?
[07:27] <Hobbsee> Burgundavia: which bits are you involved in?
[07:27] <bluefoxicy> I'm waiting to play with the knot
[07:27] <Burgundavia> despise it
[07:27] <Hobbsee> hehe
[07:27] <Burgundavia> Hobbsee: doc team, marketing, etc.
[07:27] <Hobbsee> Burgundavia: ahh, nice :)
[07:28] <Burgundavia> the soft stuff
[07:28] <Laser_away> whatever
[07:28] <Burgundavia> I do sales in my day job
[07:28] <Laser_away> I've been to the doc side, and I've worked with your boss
[07:28] <Burgundavia> Laser_away: btw, have you been paid?
[07:29] <bluefoxicy> Burgundavia:  do you know anyone who's familiar with gcc's internals that I might be able to pry maybe a half hour out of?
[07:29] <Burgundavia> nope, sorry
[07:29] <bluefoxicy> damn.
[07:30] <bluefoxicy> I am still trying to find someone to do that side of the compiler work
[07:30] <Laser_away> Burgundavia: yes, thanks for asking, Tim said there was a snafu or something but I got it
[07:30] <Burgundavia> Laser_away: perfect, glad that got sorted
[07:31] <bluefoxicy> I got paid for my prelink article the other day ^o.o^
[07:31] <Hobbsee> bluefoxicy: edgy+1,anyawy
[07:31] <bluefoxicy> Hobbsee:  hm?
[07:31] <Laser_away> me too, it helped offset my little "incident" in Paris
=== freeflying_ [n=freeflyi@221.221.151.224]  has joined #ubuntu-devel
[07:32] <Hobbsee> bluefoxicy: the compiler stuff would have to wake edgy+1, i take it
[07:32] <bluefoxicy> Hobbsee:  it would, but the chunk i need written has to go to mainline anyway.
[07:32] <bluefoxicy> Hobbsee:  it involves modifying the code in gcc/targhooks.c (i think it's called) for 2 functions, to change an emitted function call to pass an argument
[07:33] <Hobbsee> fair enough
[07:33] <bluefoxicy> I am trying to change __stack_chk_fai(), the handler called when a stack buffer overflow is detected, to __stack_chk_fail2(const char *fctn) (__stack_chk_fail() needs to stay for legacy support)
=== Hobbsee knows nothing about such thinsg, and is happy to remain in ignorance
[07:33] <bluefoxicy> that way we can derive the exact function that a stack smash happened in when an overflow occurs.
[07:34] <bluefoxicy> My eventual goal is to get a slight hack onto glibc into Ubuntu that replaces the handler on our end (this part is in no way touching mainline) with one that collects this information, to improve reaction time wrt security vulns (because we can detect their existence earlier)
[07:34] <pitti> bluefoxicy: but that would require instrumenting the code with function names
[07:34] <pitti> bluefoxicy: and I do not see why this would give us more information than a gdb backtrace?
[07:34] <bluefoxicy> pitti:  yes.  There is code in some places in the compiler that does this.  The preprocessor can turn __FUNC__ into the current function name
[07:35] <bluefoxicy> pitti:  does every end user run every program in gdb?
[07:35] <pitti> bluefoxicy: right, I'm aware of that, but that would mean to blow up the code with additional strings
[07:35] <bluefoxicy> pitti: see https://wiki.ubuntu.com/GccSspEnhancements specifically.
[07:35] <fabbione>  ls -las /bin/sh
[07:35] <bluefoxicy> pitti:  ProPolice used to do function and source file name
[07:35] <pitti> bluefoxicy: with the spec I'm working on, we will automatically get backtraces for every crashed (packaged) program
[07:35] <fabbione> 0 lrwxrwxrwx  1 root root 4 Jan  4  2006 /bin/sh -> gdb
[07:35] <bluefoxicy> pitti:  automatically?  You do ask the user, right?
[07:36] <pitti> bluefoxicy: we'll ask the user about what to do with it, of course
[07:36] <bluefoxicy> pitti:  do the backtraces contain function names?  We have address space randomization, if we just get addresses it's kind of useless.
[07:36] <pitti> bluefoxicy: but we'll automatically get /var/crash/blabla report
=== freeflying|away [n=freeflyi@ubuntu/member/freeflying]  has joined #ubuntu-devel
[07:36] <bluefoxicy> also how are you getting a back trace?
[07:36] <pitti> bluefoxicy: yes, even stripped programs still have enough symbols to get the function names usually
[07:36] <pitti> bluefoxicy: of course it's better to have debug symbols installed
[07:37] <bluefoxicy> how DO you get the function names?
[07:37] <pitti> bluefoxicy: we thought of that, please see wiki.ubuntu.com/AutomatedProblemReports
[07:37] <bluefoxicy> pitti: won't work.
[07:38] <pitti> bluefoxicy: if we don't have symbols, we can save a (reduced) core dump and restore the bt later
[07:38] <bluefoxicy> "Create a small library libcrashrep.so whose init function installs a signal handler for the most common types of crashes (segmentation violation, floating point error, and bus error). The handler will catch all signals that the application does not handle itself. When a crash is detected, the library calls an external program. The library is put into /etc/ld.so.preload."
[07:38] <bluefoxicy> pitti:  in the case of a stack buffer overflow, the signal handler will not run.
[07:38] <pitti> bluefoxicy: that's not what we are using
[07:38] <bluefoxicy> oh, sorry, I'm skimming too fast.
[07:38] <pitti> bluefoxicy: we're using the kernel hook
[07:38] <bluefoxicy> pitti:  I'm still seeing signal handlers
[07:39] <pitti> I'm currently at making this actually work
[07:39] <pitti> bluefoxicy: ?
[07:39] <pitti> bluefoxicy: if the kernel is about to send a sigseg/ftp/bus/ill to a process, it calls this hook before, and stalls the crashed process
[07:40] <bluefoxicy> pitti:  in the case of a stack smash the program calls _exit() I think.
=== lfittl [n=lfittl@83-65-241-12.dynamic.xdsl-line.inode.at]  has joined #ubuntu-devel
[07:40] <bluefoxicy> let me examine glibc a little okay?
[07:40] <pitti> sure
[07:40] <pitti> bluefoxicy: right, if SSP hits, this could be circumvented
[07:41] <bluefoxicy> pitti:  Right.  I wanted to send a stack dump, the function name, and the module it occurred in.
[07:41] <bluefoxicy> I am rather certain that given the proper handler I can discern all of this information.  If you think you can do it with just an address in the library, I can also make a good try there; but be wary, unless you can get the EXACT function that ANY .text is associated with, this will not work.
[07:41] <pitti> fabbione: erm, /bin/sh -> gdb?
[07:42] <bluefoxicy> I know for a fact that looking in the symbol table and comparing addresses will fuzz around with static functions and inlines
=== imbrandon [n=brandon@ubuntu/member/pdpc.active.imbrandon]  has joined #ubuntu-devel
=== sevrin [n=sevrin@202.75.186.154]  has joined #ubuntu-devel
[07:42] <fabbione> pitti: :)
[07:42] <Hobbsee> hi fabbione!
[07:42] <bluefoxicy> but if the debugging data has them correct, and you have that information on your end, then we're good.
[07:42] <fabbione> hey Hobbsee 
[07:42] <pitti> bluefoxicy: maybe we can just modify __stack_chk_fail() to also call the crash report agent
[07:42] <bluefoxicy> however this is fragile, it REQUIRES you have the debugging data for that specific version of that library.  In other words, only ubuntu shipped things.
[07:43] <pitti> bluefoxicy: so that we can get the same report, and then let the program die as usual
[07:43] <bluefoxicy> pitti:  yes, that is what I was going to do.  "I am rather certain that given the proper handler I can discern all of this information.  If you think you can do it with just an address in the library, I can also make a good try there"
=== enrico [n=enrico@debian/developer/enrico]  has joined #ubuntu-devel
[07:43] <pitti> bluefoxicy: well, of course we need to save the stack frame (core dump or similar) to reconstruct a bt post mortem
[07:44] <bluefoxicy> pitti:  I'll get to work on that, it'll require a slight glibc modification though.  Don't preload this stuff, for the love of all that is holy and good.
[07:44] <bluefoxicy> pitti:  Be wary of stack dumps.
[07:44] <pitti> bluefoxicy: no, the preloaded library was just for some initial experiments
[07:44] <bluefoxicy> A back trace will NOT work by the way
[07:44] <pitti> bluefoxicy: why, does __stack_chk_fail() already unwind?
[07:44] <bluefoxicy> remember with a stack smash the stack has been scribbled over.  I can tell you where the last executing address fell before we detected it -- what function was borked up -- but beyond that it's up to the mercey of whatever junk was written past that buffer.
[07:45] <pitti> I thought it doesn't even return from the function and immediately dies
[07:45] <bluefoxicy> __builtin_return_address(0) will tell me the function that the current function was called from; __builtin_return_address(1) will tell me the function that the caller was called from, right?
[07:45] <pitti> bluefoxicy: right, I'm aware of that
[07:45] <bluefoxicy> well, the caller's retp is destroyed.  backtrace() also uses the stack, so that's kindo f screwed too.
[07:46] <pitti> bluefoxicy: well, the topmost function should still be correct, right?
[07:46] <bluefoxicy> yes, it should.
[07:46] <pitti> so, I think that's about as much as we can figure out in case of a stack smash
[07:46] <bluefoxicy> as I said, I can get you the calling address in the function that the smash was detected from.
[07:47] <bluefoxicy> pitti:  that being said a stack dump is useful. It shows the damaging data
[07:47] <bluefoxicy> so you know what buffer data will cause a smash.
[07:47] <bluefoxicy> however it *may* contain passwords and gpg keys and god knows what
[07:47] <pitti> bluefoxicy: that's true for non-ssp dumps as well
[07:47] <bluefoxicy> yeah
[07:47] <pitti> bluefoxicy: that's why we have to be careful about them and ask the user, and all that
[07:48] <pitti> we didn't yet spec out the further process
[07:49] <bluefoxicy> Application contents are very very sensitive.  I would love to send the __builtin_return_address(0) and force the user to manually review and send stack dumps in ascii/hex side by side, but that will result in a lot of dumps not being sent.  I don't want dumps auto-sent ever, it'd be hell if one day mozilla crashes and we have someone's credit card number.
[07:49] <pitti> they won't
[07:49] <bluefoxicy> but I may be being very picky here
[07:49] <bluefoxicy> return address is harmless.
[07:50] <bluefoxicy> pitti:  I'll get to work on that.  I'm actually almost there.
[07:50] <pitti> bluefoxicy: what we'll probably do is to ask the user whether he wants to send us the core (defaulting to off) and add some explanatory text about potential disclosure
[07:50] <bluefoxicy> pitti: http://bluefox.kicks-ass.org/stuff/bluefox/ssp_patches/  <-- last few days.
[07:50] <pitti> and never publish the core anywhere
[07:50] <pitti> bluefoxicy: we only need the core to reassemble a good trace (on a separate server), then we can throw it away anyway
[07:50] <bluefoxicy> yeah
[07:51] <pitti> well, it might be useful for other debugging, too, but that might get too sensitive
[07:51] <bluefoxicy> pitti:  warn the user not to send it if he was entering passwords, credit card numbers, using PGP/GPG keys, or using other sensitive information in the application maybe?
[07:51] <pitti> bluefoxicy: the reason we go through this fuss is to avoid requiring the user to download all the debug symbols on a crash
[07:52] <pitti> bluefoxicy: yep
[07:52] <bluefoxicy> pitti:  I would not mind the option to reduce to the last 64k of stack data; and then visually grep it and "expunge" certain information i.e. hey that's my password ;)
[07:52] <bluefoxicy> but that would be a very advanced option
[07:52] <pitti> bluefoxicy: wrt to that, I did some experiments with reducing the core dump file size by throwing out sections we do not need
[07:52] <pitti> however, that requires more work and research
[07:52] <bluefoxicy> dude reduce the coredump size by using bzip2
[07:52] <pitti> bluefoxicy: if you are interested in that, feel free to ping me ::)
[07:53] <bluefoxicy> not particularly.
[07:53] <pitti> bluefoxicy: that's what I'm going to do anyway
[07:53] <bluefoxicy> pitti:  I am worried about the handler though.  It is good to avoid using external functions in it.
[07:53] <pitti> bluefoxicy: but if we throw out e. g. code sections, it'll shrink even further
[07:53] <bluefoxicy> that's why I wrote my own strcpy() and strcat()
[07:53] <pitti> well, strcpy() in C is easy :) while(*dest++ = *src++)   /me <3 C 
[07:53] <bluefoxicy> the whole lib needs to be self-contained.  Some libraries even supply their own read() that overrides glibc, that isn't what I want to deal with.
=== bluefoxicy is currently trying to figure a way to get glibc to pass something to let the ssp library get *its* handlers, or something.
[07:54] <pitti> bluefoxicy: that gets trickier if you want to call the crash-reporting agent
[07:55] <bluefoxicy> pitti:  I am considering the 'agent' be connected to a daemon
[07:55] <pitti> bluefoxicy: oh you want to use IPC to talk to it? hmm
[07:55] <bluefoxicy> and my job be to write the data to something-- named pipe, some file in some directory, anything I can do with minimal code-- and get out of the dead program
[07:55] <pitti> I'd rather have it spawned by the crash handler or the kernel
[07:56] <bluefoxicy> I want as little code running in the dead program as possible after it's been smashed
[07:56] <pitti> bluefoxicy: right, that's why we came up with the kernel helper
[07:56] <pitti> so that we do not need any code at all in the crashed process
[07:56] <bluefoxicy> right, but stack smashed programs exit cleanly.
[07:56] <bluefoxicy> ... for the most part.
[07:56] <pitti> true, we have to add a hook there
[07:56] <pitti> and that'll get tricky
[07:56] <bluefoxicy> you're going to need something on that end
[07:57] <pitti> bluefoxicy: however, it's not the common crash case anyway
[07:57] <pitti> so if we add that later, that'll be fine
[07:57] <bluefoxicy> yeah
[07:57] <bluefoxicy> it doesn't even have to operate the same way, just as long as it's not totally insane
[07:58] <pitti> right, it would just be nice to reuse our crash agent, since it collects so much valuable information
[07:58] <pitti> (not only the bt, but also package versions, dependencies, /proc status, etc.)
[07:58] <bluefoxicy> it can be reused.  Can you trigger a program to core dump?
[07:58] <pitti> bluefoxicy: kill(x, SIGSEGV) :)
[07:58] <pitti> bluefoxicy: yes, in fact that's what stack_chk_fail() could (ab)use :)
[07:59] <bluefoxicy> like I said, in a stack smash you're not getting a back trace.  You're getting whatever address the handler would "return" to (if it returned) and a stack that's scribbled over garbage ;)
[07:59] <bluefoxicy> the data you need to build a back trace is most likely destroyed
[07:59] <pitti> bluefoxicy: I know, but we'd still know the package, version, OS version, dependency versoins, /proc etc.
[07:59] <bluefoxicy> SIGSEGV can be trapped.
[07:59] <bluefoxicy> yeah
[08:00] <pitti> bluefoxicy: I know it can be trapped, we have to make sure that the process doesn't continue to run afterwards
[08:00] <pitti> maybe by resetting the segv handler or so
[08:00] <bluefoxicy> hmm.
[08:01] <bluefoxicy> SIGKILL can't be trapped, I can send that simply enough from within the program but i can do it from bash too
[08:01] <pitti> bluefoxicy: right, but we shouldn't trigger the crash handler on KILL
[08:01] <bluefoxicy> I can send sigsegv from bash but that's not common.
[08:01] <bluefoxicy> pitti:  well, hold on.
[08:01] <bluefoxicy> I would be sending the kill to myself.
[08:01] <bluefoxicy> PID 1000 -> PID 1000
[08:02] <pitti> yes
[08:02] <bluefoxicy> that is clearly a not normal situation.
[08:02] <bluefoxicy> You can detect this in the kernel, I'm sure.
[08:02] <pitti> hm, I'm not sure whether we should special case that in our kernel hook
[08:02] <pitti> bluefoxicy: maybe we should check if a process sends a SIGSEGV to itself
[08:03] <pitti> well, then we don't need the 'to itself' special case
[08:03] <bluefoxicy> uh
[08:03] <bluefoxicy> processes can catch sigsegv and handle it safely
[08:03] <pitti> bluefoxicy: do you see a reason why signal(SIGSEGV, SIG_DFL) won't work?
[08:03] <bluefoxicy> they can NOT catch a stack smash and handle it safely
[08:04] <pitti> oh, true, right now we do allow programs to trap segv, just to not trample over existing crash handlers
[08:04] <bluefoxicy> Etoh DID however clear the signal handler on sigsegv, but I am not comfortable doing this in a multithreaded environment because I am paranoid another thread might race me.
[08:04] <bluefoxicy> it's theoretically possible
[08:04] <pitti> no, you are right, that's too crackful and unsafe
[08:05] <pitti> bluefoxicy: so what we need is a simple kernel API to say 'please call the crash handler on me', and then just _exit()
[08:05] <bluefoxicy> I don't see a harm in catching a sigkill to self, why a program would do such a thing is beyond me; the normal way to exit is _Exit() (calling atexit() handlers) or _exit() (exiting immediately without running any more code)
[08:05] <pitti> bluefoxicy: ok, we should consider this special case
[08:05] <bluefoxicy> at the very least I am 100% sure that POSIX mandates sigkill can never be trapped
[08:06] <pitti> that's true
[08:06] <pitti> that's the whole point of kill over term :)
[08:06] <bluefoxicy> the gcc guys have _exit(127) as their last ditch effort of 3 things they try to do to exit
[08:08] <bluefoxicy> pitti:  also if you change the handler to straight out _exit() you have to collect the crash data yourself, you have to do the backtracing yourself, which means you have to figure out the stack frames up to the damaged ones
[08:08] <bluefoxicy> err. to kill self, exit, or whatnot.
[08:08] <pitti> bluefoxicy: what I meant is:
[08:08] <pitti> bluefoxicy: right now, __stack_chk_fail() prints/logs a blurp and _exit()'s, right?
[08:09] <bluefoxicy> yes, pretty much.
[08:09] <pitti> bluefoxicy: so, my idea is to insert a __sys_call_crash_handler() or whatever between the print and the _exit()
[08:09] <bluefoxicy> in glibc (the one we use) it uses __libc_message(1, "...", program_name)
[08:09] <bluefoxicy> (before the print)
[08:10] <pitti> bluefoxicy: similar to the do_coredump() hook we changed in the current kernel, this could trigger callign the crashdump helper from the kernel and suspend the program in the meantime
[08:10] <bluefoxicy> pitti:  do you want to do this in an external library, or hack it straight into libc?
[08:10] <bluefoxicy> interesting.
[08:11] <pitti> bluefoxicy: I thought about a kernel interface, if that's possible
[08:11] <pitti> to avoid execve() and similar stuff from the crashed process
[08:11] <bluefoxicy> yes I mean we have to modify the crash handler
[08:11] <bluefoxicy> the __stack_chk_fail() function
[08:11] <pitti> bluefoxicy: oh, the actual crash handler is a separate process (currently in python)
[08:12] <bluefoxicy> alright
[08:12] <pitti> bluefoxicy: oh, that's in glibc right now, and I think that's a good place
[08:12] <bluefoxicy> alright.
[08:12] <bluefoxicy> What has to be inserted before glibc bails out
[08:12] <pitti> bluefoxicy: in Debian it is in libssp0, but glibc 2.4 has it natively
[08:12] <bluefoxicy> yes
[08:13] <bluefoxicy> I was thinking to alter glibc to read /etc/libc.ssp.conf on start-up, dlopen() the library mentioned in there, and get a symbol for __stack_chk_fail(); and in the stack smash handler in glibc, call that address if it actually existed, otherwise default behavior
[08:13] <bluefoxicy> this would add an extra library to each load of each program however
[08:14] <bluefoxicy> but would allow us to basically do whatever we want in this realm without rebuilding glibc
=== lukketto [n=lukketto@host251-99.pool8257.interbusiness.it]  has joined #ubuntu-devel
[08:14] <bluefoxicy> I guess if you can collect ALL the data you need from outside the process though, then all we really need is for glibc to kill itself in a not so graceful manner
[08:14] <bluefoxicy> which is one line of code.
[08:14] <pitti> bluefoxicy: it's not entirely unlike my first ld.preload appraoch :)
[08:14] <bluefoxicy> not entirely, but ld.preload I have issue with:)
[08:14] <pitti> right
[08:15] <pitti> although it's not that evil IMHO
=== lukketto [n=lukketto@host251-99.pool8257.interbusiness.it]  has left #ubuntu-devel [] 
[08:15] <bluefoxicy> unless you have multilib
[08:15] <bluefoxicy> and suid
[08:15] <pitti> bluefoxicy: setuid programs do respect /etc/ld.so.preload, they just don't respect $LD_PRELOAD
[08:16] <bluefoxicy> if an ld.so.preload can't load, then a suid program refuses to run.  You NEED a livecd to fix this.  So we would not be able to ld.so.preload for any 32 bit programs (openoffice is probably our last one though)
[08:16] <bluefoxicy> found that one out trying to do two libsafes on gentoo.
[08:16] <bluefoxicy> err, *32 bit programs on amd64
[08:17] <pitti> oh, good point
[08:17] <bluefoxicy> besides that it just feels like a fragile approach, I don't know why
[08:17] <bluefoxicy> but that's irrelavent
[08:17] <bluefoxicy> pitti:  what can be gathered without any help from the program?
[08:18] <bluefoxicy> Can you figure out the absolute last stack frame, and what function was executing?  Can you figure out the return address that function would have gone to?
[08:19] <bluefoxicy> If you can, then everything I could pass you from the handler is moot, the handler just needs to die in a way that triggers the crash handler.
[08:19] <pitti> bluefoxicy: with gdb you can figure out quite much, and I would like to collect all data externally
[08:20] <pitti> bluefoxicy: we might be able to extract a dump of the stack frame in the crashed process itself, that would avoid the huge core dump, but that feels fragile
[08:20] <bluefoxicy> alright, and gdb can attach to a running process if it has CAP_SYS_PTRACE?
[08:20] <pitti> bluefoxicy: yes, the kernel crash handler is always called as root
[08:20] <pitti> I currently drop permissions to the target process, but we can tweak that however we like
[08:20] <bluefoxicy> let's not do root, let's do CAP_SYS_PTRACE and whatever other caps you need
[08:21] <pitti> see above :)
[08:21] <bluefoxicy> yeah
[08:21] <bluefoxicy> also, make a note
[08:21] <bluefoxicy> in the future it may become fashionable to block access to /proc/PID/maps and friends
[08:21] <pitti> bluefoxicy: also, if the target process has the 'pink' bit, i. e. has privileges above the average, then I'd rather not gdb it
=== Fujitsu [n=Fujitsu@c211-28-181-26.eburwd7.vic.optusnet.com.au]  has joined #ubuntu-devel
[08:21] <bluefoxicy> You should develop a strategy for specifically granting a process permissions to access /proc/PID/maps eventually, but it's not necessary right now.
[08:22] <pitti> bluefoxicy: if a process started as suid root and then setuid(getuid()) it is not ptrace()able from that uid
[08:22] <pitti> bluefoxicy: and my feeling is that we should respect that
[08:22] <bluefoxicy> pitti:  nods.
[08:22] <pitti> I'd favor a missing backtrace over an information disclosure
[08:22] <pitti> bluefoxicy: anyway, let's get that thing going for the basic cases
[08:22] <pitti> then we can refine it
[08:23] <pitti> bluefoxicy: (interesting discussion, thanks!)
[08:23] <bluefoxicy> pitti:  this is dead simple, what do you need to kill the process with?
[08:23] <pitti> bluefoxicy: context?
[08:23] <pitti> a slashaxe? :)
[08:23] <bluefoxicy> haha
[08:23] <bluefoxicy> I mean in __stack_chk_fail(), what kind of thing needs to happen?
[08:24] <pitti> bluefoxicy: <pitti> bluefoxicy: so, my idea is to insert a __sys_call_crash_handler() or whatever between the print and the _exit()
[08:24] <pitti> bluefoxicy: of course we do not have this kernel API right now
[08:24] <bluefoxicy> do you NEED that kernel API for anything else?
[08:24] <pitti> it was just a random idea
[08:24] <pitti> bluefoxicy: actually not
[08:25] <bluefoxicy> if not a simple kill(getpid(),SIGKILL) and catching SIGKILL to current will probably be less invasive and we won't have to worry about securing a syscall number
[08:26] <pitti> true
[08:26] <bluefoxicy> the backtrace will be like, kill <- __stack_chk_fail() <- whatever_vuln_function()
[08:26] <pitti> bluefoxicy: I agree that this is the easiest idea so far
[08:28] <bluefoxicy> I still gotta figure out what to do about libc.  It simultaneously reports and kills self in same line of code.  I may just have to change a 1 to a 0 though
[08:28] <bluefoxicy> also I am looking at the gcc stack smash protector library
[08:28] <bluefoxicy> oh I get it
[08:28] <bluefoxicy> teh compiler would optimize out half the code if they did it a simple way.
[08:29] <pitti> bluefoxicy: I'm not sure about the semantics of signal()
[08:29] <pitti> bluefoxicy: we have to make sure that it blocks at least until the kernel has the chance to call the crash helper
[08:29] <bluefoxicy> pitti:  signal() sets up a signal handler
[08:29] <pitti> erm, I mean kill()
[08:30] <pitti> sorry, brain still sleeping
=== pitti woke up veeery early after only 4 hours of sleep
[08:30] <Mithrandir> siretart: please hold it off.
[08:30] <bluefoxicy> oh good point
[08:31] <Hobbsee> hi Mithrandir 
[08:31] <pitti> bluefoxicy: otherwise we will kill ourself before crash-agent has the chance of examining
[08:31] <bluefoxicy> pitti: yeah, unless a core dump can be used as effectively as gdbing the process
[08:32] <pitti> bluefoxicy: well, if we have a core dump available, then we WON
[08:32] <pitti> bluefoxicy: but a firefox core dump is ~ 130 MB
[08:32] <pitti> even bzip2'ed it's still several MB
[08:32] <bluefoxicy> ahshit.
=== pitti doesn't dare to create an OO.o core
=== ogra [n=ogra@ubuntu/member/ogra]  has joined #ubuntu-devel
[08:32] <bluefoxicy> yeah and we can't stop the process
[08:32] <pitti> moing ogra
[08:33] <bluefoxicy> that would make sigkill work like sigstop
[08:33] <bluefoxicy> which would be bad.
[08:33] <Mithrandir> morning, Hobbsee
[08:33] <pitti> bluefoxicy: well, it's not going to STOP, the process is in state 'D' (uninterruptible kernel sleep) while the crash helper runs
[08:33] <bluefoxicy> pitti:  and when the crash helper exits it goes away?
[08:33] <pitti> bluefoxicy: then I have to jump through some hoops to make it go into state T while tracing it, and then I let it die
[08:34] <pitti> I'm still working on this
[08:34] <bluefoxicy> what happens when the program gets a sigkill during state T
[08:34] <pitti> bluefoxicy: I can't directly gdb from the crash helper since you cannot trace or waitpid() a process in D state
[08:35] <pitti> bluefoxicy: interesting question
[08:35] <bluefoxicy> i.e. I gdb ls, then kill -9 ls
[08:35] <pitti> martin    8207  0.0  0.0   3948   792 pts/3    T+   08:36   0:00 cat
[08:35] <bluefoxicy> it goes to T+?   :P
[08:35] <pitti> kill -9
[08:35] <pitti> martin    8207  0.0  0.0      0     0 pts/3    Z+   08:36   0:00 [cat]  <defunct>
[08:35] <pitti> haha
[08:36] <bluefoxicy> hah, can you still stack dump it?
[08:36] <pitti> bluefoxicy: no
[08:36] <pitti>  bt
[08:36] <pitti> #0  0x00002b4fcde99460 in read () from /lib/libc.so.6
[08:36] <pitti> Cannot access memory at address 0x7fffdcde9468
[08:36] <pitti> detach -> 'ptrace: No such process.'
[08:37] <bluefoxicy> pitti:  okay, how about
[08:37] <pitti> ouch, quitting gdb in that state is ... interesting
[08:37] <pitti> bluefoxicy: but that should be fine
[08:37] <bluefoxicy> pitti:  how about before the kernel actually sends the signal, you incur.... wait()
[08:37] <pitti> bluefoxicy: our crash handler will run *before* the KILL is actually 'executed'
[08:37] <bluefoxicy> so
=== robitaille [i=robitail@ubuntu/member/robitaille]  has joined #ubuntu-devel
[08:38] <bluefoxicy> kill(getpid(),SIGKILL) -> kernel -> fork() -> child: execve(crash handler) -> parent: wait(child) -> child does its thing -> crash handler exits -> as per the function of wait(), program execution continues -> signal kill is sent to the process -> process dies
=== freeflying|away [n=freeflyi@ubuntu/member/freeflying]  has joined #ubuntu-devel
[08:39] <bluefoxicy> pitti:  question:  Can we sleep the process in the kernel via wait() from kernel space
[08:39] <pitti> bluefoxicy: no idea
[08:40] <bluefoxicy> if we can, then this progression naturally puts the entire process to sleep until the crash handler exits
[08:41] <bluefoxicy> pitti:  nothing indicates it can't.
[08:42] <bluefoxicy> pitti:  also I don't think we need to worry about printing the ***stack smash detected*** message to the user from the handler.  That's largely irrelavent, POSIX doesn't care, and I'm sure the user is WELL AWARE something just happened.
=== Gerrath [n=Shane_@unaffiliated/gerrath]  has joined #ubuntu-devel
[08:43] <pitti> bluefoxicy: however, it's nice to have it in syslog
=== freeflying|away [n=freeflyi@ubuntu/member/freeflying]  has joined #ubuntu-devel
[08:43] <bluefoxicy> it doesn't go to syslog()
[08:43] <pitti> does it not? it should ;)
[08:44] <bluefoxicy> is syslog() stack smash protected?
=== pitti would like to see it in auth.log
[08:44] <bluefoxicy> hey
[08:44] <bluefoxicy> you can call syslog() from your crash handler process
[08:44] <pitti> indeed
[08:44] <bluefoxicy> I would really rather not.
[08:45] <bluefoxicy> plus the unique kill(self) indicates that it's a stack smash
[08:47] <pitti> right
[08:48] <bluefoxicy> pitti:  this is down to a one-line change, glibc/debug/stack_chk_fail.c, insert a line at 29, "  kill(getpid(),SIGKILL);", remove the rest of the function if you want
=== ivoks [n=ivoks@ubuntu/member/ivoks]  has joined #ubuntu-devel
[08:52] <pitti> bluefoxicy: debian/patches/commit_suicide.dpatch :)
[08:52] <ivoks> :)
[08:52] <pitti> hi ivoks 
[08:52] <ivoks> hi pitti 
[08:52] <pitti> ivoks: (talking about kill(getpid(),SIGKILL))
[08:53] <ivoks> for what? :)
[08:53] <bluefoxicy> stack smash detection
[08:53] <bluefoxicy> the protection exits nice and cleanly
[08:54] <pitti> ivoks: long story, read ubuntulog if you are interested (short story: calling our crash handler for ssp violations)
[08:54] <bluefoxicy> https://wiki.ubuntu.com/AutomatedProblemReports  This won't trigger
[08:54] <bluefoxicy> so we want a nice and clean self-kill that will indicate that something is clearly wrong and trigger it.
[08:54] <ivoks> oh, i didn't met a user who likes that "your program crashed, what do you want to do?"
[08:54] <bluefoxicy> kill -9'ing yourself is one of the more obvious ones, and pretty special case
[08:55] <bluefoxicy> ivoks:  we can get really good data though.
[08:55] <pitti> ivoks: no, but we developers like it :)
[08:55] <ivoks> i know we/they do, but OS is for users, not developers :)
[08:55] <pitti> ivoks: eventually, users are better of if we actually have a chance of fixing bugs than ignoring them forever due to insufficient information
[08:56] <ivoks> i know and i understand the goal
[08:56] <ivoks> this is just my view on things, feel free to ignore it :)
[08:56] <pitti> ivoks: also, we'll provide different frontends for crash reports
[08:56] <bluefoxicy> it could be majorly automated.
[08:56] <pitti> ivoks: a gtk one that pops into your face is just one alternative :)
[08:57] <bluefoxicy> it should be possible on the user's end to figure out where in the program the crash happened exactly
[08:57] <ivoks> if everything could be places in background, then great
[08:57] <bluefoxicy> that information and a notice that says 'Firefox crashed' and we can figure out what exact function it crashed in
[08:57] <ivoks> placed
[08:57] <bluefoxicy> so the user can get asked once what to do and allow this much to be automated at least
[08:58] <bluefoxicy> pitti:  also, the /proc/pid/maps for that address is extremely important and doubly useful:  it reveals the exact code module we crashed in so we know if it was i.e. Firefox or LibPng that fucked up.
[08:58] <ivoks> bluefoxicy: what about single place for crash handling with one checkbox "send crash information to developers"
[08:58] <ivoks> if you do that for every app, then users will ask why does this happen for firefox, but not for gedit
[08:58] <pitti> bluefoxicy: *nod*
[08:59] <pitti> ivoks: dangerous
[08:59] <bluefoxicy> ivoks: I'm thinking teh first app crashes "Hi what should we do?"  "[X]  Always send minimal crash information to the developers"
[08:59] <pitti> ivoks: you'll likely expose sensitive data to us that way
[08:59] <pitti> ivoks: and if we leave out the potentially sensitive bits, then we also leave out the bits that help us to find the bug
[09:00] <ivoks> ok
[09:00] <bluefoxicy> pitti:  we can send:  1)  Return address from __stack_chk_fail() (this should be unaltered, so is just an address, nothing sensitive here); 2) /proc/pid/maps line indicating what code module (library) that address is in (kernel space, not damaged, not sensitive); 3) name of the application that crashed
[09:00] <bluefoxicy> pitti:  That can be sent quite harmlessly if the user agrees to it, no sensitive data
=== marilize [n=marilize@196.36.161.235]  has joined #ubuntu-devel
[09:01] <pitti> bluefoxicy: true, but eventually deveopers want stacktraces, not just the library a crash occured in
[09:01] <bluefoxicy> the user only needs to agree with it because (omg) we don't want to turn spyware on by default
=== Zdra [n=zdra@132-18.241.81.adsl.skynet.be]  has joined #ubuntu-devel
[09:02] <bluefoxicy> pitti:  a stack dump of the last 64K will be useful; an actual call trace is not gatherable because the information is destroyed
=== [PUPPETS] Gonzo [i=gonzo@80.69.47.16]  has joined #ubuntu-devel
[09:03] <pitti> bluefoxicy: do you have an idea how I can get a stack dump from an external process?
[09:03] <bluefoxicy> pitti:  but a stack dump, 10 bytes or the whole stack, may contain sensitive information; I don't want that automated ever.
[09:03] <bluefoxicy> pitti:  well... you can locate the [stack]  in /proc/pid/maps and read it?
[09:03] <pitti> bluefoxicy: me neither, that's why we have to ask
[09:03] <pitti> oh, indeed
=== rpedro [n=rpedro@87-196-39-157.net.novis.pt]  has joined #ubuntu-devel
[09:03] <pitti> bluefoxicy: and then we can use gdb dump to save that part into a file
[09:04] <bluefoxicy> pitti:  nods.  Like I said, the user can store those for later review, purge say every month or every 3 months or such, and send them later.
[09:04] <pitti> bluefoxicy: we just cannot use gdb then to create a symbolic stack trace from that, or can we?
[09:04] <bluefoxicy> pitti:  you can't do a symbolic stack trace, because the function may be a static function or an inline function
[09:04] <bluefoxicy> the symbols won't be there
[09:04] <pitti> bluefoxicy: gdb has a load command (or so) to restore a memory region from a file, but to do a bt it needs more
[09:05] <bluefoxicy> even if the library isn't stripped the symbols aren't there, you need real debugging information.
[09:05] <pitti> bluefoxicy: we will have them
[09:05] <bluefoxicy> you need to keep the debugging information on your end, the user sends you the address, and you turn that into a function.
[09:05] <pitti> bluefoxicy: that's the point: on an external server, we want to put the stack dump and the symbols together to get a good bt
[09:05] <bluefoxicy> hell you can turn it into a source file ;)
[09:06] <pitti> bluefoxicy: with a core file that's damn easy, gdb exe core, symbols-file, bt
[09:06] <bluefoxicy> pitti:  anything but a stack smash will give you a good back trace.
[09:06] <pitti> but if we only have a stack frame dump, we have to generate this somehow
=== dholbach [n=daniel@i577B0CD0.versanet.de]  has joined #ubuntu-devel
[09:06] <pitti> hi dholbach 
[09:06] <bluefoxicy> mmm.
[09:07] <bluefoxicy> the stack dump is enough to show you what data caused the overflow
[09:07] <bluefoxicy> or whatnot
[09:07] <bluefoxicy> in any other case it'd be rather useless on its own I'd think
[09:07] <pitti> bluefoxicy: you see, we eventually want the result of 'bt full' with symbols
[09:07] <pitti> this is nice, compact, and obvious to read for developers
=== dholbach [n=daniel@i577B0CD0.versanet.de]  has joined #ubuntu-devel
[09:08] <bluefoxicy> can you do a 'bt full' and get addresses
[09:08] <bluefoxicy> and then send those and turn them into symbols?
[09:08] <pitti> bluefoxicy: we have the addresses, yes
[09:08] <pitti> bluefoxicy: but no function arguments, nor local stack variables
[09:08] <pitti> bluefoxicy: of course they can be figured out from the stack trace
[09:08] <pitti> in theory
[09:08] <bluefoxicy> hm
[09:08] <pitti> but we need a tool that actually does that
[09:08] <bluefoxicy> write one :)
[09:08] <pitti> and I'm not sure how gdb can be poked to do it
=== marilize_ [n=marilize@196.36.161.235]  has joined #ubuntu-devel
[09:09] <bluefoxicy> hire someone to write one?  :)
[09:09] <pitti> bluefoxicy: would make a good bounty, yes :)
[09:13] <ivoks> see you later guys
[09:15] <bluefoxicy> I must sleep for it is 3am
[09:16] <bluefoxicy> pitti:  if all else fails, you would not believe how immensely helpful a function name is, because you can get back to source file and function that the problem is in.
[09:16] <bluefoxicy> I say worry about getting the tool working first.
[09:16] <sivang> morning
=== dholbach_ [n=daniel@i577B0CD0.versanet.de]  has joined #ubuntu-devel
=== dholbach_ is now known as dholbach
[09:18] <bluefoxicy> Collect some information, get a symbolic stack trace as far as you can, get a full /proc/PID/maps
[09:18] <bluefoxicy> pitti:  also
[09:18] <bluefoxicy> proc information (/proc/pid/{cmdline,environ,maps,status})
[09:18] <dholbach> good morning
[09:18] <sivang> morning dholbach :)
[09:18] <sivang> yay, new fglrx
[09:18] <dholbach> hi sivang
[09:18] <bluefoxicy> absolutely no automated reporting of cmdline and environ
[09:20] <bluefoxicy> I see that mine is exposing my user name, not really important but in general it's considered not a good idea to publish a list of usernames on the system
[09:20] <bluefoxicy> (this is why we say "bad username and password combination" and not "user does not exist" vs "password is wrong")
[09:21] <bluefoxicy> cmdline on the other hand well... some stupid apps like to take passwords on the command line
[09:21] <bluefoxicy> I've used a few.
[09:22] <bluefoxicy> pitti:  this is never really going to be practical, but it would be wonderful if there was a way for users to volunteer their time by giving us contact information so that we could get in touch with them over anything we need more info on
[09:22] <bluefoxicy> including IRC handles on freenode and OFTC, or e-mail addresses, or IM screen names maybe
[09:23] <bluefoxicy> with the standard "Be advised if we need more information about a crash you report, we will contact you" notice to ward away users that do not want to talk to us
[09:23] <bluefoxicy> that way if we got an interesting, stackless crash we could e-mail the user and say "Hey can you give us some help..."
[09:24] <bluefoxicy> I do know several people who would opt in but they're all geeks :P
[09:24] <dholbach> I'd rather like to have all the information in bug reports and in one central place
[09:24] <bluefoxicy> dholbach: https://wiki.ubuntu.com/AutomatedProblemReports
[09:25] <bluefoxicy> dholbach:  some of the most useful information that can be gathered can get rather sensitive
[09:25] <dholbach> I wouldn't like to have to IM/mail/jabber/whatever people to get information about a crash
[09:26] <dholbach> it's more useful to have all the information in one place, where not only i have that information
=== Gloubiboulga [n=gauvain@ubuntu/member/gloubiboulga]  has joined #ubuntu-devel
=== uniq [n=frode@ubuntu/member/frode]  has joined #ubuntu-devel
[09:27] <bluefoxicy> dholbach:  the useful information we can get consists of executable name, stack dump, addresses of functions on the crash path, /proc/pid/maps so we know what library what address goes with and can identify the function names from our debugging info
[09:28] <bluefoxicy> dholbach: /proc/pid/cmdline and /proc/pid/environ and /proc/pid/status, and perhaps a core dump if it's small enough.
[09:28] <dholbach> i was referring to " including IRC handles on freenode and OFTC, or e-mail addresses, or IM screen names "
[09:28] <bluefoxicy> dholbach: Unfortunately, cmdline, environ, core dump, and stack dump may contain passwords, DECRYPTED GPG KEYS, credit card numbers, logins, etc.
[09:30] <bluefoxicy> dholbach:  I would prefer that we ward users who honestly don't know what they're doing AWAY from submitting any of that, and just gather loads of executable:addresses:proc-pid-maps:proc-pid-status
[09:30] <bluefoxicy> users have to send the other stuff on a case by case basis, mandatory.
[09:30] <dholbach> hm
[09:31] <bluefoxicy> now this is all well and good for those of us who both A) know enough to fiddle with this stuff, and B) have time and actually care to go fiddling.
[09:31] <dholbach> hey Gloubiboulga
[09:31] <bluefoxicy> me, I will likely on a good day go looking when I see a crash; if it says "HI I detected a stack smash" I am definitely looking and making sure you get whatever data you need to fix it
[09:31] <Gloubiboulga> hi dholbach, hi all
[09:32] <bluefoxicy> non-technical users are likely to click the "send non-sensitive data about crashes automatically" button and coast
[09:32] <bluefoxicy> normally, I'll fall into (A) but not (B), which means you'll get automatic non-sensitive data from me but no stack dumps or cores.
[09:33] <bluefoxicy> However i have no problems with someone e-mailing me and asking for a little help if they need more information
[09:33] <bluefoxicy> when it comes down to that, it's a last resort measure; but if you have to come and get me, then you obviously REALLY need the help.
[09:35] <bluefoxicy> the point of it being completely voluntary and opt-in is that only users that really want you to come get them should opt in.  Try to ward them off gently; if they're persistent enough to come along anyway, then they know what they want
[09:35] <bluefoxicy> at any rate
[09:35] <bluefoxicy> I need sleep.
[09:37] <dholbach> good night
=== el [n=konversa@u40-30.dsl.vianetworks.de]  has joined #ubuntu-devel
=== carlos [n=carlos@58.Red-88-9-35.dynamicIP.rima-tde.net]  has joined #ubuntu-devel
=== pvanhoof [n=pvanhoof@mailhost.newtec.be]  has joined #ubuntu-devel
=== ompaul [n=ompaul@ubuntu/member/ompaul]  has joined #ubuntu-devel
=== j_ack [n=rudi@p508D99C3.dip0.t-ipconnect.de]  has joined #ubuntu-devel
=== janimo [n=jani@serverobs.obs.utcluj.ro]  has joined #ubuntu-devel
=== KaiL [n=KaiL@p548F7A6D.dip.t-dialin.net]  has joined #ubuntu-devel
[10:32] <ogra> pitti, hey, thanks for the hwdb review :) (even though we went through the same scripts before :) )
=== doko_ [n=doko@dslb-088-073-093-142.pools.arcor-ip.net]  has joined #ubuntu-devel
[10:33] <pitti> ogra: yes, when I looked at it it was quite familiar :)
[10:35] <ogra> :)
[10:35] <Kamion> Mithrandir: can I upload this gfxboot-theme-ubuntu change?
[10:35] <Kamion>   * Make "lang" file work with locales that require _CC (pt_BR, zh_CN,
[10:35] <Kamion>     zh_TW).
[10:35] <Kamion>   * Use the new "locale" alias for debian-installer/locale.
[10:35] <Mithrandir> Kamion: go ahead.
[10:36] <Mithrandir> Kamion: how did your d-i testing work out yesterday?
[10:36] <Kamion> thanks
[10:36] <ogra> pitti, the other one is a bit more evil inside, i think you havent seen that yet, but it has the same input check so no way to intrude code
[10:36] <Kamion> Mithrandir: found/fixed the locale bug, waiting for kernel upload to come through before uploading d-i again
[10:36] <Kamion> otherwise it miraculously seems to have mostly worked, aside from some weird udev fuckage that Scott's fixed
[10:36] <Mithrandir> Kamion: ok, thanks.  It'll require unifdef to be promoted, but you know that already.
[10:37] <Kamion> yep, waiting for the publisher
[10:37] <Mithrandir> then I just want Scott or Adam to appear so we hopefully can get the livefs-es to build today.
[10:38] <Kamion> still concerned about the boot problem, but Ben reckons that's a kernel bug
[10:38] <Kamion> "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[10:38] <Kamion> "
[10:38] <Kamion> Mithrandir: er - we built livefses last night
[10:38] <Mithrandir> full ones?
[10:38] <Kamion> yeah
[10:38] <Kamion> mdz said the live CD had weird I/O errors on boot though, on several different machines
[10:39] <Mithrandir> uh, I thought -desktop wasn't installable or was that a figment of my imagination?
[10:39] <Kamion> it appeared to work well enough. I think we've hit a corner case that confuses britney but not apt
[10:39] <Mithrandir> ok, goodie, then we "just" need to test and release.
[10:41] <Mithrandir> there are both dapper and edgy .iso-s in http://cdimage.ubuntu.com/daily-live/current/ ; we should probably nuke the dapper ones.
[10:41] <Mithrandir> and it seems we just have i386?
[10:43] <Mithrandir> and no alternate ppc or sparc.
[10:44] <Mithrandir> afk for a little bit
[10:44] <Kamion> powerpc's still hosed
[10:44] <Kamion> (needs gcc-4.1 bootstrap and then a big pile of builds)
[10:44] <ogra> totally ...
[10:45] <ogra> i cant even bootstarp a thin client here ...
[10:46] <Kamion> Mithrandir: nuked the dapper .isos
[10:46] <Kamion> thanks
[10:46] <ogra> edgy_probs looks a lot better today though
[10:46] <Kamion> yes, bootstrapping won't work because aptitude is uninstallable. we know.
[10:54] <infinity1> Kamion: Hrm.  Do you know any tricks to completely delete a queue item, rather than rejecting it?
[10:54] <crimsun> janimo: user request in #xubuntu
[10:55] <janimo> crimusn, thanks
[10:55] <infinity1> Kamion: 'queue -Q rejected info 72147' <-- Due to a lovely race in the builddmaster.  Argh.
[10:55] <infinity1> Kamion: I rejected that and then got the gcc/ppc upload in properly (so that should hit the next publisher run), but it leaves gpass/sparc kinda hosed, since I can't push it through a second time without things exploding.
[10:56] <infinity1> Kamion: I figured if I was oging to break one, some random universe package seemed slightly less important.
[10:58] <Kamion> can a queue item not exist more than once in rejected?
[10:58] <Kamion> I thought it could
[10:58] <Kamion> if not, that's a bug ...
[10:59] <Kamion> bug 52938 <- sigh, TEAM SOYUZ, QUIT MESSING WITH STUFF THAT WASN'T BROKEN
[10:59] <Ubug2> Malone bug 52938 in qprocd "change-override.py -S doesn't move binaries any more" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52938
[10:59] <Mithrandir> infinity1: any chance you could give me a give-back of gcj-4.1 on amd64?
[10:59] <infinity1> Kamion: If I go to reprocess the upload (with just the gpass binaries), it just revives the old broken queue item (with gpass and gcc in the same upload), which is pretty hideously broken.
[11:00] <Mithrandir> we should just be able to do a no-change upload of gpass, shouldn't we?
[11:00] <Kamion> infinity1: ! is there a bug filed about that?
[11:00] <slomo> oh, someone please give-back mono on ppc... should build fine now that gcc built again
=== giftnudel [n=mb@p54B29676.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[11:01] <infinity> Kamion: No idea.  Not really here enough to go looking.
[11:01] <Kamion> infinity: anyway, you need a soyuz person, I think - I'll go ask
[11:02] <infinity> Kamion: There is a bug about the builddmaster race condition that can lead to multiple binary uploads getting stuck together, but that's not been addressed because it can (in theory) only happen when doing manual upload processing.
[11:06] <siretart> Mithrandir: already uploaded (was authorized by mdz)
[11:06] <Mithrandir> siretart: ok
=== j_ack [n=rudi@p508D99C3.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[11:08] <ogra> pitti, would you mind having a look at the ttf-dustin main inclusion report (no brainer font report) ? it keeps khangman and thus edubuntu-desktop uninstallable atm
[11:09] <pitti> ogra: sounds easy enough, a minute
[11:09] <ogra> no hurry ...
[11:09] <ogra> just before knot 1 :)
=== imbrandon [n=brandon@ubuntu/member/pdpc.active.imbrandon]  has joined #ubuntu-devel
[11:11] <pitti> ogra: approved
[11:11] <ogra> thanks ! :)
=== herzi [n=herzi@kiwi.mediascape.de]  has joined #ubuntu-devel
=== heno [n=henrik@henrik.gotadsl.co.uk]  has joined #ubuntu-devel
=== Nuffing [n=JaneW@196.211.88.182]  has joined #ubuntu-devel
=== Nuffing [n=JaneW@196.211.88.182]  has left #ubuntu-devel ["Leaving"] 
[11:40] <Kamion> infinity: still around?
[11:41] <Kamion> infinity: Kinnison wants to know if you were manually running process-upload at any time
=== lukketto [n=lukketto@host251-99.pool8257.interbusiness.it]  has joined #ubuntu-devel
=== highvoltage [n=jono@196.1.57.88]  has joined #ubuntu-devel
=== lukketto [n=lukketto@host251-99.pool8257.interbusiness.it]  has left #ubuntu-devel [] 
=== lloydinho [n=andreas@rosinante.egmont-kol.dk]  has joined #ubuntu-devel
=== jouni__m [n=jouni__m@laku34.adsl.netsonic.fi]  has joined #ubuntu-devel
[11:52] <infinity> Kamion: Well, yes, I thought I made that clear.  Though the error comes from having two things in incoming/ when the builddmaster runs process-upload in a very silly fashion.
=== freeflying|away [n=freeflyi@ubuntu/member/freeflying]  has joined #ubuntu-devel
=== Nuffing [n=JaneW@196.211.88.182]  has joined #ubuntu-devel
=== JaneW [n=JaneW@196.211.88.182]  has left #ubuntu-devel ["Leaving"] 
[12:00] <Kinnison> mdz: ping?
[12:00] <Kinnison> mdz: I have a one line fix for process-upload which will finally squash this nasty race condition
[12:01] <Kinnison> mdz: I'd like to monkey it directly in on drescher so that this kind of problem doesn't occur again
[12:01] <Kinnison> mdz: According to the peace treaty of '06, I need your say-so :-)
[12:01] <mdz> Kinnison: pong
[12:01] <mdz> Kinnison: I'm not familiar with the problem you're referring to; is there a bug#?
=== Kinnison goes to find the bug
[12:02] <Kinnison> mdz: bug 36468
[12:02] <Ubugtu> Malone bug 36468 in launchpad-buildd "builddmaster appears to batch process by accident?" [Medium,Unconfirmed]  http://launchpad.net/bugs/36468
[12:02] <Kinnison> mdz: it tickled this morning and the info this time led us to actually track down the bug
[12:03] <mdz> Kinnison: can I see the patch?
[12:03] <Kinnison> Sure, one sec and I'll ask bzr for it
=== Kinnison suspends workrave before it manages to restbreak me right now
[12:04] <Kinnison> mdz: https://chinstrap.ubuntu.com/~dsilvers/paste/fileJ7lspg.html
=== ToadZzZztool is now known as Toadstool
[12:14] <mdz> Kinnison: patch seems straightforward enough, though from the bug report this doesn't sound like a common situation.  did infinity say otherwise?
[12:15] <mdz> it seems like it would be fine to roll into the next update
=== giftnudel [n=mb@p54B29334.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[12:17] <Kamion> mdz: I don't think it's *that* common, but it happened - see above
[12:17] <Kinnison> mdz: It is a race which can happen if manual processing is going alongside the normal buildd processing
[12:17] <Kinnison> mdz: I.E. most common during port bringup
[12:18] <mdz> Kinnison: it's OK with me if it's important to the archive team
[12:18] <Kamion> I think the db corruption in the queue should lead us to consider this important, yes
[12:20] <mdz> Kamion: has anyone else tried the edgy live CD of doom?
[12:20] <Kinnison> Right, I'll patch that on drescher. I've updated the bug already
[12:20] <Kamion> mdz: I'm 44% of my way through a wget
[12:20] <Kamion> I don't think anyone else has tried yet
[12:20] <mdz> it's very odd
[12:20] <mdz> I hope my burner isn't dying
[12:21] <Kamion> BenC seemed to think the kernel was a bit bust, and that his recent uploads would be happier
[12:21] <Kamion> although that was with respect to another bug
[12:22] <crimsun> mdz: is the debdiff attached to bug 46776 suitable for dapper-updates?
[12:22] <Ubugtu> Malone bug 46776 in apt-proxy "Incompatible with full URL HTTP requests from recent apt versions" [Unknown,Unknown]  http://launchpad.net/bugs/46776
[12:28] <mdz> crimsun: strange report there
[12:28] <mdz> I don't know much about apt-proxy; is it used transparently or as an explicitly-configured proxy?
[12:28] <StevenK> It's explicity configured.
[12:29] <mdz> it's quite normal to send the full URL in the GET when talking to a proxy
[12:29] <mdz> I'd be surprised if mvo changed that
[12:29] <StevenK> I suspect that apt-proxy doesn't think it's a proxy, though.
[12:30] <StevenK> It gets a request, it looks up it's config, it slaps the front part of the URL on and tries to retrieve it.
[12:30] <mdz> oh, it's not configured as a proxy, it's configured in sources.list
[12:30] <Mithrandir> mdz: you just point your sources.list at the apt-proxy host and it does its magic from there, so it's not a standard proxy.
[12:30] <StevenK> It's a bit naive.
[12:30] <StevenK> mdz: Correct.
[12:31] <StevenK> I've stopped using it, because I was sick of it breaking all the time.
[12:31] <StevenK> And apt-proxy v2 is much worse.
[12:32] <tseng> StevenK: oh jeez apt-proxy
[12:33] <mdz> I'd be fairly surprised if apt suddenly started sending GET <url> rather than GET <path>
[12:34] <mdz> I didn't even think that was valid for non-proxies
=== StevenK has scary memories of running apt-proxy v1 through sh -x (yes, it's written in shell) because it didn't work and I was trying to fix it.
[12:35] <Mithrandir> mdz: it's valid for HTTP 1.1
[12:35] <Mithrandir> iirc
[12:35] <StevenK> Mithrandir: Correct.
[12:35] <mdz> ok, I believe you
[12:35] <mdz> however, I've just sniffed, and apt doesn't do that
[12:36] <StevenK> mdz: Which apt, though?
[12:36] <mdz> StevenK: edgy
[12:36] <StevenK> mdz: What about the magical pdiff version in Debian?
[12:36] <mdz> which is identical to dapper
[12:37] <Mithrandir> Kamion: how do you feel about adding "generate sort list for squashfs" to the milestonerhythm tasks?
[12:37] <mdz> StevenK: see the bug; they're claiming that dapper is behaving this way
[12:37] <Kamion> Mithrandir: for every milestone?
=== StevenK re-reads it.
[12:37] <Kamion> I still feel that if we have to do that by hand, we're doing something wron
[12:37] <Kamion> g
[12:37] <Mithrandir> Kamion: it's quite easy to do, so yes.
[12:37] <Mithrandir> Kamion: it requires a boot + grabbing the list + putting it somewhere the build can get at it.
[12:37] <Kamion> Mithrandir: if it's documented how to do it ...
[12:38] <crimsun> mdz: err, dapper and edgy don't appear to have the same versions of apt, or did I misparse?
[12:38] <Mithrandir> Kamion: obviously, that'd be a requirement so it's not just documented in my ~/.zsh_history..
[12:38] <mdz> crimsun: oh, you're right
[12:38] <mdz> but they're close enough
[12:38] <Kamion> Mithrandir: ok then
[12:39] <Mithrandir> Kamion: if you can come up with a way to get to it automatically, I'm all ears, but I can't see a way which works and doesn't require booting the cd.
[12:39] <StevenK> mdz: Colour me as confused as you, then.
=== Fjodor [n=sune@0x55510b65.adsl.cybercity.dk]  has joined #ubuntu-devel
[12:46] <Kamion> infinity: please give-back aptitude 0.4.1-1.1ubuntu2 on powerpc
[12:51] <Kamion> siretart: could you fix libxine-dev's dependencies, please? it depends on libxine1 which doesn't exist
[12:51] <Kamion> siretart: (you could fix libxine1-dbg at the same time then, before knot-1)
[12:52] <mdz> gah, totem still isn't building
[12:53] <mdz> ah, Kamion noticed already
[12:53] <Kamion> yeah, I've been tracing that
[12:53] <Kamion>   libsdl1.2-dev: Depends: libglu1-mesa-dev but it is not going to be installed or
[12:53] <Kamion>                           libglu-dev
[12:53] <Kamion> ^-- xine-lib build failure on ia64 powerpc sparc
[12:53] <Kamion> ia64 also has:
[12:53] <Kamion>   libgnomevfs2-dev: Depends: libgnomevfs2-0 (= 2.15.2-0ubuntu1) but it is not going to be installed
[12:56] <doko> Keybuk: the new dejagnu breaks all the biarch testsuites, running with something like --target_board=unix\{,-m32\} :-(
[12:56] <mdz> Kamion: mesa ftbfs on those architectures
[12:56] <Kamion> yeah, just got that far
[12:56] <mdz> rodarvus: http://librarian.launchpad.net/3405259/buildlog_ubuntu-edgy-powerpc.mesa_6.4.2-1ubuntu2_FAILEDTOBUILD.txt.gz
[12:56] <Mithrandir> doko: Scott's not around ATM.
[12:56] <Kamion> ia64 looks like l-k-h/gcc damage, best ignored
[12:57] <Mithrandir> Kamion: jbailey has a fix for that, but it's post-knot.
[12:57] <Kamion> powerpc and sparc failures are basically the same
[12:57] <Kamion> I'll try building it on powerpc with the new gcc
[12:57] <mdz> powerpc seems like it could be a glibc bug
[12:57] <Mithrandir> do we have anybody who can actually do give-backs around ATM?
[12:57] <mdz> it has -D_GNU_SOURCE which should give it dprintf
[12:57] <doko> Mithrandir: did jbailey talk to you about a lkh update?
[12:57] <mdz> Mithrandir: I can do 'Reset build's, not sure if that's the same thing or not
[12:58] <Mithrandir> doko: yes, it's post-knot-1.
[12:58] <Kamion> mdz: should be, techboard is a member of launchpad-buildd-admins
[12:58] <Mithrandir> mdz: ok.  Can you then give-back gcj-4.1?
[12:58] <Mithrandir> mdz: (on amd64 and powerpc)
[12:59] <mdz> Mithrandir: amd64 says currently building
[12:59] <Kamion> and aptitude on powerpc, per above
[12:59] <Mithrandir> mdz: oh, ok.  Great, then. :-)
[12:59] <mdz> Mithrandir: powerpc reset
[12:59] <Mithrandir> cheers
[12:59] <mdz> also done
[01:00] <fabbione> mdz: the mesa FTBFS is known but it seems to be a problem with the headers and not mesa. If you notice it fails only on big endian machines
[01:01] <fabbione> mdz: i already spoke with jbailey yesterday about it and he has a reduced test case to find a fix
[01:01] <Kamion> can it be a candidate for a workaround in mesa if possible? it's blocking a big load of stuff on those arches
=== Kamion can't build ubiquity until that's sorted
[01:02] <fabbione> Kamion: i don't know.. 
[01:02] <Kamion> I'm test-building it here, will see what's possible
[01:03] <fabbione> thanks
[01:04] <Kamion> well, until that's sorted and about half a dozen other things build, but who's counting
[01:05] <StevenK> Hah
[01:05] <fabbione> Kamion: i am pretty sure jb will show up soon and we can ask him if he has a solution already
[01:06] <StevenK> I did that at work today. "Steve, if I can borrow you for the nth time?", "The sixth, but who's counting."
[01:06] <Kamion> fabbione: that's fine, I just want to have multiple lines of attack in case one fails
=== pygi [n=pygi@83-131-234-249.adsl.net.t-com.hr]  has joined #ubuntu-devel
[01:06] <fabbione> Kamion: yup...
[01:06] <Kamion> I can't do a lot else until I clear this up anyway
[01:07] <Kamion> s/I clear/we clear/ obviously, hubris--
[01:07] <fabbione> Kamion: :D
[01:12] <mdz> kernel is still building
=== FliesLikeALap [n=Ryan@ool-45796272.dyn.optonline.net]  has joined #ubuntu-devel
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-devel
=== pygi [n=pygi@83-131-234-249.adsl.net.t-com.hr]  has joined #ubuntu-devel
=== spacey [n=herman@ubuntu/member/spacey]  has joined #ubuntu-devel
[01:30] <thom> mdz: any idea why debian #213465 was never merged?
[01:30] <Ubugtu> Debian bug 213465 in apt "Subject: HTTPS support (Progeny)" [Wishlist,Open]  http://bugs.debian.org/213465
[01:31] <mdz> thom: yes, openssl license conflicts and massive source code conflicts
[01:31] <siretart> Kamion: I'm on it
[01:31] <thom> gnar openssl
[01:31] <thom> ok, thanks
[01:31] <mdz> I think mvo sorted the source conflicts later on
[01:31] <mdz> but we needed an explicit exception from someone for openssl and didn't get it
[01:32] <thom> bah, ok. so it's just licensing and not a technical objection?
[01:32] <thom> "just"
[01:33] <mdz> there may have been issues with the code as well; I don't remember
[01:34] <mdz> but  we could fix those at any rate
=== Gerrath [n=Shane_@unaffiliated/gerrath]  has joined #ubuntu-devel
[01:35] <thom> mdz: nod
[01:39] <mdz> how is it that this xine-lib breakage isn't reported in Debian yet? odd
=== Tonio_ [n=tonio@vbo91-1-82-238-217-179.fbx.proxad.net]  has joined #ubuntu-devel
=== ThunderStruck [n=ThunderS@ubuntu/member/gnomefreak]  has joined #ubuntu-devel
=== nekohayo-sleep is now known as nekohayo
[01:47] <thom> why the heck did they use stunnel? 
=== thom gibbers
[01:51] <Kamion> siretart: thanks
[01:52] <Kamion> mdz: nobody ever ported it to gnutls then?
[01:53] <thom> Kamion: doesn't look that way - i think the problem is that they use stunnel to do the ssl connection itself, and stunnel is built against openssl
=== epx [n=Elvis@200.249.192.132]  has joined #ubuntu-devel
=== nekohayo [n=jeff@ip216-239-74-27.vif.net]  has left #ubuntu-devel ["Ex-Chat"] 
=== eggauah [n=daniel@150233.cps.virtua.com.br]  has joined #ubuntu-devel
[02:19] <Mithrandir> doko: hmm, it seems like pytho-gnome2-extras isn't updated to the new python policy?
[02:22] <Mithrandir> dholbach: or do you know anything about that?  It seems to block a fair bit of the gnome stack on amd64.
[02:22] <doko> Mithrandir: it is
[02:24] <Mithrandir> doko: doesn't seem to be:
[02:24] <Mithrandir> Depends: python (<< 2.5), python2.4-gnome2-extras, python (>= 2.4)
[02:24] <Mithrandir> ?
[02:25] <doko> but it looks like the packages don't have a XB-Python-Version included. I will fix that, but maybe dholbach and seb128 should forward that to Debian ...
[02:25] <Mithrandir> doko: what does XB-P-V imply?
[02:27] <doko> Mithrandir: it allows us to see, which python versions a package supports, just by looking at the Packages file, not into the package itself. 
[02:27] <Mithrandir> doko: hmm, but that shouldn't make it uninstallable?  Apt doesn't care, does it?
=== stub [n=stub@ppp-58.8.1.197.revip2.asianet.co.th]  has joined #ubuntu-devel
[02:27] <doko> correct
[02:28] <doko> Mithrandir: which architecture?
[02:28] <Mithrandir> doko: amd64
[02:29] <doko> hmm, failed to build on all archs
[02:30] <doko> Mithrandir: totem is requred, but not installable
[02:31] <Kamion> Mithrandir: it didn't build, this all traces back to the mesa breakage
[02:31] <Kamion> ... eventually
=== fabbione raises his fists in sign of almost victory..
[02:32] <fabbione> only init scripts are left to be merged for the cluster suite
=== fabbione starts installing a cluster or two...
[02:35] <ThunderStruck> i still have python* hold backs is it safe to install them (had to do it with X
[02:35] <Kamion> ThunderStruck: if trying to install them removes packages you want to keep installed, then no.
[02:36] <ThunderStruck> ok didnt know the staus of them atm thats why i ask
[02:36] <Kamion> that's basically why apt holds packages back (well, one of the possibilities, anyway, and the likely one here)
=== Hobbsee [n=Hobbsee@ubuntu/member/hobbsee]  has joined #ubuntu-devel
=== lfittl [n=lfittl@83-65-241-12.dynamic.xdsl-line.inode.at]  has joined #ubuntu-devel
[02:37] <doko> Kamion: how do we best remove the outdated binaries? can you find out about binaries which aren't built anymore from a source package?
=== ivoks [n=ivoks@ubuntu/member/ivoks]  has joined #ubuntu-devel
[02:39] <Mithrandir> gnr, ok.
[02:39] <dholbach> Mithrandir, doko: slomo looked into the gnome python packages and merged them - maybe he has an idea.
[02:42] <slomo> dholbach, doko: XB-Python-Version is really missing in that package in debian and for us. i'll fix it with next upload and file a bug in debian...
=== Hobbsee_ [n=Hobbsee@ubuntu/member/hobbsee]  has joined #ubuntu-devel
[02:43] <dholbach> slomo: but that's not the reason why the gnome python world is in limbo atm, is it?
[02:43] <doko> slomo: be prepared for accusations and other stuff ...
[02:44] <slomo> dholbach: nope... that's because build-depends were failing on some archs
[02:44] <Mithrandir> siretart: did you upload a fixed xine?
[02:45] <dholbach> slomo: ok
[02:45] <slomo> dholbach: the same as for most parts of gnome unfortunately :) but i thought that this was fixed already
=== zul [n=chuck@ubuntu/member/zul]  has joined #ubuntu-devel
[02:46] <zul> hiho
[02:46] <Mithrandir> ok, I'll do a new xine-lib upload so we can get totem to build so we can get python-gnome2-extras so serpentine will be installable.  Hopefully.
[02:47] <Kamion> doko: yes, and I will do it AFTER the world has settled down
[02:47] <slomo> doko: hm, the policy only says that this field "should" be there
[02:47] <doko> slomo: that's enough for a bug report :)
[02:48] <slomo> doko: yes... but this imho qualifies only as wishlist, not as important as i first thought ;)
=== ogra_ [n=ogra@p548AF6B8.dip.t-dialin.net]  has joined #ubuntu-devel
[02:49] <siretart> Mithrandir: not yet, just a sec
[02:50] <siretart> Mithrandir: I'm still testbuilding :/
[02:50] <Mithrandir> siretart: too late, I'll do it.
=== snorre [i=will@129.177.56.180]  has joined #ubuntu-devel
[02:50] <siretart> shall I give you my branch?
[02:51] <Kamion> oh I see - mesa defines a clashing version of dprintf
=== jsgotangco [n=jsg123@ubuntu/member/jsgotangco]  has joined #ubuntu-devel
[02:52] <Mithrandir> siretart: have you done anything but changing the libxine-dev depends?
[02:52] <Kamion> there's a libxine1-dbg fix too
=== Mithrandir urges his test build to build faster.
[02:54] <Hobbsee> hehe
[02:54] <Hobbsee> good luck Mithrandir!  once you find out how to do that, do tell me
=== Hobbsee starts her package going too, come to think of that.
[02:55] <siretart> Mithrandir: yes, here is my patch http://paste.debian.net/9027
[02:56] <Mithrandir> siretart: ok, please upload.
[02:56] <Mithrandir> Hobbsee: if I really meant it, I'd probably just have built on a faster machine.
[02:56] <Hobbsee> Mithrandir: true
[02:56] <Mithrandir> it's not like this old amd64 is the fastest one around here.
[02:56] <Hobbsee> hehe
[02:57] <Mithrandir> siretart: please try to make this cron.daily.
[02:57] <Kinnison> Which means in the next 3 minutes please :-)
[02:59] <siretart> Mithrandir: uploaded
[02:59] <Mithrandir> siretart: you didn't confirm, so I uploaded my fixes.
[02:59] <Mithrandir> siretart: well, we raced.  We'll see who wins.
[02:59] <siretart> :)
=== ogra_ [n=ogra@p548AF6B8.dip.t-dialin.net]  has joined #ubuntu-devel
[03:01] <Mithrandir> siretart: according to https://launchpad.net/distros/ubuntu/edgy/+queue?queue_state=2&queue_text=xine-lib, I beat you with six seconds.
[03:01] <siretart> Mithrandir: I just got an Accepted email from launchpad
[03:02] <slomo> both are accepted ;)
[03:03] <Kamion> Mithrandir: the second one wins, though
[03:03] <siretart> let's see what ends in the archive
[03:03] <siretart> lol
[03:03] <Mithrandir> well, that's just as good, since siretart seemed to have more fixes.
[03:04] <Kamion> ok, I should have a mesa fix for the next publisher (not this one)
[03:04] <Kamion> though dear god the fix is nasty
=== WaterSevenUb [n=WaterSev@195-23-238-243.nr.ip.pt]  has joined #ubuntu-devel
[03:08] <Kamion> what's a good test for whether libGLU is working?
[03:09] <mjg59> /usr/lib/xscreensaver/morph3d
[03:09] <sladen> Kamion: glxgears
[03:10] <sladen> Kamion: what particular functions from libGLU are you needing to test?
=== truz_`24 [n=truz_`24@74.129.166.232]  has joined #ubuntu-devel
[03:12] <Kamion> sladen: libGLU
[03:12] <Kamion> (basically ...)
[03:12] <Kamion> nothing in particular, I just want to make sure it like runs
[03:12] <Kamion> I'll try those two once the binaries have built
=== Keybuk [n=scott@quest.netsplit.com]  has joined #ubuntu-devel
[03:13] <sladen> functions like  gluOrtho2D  are used by lots of things as most people can't be bothered to set up their own matrices directly
[03:13] <Kamion> also, I have a heavingly enormous pile of housework to do, so I'll be away for effectively a long lunch. I'll be working late to make up for it, which is probably going to be better timing anyway.
[03:13] <Kamion> Keybuk: good timing
[03:14] <Keybuk> Kamion: oh?
[03:14] <Kamion> Keybuk: please shuffle linux-source-2.6.17 and xine-lib binaries through NEW as they arrive
[03:14] <Kamion> I've done some of the former
[03:14] <Keybuk> sure
[03:16] <doko> mdz, Kamion: please requeue ecj-bootstrap on powerpc
[03:16] <Keybuk> doko: do you mean give back on the buildd?
[03:17] <doko> Keybuk: yes, but wait, gcj-4.1 needs to be given back first (if nobody did that already)
[03:17] <infinity> doko: If it failed because gcj is uninstallable, that's not going to magicall resolve itself until gcj-4.1 can build ( which won't happen until l-k-h is fixed)
[03:18] <Keybuk> hmm, ecj-bootstrap looks built to me
[03:18] <doko> infinity: no, gcj-4.1 doesn't b-d on gcj
[03:19] <infinity> doko: No, but ecj-bootstrap does.
[03:19] <infinity> doko: No?
[03:19] <infinity> doko: But Keybuk's right, ecj-bootstrap is built anyway.
[03:19] <infinity> doko: gcj-4.1, on the other hand, won't build on powerpc until l-k-h gets love.
[03:20] <doko> infinity: so gcc-4.1 did have the same problem, and you worked around it?
[03:20] <infinity> doko: gcc-4.1 "just worked"...
[03:21] <doko> infinity: so why shouldn't gcj-4.1 "just work"?
[03:21] <infinity> doko: Hell if I know, but the build log looks pretty angry to me.
[03:21] <infinity> http://librarian.launchpad.net/3415235/buildlog_ubuntu-edgy-powerpc.gcj-4.1_4.1.1-8ubuntu1_FAILEDTOBUILD.txt.gz
[03:23] <doko> infinity: I'm really wondering how you did succeed building gcc-4.1 then ...
[03:23] <infinity> doko: Either I forgot to upgrade the chroot (possible, I was only half alive), or... I have no idea.
[03:23] <doko> ohh wait, I know ...
[03:24] <infinity> No, wait, I definitely upgraded the chroot before I built it.
=== ogra_ [n=ogra@p548AF6B8.dip.t-dialin.net]  has joined #ubuntu-devel
[03:24] <infinity> Cause I added your bootstrap debs to sources.list before I started, then did an upgrade.
[03:27] <doko> hmm, no I don't know ...
[03:27] <Keybuk> I like this
[03:27] <Keybuk> you're actually investigating why a build *worked*
[03:28] <doko> Keybuk: no, it didn't work: FAILEDTOBUILD ;-P
=== jbailey [n=jbailey@209.217.74.66]  has joined #ubuntu-devel
[03:28] <Keybuk> oh, pardon me
[03:29] <Kamion> ok, there goes mesa
[03:29] <infinity> doko: Well, the point being that gcc and gcj should have either both worked or both failed.  So either we're investigating why gcj failed, or why gcc didn't.
[03:30] <infinity> doko: Oh, no.  I assume it's because gcc bootstrapped with an old gcc, and gcj bootstrapped with the new gcc... Or something.
=== infinity 's head explodes.
[03:31] <doko> infinity: no, gcj-4.1 still had the fixed multilib/multiarch mapping
[03:31] <doko> needs unfixing until glibc and lkh are fixed
[03:32] <jbailey> doko: What glibc problem are you thinking of?
[03:32] <jbailey> doko: I have an lkh that undoes the multiarch for ia64 and parisc like you asked, and has sparc64 headers fixed.
[03:33] <jbailey> What else do you need?
[03:33] <doko> installation in /usr/include/powerpc64-linux-gnu instead of ppc64-linux-gnu
[03:33] <doko> or is this just lkh?
[03:35] <jbailey> Oh, right.  glibc fails to build at the moment with a gcc newer than 4.1.1-2ubuntu4
[03:39] <Kamion> Keybuk: mesa might need NEW-shuffling on non-x86 arches too
[03:39] <Kamion> though that probably won't arrive for a couple of hours yet
[03:39] <doko> jbailey: the consequence of installing into /usr/include/TARGET_ALIAS is that you cannot build an unpatched compiler anymore. Ok, it's edgy, but I have to fix it in every compiler version, and you cannot build an upstream gcc anymore
[03:39] <pitti> mdz: FYI, I cleaned up the field names and their documentation in https://wiki.ubuntu.com/AutomatedProblemReports
=== phanatic [n=phanatic@ubuntu/member/phanatic]  has joined #ubuntu-devel
=== ompaul [n=ompaul@ubuntu/member/ompaul]  has joined #ubuntu-devel
[03:42] <ogra_> Mithrandir, i'll need an exception for ltsp as soon as i have my new amd64 laptop running and am able to fix the breakages 
[03:43] <ogra_> is there already an ETA for the CDs ?
=== kbyrd [n=Miranda@mailout1.vmware.com]  has joined #ubuntu-devel
=== janimo [n=jani@Home03207.cluj.astral.ro]  has joined #ubuntu-devel
[03:53] <janimo> Gloubiboulga: I had not updated xfce4-session and xfce4-utils yet to beta2 as not much happened since the svn snapshot we have and more importantly we have some big patches with touch configure
[03:54] <janimo> Gloubiboulga: just so you know I did not forgot about those :)
[03:54] <janimo> forget
[03:54] <Gloubiboulga> janimo, ok :)
[03:55] <jbailey> doko: Doesn't gcc have a way of specifying additional directories to use for system headers?
[03:57] <doko> jbailey: no, not for biarch, the extension I did write does map the multilibdir to one multiarchdir, not more
[04:02] <Kamion> ogra_: no
[04:03] <ogra_> great :)
[04:03] <ogra_> gives me hope to make it in time ...
[04:03] <ogra_> if only this edgy upgrade would finish ...
=== ogra_ taps his foot
[04:05] <jbailey> doko: I'm not sure what the best solution is then.  I guess probably to get this in upstream with some configury magic so that it can be easily specified.
[04:05] <jbailey> Or try and get it LSB'd or something so that they'll just do it automatically.
=== wasabi [n=wasabi@ubuntu/member/wasabi]  has joined #ubuntu-devel
=== lukketto [n=lukketto@host251-99.pool8257.interbusiness.it]  has joined #ubuntu-devel
=== thierryn [n=thierry@modemcable251.69-131-66.mc.videotron.ca]  has joined #ubuntu-devel
[04:13] <ogra_> hmm, lots of locale errors on upgrade 
[04:16] <doko> Mithrandir: ok to upload gcj-4.1 to fix the build failure on powerpc (and ia64, but that requires a fixed gcc-4.1 as well)
=== Toadstool [n=jcorbier@ubuntu/member/toadstool]  has joined #ubuntu-devel
=== Zdra [n=zdra@51.224-242-81.adsl-dyn.isp.belgacom.be]  has joined #ubuntu-devel
[04:20] <Mithrandir> doko: please.
=== sladen_ [i=paul@starsky.19inch.net]  has joined #ubuntu-devel
=== Riddell_ [i=jr@muse.19inch.net]  has joined #ubuntu-devel
=== sivang_ [i=sivan@muse.19inch.net]  has joined #ubuntu-devel
=== pygi [n=pygi@83-131-236-110.adsl.net.t-com.hr]  has joined #ubuntu-devel
=== Zdra [n=zdra@175.239-243-81.adsl-dyn.isp.belgacom.be]  has joined #ubuntu-devel
=== lukketto [n=lukketto@host251-99.pool8257.interbusiness.it]  has left #ubuntu-devel [] 
[04:38] <ogra_> Keybuk, what about the kino breakage ?
[04:39] <ogra_> any idea what causes that ?
[04:44] <Keybuk> "the kino breakage" ?
[04:44] <Keybuk> 0v
[04:46] <ogra_> http://librarian.launchpad.net/3416008/buildlog_ubuntu-edgy-i386.kino_0.90-1ubuntu1_FAILEDTOBUILD.txt.gz
[04:46] <ogra_> its only i386, ut holds back edubuntu-desktop
[04:47] <ogra_> *but
=== heno [n=henrik@henrik.gotadsl.co.uk]  has joined #ubuntu-devel
[04:49] <Keybuk> kino_common.h:319: error: previous declaration of 'KinoCommon* common' with 'C++' linkage
[04:49] <Keybuk> preferences_dialog.cc:55: error: conflicts with new declaration with 'C' linkage
[04:49] <Keybuk> *shrug*
[04:49] <Keybuk> bug
[04:49] <Keybuk> likely missing extern "C" in the header file
[04:50] <ogra_> strange that it builds flawless on all other arches
=== givre [n=flo@APuteaux-152-1-30-129.w82-120.abo.wanadoo.fr]  has joined #ubuntu-devel
[04:50] <dholbach> debian bug 377174
[04:52] <ogra_> dholbach, thanks !
=== asw [n=asw@karuna.med.harvard.edu]  has joined #ubuntu-devel
=== sbalneav [n=sbalneav@mail.legalaid.mb.ca]  has joined #ubuntu-devel
[05:07] <ogra_> could somebody promote ttf-dustin to unbreak khangman, Keybuk, Kamion ?
=== glatzor [n=sebi@ppp-82-135-83-247.dynamic.mnet-online.de]  has joined #ubuntu-devel
[05:10] <Keybuk> ogra_: done
[05:10] <ogra_> ta !
[05:10] <snorre> I know this is not the right place to ask for support, but I've been trying to get help with building driver modules in the main channel to no avail
=== ogra_ reboots to edgy to see if the new install survived
=== imbrandon_ [n=brandon@CPE-72-135-8-5.kc.res.rr.com]  has joined #ubuntu-devel
[05:16] <snorre> I'm trying to build a driver based on a partial source code that I received directly from the manufacturer, but the driver module can't be inserted in the latest Ubuntu 6.06 Server kernel (2.6.15-23-server)
[05:18] <zul> pitti: ping
[05:18] <ogra> hmm, that didnt work so well 
[05:18] <ogra> apparently i have no fixed font in any fontpath after the upgrade 
[05:21] <Kamion> damnit
[05:21] <Kamion> http://librarian.launchpad.net/3416581/buildlog_ubuntu-edgy-powerpc.mesa_6.4.2-1ubuntu3_FAILEDTOBUILD.txt.gz
[05:22] <Kamion> please fix the toolchain kthxbye :p
[05:25] <ogra> rodarvus, seems like mkfontdir or update-fonts-dir isnt run properly on dapper->edgy upgrades
[05:26] <ogra> i guess from xfonts-base, since the fixed font wasnt found
=== msw [n=msw@rdu-nat.rpath.com]  has joined #ubuntu-devel
[05:28] <Kamion> BenC: <urgent> you need to include asm-generic in linux-kernel-headers on all arches
=== ogra_ [n=ogra@p548AF6B8.dip.t-dialin.net]  has joined #ubuntu-devel
[05:30] <Kamion> I think practically everything that builds anything in C or C++ will FTBFS until that's fixed
=== Huahua [n=hua_@123.49.236.54]  has joined #ubuntu-devel
=== ogra_ [n=ogra@p548AF6B8.dip.t-dialin.net]  has joined #ubuntu-devel
[05:33] <fabbione> BenC: and please apply jbailey patch or sparc is extra doomed
[05:34] <doko> BenC: and please add an *additional* /usr/include/powerpc64-linux-gnu dir with an asm symlink/dir
[05:35] <Kamion> bug 52990
[05:35] <Ubugtu> Malone bug 52990 in linux-source-2.6.17 "asm-generic missing from linux-kernel-headers" [High,Unconfirmed]  http://launchpad.net/bugs/52990
[05:37] <BenC> doh!
[05:37] <BenC> how could I forget asm-generic
=== Kamion goes to mega-time-shift the rest of his working day to a time when it will be more useful. :-)
[05:39] <pygi> Kamion, :)
[05:40] <Hobbsee> Kamion: you mean you dont already?  wow
[05:40] <Kamion> I'm normally about 9:30am until whenever I fall over
[05:40] <Hobbsee> hehe
[05:41] <Hobbsee> Kamion: i thought you werent supposed to fall over
[05:43] <BenC> fabbione: what's the sparc patch? I didn't see anything in jbailey's email
[05:44] <fabbione> BenC: it's in his second email
[05:44] <Kamion> doko: previous linux-kernel-headers didn't have powerpc64-linux-gnu?
[05:44] <fabbione> BenC: see /msg
[05:46] <doko> Kamion: no, but that should be DEB_HOST_GNU_TYPE, but we need to keep the wrong ppc64-linux-gnu until the compilers are rebuilt
[05:47] <Kamion> ah
[05:48] <doko> BenC: and please don't use /usr/include/<target-alias> for ia64 and hppa yet
[05:52] <BenC> doko: ok, I was just copying what was in linux-kernel-headers proper
[05:52] <BenC> I noticed ia64 was already broken
=== ThunderStruck [n=ThunderS@ubuntu/member/gnomefreak]  has joined #ubuntu-devel
=== lmanul [n=manu@dan75-4-82-239-58-38.fbx.proxad.net]  has joined #ubuntu-devel
=== lbm [n=lbm@82.192.173.92]  has joined #ubuntu-devel
=== bronson [n=bronson@209-221-203-148.dsl.qnet.com]  has joined #ubuntu-devel
=== Gloubiboulga [n=gauvain@ubuntu/member/gloubiboulga]  has joined #ubuntu-devel
=== sbodo [n=sbodo@84.236.5.74]  has joined #ubuntu-devel
[06:27] <ogra_> shriek
[06:27] <ogra_> /usr/include/i486-linux-gnu/asm/errno.h:4:31: error: asm-generic/errno.h: No such file or directory
[06:27] <ogra_> whats that ? 
=== givre [n=flo@APuteaux-152-1-30-129.w82-120.abo.wanadoo.fr]  has joined #ubuntu-devel
[06:28] <Keybuk> ogra_: ya know, if you looked, oh, at the previous lines on this channel ... 
[06:29] <ogra_> Keybuk, meh, sorry, i'm blind :)
[06:30] <rodarvus> ogra_: there was a problem with font packages recompiled before we had new xfonts-utils in place
[06:30] <rodarvus> (but I believed these to be fixed by now)
[06:30] <Keybuk> nothing will compile at the moment
[06:30] <rodarvus> ogra: you mean update-fonts-dir is failing for *all* font packages, or just a few?
[06:31] <ogra_> rodarvus, i havent digged deeper than getting X to work here to be able to do some work 
[06:31] <ogra_> there was no fonts.dir in /usr/share/fonts/X11/misc
[06:32] <ogra_> but since it was a plain new install that i upgraded it seems to be broken
=== pvanhoof [n=pvanhoof@d54C0E27E.access.telenet.be]  has joined #ubuntu-devel
=== ogra_ looks in the postinst
[06:33] <rodarvus> ogra_: which package(s) is(are) failing upgrade?
[06:33] <ogra_> i think the fixed font is in xfonts-base or so ...
[06:35] <ogra_> hmm line 436 in /var/lib/dpkg/info/xfonts-base.postinst disagrees ...
[06:37] <Keybuk> https://lists.ubuntu.com/archives/ubuntu-patches/2006-July/000001.html
[06:37] <Keybuk> \o/
=== j_ack [n=rudi@p508D99C3.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[06:39] <ogra_> Keybuk, nice !
[06:40] <BenC> I have a linux-source-2.6.17 that fixes all the lkh breakage...anyone help me in getting it built (considering lkh is broken)?
[06:41] <BenC> pretty much I need linux-kernel-headers from dapper installed just for this build
[06:42] <doko> BenC: isn't linux-source-2.6.17 supposed to use the included headers and don't use the system headers? then it should just build
[06:42] <BenC> not for things like HOSTCC
[06:42] <BenC> check the ia64 build failure, and you'll see what I mean
[06:43] <Keybuk> see, if Linus had accepted CML2 ...
[06:43] <BenC> things like modpost and gen* scripts are C, and wont compile
[06:44] <Keybuk> this will only get worse once klibc is in the kernel
[06:45] <BenC> once klibc is in the kernel, then the kernel wont depend on any userspace libs/headers to compile :)
[06:46] <Keybuk> true, actually
=== Keybuk hugs klibc
[06:47] <Keybuk> I had another read of it this week, and remembered again why I liked it so much at Montral
[06:48] <BenC> so does anyone have the power to brute force the build systems to using dapper's lkh?
[06:48] <Keybuk> infinity can
[06:48] <BenC> I only have the power to break things, not fix them
[06:49] <Keybuk> I'm glad it's not me this cycle
[06:50] <BenC> I could so something evil like copy the headers in place just this one build :)
[06:52] <BenC> actually...a simple -I$(PWD)/include added to the host cflags might make it work aswell
[06:55] <ogra_> rodarvus, 
[06:55] <ogra_> ii  xfonts-utils                   1.0.0-6ubuntu1                 X Window System font utility programs
[06:55] <ogra_> ogra@edubuntu:/usr/share/fonts/X11$ sudo update-fonts-alias --x11r7-layout misc
[06:55] <ogra_> warning: /usr/lib/X11/fonts/misc does not exist or is not a directory
=== giftnudel [n=mb@p54A92654.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[06:56] <ogra_> seems it ignores the new fontpath
[07:00] <BenC> ok, 5.10 kernel uploaded with a temporary -Iinclude in the hostcflags, so things should get back to normal soon
[07:02] <ogra_> yay
[07:03] <rodarvus> ogra_: I'll see if I can reproduce this here
[07:03] <rodarvus> but note that I have a semi-broken environment right now (halfway X 7.1)
[07:03] <rodarvus> so I'm not sure I'll be able to reproduce things as desired :)
[07:04] <ogra_> well the fix is easy 
[07:04] <ogra_> as long as the new packages have it fixed there will only be a few thousand people knock on your door :)
[07:04] <ogra_> before the fix is there ;)
[07:05] <Keybuk> so that's kinda interesting
[07:05] <Keybuk> atheros card doesn't work in currnet lrm
[07:05] <Keybuk> (and man, aptitude got slow!)
[07:06] <ogra_> yeah
[07:07] <ogra_> hmm ? why am i running 2.6.15-23 ?
[07:08] <ogra_> heh, no menu.lst entry ...
[07:12] <bluefoxicy> Is it okay if I make some comments on https://wiki.ubuntu.com/AutomatedProblemReports ?
[07:14] <bluefoxicy> mainly "Providing minimal symbols in binaries" I want to point out that symbols in packages won't point out to you when inline and static functions are used (having debugging information gives you the line of code responsible for an address); and point out which data is sensitive and why.
[07:14] <bluefoxicy> Just tagging them at the end below Superseeded Discussion
[07:15] <Kamion> BenC: any reason your -5.10 changelog isn't just the changes from -5.9 to -5.10, btw? :)
=== rpedro [n=rpedro@87-196-39-157.net.novis.pt]  has joined #ubuntu-devel
[07:20] <BenC> Kamion: mainly because I'd have to get all the ABI files and put them in there if I start a new changelog entry
[07:20] <BenC> this way, I just keep the 4.6 abi files, and the build is happy
[07:21] <bluefoxicy> can someone explain to me what 200 megs of abi files are for
[07:22] <Kamion> BenC: yum, weirdo build system. :)
=== carlos [n=carlos@207.Red-88-3-205.dynamicIP.rima-tde.net]  has joined #ubuntu-devel
[07:23] <bluefoxicy> BenC:  I have a 64 bit system but sometimes a 64-bit ubuntu isn't so hot, re no flash.
[07:23] <BenC> it's like one of those things you'd find if there was such a thing as kernelbuild.cheatplanet.com :)
[07:23] <bluefoxicy> BenC: Any chance of a 64-bit kernel on i386?  It'd be the 64-bit kernels you have now, just marked to be able to install on i386
[07:24] <BenC> bluefoxicy: where do you have 200megs of ABI files?
[07:24] <bluefoxicy> oh, I dunno.  I don't remember how big they were, I just felt like poking you :)
[07:24] <BenC> bluefoxicy: that's a little harder than it sounds
[07:24] <BenC> but I've considered it
[07:24] <BenC> thing is, USB printing is broken on when running 64-bit kernel and 32-bit userspace, so I've been reluctant
[07:25] <bluefoxicy> BenC:  Specific issues I can think of are that your host suddenly becomes like x86-64-pc-gnu-linux (which borks up compilation sometimes, re openssh; at least on Gentoo it has a fit when you try to 32-bit with a 64-bit kernel); and... huh.
[07:25] <bluefoxicy> why would usb printing break.
[07:25] <BenC> 32-bit ioctl thunking isn't supported with usblp
[07:25] <bluefoxicy> aha.
[07:26] <bluefoxicy> that's possible to add though right?
[07:26] <bluefoxicy> Might not be trivial but in the future it can happen..
[07:26] <Kamion> proper multiarch is probably easier :P
[07:26] <BenC> I think fabbione looked at it once because it's inherently broken on sparc64
[07:26] <bluefoxicy> inherently broken == can't be fixed?
[07:27] <BenC> inherently broken meaning sparc64 will always be 64-bit kernel on 32-bit userspace
=== rpedro [n=rpedro@87-196-39-157.net.novis.pt]  has joined #ubuntu-devel
[07:27] <BenC> they have no choice :)
[07:28] <bluefoxicy> why am I reading the changelogs in update manager... I always do this, like there's some useful information in there that I would actually benefit from
[07:28] <BenC> I only read them to see if there's anything funny
[07:28] <dholbach> haha
[07:28] <bluefoxicy>   * Added xserver-xorg-input-elographics to debian/scripts/i386.vars, to let xserver-xorg-input-all on i386) to Require it correctly
[07:29] <bluefoxicy> well, I see bad grammar and a stray ), that's kind of funny.
[07:29] <bluefoxicy> Or at least it got a pause out of me trying to figure out what in the hell it's saying in english.
[07:30] <bluefoxicy> BenC:  I am still waiting for liboobs-1-0 to get a changelog "Applied an optimization for a 30% size reduction that makes it 20% faster"
=== givre [n=flo@APuteaux-152-1-30-129.w82-120.abo.wanadoo.fr]  has joined #ubuntu-devel
[07:36] <tseng> bluefoxicy: could you please direct random comments elsewhere?
[07:36] <bluefoxicy> alright wel I'm gonna tack my comments to the end of this spec since nobody seems to care
[07:36] <bluefoxicy> tseng:  hi.
[07:36] <tseng> hi.
=== ogra_ [n=ogra@p548AF6B8.dip.t-dialin.net]  has joined #ubuntu-devel
[07:47] <tseng> jdub: interesting topic at oscon
[07:51] <jdub> tseng: my talk?
[07:51] <tseng> jdub: yes.
[07:52] <jdub> ahr
[07:52] <tseng> what direction is it going?
[07:52] <jdub> yeah, now i'm also doing a brief ubuntu thingy at tim's radar executive briefing day
[07:52] <jdub> that ought to be fun
[07:52] <jdub> haha
[07:52] <jdub> UP!
[07:52] <jdub> THE ONLY WAY IS UP!
[07:52] <tseng> AND AWAY
[07:52] <tseng> pants off.
[07:52] <tseng> no one says that anymore
[07:53] <mjg59> Jeff does
[07:53] <tseng> i havent heard it in ages
[07:53] <bluefoxicy> if tseng was a starship captain he'd rig the beaming thing so on peoples' birthdays you'd show up on the planet with no pants on.
[07:54] <tseng> uh, right.
[07:54] <tseng> way to miss the mark by about 1000 miles
[07:54] <sivang> bluefoxicy: if you look at my changlog entery for notification daemon, you'd see some meniton of a Mao phrase :)
[07:54] <Keybuk> thank gods I took my birthday off
[07:54] <bluefoxicy> tseng:  I have no idea what you're talking about so I improvised.  it's why I have no real social life.
[07:55] <sivang> Keybuk: took it off from where ?
[07:55] <Keybuk> sivang: as in am taking a day's leave
[07:55] <BenC> so are the build systems disabled right now? My .10 upload isn't even showing in the package list
[07:55] <tseng> sivang: vacation.
[07:55] <Keybuk> bluefoxicy: you need to get a hair cut, a muscle top, and head down those night clubs and shake your booty on the dance floor at pretty ghings
[07:55] <Keybuk> things too
[07:55] <Keybuk> BenC: -10 of?
[07:56] <BenC> linux-source-2.6.17
[07:56] <BenC> 5.10
[07:56] <Keybuk> let me check
[07:56] <Keybuk> ---------|----|----------------------|----------------------|---------------
[07:56] <Keybuk>    72260 | S- | linux-source-2.6.17  | 2.6.17-5.10          | 51 minutes
[07:56] <Keybuk>          | * linux-source-2.6.17/2.6.17-5.10 Component: main Section: devel
[07:56] <Keybuk> ---------|----|----------------------|----------------------|---------------
[07:56] <bluefoxicy> Keybuk:  I am about 98.7% sure you do not want me to do that.
[07:56] <Keybuk> you uploaded it roughly 1 minute too late for the last publisher run ;)
[07:56] <Keybuk> bluefoxicy: oh, why?
[07:57] <BenC> ah, heh
[07:57] <bluefoxicy> Keybuk:  ask tseng
[07:57] <tseng> er what?
[07:57] <Keybuk> tseng: can John not dance?
[07:57] <tseng> Keybuk: i narrowly escaped actually meeting him in person
[07:58] <sivang> Keybuk: ah, I see. Anyway I know this is becoming annoying, and I'm reminidng it to you only if you forgot :) re: SystemCleanUpTool 
[07:59] <Keybuk> hmm, did I not change the status on that?
[07:59] <sivang> Keybuk: not that I noticed, or either received a notification from LP
[07:59] <Keybuk> I did mean to approve it yesterday
[07:59] <Keybuk> maybe I didn't do it hard enough
[08:00] <tseng> bluefoxicy: i have an idea what you are talking about, which is kind of more ironic than either of you realize.
[08:00] <bluefoxicy> :P
[08:01] <tseng> bluefoxicy: but i really have no interest in being involved in clearing it up.
[08:01] <bluefoxicy> okay so I'm not so sure then :P
[08:01] <bluefoxicy> tseng:  I'm interested in figuring out how to get a random .so file relocated to a specific address... I'm currently prodding elfsh to see if it can.
[08:02] <tseng> that sounds like a pretty bad idea
[08:03] <bluefoxicy> no, not really.  If I can get gdb to debug something like elfsh; relocate random lib to a specific address; and then have gdb compare code at address <$foo> to debugging info on the library; then I can pseudo-debug the library even though it's not in the program it used to be in
[08:03] <bluefoxicy> then again I can probably just let it relocate wherever and adjust the address accordingly.  why the heck am I doing this.
[08:03] <Tonio_> hi there, is it the good place to discuss proftpd issues ? I just found a hudge one...
[08:03] <tseng> yeah...
=== givre_ [n=flo@APuteaux-152-1-46-102.w82-120.abo.wanadoo.fr]  has joined #ubuntu-devel
[08:13] <sivang> Keybuk: thanks for all the commnetns. YOu helped make it a better spec. I'm happy to hear more if you have , before you approve it.
[08:14] <Keybuk> is approved already :)
=== j_ack [n=rudi@p508D99C3.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[08:17] <sivang> Keybuk: ah, so even if you have points that are worth thinking of and not just spec approval blockers , they are welcome as well =)
=== johanbr [n=j@jupiter.physics.ubc.ca]  has joined #ubuntu-devel
=== daq4th [n=darkness@netstation-005.cafe.zSeries.org]  has joined #ubuntu-devel
=== pvanhoof [n=pvanhoof@d54C0E27E.access.telenet.be]  has joined #ubuntu-devel
[08:26] <BenC> I think I missed the seeing on the calendar that today was "see how many kernel uploads we can do in one day" day
[08:29] <Keybuk> 24
[08:29] <bluefoxicy> it doesn't matter to me, I'm refraining from rebooting for a while because I don't know where my X video drivers went.
[08:29] <bluefoxicy> they were suddenly "local or obsolete" so I removed them all.
[08:30] <bluefoxicy> and I can't find any kind of *vesa* files anywhere so I am not convinced that Xorg has video drivers anymore o_o
[08:30] <Keybuk> bluefoxicy: renamed to xserver-xorg-video-*
[08:30] <LaserJock> did we have issues in dapper kernel upload with people getting the new -image but not restricted-modules?
[08:30] <bluefoxicy> Keybuk:  ah thanks.  Indeed none installed!
[08:30] <Keybuk> bluefoxicy: yeah, we've mentioned this one to the X SWAT TEAM
[08:30] <Keybuk> but they didn't seem to see the problem
[08:30] <Keybuk> there should be transitional packages
[08:31] <bluefoxicy> the problem.. how to describe.. if you install ubuntu-desktop from an ubuntu-minimal install you probably won't have video drivers.  8)
[08:32] <bluefoxicy> Keybuk:  thanks, I feel much safer now.
=== mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net]  has joined #ubuntu-devel
[08:43] <ogra_> jdub, did you notice that the fridge calendar is gone ?
=== cassidy [n=cassidy@f1-pc174.ulb.ac.be]  has joined #ubuntu-devel
[08:46] <jdub> ogra_: the website moved host without my knowing; i hadn't had time to check everything yet - thanks for pointing that out
=== OculusAquilae [n=oculus@pD9509E76.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[08:46] <ogra_> :)
=== xxpor [n=xxpor@c-69-141-157-224.hsd1.nj.comcast.net]  has joined #ubuntu-devel
[08:55] <LaserJock> jdub: and fridge rss doesn't seem to be working right now, if you didn't know already
[08:56] <Kamion> E: Couldn't find package nic-firmware-2.6.17-5-386-di
[08:56] <Kamion> damnit, soyuz, that's a dep-wait :-P
[08:57] <Kamion> c.f. https://launchpad.net/+builds/+build/228676
=== LinuxJones [n=willy@hlfxns01bbh-142068187253.pppoe-dynamic.ns.aliant.net]  has joined #ubuntu-devel
=== Tonio__ [n=tonio@vbo91-1-82-238-217-179.fbx.proxad.net]  has joined #ubuntu-devel
=== HWolf [n=hc_brugm@212-127-236-81.cable.quicknet.nl]  has joined #ubuntu-devel
=== robitaille [i=robitail@ubuntu/member/robitaille]  has joined #ubuntu-devel
[09:10] <robitaille> jdub,  is there a problem with the fridge?  I can't seem to be able to access any pages except the main page
[09:12] <jdub> robitaille: yeah
[09:12] <jdub> robitaille: it magically changed hosts, and lots of stuff is broken
[09:13] <jdub> robitaille: i haven't had time to climb in and find out what's up yet 
[09:13] <robitaille> ah magic.  The source of so many computer problems :)
[09:13] <jdub> it still has its blue smoke though :)
=== HWolf is now known as HiddenWolf
[09:16] <sladen> ooh, working again
=== j_ack [n=rudi@p508D8E9F.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[09:21] <Kamion> Keybuk: could you give-back debian-installer 20060711ubuntu3 on amd64, i386, and powerpc, please?
[09:22] <elmo> yeah fridge is fixed, sorry about that, my bad
[09:23] <robitaille> thanks elmo  jdub 
[09:23] <ogra_> thanks elmo 
[09:24] <jdub> elmo: rock, thanks!
[09:24] <jdub> elmo put the magic back in :-)
[09:31] <Keybuk> debian-installer 20060711ubuntu3 - powerpc ia64 i386 amd64
[09:33] <sladen> oooh, now that's fixed, time for an update!
[09:33] <sladen> hint hint, prod prod, /me looks in jdub's direction
[09:33] <Kamion> Keybuk: ok, ia64 didn't need it, but it can always fail again ;-)
=== ogra__ [n=ogra@p548AF6B8.dip.t-dialin.net]  has joined #ubuntu-devel
=== ogra_ibook [n=ogra@ubuntu/member/ogra]  has joined #ubuntu-devel
=== pygi [n=pygi@83-131-231-250.adsl.net.t-com.hr]  has joined #ubuntu-devel
[09:49] <Keybuk> Kamion: heh, I haven't given my tool any smarts to exclude or include arches
[09:49] <Keybuk> it just gives back any build that failed
[09:54] <Keybuk> I still want to know what "Blind" and "Consult" mean on my phone
=== yosch [n=yosch@lns-bzn-55-82-255-169-222.adsl.proxad.net]  has joined #ubuntu-devel
=== mhb [n=martin@162.43.broadband7.iol.cz]  has joined #ubuntu-devel
[09:55] <mhb> hello everyone
[09:56] <mhb> I have a tiny little question - is it too late to post specs for Edgy?
[09:56] <Keybuk> it depends, is it a spec you want to implement yourself, or is it one you want somebody else to implement?
[09:56] <mhb> I think I could handle it myself, if someone allows me to
[09:57] <Keybuk> well, you're free to do anything you like :)
[09:57] <mhb> my spec could get rejected
[09:57] <Keybuk> it's too late for a spec to be considered a "feature goal" for edgy ... but that doesn't mean that if your spec were implemented before feature freeze that it could not be part of edgy
[09:57] <Keybuk> right, that's always true though
[09:59] <mhb> to be exact: I want to make some changes in gdm and kdm to enable Gnome and KDE to shutdown even with the "inappropirate" session manager
[09:59] <mhb> do you think it could get approved?
=== ivoks [n=ivoks@ubuntu/member/ivoks]  has joined #ubuntu-devel
[10:01] <Keybuk> I don't see a reason why not, draft a spec
[10:01] <Keybuk> obviously I can't review a spec I haven't read yet
[10:02] <BenC> clearly I'm going to need infinity's help to get a kernel build to succeed today
[10:02] <zul> heh
[10:03] <mhb> Keybuk: I'll do it as soon as I have some free time (on Monday) - I wanted to make sure that it isn't too late
[10:03] <BenC> mhb: it's never too late if you have connections, and monetary contributions always help with that
=== BenC could use a few extra bucks
=== mhb too
[10:04] <Keybuk> BenC: here's a nickel, buy yourself a REAL internet connection :p
[10:05] <BenC> gonna need a lot of nickels to get that last .8 miles of coax to my house
[10:07] <Keybuk> jbailey did an amusing impression of VoIP over your connection earlier
[10:08] <BenC> probably not too far off from when you watch cnn/bbc and their reporters are talking to each other over a sat link :)
[10:10] <BenC> probably need to use ham or cb lingo to make it useful..."The development cycle will not adversely affect our stability...OVER", "10-4, I'll not that on the weekly progress...OVER"
[10:11] <LaserJock> lol
[10:12] <LaserJock> throw in some police codes and you could probably get away with Morse code
=== ogra [n=ogra@ubuntu/member/ogra]  has joined #ubuntu-devel
[10:12] <Keybuk> aha!  Blind and Consult are methods of call transfer
[10:12] <BenC> "Soyuz has a 220 in progress...OVER"
[10:12] <Keybuk> 220 ... hmmm, oh, "running under cron.keybuk due to publisher taking ages again"
[10:12] <LaserJock> "Code Blue, the kernel is going down"
[10:13] <BenC> "Team Admin responding to 220, request backup...OVER"
[10:14] <BenC> "Roger that, Team Admin, The Elmo is en-route, and will aide in the apprehension...OVER"
=== mhb [n=martin@162.43.broadband7.iol.cz]  has left #ubuntu-devel [] 
[10:17] <BenC> I need a spotlight with a cool symbol to shine in the sky so I can summons infinity
[10:17] <tseng> an.. infinity symbol
[10:17] <tseng> and a silloette of elmo the muppet
[10:18] <BenC> hehe
[10:18] <Keybuk> BenC: it's like 8am there ... he's probably only just gone to bed! :P
[10:19] <msw> tseng: people might mistake it for the fedora logo
[10:19] <msw> tseng: http://people.redhat.com/dfong/icFedora/060712/060712.jpg
[10:20] <tseng> yes i am familiar
[10:21] <bluefoxicy> msw:  I mistake the RedHat logo for Carmen Sandiego all the time
[10:21] <LaserJock> haha
[10:21] <LaserJock> that's the first thing I thought of when I saw it
[10:21] <msw> bluefoxicy: heh, yea.  when the design firm first showed Red Hat the shadow man logo, that was the immediate response.  it nearly killed it being accepted
[10:22] <bluefoxicy> LaserJock:  I could rant on it, since I just saw those guys jump up and blatantly claim they invented something that some other guy came up with on the binutils mailing list; but I'll leave that for another time and place
[10:22] <bluefoxicy> msw:  seriously?
[10:23] <LaserJock> I always thought it was cool, though a little mobsterish
[10:23] <bluefoxicy> LaserJock:  I find it fitting.
[10:25] <msw> bluefoxicy: no joke
[10:26] <bluefoxicy> RWX --- ---   /usr/bin/lame
[10:26] <bluefoxicy> Irony.  Total irony.
[10:26] <tseng> ?
[10:26] <tseng> you are an odd bird
[10:27] <msw> lifeless: I just ran bzr vis on a new branch we've been working on -- the results are *MUCH* better than hgk
[10:27] <bluefoxicy> tseng:  executable stack == lame; and lame has an executable stack.  It doesn't make you chuckle?
[10:27] <tseng> bluefoxicy: no, its a pretty obvious (And childish) pun
[10:27] <tseng> lame, even
[10:28] <LaserJock> yikes
[10:28] <bluefoxicy> LaserJock: ?
[10:29] <ThunderStruck> was libonobo updated in dapper?
[10:31] <crimsun> ThunderStruck: ?
[10:31] <msw> ThunderStruck: https://launchpad.net/distros/ubuntu/+source/libbonobo
[10:31] <crimsun> it hasn't been updated since release, why?
[10:32] <ThunderStruck> libonobo was updated for edgy the other day now someone on dapper is complaining about that stpping him from booting ubutnu (same issue on edgy) but rebooting fixed that
[10:33] <ThunderStruck> ok ty just making sure i didnt think it was updated in dapper
=== cassidy [n=cassidy@f1-pc174.ulb.ac.be]  has joined #ubuntu-devel
=== Seveas [n=seveas@ubuntu/member/seveas]  has joined #ubuntu-devel
=== stub [n=stub@ppp-58.8.1.197.revip2.asianet.co.th]  has joined #ubuntu-devel
=== pygi [n=pygi@83-131-232-196.adsl.net.t-com.hr]  has joined #ubuntu-devel
=== rgould [n=rgould@mail.refractions.net]  has joined #ubuntu-devel
=== lmanul [n=manu@dan75-4-82-239-58-38.fbx.proxad.net]  has joined #ubuntu-devel
=== eggauah [n=daniel@150233.cps.virtua.com.br]  has joined #ubuntu-devel
=== jenda [n=jenda@ubuntu/member/jenda]  has joined #ubuntu-devel
=== jenda [n=jenda@ubuntu/member/jenda]  has left #ubuntu-devel ["Find] 
=== phanatic [n=phanatic@ubuntu/member/phanatic]  has joined #ubuntu-devel
=== ompaul [n=ompaul@ubuntu/member/ompaul]  has joined #ubuntu-devel
=== geser [n=michael@85.25.104.150]  has joined #ubuntu-devel
=== robertj [n=robertj@66-188-77-153.dhcp.athn.ga.charter.com]  has joined #ubuntu-devel
=== ryan__ [n=Ryan@ool-45796272.dyn.optonline.net]  has joined #ubuntu-devel
=== sbodo [n=sbodo@84.236.5.74]  has left #ubuntu-devel [] 
=== ogra_ibook [n=ogra@ubuntu/member/ogra]  has joined #ubuntu-devel
=== torkel [i=torkel@69-188.umenet.t3.se]  has joined #ubuntu-devel
=== ogra [n=ogra@ubuntu/member/ogra]  has joined #ubuntu-devel
=== theCore [n=alex@modemcable240.218-70-69.mc.videotron.ca]  has joined #ubuntu-devel