=== wgrant_ is now known as wgrant === fabbione_vac is now known as fabbione === ogasawara_ is now known as ogasawara [04:58] Good morning [04:59] mpt: actually ev is right; we will stop installing the proprietary drivers automatically in ubiquity; we actually never intended to at least for fglrx (that was a blatant bug) [05:00] mpt: and with the system compositor, lightdm for screen locking etc, non-KMS drivers just won't cut it any more, so I'm all for not enabling nvidia automatically either any more [05:00] mpt: (but NB that this is not really my decision to take any more) [05:01] mpt: right, it's irrelevant whether the driver comes from jockey, or what modaliases are; this is just about "do we install it automatically or not?" [05:27] doko / jdstrand: https://bugs.launchpad.net/ubuntu/+source/libfile-fcntllock-perl/+bug/1014961 is going to need a reasonably quick review by someone MIRish. [05:27] Launchpad bug 1014961 in libfile-fcntllock-perl (Ubuntu) "[MIR] libfile-fcntllock-perl; new dpkg-dev dependency" [Undecided,New] [05:29] apw: FWIW, the above is to fix your debian/files concurrency issues, do you can stop employing dirty locking hacks in the kernel with the new dpkg. === BenC_ is now known as BenC [06:07] RAOF: heyo! thanks for the upload of software-center 5.2.3 :D [06:16] tremolux: Please make it less of an ordeal next time :) [06:18] RAOF: not really under my control, my friend, but I'll do my best ;) [06:24] Hi gang, does anyone else get the cdimage mails to mailing lists? We're (Studio) having a problem with the size of the emails, seems they're about 50KB when apparently the mailman stops messages at 40KB. [06:25] I haven't found a way to tweak this individually for our list only on the administrative interface, but have I just not looked hard enough? How have you resolved the issue? [06:27] astraljava: http://staff.imsa.edu/~ckolar/mailman/mailman-admin-quickref-0.2.html [06:28] micahg: bah... I can't seem to get anything right today. Thanks! :) === zyga-afk is now known as zyga [07:07] good morning [07:16] cjwatson, ev: could you please add an XS-Testsuite header to ubiquity, like in http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/quantal/apport/ubuntu/revision/2031 ? I recently discussed that with the DEP-8 guys, and the spec is updated now [07:28] xnox: who pinged me? [07:28] s/who/you/ [07:33] xnox: Also, congrats! [07:35] pitti, so the Nvidia driver won't be installed even if you check the "Ubuntu uses third-party software to play Flash, MP3..." checkbox? [07:35] mpt: that's how I take it, anyway [07:36] pitti, ok, thanks [07:36] mpt: I guess in the end we need to see how much we value system compositor, lock screen etc. over nvidia performance by default, and how well nvidia and nouveau work with unity [07:36] RAOF: ^ how did you understand this discussion back theN? [07:36] RAOF: (installing nvidia by default when you click the "third-party" check box in ubiquity) [07:37] pitti, while I was digging through this yesterday I was depressed to discover that "text-free boot" has basically been made dependent on "ship Wayland" :-) [07:37] mpt: we won't actually ship wayland [07:37] mpt: that's teh "system compositor" stuff [07:37] pitti, or at least that's what the blueprint says [07:37] but again, it's depending on a KMS graphics driver [07:38] mpt: they are very similar, anyway [07:38] "The technology used will probably be Wayland, and in some ways this change is to implement the Wayland Tech Preview that was proposed for Precise [1]." [07:38] pitti, mpt: I'm not sure whether that's the right tradeoff yet. *Certainly* fglrx is wrong. [07:38] yes, fully agreed to fglrx [07:38] this _never_ was intended to be installed automatically [07:38] it was a bug [07:39] as for nvidia, I guess the desktop team needs to decide that in this cycle, considering performance, stability, and KMS-dependent features [07:40] (Sorry, multiplexing conversations) [07:40] We're not going to *break* the existing setup with the system compositor; if you're not running it, you'll get exactly the same behaviour as now. [07:42] Except in so much as the system-compositor based stack will get progressively better, and those improvements won't be able to be made on the binary driver side. [07:43] RAOF: so you think nouveau is still considerably worse than ati? i. e. worse enough to warrant shipping nvidia by default? [07:43] . o O { such a hard trade of which kind of badness you want... } [07:43] Yes; power management is the last big thing. [07:44] mpt: ok, so it actually seems it's relatively likely that we'll install nvidia by default; sorry for all that confusion [07:44] If nouveau had power management enabled now, I'd be putting nvidia in the same basket as fglrx; some people will want it, most won't need it. [07:44] RAOF: does "enabled" mean that it already exists and is buggy, or that it doesn't exist at all yet? [07:44] pitti, by "by default" do you mean if the checkbox is checked, or even if it isn't? [07:45] mpt: if the checkbox is set, sorry [07:45] ok [07:45] we don't install any proprietary stuff without the checkbox [07:45] pitti, how did you find this out? :-) [07:45] (and haven't ever) [07:45] pitti: It already exists, and I *think* it's in our quantal kernel, but is hidden behind an elaborate series of tests designed to disuade the unworthy. [07:45] mpt: with "this" == ? [07:46] pitti, that we will be installing Nvidia driver if you check the checkbox [07:46] mpt: ah; cf. "desktop team needs to decide that during quantal" [07:47] mpt: but it seems after what RAOF said we should install it for now [07:48] pitti, oh, you found it out from that discussion with RAOF [07:48] Yes. If you need it again, unequivocably: Ticking that checkbox should enable the nvidia driver, if available. [07:48] not from some mailing list message I haven't seen yet :-) [07:48] RAOF: ok; committing that change to ubuntu-drivers-common then [07:49] pitti, so the text in the installer should mention graphics after all [07:49] yes, seems so :( [07:49] okay. [07:51] Heisenbergian work item [07:51] * pitti sympathizes with https://plus.google.com/u/1/110197054476722784567/posts/eK8RFnDg39K [07:55] xnox: pong [07:55] pitti: hehe [07:56] vibhav: hello, sorry, I think I got the dates wrong. Keep calm and carry on. [07:57] yeah, thats what I thought === tkamppeter__ is now known as tkamppeter [07:58] RAOF, mpt: ok, done: https://github.com/tseliot/ubuntu-drivers-common/commit/3edabca8 [07:59] ok [08:00] * mpt tries the "bzr uncommit" command for the first time [08:07] pitti, fwiw; I don't sympathise with that comment - the contact I've been having with the one Nvidia engineer active in the audio area has been good and friendly. (That doesn't mean that I think they should provide open source drivers, but that's another story.) [08:08] no doubt about that; but I still critizice them about not releasing specs and claim it's because of patents or so [08:09] hey pitti, diwic [08:09] I mean, whether it's bit 5 or 8, or port 55 or 58 to wiggle to activate a particular function is not science, it's simply an arbitrary decision and convention [08:09] hey seb128 [08:09] seb128, hi [08:10] so it's once again not an engineer problem (I'm sure many of them feel similar), but again a management/patent/bureaucracy one [08:10] pitti, yeah, agreed. [08:10] I wouldn't put it as strongly as Linus, but I would never recommend anyone to buy an nvidia card if they want to use linux [08:11] pitti, interesting. I think the xbmc community recommends nvidia as being the best. [08:11] let me look that up [08:11] well, I don't speak for the world :) [08:12] diwic, pitti: The actual nvidia linux driver team is pretty cool; they care about things being good. But there aren't that many of them. [08:12] * pitti quietly hides his world domination plan [08:14] from http://wiki.xbmc.org/index.php?title=Supported_hardware - "Team-XBMC recommends NVIDIA GeForce 6150 or later as NVIDIA are currently the manufacturer that offers good device-drivers for Linux" [08:14] I think they should clarify "good" here === fenris is now known as Guest13007 [08:16] they have lots of bugs, have lots of problems with multiple heads, have poor support for older hardware, and no KMS support, and nvidia hardware is a power drain compared to intel (although that is quite understandable given the different performance level) [08:16] so they are certainly the better choice for gamers, but an absolutely bad choice for a work laptop [08:18] That's true. [08:19] They've got quite a good GL stack. [09:11] stgraber: I've just rejected the libvirt precise SRU. Are you here to discuss it?+ [09:25] RAOF: He lives in Canadia, and all sane Canadians (ie: the ones who aren't me) are fast asleep. [09:31] http://marcin.juszkiewicz.com.pl/~hrw/shots/bad-fonts.jpg - does anyone know why I have some crappy fonts in GTK apps? [09:39] hrw: because you use Gvim? =) /me no clue to be honest [09:41] xnox: same in chromium, gnotes [09:42] =( [09:43] looks like oxygen-gtk theme is borked [09:44] light-themes is rather broken ATM as well; both need adjustments for current GTK presumably [09:44] s/presumably/confirmed/ for light-themes [09:45] pitti: so which light colour theme is safe? (other they rayleigh) [09:45] pitti: Sounds good, thanks - done [09:46] cjwatson: cheers [09:46] hrw: light-themes should mostly work again (I use Radiance) [09:46] looks like 'xfce-winter' is also safe [09:47] nope ;( [09:47] text rendering is not part of the theme [09:47] seb128: part of engine? [09:47] no [09:48] that's pango, freetype, etc [09:48] the theme does shapes and colors basically, and effects [09:48] seb128: Qt also uses freetype and displays properly [09:48] when did the issue start? [09:48] gnotes and chromium are not gtk3 [09:48] at least few days ago [09:48] so I doubt it's any of the recent gtk3 changes [09:49] neither is gvim [09:50] in chromium issue is only on tabs and toolbars - pages are rendered properly [09:51] is chromium using gtk3? (I don't think it does) [09:51] gtk2 [09:51] ok, so your issues are different from what pitti mentioned [09:52] no clue what they are but gtk2 didn't change for a while [09:52] on my system only nautilus-dropbox is returned by 'aptitude why libgtk-3.0' [09:52] s/3.0/3-0/ [09:53] urg [09:53] dunno what weird setup you use [09:53] seb128: kde [09:53] ok, so I guess check with the KDE guys what they changed [09:53] mkey [09:53] I doubt the issue comes from the GTK side [09:53] that stack didn't change in months [10:00] hi guys !!! [10:07] can anyone help me please , i found a bug but i dont know against which package i have to report it . the bug goes as follow when opening a gtk app (gedit for example) the menubar appears on both the application and the global menu but only when these apps are running on kde [10:09] doko, barry: are there any plans of getting this into Ubuntu: https://fedoraproject.org/wiki/Features/EasierPythonDebugging#py-bt [10:09] The use case I have is for hanging application. We're going to pop up apport when we detect an desktop application hang. When the user presses submit, apport then SEGVs the process and we get back a nice core dump [10:09] Which will give us a stack trace, but for python applications it would be better if we could get a python traceback [10:10] I suppose one alternative is to install a special signal handler in every python application and get it that way [10:13] ev: this should already be there. I can check if this is the newest version however, but I'd like to avoid backports to gdb [10:13] hmm, maybe not for python3 [10:13] (gdb) py-bt [10:13] Undefined command: "py-bt". Try "help". [10:14] That's gdb 7.4-2012.04-0ubuntu2 [10:16] ev: Which python executable are you debugging? [10:17] ev: It works with python-dbg. [10:17] ev: (Which is my reading of the Fedora spec too) [10:18] ahh [10:19] cjwatson, doko: that was indeed it [10:19] thanks [10:19] But yes, not in python3-dbg right now [10:20] cjwatson: while I have you here, what are your thoughts on the idea? gdb to python stacktrace or installed signal handler that raises an uncaught exception? [10:20] if you have a moment, of course [10:20] otherwise no worries [10:20] I'm *very* wary of injecting signal handlers into unsuspecting processes, even if they are SEGV. [10:21] You must be ^-- this tall to use signals, as the saying goes [10:21] :) [10:21] looks like that leaves us with one option then [10:21] You don't want to have to re-exec with python(3)-dbg, though. [10:21] yeah, hm [10:21] Is it possible to make the gdb script work with the non-dbg interpreter? (If it isn't, the signal handler approach wouldn't work anyway) [10:22] Why wouldn't the signal handler approach work with a non-dbg interpreter? [10:22] or am I incorrectly parsing your sentence [10:23] Something still has to be able to introspect enough of Python's data structures to generate the backtrace. [10:23] I don't know whether the dbg-ness is what allows us to do that. [10:25] cjwatson: python application hangs, send SIGQUIT to it, signal handler does raise(YoullNeverCatchMe), apport python hook picks it up, job done. [10:25] no need to know the internals of the python data structures [10:25] mind you, I'm not saying we go with this approach for the reasons you raised [10:25] just pointing out that I don't see why it needs dbg packages [10:25] I'm concerned about Python's habit of leaking signal handlers to subprocesses it calls. See SIGPIPE. [10:26] indeed, I do recall the pain you faced from that in ubiquity :) [10:26] Unless you were supernaturally careful in a way that I'm not even sure how it's possible to be, the effect of this would be that any non-Python subprocess of Python would have SIGQUIT ignored. [10:26] So I can't recommend that. [10:26] hmm, indeed [10:27] (And yes, I'd misunderstood how you were planning to use the signal handler) [10:30] It doesn't seem like there's a good way to do this at present then. I think it's still valuable to collect these so that we get statistics on application hangs, but the python ones will just be unparseable. [10:31] unparseable in that a developer will look at them and their brain will melt out, not that the retracers will have any difficulty handling a SEGV'ing python application [10:33] The signatures for these may end up looking very similar to one another as well, but I think I'd rather collect python hangs and provide consistent UI than only show the dialog for binary applications. [10:38] Mm. (A small handful of the Python crashes will be useful even without this.) [10:39] atfork? [10:39] [ok, terrible idea] [10:39] cjwatson: I'm not sure I follow [10:40] hi lifeless [10:40] hi ev, and bye, tis sleep time for me! :) [10:42] ev: Cases where the crash is in a C extension will be useful [10:48] lifeless: enjoy! [10:49] cjwatson: to be clear, they're hangs not crashes. We're just treating them as crashes because that's the most secure way to do it (https://bugs.launchpad.net/ubuntu/+source/whoopsie-daisy/+bug/1006398) [10:49] but if the hang were in a c extension, that would indeed be useful to capture [10:49] Launchpad bug 1006398 in whoopsie-daisy (Ubuntu) "Bypassing ptrace restrictions for errors from hanging applications" [Undecided,New] [10:49] if I'm following your logic :) [10:51] ev: Right === MacSlow is now known as MacSlow|lunch [11:14] infinity: there, have a building cups [11:14] cjwatson: I've created bug 1015080 to track this, if we ever come up with a better solution. [11:14] Launchpad bug 1015080 in Whoopsie "Retrieve Python tracebacks from hanging applications" [Wishlist,New] https://launchpad.net/bugs/1015080 === MacSlow|lunch is now known as MacSlow === achille_ is now known as achille [12:36] https://gist.github.com/2953844 # I'd like some thoughts on creating .deb packages that install ppas/repos that can in turn be dependencies of metapackags. [12:37] infinity: libfile-fcntllock-perl: done [12:38] hippiehacker: this was discussed at some length at the last UDS. https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-security-of-third-party-debs Summary: it's not somthing we are mad about, it'd be nice to provide a recommended alternative [12:52] tumbleweed: I'm trying to create a tool that generates a local repository (with self-signed .debs) the debs themselves containing only dependency lists and ppas generated from simple profiles: https://github.com/hh/sputnik-repo/blob/master/data_bags/sputnik_profiles/rails%2Bsublime.json [12:57] The profiles could be easily shared / possibly digtially signed / and include the gpg for the dependent repos. [12:58] hippiehacker: we'd like it if that problem could go away, but for now it's a reasonable solution [13:12] dpm: pitti: I'd like to suggest this to stop creating the kde language packs from launchpad https://code.launchpad.net/~jr/langpack-o-matic/no-kde-lang-pack/+merge/111010 [13:12] tumbleweed: is https://wiki.ubuntu.com/ThirdPartyApt the main thrust of where we are currently headed? [13:16] hippiehacker: that's ancient, but it's what I'd want,yes [13:23] does anybody have an example of a cdbs package that has to call configure twice and build with two different set of options? i'm currently looking at libpeas, but the cdbs magic is evading me. or should i just switch it to dh and avoid the pain? ;) [13:25] Hello. I'm trying to do a requestsync for qjackctl, but I get this: E: The package 'qjackctl' does not exist in the Debian primary archive in sid, sid-security, sid-updates or sid-proposed [13:25] Never done this before, but I do know qjackctl does exist in Sid [13:26] ailo: What's your full requestsync command line? [13:26] Just: requestsync qjackctl [13:26] I assumed options would be right by default [13:27] * cjwatson blinks [13:27] https://launchpad.net/debian/+source/qjackctl/+publishinghistory [13:27] rmadison thinks it's present, though [13:27] it is present [13:28] but not according to LP [13:28] ailo: requestsync -d sid qjackctl quantal [13:28] vibhav: No [13:28] cjwatson: why? [13:28] vibhav: Won't help [13:28] ah got you [13:28] sorry :( [13:29] This is confusing; I have no idea why LP thinks that was removd [13:29] *removed [13:30] * cjwatson wonders if he can get at the importer logs anywhere [13:30] 2012-06-18 04:24:30 ERROR Error processing package files for qjackctl [13:30] -> http://launchpadlibrarian.net/107864828/3nXxcopS5CWaeRIReI3Axcuek7g.txt (Error 25 unpacking source) [13:31] That ain't gonna help [13:31] barry: build: make -f debian/rules configure1-stamp && make -f debian/rules configure2-stamp ..... [13:31] barry: or you can simply add additional -stamp dependencies to the configure magic target [13:31] Hello, can anybody help me with Glade? [13:32] So, it'll work if LP changes to unpack with DEB_VENDOR=debian [13:33] bug 901334 [13:33] Launchpad bug 901334 in Launchpad itself "ExecutionError: Error 2 unpacking source raised by gina.py" [Critical,Triaged] https://launchpad.net/bugs/901334 [13:33] xnox: i have to do major surgery on the build. i have to build it in two different locations, with clean, different configures each time, then move and rename one of the .sos into place. i've no doubt that there's plenty of makemagic hidden in there, but the cdbs documentation is pitiful, and the .mk files are inscrutable. you can probably infer my opinion of cdbs ;) [13:33] (different source, same bug) [13:34] barry: do you want me to try packaging it, if you promise to test it?! [13:34] * xnox did many 'multi build' splits before [13:35] * xnox used to love cdbs.... [13:35] Does resyncronize and merge mean the same thing [13:35] vibhav: Depends who's using the terms, but probably yes [13:36] cjwatson: So it's a launchpad bug? Doesn't this affect a whole range of packages? [13:36] cjwatson: you [13:36] ailo: I think I can fix this, but it will require landing an LP change so will take at least a couple of days; is that OK with you? Once this is fixed, it'll be auto-synced, and won't need anyone to run requestsync [13:36] vibhav: Then yes [13:36] ah thanks [13:36] ailo: A handful; not many packages have different Debian and Ubuntu patch series to start with, and of those only a small fraction fail to unpack using the Ubuntu patch series [13:37] cjwatson: Sounds great. I'm not in a hurry, no. Actually looking to backport that package to Precise later [13:37] Aha [13:37] ncbi-rrna-data Pre-Depends: dpkg (>= 1.15.6) for xz compression support. [13:37] Needed until after Ubuntu 12.04 LTS. [13:38] won't it still fail to unpack when we try to build it though? [13:38] cjwatson: Do you know if we still need dpkg as a pre-depends in ncbi-tools6 for quantal? [13:39] I suppose it is more correct to have the failure there than in the importer [13:39] vibhav: We do not, and in any case the Pre-Depends was added in Debian; I've synced that package now. (Though it'll probably fail to build until Adam's new dpkg upload lands.) [13:40] Laney: Probably, but at that point it'll actually be feasible to fix it by hand [13:40] cjwatson: Thanks for the info [13:41] slangasek: you there? === BenC__ is now known as BenC === zyga is now known as zyga-afk [13:53] RAOF: wasn't around anymore to discuss libvirt, ping me (and probably hallyn too as AFAIK he's the author of the SRU) when you start your day [13:59] pitti: ping. any news about u1 MRE request? [14:00] dobey: it seems fine to me, but we either need three more +1 on the list, or wait for the next TB meeting (next Monday) [14:01] that's not what the wiki says [14:01] "Changes can be approved via any single TB member" [14:02] is the wiki wrong again? :) [14:05] hm, I was not aware of that [14:05] slangasek acked that when we discussed GNOME, he said one +1 was enough [14:05] changing policies sounds like a board decision, not a member decision to me [14:06] but so much the better [14:06] I'll reply to the list and add it to the MRE page [14:06] cjwatson: OOI, were you aware that new MREs can be approved by a single TB member? [14:07] it's from 2007 already: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions?action=diff&rev2=3&rev1=2 [14:11] right. 2007 is pretty old :) [14:18] pitti: thanks again. :) [14:19] pitti: Heh, I did know that once but I'd forgotten [14:25] xnox: you there? [14:25] vibhav: yes [14:26] xnox: PM? [14:26] ? [14:27] vibhav: what do you mean? [14:27] xnox: Could I PM You? [14:27] Private Message [14:27] yes.... you could have just done that straight away === zyga-afk is now known as zyga [14:36] !staff [14:36] hey Christel, Dave2, Gary, KB1JWQ, Levia, Martinp23, SportsChick, VorTechS, jayne, jenda, marienz, nalioth, niko, nhandler, rob, dax, stew, or tomaw, I could use a bit of your time :) [14:36] !ops [14:36] Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom! [14:39] hi, could someone help me understand this lintian warning: W: landscape-client source: binary-nmu-debian-revision-in-source 12.05-0ubuntu0.12.04 [14:39] I'm building a sru candidate for precise, upstream version 12.05 [14:40] current precise package is 12.04.3-0ubuntu1 [14:40] current quantal package is 12.05-0ubuntu1 [14:40] ahasenack, this warning is safe to ignore - NMUs are a Debianism [14:41] dholbach: ok, it doesn't warrant an override I guess? [14:41] no [14:41] ok, thanks [14:59] bdmurray, SpamapS: hey, could one of you review the gwibber SRU today? I've added a filtered debdiff to the bug (the queue diff is a bit noisy due to vala autogenerated code diffs), the update fixes a bug in libgwibber-gtk that the appdevelopper guys would like to see resolved because their documentation example of how to use gwibber hits the said bug [15:19] seb128: I'll have a look [15:19] bdmurray, thanks, let me know if anything is missing [15:24] seb128: well bug 938667 doesn't have an explicit test case [15:24] Launchpad bug 938667 in gwibber (Ubuntu Precise) "gwibber-accounts crashed with UnicodeEncodeError in on_facebook_auth_title_change(): 'ascii' codec can't encode characters in position 0-7: ordinal not in range(128)" [High,Fix committed] https://launchpad.net/bugs/938667 [15:26] bdmurray, refresh [15:29] seb128: and this is supposed to supercede the existing one in -proposed? [15:29] bdmurray, yes, the fix from the current one was incomplete and failed verification [15:32] bdmurray, thanks ;-) [15:51] infinity: bug #1011597 - done [15:51] Launchpad bug 1011597 in perl (Ubuntu) "[MIR] libfcgi-perl, libcgi-fast-perl" [High,Fix committed] https://launchpad.net/bugs/1011597 [16:00] SpamapS: do you mind if I rebuild drizzle for boost1.49? Or will you do bug 987575 really soon now ;-) [16:00] Launchpad bug 987575 in drizzle (Ubuntu) "Please merge drizzle 1:7.1.33-stable-4 from Debian unstable" [High,In progress] https://launchpad.net/bugs/987575 === zyga is now known as zyga-afk [16:49] xnox: I'll upload drizzle ASAP [16:50] SpamapS: awesome =) [16:50] thanks [17:07] pitti, jdstrand: My heroes. [17:20] * xnox doesn't feel like breaking autofs today, unless I messed up my upstart state [17:21] hi, can someone help me interpret this basic message? [17:21] "Good signature on /home/andreas/bzr/sru/12.05/precise/landscape-client_12.05-0ubuntu0.12.04.dsc. [17:21] Package includes an .orig.tar.gz file although the debian revision suggests [17:21] that it might not be required." [17:22] why would the .orig file not be required? [17:22] ahasenack: It's a case of tools being insufficiently clever. Ignore it. [17:22] it's not a native package [17:22] cjwatson: ok, thanks [17:22] if debian_version == '0.1' or debian_version == '1' \ [17:22] or debian_version == '1.1' or debian_version == '0ubuntu1': [17:22] include_orig = 1 [17:23] But that's just a heuristic which goes wrong in this case, to purely cosmetic effect [17:23] * xnox how unpythonic. BTW what about 0.1ubuntu1? [17:24] I suspect it's not worth trying to add further band-aids [17:24] or to be honest 0ubuntu0* [17:24] =))) [17:24] if you want to get an extra line of code in your LP quota, you can probably switch to "if debian_version in (...)" (or just drop the check entirely?) [17:24] stgraber: this is in dput, not LP [17:25] I'm doing the fork count of automount and I get........ 9 [17:25] =( [17:25] LP *knows* whether the .orig is needed; dput is guessing [17:33] stgraber: now this is funky. didn't it sued to be that you could 'bzr push lp:~user/ubuntu/project/whatever' and it would auto-expand to add 'quantal' after 'ubuntu'? [17:33] maybe not [17:33] Not AFAIK. [17:34] hallyn: that works for the main branch (lp:ubuntu/lxc) but for user branches you need to have the series in tehre [17:34] I think you're thinking of lp:ubuntu/package -> lp:ubuntu//package. [17:34] *there [17:34] i see [17:34] thanks === arges is now known as arges-lunch [18:24] why is there a small thin line just under the titlebar when i move windows around? [18:58] infinity: so, how important is it for us to drop gcc 4.5 from the mysql build? At this point, upstream has ack'd the i386 ASM bug.. but I have no idea how long it will take them to reproduce [18:59] SpamapS: It should happen eventually, so we're not carrying 17 versions of GCC, it's certainly not world-endingly urgent. [18:59] infinity: ok, it appears that mysql is also one of the only things keeping 4.5 in Debian, and there's a push to drop it for wheezy [19:00] infinity: 4.4 has been offered up as an alternative, apparently it has to be kept for some reason [19:01] I'm not sure that's much of an alternative. :P [19:03] SpamapS: I don't see anything obviously keeping gcc-4.4 in either, but maybe I'm missing it. [19:05] infinity: Yeah, I think the right answer is actually to just disable the optimizations for i386 SSL [19:05] infinity: upstream has it as a Serious / Critical issue so they will fix soon enough. [19:06] in the mean time, i386 users will just have slow SSL. :-P [19:06] SpamapS: Oh, boost depends on gcc-4.4. Hilarious. [19:06] infinity: of course it does [19:06] boost depends on anger [19:06] and frustration [19:06] and pixie-dust I think [19:06] should rename it to dementor [19:06] SpamapS: So, I guess you could join the ranks of boost for now and downgrade. Except that downgrading compilers makes things more and more likely to suck on ARM. [19:06] SpamapS: And I hear we care about ARM now. [19:07] SpamapS: You could use 4.4 on i386, and 4.7 everywhere else? [19:07] SpamapS: That would be an acceptable solution to me for now. [19:07] infinity: caring, whats that? [19:07] infinity: I wonder if it will make x86 suck a bit more too tho [19:07] SpamapS: A tiny bit, perhaps, but not as much as disabling SSL optimisation, I imagine. [19:08] infinity: if SSL is 4x slower, but the rest of the server is 5% faster, I'd prefer that. [19:08] SpamapS: The x86 codepaths in GCC are fairly solid and mature, oddly enough, so all you'd be missing out on is random clever hacks for shiny new hardware we don't target. [19:08] infinity: SSL is a niche case for mysqld [19:08] But, you could always test, I suppose. [19:08] Your call. [19:08] I'll take your word for it. This is i386 after all [19:08] Just saying that if you do decide to downgrade compilers, please only do it on i386. [19:08] yeah that makes sense [19:12] slangasek: hey, so what is blocking precise nova sru? [19:13] slangasek: we sort of left the conversation unfinsihed yesterday. === BenC__ is now known as BenC [19:17] Daviey: clarity from the TB about whether there should be an MRE for this and on what terms. It clearly doesn't fit *except* as an MRE, and things are in limbo due to the "trial" MRE SRU in oneiric stalling out. I asked zul to email the TB with details on what the test plan is, so we can un-stick it [19:19] slangasek: why is nova wedged on this, but the other openstack components were accepted? [19:19] slangasek: verification of the whole suite, were intended to be done coordinated. [19:19] Daviey: I don't know the openstack components by package name; but that question is better addressed to whoever did the accept? [19:21] in general terms, they were accepted because the SRU team member who reviewed them was satisfied that they meet the SRU requirements as-is, and that doesn't appear to be the case for nova [19:21] Daviey: The simple answer could be (though I don't know) that the other components had simple and targetted fixes, and nova doesn't. [19:21] slangasek: do you see harm in nova being accepted into -proposed, under the condition that it does not paas verification until this matter is cleared up? [19:21] Daviey: And slangasek beat me to that. [19:23] nova certainly has more changes, but i am not satisfied that the other components had fixes soley targeted towards issues that impact us. [19:25] Daviey: a) our processes don't give us any way to effectively put a hold on the package once it's in -proposed, b) I don't see any progress being made on clearing it up as there are no new mails on the tb list about this from the server team [19:27] slangasek: okay, bug 978907 is a bug fix for SUSE which is in glance currently in -proposed that was accepted. [19:27] Launchpad bug 978907 in glance (Ubuntu) "[SRU] capture-output fails in glance-control" [Undecided,In progress] https://launchpad.net/bugs/978907 === arges-lunch is now known as arges [19:27] If your demand is accurate, we should probably pull glance out of -proposed. [19:28] zul: can you rekindle the mail to TB as a matter of urgency please [19:28] Daviey: yeah [19:34] Daviey: the glance diff is 4% the size of the nova diff, and over half of the glance diff is in the debian/ directory. I think it's reasonable to think that the glance changes actually did fit in the SRU guidelines as-is. [19:35] sorry, I missed a decimal point [19:35] .4% :P [19:36] though strangely most of that diff is the addition of a ChangeLog file, heh [19:37] slangasek: Currently, this is a one off request. Which means it doesn't need a TB blessed MRE. mdz commented that the SRU team are empowered to make this call. [19:40] Daviey: where has he said that? [19:42] slangasek: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/651875/comments/12 .. until we ask to do this again, it's a one-off.. no? [19:42] Launchpad bug 651875 in bind9 (Ubuntu Lucid) "Bind 9.7.0-P1 validation errors" [Medium,Confirmed] [19:43] do you intend to only ask for one? [19:43] Note, i'm not trying to bypass the TB.. i'm just keen to try to get this progressing to avoid what happend in Oneiric. [19:43] slangasek: today, i plan to only ask once. [19:43] I don't see how this is at all analogous to what happened in oneiric [19:44] the SRU *was* accepted into oneiric, and then there was no follow-through [19:44] slangasek: numerous contributing factors lead to it not being successful. [19:44] slangasek: it was accepted yes, but superseeded by -security, no? [19:45] Daviey: well, and? Once superseded by security, shouldn't the uploader have merged the security changes and re-uploaded? [19:45] --> no follow-through [19:46] slangasek: no, it's not as simple as that. [19:47] and it seems to me that the server team, as a rule, does want MRE handling of these packages, which means everyone's time is better spent getting that MRE than having the SRU team review it and *then* have the TB review it [19:48] slangasek: as mentioned above, a standing MRE is being re-sought. (i hoped it would be obvious the prior approval would be carry forwarded).. but at this stage, it seems reasonable to consider it a one off, whilst that is ongoing IMO. [19:49]