[00:26] Sweetshark: I'd suggest discussing with tyhicks about ecryptfs and how likely it is to be impacting this bug [00:58] micahg: Good suggestion - I've read through it and don't have any good ideas about what eCryptfs could be doing incorrectly [00:59] Digging in deeper is next on my todo list [00:59] tyhicks: sweetshark is in UTC +2 I believe, maybe you could chat with him at some point [01:00] Sweetshark: My opinion (which I've already given you in private before) is that you've been trying too aggressively to "close the ticket" and get it off your radar. When what should really be done is analyze and fix the problem. [01:00] Sweetshark: Case in point: Your recent setting to invalid state for the office package when no matter what ecryptfs does or doesn't do, a program should never segfault. Or your closing as wontfix without any explanation. You're doing better with the latest comments and explanations. [01:00] Sweetshark: thank you for the work you're doing. Much appreciated. [01:01] * Laibsch is one of the affected people and in UTC+8 [01:02] Laibsch: hello - upstream eCryptfs kernel maintainer here [01:02] I know [01:02] I'm the 50G/140G false positive guy ;-) [01:02] Laibsch: I tend to agree - since eCryptfs isn't oopsing or falling completely on its face, it sounds like something that could be handled better in userspace [01:02] so we meet again (we can talk privately if you want) [01:02] Laibsch: ah, that's right :) [01:04] the problem is 100% reproducible for me. So, if you can cook up something to collect data, I'm here. [01:04] Laibsch: I've looked through the report and traces provided and I didn't see much to work off of [01:05] Laibsch: I think I'm going to need to reproduce it locally (I haven't had a chance to try yet) and then start poking from there [01:05] Laibsch: I really appreciate the offer and will keep it in mind [01:06] tyhicks: Yes, best is of course if you can reproduce it locally. But apparently Sweetshark had some trouble doing that. [01:12] tyhicks: I find that Ian guy a bit of a pain in the ... but he says he can reproduce file corruption (comment 53). Whether that's the root cause of the crashes or even a false claim, I don't know. But maybe he can give you some valuable data as well on supposedly ecryptfs-induced file corruption. [01:13] Laibsch: Yeah - just read that comment... I'll definitely have to follow up on that claim [01:13] would it help if I ran Office through valgrind? [01:14] * Laibsch wonders what upstream discussion Sweetshark was referring to [01:15] probably http://nabble.documentfoundation.org/Multiple-issues-with-cppuhelper-source-exc-thrower-cxx-td2992234.html [01:15] slangasek, heres a strange (to me) console log http://paste.ubuntu.com/695394/ === plars-afk is now known as plars [02:25] I wonder, how do I get do-release-upgrade to _NOT_ run screen? [02:26] why would you want that? [02:26] because the serial console hates screen [02:26] slangasek, ok. i opened bug 856984. i know whats wrong, and *a* fix is fairly straight forward. [02:26] Launchpad bug 856984 in isc-dhcp (Ubuntu) "dhclient-script attempts to write /etc/resolv.conf before it is writable" [Undecided,New] https://launchpad.net/bugs/856984 [02:26] seems that removing screen fixes the issue [02:26] nice [02:31] /c/c === Amaranthus is now known as Amaranth [04:30] Man, where's barry when you need him. [04:30] * ScottK wanted to see him headdesk: https://github.com/whymirror/unholy [05:28] ScottK: That's vile. And a thing of beauty. [05:28] * ScottK thinks barry will love it. [05:29] Or he will claw his eyes out. [05:29] reminded me of this: http://www.linuxjournal.com/article/9282 [05:29] Entertaining either way. [05:31] you guys have seen perl's Inline::C and Inline::Python, right? [05:31] (well, s/perl/CPAN/) [05:31] Inlining is a bit different than this python/ruby translation madness. [05:32] I've *used* Inline::Python. [05:32] I'm reminded of Facebook's PHP-to-C compiler. [05:32] It's utter crack. [05:32] infinity: but similarly terrifying :) [05:35] good morning [05:35] Good morning. [05:35] didrocks: Bad news on the Qt front ... [05:35] It looks like it's going to fail on armel (already did on powerpc) [05:36] With that bit of joy, I'm off to bed. [05:36] Have a nice $TIME_OF_DAY. [05:36] ScottK: argh, ok, I'll try to have a look [05:36] Thanks. [05:36] ScottK: have a good night :) === Quintasan_ is now known as Quintasan [06:09] doko_: libdb-ruby was entirely superseded by ruby-bdb, it just needs decruft to disappear === eyes_ is now known as EyesIsServer [07:14] good morning [07:57] lucas, right seen now. but the source is still in unstable too (and libcairo-ruby) === tkamppeter__ is now known as tkamppeter [08:29] pitti, hi [08:38] mvo, slangasek: I think the break is correct (bug 853688), but I could remove it as well, if it cannot be addressed otherwise [08:38] Launchpad bug 853688 in gcj-4.4 (Ubuntu Oneiric) "Natty to Oneiric - failed to calculate the upgrade with gcj-4.4-jre installed" [High,Triaged] https://launchpad.net/bugs/853688 [08:40] doko_: sorry, I haven't had a chance yet to properly look at this [09:20] SpamapS, barry: could you have a look at bug 771121? the easiest way would be to disable the python3 package [09:20] Launchpad bug 771121 in gearman-interface (Ubuntu Oneiric) "gearman-interface version 0.13.2-2build2 failed to build on amd64 with GCC-4.6/oneiric" [High,Confirmed] https://launchpad.net/bugs/771121 [09:21] pitti: hallo, I was wondering if you have a few minutes for some language packs? [09:24] TLE, think he's on vacation currently [09:25] I have uploaded a new HPLIP package which fixes bug 560849 with a tiny patch. The package hangs in the "wait for approval" queue. Can someone approve it (is beta2 not unfrozen yet?). [09:25] Launchpad bug 560849 in hplip (Ubuntu) "hpfax crashed with NameError in bug()" [Undecided,Fix committed] https://launchpad.net/bugs/560849 [09:25] tkamppeter, we don't unfreeze [09:25] bryceh: ok, do you know who might be filling in for him on stuff like copying newly generated language packs to a proposed repository? [09:25] tkamppeter, uploads until Oneiric need to get reviewed [09:27] seb128, do I need to do anything special for the uploads to get reviewed? [09:28] tkamppeter, no [09:28] tkamppeter, they will just be regularly reviewed when release team member look at the queue [09:28] TLE, seb128. [09:29] bryceh: thanks [09:29] heh [09:29] ahh, you got volouteered there [09:29] *G* [09:30] TLE, better to wait for pitti to be back, he will be back for monday for sure but it's likely he will be around before that so if you need anything important drop him an email I guess [09:31] well, we are trying to release language pack updates according to a schedule, so that translators know what they have to aim for, and that isn't much good if we keep postponing them. In any case, I'll talk to dpm first and see what he thinks and then maybe I'll be back later [09:32] seb128: ^" [09:32] TLE: ok, if pitti get online during the day I will ping him about it, I've no real clue how the langpacks work and how to do the copy so I would prefer for him to do it [09:34] I already pinged him, I can talk to him about it and them we'll bug you if necessary ;) [09:34] TLE, let's have a chat later on in the day about langpacks if that works for you [09:34] dpm: absolutely, in the office all day [09:34] cool, thanks TLE [09:35] no worries [10:10] pitti: bad pittivi FFe ;-P [10:38] pitti: Any idea why the libvirt package in lucid-proposed hasn't propagated to -updates? [10:41] bug 823638 hasn't been marked v-done [10:41] Launchpad bug 823638 in libvirt (Ubuntu Natty) "Please put comment in /etc/default/libvirt-bin or remove it from the .deb" [Undecided,Fix committed] https://launchpad.net/bugs/823638 [10:42] which may be trivial from that bug description; I'm just reading the dashboard [10:43] Oh, I see. [10:46] janimo: The glmark2 package you uploaded seems very much like it's not just bug fix only, so I'm going to reject it. Please coordinate with the person you're sponsoring for (Alexandros Frantzis) and follow the FFe process. [10:48] Any AA's around that can promote an approved MIR please? [10:49] ScottK, it is sponsoring by alf_ via pm request this morning [10:50] janimo: Right. I'm not saying who needs to fill out the FFe, but you're the one that's supposed to know about such things. [10:50] ScottK, honestly had no idea FFE applies to universe [10:51] OK. [10:51] It applies to the entire archive. It always has. [10:51] Lesson learned I guess. [10:51] always? Even for GNOME components? [10:51] Everything that doesn't have a standing exception. [10:52] janimo: Are you thinking of feature defintion freeze? [10:52] That doesn't apply to universe. [10:52] Daviey, not sure about the naming. Thinking along the lines, of blanket exception for universe packages where upstream collaborates closely with Ubuntu (e.g linaro in this case) and where they know what they're doing [10:53] soren, yes, I assumed there was a standing exception for universe [10:54] https://wiki.ubuntu.com/StandingFeatureFreeze [10:54] Hardy :) [10:54] janimo: No, standing applies to packages or groups of, not whole components. :o [10:55] Daviey, what does it take to add a new group there? A lot of Linaro stuff - on a different schedule than ours - keeps happening after our freezes. For ARM users and devs it helps to get access to these via the official archives [10:56] not talking about landing new kernels/bootloaders which can break stuff, but universe apps [10:57] janimo: A blanket standing exception to the release team via a bug of nominated packages, and who is responsible for making sure they are kosher. [10:58] ScottK, https://bugs.launchpad.net/ubuntu/+source/glmark2/+bug/857279 [10:58] Ubuntu bug 857279 in glmark2 (Ubuntu) "FFE for Oneiric" [Undecided,New] [10:58] janimo: https://wiki.ubuntu.com/FreezeExceptionProcess should be a good guide [10:59] janimo: That bug really needs more detail [10:59] asac, rsalveti see what Daviey says above. You may want to add this to the discussion at UDS [10:59] janimo: freeze doesn't mean you can't upload stuff, it just means it requires some thought [10:59] Linaro does too much core stuff for me to be comfortable with a standing feature freeze exception for everything they do [11:00] for universe applications, I'd have thought that we could easily just work case-by-case? [11:01] cjwatson, no core stuff, no kernel/bootloader/X is sane to upload with features at this point. I was talking about blanket for the sundry apps/tests/tools they do that affect hardly anyone but ARM users [11:01] Daviey, I'll ask alf I merely sponsored him, have no idea what is in the new release [11:02] janimo: Are you talking features or bugs? [11:03] I mean, if you are fixing FTBFS's on arm for example, that wouldn't need a FFe. [11:03] Daviey, features but for fringe apps [11:03] sure, bugs I know [11:03] soren: hi! are you currently testing the suggested patch at https://bugs.freedesktop.org/show_bug.cgi?id=41059 ? [11:03] Freedesktop bug 41059 in Driver/intel "XRANDR operations very slow unless (phantom) HDMI1 disabled" [Major,New] [11:03] Daviey, universe apps which do not affect non-ARM images [11:04] and mostly developer stuff [11:05] janimo: Something that adds weight is that those working on it will /use/ it before release to spot regressions, and committing to fixing them. [11:06] for example, we decided not to update to the latest qemu as we knew that if it did go bang - we'd not have the time/resources to fix it. [11:06] although slangasek is thinking about doing that for qemu-linaro :) [11:06] Daviey, I sure hope Linaro uses their tools. They use PPA's a lot so they are not much pressured to upload or do not know the hops that need to be jumped through [11:07] Daviey, QEMu breaking would mean the whole cloud/server things being affected, very different :) [11:07] glmark2 having a regression? pfft [11:07] anyway something to discuss with the Linaro guys at UDS [11:08] janimo, well, its our job to care for the archive and get the bits into it [11:08] i dont think there is much to discuss [11:08] Yeah, too much policy/hoops can make people choose not to bother :(.. Having done a few FFe's, it becomes a reasonably fast process.. it's a reasonable balance atm, i feel. [11:08] they move at a fast pace with their development, monthly releases and PPAs, need to find a good match between their interrests and the fact that we'd also like to ship ARM stuff that is not too stale [11:08] htorque: Not really :( If someone could toss me a kernel image that I could try, then sure. I'm a bit too busy to sort that out myself right now :( [11:08] janimo, in the past we simply used to have a team member in the universe release team [11:08] we should probably revive that [11:09] ogra_: arm or linaro? [11:09] Daviey, ?? [11:09] ogra_, 1) so we could just approve all our FFEs? Nice 2) You are not talking me into becoming that person [11:09] lol [11:09] Daviey, i'm ubuntu-arm [11:10] ogra_: "in the past 'we' had a tam member", who is we? [11:10] team* [11:10] * ogra_ doesnt talk for linaro [11:10] I don't think we should have people who are in ubuntu-release just to approve their team's exceptions [11:10] cross-fertilisation and cross-checking is extremely valuable [11:10] soren: ok, in that case i'll test it with 3.1-rc7 here. just hope my tailored config is enough to reproduce the bug. don't wanna build a full ubuntu-config kernel. [11:11] cjwatson, I forgot a smiley there in 1) [11:11] cjwatson, well, but having the people knowing the code also reviewing it makes everything a bit easier [11:11] ogra_: certainly having people available is helpful, but I will definitely nack any attempt to add people to the release team simply in order to work around exception requirements [11:11] (and not only knowing but being able to verify on HW) [11:12] cjwatson, i didnt intend that with the suggestion [11:12] the release team is the Ubuntu release team, not just the Ubuntu ARM release team - I expect team members to be concerned for the health of the project as a whole [11:12] we used to do it in the past simply because the process was faster [11:12] not because we handled the execptions more losely [11:13] ogra_: It should be possible to demostrate a good level of confidence to someone who doesn't understand the issue IMO. [11:13] Yeah, i don't think ogra_ is suggesting bypass of process. [11:13] oh, sure, i dont say i mistrust anyone :) [11:14] I trust the people involved, but I've found for myself that when you're the person who's acting for the release team for your own team's requests, there is a lot of psychological pressure to say yes despite reservations because you know that your teammates have put a lot of work into this [11:15] Laney, janest-core, remove or fix it? [11:15] a degree of separation helps to avoid that and can actually reduce stress [11:15] cjwatson, true. [11:15] but it also slows down the process since you need to work yourself into code other know in and out [11:15] *others [11:16] I think that's an acceptable price to pay [11:16] anyway, reviewing freeze exceptions doesn't mean a complete code review [11:16] indeed [11:17] it's more an assessment of its likely impact and sanity [11:17] which an arm person can judge better than a non arm person in this case [11:17] I do not in general agree [11:18] if the ARM person can't explain it in a way that's clear enough for a non-ARM person to understand, I find that questionable [11:18] and non-ARM people are perfectly capable of judging when things essentially only affect ARM and when they may affect other architectures too [11:18] and acting accordingly [11:19] well, you save the need for the explanation in that case, indeed one asking for a freeze exception should always be able to explain it to non arm people [11:19] (and thats not arm specific at all) [11:19] Inverse, unless the package only builds on arm target - can they measure the impact for other arches with confidence? [11:19] I don't agree that saving the need for the explanation is a good thing [11:20] has we/linaro requested a standing freeze exception? :) [11:20] lol [11:20] no [11:20] ok. got the impression we had from the lines i saw above :) [11:20] where possible, we should be finding points of commonality across architectures, and it's important that (especially) release team people learn the rough parameters of the differences between ARM and everything else [11:21] saying "don't worry, the ARM people will sort it all out and don't need to explain it to you" just encourages siloing [11:21] and I really think it's important to find ways to avoid that [11:21] asac, i was only suggesting to have an arm person back in the universe approval team for FFes as we had it in the past [11:21] I think we are happy with the process until we complain. however, we are on a monthly release cadance so keeping process lean for stuff that doesnt risk ubuntu release would make sense [11:22] ogra_: ok i see [11:22] ogra_: any cases of slow turnaround of current team? or "stupid" quesitons of release team because they were not familiar enough with ARM topics? [11:24] tjaalton: can we merge libx11 from unstable (or can I)? It has a cross-building fix I'd like to have [11:25] asac, neither, just janimo not knowing we need FFes for universe that lead to this discussion [11:25] tjaalton: I don't know if you manage it in revision control [11:25] ogra_: ah. that feels is a different problem :) [11:25] cjwatson: i merged it yesterday already [11:26] and uploaded [11:26] appears to be in the archive too :) [11:26] oh :) [11:27] sudo apt-get --reinstall install brain [11:27] thanks [11:27] asac, exception requests aside, it is not clear what Linaro wants to have in the main archives, if there is such a position at all, or left for each WG/developer to sort it out [11:27] ogra_: I think one thing that could be done better is to what a feature really is ... is it if it changes the the software (current) or rather if it changes the behaviour/featureset availbale in one of the seeds [11:27] better define (or maybe improve) what a feature really is [11:27] but thats just a guts feeling [11:27] well, it's already well-defined that simply changing the software does not amount to a feature [11:27] bug-fixes are fine [11:28] sure [11:28] TBH I've not had any developer enquire what a feature is before :-) [11:28] cjwatson: yeah jcristau mentioned the bug on irc, and later Sarvatt noticed that the fix was uploaded so I merged it right away [11:28] it's just the plain English meaning [11:28] i was meaning: is a package view really what is important or should we rather take a seed/image view to identify if something is a feature worth spending review cycles on [11:28] we certainly do not have anything which ties it to seeds or images, otherwise FFes would be meaningless for universe [11:29] and I think the consensus among universe mavens has been that they want to have a degree of review there [11:29] so xubuntu etc. dont use universe at all? [11:30] well, OK, there are images built out of universe [11:30] but I mean MOTU leaders have historically expressed a preference for having a consistent feature freeze *process* across the board, even if the actual reviews are often pretty rubberstampy for things whose effect is minimal [11:31] right [11:31] doko_: thanks for the promotion. [11:31] and I do think it's clearer to be able to just say "if you're adding features after feature freeze, you need an exception" rather than having to figure out whether something is in an image or not [11:31] (which is actually kind of non-trivial for many people to work out) [11:31] true [11:34] pitti, seb128, didrocks: is there a gnome-shell upload pending? [11:35] doko_, not sure, I need to check with jbicha when he will be online, the current one is depwaiting on caribou [11:36] doko_, which he was trying to get in for some time, so not sure if we should wait on caribou on try to reverse the depends on it [11:36] revert [11:36] same for pitivi, waiting on jbicha to be online [11:57] ogra@horus:~$ echo "FileVersion: 14.0.4756.1000"| sed "/^FileVersion: */!d; s///;q" [11:57] echo "FileVersion: 14.0.4756.1000"| sed "/^FileVersion: */dmesg; s///;q" [11:57] sed: -e expression #1, char 19: extra characters after command [11:58] wow, wher does that autocompletion come from ? [11:58] *where [12:04] ogra_: history expansion [12:04] ogra_: the '!' [12:04] ogra_: use single quotes instead; you have no need for double-quote expansion there [12:04] intresting [12:05] * ogra_ doesnt actually have a usecase for this, i just verified something from the ubuntu-devel ML ... but found it surprising to see what happens :) [12:06] I turn off history expansion on my systems because (a) I find it too annoying (b) I never actually want to use it (c) it conflicts with more useful expansions enabled by extglob [12:06] ogra_: echo "!emacs" etc [12:07] so I have 'set +H; shopt -s extglob' in .bashrc [12:07] doko: I have no idea what that is [12:07] is there some reason I should? [12:08] sladen, heh, that would require that any of my systems has ever seen emacs :) but yeah, i get it [12:08] so for me the command line ogra_ quotes works as presumably intended, but it's not portable [12:08] thaks for the exaplanation ! [12:08] np [12:08] Laney, I don't know, didn't you fix some other ocaml stuff? [12:08] probably not intentionally [12:09] i did once write some ocaml [12:09] doko: you might be mixing up ocaml and haskell [12:09] Everytime i forget to sudo a command, i follow it with a "sudo !!" on the next line [12:09] ahh, ok. removing then! [12:09] I recommend you ask sgnb about it [12:09] give peace a chance! [12:10] ok, ok ... [12:11] it looks like something you'd be able to fix if you know what the error means [12:12] Daviey: yeah, I know some people use that - I've got used to up-arrow ctrl-a sudo space enter, and !(...) is such an incredibly useful extended glob expansion that it's worth it [12:13] Laney: about what? [12:13] ("any file that does not match these patterns") [12:13] oh, you're here [12:13] sgnb: https://bugs.launchpad.net/ubuntu/+source/janest-core/+bug/831106 [12:13] Ubuntu bug 831106 in janest-core (Ubuntu Oneiric) "janest-core version 0.6.0-3 failed to build in oneiric" [High,Confirmed] [12:13] doko is on an FTBFS busting exercise [12:13] Daviey: plus the way that if you mistakenly type ! in something it disappears from your history really bugs me [12:13] Laney: ah, known issue [12:13] known fix? [12:14] upgrade to latest upstream [12:14] but ENOTIME these days [12:14] (and there are also dependencies to upgrade) [12:15] cjwatson: I can see benefit for using extglob, might start. [12:15] sgnb, so better remove it for oneiric, or will you have a chance to update it [12:15] remove it [12:15] ok [12:15] (it has been removed from testing, fwiw) [12:16] but uninstallability of ocamlgraph is unexpected [12:16] I guess a recompilation should fix it [12:17] Daviey: oh, hmm, it looks as though nowadays you can use extglob sensibly even with history expansion turned on, so my (c) no longer applies [12:18] bah [12:19] Daviey: this wasn't true in Feb 2003 when I made this change to my .bashrc :) [12:20] cjwatson: you've kept the same .bashrc since 2003? crikey. [12:20] 14:13 < sgnb> Laney: ah, known issue [12:20] oops [12:20] Daviey: no, but I've had it in revision control since 2002 :) [12:20] I hate it when you select sth and just when you copy the terminal scrolls under you [12:20] certainly a linear descendant; I see no reason to rewrite it ... [12:21] 14:13 < cjwatson> Daviey: plus the way that if you mistakenly type ! in something it disappears from your history really bugs me -> this indeed, I hate that you have to copy/paste the original command and fix it [12:21] My rule of thumb is that .bashrc should be younger than your current underwear. [12:21] * cjwatson spots a cloud person [12:21] ah indeed, I'll see about rebuilding ocamlgraph frama-c [12:22] (please tell me you don't store your underwear in the cloud) [12:22] Laney: ocamlgraph should definitely be recompiled (and has been since lablgtk2 was upgraded) [12:22] cjwatson: at least it's dry-cleaned that way ^^ [12:22] Daviey, iiuc ScottK, bug 831121 and bug 831179 are on the server radar? [12:22] Launchpad bug 831121 in dovecot-antispam (Ubuntu Oneiric) "dovecot-antispam version 1.4~rc3-1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/831121 [12:22] Launchpad bug 831179 in dovecot-metadata-plugin (Ubuntu Oneiric) "dovecot-metadata-plugin version 0.0.1~hg144-0ubuntu1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/831179 [12:23] Laney: and maybe frama-c as well, but I'd wait for ocamlgraph to be installable again [12:23] aye [12:23] * Laney is familiar with the dance [12:23] doko: dovecot-antispam wasn't [12:23] thanks [12:24] cjwatson: IMO a "blog your .bashrc/.vimrc/.screenrc" meme would be interesting and useful :) [12:24] especially from debian/ubuntu developers [12:25] there was a point in job[-1] when my .vim directory was simultaneously stored in CVS and Subversion [12:26] that was exciting [12:26] exciting? sounds confusing instead [12:26] scary [12:26] I just got a prompt which just said "Password: " and kept respawning when dismissed [12:27] Chipzz: I keep meaning to blog about my .bashrc and .emacs.d; both are set up to dynamically handle being on multiple machines and custom parts on each [12:28] Nafai: I recently fixed my .vimrc to work with vim-tiny [12:28] I was getting annoyed at vim-tiny throwing sh*tload of errors upon starting with my .vimrc [12:29] (first thing I do when I install a new machine is wget my .vimrc, but I sometimes forget to replace vim-tiny with regular vim) [12:29] I used to have shell configuration which was capable of setting up a sane terminal configuration on all of Linux, HP-UX, SunOS, UnixWare, and IRIX, and various bits in ~/bin/ to try to smooth over the more annoying differences [12:29] (the current /usr/bin/which on Debian/Ubuntu actually descends from that) [12:30] http://chipzz.safehex.be/docs/vimrc | http://chipzz.safehex.be/docs/bashrc | http://chipzz.safehex.be/docs/screenrc [12:31] hrrrrm my .bashrc is missing some useful stuff [12:33] http://chipzz.safehex.be/docs/bashrc | http://chipzz.safehex.be/docs/sshrc [12:34] [ "$SSH_AUTH_SOCK" ] && export SSH_AUTH_SOCK=$HOME/.ssh/@`hostname -s`.agent [12:34] that in conjunction with my .ssh/rc is a nice way of getting screen and ssh agent forwarding to work together [12:36] (but keep in mind to set proper permissions on ~/.ssh !) === kentb-out is now known as kentb [13:41] can somebody moderate my mail through u-d-a? [13:56] kees: hey, regarding the lvm udev rules, you said in email there were specific reasons you had to do it how you did - are those documented, and are there testcases? [13:58] smb: when you say 'pkill of udev was a problem on xen guests and had to be redone' - you mean udev didn't really die? [14:00] hallyn, On the attempts I did it at least did not immediately. So there I had a loop re-doing pkill untill no udev was to be seen anymore [14:01] hallyn, Maybe bashing it repeatedly with that hammer was not neede dand it was just waiting for all the numerous helpers to be done [14:03] smb: well you're not doin gpkill -9 right? I assume it was hanging for the same reason it sometimes hangs with udevadm control --exit [14:03] smb: what kills me is anytime i try to have udevd print out the list of pending events, i can't reproduce it :) [14:05] hallyn, I think there were two problems there: 1. it not getting done with what it was doing when next steps were tried and 2. it never get done (this seems to still happen sometimes with --exit, I was trying to have some dumps of that but xen pv dumps were broken (maybe because of my pvgrub)) [14:06] hallyn, And yes, a pretty Heissen-bug [14:06] makes me feel like i wasted the afternoon, btw [14:06] smb: are you working that bug today? [14:07] hallyn, No its sort of on a backlog [14:07] k [14:07] smb: with xen, is there a way from the host to slow down (renice) the backign store process separately from the domain itself? [14:08] hallyn, If there is I don't know of one. It seemed to happen relatively reliable on some boots on my server [14:09] But I yet, have to confirm whether the dumps would be usable in crash now with the new pvgrub I got [14:09] ok, thx smb. ttyl [14:18] barry: I ran across something yesterday I thought you'd love: https://github.com/whymirror/unholy [14:19] ScottK: oh wow [14:21] ScottK, please could you have a look at the patch in bug 770975? still ftbfs for me ... [14:21] Launchpad bug 770975 in mm3d (Ubuntu Oneiric) "mm3d version 1.3.7-1.2 failed to build on amd64 with GCC-4.6/oneiric" [High,Confirmed] https://launchpad.net/bugs/770975 [14:27] doko: Seems mostly OK, but hard codes multi-arch paths. I think slangasek should review. I'm sure he'd know the best way. [14:45] mvo: do you have any updated assessment of whether porting update-notifier to libappindicator might be feasible for oneiric (bug 779382)? [14:45] Launchpad bug 779382 in unity (Ubuntu Natty) "update-notifier not visible under unity" [High,Triaged] https://launchpad.net/bugs/779382 [14:47] mvo: also I don't suppose you've managed to get anywhere with bug 848659 ... [14:47] Launchpad bug 848659 in update-manager (Ubuntu Oneiric) "Upgrade from natty fails with 64-bit oneiric beta cd" [High,Confirmed] https://launchpad.net/bugs/848659 [14:47] hallyn: not very well documented, but the reasoning was to bring up a root-on-lvm-on-md system without races. the testcase was that my system boots. :) [14:51] cjwatson: let me check [14:59] cjwatson: hi there. was just looking at bug 736743. would it be appropiate to hide the error message from 11.10 you reckon? just comment it out sort of thing. [14:59] Launchpad bug 736743 in grub2 (Ubuntu Oneiric) "environment block not implemented on btrfs" [Wishlist,Triaged] https://launchpad.net/bugs/736743 [15:01] Nafallo: uh, maybe, I'm not in general comfortable with that approach but would need to look [15:02] I mean, it does genuinely cause limited functionality [15:03] cjwatson: I just tried ubuntu-defaults-image with a local --package option. Like ubuntu-defaults-image --package ~/work/isofr/ubuntu-defaults-french_0.1_all.deb. I'm under the impression that despite the package having been copied to config/chroot_packages/, this one wasn't installed in the chroot (I don't see it), and so, all the localization failed. [15:03] doko: 853688> well, we also don't know if dropping the breaks on libgcc1 is sufficient... if we have to drop the breaks from both libgcc1 and libc6-dev to get apt to solve it, maybe we want to try a different way [15:04] cjwatson: nope. it's just an obstacle in the experience. people notice it, and I bet the splash would come up faster without the message getting displayed. [15:04] Nafallo: pretty sure it makes sod-all difference to speed [15:04] cjwatson: PACKAGE and PACKAGENAME are correct though, and all the sedding as well, I'm not familiar with lb, does lb config really need to be called before copying those package? (and then lb build should do the right thing?) [15:05] cjwatson: heh, you might be right. I'm happy to clock the difference if you want to give it a go :-) [15:05] didrocks: well, lb config *is* called before, isn't it? [15:05] didrocks: and yes, pretty sure it needs to be [15:05] cjwatson: indeed, ok, so not that, I don't see any log of the package being installed [15:06] cjwatson: I'm on it, seb128 is a great help [15:06] cjwatson: on the indicator stuff [15:07] didrocks: it ought to work from what I can see - can you file a bug with a log? [15:07] mvo: cjwatson: FYI, update-notifier should be visible in unity since beta2, I whitelisted it [15:07] mvo: great, thanks [15:07] didrocks: yeah, I noticed that, but not unity-2d right? [15:07] cjwatson: sure, doing that [15:07] cjwatson: unity-2d as well [15:07] at least, was working when I tested it [15:07] (if you turn the right gsettings options of course to get update-notifier showing its icon) [15:08] didrocks: ? awsome [15:08] oh, right, I missed that that task had been marked Invalid [15:08] didrocks: so the fix is actually not that urgent anymore? that is good news and may safe my friday [15:09] there is a bug about glitches in the icon rendering, but it's rather it being big that hidden (and only under unity): bug #856125 [15:09] Launchpad bug 856125 in unity (Ubuntu) "update-notifier systray icons showed and the wrong place and size" [Medium,Triaged] https://launchpad.net/bugs/856125 [15:09] mvo: yeah, you can enjoy your week-end and it's just a "nice to have" now :) [15:09] cjwatson: if it's considered as a security issue, we should whitelist it in natty as well btw [15:10] we should either whitelist it or port it there, yes [15:10] port it for natty? doesn't it sound risky? (whitelist is just a gsettings key away, not that I found the WMCLASS) [15:11] kees: i kinda wish boris was to be found here on irc :) I don't know how far he's gotten in looking at this [15:12] slangasek, would you consider the trivial patch to bug 856984 for oneiric ? [15:12] Launchpad bug 856984 in isc-dhcp (Ubuntu) "dhclient-script attempts to write /etc/resolv.conf before it is writable" [Undecided,New] https://launchpad.net/bugs/856984 [15:12] ppetraki: do you have a root-on-lvm-on-md system we'd be able to use as a test for whether oneiric with new udev-lvm rules works? [15:13] hallyn, readily available, no, but I can spare a blade for you. [15:13] didrocks: yeah, agreed [15:14] smoser: I think your { } are redundant and should be dropped, but otherwise yes, I think that looks sane [15:14] they're not redundant [15:15] to avoid the error of failed write going to stderr [15:15] you can test if you'd like [15:15] $ sh -c ': >> /etc/passwd 2>/dev/null' [15:15] sh: /etc/passwd: Permission denied [15:15] versus [15:15] sh -c '{ : >> /etc/passwd; } 2>/dev/null' [15:16] ppetraki: ok, thanks. At this point tbh i'm afraid we have to wait for P to open up, and address lvm2, dmsetup, and udev packages alltogether. [15:16] hallyn, sounds like fun :) [15:16] ppetraki: which, i suppose, is really a foundations team thing... [15:16] but we can beg to be in the loop :) [15:16] heh [15:16] i probably *do* uses {} more than other people in shell scripts (especially around variable names), but here they're actually useful [15:17] smoser: ah, because the redirect is done by the parent shell, not by :, check [15:17]