/srv/irclogs.ubuntu.com/2010/11/17/#ubuntu-devel.txt

cjwatsonSpamapS: thank psurbhi for that00:05
psusicjwatson, say umm... is it known that the amd64 builds of grub-emu are broken?  I get "invalid arch independent ELF magic" trying to load modules, but not on an i386 system01:03
=== sanchaz is now known as sanchaz-away
=== jelmer is now known as Guest8056
=== jjohansen1 is now known as jj-afk
=== bjf is now known as bjf[afk]
=== amitk-afk is now known as amitk
=== amitk is now known as amit-afk
=== amit-afk is now known as amitk
=== smb` is now known as smb
dholbachgood morning!07:51
didrocksgood morning Mr Holbach :)07:54
dholbachsalut monsieur didrocks07:57
dholbachcomment ça va?07:57
didrocksdholbach: très bien, et toi ? :)07:57
dholbachtrès bien aussi - merci07:58
* dholbach va chercher du café08:01
didrocksdholbach: french speaking day for you? :)08:06
dholbachdidrocks, just a little bit :)08:06
=== artnay_ is now known as artnay
apwanyone know if there was a build farm problem last night, i have an i386 and a powerpc build failure without logs08:55
wgrantapw: Yeah, there were some issues.08:55
wgrantapw: Not entirely resolved, but it should be mostly better now. Please retry.08:56
wgrantWe may do a mass-giveback later.08:56
wgrantOnce we have everything fixed.08:56
apwwgrant, that sounds bad08:56
wgrantBut no guarantees.08:56
apwnot pkgmangler ?08:56
wgrantNo, internal Launchpad issues.08:57
wgrantpkgbinarymangler is easily fixable.08:57
apwwgrant, yay another successful launchpad release ?09:01
wgrantapw: No, that's not for a couple of hours :)09:04
wgrantAlthough this was an update to see if the release was safe...09:05
=== hunger_ is now known as hunger
=== mthaddon changed the topic of #ubuntu-devel to: Launchpad down/read-only from 10:00-12:00 UTC for DB update | Archive: Open | maverick-proposed is now unfrozen | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/Help
=== Guest8056 is now known as jelmer
rsajdokHow long does it take to get approval of a sent message to the list?09:46
cjwatsonrsajdok: between when I answered you last night and about now, I've been (a) having family time and then (b) in bed.  patience!09:56
ograyou really need to cut donw on that bed stuff :P09:57
cjwatsonthere were a whole 7 messages in the queue when I last looked - not a huge backlog or anything09:57
ogradid you notice that antimony seems to have run out of space ?09:57
cjwatsonso what else is new :P09:57
* ogra wonders whom to ping09:57
cjwatsonI'll look in a bit09:58
ograheh09:58
cjwatsonrsajdok: uh, this mail isn't really appropriate for ubuntu-devel - the package is clearly buildable by Ubuntu so it's basically a support request, and there isn't enough information in your pastebin entry to fix your problem even if it were appropriate10:15
cjwatsonrsajdok: which bzr branch did you check out before running bzr-buildpackage?10:15
cjwatsonrsajdok: I'd be happy to help you figure out your problem, just not on the ubuntu-devel mailing list10:19
=== nijaba is now known as nijaba_afk
joaopintogood morning10:25
joaopintohow do we report bugs for partner packages ?10:25
cjwatsonthey should have source package entries in Ubuntu in Launchpad10:26
joaopintogstreamer0.10-fluendo-plugins-mp3-partner presents an acceptance dialog, but I am not alllowed to cancel the install10:26
joaopintoubuntu-bug tells me it's not a genuine package10:26
cjwatsonhttps://launchpad.net/ubuntu/+source/gstreamer0.10-fluendo-plugins-partner/+filebug (when LP comes back out of read-only mode)10:27
joaopintook, will do, thanks10:28
rsajdokcjwatson: yes, I did check out bzr branch, like description: http://unity.ubuntu.com/getinvolved/#coding10:35
rsajdokcjwatson: so, where is better place for this question?10:35
cjwatsonrsajdok: I see your confusion.  lp:unity is the upstream branch - it doesn't have packaging metadata, so you can't build it with bzr-buildpackage10:36
cjwatsonrsajdok: looking at the source, I guess you need to use cmake to build it (not a build system I know very well).  #ayatana can probably help if you have detailed questions on that10:39
didrocksthe packaging branch is at lp:~unity-team/unity/packaging.10:39
didrocksrsajdok: you have build instructions at https://wiki.ubuntu.com/Unity/InstallationGuide10:39
rsajdokcjwatson: Where is better place to ask questions of involved unity?10:40
cjwatsonrsajdok: I already suggested #ayatana, which I think is right - didrocks?10:44
didrocksyep, this is the good place to be :)10:44
rsajdokcjwatson: thanks for wiki. This is it.10:47
rsajdokdidrocks: thanks also!10:48
=== nijaba_afk is now known as nijaba
=== mthaddon changed the topic of #ubuntu-devel to: Archive: Open | maverick-proposed is now unfrozen | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
seb128ev: thanks for the usb-creator upload11:26
evsure thing.  Sorry I didn't get to it sooner11:26
cjwatsongrr, one of these days I will do a man-db release and not screw something up11:39
cjwatsonogra: cleared up 27GB or so, hopefully that will keep us going for a bit11:43
cjwatson(well, rm -rf still running)11:43
ogra_acgreat11:43
ogra_accant we have some additional disks ?11:43
ogra_acso we dont always hit the limit11:43
cjwatsonfeel free to file an RT, I gathered there were some physical limits11:45
cjwatsonplus there are problems on the internal cdimage mirrors if the size goes up very much, so it's not just that one machine11:45
ogra_achmm, k11:45
cjwatsonthe local archive mirror does tend to grow though11:46
cjwatsonI wonder if I should just drop the separate universe mirror11:46
ogra_aclong term it might be good though, if we one day start building more armel flavours the space might get eaten up faster11:46
cjwatsonbut that makes it easy to have accidents11:46
cjwatsonif you do you're going to have to figure out hosting11:46
cjwatsonit's a problem11:46
ogra_acwell, we only need the temporary space during builds11:47
ogra_acbut if you build in parallel that might be a lot11:47
cjwatsonhosting => cdimage.ubuntu.com11:48
cjwatsonnot talking about antimony ...11:48
ogra_acright, hosting should be okayish, the resultimg images are rather small11:48
ogra_ac*resulting11:49
ogra_acand currently we dont build many more flavours11:49
ogra_ac(natty that is)11:49
=== doko__ is now known as doko
ogra_accjwatson, oh, btw, feel free to ignore the armel build failure of d-i for now, i'm still waiting for a statement from the kernel team about the possibility of using linaro kernels for omap3, until then its fine to let it fail11:51
cjwatsonah, here, I can do some backup clearance11:52
cjwatsonogra_ac: ignoring :-)11:52
cjwatsonogra_ac: 93GB free now, should last for a while11:56
ogra_acyeah, sounds good11:56
=== oubiwann is now known as oubiwann-away
=== oubiwann-away is now known as oubiwann
gesermvo: Hi, do you have a minute to look at this libapt-pkg check from postgresql-debversion? http://paste.ubuntu.com/533447/ Do you have idea what's causing this?12:44
apwpitti, is the natty.cfg under platform under revision control at all ?12:45
pittiapw: no, not any more; other projects use the wi tracker as well now, and I don't think it's appropriate to keep them all in trunk12:46
apwpitti, yep understand why our configs wouldn't be in there, wondered if there was a branch for it,  ie a place with just our configs into which we regularly merge trunk or ... its not in VCS12:46
pittiit's not a VCS right now12:47
apwif its not thats fine, just don't want to do the wrong thing... thanks :)12:47
pittiif somebody wants to create one, I don't mind at all12:47
* ogra_ac lols about none-kernel-n-misc ... apw now thats a funny spec 13:02
apwheh why funny ?13:02
apwour left over crap spec13:03
ogra_acapw, you are aware that this addes another 5-10 items for canonical-arm to even produce such an image ?13:03
ogra_acunless the kernel team planned to build it13:04
apwogra_ac, why so?  i swap in kernels into an existing image all the time13:04
apwthe item was to cover the fact that you need to know whether a linaro kernel is any good for making CDs or not?13:04
ogra_acah, thats something the workitem should say ;)13:04
ogra_aci cant really say if the built initrd will be good, if jasper will work etc13:04
apw[canonical-arm] to swap in a Linaro kernel into an existing CD image confirm feature set:TODO13:05
apwis that better ?13:05
ogra_acunless i actually build it the way we build all our images, the preinstalled images we ship are more like live images13:05
apwogra_ac, yeah i have been droppiing replacement kernels into live CDs, its not 'easy' but its doable13:05
ogra_acyes, we cant say if it will work for preinstalled that way, but can at least roughly judge if the HW works13:05
apwas long as you then put them on a USB stick anyhow13:05
ogra_acright13:06
ogra_acpreinstalled images make that a lot easier than live ones, but its a bit more work than just replacing vmlinuz13:06
apwyep you have to unwrap the initrd and replace the modules and roll it back up13:06
ogra_acnah13:07
ogra_acin preinstalled you just chroot into the rootfs and run update-initramfs ;)13:07
apwahh13:07
ogra_acthe tricky part is that you need to do the bootloader bits by hand13:07
ogra_aci.e. run mkimage to create uImage and uInitrd for uboot13:07
apwanyhow i've used the reworded item so you don't explode :)13:08
ogra_acand put them in the right places13:08
ogra_aci dont explode ;)13:08
ogra_acoriginally it just sounded like we should build an image13:08
apw(through overwork)13:08
ogra_acwhich needs MIR etc13:08
apwheh no, this is a pre-cursor activity, though if they arn't supporting them then its likely they fail before then13:09
ogra_acwell, the kernel and security teams from ubuntu would have to support them13:09
ogra_acthey would just offer the base tree but aligned with our master13:09
apwand i suspect that the work is minor for security but i don't see where we will have resource to do that for sometime yet13:10
ogra_acso the only issue left to use them are config alignments and security updates13:10
ogra_acapw, well, dont you have two new arm positions ?13:10
ogra_aconce these are filled one of them could work on that13:10
apwso if it takes 2 months to fill them, and 2 months to train them, we'll have resource available after feature freeze13:11
ogra_aci assume one fulltime person is enough and it would load off most of the arm work to linaro13:11
apwkernel freeze even13:11
ogra_acyeah, thats a bit late13:11
ogra_acthough its likely that the only kernel for now will be omap313:11
ogra_acomap4 is handled differently anyway13:11
apwand what is the use case for omap3 ?13:11
ogra_acit has teh biggest community in arm land13:12
apwomap4> indeed13:12
ogra_acwe dont want to lose them13:12
ogra_acoh, omap413:12
ogra_accontracts ;)13:12
apwyeah happy we have the incentive and resource for omap413:12
ogra_acbryan will work full time on omap4 with TI as last release13:12
apwyep13:12
ogra_acthere wont be many changes apart from timing at TI side13:13
ScottKapw: There are other teams making plans based on the understanding there will be an omap3 kernel.13:13
ogra_acso the only intresting part is omap313:13
ogra_acsince we want to keep it for the community13:13
apwogra_ac, you wanted omap3 pulled out of master, why was that13:13
apwgiven noone is sending anything to add to any hyperthetical omap3 branch13:13
ogra_acapw, because it got in your way wrt build time and it got into our way wrt flexibility for adding patches late in the cycle13:14
apwthough now you have nothing instead13:14
ogra_achaving it in mainline vs a topic branch was always getting in our way13:14
ogra_acnow i have a vibrant discussion with linaro13:14
ogra_acand hopefully wiht the kernel and security teams13:15
apwheh well there is that13:15
ogra_acwith the target to load all core maintenance work off to linaro13:15
ogra_acand only have the long trem tasks in karnel/security13:15
ogra_ac*term13:15
apwbut if they provide no support for their kernels how do they end up doing anything maintenance wise13:15
ogra_acthe omap3 kernel is pulled directly from our mainline13:16
ogra_acincluding the ubuntu sauce13:16
ogra_acand the existing config13:16
ogra_acso all i need is security commitment for post release13:16
apwbut we already had exactly that in our kernel before we ripped it out, if that is where it is coming from13:16
apwso i am doing the work anyhow before release, and after we'd have to do it?13:17
apwso thats lose lose lose for me ?13:17
ogra_acright, but you wont have to handle e.g. my $new_omap3_board misses patch XY13:17
apwyeah we do, as they don't do any support after release13:17
ogra_acall the patchwork goes to linaro13:17
apwthey don't maintain any released versions, they move on to new ones and do not look back13:18
ogra_acso we could define that no SRUs happen for that kernel ;)13:18
ogra_aconly security maintenance13:18
apwthen we still gained exactly nothing for adding linaro into the loop13:18
ogra_acwhich should be trivial given they are both the same tree13:18
ogra_acsure you do13:19
* apw waits to be enlightened13:19
ogra_acyou dont have to care for it at all during development13:19
ogra_acsince linaro does that13:19
apwexcept their tree comes from whats in our master branch13:19
ogra_acplus their patches13:19
apwand i am providing the sauce and ocnfigs13:19
apwhow are they helping me at all13:19
ogra_acthey maintain the arch specific config13:20
ogra_acnot your job13:20
ogra_acthey maintin everything thats arch specifc13:20
ogra_acyou dont have to touch it13:20
apware they commited to an ubuntu config there?  i heard they were going minimal on all their configs13:20
ogra_acwell, thats discussable i think13:20
ogra_achow i see it is that during developemtn you shouldnt have to touch it at all13:21
apwsee now we have to have a discussion ... i am not convinced there is any time saving in here13:21
apwif we'd just left it in master you'd have 2.6.37-rc2 ker13:21
ogra_acand post release you would take over security maintenance13:21
apwkernels by now, instread of none13:21
ogra_achmm13:21
ogra_acbut you have the maintenance work, have to review patches etc13:21
apwOMAP3 is mostly upstream though isn't it13:22
ogra_aci'm fine not having omap3 before alpha2 if that turns into less duplication13:22
apwas its nearly so old as to being dead13:22
ogra_acits mostly upstream plus linux-omap13:22
ogra_acthe work intensive part is the -omap tree merges13:22
ogra_acwhich adds i.e. support for extra boards etc13:23
apwyou didn't need any of that last cycle13:23
ogra_aclook at all the IGEP2 bugs that are still open13:23
ogra_acwith plenty of them being SRU13:23
ogra_acthere is a *lot* omap3 HW out there my guess would be that we only support 20% yet13:24
ogra_acso there is more to come13:24
apwok so i'll assume that sometime someone will tell us where omap3 is coming from :)13:24
apwand in the meantime i can definatly strip the omap3 configs from our tree13:24
ogra_acwould you prefer to maintin it ?13:24
mvogeser: looking now13:24
apwogra_ac, no i just don't want any supprises13:25
ogra_acmy whole idea was to putt workload off the kernel team13:25
apwso i keep poking the anthill with my stick13:25
ogra_acand you dont sound like i did13:25
apwyep, you have convinced me you are getting something different from linaro if you take their kernel so there is something in it for you13:25
apwsounds like you think you don't need any help from kernel till release13:26
ogra_aci might13:26
apwand you know when we might have resource to help if you do13:26
mvogeser: was this working before?13:26
ogra_acthats still open, and thats why i started the ML discussion13:26
ogra_aci'm a bit sad that nearly everyone chimed in on that apart from kernel and security teams13:26
apwogra_ac, to my mind your team is the only one which can determine whether that branch is acceptable13:27
ogra_acright, but also only for the boards we have13:27
apwas for not responding, that is cause we didn't at the time at least have a clue if we had resource13:27
apwwe know now we do not until the heads are filled13:27
ogra_acthe only real resource that can determine it is the community13:27
highvoltage /win 1513:27
mvogeser: hm, that seems to be working for me (that snippet)13:27
apwogra_ac, your team doesn't have any omap3 to test with ?13:28
ogra_acright, *i* know that you dont have resources, the people discussing in the thread dont13:28
ogra_acwe have beagleboards13:28
ScottKapw and ogra_ac: I know there will be some community testing of omap3.13:28
mvogeser: with g++4.4, let me try 4.513:28
ogra_acScottK, yeah, i would expect so13:28
apwogra_ac, yep someone needs to respond now the position has shaken out, i'll poke people13:28
gesermvo: this was from a natty pbuilder13:28
ogra_acapw, thanks a lot :)13:28
mvogeser: ok, let me try that (for the record, g++-4.5 compiled it too)13:31
gesermvo: I've tried now to build the package in my maverick pbuilder and it worked there, only natty fails13:32
mvogeser: I can reproduce it here now13:40
hallynDoes the i386 build failure at https://launchpad.net/ubuntu/natty/+source/qemu-kvm/0.13.0+noroms-0ubuntu4 look to anyone like anything but a natty toolchain failure?13:42
=== zyga is now known as zyga-food
ScottKhallyn: It's a gcc problem.  You might try to grab the previous gcc-4.5 version and see if you can build it.  The latest gcc-4.5 update is not regression free.13:48
hallynScottK: ok, thanks.  can i specify the version with build-depends, i suppose?13:49
ScottKNo.13:50
hallyndrat13:50
ScottKYou'll need to grab the old one from LP and try it locally.13:50
hallynwell, i know under maverick it compiled fine13:50
hallyni'm just wondering whether to ask kirkland to just re-try the official build, and hope that the dice get cast in my favor this round13:50
mvogeser: hm, I just checked the code and I can not spot the problem - doko, do you have a idea what changed in g++ in natty that makes http://paste.ubuntu.com/533447/plain/ fail? in mav with g++-4.5 that builds fine13:51
dokomvo: no, does it work with gcc-snapshot?13:52
ScottKdoko: Does gcc-snapshot use linaro or fsf upstream?13:54
dokoScottK: fsf13:54
ScottKdoko: Speaking of which, any thoughts on Bug #675347?13:55
ubottuLaunchpad bug 675347 in gcc-4.5 (Ubuntu Natty) "volatile int causes inline assembly build failure" [High,Confirmed] https://launchpad.net/bugs/67534713:55
dokoScottK: as mentioned yesterday, please ask jbrown on #linaro13:56
ScottKOK.13:56
gesermvo, doko: adding --no-as-needed to the -Wl flags makes it link13:56
ogra_acwe should just rewrite everything in shell13:56
ogra_acwould fix all compiler issues13:57
dokogeser: which lib has the symbol?13:58
=== zul is now known as ep
=== ep is now known as zul
geserdoko: it should be in libapt-pkg, see http://paste.ubuntu.com/533466/ for the ldd of the linked binary and objdump -T for libapt-pkg.so14:01
dokogeser. mvo: maybe fix the conftest, so that the library is really linked?14:07
mvodoko: hm? is -lapt-pkg not enough to really link it?14:08
geserdoko: what you mean with really linked? the configure script used "x86_64-linux-gnu-g++ -o conftest -g -O2  -Wl,-Bsymbolic-functions -lapt-pkg conftest.cpp"14:08
geserI used "g++ -o conftest -g -O2  -Wl,-Bsymbolic-functions,--no-as-needed -lapt-pkg conftest.cpp" to make it link14:09
dokomvo: apparently the symbol you are checking for can be used without the lib14:09
dokoit's included from the a header14:09
mvodoko: its in the header as "extern" - is that not enough?14:10
dokomvo: apparently not with --as-needed14:10
mvodoko: hmhm14:11
dokomvo: hmm, the test works on i38614:13
geserI'm on amd64 if it matters14:14
dokogeser: can't reproduce it here :-/14:18
geserdoko: on natty? I got it while test-building a package in my natty pbuilder14:18
dokoyes, natty14:19
geserhmm, mvo perhaps you can help doko how to reproduce it as you managed to reproduce it too14:21
geserwhen I copy the code from the paste and try "g++ -o conftest -g -O2  -Wl,-Bsymbolic-functions -lapt-pkg conftest.cpp" I get the linking error14:24
=== yofel_ is now known as yofel
dokogeser: my libapt-pkg-dev is 0.8.8ubuntu314:30
geserthe same14:30
geserg++ is 4:4.5.1-1ubuntu3 and g++-4.5 is 4.5.1-10ubuntu114:32
* geser is away for around 2h14:33
=== zyga-food is now known as zyga
seb128didrocks, did you open a bug about the gcc-4.5 issue breaking gnome-settings-daemon?14:40
seb128or just pinged doko?14:40
seb128I think other sources fail the same way14:40
didrocksseb128: I just pinged doko and gave him some pastebin as examples14:41
seb128doko, did you have time to investigate the issue didrocks pinged you about? do you need a bug report?14:42
mvojames_w: what is the best way if I have packaging in a bzr-builder compatible branch (i.e. just the packging files like rules, watch, no debian/ dir) and want to build a source pkg from that. I basicly want to say "bzr-buildpackage -S" from such a branch (if possible :)14:50
james_wmvo, --merge14:50
mvo*cough*14:51
mvothanks james_w14:52
mvodoko: hm, odd - on my normal natty system it works, in my pbuider it does not, let me try to figure out what is different14:53
=== azul_ is now known as jodh
=== dendrobates is now known as dendro-afk
=== dendro-afk is now known as dendrobates
apwpitti, on the 'overall cycle' versions of the burn-down charts, what is _not_ included in the graph that is included in the tables below?  I added up the tables and found I had 129 tasks, but when I put that as the burn down start I find the graph is somewhat short at about 118 entries .. and am wondering why15:00
mvodoko: aha! funny (or not). order matters: "g++ -o lala  -lapt-pkg lala.cc" fails, but "g++ -o lala lala.cc -lapt-pkg" does no (<- geser)15:02
dokomvo: ahh, so the fix should be easy15:03
mvodoko: well, its all genearted by configure.ac15:04
seb128doko, hey15:04
seb128doko, so I've sources failing with gcc-4.5, I think it's the same issue that didrocks pinged you about yesterday15:04
seb128doko, should I make those use an another gcc version for now?15:04
dokoseb128: didrocks wanted to file a bug report, I didn't see one yet ...15:06
didrocksdoko: you didn't answered me if you wanted it and asking for others questions… I was taking that as a "no"15:06
dokohmm ...15:07
kirklandhallyn: i was going to merge your last proposal and send that for a build15:07
kirklandhallyn: cool?15:07
seb128didrocks, can you open a bug now?15:08
didrocksnow that it's a clear "yes", sure I can15:08
mvogeser: something like http://paste.ubuntu.com/533486/ should work15:08
mptWho is able to approve blueprints for Natty? Is it anyone in Ubuntu Drivers?15:13
didrocksdoko: seb128: bug #67651915:15
ubottuLaunchpad bug 676519 in gcc-4.5 (Ubuntu) "link failing despite the right linking arguments are presents on command line" [Undecided,New] https://launchpad.net/bugs/67651915:15
seb128didrocks, thanks15:15
dokodidrocks: this smells like mvo's problem above. put the objects before the libs15:15
didrocksdoko: indeed, that worked15:16
mvoI guess a common way of doing it before was using LDFLAGS to smuggle in libs15:16
mvowhere LIBS should be used15:16
dokoyeah ...15:16
cjwatsonor LDLIBS, yes15:16
mvoespecially on configure tests its a bit anoying, but *shrug*15:16
cjwatson(LDLIBS for make's implicit rules)15:17
mvocjwatson: which is the more "correct" one?15:17
mvocjwatson: aha, ok15:17
hallynkirkland: cool, thanks15:18
hallynkirkland: and if it fails to build, then just resend it.15:18
hallyncause the toolchain is eating us for breakfast15:18
seb128doko, bug #67651915:34
ubottuLaunchpad bug 676519 in gnome-settings-daemon (Ubuntu) "link failing despite the right linking arguments are presents on command line" [Undecided,New] https://launchpad.net/bugs/67651915:34
seb128doko, you don't consider that a regression from gcc?15:34
seb128we have several sources failing this way, that used to work, is there any reason gcc couldn't handle the other order?15:35
dokoseb128: yes, --as-needed. it's not a regression, it's exposing a sloppyness in the test case15:35
seb128it was working some days ago with --as-needed15:36
dokono15:36
seb128the previous upload from those source in natty worked15:36
doko--as-needed was introduced on Monday15:36
seb128and --as--needed was in place since it failed due to it15:36
seb128so --as-needed is different from the dso changes?15:36
doko--no-add-needed is in place since the opening of natty, --as-needed since Monday15:37
mvodoko: mumble?15:38
highvoltagelife/win 1315:38
highvoltagebah! (sorry, I should really add gnome-do to my default session!)15:39
smbpitti, Could you accept the kernels for maverick and lucid so they get build15:39
seb128doko, I don't get why the object have to be before?15:41
seb128the gcc man says15:41
seb128       gcc [-c|-S|-E] [-std=standard]15:41
seb128...15:41
seb128           [-o outfile] [@file] infile...15:41
seb128that ought to work in this order no?15:41
=== bjf[afk] is now known as bjf
dokono, the order of objects does matter, same for libs15:42
cjwatsonyeah, this is traditional unix linker stuff15:43
cjwatsongcc's been a bit permissive in the past so people have got a bit sloppy15:43
cjwatsonbut the way you've generally had to do it is that objects that provide symbols used by other objects need to come later15:44
seb128so I guess in a Makefile.am the .la should come before the _LIBS in a _LDADD15:44
seb128NOTIFICATION_AREA_LDADD =\15:45
seb128$(NOTIFICATION_AREA_LIBS)\15:45
seb128libtray.la15:45
seb128is failing because the .la is after the _LIBS?15:45
cjwatsondepends, does libtray.la use symbols from $(NOTIFICATION_AREA_LIBS)?15:46
seb128yes15:46
cjwatsonthen yes15:47
seb128hum ok, I'm not sure how to explain that to upstream in the bug report though15:48
cjwatson"breaks with ld --as-needed" should be enough?15:49
cjwatsonwe're not the only distribution trying this15:49
seb128well it seems fedora has dso linking on and it doesn't break for them15:49
seb128well point is that this order works on other distros15:49
seb128or at least on fedora and opensuse15:50
seb128so I'm not sure how the way we do it is different or pickier15:50
* ScottK also doesn't recall this being disucssed in the planned toolchain changes.15:50
dokoseb128: no, fedora doesn't have it, but OpenSuse has15:57
seb128hum, got disconnected16:01
seb128doko, then I need to check with vuntz why he doesn't get the issue on opensuse with the same tarball16:01
=== diwic is now known as diwic_afk
=== tkamppeter_ is now known as tkamppeter
lifelesskees: is it still fast ? :)16:55
gesermvo: thanks, works without any further changes17:02
=== jam1 is now known as jam
mvogeser: cool17:05
=== jdstrand is now known as jdstrand_
geserI guess the fixes for the missing DSO linking done to some package (add the lib to LDFLAGS) won't work then anymore and the packages FTBFS again17:09
ogra_accjwatson, erm, bug 673504 is not a duplicate ... (beagle XM isnt omap4 but omap3)17:27
ubottuLaunchpad bug 673504 in linux-ti-omap4 (Ubuntu) "Pandaboard chooses a new IP address on each boot" [High,Triaged] https://launchpad.net/bugs/67350417:27
ogra_acerr17:28
ogra_acBug 673509 i mean17:28
ubottuLaunchpad bug 673509 in linux (Ubuntu) "Beagleboard-xm chooses a new IP address on each boot (dup-of: 673504)" [Undecided,Confirmed] https://launchpad.net/bugs/67350917:28
* ogra_ac looks what happened there17:28
jdongwow, this put-each-tty-in-a-cgroup patch works beautifully17:33
* SpamapS is having a bout with his mad-scientist side that wants to spawn 10 ec2 c1.medium's to grep through the entire archive for bash tab completion scripts...17:34
sladencjwatson: do you bother using the upstream (top level) 'ubiquity' project in LP17:34
ebroderSpamapS: Elastic Map Reduce?17:35
ebroderSpamapS: Although apt-file is probably faster :-P17:36
SpamapSebroder: I actually need to look at the content of the scripts, so apt-file would just produce the list of stuff to map/reduce. ;)17:37
keeslifeless: let me try again...17:59
ebrodercjwatson: I'm slightly confused by your e-mail. Is the conclusion that you're going to turn Lua on for 1.99 and we can go forward with that? Or do you want me to look into doing the hwmatch stuff as a C module?18:01
SpamapSajmitch: ping? I see you grabbed the php5 merge (https://merges.ubuntu.com/main.html) ...18:23
ajmitchSpamapS: that's probably an old comment, but I can do it if you'd like :)18:25
SpamapSajmitch: no, I am working on it, so I'll clear that out. ;)18:25
ajmitchok18:25
ajmitchSpamapS: it would have been a comment from a previous release, they should get cleared automatically now18:28
SpamapSajmitch: hm.. maybe a bug or something18:28
ajmitchSpamapS: yeah, a bug that was fixed but the previous comments haven't been cleared out for packages that weren't showing18:30
ajmitchno big issue though18:30
ari-tczewyes, cjwatson has fixed this bug, but if comment is old, it has to be updated. after update, comment won't be saved anymore18:40
=== oubiwann is now known as oubiwann-away
=== oubiwann-away is now known as oubiwann
=== zul_ is now known as zul
SpamapShrm, something broken in natty with the LDAP/SASL libs..18:57
SpamapSconfigure: error: LDAP SASL check failed. Please check config.log for more information.18:57
SpamapSzul: ^^ thats from php518:59
SpamapSzul: current and merged versions18:59
zulSpamapS: umm...interesting18:59
SpamapSzul: help me with sbuild/schroot .. if I wanted it to drop me to the bash command line instead of kicking me out of sbuild.. can I do that with sbuild or do I have to sort of emulate it through schroot'ing in and then making stuff happen?19:00
=== deryck is now known as deryck[lunch]
zulSpamapS: schroot -c <chroot> -u <user>19:01
SpamapSzul: ok, but then I need to install the build-deps ..19:02
SpamapSzul: so -u root, then su to my non-root user after that?19:02
ebroderSpamapS: Do you know about schroot -bc, -rc, and -ec?19:03
zulyou can19:03
SpamapSebroder: the man page doesn't seem to mention a -b19:03
ebroderSpamapS: I do something like session=$(schroot -bc <chroot>); schroot -rc $session -u root apt-get build-dep whatever; schroot -rc $session19:03
ebroderSpamapS: Then be sure to do schroot -ec $session when you're done19:03
SpamapSahh there it is19:04
SpamapSebroder: ok thats what I was looking for19:04
ebroderSpamapS: Also I usually will install pbuilder in the chroot and run schroot -rc $session -u root /usr/lib/pbuilder/pbuilder-satisfydepends out of laziness :)19:04
segleri want to upgrade a package in universe, i did not find any usefull help. where do i start? i already have done packaging it. where do i send it? to revu or directly post it in bugs database?19:07
ScottKsegler: Open a bug, attach the .diff.gz to the bug and subscribe the ubuntu-sponsors team to the bug.19:08
seglerok, thank you19:08
seglerhmm, my source package does not have a diff.gz19:10
seglerdo you mean the debian.tar.gz?19:10
=== xfaf is now known as zul
ScottKsegler: yes19:14
ScottKdiff.gz for format v1 packages and debian.tar.gz for format v319:15
seglerok, thank you :)19:15
=== hanska is now known as dapal
keeshallyn, kirkland: do either of you have an AMD svm system that can test the new version of kvm-ok? (i.e. test it with bios blocking svm and not block svm, etc)?19:26
hallynkees: not me i'm afraid19:27
ebroderkees: I know we've got an AMD machine at the office...somewhere around here. If you can't find someone else I can probably hunt it down and commandeer it.19:27
keesebroder: sweet, that would be great. I can test the intel half, but I have no AMD with virt extensions.19:28
RoAkSoAxachiang: finally fixed the problem for pacemaker :)19:33
achiangRoAkSoAx: cool! what was the answer?19:34
ebroderkees: Ok, found a machine. It's currently in use, so it may take me a little while before I can commandeer it. (AMD machines are *hard* to find these days)19:34
RoAkSoAxachiang: in pengine/Makefile.am I added ptest_LDFLAGS  = $(top_builddir)/pengine/libpengine.la and it worked. However, searching on upstream's mercurial repo, I found that they added libpengine_la_LIBADD  = $(top_builddir)/lib/pengine/libpe_status.la.19:36
achiangah ha19:36
RoAkSoAxachiang: so I just took upstream's change :)19:37
achiangRoAkSoAx: so actually, my theory was correct (iirc). i think it was the syntax that was busted19:37
ebroderkees: When I get the machine, I'm looking at lp:~cpu-checker-dev/cpu-checker/trunk?19:37
RoAkSoAxachiang: yeah, upstream changelog for the fix is: " Correct the linking order so that libpe_status is linked after libpengine."19:38
RoAkSoAxachiang: so indeed was the linking order19:38
keesebroder: http://bazaar.launchpad.net/~cpu-checker-dev/cpu-checker/trunk/annotate/head%3A/kvm-ok19:38
ebroderkees: Cool. I'll let you know19:38
achiangRoAkSoAx: good to know that my understanding of the toolchain is correct. i think it'll be another decade before i understand autotools though. :)19:38
RoAkSoAxachiang: hahah same here :)19:38
SpamapSis there something broken in the linker right now in natty?19:45
SarvattSpamapS: working as intended unfortunately19:46
SpamapShttp://paste.ubuntu.com/533574/19:47
=== deryck[lunch] is now known as deryck
Sarvatthttps://lists.ubuntu.com/archives/ubuntu-devel/2010-October/031860.html19:47
SpamapSfailing to find sasl_version in libsasl2 ...19:48
SpamapSok, so -lsasl is there...19:49
SpamapSerr19:49
SpamapS-lsasl219:49
SpamapSand sasl_version is indeed a symbol from that library19:50
cjwatsonogra_ac: I didn't dup that - it was like that when I got there19:51
cjwatsonsladen: just for code hosting, not bugs etc.19:51
cjwatsonebroder: could you look at doing it as a C module?19:51
cjwatsonebroder: if it's really infeasibly awkward then we'll use lua, but Robert seemed pretty down on that with his upstream hat on19:52
ebrodercjwatson: Sure. I don't suspect it would be hard, although I might change the {black,white}list format to be more C-friendly19:52
ebrodercjwatson: FWIW, I definitely do need Lua for the stuff I'm doing at work, which is part of why I was hopeful we could do it in Ubuntu - so I wouldn't have to rebuild GRUB myself. But I understand if it's a no-go19:54
keeslifeless: still fast, no 503s19:55
geserSpamapS: the problems are the -l... before the conftest.c; since the latest gcc changes (--as-needed) the order matters now19:57
cjwatsonebroder: yeah, just uncomfortable at doing it over a nack from Robert19:59
ebrodercjwatson: OOC, is upstream's support for Lua different from their support for the other extras?20:00
cjwatsonebroder: extras vary wildly20:02
* ebroder nods20:02
cjwatsonebroder: lua's particularly controversial because of its overlap with grub script - most of the others provide a more obviously new feature20:03
cjwatsonthe gpxe extra is fairly scary and poorly tested right now so we don't build that in20:03
cjwatsonthe others are fairly noninvasive (zfs does what it says on the tin, ntldr-img is a bit messy but doesn't really get in anyone's way, 915resolution is basically just an extra command)20:04
cjwatsonthey're in extras just because they aren't copyright-assigned to the FSF20:04
cjwatsonit's a shame extras can't be built truly separately20:05
ebrodercjwatson: Do you think hwmatch seems like something that would be upstreamable, or should I create it as a new extra? (or should I do it as a distro-specific patch to core)20:05
SpamapShmmm.. it seems that php expected sasl_version to be included in -lldap .. precisely the DSO problem.. but still.. it did -lsasl2 too.. so what gives?20:05
cjwatsonebroder: if you're happy to copyright-assign it, and don't mind arguing out the interface, it should be upstreamable20:06
cjwatsoninitially I guess it would be a distro patch though20:06
ebrodercjwatson: Oh, sure. I'll be doing this on work time, so I guess I'll have to get back to you on copyright assignment. Shouldn't keep me from at least starting on the code, though20:07
SpamapSaha.. looks like upstream needs to be smacked a bit. ;)20:09
SpamapSs/smacked/hugged and brought along the path of enlightenment/20:10
ajmitchSpamapS: it's PHP...20:10
SpamapSajmitch: True, they've been smacked so many times, its clear that corporal punishment just doesn't work with them.20:11
cjwatsonebroder: yeah, if it can't be assigned an extra will probably be ok20:11
geserSpamapS: -lsasl2 is left of conftest.c20:11
cjwatsonas long as it's GPLv3-compatible20:12
ebrodercjwatson: Boss just got out of his meeting - copyright assignment won't be an issue20:12
SpamapSgeser: yeah I just figured that out now. :-P20:12
cjwatsonexcellent20:12
SpamapSgeser: but thank you for confirming. :)20:12
SpamapSgeser: patching config.m4 to check sasl2 for sasl_version, which is where it has always lived anyway, is the appropriate fix20:13
geserSpamapS: I know it since this afternoon now too, run into the same problem20:13
SpamapSOh boy.. more of these happen later in the build. :-P20:13
ajmitchSpamapS: OK, I'm glad you're doing the merge now :)20:14
SpamapSajmitch: haha yeah no kidding20:14
ScottKRight.  Because DSO, gcc-4.5, and a new Python weren't enough pain for one release cycle.20:14
SpamapSlooks like OpenSSL is linked improperly as well.20:14
SpamapSScottK: at least we're doing it now, and not in O or P!20:15
SpamapSScottK: I will say that more and more developers that I talk to respect the constant toolchain advancements and appreciate that we figure out how to get stuff working before they have to.20:16
ajmitchScottK: how much of it has been done in fedora already?20:16
ScottKSpamapS: I don't mind toolchain advancements.  I do mind toolchain advancement suprises and I don't recall this one being discussed.20:17
ScottKajmitch: For the -as-needed ordering stuff, none of it.  Allegedly done in opensuse, but accounts vary.20:17
ajmitchhm, it may have been F15 that I was reading about it20:17
ScottKThey did the DSO linking bit.20:18
ScottKThey've also done Python2.7.20:18
ajmitchright20:18
cjwatsonI think this was oversight rather than deliberate surprise ...20:19
=== barry` is now known as barry_
bdrunghallyn: i did more investigation in the kvm / libsdl caps lock bug: the caps lock button is mapped to 'alt gr' and correctly passed to kvm.21:17
hallynbdrung: meaning what, exactly?  The client should be able to decode it as alt-gr?21:29
bdrunghallyn: i patched libsdl: http://pastebin.com/JPwTqqnR - and the press and release of the caps lock key are detected (as alt-gr), but the client doesn't get the key press.21:32
bdrunghallyn: let me test what kvm thinks which key it gets21:34
hallynwell, the old patch implies that the guest gets keydown but not keyup?21:36
bdrungyes, but the client should get 'alt gr' instead of 'caps lock' if caps lock is pressed (caps lock and alt gr are modifier for the same level in NEO2)21:37
RoAkSoAxare new binary packages approved automatically, or do they pass a manual inspection?21:58
cjwatsonthe latter21:58
cjwatsonmore or less21:58
cjwatsonnew binary packages that came from Debian get waved through semi-automatically21:58
RoAkSoAxcjwatson: what's the case when those are binary packages that didn't come from a debian sync/merge?21:59
cjwatsonthen we check them manually21:59
RoAkSoAxcjwatson: ok then, I guess i'll just have to wait because of that, another package FTBFS :) Thanks for the info22:00
=== ogra_ac_ is now known as ogra_ac
=== johanbr_ is now known as johanbr
cjwatsonseb128: are these shared-mime-info and telepathy-mission-control syncs in ~lp_archive/syncs/ yours?23:32
seb128cjwatson, oh yes, I started on that early and got an dsl disconnect which made me stop and I forgot to finish those23:33
seb128cjwatson, you can flush them if you want23:33
seb128sorry about that23:33
seb128cjwatson, if you are doing syncs "-S experimental -f telepathy-glib" and "-S experimental telepathy-gabble" are to do as well23:34
seb128I will do them tomorrow otherwise, I was about to go to bed now23:34
seb128'night23:34
cjwatsonflushing, thanks23:34
seb128cjwatson, thanks23:34
cjwatsonsure, I can do those.  -b seb128?23:34
seb128yes23:35
cjwatsonI was just going to do a man-db sync23:35
=== bjf is now known as bjf[afk]
seb128cjwatson, thanks23:35
cjwatsonnp23:35
bdrunghallyn: can you test the patch attached to bug #427612 and share your results?23:56
ubottuLaunchpad bug 427612 in qemu-kvm (Ubuntu) "does not pass pressed caps lock to client" [Low,New] https://launchpad.net/bugs/42761223:56

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!