[00:05] <cjwatson> SpamapS: thank psurbhi for that
[01:03] <psusi> cjwatson, 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 system
[07:51] <dholbach> good morning!
[07:54] <didrocks> good morning Mr Holbach :)
[07:57] <dholbach> salut monsieur didrocks
[07:57] <dholbach> comment ça va?
[07:57] <didrocks> dholbach: très bien, et toi ? :)
[07:58] <dholbach> très bien aussi - merci
[08:01]  * dholbach va chercher du café
[08:06] <didrocks> dholbach: french speaking day for you? :)
[08:06] <dholbach> didrocks, just a little bit :)
[08:55] <apw> anyone know if there was a build farm problem last night, i have an i386 and a powerpc build failure without logs
[08:55] <wgrant> apw: Yeah, there were some issues.
[08:56] <wgrant> apw: Not entirely resolved, but it should be mostly better now. Please retry.
[08:56] <wgrant> We may do a mass-giveback later.
[08:56] <wgrant> Once we have everything fixed.
[08:56] <apw> wgrant, that sounds bad
[08:56] <wgrant> But no guarantees.
[08:56] <apw> not pkgmangler ?
[08:57] <wgrant> No, internal Launchpad issues.
[08:57] <wgrant> pkgbinarymangler is easily fixable.
[09:01] <apw> wgrant, yay another successful launchpad release ?
[09:04] <wgrant> apw: No, that's not for a couple of hours :)
[09:05] <wgrant> Although this was an update to see if the release was safe...
[09:46] <rsajdok> How long does it take to get approval of a sent message to the list?
[09:56] <cjwatson> rsajdok: between when I answered you last night and about now, I've been (a) having family time and then (b) in bed.  patience!
[09:57] <ogra> you really need to cut donw on that bed stuff :P
[09:57] <cjwatson> there were a whole 7 messages in the queue when I last looked - not a huge backlog or anything
[09:57] <ogra> did you notice that antimony seems to have run out of space ?
[09:57] <cjwatson> so what else is new :P
[09:57]  * ogra wonders whom to ping
[09:58] <cjwatson> I'll look in a bit
[09:58] <ogra> heh
[10:15] <cjwatson> rsajdok: 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 appropriate
[10:15] <cjwatson> rsajdok: which bzr branch did you check out before running bzr-buildpackage?
[10:19] <cjwatson> rsajdok: I'd be happy to help you figure out your problem, just not on the ubuntu-devel mailing list
[10:25] <joaopinto> good morning
[10:25] <joaopinto> how do we report bugs for partner packages ?
[10:26] <cjwatson> they should have source package entries in Ubuntu in Launchpad
[10:26] <joaopinto> gstreamer0.10-fluendo-plugins-mp3-partner presents an acceptance dialog, but I am not alllowed to cancel the install
[10:26] <joaopinto> ubuntu-bug tells me it's not a genuine package
[10:27] <cjwatson> https://launchpad.net/ubuntu/+source/gstreamer0.10-fluendo-plugins-partner/+filebug (when LP comes back out of read-only mode)
[10:28] <joaopinto> ok, will do, thanks
[10:35] <rsajdok> cjwatson: yes, I did check out bzr branch, like description: http://unity.ubuntu.com/getinvolved/#coding
[10:35] <rsajdok> cjwatson: so, where is better place for this question?
[10:36] <cjwatson> rsajdok: I see your confusion.  lp:unity is the upstream branch - it doesn't have packaging metadata, so you can't build it with bzr-buildpackage
[10:39] <cjwatson> rsajdok: 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 that
[10:39] <didrocks> the packaging branch is at lp:~unity-team/unity/packaging.
[10:39] <didrocks> rsajdok: you have build instructions at https://wiki.ubuntu.com/Unity/InstallationGuide
[10:40] <rsajdok> cjwatson: Where is better place to ask questions of involved unity?
[10:44] <cjwatson> rsajdok: I already suggested #ayatana, which I think is right - didrocks?
[10:44] <didrocks> yep, this is the good place to be :)
[10:47] <rsajdok> cjwatson: thanks for wiki. This is it.
[10:48] <rsajdok> didrocks: thanks also!
[11:26] <seb128> ev: thanks for the usb-creator upload
[11:26] <ev> sure thing.  Sorry I didn't get to it sooner
[11:39] <cjwatson> grr, one of these days I will do a man-db release and not screw something up
[11:43] <cjwatson> ogra: cleared up 27GB or so, hopefully that will keep us going for a bit
[11:43] <cjwatson> (well, rm -rf still running)
[11:43] <ogra_ac> great
[11:43] <ogra_ac> cant we have some additional disks ?
[11:43] <ogra_ac> so we dont always hit the limit
[11:45] <cjwatson> feel free to file an RT, I gathered there were some physical limits
[11:45] <cjwatson> plus there are problems on the internal cdimage mirrors if the size goes up very much, so it's not just that one machine
[11:45] <ogra_ac> hmm, k
[11:46] <cjwatson> the local archive mirror does tend to grow though
[11:46] <cjwatson> I wonder if I should just drop the separate universe mirror
[11:46] <ogra_ac> long term it might be good though, if we one day start building more armel flavours the space might get eaten up faster
[11:46] <cjwatson> but that makes it easy to have accidents
[11:46] <cjwatson> if you do you're going to have to figure out hosting
[11:46] <cjwatson> it's a problem
[11:47] <ogra_ac> well, we only need the temporary space during builds
[11:47] <ogra_ac> but if you build in parallel that might be a lot
[11:48] <cjwatson> hosting => cdimage.ubuntu.com
[11:48] <cjwatson> not talking about antimony ...
[11:48] <ogra_ac> right, hosting should be okayish, the resultimg images are rather small
[11:49] <ogra_ac> *resulting
[11:49] <ogra_ac> and currently we dont build many more flavours
[11:49] <ogra_ac> (natty that is)
[11:51] <ogra_ac> cjwatson, 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 fail
[11:52] <cjwatson> ah, here, I can do some backup clearance
[11:52] <cjwatson> ogra_ac: ignoring :-)
[11:56] <cjwatson> ogra_ac: 93GB free now, should last for a while
[11:56] <ogra_ac> yeah, sounds good
[12:44] <geser> mvo: 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:45] <apw> pitti, is the natty.cfg under platform under revision control at all ?
[12:46] <pitti> apw: 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 trunk
[12:46] <apw> pitti, 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 VCS
[12:47] <pitti> it's not a VCS right now
[12:47] <apw> if its not thats fine, just don't want to do the wrong thing... thanks :)
[12:47] <pitti> if somebody wants to create one, I don't mind at all
[13:02]  * ogra_ac lols about none-kernel-n-misc ... apw now thats a funny spec 
[13:02] <apw> heh why funny ?
[13:03] <apw> our left over crap spec
[13:03] <ogra_ac> apw, you are aware that this addes another 5-10 items for canonical-arm to even produce such an image ?
[13:04] <ogra_ac> unless the kernel team planned to build it
[13:04] <apw> ogra_ac, why so?  i swap in kernels into an existing image all the time
[13:04] <apw> the 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_ac> ah, thats something the workitem should say ;)
[13:04] <ogra_ac> i cant really say if the built initrd will be good, if jasper will work etc
[13:05] <apw> [canonical-arm] to swap in a Linaro kernel into an existing CD image confirm feature set:TODO
[13:05] <apw> is that better ?
[13:05] <ogra_ac> unless i actually build it the way we build all our images, the preinstalled images we ship are more like live images
[13:05] <apw> ogra_ac, yeah i have been droppiing replacement kernels into live CDs, its not 'easy' but its doable
[13:05] <ogra_ac> yes, we cant say if it will work for preinstalled that way, but can at least roughly judge if the HW works
[13:05] <apw> as long as you then put them on a USB stick anyhow
[13:06] <ogra_ac> right
[13:06] <ogra_ac> preinstalled images make that a lot easier than live ones, but its a bit more work than just replacing vmlinuz
[13:06] <apw> yep you have to unwrap the initrd and replace the modules and roll it back up
[13:07] <ogra_ac> nah
[13:07] <ogra_ac> in preinstalled you just chroot into the rootfs and run update-initramfs ;)
[13:07] <apw> ahh
[13:07] <ogra_ac> the tricky part is that you need to do the bootloader bits by hand
[13:07] <ogra_ac> i.e. run mkimage to create uImage and uInitrd for uboot
[13:08] <apw> anyhow i've used the reworded item so you don't explode :)
[13:08] <ogra_ac> and put them in the right places
[13:08] <ogra_ac> i dont explode ;)
[13:08] <ogra_ac> originally it just sounded like we should build an image
[13:08] <apw> (through overwork)
[13:08] <ogra_ac> which needs MIR etc
[13:09] <apw> heh no, this is a pre-cursor activity, though if they arn't supporting them then its likely they fail before then
[13:09] <ogra_ac> well, the kernel and security teams from ubuntu would have to support them
[13:09] <ogra_ac> they would just offer the base tree but aligned with our master
[13:10] <apw> and i suspect that the work is minor for security but i don't see where we will have resource to do that for sometime yet
[13:10] <ogra_ac> so the only issue left to use them are config alignments and security updates
[13:10] <ogra_ac> apw, well, dont you have two new arm positions ?
[13:10] <ogra_ac> once these are filled one of them could work on that
[13:11] <apw> so if it takes 2 months to fill them, and 2 months to train them, we'll have resource available after feature freeze
[13:11] <ogra_ac> i assume one fulltime person is enough and it would load off most of the arm work to linaro
[13:11] <apw> kernel freeze even
[13:11] <ogra_ac> yeah, thats a bit late
[13:11] <ogra_ac> though its likely that the only kernel for now will be omap3
[13:11] <ogra_ac> omap4 is handled differently anyway
[13:11] <apw> and what is the use case for omap3 ?
[13:12] <ogra_ac> it has teh biggest community in arm land
[13:12] <apw> omap4> indeed
[13:12] <ogra_ac> we dont want to lose them
[13:12] <ogra_ac> oh, omap4
[13:12] <ogra_ac> contracts ;)
[13:12] <apw> yeah happy we have the incentive and resource for omap4
[13:12] <ogra_ac> bryan will work full time on omap4 with TI as last release
[13:12] <apw> yep
[13:13] <ogra_ac> there wont be many changes apart from timing at TI side
[13:13] <ScottK> apw: There are other teams making plans based on the understanding there will be an omap3 kernel.
[13:13] <ogra_ac> so the only intresting part is omap3
[13:13] <ogra_ac> since we want to keep it for the community
[13:13] <apw> ogra_ac, you wanted omap3 pulled out of master, why was that
[13:13] <apw> given noone is sending anything to add to any hyperthetical omap3 branch
[13:14] <ogra_ac> apw, because it got in your way wrt build time and it got into our way wrt flexibility for adding patches late in the cycle
[13:14] <apw> though now you have nothing instead
[13:14] <ogra_ac> having it in mainline vs a topic branch was always getting in our way
[13:14] <ogra_ac> now i have a vibrant discussion with linaro
[13:15] <ogra_ac> and hopefully wiht the kernel and security teams
[13:15] <apw> heh well there is that
[13:15] <ogra_ac> with the target to load all core maintenance work off to linaro
[13:15] <ogra_ac> and only have the long trem tasks in karnel/security
[13:15] <ogra_ac> *term
[13:15] <apw> but if they provide no support for their kernels how do they end up doing anything maintenance wise
[13:16] <ogra_ac> the omap3 kernel is pulled directly from our mainline
[13:16] <ogra_ac> including the ubuntu sauce
[13:16] <ogra_ac> and the existing config
[13:16] <ogra_ac> so all i need is security commitment for post release
[13:16] <apw> but we already had exactly that in our kernel before we ripped it out, if that is where it is coming from
[13:17] <apw> so i am doing the work anyhow before release, and after we'd have to do it?
[13:17] <apw> so thats lose lose lose for me ?
[13:17] <ogra_ac> right, but you wont have to handle e.g. my $new_omap3_board misses patch XY
[13:17] <apw> yeah we do, as they don't do any support after release
[13:17] <ogra_ac> all the patchwork goes to linaro
[13:18] <apw> they don't maintain any released versions, they move on to new ones and do not look back
[13:18] <ogra_ac> so we could define that no SRUs happen for that kernel ;)
[13:18] <ogra_ac> only security maintenance
[13:18] <apw> then we still gained exactly nothing for adding linaro into the loop
[13:18] <ogra_ac> which should be trivial given they are both the same tree
[13:19] <ogra_ac> sure you do
[13:19]  * apw waits to be enlightened
[13:19] <ogra_ac> you dont have to care for it at all during development
[13:19] <ogra_ac> since linaro does that
[13:19] <apw> except their tree comes from whats in our master branch
[13:19] <ogra_ac> plus their patches
[13:19] <apw> and i am providing the sauce and ocnfigs
[13:19] <apw> how are they helping me at all
[13:20] <ogra_ac> they maintain the arch specific config
[13:20] <ogra_ac> not your job
[13:20] <ogra_ac> they maintin everything thats arch specifc
[13:20] <ogra_ac> you dont have to touch it
[13:20] <apw> are they commited to an ubuntu config there?  i heard they were going minimal on all their configs
[13:20] <ogra_ac> well, thats discussable i think
[13:21] <ogra_ac> how i see it is that during developemtn you shouldnt have to touch it at all
[13:21] <apw> see now we have to have a discussion ... i am not convinced there is any time saving in here
[13:21] <apw> if we'd just left it in master you'd have 2.6.37-rc2 ker
[13:21] <ogra_ac> and post release you would take over security maintenance
[13:21] <apw> kernels by now, instread of none
[13:21] <ogra_ac> hmm
[13:21] <ogra_ac> but you have the maintenance work, have to review patches etc
[13:22] <apw> OMAP3 is mostly upstream though isn't it
[13:22] <ogra_ac> i'm fine not having omap3 before alpha2 if that turns into less duplication
[13:22] <apw> as its nearly so old as to being dead
[13:22] <ogra_ac> its mostly upstream plus linux-omap
[13:22] <ogra_ac> the work intensive part is the -omap tree merges
[13:23] <ogra_ac> which adds i.e. support for extra boards etc
[13:23] <apw> you didn't need any of that last cycle
[13:23] <ogra_ac> look at all the IGEP2 bugs that are still open
[13:23] <ogra_ac> with plenty of them being SRU
[13:24] <ogra_ac> there is a *lot* omap3 HW out there my guess would be that we only support 20% yet
[13:24] <ogra_ac> so there is more to come
[13:24] <apw> ok so i'll assume that sometime someone will tell us where omap3 is coming from :)
[13:24] <apw> and in the meantime i can definatly strip the omap3 configs from our tree
[13:24] <ogra_ac> would you prefer to maintin it ?
[13:24] <mvo> geser: looking now
[13:25] <apw> ogra_ac, no i just don't want any supprises
[13:25] <ogra_ac> my whole idea was to putt workload off the kernel team
[13:25] <apw> so i keep poking the anthill with my stick
[13:25] <ogra_ac> and you dont sound like i did
[13:25] <apw> yep, you have convinced me you are getting something different from linaro if you take their kernel so there is something in it for you
[13:26] <apw> sounds like you think you don't need any help from kernel till release
[13:26] <ogra_ac> i might
[13:26] <apw> and you know when we might have resource to help if you do
[13:26] <mvo> geser: was this working before?
[13:26] <ogra_ac> thats still open, and thats why i started the ML discussion
[13:26] <ogra_ac> i'm a bit sad that nearly everyone chimed in on that apart from kernel and security teams
[13:27] <apw> ogra_ac, to my mind your team is the only one which can determine whether that branch is acceptable
[13:27] <ogra_ac> right, but also only for the boards we have
[13:27] <apw> as for not responding, that is cause we didn't at the time at least have a clue if we had resource
[13:27] <apw> we know now we do not until the heads are filled
[13:27] <ogra_ac> the only real resource that can determine it is the community
[13:27] <highvoltage>  /win 15
[13:27] <mvo> geser: hm, that seems to be working for me (that snippet)
[13:28] <apw> ogra_ac, your team doesn't have any omap3 to test with ?
[13:28] <ogra_ac> right, *i* know that you dont have resources, the people discussing in the thread dont
[13:28] <ogra_ac> we have beagleboards
[13:28] <ScottK> apw and ogra_ac: I know there will be some community testing of omap3.
[13:28] <mvo> geser: with g++4.4, let me try 4.5
[13:28] <ogra_ac> ScottK, yeah, i would expect so
[13:28] <apw> ogra_ac, yep someone needs to respond now the position has shaken out, i'll poke people
[13:28] <geser> mvo: this was from a natty pbuilder
[13:28] <ogra_ac> apw, thanks a lot :)
[13:31] <mvo> geser: ok, let me try that (for the record, g++-4.5 compiled it too)
[13:32] <geser> mvo: I've tried now to build the package in my maverick pbuilder and it worked there, only natty fails
[13:40] <mvo> geser: I can reproduce it here now
[13:42] <hallyn> Does 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:48] <ScottK> hallyn: 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:49] <hallyn> ScottK: ok, thanks.  can i specify the version with build-depends, i suppose?
[13:50] <ScottK> No.
[13:50] <hallyn> drat
[13:50] <ScottK> You'll need to grab the old one from LP and try it locally.
[13:50] <hallyn> well, i know under maverick it compiled fine
[13:50] <hallyn> i'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 round
[13:51] <mvo> geser: 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 fine
[13:52] <doko> mvo: no, does it work with gcc-snapshot?
[13:54] <ScottK> doko: Does gcc-snapshot use linaro or fsf upstream?
[13:54] <doko> ScottK: fsf
[13:55] <ScottK> doko: Speaking of which, any thoughts on Bug #675347?
[13:56] <doko> ScottK: as mentioned yesterday, please ask jbrown on #linaro
[13:56] <ScottK> OK.
[13:56] <geser> mvo, doko: adding --no-as-needed to the -Wl flags makes it link
[13:56] <ogra_ac> we should just rewrite everything in shell
[13:57] <ogra_ac> would fix all compiler issues
[13:58] <doko> geser: which lib has the symbol?
[14:01] <geser> doko: 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.so
[14:07] <doko> geser. mvo: maybe fix the conftest, so that the library is really linked?
[14:08] <mvo> doko: hm? is -lapt-pkg not enough to really link it?
[14:08] <geser> doko: 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:09] <geser> I used "g++ -o conftest -g -O2  -Wl,-Bsymbolic-functions,--no-as-needed -lapt-pkg conftest.cpp" to make it link
[14:09] <doko> mvo: apparently the symbol you are checking for can be used without the lib
[14:09] <doko> it's included from the a header
[14:10] <mvo> doko: its in the header as "extern" - is that not enough?
[14:10] <doko> mvo: apparently not with --as-needed
[14:11] <mvo> doko: hmhm
[14:13] <doko> mvo: hmm, the test works on i386
[14:14] <geser> I'm on amd64 if it matters
[14:18] <doko> geser: can't reproduce it here :-/
[14:18] <geser> doko: on natty? I got it while test-building a package in my natty pbuilder
[14:19] <doko> yes, natty
[14:21] <geser> hmm, mvo perhaps you can help doko how to reproduce it as you managed to reproduce it too
[14:24] <geser> when 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 error
[14:30] <doko> geser: my libapt-pkg-dev is 0.8.8ubuntu3
[14:30] <geser> the same
[14:32] <geser> g++ is 4:4.5.1-1ubuntu3 and g++-4.5 is 4.5.1-10ubuntu1
[14:33]  * geser is away for around 2h
[14:40] <seb128> didrocks, did you open a bug about the gcc-4.5 issue breaking gnome-settings-daemon?
[14:40] <seb128> or just pinged doko?
[14:40] <seb128> I think other sources fail the same way
[14:41] <didrocks> seb128: I just pinged doko and gave him some pastebin as examples
[14:42] <seb128> doko, did you have time to investigate the issue didrocks pinged you about? do you need a bug report?
[14:50] <mvo> james_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_w> mvo, --merge
[14:51] <mvo> *cough*
[14:52] <mvo> thanks james_w
[14:53] <mvo> doko: hm, odd - on my normal natty system it works, in my pbuider it does not, let me try to figure out what is different
[15:00] <apw> pitti, 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 why
[15:02] <mvo> doko: 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:03] <doko> mvo: ahh, so the fix should be easy
[15:04] <mvo> doko: well, its all genearted by configure.ac
[15:04] <seb128> doko, hey
[15:04] <seb128> doko, so I've sources failing with gcc-4.5, I think it's the same issue that didrocks pinged you about yesterday
[15:04] <seb128> doko, should I make those use an another gcc version for now?
[15:06] <doko> seb128: didrocks wanted to file a bug report, I didn't see one yet ...
[15:06] <didrocks> doko: you didn't answered me if you wanted it and asking for others questions… I was taking that as a "no"
[15:07] <doko> hmm ...
[15:07] <kirkland> hallyn: i was going to merge your last proposal and send that for a build
[15:07] <kirkland> hallyn: cool?
[15:08] <seb128> didrocks, can you open a bug now?
[15:08] <didrocks> now that it's a clear "yes", sure I can
[15:08] <mvo> geser: something like http://paste.ubuntu.com/533486/ should work
[15:13] <mpt> Who is able to approve blueprints for Natty? Is it anyone in Ubuntu Drivers?
[15:15] <didrocks> doko: seb128: bug #676519
[15:15] <seb128> didrocks, thanks
[15:15] <doko> didrocks: this smells like mvo's problem above. put the objects before the libs
[15:16] <didrocks> doko: indeed, that worked
[15:16] <mvo> I guess a common way of doing it before was using LDFLAGS to smuggle in libs
[15:16] <mvo> where LIBS should be used
[15:16] <doko> yeah ...
[15:16] <cjwatson> or LDLIBS, yes
[15:16] <mvo> especially on configure tests its a bit anoying, but *shrug*
[15:17] <cjwatson> (LDLIBS for make's implicit rules)
[15:17] <mvo> cjwatson: which is the more "correct" one?
[15:17] <mvo> cjwatson: aha, ok
[15:18] <hallyn> kirkland: cool, thanks
[15:18] <hallyn> kirkland: and if it fails to build, then just resend it.
[15:18] <hallyn> cause the toolchain is eating us for breakfast
[15:34] <seb128> doko, bug #676519
[15:34] <seb128> doko, you don't consider that a regression from gcc?
[15:35] <seb128> we have several sources failing this way, that used to work, is there any reason gcc couldn't handle the other order?
[15:35] <doko> seb128: yes, --as-needed. it's not a regression, it's exposing a sloppyness in the test case
[15:36] <seb128> it was working some days ago with --as-needed
[15:36] <doko> no
[15:36] <seb128> the previous upload from those source in natty worked
[15:36] <doko> --as-needed was introduced on Monday
[15:36] <seb128> and --as--needed was in place since it failed due to it
[15:36] <seb128> so --as-needed is different from the dso changes?
[15:37] <doko> --no-add-needed is in place since the opening of natty, --as-needed since Monday
[15:38] <mvo> doko: mumble?
[15:38] <highvoltage> life/win 13
[15:39] <highvoltage> bah! (sorry, I should really add gnome-do to my default session!)
[15:39] <smb> pitti, Could you accept the kernels for maverick and lucid so they get build
[15:41] <seb128> doko, I don't get why the object have to be before?
[15:41] <seb128> the gcc man says
[15:41] <seb128>        gcc [-c|-S|-E] [-std=standard]
[15:41] <seb128> ...
[15:41] <seb128>            [-o outfile] [@file] infile...
[15:41] <seb128> that ought to work in this order no?
[15:42] <doko> no, the order of objects does matter, same for libs
[15:43] <cjwatson> yeah, this is traditional unix linker stuff
[15:43] <cjwatson> gcc's been a bit permissive in the past so people have got a bit sloppy
[15:44] <cjwatson> but the way you've generally had to do it is that objects that provide symbols used by other objects need to come later
[15:44] <seb128> so I guess in a Makefile.am the .la should come before the _LIBS in a _LDADD
[15:45] <seb128> NOTIFICATION_AREA_LDADD =				\
[15:45] <seb128> 	$(NOTIFICATION_AREA_LIBS)			\
[15:45] <seb128> 	libtray.la
[15:45] <seb128> is failing because the .la is after the _LIBS?
[15:46] <cjwatson> depends, does libtray.la use symbols from $(NOTIFICATION_AREA_LIBS)?
[15:46] <seb128> yes
[15:47] <cjwatson> then yes
[15:48] <seb128> hum ok, I'm not sure how to explain that to upstream in the bug report though
[15:49] <cjwatson> "breaks with ld --as-needed" should be enough?
[15:49] <cjwatson> we're not the only distribution trying this
[15:49] <seb128> well it seems fedora has dso linking on and it doesn't break for them
[15:49] <seb128> well point is that this order works on other distros
[15:50] <seb128> or at least on fedora and opensuse
[15:50] <seb128> so I'm not sure how the way we do it is different or pickier
[15:50]  * ScottK also doesn't recall this being disucssed in the planned toolchain changes.
[15:57] <doko> seb128: no, fedora doesn't have it, but OpenSuse has
[16:01] <seb128> hum, got disconnected
[16:01] <seb128> doko, then I need to check with vuntz why he doesn't get the issue on opensuse with the same tarball
[16:55] <lifeless> kees: is it still fast ? :)
[17:02] <geser> mvo: thanks, works without any further changes
[17:05] <mvo> geser: cool
[17:09] <geser> I 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 again
[17:27] <ogra_ac> cjwatson, erm, bug 673504 is not a duplicate ... (beagle XM isnt omap4 but omap3)
[17:28] <ogra_ac> err
[17:28] <ogra_ac> Bug 673509 i mean
[17:28]  * ogra_ac looks what happened there
[17:33] <jdong> wow, this put-each-tty-in-a-cgroup patch works beautifully
[17:34]  * 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] <sladen> cjwatson: do you bother using the upstream (top level) 'ubiquity' project in LP
[17:35] <ebroder> SpamapS: Elastic Map Reduce?
[17:36] <ebroder> SpamapS: Although apt-file is probably faster :-P
[17:37] <SpamapS> ebroder: 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:59] <kees> lifeless: let me try again...
[18:01] <ebroder> cjwatson: 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:23] <SpamapS> ajmitch: ping? I see you grabbed the php5 merge (https://merges.ubuntu.com/main.html) ...
[18:25] <ajmitch> SpamapS: that's probably an old comment, but I can do it if you'd like :)
[18:25] <SpamapS> ajmitch: no, I am working on it, so I'll clear that out. ;)
[18:25] <ajmitch> ok
[18:28] <ajmitch> SpamapS: it would have been a comment from a previous release, they should get cleared automatically now
[18:28] <SpamapS> ajmitch: hm.. maybe a bug or something
[18:30] <ajmitch> SpamapS: yeah, a bug that was fixed but the previous comments haven't been cleared out for packages that weren't showing
[18:30] <ajmitch> no big issue though
[18:40] <ari-tczew> yes, cjwatson has fixed this bug, but if comment is old, it has to be updated. after update, comment won't be saved anymore
[18:57] <SpamapS> hrm, something broken in natty with the LDAP/SASL libs..
[18:57] <SpamapS> configure: error: LDAP SASL check failed. Please check config.log for more information.
[18:59] <SpamapS> zul: ^^ thats from php5
[18:59] <SpamapS> zul: current and merged versions
[18:59] <zul> SpamapS: umm...interesting
[19:00] <SpamapS> zul: 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:01] <zul> SpamapS: schroot -c <chroot> -u <user>
[19:02] <SpamapS> zul: ok, but then I need to install the build-deps ..
[19:02] <SpamapS> zul: so -u root, then su to my non-root user after that?
[19:03] <ebroder> SpamapS: Do you know about schroot -bc, -rc, and -ec?
[19:03] <zul> you can
[19:03] <SpamapS> ebroder: the man page doesn't seem to mention a -b
[19:03] <ebroder> SpamapS: I do something like session=$(schroot -bc <chroot>); schroot -rc $session -u root apt-get build-dep whatever; schroot -rc $session
[19:03] <ebroder> SpamapS: Then be sure to do schroot -ec $session when you're done
[19:04] <SpamapS> ahh there it is
[19:04] <SpamapS> ebroder: ok thats what I was looking for
[19:04] <ebroder> SpamapS: 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:07] <segler> i 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:08] <ScottK> segler: Open a bug, attach the .diff.gz to the bug and subscribe the ubuntu-sponsors team to the bug.
[19:08] <segler> ok, thank you
[19:10] <segler> hmm, my source package does not have a diff.gz
[19:10] <segler> do you mean the debian.tar.gz?
[19:14] <ScottK> segler: yes
[19:15] <ScottK> diff.gz for format v1 packages and debian.tar.gz for format v3
[19:15] <segler> ok, thank you :)
[19:26] <kees> hallyn, 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:27] <hallyn> kees: not me i'm afraid
[19:27] <ebroder> kees: 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:28] <kees> ebroder: sweet, that would be great. I can test the intel half, but I have no AMD with virt extensions.
[19:33] <RoAkSoAx> achiang: finally fixed the problem for pacemaker :)
[19:34] <achiang> RoAkSoAx: cool! what was the answer?
[19:34] <ebroder> kees: 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:36] <RoAkSoAx> achiang: 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] <achiang> ah ha
[19:37] <RoAkSoAx> achiang: so I just took upstream's change :)
[19:37] <achiang> RoAkSoAx: so actually, my theory was correct (iirc). i think it was the syntax that was busted
[19:37] <ebroder> kees: When I get the machine, I'm looking at lp:~cpu-checker-dev/cpu-checker/trunk?
[19:38] <RoAkSoAx> achiang: yeah, upstream changelog for the fix is: " Correct the linking order so that libpe_status is linked after libpengine."
[19:38] <RoAkSoAx> achiang: so indeed was the linking order
[19:38] <kees> ebroder: http://bazaar.launchpad.net/~cpu-checker-dev/cpu-checker/trunk/annotate/head%3A/kvm-ok
[19:38] <ebroder> kees: Cool. I'll let you know
[19:38] <achiang> RoAkSoAx: 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] <RoAkSoAx> achiang: hahah same here :)
[19:45] <SpamapS> is there something broken in the linker right now in natty?
[19:46] <Sarvatt> SpamapS: working as intended unfortunately
[19:47] <SpamapS> http://paste.ubuntu.com/533574/
[19:47] <Sarvatt> https://lists.ubuntu.com/archives/ubuntu-devel/2010-October/031860.html
[19:48] <SpamapS> failing to find sasl_version in libsasl2 ...
[19:49] <SpamapS> ok, so -lsasl is there...
[19:49] <SpamapS> err
[19:49] <SpamapS> -lsasl2
[19:50] <SpamapS> and sasl_version is indeed a symbol from that library
[19:51] <cjwatson> ogra_ac: I didn't dup that - it was like that when I got there
[19:51] <cjwatson> sladen: just for code hosting, not bugs etc.
[19:51] <cjwatson> ebroder: could you look at doing it as a C module?
[19:52] <cjwatson> ebroder: if it's really infeasibly awkward then we'll use lua, but Robert seemed pretty down on that with his upstream hat on
[19:52] <ebroder> cjwatson: Sure. I don't suspect it would be hard, although I might change the {black,white}list format to be more C-friendly
[19:54] <ebroder> cjwatson: 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-go
[19:55] <kees> lifeless: still fast, no 503s
[19:57] <geser> SpamapS: the problems are the -l... before the conftest.c; since the latest gcc changes (--as-needed) the order matters now
[19:59] <cjwatson> ebroder: yeah, just uncomfortable at doing it over a nack from Robert
[20:00] <ebroder> cjwatson: OOC, is upstream's support for Lua different from their support for the other extras?
[20:02] <cjwatson> ebroder: extras vary wildly
[20:02]  * ebroder nods
[20:03] <cjwatson> ebroder: lua's particularly controversial because of its overlap with grub script - most of the others provide a more obviously new feature
[20:03] <cjwatson> the gpxe extra is fairly scary and poorly tested right now so we don't build that in
[20:04] <cjwatson> the 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] <cjwatson> they're in extras just because they aren't copyright-assigned to the FSF
[20:05] <cjwatson> it's a shame extras can't be built truly separately
[20:05] <ebroder> cjwatson: 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] <SpamapS> hmmm.. 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:06] <cjwatson> ebroder: if you're happy to copyright-assign it, and don't mind arguing out the interface, it should be upstreamable
[20:06] <cjwatson> initially I guess it would be a distro patch though
[20:07] <ebroder> cjwatson: 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, though
[20:09] <SpamapS> aha.. looks like upstream needs to be smacked a bit. ;)
[20:10] <SpamapS> s/smacked/hugged and brought along the path of enlightenment/
[20:10] <ajmitch> SpamapS: it's PHP...
[20:11] <SpamapS> ajmitch: True, they've been smacked so many times, its clear that corporal punishment just doesn't work with them.
[20:11] <cjwatson> ebroder: yeah, if it can't be assigned an extra will probably be ok
[20:11] <geser> SpamapS: -lsasl2 is left of conftest.c
[20:12] <cjwatson> as long as it's GPLv3-compatible
[20:12] <ebroder> cjwatson: Boss just got out of his meeting - copyright assignment won't be an issue
[20:12] <SpamapS> geser: yeah I just figured that out now. :-P
[20:12] <cjwatson> excellent
[20:12] <SpamapS> geser: but thank you for confirming. :)
[20:13] <SpamapS> geser: patching config.m4 to check sasl2 for sasl_version, which is where it has always lived anyway, is the appropriate fix
[20:13] <geser> SpamapS: I know it since this afternoon now too, run into the same problem
[20:13] <SpamapS> Oh boy.. more of these happen later in the build. :-P
[20:14] <ajmitch> SpamapS: OK, I'm glad you're doing the merge now :)
[20:14] <SpamapS> ajmitch: haha yeah no kidding
[20:14] <ScottK> Right.  Because DSO, gcc-4.5, and a new Python weren't enough pain for one release cycle.
[20:14] <SpamapS> looks like OpenSSL is linked improperly as well.
[20:15] <SpamapS> ScottK: at least we're doing it now, and not in O or P!
[20:16] <SpamapS> ScottK: 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] <ajmitch> ScottK: how much of it has been done in fedora already?
[20:17] <ScottK> SpamapS: I don't mind toolchain advancements.  I do mind toolchain advancement suprises and I don't recall this one being discussed.
[20:17] <ScottK> ajmitch: For the -as-needed ordering stuff, none of it.  Allegedly done in opensuse, but accounts vary.
[20:17] <ajmitch> hm, it may have been F15 that I was reading about it
[20:18] <ScottK> They did the DSO linking bit.
[20:18] <ScottK> They've also done Python2.7.
[20:18] <ajmitch> right
[20:19] <cjwatson> I think this was oversight rather than deliberate surprise ...
[21:17] <bdrung> hallyn: 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:29] <hallyn> bdrung: meaning what, exactly?  The client should be able to decode it as alt-gr?
[21:32] <bdrung> hallyn: 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:34] <bdrung> hallyn: let me test what kvm thinks which key it gets
[21:36] <hallyn> well, the old patch implies that the guest gets keydown but not keyup?
[21:37] <bdrung> yes, 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:58] <RoAkSoAx> are new binary packages approved automatically, or do they pass a manual inspection?
[21:58] <cjwatson> the latter
[21:58] <cjwatson> more or less
[21:58] <cjwatson> new binary packages that came from Debian get waved through semi-automatically
[21:59] <RoAkSoAx> cjwatson: what's the case when those are binary packages that didn't come from a debian sync/merge?
[21:59] <cjwatson> then we check them manually
[22:00] <RoAkSoAx> cjwatson: ok then, I guess i'll just have to wait because of that, another package FTBFS :) Thanks for the info
[23:32] <cjwatson> seb128: are these shared-mime-info and telepathy-mission-control syncs in ~lp_archive/syncs/ yours?
[23:33] <seb128> cjwatson, oh yes, I started on that early and got an dsl disconnect which made me stop and I forgot to finish those
[23:33] <seb128> cjwatson, you can flush them if you want
[23:33] <seb128> sorry about that
[23:34] <seb128> cjwatson, if you are doing syncs "-S experimental -f telepathy-glib" and "-S experimental telepathy-gabble" are to do as well
[23:34] <seb128> I will do them tomorrow otherwise, I was about to go to bed now
[23:34] <seb128> 'night
[23:34] <cjwatson> flushing, thanks
[23:34] <seb128> cjwatson, thanks
[23:34] <cjwatson> sure, I can do those.  -b seb128?
[23:35] <seb128> yes
[23:35] <cjwatson> I was just going to do a man-db sync
[23:35] <seb128> cjwatson, thanks
[23:35] <cjwatson> np
[23:56] <bdrung> hallyn: can you test the patch attached to bug #427612 and share your results?