| === wgrant_ is now known as wgrant | ||
| === fabbione_vac is now known as fabbione | ||
| === ogasawara_ is now known as ogasawara | ||
| pitti | Good morning | 04:58 |
|---|---|---|
| pitti | 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) | 04:59 |
| pitti | 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 |
| pitti | mpt: (but NB that this is not really my decision to take any more) | 05:00 |
| pitti | 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:01 |
| infinity | 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 |
| ubottu | Launchpad bug 1014961 in libfile-fcntllock-perl (Ubuntu) "[MIR] libfile-fcntllock-perl; new dpkg-dev dependency" [Undecided,New] | 05:27 |
| infinity | 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. | 05:29 |
| === BenC_ is now known as BenC | ||
| tremolux | RAOF: heyo! thanks for the upload of software-center 5.2.3 :D | 06:07 |
| RAOF | tremolux: Please make it less of an ordeal next time :) | 06:16 |
| tremolux | RAOF: not really under my control, my friend, but I'll do my best ;) | 06:18 |
| astraljava | 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:24 |
| astraljava | 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:25 |
| micahg | astraljava: http://staff.imsa.edu/~ckolar/mailman/mailman-admin-quickref-0.2.html | 06:27 |
| astraljava | micahg: bah... I can't seem to get anything right today. Thanks! :) | 06:28 |
| === zyga-afk is now known as zyga | ||
| dholbach | good morning | 07:07 |
| pitti | 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:16 |
| vibhav | xnox: who pinged me? | 07:28 |
| vibhav | s/who/you/ | 07:28 |
| vibhav | xnox: Also, congrats! | 07:33 |
| mpt | 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 |
| pitti | mpt: that's how I take it, anyway | 07:35 |
| mpt | pitti, ok, thanks | 07:36 |
| pitti | 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 |
| pitti | RAOF: ^ how did you understand this discussion back theN? | 07:36 |
| pitti | RAOF: (installing nvidia by default when you click the "third-party" check box in ubiquity) | 07:36 |
| mpt | 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 |
| pitti | mpt: we won't actually ship wayland | 07:37 |
| pitti | mpt: that's teh "system compositor" stuff | 07:37 |
| mpt | pitti, or at least that's what the blueprint says | 07:37 |
| pitti | but again, it's depending on a KMS graphics driver | 07:37 |
| pitti | mpt: they are very similar, anyway | 07:38 |
| mpt | "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 |
| RAOF | pitti, mpt: I'm not sure whether that's the right tradeoff yet. *Certainly* fglrx is wrong. | 07:38 |
| pitti | yes, fully agreed to fglrx | 07:38 |
| pitti | this _never_ was intended to be installed automatically | 07:38 |
| pitti | it was a bug | 07:38 |
| pitti | as for nvidia, I guess the desktop team needs to decide that in this cycle, considering performance, stability, and KMS-dependent features | 07:39 |
| RAOF | (Sorry, multiplexing conversations) | 07:40 |
| RAOF | 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:40 |
| RAOF | 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:42 |
| pitti | RAOF: so you think nouveau is still considerably worse than ati? i. e. worse enough to warrant shipping nvidia by default? | 07:43 |
| pitti | . o O { such a hard trade of which kind of badness you want... } | 07:43 |
| RAOF | Yes; power management is the last big thing. | 07:43 |
| pitti | mpt: ok, so it actually seems it's relatively likely that we'll install nvidia by default; sorry for all that confusion | 07:44 |
| RAOF | 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 |
| pitti | RAOF: does "enabled" mean that it already exists and is buggy, or that it doesn't exist at all yet? | 07:44 |
| mpt | pitti, by "by default" do you mean if the checkbox is checked, or even if it isn't? | 07:44 |
| pitti | mpt: if the checkbox is set, sorry | 07:45 |
| mpt | ok | 07:45 |
| pitti | we don't install any proprietary stuff without the checkbox | 07:45 |
| mpt | pitti, how did you find this out? :-) | 07:45 |
| pitti | (and haven't ever) | 07:45 |
| RAOF | 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 |
| pitti | mpt: with "this" == ? | 07:45 |
| mpt | pitti, that we will be installing Nvidia driver if you check the checkbox | 07:46 |
| pitti | mpt: ah; cf. "desktop team needs to decide that during quantal" | 07:46 |
| pitti | mpt: but it seems after what RAOF said we should install it for now | 07:47 |
| mpt | pitti, oh, you found it out from that discussion with RAOF | 07:48 |
| RAOF | Yes. If you need it again, unequivocably: Ticking that checkbox should enable the nvidia driver, if available. | 07:48 |
| mpt | not from some mailing list message I haven't seen yet :-) | 07:48 |
| pitti | RAOF: ok; committing that change to ubuntu-drivers-common then | 07:48 |
| mpt | pitti, so the text in the installer should mention graphics after all | 07:49 |
| pitti | yes, seems so :( | 07:49 |
| mpt | okay. | 07:49 |
| mpt | Heisenbergian work item | 07:51 |
| * pitti sympathizes with https://plus.google.com/u/1/110197054476722784567/posts/eK8RFnDg39K | 07:51 | |
| vibhav | xnox: pong | 07:55 |
| vibhav | pitti: hehe | 07:55 |
| xnox | vibhav: hello, sorry, I think I got the dates wrong. Keep calm and carry on. | 07:56 |
| vibhav | yeah, thats what I thought | 07:57 |
| === tkamppeter__ is now known as tkamppeter | ||
| pitti | RAOF, mpt: ok, done: https://github.com/tseliot/ubuntu-drivers-common/commit/3edabca8 | 07:58 |
| mpt | ok | 07:59 |
| * mpt tries the "bzr uncommit" command for the first time | 08:00 | |
| diwic | 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:07 |
| pitti | no doubt about that; but I still critizice them about not releasing specs and claim it's because of patents or so | 08:08 |
| seb128 | hey pitti, diwic | 08:09 |
| pitti | 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 |
| pitti | hey seb128 | 08:09 |
| diwic | seb128, hi | 08:09 |
| pitti | 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 |
| diwic | pitti, yeah, agreed. | 08:10 |
| pitti | 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:10 |
| diwic | pitti, interesting. I think the xbmc community recommends nvidia as being the best. | 08:11 |
| diwic | let me look that up | 08:11 |
| pitti | well, I don't speak for the world :) | 08:11 |
| RAOF | 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:12 | |
| diwic | 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 |
| pitti | I think they should clarify "good" here | 08:14 |
| === fenris is now known as Guest13007 | ||
| pitti | 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 |
| pitti | so they are certainly the better choice for gamers, but an absolutely bad choice for a work laptop | 08:16 |
| RAOF | That's true. | 08:18 |
| RAOF | They've got quite a good GL stack. | 08:19 |
| RAOF | stgraber: I've just rejected the libvirt precise SRU. Are you here to discuss it?+ | 09:11 |
| infinity | RAOF: He lives in Canadia, and all sane Canadians (ie: the ones who aren't me) are fast asleep. | 09:25 |
| hrw | http://marcin.juszkiewicz.com.pl/~hrw/shots/bad-fonts.jpg - does anyone know why I have some crappy fonts in GTK apps? | 09:31 |
| xnox | hrw: because you use Gvim? =) /me no clue to be honest | 09:39 |
| hrw | xnox: same in chromium, gnotes | 09:41 |
| xnox | =( | 09:42 |
| hrw | looks like oxygen-gtk theme is borked | 09:43 |
| pitti | light-themes is rather broken ATM as well; both need adjustments for current GTK presumably | 09:44 |
| pitti | s/presumably/confirmed/ for light-themes | 09:44 |
| hrw | pitti: so which light colour theme is safe? (other they rayleigh) | 09:45 |
| cjwatson | pitti: Sounds good, thanks - done | 09:45 |
| pitti | cjwatson: cheers | 09:46 |
| pitti | hrw: light-themes should mostly work again (I use Radiance) | 09:46 |
| hrw | looks like 'xfce-winter' is also safe | 09:46 |
| hrw | nope ;( | 09:47 |
| seb128 | text rendering is not part of the theme | 09:47 |
| hrw | seb128: part of engine? | 09:47 |
| seb128 | no | 09:47 |
| seb128 | that's pango, freetype, etc | 09:48 |
| seb128 | the theme does shapes and colors basically, and effects | 09:48 |
| hrw | seb128: Qt also uses freetype and displays properly | 09:48 |
| seb128 | when did the issue start? | 09:48 |
| seb128 | gnotes and chromium are not gtk3 | 09:48 |
| hrw | at least few days ago | 09:48 |
| seb128 | so I doubt it's any of the recent gtk3 changes | 09:48 |
| seb128 | neither is gvim | 09:49 |
| hrw | in chromium issue is only on tabs and toolbars - pages are rendered properly | 09:50 |
| seb128 | is chromium using gtk3? (I don't think it does) | 09:51 |
| hrw | gtk2 | 09:51 |
| seb128 | ok, so your issues are different from what pitti mentioned | 09:51 |
| seb128 | no clue what they are but gtk2 didn't change for a while | 09:52 |
| hrw | on my system only nautilus-dropbox is returned by 'aptitude why libgtk-3.0' | 09:52 |
| hrw | s/3.0/3-0/ | 09:52 |
| seb128 | urg | 09:53 |
| seb128 | dunno what weird setup you use | 09:53 |
| hrw | seb128: kde | 09:53 |
| seb128 | ok, so I guess check with the KDE guys what they changed | 09:53 |
| hrw | mkey | 09:53 |
| seb128 | I doubt the issue comes from the GTK side | 09:53 |
| seb128 | that stack didn't change in months | 09:53 |
| achille | hi guys !!! | 10:00 |
| achille | 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:07 |
| ev | doko, barry: are there any plans of getting this into Ubuntu: https://fedoraproject.org/wiki/Features/EasierPythonDebugging#py-bt | 10:09 |
| ev | 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 |
| ev | Which will give us a stack trace, but for python applications it would be better if we could get a python traceback | 10:09 |
| ev | I suppose one alternative is to install a special signal handler in every python application and get it that way | 10:10 |
| doko | 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 |
| doko | hmm, maybe not for python3 | 10:13 |
| ev | (gdb) py-bt | 10:13 |
| ev | Undefined command: "py-bt". Try "help". | 10:13 |
| ev | That's gdb 7.4-2012.04-0ubuntu2 | 10:14 |
| cjwatson | ev: Which python executable are you debugging? | 10:16 |
| cjwatson | ev: It works with python-dbg. | 10:17 |
| cjwatson | ev: (Which is my reading of the Fedora spec too) | 10:17 |
| ev | ahh | 10:18 |
| ev | cjwatson, doko: that was indeed it | 10:19 |
| ev | thanks | 10:19 |
| cjwatson | But yes, not in python3-dbg right now | 10:19 |
| ev | 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 |
| ev | if you have a moment, of course | 10:20 |
| ev | otherwise no worries | 10:20 |
| cjwatson | I'm *very* wary of injecting signal handlers into unsuspecting processes, even if they are SEGV. | 10:20 |
| cjwatson | You must be ^-- this tall to use signals, as the saying goes | 10:21 |
| ev | :) | 10:21 |
| ev | looks like that leaves us with one option then | 10:21 |
| cjwatson | You don't want to have to re-exec with python(3)-dbg, though. | 10:21 |
| ev | yeah, hm | 10:21 |
| cjwatson | 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:21 |
| ev | Why wouldn't the signal handler approach work with a non-dbg interpreter? | 10:22 |
| ev | or am I incorrectly parsing your sentence | 10:22 |
| cjwatson | Something still has to be able to introspect enough of Python's data structures to generate the backtrace. | 10:23 |
| cjwatson | I don't know whether the dbg-ness is what allows us to do that. | 10:23 |
| ev | cjwatson: python application hangs, send SIGQUIT to it, signal handler does raise(YoullNeverCatchMe), apport python hook picks it up, job done. | 10:25 |
| ev | no need to know the internals of the python data structures | 10:25 |
| ev | mind you, I'm not saying we go with this approach for the reasons you raised | 10:25 |
| ev | just pointing out that I don't see why it needs dbg packages | 10:25 |
| cjwatson | I'm concerned about Python's habit of leaking signal handlers to subprocesses it calls. See SIGPIPE. | 10:25 |
| ev | indeed, I do recall the pain you faced from that in ubiquity :) | 10:26 |
| cjwatson | 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 |
| cjwatson | So I can't recommend that. | 10:26 |
| ev | hmm, indeed | 10:26 |
| cjwatson | (And yes, I'd misunderstood how you were planning to use the signal handler) | 10:27 |
| ev | 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:30 |
| ev | 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:31 |
| ev | 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:33 |
| cjwatson | Mm. (A small handful of the Python crashes will be useful even without this.) | 10:38 |
| lifeless | atfork? | 10:39 |
| lifeless | [ok, terrible idea] | 10:39 |
| ev | cjwatson: I'm not sure I follow | 10:39 |
| ev | hi lifeless | 10:40 |
| lifeless | hi ev, and bye, tis sleep time for me! :) | 10:40 |
| cjwatson | ev: Cases where the crash is in a C extension will be useful | 10:42 |
| ev | lifeless: enjoy! | 10:48 |
| ev | 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 |
| ev | but if the hang were in a c extension, that would indeed be useful to capture | 10:49 |
| ubottu | Launchpad bug 1006398 in whoopsie-daisy (Ubuntu) "Bypassing ptrace restrictions for errors from hanging applications" [Undecided,New] | 10:49 |
| ev | if I'm following your logic :) | 10:49 |
| cjwatson | ev: Right | 10:51 |
| === MacSlow is now known as MacSlow|lunch | ||
| pitti | infinity: there, have a building cups | 11:14 |
| ev | cjwatson: I've created bug 1015080 to track this, if we ever come up with a better solution. | 11:14 |
| ubottu | Launchpad bug 1015080 in Whoopsie "Retrieve Python tracebacks from hanging applications" [Wishlist,New] https://launchpad.net/bugs/1015080 | 11:14 |
| === MacSlow|lunch is now known as MacSlow | ||
| === achille_ is now known as achille | ||
| hippiehacker | 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:36 |
| jdstrand | infinity: libfile-fcntllock-perl: done | 12:37 |
| tumbleweed | 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:38 |
| hippiehacker | 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:52 |
| hippiehacker | The profiles could be easily shared / possibly digtially signed / and include the gpg for the dependent repos. | 12:57 |
| tumbleweed | hippiehacker: we'd like it if that problem could go away, but for now it's a reasonable solution | 12:58 |
| Riddell | 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 |
| hippiehacker | tumbleweed: is https://wiki.ubuntu.com/ThirdPartyApt the main thrust of where we are currently headed? | 13:12 |
| tumbleweed | hippiehacker: that's ancient, but it's what I'd want,yes | 13:16 |
| barry | 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:23 |
| ailo | 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 |
| ailo | Never done this before, but I do know qjackctl does exist in Sid | 13:25 |
| cjwatson | ailo: What's your full requestsync command line? | 13:26 |
| ailo | Just: requestsync qjackctl | 13:26 |
| ailo | I assumed options would be right by default | 13:26 |
| * cjwatson blinks | 13:27 | |
| Laney | https://launchpad.net/debian/+source/qjackctl/+publishinghistory | 13:27 |
| cjwatson | rmadison thinks it's present, though | 13:27 |
| Laney | it is present | 13:27 |
| Laney | but not according to LP | 13:28 |
| vibhav | ailo: requestsync -d sid qjackctl quantal | 13:28 |
| cjwatson | vibhav: No | 13:28 |
| vibhav | cjwatson: why? | 13:28 |
| cjwatson | vibhav: Won't help | 13:28 |
| vibhav | ah got you | 13:28 |
| vibhav | sorry :( | 13:28 |
| cjwatson | This is confusing; I have no idea why LP thinks that was removd | 13:29 |
| cjwatson | *removed | 13:29 |
| * cjwatson wonders if he can get at the importer logs anywhere | 13:30 | |
| cjwatson | 2012-06-18 04:24:30 ERROR Error processing package files for qjackctl | 13:30 |
| cjwatson | -> http://launchpadlibrarian.net/107864828/3nXxcopS5CWaeRIReI3Axcuek7g.txt (Error 25 unpacking source) | 13:30 |
| cjwatson | That ain't gonna help | 13:31 |
| xnox | barry: build: make -f debian/rules configure1-stamp && make -f debian/rules configure2-stamp ..... | 13:31 |
| xnox | barry: or you can simply add additional -stamp dependencies to the configure magic target | 13:31 |
| mtcomscxstart | Hello, can anybody help me with Glade? | 13:31 |
| cjwatson | So, it'll work if LP changes to unpack with DEB_VENDOR=debian | 13:32 |
| cjwatson | bug 901334 | 13:33 |
| ubottu | Launchpad bug 901334 in Launchpad itself "ExecutionError: Error 2 unpacking source raised by gina.py" [Critical,Triaged] https://launchpad.net/bugs/901334 | 13:33 |
| barry | 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 |
| cjwatson | (different source, same bug) | 13:33 |
| xnox | 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:34 | |
| * xnox used to love cdbs.... | 13:35 | |
| vibhav | Does resyncronize and merge mean the same thing | 13:35 |
| cjwatson | vibhav: Depends who's using the terms, but probably yes | 13:35 |
| ailo | cjwatson: So it's a launchpad bug? Doesn't this affect a whole range of packages? | 13:36 |
| vibhav | cjwatson: you | 13:36 |
| cjwatson | 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 |
| cjwatson | vibhav: Then yes | 13:36 |
| vibhav | ah thanks | 13:36 |
| cjwatson | 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:36 |
| ailo | cjwatson: Sounds great. I'm not in a hurry, no. Actually looking to backport that package to Precise later | 13:37 |
| ailo | Aha | 13:37 |
| vibhav | ncbi-rrna-data Pre-Depends: dpkg (>= 1.15.6) for xz compression support. | 13:37 |
| vibhav | Needed until after Ubuntu 12.04 LTS. | 13:37 |
| Laney | won't it still fail to unpack when we try to build it though? | 13:38 |
| vibhav | cjwatson: Do you know if we still need dpkg as a pre-depends in ncbi-tools6 for quantal? | 13:38 |
| Laney | I suppose it is more correct to have the failure there than in the importer | 13:39 |
| cjwatson | 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:39 |
| cjwatson | Laney: Probably, but at that point it'll actually be feasible to fix it by hand | 13:40 |
| vibhav | cjwatson: Thanks for the info | 13:40 |
| vibhav | slangasek: you there? | 13:41 |
| === BenC__ is now known as BenC | ||
| === zyga is now known as zyga-afk | ||
| stgraber | 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:53 |
| dobey | pitti: ping. any news about u1 MRE request? | 13:59 |
| pitti | 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:00 |
| dobey | that's not what the wiki says | 14:01 |
| dobey | "Changes can be approved via any single TB member" | 14:01 |
| dobey | is the wiki wrong again? :) | 14:02 |
| pitti | hm, I was not aware of that | 14:05 |
| seb128 | slangasek acked that when we discussed GNOME, he said one +1 was enough | 14:05 |
| pitti | changing policies sounds like a board decision, not a member decision to me | 14:05 |
| pitti | but so much the better | 14:06 |
| pitti | I'll reply to the list and add it to the MRE page | 14:06 |
| pitti | cjwatson: OOI, were you aware that new MREs can be approved by a single TB member? | 14:06 |
| pitti | it's from 2007 already: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions?action=diff&rev2=3&rev1=2 | 14:07 |
| dobey | right. 2007 is pretty old :) | 14:11 |
| dobey | pitti: thanks again. :) | 14:18 |
| cjwatson | pitti: Heh, I did know that once but I'd forgotten | 14:19 |
| vibhav | xnox: you there? | 14:25 |
| xnox | vibhav: yes | 14:25 |
| vibhav | xnox: PM? | 14:26 |
| xnox | ? | 14:26 |
| xnox | vibhav: what do you mean? | 14:27 |
| vibhav | xnox: Could I PM You? | 14:27 |
| vibhav | Private Message | 14:27 |
| xnox | yes.... you could have just done that straight away | 14:27 |
| === zyga-afk is now known as zyga | ||
| Yankees52 | !staff | 14:36 |
| ubottu | 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 |
| Yankees52 | !ops | 14:36 |
| ubottu | Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom! | 14:36 |
| ahasenack | 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 |
| ahasenack | I'm building a sru candidate for precise, upstream version 12.05 | 14:39 |
| ahasenack | current precise package is 12.04.3-0ubuntu1 | 14:40 |
| ahasenack | current quantal package is 12.05-0ubuntu1 | 14:40 |
| dholbach | ahasenack, this warning is safe to ignore - NMUs are a Debianism | 14:40 |
| ahasenack | dholbach: ok, it doesn't warrant an override I guess? | 14:41 |
| dholbach | no | 14:41 |
| ahasenack | ok, thanks | 14:41 |
| seb128 | 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 | 14:59 |
| bdmurray | seb128: I'll have a look | 15:19 |
| seb128 | bdmurray, thanks, let me know if anything is missing | 15:19 |
| bdmurray | seb128: well bug 938667 doesn't have an explicit test case | 15:24 |
| ubottu | 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:24 |
| seb128 | bdmurray, refresh | 15:26 |
| bdmurray | seb128: and this is supposed to supercede the existing one in -proposed? | 15:29 |
| seb128 | bdmurray, yes, the fix from the current one was incomplete and failed verification | 15:29 |
| seb128 | bdmurray, thanks ;-) | 15:32 |
| jdstrand | infinity: bug #1011597 - done | 15:51 |
| ubottu | Launchpad bug 1011597 in perl (Ubuntu) "[MIR] libfcgi-perl, libcgi-fast-perl" [High,Fix committed] https://launchpad.net/bugs/1011597 | 15:51 |
| xnox | SpamapS: do you mind if I rebuild drizzle for boost1.49? Or will you do bug 987575 really soon now ;-) | 16:00 |
| ubottu | 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 | 16:00 |
| === zyga is now known as zyga-afk | ||
| SpamapS | xnox: I'll upload drizzle ASAP | 16:49 |
| xnox | SpamapS: awesome =) | 16:50 |
| xnox | thanks | 16:50 |
| infinity | pitti, jdstrand: My heroes. | 17:07 |
| * xnox doesn't feel like breaking autofs today, unless I messed up my upstart state | 17:20 | |
| ahasenack | hi, can someone help me interpret this basic message? | 17:21 |
| ahasenack | "Good signature on /home/andreas/bzr/sru/12.05/precise/landscape-client_12.05-0ubuntu0.12.04.dsc. | 17:21 |
| ahasenack | Package includes an .orig.tar.gz file although the debian revision suggests | 17:21 |
| ahasenack | that it might not be required." | 17:21 |
| ahasenack | why would the .orig file not be required? | 17:22 |
| cjwatson | ahasenack: It's a case of tools being insufficiently clever. Ignore it. | 17:22 |
| ahasenack | it's not a native package | 17:22 |
| ahasenack | cjwatson: ok, thanks | 17:22 |
| cjwatson | if debian_version == '0.1' or debian_version == '1' \ | 17:22 |
| cjwatson | or debian_version == '1.1' or debian_version == '0ubuntu1': | 17:22 |
| cjwatson | include_orig = 1 | 17:22 |
| cjwatson | 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:23 | |
| cjwatson | I suspect it's not worth trying to add further band-aids | 17:24 |
| xnox | or to be honest 0ubuntu0* | 17:24 |
| xnox | =))) | 17:24 |
| stgraber | 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 |
| cjwatson | stgraber: this is in dput, not LP | 17:24 |
| xnox | I'm doing the fork count of automount and I get........ 9 | 17:25 |
| xnox | =( | 17:25 |
| cjwatson | LP *knows* whether the .orig is needed; dput is guessing | 17:25 |
| hallyn | 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 |
| hallyn | maybe not | 17:33 |
| cjwatson | Not AFAIK. | 17:33 |
| stgraber | hallyn: that works for the main branch (lp:ubuntu/lxc) but for user branches you need to have the series in tehre | 17:34 |
| cjwatson | I think you're thinking of lp:ubuntu/package -> lp:ubuntu/<development series>/package. | 17:34 |
| stgraber | *there | 17:34 |
| hallyn | i see | 17:34 |
| hallyn | thanks | 17:34 |
| === arges is now known as arges-lunch | ||
| pp7 | why is there a small thin line just under the titlebar when i move windows around? | 18:24 |
| SpamapS | 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:58 |
| infinity | SpamapS: It should happen eventually, so we're not carrying 17 versions of GCC, it's certainly not world-endingly urgent. | 18:59 |
| SpamapS | 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 | 18:59 |
| SpamapS | infinity: 4.4 has been offered up as an alternative, apparently it has to be kept for some reason | 19:00 |
| infinity | I'm not sure that's much of an alternative. :P | 19:01 |
| infinity | SpamapS: I don't see anything obviously keeping gcc-4.4 in either, but maybe I'm missing it. | 19:03 |
| SpamapS | infinity: Yeah, I think the right answer is actually to just disable the optimizations for i386 SSL | 19:05 |
| SpamapS | infinity: upstream has it as a Serious / Critical issue so they will fix soon enough. | 19:05 |
| SpamapS | in the mean time, i386 users will just have slow SSL. :-P | 19:06 |
| infinity | SpamapS: Oh, boost depends on gcc-4.4. Hilarious. | 19:06 |
| SpamapS | infinity: of course it does | 19:06 |
| SpamapS | boost depends on anger | 19:06 |
| SpamapS | and frustration | 19:06 |
| SpamapS | and pixie-dust I think | 19:06 |
| SpamapS | should rename it to dementor | 19:06 |
| infinity | 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 |
| infinity | SpamapS: And I hear we care about ARM now. | 19:06 |
| infinity | SpamapS: You could use 4.4 on i386, and 4.7 everywhere else? | 19:07 |
| infinity | SpamapS: That would be an acceptable solution to me for now. | 19:07 |
| lifeless | infinity: caring, whats that? | 19:07 |
| SpamapS | infinity: I wonder if it will make x86 suck a bit more too tho | 19:07 |
| infinity | SpamapS: A tiny bit, perhaps, but not as much as disabling SSL optimisation, I imagine. | 19:07 |
| SpamapS | infinity: if SSL is 4x slower, but the rest of the server is 5% faster, I'd prefer that. | 19:08 |
| infinity | 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 |
| SpamapS | infinity: SSL is a niche case for mysqld | 19:08 |
| infinity | But, you could always test, I suppose. | 19:08 |
| infinity | Your call. | 19:08 |
| SpamapS | I'll take your word for it. This is i386 after all | 19:08 |
| infinity | Just saying that if you do decide to downgrade compilers, please only do it on i386. | 19:08 |
| SpamapS | yeah that makes sense | 19:08 |
| Daviey | slangasek: hey, so what is blocking precise nova sru? | 19:12 |
| Daviey | slangasek: we sort of left the conversation unfinsihed yesterday. | 19:13 |
| === BenC__ is now known as BenC | ||
| slangasek | 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:17 |
| Daviey | slangasek: why is nova wedged on this, but the other openstack components were accepted? | 19:19 |
| Daviey | slangasek: verification of the whole suite, were intended to be done coordinated. | 19:19 |
| slangasek | Daviey: I don't know the openstack components by package name; but that question is better addressed to whoever did the accept? | 19:19 |
| slangasek | 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 |
| infinity | 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 |
| Daviey | 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 |
| infinity | Daviey: And slangasek beat me to that. | 19:21 |
| Daviey | nova certainly has more changes, but i am not satisfied that the other components had fixes soley targeted towards issues that impact us. | 19:23 |
| slangasek | 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:25 |
| Daviey | slangasek: okay, bug 978907 is a bug fix for SUSE which is in glance currently in -proposed that was accepted. | 19:27 |
| ubottu | Launchpad bug 978907 in glance (Ubuntu) "[SRU] capture-output fails in glance-control" [Undecided,In progress] https://launchpad.net/bugs/978907 | 19:27 |
| === arges-lunch is now known as arges | ||
| Daviey | If your demand is accurate, we should probably pull glance out of -proposed. | 19:27 |
| Daviey | zul: can you rekindle the mail to TB as a matter of urgency please | 19:28 |
| zul | Daviey: yeah | 19:28 |
| slangasek | 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:34 |
| slangasek | sorry, I missed a decimal point | 19:35 |
| slangasek | .4% :P | 19:35 |
| slangasek | though strangely most of that diff is the addition of a ChangeLog file, heh | 19:36 |
| Daviey | 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:37 |
| slangasek | Daviey: where has he said that? | 19:40 |
| Daviey | 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 |
| ubottu | Launchpad bug 651875 in bind9 (Ubuntu Lucid) "Bind 9.7.0-P1 validation errors" [Medium,Confirmed] | 19:42 |
| slangasek | do you intend to only ask for one? | 19:43 |
| Daviey | 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 |
| Daviey | slangasek: today, i plan to only ask once. | 19:43 |
| slangasek | I don't see how this is at all analogous to what happened in oneiric | 19:43 |
| slangasek | the SRU *was* accepted into oneiric, and then there was no follow-through | 19:44 |
| Daviey | slangasek: numerous contributing factors lead to it not being successful. | 19:44 |
| Daviey | slangasek: it was accepted yes, but superseeded by -security, no? | 19:44 |
| slangasek | Daviey: well, and? Once superseded by security, shouldn't the uploader have merged the security changes and re-uploaded? | 19:45 |
| slangasek | --> no follow-through | 19:45 |
| Daviey | slangasek: no, it's not as simple as that. | 19:46 |
| slangasek | 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:47 |
| Daviey | 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:48 |
| slangasek | what prior approval? | 19:49 |
| slangasek | someone on the TB proposed a trial SRU in oneiric, which for all intents and purposes was a failure | 19:49 |
| Daviey | slangasek: the oneiric MRE wanted to see a 'one off first' | 19:49 |
| Daviey | this is the new, 'one off'. | 19:49 |
| micahg | infinity: FWIW, the libboost and libusb deps on gcc-4.4 seem to be alternate deps | 19:57 |
| infinity | micahg: Ahh, indeed. That's rather unclever. | 19:58 |
| micahg | infinity: the thing is, Debian doesn't seem to have plans to remove it ATM, so I wonder what they're keeping it for | 19:59 |
| iamfuzz | IIRC the automatic installation of recommends came in Lucid. Is this behavior enabled on Ubuntu Server installs as well or just desktop builds? | 20:00 |
| infinity | iamfuzz: It's at the apt level. | 20:00 |
| infinity | iamfuzz: (So yes, servers too) | 20:01 |
| iamfuzz | infinity, cool, thanks, I thought I had remembered a discussion where a conf file was changed via the installer as serve rpeople didn't like recs getting yanked in by default | 20:01 |
| iamfuzz | probably just losing my mind as usual | 20:01 |
| infinity | iamfuzz: Nah, we did go on the warpath long ago to make sure that none of the recommends in main were silly, though. And drop some to suggests. | 20:03 |
| infinity | iamfuzz: Of course, if people prefer to not pull in recommends, they can change their apt configs (or run apt-get --no-install-recommends) | 20:03 |
| micahg | or aptitude -R | 20:04 |
| iamfuzz | infinity, I'm actually a fan of it | 20:06 |
| slangasek | if people prefer that, they really shouldn't | 20:08 |
| slangasek | ;) | 20:08 |
| iamfuzz | slangasek, prefer having recommends installed by default? | 20:09 |
| slangasek | prefer to not pull them in | 20:10 |
| slangasek | the definition of Recommends in policy is such that anyone excluding them by default is inviting trouble | 20:10 |
| iamfuzz | indeed, but I find many Debian "purists" annoyed by it | 20:10 |
| iamfuzz | not a strict dep, so don't install it without my asking | 20:11 |
| bdmurray | infinity: you'd said link to the build pages with sru-sccept? https://bugs.launchpad.net/ubuntu/+source/cron/+bug/794082/comments/7 | 20:25 |
| ubottu | Launchpad bug 794082 in cron (Ubuntu Lucid) "cron ignores /etc/default/cron" [Undecided,Triaged] | 20:26 |
| === pjdc_ is now known as pjdc | ||
| === jbicha is now known as Guest87840 | ||
| === vibhav is now known as Guest7599 | ||
| === BenC__ is now known as BenC | ||
| === jedney is now known as JonEdney | ||
| === chu_ is now known as chu | ||
| SpamapS | lifeless: hey, would you be able to have a peek at bug #978356 .. or perhaps know a squid person who I can talk to about it? | 22:19 |
| ubottu | Launchpad bug 978356 in squid3 (Ubuntu) "squid3 gets killed at startup with dnsmasq and no networkmanager" [Low,Confirmed] https://launchpad.net/bugs/978356 | 22:19 |
| barry | mterry: hi. i have to leave in a bit, but i will look again at your branch later tonight. | 22:21 |
| mterry | barry, sure! I'll hit up mvo tomorrow about tests | 22:21 |
| barry | mterry: sounds good, and i'll respond to your responses tonight too. no worries on the indents. u-m is on my hit list for major refactoring, though with all the py3 work i doubt i'll get to it this cycle. ;) | 22:22 |
| mterry | barry, if you liked reviewing that branch, you'll live the 5 more I have chained on its back! | 22:23 |
| mterry | :) | 22:23 |
| mterry | s/live/love/ | 22:23 |
| barry | :-D | 22:23 |
| barry | mterry: i'll rubber stamp any change that has more red than green :) | 22:23 |
| mterry | :) | 22:24 |
| barry | anyway gotta run. ttyl | 22:24 |
| === salem_ is now known as _salem | ||
| RAOF | stgraber, hallyn: Ping, re libvirt SRU. | 22:43 |
| stgraber | RAOF: pong | 22:44 |
| RAOF | So, you've probably noticed that I've rejected the libvirt SRU; primarily because the postrm was doing bad things, but I'd also like to know what the impact of setting bind-interfaces is. | 22:46 |
| stgraber | it's technically hallyn's SRU so I didn't actually look at that SRU at all but I indeed created that dnsmasq workaround for lxc initially that found its way to quantal and is being SRUed for lxc and libvirt in precise | 22:47 |
| lifeless | SpamapS: hi | 22:47 |
| stgraber | basically, the problem is that dnsmasq (not to be confused with dnsmasq-base) binds 0.0.0.0, preventing any other dnsmasq daemon from starting | 22:48 |
| stgraber | bind-interfaces instead makes it bind all the interfaces (available at startup time) individually | 22:48 |
| stgraber | and the "except" lines that we're adding for lxc and libvirt prevent the main dnsmasq daemon from binding interfaces where we spawn our own dnsmasq instance | 22:49 |
| stgraber | this fixes a whole lot of bug report we've been getting for both lxc and libvirt (and I'm hoping to soon have the same trick in Network Manager, still need to talk to cyphermox) | 22:50 |
| RAOF | Ok. And dnsmasq won't bind to interfaces that appear after it's started, right? What can be the consequences of that?\ | 22:50 |
| RAOF | Presumably the worst case is something like: a user plugs in a 3G modem and doesn't get DNS on it? | 22:51 |
| stgraber | right, that's the one downside of that change though dnsmasq starts late in the boot sequence so it's unliekly to miss one of the builtin network cards | 22:51 |
| stgraber | and it's pretty unlikely that you want a dns/dhcp server to automatically bind a usb interface you'd plug post-boot | 22:51 |
| stgraber | so yeah, if a user plugs a 3G modem they won't get a DNS server binding to it, but I can't really think of a good reason why they'd like a server to bind to it in the first place :) | 22:52 |
| lifeless | SpamapS: replied in the bug. | 22:52 |
| stgraber | that config change will only impact people who have both dnsmasq and lxc or libvirt installed. That's a very small subset of people as none of these are installed by default (we installed dnsmasq-base which doesn't contain the dnsmasq init script) | 22:53 |
| stgraber | and these users already have a 50% chance of not getting dnsmasq started at boot time | 22:53 |
| stgraber | (the other 50% is the case where they have dnsmasq but not a working lxc or libvirt) | 22:54 |
| SpamapS | lifeless: I filed a bugzilla ticket.. will that have a similar effect as emailing squid-dev ? | 22:54 |
| RAOF | Oh, because lxc/libvirt's dnsmasq claim the interface? | 22:54 |
| SpamapS | lifeless: meanwhile revisiting it made me realize we can work around the issue by just respawning squid if it dies via SIGHUP | 22:55 |
| stgraber | RAOF: we currently have libvirt, lxc and network-manager that all spawn their own dnsmasq. They all use bind-interfaces and only bind their interface (respectively virbr0, lxcbr0 and lo) | 22:55 |
| stgraber | RAOF: the problem is that if they try to do so after the dnsmasq init job is started, they can't as it's already binding 0.0.0.0 on all interfaces | 22:55 |
| stgraber | and by chance they start before the dnsmasq init job, then dnsmasq itself will fail as it can't bind all interfaces (because some are already taken by lxc/libvirt/network-manager) | 22:56 |
| andersk | Today’s dpkg upload broke my quantal multiarch system. I filed bug 1015329. | 22:57 |
| ubottu | Launchpad bug 1015329 in dpkg (Ubuntu) "dpkg: error: file triggers record mentions illegal package name `libgtk2.0-0' (for interest in file `/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules'): ambiguous package name 'libgtk2.0-0' with more than one installed instance" [Undecided,New] https://launchpad.net/bugs/1015329 | 22:57 |
| lifeless | SpamapS: close enough | 22:57 |
| stgraber | so while not perfect, I think that bind-interfaces trick is the best way we have to force all dnsmasq instances to bind only what they actually need (where dnsmasq itself is considered to "need" everything but the libvirt/lxc/NM interfaces) | 22:57 |
| lifeless | SpamapS: that said, the race still exists with your patch | 22:57 |
| lifeless | SpamapS: you actually need to either a) set SIGHUP to ignore as you spawn, or b) check for something (e.g. the pid file) before assuming you can SIGHUP it. | 22:58 |
| === Guest87840 is now known as jbicha | ||
| lifeless | SpamapS: mmm, I might be wrong, if you are setting it before the pid file is written, and the script gets the pid by reading the pidfile. | 22:59 |
| RAOF | stgraber: I don't suppose there's a way to get the best of both worlds? Have dnsmasq ignore the interfaces you need, *and* pick up new interfaces? | 23:01 |
| RAOF | For example: how disruptive is restarting dnsmasq? | 23:01 |
| * xnox ---> this made my day "svn log can now print diffs" | 23:02 | |
| * xnox it's --diff not -p | 23:02 | |
| stgraber | RAOF: I think we might be able to do something like that using an upstart job triggering on net-device-added and net-device-removed and sending SIGHUP to dnsmasq (assuming dnsmasq binds to new interfaces in such case) | 23:04 |
| slangasek | svn --i-want-to-be-a-real-boy^H^H^Hvcs | 23:05 |
| stgraber | RAOF: but that's somewhere on my nice to have list of dnsmasq stuff for 12.10, not something I consider critical for the 12.04 SRU | 23:05 |
| xnox | infinity: thank you for dpkg! dep-waits unleashed =) | 23:05 |
| stgraber | RAOF: mostly because dnsmasq itself isn't supported (universe package). We care a lot more about libvirt/lxc/network-manager so improving dnsmasq is pretty low on the todo. | 23:06 |
| infinity | xnox: Mmhmm, and https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1015329 caused, apparently. | 23:06 |
| ubottu | Launchpad bug 1015329 in dpkg (Ubuntu) "dpkg: error: file triggers record mentions illegal package name `libgtk2.0-0' (for interest in file `/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules'): ambiguous package name 'libgtk2.0-0' with more than one installed instance" [Undecided,New] | 23:06 |
| xnox | slangasek: one of these days PAPT PMPT will change to a real vcs | 23:06 |
| slangasek | unfortunately it'll probably be the one that's real but ugly ;) | 23:06 |
| RAOF | stgraber: It would make *me* happier with the SRU if it changed behaviour for only libvirt, lxc, network-manager :). I wonder if SpamapS would like to weigh in? | 23:06 |
| xnox | infinity: nah =) I only care about unblocking packages in boost1.49 transition. If only cjwatson does aptitude merge in his sleep ;-) | 23:07 |
| xnox | only 10 left ! | 23:07 |
| stgraber | RAOF: well, as it is the SRU will only change the behaviour for users of libvirt, lxc and network-manager as it's a change in these packages and not in dnsmasq itself. | 23:08 |
| * xnox or 15 if including otherwise marked as dealt with | 23:08 | |
| cjwatson | xnox: hopefully tomorrow | 23:08 |
| xnox | cjwatson: \0/ yeah =) | 23:09 |
| xnox | cjwatson: hopefully tomorrow i will train autofs' upstart job to work after merging new release! | 23:09 |
| * xnox new release == merging debian | 23:09 | |
| stgraber | RAOF: oh, and I apparently forgot to mention that on top of the boot time race between the various dnsmasqs, this bug also prevents someone from installing lxc, libvirt or network-manager on a system that's already running the system wide dnsmasq. | 23:10 |
| slangasek | we should probably put an archive hold on the new dpkg for bug #1015329 | 23:10 |
| ubottu | Launchpad bug 1015329 in dpkg (Ubuntu) "dpkg: error: file triggers record mentions illegal package name `libgtk2.0-0' (for interest in file `/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules'): ambiguous package name 'libgtk2.0-0' with more than one installed instance" [Critical,Triaged] https://launchpad.net/bugs/1015329 | 23:10 |
| RAOF | stgraber: Right, but what I meant is that it (potentially) changes the behaviour on interfaces which aren't owned by libvirt, lxc, and network-manager. But dnsmasq *is* in universe, so the bar for convincing me that it'll be too much effort to avoid that is lower than for a main package :) | 23:10 |
| * xnox off to sleep while buildds do their chugga chugga | 23:11 | |
| stgraber | RAOF: oh, and btw, lxc with the exact same fix was allowed into -proposed a week ago :) | 23:11 |
| TheMuso | @pilot in | 23:13 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso, pitti | ||
| SpamapS | lifeless: ACK, I see that the patch is probably not entirely sufficient. | 23:13 |
| SpamapS | lifeless: just narrowed the window of vulnerability | 23:14 |
| stgraber | RAOF: I guess my point of view is that these systems are already broken, so anything we do will make them less broken. If these people, after getting the initial fix through lxc, libvirt and network-manager get into the issue where dnsmasq doesn't bind some interfaces, we can always look at SRUing dnsmasq to introduce the upstart job trick (or an ifupdown hook, or udev hook, ...) | 23:14 |
| RAOF | stgraber: That makes sense. | 23:15 |
| RAOF | Thanks. | 23:15 |
| dupondje | slangasek: just hit that bug also now :( just when I decided to upgrade my system :P | 23:17 |
| slangasek | dupondje: info on the bug about how to manually recover; working now on mitigating | 23:17 |
| dupondje | 'by manually editing /var/lib/dpkg/triggers/File' :) doesn't really say what to change :) | 23:18 |
| andersk | I had to replace libgtk2.0-0 with libgtk2.0-0:amd64 in the second column, then repeat for a few other packages as the error message changed. | 23:18 |
| dupondje | lets see | 23:20 |
| dupondje | seems working | 23:20 |
| === jedney is now known as JonEdney | ||
| dupondje | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667843 | 23:24 |
| ubottu | Debian bug 667843 in apt "dpkg: error "ambiguous package name" during upgrade to multiarch package" [Important,Fixed] | 23:24 |
| YokoZar | !regression-alert | 23:26 |
| YokoZar | https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1015337 --- apt-get install dansguardian started failing with the new clamav update | 23:26 |
| ubottu | cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive | 23:26 |
| ubottu | Launchpad bug 1015337 in clamav (Ubuntu) "clamav-base fails configure with `/usr/share/doc/clamav-base/examples/main.cvd': No such file or directory" [Undecided,New] | 23:26 |
| YokoZar | Good afternoon folks :) | 23:26 |
| slangasek | dupondje: bug description updated with a script to rescue the system | 23:34 |
| YokoZar | Actually, my regression alert is an ubuntu-security regression it seems. | 23:36 |
| slangasek | andersk: thanks for the bug report - I've updated the bug description now with a script that I believe should DTRT for all users, do you want to review? | 23:37 |
| dupondje | great :) | 23:39 |
| mdeslaur | YokoZar: hi! clamav upstream no longer bundles the virus definitions in the main package | 23:48 |
| mdeslaur | YokoZar: oh, switching to #ubuntu-hardened | 23:49 |
| andersk | After fixing the triggers file, I was in a state where apt didn’t understand that any foreign packages were installed, which is why I did ‘dpkg --add-architecture’. | 23:49 |
| andersk | It’s possible that dpkg.postinst would have taken care of that, but I’d have to think carefully about the ordering of events or try to test it again. | 23:50 |
| slangasek | andersk: yes, there's an unfortunate window where dpkg has forgotten about the foreign architectures, but 'dpkg --configure -a' was definitely sufficient here to fix it | 23:51 |
| slangasek | so provided you're not unpacking foreign-arch packages at the same time as dpkg itself, it will definitely work; and if you *are* unpacking foreign-arch packages at the same time as dpkg, I'm not sure what happens, but definitely nothing unrecoverable | 23:52 |
| andersk | I also reinstalled the affected packages for good measure. For that I had to delete a bunch of broken symlinks: /usr/share/doc/libglib2.0-0/{README.gz,changelog.Debian.gz,AUTHORS,NEWS.gz}. But that might be an unrelated bug from long ago. | 23:52 |
| andersk | In fact, I still have several such broken symlinks, e.g. /usr/share/doc/libfuse2/changelog.Debian.gz is a symlink to itself. | 23:54 |
| slangasek | I'm reasonably certain that's unrelated | 23:56 |
| slangasek | given that I had that broken symlink on my system before upgrading dpkg | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
