[00:21] stgraber: ping === _salem is now known as salem_ === salem_ is now known as _salem [05:03] Good morning [06:02] good morning [06:19] stokachu: pong === security is now known as megha === tvoss is now known as tvoss|exercise === jono is now known as Guest50668 [07:35] roaksoax, Daviey: So MAAS was uploaded after final freeze. How critical is it that you have it on media for 13.04? === smb` is now known as smb [08:04] pitti: Methinks it's probably final langpack time? [08:04] pitti: (Unless that happened when I wasn't looking, it's been a weird week for me) [08:05] stgraber, infinity: I'm about to upload a new network-manager with more tests, and resurrecting the dnsmasq autopkgtest; no changes to the actual code, is that okay? [08:05] infinity: ah, good point; requesting full export now [08:05] pitti: More tests are fine, if they pass. :P [08:05] infinity: yes, I'm pre-testing in a jenkins-like VM [08:05] and they now cover WPA and WPA2 as well [08:06] infinity: actually, we got a full export yesterday, so unless we are heading for an even fresher one I'll take that one [08:06] pitti: Also, I've lost track through all the apport/whoopsie iterations what the new and improved "we're about to release" workflow is for stuff. Do we still do some bit twiddle on apport, or is that a thing of the past? [08:06] infinity: we still have to twiddle, but that already happened for raring [08:06] pitti: Yesterday should probably be fine. [08:07] pitti: Okay, cool beans. [08:08] pitti: Did your langpack chroot ever get upgraded, or are you still fudging it on a porter? [08:08] infinity: it was, all working fine on macquarie now [08:09] the cron'ed ones also come from there [08:09] \o/ [08:10] Hrm, I wonder if I should try to fast-track Marc's apt-ftparchive change in precise to get it on pepo before we generate raring's final Sources.gz [08:10] infinity: the only thing left to do there is to figure out how I can copy/rsync the precise ones from the porter box to macquarie [08:10] I haven't yet found a suitable route through ssh/firewalls/etc (except through my box, which would take ages) [08:10] pitti: netcat ftw? [08:11] pitti: Or just ask a GSA to do it for you. [08:11] infinity: yeah, probably an RT [08:11] infinity: I tried that back then, can't directly ping/cat from macquarie to osageorange [08:12] (or the other way round) [08:12] * pitti turns the crank for building packs [08:13] as we currently have four amd64 and four i386 buildds, I guess one should be permanently reassigned back to i386? [08:13] allspice? === Amaranthus is now known as Amaranth [08:15] pitti: Oh, we should toss more than one back when we accept this mess anyway. [08:15] pitti: Like, all but one. :P [08:15] right, but only temporarily [08:15] Yeah. [08:15] but I thought we permanently have 5 i386 and 3 amd64 [08:15] Usually, yeah. I rebalanced cause we had a bunch of heavy arch:any jobs on the go. [08:16] Making that a shared pool is on my TODO for the next cycle. [08:18] pitti: Anyhow, crank away. You have 7 i386 builders now. [08:18] pitti: Once you verify those source packages are building right and looking sane or whatever, feel free to self-accept the lot. [08:18] infinity: it'll take some two or three hours to build the (source) packages on macquarie and then I want to test them first [08:19] infinity: ack, will do [08:19] infinity: pepo's on lucid, not precise, FWIW [08:19] cjwatson: Oh, right. Derp. [08:19] cjwatson: I can backport his patch for IS. [08:19] I thought that's what barry had done [08:19] Oh, did someone already get there? :P [08:19] Did that not happen? He was certainly talking about it in foundations meetings ... [08:20] I've been missing those meetings of late. [08:20] Yeah, it's on pepo [08:20] Yeahp, so it is. [08:20] Shiny. [08:20] http://paste.ubuntu.com/5720945/ - head of /usr/share/doc/apt-utils/changelog.gz [08:20] He says to the man staring at that in a terminal. [08:21] Heh [08:21] Was there a plan to also push that to lucid-updates, so it doesn't get lost after a security update? [08:22] Not sure. barry? [08:22] I mean, ideally, pepo will be precise some day. But, I don't know when that day it. [08:22] s/it/is/ [08:23] * cjwatson fixes up the bug metadata [08:23] * infinity gives the i386 chroot a quick refresh before pitti goes all langpacky. [08:24] infinity: ah, thanks [08:24] Actually, I guess I'll do them all. It's not like I can sleep anyway. [08:26] infinity: are you trying to shift to the Australian timezone right before flying to Europe? you really like jetlag that much? :) [08:26] * infinity wonders why his Panda thinks it's 2012... [08:26] stgraber: I've only slept about 8 hours since Sunday. It's not by choice, I assure you. [08:27] urgh [08:27] infinity: ouch [08:36] xnox, hey [08:36] seb128: heya. [08:36] xnox, https://bugs.launchpad.net/ubuntu-geonames/+bug/1150109 ... is "fix commited", what is needed for it to be "fix released"? #is to deploy the update? [08:36] Launchpad bug 1150109 in Ubuntu Geonames "Ubuntu's geonames only knows about Hong Kong in Guyana, not in China" [Undecided,Fix committed] [08:37] seb128: pending RT ticket I believe. [08:37] xnox, ok, thanks [08:37] xnox, do you have the rt number by any chance? ;-) [08:38] xnox, 60594 I guess [08:38] seb128: correct. =) you are quick with RT [08:39] xnox, :p [08:39] seb128: /me was waiting on thunderbird to launch and find the emails. [08:39] I went on the site and typed "geoname" in the query field [08:39] that listed only 2 tickets [08:39] so easy enough ;-) [08:39] 2...? interesting..... [08:40] xnox, the other one is "Make geonames a fully webops managed service" [08:40] seb128: interesting =) maybe I should look into that. [08:43] infinity: Think I should flip base-files now, for the sake of minimal obstacles to release candidate being true candidate? [08:44] cjwatson: Go nuts. [08:45] cjwatson: We really need to rewrite these checklists as we go. They're a bit stale. [08:45] Yeah [08:45] Fighting the last battle [08:45] cjwatson: Twiddling CONF.sh early isn't an awful plan either, IMO. [08:45] Indeed [08:49] Hm, I've not done os-release before. Any objections to me setting PRETTY_NAME to "Ubuntu 13.04", rather than something in the style of "Ubuntu quantal (12.10)" as was used for 12.10? [08:50] cjwatson: How's it look in Debian? I'm not too picky, since we've not really done much with os-release... [08:50] PRETTY_NAME="Debian GNU/Linux 7.0 (wheezy)" [08:51] So, seems to match vaguely the format of issue.net [08:51] cjwatson: I think it makes sense not to use the codename for the released version. [08:51] OK, I'll go for "Ubuntu 13.04"; people can reupload if they object [08:51] the upstream definition is "A pretty operating system name in a format suitable for presentation to the user. May or may not contain a release code name or OS version of some kind, as suitable." [08:51] "Ubuntu 13.04" seems fine to me [08:51] cjwatson: That sounds good to me. [08:54] Oh, wait, that means you're stealing base-files TILM from me. Grr. :) [08:54] I geuss I'll resync in a week. :P [08:55] Heh [08:55] Feel free [08:55] mpt: current theory: code is sound, we just need to run build_errors_by_release twice. [08:55] ev, you've unit-tested? [08:55] mpt: I have for the case of one system that reports an error a week ago, then a day later, then a day later [08:55] mpt: feel free to suggest more test cases [08:56] but I realised that the work of build_errors_by_release would be inaccurate after the first run. FirstError will not be correct until we've seen all the data, and so ErrorsByRelease will not be correct until a second run. [08:57] We're not processing the error reports in time order. We can't. === zyga_ is now known as zyga [08:58] So for one system, if we see a report from a day ago and write it into FirstError and ErrorsByRelease, then we see a report from a week ago and write it into FirstError and ErrorsByRelease, the data in FirstError will be correct, but that first error report value in ErrorsByRelease will be inaccurate, because it was based on a report from a week ago being the first error report seen for the given release. [08:59] base-files uploaded, CONF.sh twiddled [08:59] I have no idea why this didn't occur to me straight away [09:01] mpt: I'll be posting a merge proposal for you and bdmurray to review today. I'll try to make the unit test as readable as possible. [09:01] cjwatson: Cheers. === ckpringle_ is now known as ckpringle [09:20] pitti: chroots are all updates, BTW. Should be good to go when you're ready. [09:20] s/updates/updated/ [09:20] infinity: thanks [09:21] sources finished building, I'll give them a smoke test and binary debdiff now [09:21] pitti: If you have buildd admin, feel free to give amd64 a few machines back when you're done. [09:21] infinity: I have, will do [09:22] * infinity goes to see if he can get a couple hours of sleep... [09:23] Maybe I'll get lucky tonight. [09:25] Good luck [09:26] infinity: sleep well! [09:48] new langpacks look good, and have a lot of previously missing domains [09:48] * pitti uploads; buildds, brace for impact [09:49] pitti, do you want/need testers? [09:50] seb128: if you wish; hang on, I'll build French ones [09:50] I checked English and German [09:50] there's no particular reason to believe anything is broken, but it can't hurt of course [09:54] seb128: les paquets de language sont ici: http://people.canonical.com/~pitti/tmp/langpack/ [09:54] "de lange" [09:54] "de langue" [09:55] didrocks, cjwatson, stgraber: perhaps for the final freeze we should disable the daily autolanding? [09:56] pitti: it's in manual mode [09:56] pitti, what daily autolanding? [09:56] what didrocks said [09:56] didrocks: ah, because I just see builds [09:56] pitti: yeah, it's building everyday [09:56] trying tests [09:56] but doesn't publish [09:56] oh, that's just for the PPA, ignore me [09:56] yep :) [09:58] didrocks: Disabling even those PPA builds next week might be nice, in case they happen to clog the buildds at Just The Wrong Time and we need to get someone to kill them. [09:58] infinity: we can do that temporarly, however, we are preparing SRU0 [09:59] infinity: so yeah, if you see anything critical, we can kill them. however, right now, what's building is more the touch stacks for S that we bootstrap than stuff in daily release [09:59] infinity: meaning, like, this morning, only 2 source packages built for raring (in indicators stack) [09:59] nothing else on the daily release "r" [10:00] didrocks: Well, for release minus 48h, it might be nice to not have a panic conflict, but I also know which shoulders to tap if I need a buildd Right Now too. [10:00] infinity: agreed, can be disabled by then, we need to have mterry, cyphermox, robru and kenvandine do the "disable bits" for it (it's not a global switch) [10:01] didrocks: Ahh, well. I'll talk to you next week about it when we're in the same timezone. [10:01] infinity: sounds good :) [10:01] pitti, language-pack works fine for me, gnome-calculator is in french, all good ;-) [10:01] so much for sleeping :( [10:02] pitti: I'm asleep right now, can't you tell? [10:02] seb128: ah, most important app ever! [10:02] seb128: merci [10:02] pitti, lol [10:02] pitti, that's the one that I know about which was missing its template ;-) [10:02] pitti, de rien [10:02] infinity: your IRC proxy clearly passes the Turing test! [10:05] pitti: Can you elaborate on that? === tvoss|exercise is now known as tvoss [10:06] Eliza, how are you today? [10:06] :) [10:07] And here I was, afraid you wouldn't get the reference. [10:07] the most important emacs feature missing in vim! [10:08] in a very poor school district in south africa, I migrated a few schools form Fedora to Ubuntu a few years ago [10:08] and received a bunch of faxes begging to bring back emacs because the kids wanted it back badly [10:09] I was a bit confused as to why the kids wanted emacs so badly. turned out it was for the psychologist :) [10:09] Heh. [10:11] Damn you, Launchpad, for not instantly knowing about new Debian uploads. [10:11] http://packages.qa.debian.org/l/lolcat/news/20130419T100008Z.html [10:12] ^-- Inclusion thereof is clearly RC for raring. [10:12] infinity: You have to wait for gina [10:12] StevenK: DON'T WANNA. [10:13] infinity: veto, unless is also ships a loldog symlink. [10:13] * StevenK overrules xnox, since he is an archive admin [10:13] * xnox :`( [10:14] * infinity removes emacs from the archive to spite xnox. [10:14] /msg doko please blacklist lolcat [10:14] infinity: please do, everyone should be using emacs24 by now ;-) [10:14] xnox: I meant all emacsen. :P [10:14] /o\ [10:15] infinity: Some way to track Debian uploads without having to have a mirror on iron (and probably somewhere else in the DC) and gina would be awesome [10:15] Oh, no, it's the debbugs mirror that is bounced twice, iron is not [10:16] StevenK: You'd think we could get near instant turnaround by tracking a changes list and pulling from incoming. [10:16] Hmm [10:16] Though, incoming suffers the problem that there's no signed index, so we're blindly trusting the signatures on the .dsc files. [10:17] Which is likely bad. :P [10:17] Which is pretty much why we wait for a mirror, yeah [10:17] And at this point, we stuck until katie runs and ftp.uk is pulsed [10:17] Of course, incoming DOES have a signed index at /buildd/ [10:17] Shame it's no accessible to the public. [10:18] infinity: Not even a DD? [10:18] Weeeell. [10:18] not _all_ DD [10:18] All buildd admins have access to the buildd bits. [10:18] Right [10:19] legal issues prevents access to incomming?! [10:19] Maybe we could get someone to agree that allowing us to pull from there would be cool. [10:19] Back in my day, you couldn't build from incoming [10:19] xnox: Yup [10:19] xnox: It's a fun legal issue [10:19] Hrm? There are no legal issues with incoming. [10:20] incoming.debian.org is poorly named, it should be accepted.debian.org. :P [10:20] infinity: if it's new and ftp-master hasn't reviewed it yet..... oh incoming is not NEW?! [10:20] The only technical issue with us pulling from incoming is that it has no trust path. [10:20] incoming is not NEW, no [10:21] xnox: incoming.debian.org is queue/accepted. Not to be confused with queue/incoming, which is the precursor to new/by-hand/etc. [10:21] NEW is locked down, due to some US acroymn and having to announce packages to the US government because they may contain crypto, but my knowledge might be years out of date [10:21] Serious terminology overload. [10:22] I thought BYHAND was mostly dead? [10:22] StevenK: right, which debian was requested to stop mailing, but simply keep a record & produce it upon request. [10:22] aren't docs and d-i bits still BYHAND? [10:22] xnox: I was around when BenC produced the first list, which was 8,000 pages [10:22] wow =) [10:23] And one wonders why DPLs burn out and disappear. [10:23] * xnox is very young ;-) [10:23] I've been a DD for 12 years [10:23] And you've still not fully repented for linda. [10:24] Linda had her uses. And a fan club. [10:24] Charles Manson has a fan club. [10:24] Just sayin'. [10:25] infinity: Here, I have something for you. It's called 'ether' [10:25] Yes, please. [10:25] * xnox ponders how to check when one became a DD [10:25] * infinity takes the hint and goes to stare at the ceiling some more. [10:25] xnox: nm.debian.org [10:26] But only those who went through the new NM process [10:26] https://nm.debian.org/public/process/13678 [10:26] meh just a year. [10:26] * xnox just under 2 years from start to finish. [10:26] I think that might be a relative definition of "new" [10:27] https://nm.debian.org/public/process/13201 is me [10:27] Sweet. Sledge has been a DD since the UNIX epoch. [10:27] Haha [10:27] https://nm.debian.org/public/people/dd_u <-- Might have accuracy issues for people who predate the NM database... [10:27] Maybe just a bit [10:27] StevenK: hmm... 5 days that's swift. [10:27] xnox: Yup [10:28] xnox: I didn't hear about the "NM problems" until after I became a DD and I was "What problems?" [10:29] StevenK: I also had something like 7m+ hunting down for someone to sign my key. [10:29] StevenK: My AM was a slacker compared to yours. === doko_ is now known as doko [10:29] I've been accused by others of having my dates changed by the klecker fire, and by one person that "I must have gotten access to the NM system and changed my own dates" [10:29] infinity: Who was your AM? [10:30] opal [10:30] n/win 12 [10:30] infinity: tbm talked to joeyh about me, joeyh said "Yeah, Steve knows what he's doing", and tbm went "Right, there's T&S done." === highvolt1ge is now known as highvoltage [10:31] ev, the simplest test case would be one machine that reported one error today producing a weighted error rate of 1/90 [10:31] xnox: Ah, I had no issues with that, Sydney has a large number of DDs [10:32] I didn't have any DDs nearby, but I had some kernel devs that were considered strongly connected enough. [10:32] I think I had four or five DD signatures by the time I applied [10:32] mpt: if a machine reported one error today and it was their only error for the release, wouldn't that be 0, not 1/90? [10:32] it's been 0 days since their first error. [10:32] bod, wildfire, gus spring to mind [10:33] pasc, csmall? [10:33] Indeed [10:33] Man, I haven't seen pasc in ages. [10:33] I pre-date pasc being a DD [10:33] Right. Sleep. No reminiscing. [10:33] ev, yep, you're right :-) [10:33] (off-by-one error!) [10:34] I feel like balloons should be falling from the ceiling right now and someone should be approaching my desk with an award [10:34] maybe a cake === ckpringle_ is now known as ckpringle [11:18] * katie runs for StevenK [11:20] bdmurray: happy to report that the only OOPS reports in https://errors.ubuntu.com/oops-local/2013-04-18/ yesterday were caused by me [11:20] Haha [11:21] katie: The *other* katie [11:21] (I have a branch to fix the bug, I'm just a bit stuck on the YUI DataSource.Get code for catching a 404 raised by the API when the user cannot be found) [11:24] tjaalton: bug 1169071 - are they superseded by some other packages? just trying to work out what to write in the removal comment [11:24] bug 1169071 in nvidia-settings-experimental-304 (Ubuntu) "please remove from the archive" [Wishlist,Confirmed] https://launchpad.net/bugs/1169071 [11:27] cjwatson: yes, we have nvidia-304/310 already [11:28] tseliot knows the right answer I think :) [11:28] why we had both === security is now known as megha [11:44] cjwatson: wrt bug #1083091, I can't do it right now in Debian because of its rdep gtg. It's on my radar, and it'll be gone as soon as Wheezy is released :) [11:44] bug 1083091 in liblarch-gtk (Ubuntu) "Remove liblarch-gtk from the archive" [Wishlist,Fix released] https://launchpad.net/bugs/1083091 [11:53] What is the lowest level packaging command that is called by all the other packaging tools like pbuilder, sbuild..? [11:55] dpkg-buildpackage -b [11:55] which essentially calls debian/rules build; fakeroot debian/rules binary [12:01] ok thanks [12:02] I am looking for to integrate scan-build int the packaging system, any ideas how to do that? [12:02] for a way [12:03] scan-build? [12:04] infinity: FTR, roseapple and allspice sent back to amd64 duty [12:04] yes a static analyzer for C/C++ programs [12:23] jibel: how would you like installer bugs tagged that affect ubuntu-gnome images? "ubuntu-gnome" tag? Are you ubuntu-gnome team monitor those? [12:24] (e.g. in ubiquity package we use kubuntu, xubuntu, lubuntu tags when it only affects those images) [12:27] cjwatson: Hmm ISTR that ffmpeg was in a germinate blacklist, but I can't find it anymore; did the situation change or is this something that we were checking manually? [12:27] I see it in supported-desktop-extra now [12:28] cjwatson: ah! found libavcodec in ubuntu.raring/usb-ship-live, nm [12:28] seb128: ^ [12:28] xnox, your question is for jbicha? [12:30] jibel: correct. [12:30] jibel: he is not here =) hmm... will catch him some other time. [12:35] Sweetsha1k: There's a bug asking for lo-menubar to be removed from raring. Is that correct? [12:40] ScottK, yes, that got replaced by an upstream implementation in libreoffice itself, but that was for quantal, I'm surprised we still have the old source in the archive [12:40] hum [12:40] so indicator-weather is just broken [12:40] Thanks. [12:40] is anyone working on it/upstream for it? [12:41] or should we just drop it from raring? [12:49] cjwatson: nvidia-310-updates has transitional packages for experimental-310 and 304->updates for experimental-304 === _salem is now known as salem_ [13:00] Could someone please answer my questions in bug 1166230 about why there are ever updates to "transitional dummy packages"? Thanks kindly. [13:00] bug 1166230 in update-manager (Ubuntu) "Updater lists many transitional dummy packages" [Medium,Confirmed] https://launchpad.net/bugs/1166230 [13:03] mpt, they are updated because they are typically built from the same source as the real package [13:03] mpt, like gcalctool -> gnome-calculator [13:03] mpt, so they have the source version [13:08] hey seb128, do you think we can backport https://bug691040.bugzilla-attachments.gnome.org/attachment.cgi?id=238204 for raring gtk2? [13:08] (bug 1125260) [13:08] bug 1125260 in gtk+2.0 (Ubuntu) "gtk_file_chooser_get_current_folder() function is broken in 2.24.10 < GTK+ < 2.24.15" [Undecided,Confirmed] https://launchpad.net/bugs/1125260 [13:08] mitya57, (sorry, otp, seems reasonable but maybe check with Laney/the release team) [13:10] it'll be nice to have it at least as a sru === mitya57 is now known as mitya57_ === mitya57__ is now known as mitya57 [13:12] mpt: at your 2nd questions: it's not always possible to remove those transitional packages yet as the transition isn't complete (e.g. ubuntu-minimal -> module-init-tools which is a transitional package to kmod) [13:14] jibel, pitti: everything green now with the python autopkg tests? [13:15] no, still not :( [13:15] https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-python3.3/10/ARCH=i386,label=adt/ [13:16] https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-python2.7/6/ARCH=i386,label=adt/ [13:16] python2.7: can't open file '/usr/lib//test/regrtest.py': [Errno 2] No such file or directory [13:16] doko, it wasn't last time I checked, dbm test failed [13:16] mpt: furthermore, we support LTS->LTS upgrades thus when we renamed gcalctool -> gnome-calculator, we kept a dummy empty package gcalctool which simply depends and installs gnome-calculator, such that a Precise user upgrades to 14.04 his "gcalctool" upgraded package installs "gnome-calculator". Then in 14.10 we can remove gcalctool transitional package. [13:16] thus most of transitional packages stick around for 2 years or less. [13:16] doko, for 3.3 [13:16] jibel, doko: right, for 3.3 there are three failures in dbm [13:17] ScottK: we can do that yeah. its a transitional by now. [13:17] ScottK: /me in call === wedgwood_away is now known as wedgwood [13:20] rsalveti: I'm just looking at the avogadro FTBFS. It's another example of the GLdouble declaration conflict. https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=gldouble+previous+declaration has nine others. Would it be an idea to collapse these into a single bug with multiple tasks? Is there a simple fix that will fix them all, or does each package need individual treatment? [13:21] jibel, pitti: crap about 2.7/testsuite. can't see the test_io failure here with 2.7/testsuite-dbg [13:25] jibel, doko: hmm, the test_dbm failure isn't reproducible here either [13:43] rbasak: Each package needs individual treatment, so it should remain separate bugs rather than being collapsed into a single bug with multiple tasks. See https://wiki.ubuntu.com/ARM/FTBFS#OpenGL_and_Qt_combination [13:43] DktrKranz: Oh, I hadn't noticed that the liblarch that builds python-liblarch-gtk is still only in experimental. [13:47] pitti: is it possible that jockey is trying to set the alternative in enable() before XorgDriverHandler.enable() finishes. This would explain our problem [13:47] cjwatson, infinity yes, it's probably a good idea to backport the patch to lucid. i can do that [13:47] ? [13:48] pitti: also maybe in a separate thread? [13:49] tseliot: jockey doesn't use threads [13:50] tseliot: so unless the nvidia.py handler calls them in the wrong order, no [13:50] pitti: could it be that apt/dpkg does though? [13:51] pitti: if so, as a workaround, I can make sure that the alternatives are set in enabled() instead of enable() [13:53] tseliot: no, enabled() must not change anything [13:54] pitti: hmm... I guess I'm out of ideas on bug 804662 (on the nvidia-common side) [13:54] bug 804662 in nvidia-common (Ubuntu Precise) "jockey-gtk crashed with TypeError in _execute_child(): execv() arg 2 must contain only strings" [High,Triaged] https://launchpad.net/bugs/804662 [13:54] need to run out for a bit, back in 45 ins [13:55] slangasek: looks like I've come up with a fix for the plymouth race bug http://pastebin.com/2bZu24yG (+ 'and plymouth-ready' to *dm.conf) [13:56] on another note, can someone explain why 'pkg-config --libs nss' doesn't show -lpthread, while it's linked against it? [13:57] tjaalton, are you sure that it should, as long as the host software doesn't need -lpthread ? [13:57] -ldl is also missing, these both caused build issues with sssd [13:57] tjaalton: it's only linked against it indirectly [13:57] diwic: I don't know [13:57] cjwatson: ahh, ok [13:57] use 'objdump foo.so | grep NEEDED' rather than ldd [13:57] sorry, objdump -p [13:58] gotcha, thanks [13:58] so sssd must either be linked against something else that fails to specify that you need -lpthread; or it's using pthread directly and erroneously not specifying it [13:59] nah the build-issues have been fixed, but upstream (or fedora) is complaining why these fixes are proposed there :) [13:59] libnssutil3 and libnspr4 are both directly linked against -lpthread [13:59] or something, pinging me about it anyway [13:59] hm, and pkg-config --libs nss says -lnssutil3 [14:00] well; -lpthread should not be necessary in sssd unless it uses pthread functions directly, should it? [14:00] there are some components that do use it [14:00] which it does [14:00] so it's sssd's fault then. use directly, link directly. [14:00] and don't use directly, don't link directly. should be very simple :) [14:00] lool, we are discussing the gettext issue on #ubuntu-hardened [14:01] lool: ubuntu.raring/ship-live is generally the governing one, but yes [14:03] cjwatson: ok, but shouldn't nss.pc have -lpthread then if libnssutil3 links to it? [14:04] tjaalton: only if the mere fact of using the nssutil API causes the program using it to have *direct* references to symbols in libpthread [14:04] tjaalton: for example if an nssutil header file had macros that expanded to pthread_* [14:04] cjwatson: alright.. think I got it this time [14:05] programs shouldn't overlink by re-specifying all the indirect linkage of the libraries they use [14:05] at least not on Linux [14:05] what changed it for raring? [14:05] it actually causes some subtle problems if they do [14:05] not aware of any toolchain-level changes here for raring [14:06] maybe something changed in nss, dunno [14:06] mitya57: is the patch reviewed/committed upstream? [14:06] maybe it's nss/nspr then [14:06] right [14:06] ok, case closed anyway [14:07] Laney: looks like a different set of patches was committed, I didn't yet figure out which of them actually fixes the bug [14:07] mitya57: sounds like SRU would be better then [14:07] there are *lots* of gtkfilechooserbutton fixes @ https://git.gnome.org/browse/gtk+/log/?h=gtk-2-24 [14:08] even since .17? [14:08] yes [14:08] * mitya57 wonders whether it'll be better to backport the whole set of fixes [14:08] so there are [14:09] maybe there will be another release [14:10] Laney: is "another release" OK for SRU? [14:10] GNOME micro releases are [14:11] Laney: OK, so let's wait for the new release, I'll prepare a SRU then [14:12] might be good to find out if/when that is planned for [14:14] I don't think there is any schedule [14:14] xnox: do you know why your reply is shown at http://www.riverbankcomputing.com/pipermail/pyqt/2013-April/thread.html, but my original mail isn't? [14:15] mitya57: are you subscribed to the mailing list? as far as I remember it's moderated list. [14:16] xnox: is it auto-moderated for those who are subscribed? I am not (yet) [14:17] mitya57: yeah. rather not moderated at all if posted by subscribers, kind of like launchpad mailing lists. [14:18] ok, let's hope they will read my mail via yours :) [14:20] xnox: by the way, did you already test if phablet toolkit works with PyQt? [14:20] mitya57: it could be me building it wrong though =/ I am surprised it build at all =)))) [14:21] mitya57: nope. I have only tried simple standard show a QApplication with a label =) [14:21] but the target is the toolkit, right? or why do you need it? [14:22] mitya57: my initial target is getting a non-trivial gui app working (e.g. ubiquity) or something QML based. [14:22] xnox: fwiw, apart from QFont constructor and Xserver crashes, I am able to run ReText under Qt 5 [14:22] mitya57: the target is to get oem-config (ubiquity) frontend in python with ubuntu-touch Qml components. [14:23] mitya57: but we'd want pyqt4 (with qt5.... and eventually pyqt5) regardless of anything. [14:24] yes, let's hope PyQt5 will be available soon [14:25] and thanks for the work you have done! [14:25] mitya57: i would not hold my breath waiting for PyQt5 release [14:26] well, probably if you are a professional diver ... [14:28] ogra_: i'm no Linus ;-) [14:28] hehe [14:29] seb128: I think https://plus.google.com/u/0/106010143685041042333/posts/XeygQ6A9dEk indicates that the author is not going to continue i-w development [14:29] cjwatson: thanks, and for the wiki link - I had googled but not found it. [14:31]