=== thomi is now known as thomi|lunch === thomi|lunch is now known as thomi [03:30] Good morning [03:30] bdmurray: I am now; I got your mail === _ffio_ is now known as ffio === Guest81623 is now known as Zic [06:58] cjwatson: thanks! I'll retry. === smb` is now known as smb [07:17] good morning [07:25] rbasak: OK - better do it quick because otherwise I might manage to land this whole stack in saucy first :) [07:25] cjwatson: done. It's building now :) [07:28] cool === tkamppeter_ is now known as tkamppeter === iahmad is now known as iahmad|afk [09:04] SpamapS, online? === doko_ is now known as doko === iahmad|afk is now known as iahmad [09:10] xnox, ping [09:14] hi, what steps do i need to follow to test lua 5.2 and ruby 1.9 ? i checked package rubyluabridge but it defaults to ruby 1.8 [09:16] tvoss_: heya [09:26] xnox, do you know about that? how to test lua 5.2 bindings for ruby 1.9? [09:26] yolanda: nope =) no idea. [09:27] found that rubyluabridge package but it forces ruby 1.8, so no clue [09:29] ruby is a wore [09:31] Ph0bus: That's hardly appropriate here [09:31] cjwatson, do you know about how to test that bindings? [09:31] i'm a bit lost on it [09:32] yolanda: Sorry, haven't the foggiest. Perhaps contact the Debian maintainers, or the appropriate language development communities [09:34] ScottK seems to be the latest uploader [09:34] i'll try [09:46] infinity: have you upstreamed your golang header patch? Or does someone need to do this? [09:47] Ph0bus> charming chap [09:52] yolanda: Note that rubyluabridge was just auto-synced from Debian, so you might want to update your working tree if you're working on it [09:52] (0.7.0-2) [09:54] Or, well, would just have been auto-synced if bits of LP weren't disabled in preparation for a deployment [09:54] cjwatson, lp still shows 0.7.0-1 version [09:54] See my previous comment :) [09:55] was typing at same moment :) [09:55] But you can grab it from https://launchpad.net/debian/+source/rubyluabridge/0.7.0-2 in the meantime [09:55] ok [09:56] just working on other issue now and i'll grab later, great [10:12] doko, we where going to talk about go policies this week - when suits you? [10:13] ogra_, ping [10:16] tvyup [10:16] eh [10:18] tvoss_, yup ? [10:18] jamespage, today is fine, after lunch? 2pm? [10:19] doko, yeah - thats good with me [10:23] rbasak: I can push it to Debian, but I'd rather someone bypass them and upstream it directly for me, if we have a decent working relationship with them. [10:23] yolanda: it's synced and (mostly) built now [10:24] great [10:31] mardy: hello! [10:31] mardy: I'm looking at lp:webaccounts-browser-extension right now [10:32] mardy: it's not daily-released right now, and I see there are no integration tests there - only unit tests [10:32] mardy: do you think it's possible to do integration testing with those branches? [10:35] infinity: OK, I'll ask. [10:39] infinity, jamespage: bug 1187722 is fixed now then, right, both for dpkg and golang? [10:39] bug 1187722 in golang (Ubuntu) "dpkg-shlibdeps fails on armhf ELF binaries that do not define architecture specific information" [High,Confirmed] https://launchpad.net/bugs/1187722 [10:44] rbasak: Oh, I didn't know there was a bug for it. [10:45] rbasak: Closed. [10:47] infinity, eglibc ping [10:50] sil2100: I doubt it, it's something very difficult to test [10:50] sil2100: unless it's possible to programmatically login into facebook [10:50] doko: See /msg [10:51] thanks [10:54] mardy: ACK [10:55] infinity: no problem. I just wanted to check that there aren't any tasks remaining, apart from upstreaming. [10:56] rbasak: Nah, my simple 3-line patch should DTRT and be upstreamable. [11:00] ack [11:00] I've asked Dave to look into it. === MacSlow is now known as MacSlow|lunch === greyback is now known as greyback|lunch [11:19] cjwatson, i checked rubyluabridge package, but it still forces ruby 1.8 [11:27] yolanda: Sure, I don't actually know about it, I was just letting you know that there was an update since you said you were working on it [11:28] i messaged ScottK to talk about it [11:34] yolanda: Do you have a partially done branch or dsc you can throw somewhere? [11:35] Daviey, for the ruby issue? [11:36] i just grabbed rubyluabridge but it has a patch forcing to ruby 1.8, i was told to test with 1.9 so not sure about how to act === greyback|lunch is now known as greyback [12:03] yolanda: Right, ScottK did an NMU in Debian, perhaps he has more info. Looking at the upstream project, certainly no fix there. [12:04] Daviey, i pushed a MP for rrdtool, that one is working [12:09] yolanda: super === MacSlow|lunch is now known as MacSlow [13:02] any archive admins around who want to NEW something for me? https://launchpad.net/ubuntu/saucy/+queue?queue_state=0&queue_text=whoopsie-preferences [13:18] Laney: sigh. i wonder how these tests ever passed in autopkgtest… [13:21] software-center? they never did [13:27] pitti: really? the entire time that software-center has had autopkgtest setup, it's never actually passed? [13:27] yes, despite several pings they've never been fixed [13:28] FWIW, if nobody has the time or cares, and there is an upstream test suite that at least succeeds locally, it could just be dropped [13:29] i don't know if the tests work locally [13:30] the tests are doing a lot of nasty broken things [13:31] doko: online now. Wassup? [13:35] SpamapS, did you try to cross-build mysql in the past? === jtechidna is now known as JontheEchidna [13:55] pitti: ok, since they've never actually worked, i just uploaded a software-center that just removes debian/tests and the X-Testsuite:, please do what you need to do to the jenkins job/britney as a result of that :) [13:55] dobey: ack [13:56] jibel: ^ on that note, I'll remove the job from the actual jenkins; does britney look at that, or at the public mirror? === jono is now known as Guest30113 [13:57] pitti, none of them the status is kept on lillypilly. it must be removed from there. [13:59] jibel: hm, where do I find that? [14:02] jibel: proposed-migration/autopkgtest/data/adt/saucy-proposed/amd64/saucy-proposed_amd64_software-center ? [14:02] jibel: just wipe that? [14:18] cjwatson: seems I made a mistake with the click hook by using people.canonical.com (external name), what's the host or fqdn that the builders see? lillypilly.canonical.com, just lillypilly or another internal domain? === balloons_ is now known as balloons [14:20] sergiusens: archive-team.internal but that's a view of people.canonical.com/~ubuntu-archive [14:22] dholbach: hi! can you take another peak at bug #1199017 please? i've updated the dsc/debian.tar for it. thanks [14:22] bug 1199017 in Ubuntu "[needs-packaging] ubuntuone-credentials" [Wishlist,New] https://launchpad.net/bugs/1199017 [14:23] stgraber: ah, so I need one more step [14:24] dobey, will do [14:24] ogra_: ideas? ^^ [14:24] sergiusens, oh, i totally forgot [14:25] pitti: so i'm not sure what to do about the u1-client autopkgtest issue. will you add the feature flag to ignore stderr? hacking up the tests to work around autopkgtest behaving differently than everything else seems wrong to me :) [14:25] sergiusens: where are those files on lillypilly? [14:25] stgraber: http://people.canonical.com/~sergiusens/click_packages/ but they can be anywhere [14:26] stgraber: you can copy them ... this is what I do ~sergiusens/click_ready/click_copy.py https://jenkins.qa.ubuntu.com ~/public_html/click_packages [14:26] sergiusens, i tallked to cjwatson already ... but wanted to wait for you :) ... the machine is reachable under a different name ond only ~/ubuntu-rachive can be seen ... i think running your copy script from an ubuntu-arechive cronjob and have it dump into ~/ubuntu-archive/public_html/click-packages would be best [14:26] stgraber, ^^^ [14:26] I just put a symlink, looks like it's working: http://people.canonical.com/~ubuntu-archive/click_packages/ [14:26] stgraber: awesome [14:26] on disk, that's a symlink to /home/sergiusens/public_html/click_packages [14:27] stgraber, well, i'm not sure the access from cadejo works that way [14:27] ogra_: let me check that [14:27] ogra_: it does [14:28] sergiusens, so now we need to change the url to http://archive-team.internal/ in livecd-rootfs [14:28] (with the proper path indeed) [14:28] ogra_: I just tried with wget http://archive-team.internal/click_packages/com.ubuntu.calendar-app_0.4_all.click -O /dev/null from nusakan and that worked fine [14:28] stgraber, you have a login on cadejo ? [14:28] ogra_: do you feel jealous? :-P [14:28] ogra_: no, but nusakan has access to that vhost/proxy server [14:28] nusakan doesnt help :) [14:28] the buildd needs to be able to see it [14:29] i can see it pulls the seeds from http://archive-team.internal/seeds/ [14:29] http://archive-team.internal/ being lilliypilly [14:29] (see live-build/auto/config) [14:30] ogra_: archive-team.internal == 91.189.89.174 which is a separate IP from the main lillypilly IP, so if cadejo can access it, then it has the same view as I'm getting from nusakan which works when access archive-team.internal/click_packages, so I'm 99% sure it'll work fine from cadejo [14:30] ok [14:31] let me change livecd-rootfs and upload [14:31] (the remaining 1% would be IS sending that traffic to squid and having some ACLs restricting to sub-directories of archive-team.internal, but I very much doubt they'd do that) [14:34] sergiusens, stgraber, livecd-rootfs change and uploaded [14:35] lets see how the next build goes [14:35] dobey: we can add the feature flag (bug appreciated, so that I don't forget and we can coordinate who will do it); hacking autopkgtest is always a lot of "fun", might take a bit [14:35] pitti: ok, i'll get a bug filed [14:36] sergiusens: So, I'd prefer for the ubuntu-archive user to be fetching the click packages itself rather than symlinking into your home directory [14:36] sergiusens: Not least because archive-team.internal will soon be a separate *machine*, not just a separate IP address [14:36] sergiusens: Is it possible to run click_copy.py on lillypilly? I couldn't figure out which Jenkins base URL to use [14:37] cjwatson: this is what I do ~sergiusens/click_ready/click_copy.py https://jenkins.qa.ubuntu.com ~/public_html/click_packages [14:38] doko: no, I have noly ever built it for x86 [14:38] only [14:38] doko: well and arm ... it has some signed char issues IIRC [14:39] sergiusens: Huh, could've sworn I'd tried that, thanks [14:39] sergiusens: I'll cron that in a bit then [14:39] yay [14:40] thanks [14:41] sergiusens: do you have it cronned at the moment? what's the frequency? [14:42] cjwatson: I don't, wanted to get an intial build before stressing anything, the click packages are built once a day, so once a day is good enough [14:42] a good time would be before the actual touch build but not really as important [14:45] cjwatson, something like 6 or 7am UTC should be fine [14:48] jibel: did you notice my question about removing the britney software-center check? [14:48] pitti | jibel: proposed-migration/autopkgtest/data/adt/saucy-proposed/amd64/saucy-proposed_amd64_software-center ← just wipe that? [14:49] pitti, yes that's the file, but if the source with a XS-TEstsuite header is still available in the release pocket it will recreate it. [14:50] jibel: ah, chicken-egg problem [14:53] pitti, yes. the copy must be forced, in any case that won't hurt since the tests have been removed. [14:55] Wellark: hi! [14:56] Wellark: could you tell me what's up with lp:~unity-team/unity-action-api/nohud ? Is it supposed to be daily-released as well? Should this land to distro? [15:17] jibel/pitti: hi - can I pester you about bug 1158391? I need to get DEP-8 integration tests working for upstart in the next few weeks so really need the ability for an autopkgtest env to spin up a nested kvm instance say and prod it in various ways. [15:17] bug 1158391 in Auto Package Testing "ability to have a DEP-8 test run a test in a separate full system environment" [High,Confirmed] https://launchpad.net/bugs/1158391 [15:22] Perhaps I should write an adt-virt-libvirt at some point [15:23] Or just a direct adt-virt-kvm [15:25] xnox: I'm having some trouble reproducing your apache 2.4 upgrade problem. I tried installing libapache2-mod-wsgi first, but the upgrade didn't fail. [15:26] rbasak: i'll try to recreate my setup and i'll let you know. [15:26] THanks [15:28] Looks like apt chose in my case to configure libapache2-mod-wsgi before apache2.2-bin but after all unpacks. [15:28] I'm not quite clear on the ordering required to reproduce it. [15:32] jibel: ah, thanks [15:32] Laney: can you do the magic to let software-center in despite failing tests? (-proposed removes the tests deliberately) [15:33] pitti: how are there failing tests then? [15:36] Laney: Apparently something in the stack is not good at handling removed tests and considers them a failure [15:36] Laney: it never succeeded, but jibel says our britney integration requires forcing this once [15:36] That is, adt-britney incorrectly requests a test run when there are no tests in that case [15:36] Yeah, seems like a bug [15:36] as long as jibel knows about it :-) [15:37] Should be sufficient to force-badtest it [15:37] indeed, but I didn't want to without making people at least aware [15:37] well, that saved us from accidentally losing tests yesterday [15:37] and it's the first time we actually remove a test (and I hope that won't happen too often) [15:42] rbasak: are you planning on merging php5 5.5.0+dfsg-15 ? [15:45] mdeslaur: wow. Struggling to keep up! [15:45] * rbasak looks [15:46] mdeslaur: I understand why you asked now. If I do, I won't get around to it until tomorrow afternoon at the earliest I think. Do you need it sooner? [15:46] rbasak: I can do it now if you don't mind [15:47] mdeslaur: sure, go ahead. Or just a cherry-pick if that's appropriate. At the pace they're going I expect to do at least another merge before release. [15:47] rbasak: ok, I'll handle it...just wanted to make sure you didn't start something already. Thanks! [15:48] cjwatson: hey, so I'm looking at those ubiquity and grub2 changes to always install and use the shim on EFI. My current plan is to simply remove the sb check in ubiquity so we always install shim-signed, grub2-signed and linux-signed, then change grub-install to always set the shim as the boot entry if it exists and grub2-signed is installed. Did I miss anything? [15:48] mdeslaur: OK. Thanks for checking! [15:52] Wellark: if you're around, could you backlog to the question I posted earlier? [15:52] Wellark: thanks [15:53] stgraber: You need to change grub-installer as well, before ubiquity [15:53] (i.e. both grub-install and grub-installer) [15:54] ev: Hey, I'm just looking at your system-settings MP... is it supposed to work on desktop? [15:54] your first isValid() call returns false here for me [15:54] Laney: it needs activity-log-manager installed at the same time. I'm working on splitting out the dbus service into the whoopsie-preferences package [15:55] ev: I already had that [15:55] I can see it in d-feet (but get polkit errors when I try to query the methods) [15:55] oh right, sorry [15:56] the other part is you need to abuse /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla [15:56] pitti, i'm looking at ./debian/extra/initramfs.top in lp:ubuntu/systemd [15:56] http://paste.ubuntu.com/5887973/ [15:56] Change crash reporting settings] [15:56] Identity=unix-group:admin [15:56] Action=com.ubuntu.whoopsiepreferences.change [15:56] ResultActive=yes [15:56] Laney: ^ [15:57] the ROOTDELAY lines blame to you. i dont think that you authored them, but i'm wondering if you could provide some insigth there. [15:57] cjwatson: ah right, forgot that one, thanks [15:57] smoser: no idea, I'm afraid; I mostly took what we had in the old udev scripts, and I was afraid to remove it [15:57] smoser: but it is certainly a gross hack [15:58] smoser: as with wait-for-root it should just work [15:58] pitti, i've never seen it before [15:58] it is not in raring [15:59] smoser: ah, then maybe it came in through debian [15:59] they dont have that file in their systmed package [15:59] smoser: right, not in version 44, it's from the 182 packages [15:59] smoser: anyway, is that creating a problem? [15:59] smoser: we can certainly take it out, but it seems like a no-op [16:00] for context, on azure, we had been booting with the 'rootdelay=' which is a similarly crappy hack to deal with the fact that their scsi disks are terribly underperformant. [16:00] and now we're seeing bug 1202700 because of this sleep. [16:00] bug 1202700 in linux (Ubuntu Saucy) "saucy kernel 300 second hang before root mounted rw on azure" [Medium,Confirmed] https://launchpad.net/bugs/1202700 [16:00] its not a no-op for sure. [16:00] if you boot with rootdelay= it most definitely causes a sleep of that long. [16:01] smoser: yes, but I meant if that didn't exist in raring, why would this parameter exist? [16:01] the parameter in raring goes to wait-for-root [16:01] it increases its default timeout [16:02] (and it still doe sgo there in saucy, it just also gets used here :) [16:02] rootdelay for the kernel means wait up to X for the root to appear, but doesn't have to wait that long [16:02] utlemming, it doesn't mean anything to the kernel. [16:02] smoser: aah, ok; so we shared the parameter, but now got a second implementation [16:02] just to 'wait-for-root' [16:02] and initramfs. [16:03] well, it seems it came and went in debian. [16:03] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414842 [16:03] Debian bug 414842 in udev "udev: Add support for the ROOTDELAY parameter" [Serious,Fixed] [16:03] i suspect somehow we merged bad or something... [16:03] no, they just implemented it differently [16:03] hm.. [16:03] the wait-for-root program is an ubuntuism, it's not in debian [16:03] well, wait-for-root is better. :) [16:03] so the sleep shoudl certainly go away from the initramfs script then [16:03] smoser: https://www.kernel.org/doc/Documentation/kernel-parameters.txt [16:04] smoser: wait-for-root is better> for sure :) [16:04] utlemming, it must do nothing if there is an initramfs. [16:04] smoser: the part that I don't understand is why that parameter is needed at all; it still smells like a bad hack [16:04] sleep is never the right answer for those kinds of problems [16:05] pitti, it is. [16:05] well, right. [16:05] pitti: for Azure, it was requested by MS [16:05] on azure its necessary [16:05] because their devices suck [16:05] the disks might just not wake up for 300 seconds [16:05] and you should pretned that is not a bug [16:05] * smoser ends rant [16:05] anyway. [16:06] pitti, so you support me just dropping those lines in our systemd ? [16:06] smoser: ah, so is that mostly to just extend the timeout of wait-for-root? (that defaults to 60 seconds, I think) [16:06] the actual reason, given by MS is that on earlier version of Azure, the network backed devices might have the full the disk presented during the time of boot.....but smoser summed it up nicely [16:06] smoser: yes, sure [16:06] pitti, thanks for your help. [16:06] so for ubuntu, that command line argument should mostly change the 60 seconds wait-for-root timeout, not actually sleep for that time [16:06] pitti, it does [16:06] with that semantics it would make sense, WDYT? [16:06] ah, good [16:07] smoser: thanks! [16:07] or at least it used to :) [16:07] but i'll make sure. [16:10] smoser: committed to my local packaging git [16:10] ah. [16:10] smoser: I plan some other systemd debugging/fixes tomorrow, is that enough? or do you want it uploaded now? [16:10] well then. [16:10] thank you. [16:10] i was going to do it [16:10] but good enough [16:10] in looking, i find that cryptsetup also reads ROOTDELAY [16:11] but it does a 'while sleep .1' for 10 x ROOTDELAY. [16:11] so thats much better than 'sleep ROOTDELAY' [16:11] but it should probably still use wait-for-root [16:21] jbicha: Um, when you synced https://launchpad.net/ubuntu/+source/packagekit-qt, you did realise that that would break future attempts to upload 0.7-series packagekit, right? [16:24] jodh: looks like pre compiled headers work fine with gcc4.8. So must be something with abi-compliance-checker! [16:25] xnox: interesting - I'll take a look tomorrow. [16:27] is there a way to tell bzr to use-existing-dir within the conf file? [16:37] cjwatson: I only synced it after packagekit 0.8 had been in saucy-proposed for ~6 weeks [16:38] anyway, the pk8-compatible aptdaemon should be nearly ready for saucy https://code.launchpad.net/~aptdaemon-developers/aptdaemon/main [16:42] I was surprised that pk-qt didn't get stuck in -proposed like the rest of the pk8 stack, and no I didn't realize that would prevent uploading "newer" pk7 updates [17:05] anyone know why i would get a symbols change error immediately after generating the symbols file, building a source package with the new file, and then trying to build the binaries in pbuilder? it makes no sense to me, and i can't figure out how to make it not happen [17:07] jbicha: ah, right, packagekit got deleted from -proposed ... [17:08] jbicha: indeed, I saw about aptdaemon, I just have packagekit changes to land in advance of that. I'll work around it [17:12] should i just pull the .symbols file for now and not worry about it? [17:13] wg 28 [17:13] doh [17:24] cjwatson, mdeslaur, sbeattie: I just responded to the ubuntu-appstore-developers list asking for confirmation that we agree on the new json structure. can you guys respond (so everyone can be unblocked)? [17:24] it sounds like we are, but wanted to be sure [17:27] jdstrand: responded [17:28] jdstrand: yep [17:29] sbeattie: I'll ditch the unconfined profile too [17:29] jdstrand: hum? unconfined profile? [17:30] sorry,unconfined template [17:30] what do you mean by "ditching it"? [17:31] mdeslaur: well, sbeattie mentioned we could remove it, but now that I think about it, I think we may still want it [17:31] we can't remove it, the upstart job still needs to switch to it [17:31] replied [17:32] There's no rush to ditch unconfined [17:32] mdeslaur: right [17:32] cjwatson: thanks [17:32] anyone? === sabdfl_ is now known as sabdfl [17:34] mdeslaur: ah, right. [17:36] jdstrand: It turns out that 30C heat in a country without pervasive aircon is not the optimal weather for doing complex rearrangements of hook execution code, but I'm trying ;-) [17:36] (Not that I expect complaints about heat to get much sympathy from your neck of the woods) [17:36] hehe :) [17:37] cjwatson: haha :) [17:37] actually, we've had unseasonably cool and rainy weather here this week :) [17:39] (if you can't stand the heat, stay out of Texas?) [17:39] Plus Texas is the land of pervasive air conditioning. [17:40] and fans. don't forget the fans [17:40] stepping back from the BBQ is kind of like air conditioning === dpm_ is now known as dpm [17:41] * jdstrand is getting hungry === bfiller is now known as bfiller_afk [18:02] dobey: well, please provide logs of the local build and pbuilder. cause e.g. symbols of libraries used can link into your symbols, especially if local build is on raring and pbuilder on saucy-proposed. [18:04] xnox: that seems like a complete failure of the system if so. the symbols provided by a library shouldn't change between raring and saucy [18:06] dobey: depends what you code. if you include a boost template, boot transition from 1.49 to 1.53 between raring and saucy suddently the same API compatible template changes functions, boom you can new/changed symbols in a saucy rebuild. [18:06] does that only happen with c++ or something crazy? [18:06] dobey: that's not the only case. [18:06] dobey: e.g. gcc-4.8 change symbol visibility / export rules slightly, enough to break bionic and loading binary drivers on android. [18:06] dobey: and that's pure c [18:07] (with with assembly) [18:07] so yes, "something crazy" :( [18:07] dobey: so nobody can tell what's going on between your local build and pbuilder, without seeing the logs. [18:07] dobey: i'm sure, our toolchain is deterministic producer of symbols in same or compatible environments. [18:07] =))))) [18:08] :( [18:08] dobey: better give the URL to the source package in question and the logs of local build vs saucy build. [18:08] cjwatson: is bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/saucy/grub2/saucy/ the right branch for grub2? the status of the patches in this one appears to be a bit weird (they're applied but .pc is empty, so quilt refuses to push/pop patches) [18:09] stgraber: lp:~ubuntu-core-dev/grub/ubuntu ? [18:10] nah, that one looks old. [18:10] stgraber: does http://people.canonical.com/~cjwatson/dpkg-quilt-setup help at all? [18:11] xnox: ah I think it'd yes, that also explains what I'm seeing in the branch I think [18:11] xnox: well, if gcc changed things, then that must be it [18:11] stgraber: i remember using that for some of patches-applied-pc-dir-vcs-ignored packaging styles [18:11] (well, except that .pc exists in my case but is empty ;)) [18:12] dobey: don't assume, can you not like pastebin the diff of symbols that pbuilder generated for you? [18:12] sbeattie: if we have this in the click manifest: [18:12] "hooks": { [18:12] "myapp": { [18:12] stgraber: =)))))) patches-applied-.pc/*-vcs-ignored packaging styles [18:12] "apparmor": "apparmor/myapp.json", [18:12] xnox: well, i did gensymbols on raring (local), and pbuilder on saucy, so yeah. it explains it. plus pbuilder didn't fail when building on raring. [18:13] xnox: and the symbols are all low level red-black tree things in qt or something :( [18:13] sbeattie: I understand the a symlink will be created that is of the form $name_myapp_$version [18:13] sbeattie: what is creating that symlink? [18:13] that should not be exported anyway, but yay c++ is crazy [18:13] oh, you know, let me reread the spec [18:14] dobey: c++filt makes those symbols not look crazy. but is it still compatible?! =/ [18:14] "On install, the package manager creates the target path as a symlink to a path provided by the Click package" [18:14] sbeattie: nm [18:18] xnox: http://pastebin.ubuntu.com/5888378/ === synaptix is now known as caboose85S [18:22] dobey: looks to me like abi got broken http://paste.ubuntu.com/5888384/ [18:22] dobey: and it's not in the Qt* symbols anything. Are you using C++11? [18:23] xnox: no: -std=c++0x is what is passed to g++ [18:24] slangasek, cjwatson: So, I've got: http://paste.ubuntu.com/5888394/ http://paste.ubuntu.com/5888396/ http://paste.ubuntu.com/5888397/ [18:25] I "think" that's all that needs changing but I can't very easily test it as the real test is spinning a new media with all of those landed [18:25] would be nice if the symbols stuff could avoid things that aren't directly from the library. [18:26] so my plan is to push that to the archive today, spin a new desktop image as soon as I can, test that in an OVMF VM without SB, confirm I boot through shim, and if that's the case, then push the same change to precise tomorrow [18:26] but yes, definitely a change in stl there [18:27] dobey: well, if it's a change in templates, it does get included in your library, it also means at the moment that ABI is broken and you need to recompile all reverse-dependencies as raring packages will fail with this saucy build lib. [18:27] xnox: is there really no way to make this work correctly on both saucy and raring with the same symbols file? [18:28] dobey: the problem here is not about "getting symbols to work", but that abi is broken and incompatible library is getting built. [18:28] the solution here is to either: bump the soname or fix the abi to stay the same. [18:28] there is no change in abi in the code. this is a problem of g++ breaking things [18:29] all i want to do is have a package that can be built on both saucy and on raring, without changes [18:29] why is that so hard to do? [18:29] well a crashing application doesn't care where the problem is, apart from that libfoo.so.2.0.0 is missing symbols. [18:30] dobey: it is most likely in your code. By the say specifying -std=c++0x is unstable abi as that's what c++11 was known as before releasing. [18:31] "they say" ? who is they? and where do they say that? === caboose85S is now known as synaptix [18:31] (and it's not my code, i didn't write libsdtd++) [18:31] dobey: Gnu GCC upstream -- enable experimental features to support c++11 standard. [18:32] dobey: the package specified to build with that standard enabled one way or the other, thus it's in the package's code. as c++0x is not the default. [18:33] (packaging or upstream) [18:34] SET (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x -O2 -g -Wall -Werror -fPIC") in https://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-credentials/trunk/view/head:/CMakeLists.txt [18:34] dobey: try compile on raring without specifying "-std=c++0x" and compile on saucy, and compare the symbols between the two. [18:35] "Important: GCC's support for C++11 is still experimental. Some features were implemented based on early proposals, and no attempt will be made to maintain backward compatibility when they are updated to match the final C++11 standard." [18:35] http://gcc.gnu.org/projects/cxx0x.html [18:35] dobey, why do you include symbols of libstdc++ at all in the symbols files? [18:35] doko: i didn't make a choice to do so [18:35] dobey, but you do have the choice to fix it [18:36] i'm trying to understand why those symbols are there, and how to fix it [18:36] but telling me my library broke ABI just because it was built on a different version of ubuntu doesn't help me [18:36] doko: how? mark them as (optional)? but isn't the abi broken? [18:37] xnox, how would it? it's not part of the API of this library [18:38] error: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [-Werror] [18:38] bah [18:38] (yeah, c++0x is now aliased to c++11, due to standard rename after final publication) [18:44] dobey: (c++|regex|optional)"std::.*@Base 13.07" in the symbols file, should make any removals/changes ignored under std::* namespace. [18:50] xnox: where is that documented? http://wiki.debian.org/UsingSymbolsFiles is not especially helpful here :-/ [18:51] dobey: man dpkg-gensymbols and https://wiki.ubuntu.com/DailyRelease/FAQ#I.27m_exposing_a_new_C.2BAC8-C.2B-.2B-_symbols_in_my_library.2C_it_seems_that_some_packaging_changes_are_needed.2BICY- [18:53] dobey: the later shows how to use "c++" filter/tag, but not the others "optional, arch, ignore-blakclist, symver, regex" [18:54] xnox: what should be in the .symbols file though? the mangled symbols, or the filtered ones? [18:55] it's not exactly clear what the preference is for that [18:55] dobey: so by default one uses symbols as they are _Zloadsofgibberish@Base 1.0, but that's not very nice for C++ since some of mangled names are architecture specific due to different sizes of things. [18:57] xnox: so it would also likely fail building on i386 or arm, even if it didn't fail on amd64, with the mangled symbols? [18:57] dobey: thus ideally for most symbols one would use full symbols (those that stay the same across all arches), and for arch specific ones use (c++)"myclass::foo()" name, to avoid commiting symbols.i386 symbols.armhf etc... [18:57] dobey: correct. [18:58] dobey: because c++ is crazy, i preffer to use (c++) for all c++ symbols, to have demangled names across the board. That does hide some changes, where mangled name changes to indicate some abi change, yet demangled name is staying the same. [18:58] but that's the price one pays for it. [18:58] it would be nice if gensymbols just did the right thing… [18:59] dobey: to catch remaining changes, I'm working on making dh-acc which takes complete dump of symbols & headers for each arch and generates and checks both ABI and API compatibility. [18:59] by using abi-compliance-checker [18:59] but that's still work in progress. [19:00] dobey: i think, it would be all ok in your case and "done the right thing..." if c++0x/c++11 was not used =/ [19:01] xnox: well, no. it wouldn't have the (c++)Foo::bar()@Base for all the symbols, they'd still be mangled [19:02] and it would still probably include things that aren't really part of the library itself, i presume [19:03] dobey: yeah, true, since the std::* is for some reason exported in your example. [19:03] let me find another example i did. [19:04] dobey: https://code.launchpad.net/~didrocks/qtubuntu-sensors/symbols/+merge/170603 [19:04]