| micahg | Sweetshark: I'd suggest discussing with tyhicks about ecryptfs and how likely it is to be impacting this bug | 00:26 |
|---|---|---|
| tyhicks | micahg: Good suggestion - I've read through it and don't have any good ideas about what eCryptfs could be doing incorrectly | 00:58 |
| tyhicks | Digging in deeper is next on my todo list | 00:59 |
| micahg | tyhicks: sweetshark is in UTC +2 I believe, maybe you could chat with him at some point | 00:59 |
| Laibsch | 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 |
| Laibsch | 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 |
| Laibsch | Sweetshark: thank you for the work you're doing. Much appreciated. | 01:00 |
| * Laibsch is one of the affected people and in UTC+8 | 01:01 | |
| tyhicks | Laibsch: hello - upstream eCryptfs kernel maintainer here | 01:02 |
| Laibsch | I know | 01:02 |
| Laibsch | I'm the 50G/140G false positive guy ;-) | 01:02 |
| tyhicks | 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 |
| Laibsch | so we meet again (we can talk privately if you want) | 01:02 |
| tyhicks | Laibsch: ah, that's right :) | 01:02 |
| Laibsch | the problem is 100% reproducible for me. So, if you can cook up something to collect data, I'm here. | 01:04 |
| tyhicks | Laibsch: I've looked through the report and traces provided and I didn't see much to work off of | 01:04 |
| tyhicks | 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 |
| tyhicks | Laibsch: I really appreciate the offer and will keep it in mind | 01:05 |
| Laibsch | tyhicks: Yes, best is of course if you can reproduce it locally. But apparently Sweetshark had some trouble doing that. | 01:06 |
| Laibsch | 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:12 |
| tyhicks | Laibsch: Yeah - just read that comment... I'll definitely have to follow up on that claim | 01:13 |
| Laibsch | would it help if I ran Office through valgrind? | 01:13 |
| * Laibsch wonders what upstream discussion Sweetshark was referring to | 01:14 | |
| Laibsch | probably http://nabble.documentfoundation.org/Multiple-issues-with-cppuhelper-source-exc-thrower-cxx-td2992234.html | 01:15 |
| smoser | slangasek, heres a strange (to me) console log http://paste.ubuntu.com/695394/ | 01:15 |
| === plars-afk is now known as plars | ||
| lamont | I wonder, how do I get do-release-upgrade to _NOT_ run screen? | 02:25 |
| micahg | why would you want that? | 02:26 |
| lamont | because the serial console hates screen | 02:26 |
| smoser | slangasek, ok. i opened bug 856984. i know whats wrong, and *a* fix is fairly straight forward. | 02:26 |
| ubottu | 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 |
| lamont | seems that removing screen fixes the issue | 02:26 |
| smoser | nice | 02:26 |
| TheMuso | /c/c | 02:31 |
| === Amaranthus is now known as Amaranth | ||
| ScottK | Man, where's barry when you need him. | 04:30 |
| * ScottK wanted to see him headdesk: https://github.com/whymirror/unholy | 04:30 | |
| infinity | ScottK: That's vile. And a thing of beauty. | 05:28 |
| * ScottK thinks barry will love it. | 05:28 | |
| StevenK | Or he will claw his eyes out. | 05:29 |
| micahg | reminded me of this: http://www.linuxjournal.com/article/9282 | 05:29 |
| ScottK | Entertaining either way. | 05:29 |
| broder | you guys have seen perl's Inline::C and Inline::Python, right? | 05:31 |
| broder | (well, s/perl/CPAN/) | 05:31 |
| infinity | Inlining is a bit different than this python/ruby translation madness. | 05:31 |
| StevenK | I've *used* Inline::Python. | 05:32 |
| infinity | I'm reminded of Facebook's PHP-to-C compiler. | 05:32 |
| StevenK | It's utter crack. | 05:32 |
| broder | infinity: but similarly terrifying :) | 05:32 |
| didrocks | good morning | 05:35 |
| ScottK | Good morning. | 05:35 |
| ScottK | didrocks: Bad news on the Qt front ... | 05:35 |
| ScottK | It looks like it's going to fail on armel (already did on powerpc) | 05:35 |
| ScottK | With that bit of joy, I'm off to bed. | 05:36 |
| ScottK | Have a nice $TIME_OF_DAY. | 05:36 |
| didrocks | ScottK: argh, ok, I'll try to have a look | 05:36 |
| ScottK | Thanks. | 05:36 |
| didrocks | ScottK: have a good night :) | 05:36 |
| === Quintasan_ is now known as Quintasan | ||
| lucas | doko_: libdb-ruby was entirely superseded by ruby-bdb, it just needs decruft to disappear | 06:09 |
| === eyes_ is now known as EyesIsServer | ||
| dholbach | good morning | 07:14 |
| doko_ | lucas, right seen now. but the source is still in unstable too (and libcairo-ruby) | 07:57 |
| === tkamppeter__ is now known as tkamppeter | ||
| tkamppeter | pitti, hi | 08:29 |
| doko_ | 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 |
| ubottu | 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:38 |
| mvo | doko_: sorry, I haven't had a chance yet to properly look at this | 08:40 |
| doko_ | SpamapS, barry: could you have a look at bug 771121? the easiest way would be to disable the python3 package | 09:20 |
| ubottu | 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:20 |
| TLE | pitti: hallo, I was wondering if you have a few minutes for some language packs? | 09:21 |
| bryceh | TLE, think he's on vacation currently | 09:24 |
| tkamppeter | 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 |
| ubottu | Launchpad bug 560849 in hplip (Ubuntu) "hpfax crashed with NameError in bug()" [Undecided,Fix committed] https://launchpad.net/bugs/560849 | 09:25 |
| seb128 | tkamppeter, we don't unfreeze | 09:25 |
| TLE | 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 |
| seb128 | tkamppeter, uploads until Oneiric need to get reviewed | 09:25 |
| tkamppeter | seb128, do I need to do anything special for the uploads to get reviewed? | 09:27 |
| seb128 | tkamppeter, no | 09:28 |
| seb128 | tkamppeter, they will just be regularly reviewed when release team member look at the queue | 09:28 |
| bryceh | TLE, seb128. | 09:28 |
| TLE | bryceh: thanks | 09:29 |
| seb128 | heh | 09:29 |
| TLE | ahh, you got volouteered there | 09:29 |
| TLE | *G* | 09:29 |
| seb128 | 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:30 |
| TLE | 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:31 |
| TLE | seb128: ^" | 09:32 |
| seb128 | 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:32 |
| TLE | I already pinged him, I can talk to him about it and them we'll bug you if necessary ;) | 09:34 |
| dpm | TLE, let's have a chat later on in the day about langpacks if that works for you | 09:34 |
| TLE | dpm: absolutely, in the office all day | 09:34 |
| dpm | cool, thanks TLE | 09:34 |
| TLE | no worries | 09:35 |
| doko_ | pitti: bad pittivi FFe ;-P | 10:10 |
| soren | pitti: Any idea why the libvirt package in lucid-proposed hasn't propagated to -updates? | 10:38 |
| cjwatson | bug 823638 hasn't been marked v-done | 10:41 |
| ubottu | 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:41 |
| cjwatson | which may be trivial from that bug description; I'm just reading the dashboard | 10:42 |
| soren | Oh, I see. | 10:43 |
| ScottK | 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:46 |
| Daviey | Any AA's around that can promote an approved MIR please? | 10:48 |
| janimo | ScottK, it is sponsoring by alf_ via pm request this morning | 10:49 |
| ScottK | 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 |
| janimo | ScottK, honestly had no idea FFE applies to universe | 10:50 |
| ScottK | OK. | 10:51 |
| ScottK | It applies to the entire archive. It always has. | 10:51 |
| ScottK | Lesson learned I guess. | 10:51 |
| janimo | always? Even for GNOME components? | 10:51 |
| soren | Everything that doesn't have a standing exception. | 10:51 |
| Daviey | janimo: Are you thinking of feature defintion freeze? | 10:52 |
| Daviey | That doesn't apply to universe. | 10:52 |
| janimo | 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:52 |
| janimo | soren, yes, I assumed there was a standing exception for universe | 10:53 |
| Daviey | https://wiki.ubuntu.com/StandingFeatureFreeze | 10:54 |
| Daviey | Hardy :) | 10:54 |
| Daviey | janimo: No, standing applies to packages or groups of, not whole components. :o | 10:54 |
| janimo | 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:55 |
| janimo | not talking about landing new kernels/bootloaders which can break stuff, but universe apps | 10:56 |
| Daviey | 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:57 |
| janimo | ScottK, https://bugs.launchpad.net/ubuntu/+source/glmark2/+bug/857279 | 10:58 |
| ubottu | Ubuntu bug 857279 in glmark2 (Ubuntu) "FFE for Oneiric" [Undecided,New] | 10:58 |
| Daviey | janimo: https://wiki.ubuntu.com/FreezeExceptionProcess should be a good guide | 10:58 |
| Daviey | janimo: That bug really needs more detail | 10:59 |
| janimo | asac, rsalveti see what Daviey says above. You may want to add this to the discussion at UDS | 10:59 |
| cjwatson | janimo: freeze doesn't mean you can't upload stuff, it just means it requires some thought | 10:59 |
| cjwatson | Linaro does too much core stuff for me to be comfortable with a standing feature freeze exception for everything they do | 10:59 |
| cjwatson | for universe applications, I'd have thought that we could easily just work case-by-case? | 11:00 |
| janimo | 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 |
| janimo | Daviey, I'll ask alf I merely sponsored him, have no idea what is in the new release | 11:01 |
| Daviey | janimo: Are you talking features or bugs? | 11:02 |
| Daviey | I mean, if you are fixing FTBFS's on arm for example, that wouldn't need a FFe. | 11:03 |
| janimo | Daviey, features but for fringe apps | 11:03 |
| janimo | sure, bugs I know | 11:03 |
| htorque | soren: hi! are you currently testing the suggested patch at https://bugs.freedesktop.org/show_bug.cgi?id=41059 ? | 11:03 |
| ubottu | Freedesktop bug 41059 in Driver/intel "XRANDR operations very slow unless (phantom) HDMI1 disabled" [Major,New] | 11:03 |
| janimo | Daviey, universe apps which do not affect non-ARM images | 11:03 |
| janimo | and mostly developer stuff | 11:04 |
| Daviey | 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:05 |
| Daviey | 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 |
| Daviey | although slangasek is thinking about doing that for qemu-linaro :) | 11:06 |
| janimo | 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:06 |
| janimo | Daviey, QEMu breaking would mean the whole cloud/server things being affected, very different :) | 11:07 |
| janimo | glmark2 having a regression? pfft | 11:07 |
| janimo | anyway something to discuss with the Linaro guys at UDS | 11:07 |
| ogra_ | janimo, well, its our job to care for the archive and get the bits into it | 11:08 |
| ogra_ | i dont think there is much to discuss | 11:08 |
| Daviey | 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 |
| janimo | 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 |
| soren | 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 |
| ogra_ | janimo, in the past we simply used to have a team member in the universe release team | 11:08 |
| ogra_ | we should probably revive that | 11:08 |
| Daviey | ogra_: arm or linaro? | 11:09 |
| ogra_ | Daviey, ?? | 11:09 |
| janimo | ogra_, 1) so we could just approve all our FFEs? Nice 2) You are not talking me into becoming that person | 11:09 |
| ogra_ | lol | 11:09 |
| ogra_ | Daviey, i'm ubuntu-arm | 11:09 |
| Daviey | ogra_: "in the past 'we' had a tam member", who is we? | 11:10 |
| Daviey | team* | 11:10 |
| * ogra_ doesnt talk for linaro | 11:10 | |
| cjwatson | I don't think we should have people who are in ubuntu-release just to approve their team's exceptions | 11:10 |
| cjwatson | cross-fertilisation and cross-checking is extremely valuable | 11:10 |
| htorque | 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:10 |
| janimo | cjwatson, I forgot a smiley there in 1) | 11:11 |
| ogra_ | cjwatson, well, but having the people knowing the code also reviewing it makes everything a bit easier | 11:11 |
| cjwatson | 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 |
| ogra_ | (and not only knowing but being able to verify on HW) | 11:11 |
| ogra_ | cjwatson, i didnt intend that with the suggestion | 11:12 |
| cjwatson | 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 |
| ogra_ | we used to do it in the past simply because the process was faster | 11:12 |
| ogra_ | not because we handled the execptions more losely | 11:12 |
| Daviey | ogra_: It should be possible to demostrate a good level of confidence to someone who doesn't understand the issue IMO. | 11:13 |
| Daviey | Yeah, i don't think ogra_ is suggesting bypass of process. | 11:13 |
| ogra_ | oh, sure, i dont say i mistrust anyone :) | 11:13 |
| cjwatson | 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:14 |
| doko_ | Laney, janest-core, remove or fix it? | 11:15 |
| cjwatson | a degree of separation helps to avoid that and can actually reduce stress | 11:15 |
| janimo | cjwatson, true. | 11:15 |
| ogra_ | but it also slows down the process since you need to work yourself into code other know in and out | 11:15 |
| ogra_ | *others | 11:15 |
| cjwatson | I think that's an acceptable price to pay | 11:16 |
| cjwatson | anyway, reviewing freeze exceptions doesn't mean a complete code review | 11:16 |
| ogra_ | indeed | 11:16 |
| cjwatson | it's more an assessment of its likely impact and sanity | 11:17 |
| ogra_ | which an arm person can judge better than a non arm person in this case | 11:17 |
| cjwatson | I do not in general agree | 11:17 |
| cjwatson | 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 |
| cjwatson | 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 |
| cjwatson | and acting accordingly | 11:18 |
| ogra_ | 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 |
| ogra_ | (and thats not arm specific at all) | 11:19 |
| Daviey | Inverse, unless the package only builds on arm target - can they measure the impact for other arches with confidence? | 11:19 |
| cjwatson | I don't agree that saving the need for the explanation is a good thing | 11:19 |
| asac | has we/linaro requested a standing freeze exception? :) | 11:20 |
| ogra_ | lol | 11:20 |
| ogra_ | no | 11:20 |
| asac | ok. got the impression we had from the lines i saw above :) | 11:20 |
| cjwatson | 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:20 |
| cjwatson | 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 |
| cjwatson | and I really think it's important to find ways to avoid that | 11:21 |
| ogra_ | 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 |
| asac | 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:21 |
| asac | ogra_: ok i see | 11:22 |
| asac | 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:22 |
| cjwatson | tjaalton: can we merge libx11 from unstable (or can I)? It has a cross-building fix I'd like to have | 11:24 |
| ogra_ | asac, neither, just janimo not knowing we need FFes for universe that lead to this discussion | 11:25 |
| cjwatson | tjaalton: I don't know if you manage it in revision control | 11:25 |
| asac | ogra_: ah. that feels is a different problem :) | 11:25 |
| tjaalton | cjwatson: i merged it yesterday already | 11:25 |
| tjaalton | and uploaded | 11:26 |
| tjaalton | appears to be in the archive too :) | 11:26 |
| cjwatson | oh :) | 11:26 |
| cjwatson | sudo apt-get --reinstall install brain | 11:27 |
| cjwatson | thanks | 11:27 |
| janimo | 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 |
| asac | 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 |
| asac | better define (or maybe improve) what a feature really is | 11:27 |
| asac | but thats just a guts feeling | 11:27 |
| cjwatson | well, it's already well-defined that simply changing the software does not amount to a feature | 11:27 |
| cjwatson | bug-fixes are fine | 11:27 |
| asac | sure | 11:28 |
| cjwatson | TBH I've not had any developer enquire what a feature is before :-) | 11:28 |
| tjaalton | 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 |
| cjwatson | it's just the plain English meaning | 11:28 |
| asac | 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 |
| cjwatson | we certainly do not have anything which ties it to seeds or images, otherwise FFes would be meaningless for universe | 11:28 |
| cjwatson | and I think the consensus among universe mavens has been that they want to have a degree of review there | 11:29 |
| asac | so xubuntu etc. dont use universe at all? | 11:29 |
| cjwatson | well, OK, there are images built out of universe | 11:30 |
| cjwatson | 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:30 |
| asac | right | 11:31 |
| Daviey | doko_: thanks for the promotion. | 11:31 |
| cjwatson | 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 |
| cjwatson | (which is actually kind of non-trivial for many people to work out) | 11:31 |
| asac | true | 11:31 |
| doko_ | pitti, seb128, didrocks: is there a gnome-shell upload pending? | 11:34 |
| seb128 | doko_, not sure, I need to check with jbicha when he will be online, the current one is depwaiting on caribou | 11:35 |
| seb128 | 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 |
| seb128 | revert | 11:36 |
| seb128 | same for pitivi, waiting on jbicha to be online | 11:36 |
| ogra_ | ogra@horus:~$ echo "FileVersion: 14.0.4756.1000"| sed "/^FileVersion: */!d; s///;q" | 11:57 |
| ogra_ | echo "FileVersion: 14.0.4756.1000"| sed "/^FileVersion: */dmesg; s///;q" | 11:57 |
| ogra_ | sed: -e expression #1, char 19: extra characters after command | 11:57 |
| ogra_ | wow, wher does that autocompletion come from ? | 11:58 |
| ogra_ | *where | 11:58 |
| cjwatson | ogra_: history expansion | 12:04 |
| sladen | ogra_: the '!' | 12:04 |
| cjwatson | ogra_: use single quotes instead; you have no need for double-quote expansion there | 12:04 |
| ogra_ | intresting | 12:04 |
| * 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:05 | |
| cjwatson | 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 |
| sladen | ogra_: echo "!emacs" etc | 12:06 |
| cjwatson | so I have 'set +H; shopt -s extglob' in .bashrc | 12:07 |
| Laney | doko: I have no idea what that is | 12:07 |
| Laney | is there some reason I should? | 12:07 |
| ogra_ | sladen, heh, that would require that any of my systems has ever seen emacs :) but yeah, i get it | 12:08 |
| cjwatson | so for me the command line ogra_ quotes works as presumably intended, but it's not portable | 12:08 |
| ogra_ | thaks for the exaplanation ! | 12:08 |
| cjwatson | np | 12:08 |
| doko | Laney, I don't know, didn't you fix some other ocaml stuff? | 12:08 |
| Laney | probably not intentionally | 12:08 |
| Laney | i did once write some ocaml | 12:09 |
| cjwatson | doko: you might be mixing up ocaml and haskell | 12:09 |
| Daviey | Everytime i forget to sudo a command, i follow it with a "sudo !!" on the next line | 12:09 |
| doko | ahh, ok. removing then! | 12:09 |
| Laney | I recommend you ask sgnb about it | 12:09 |
| Laney | give peace a chance! | 12:09 |
| doko | ok, ok ... | 12:10 |
| Laney | it looks like something you'd be able to fix if you know what the error means | 12:11 |
| cjwatson | 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:12 |
| sgnb | Laney: about what? | 12:13 |
| cjwatson | ("any file that does not match these patterns") | 12:13 |
| Laney | oh, you're here | 12:13 |
| Laney | sgnb: https://bugs.launchpad.net/ubuntu/+source/janest-core/+bug/831106 | 12:13 |
| ubottu | Ubuntu bug 831106 in janest-core (Ubuntu Oneiric) "janest-core version 0.6.0-3 failed to build in oneiric" [High,Confirmed] | 12:13 |
| Laney | doko is on an FTBFS busting exercise | 12:13 |
| cjwatson | Daviey: plus the way that if you mistakenly type ! in something it disappears from your history really bugs me | 12:13 |
| sgnb | Laney: ah, known issue | 12:13 |
| Laney | known fix? | 12:13 |
| sgnb | upgrade to latest upstream | 12:14 |
| sgnb | but ENOTIME these days | 12:14 |
| sgnb | (and there are also dependencies to upgrade) | 12:14 |
| Daviey | cjwatson: I can see benefit for using extglob, might start. | 12:15 |
| doko | sgnb, so better remove it for oneiric, or will you have a chance to update it | 12:15 |
| sgnb | remove it | 12:15 |
| doko | ok | 12:15 |
| sgnb | (it has been removed from testing, fwiw) | 12:15 |
| sgnb | but uninstallability of ocamlgraph is unexpected | 12:16 |
| sgnb | I guess a recompilation should fix it | 12:16 |
| cjwatson | 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:17 |
| Daviey | bah | 12:18 |
| cjwatson | Daviey: this wasn't true in Feb 2003 when I made this change to my .bashrc :) | 12:19 |
| Daviey | cjwatson: you've kept the same .bashrc since 2003? crikey. | 12:20 |
| Chipzz | 14:13 < sgnb> Laney: ah, known issue | 12:20 |
| Chipzz | oops | 12:20 |
| cjwatson | Daviey: no, but I've had it in revision control since 2002 :) | 12:20 |
| Chipzz | I hate it when you select sth and just when you copy the terminal scrolls under you | 12:20 |
| cjwatson | certainly a linear descendant; I see no reason to rewrite it ... | 12:20 |
| Chipzz | 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 |
| Daviey | My rule of thumb is that .bashrc should be younger than your current underwear. | 12:21 |
| * cjwatson spots a cloud person | 12:21 | |
| Laney | ah indeed, I'll see about rebuilding ocamlgraph frama-c | 12:21 |
| cjwatson | (please tell me you don't store your underwear in the cloud) | 12:22 |
| sgnb | Laney: ocamlgraph should definitely be recompiled (and has been since lablgtk2 was upgraded) | 12:22 |
| Chipzz | cjwatson: at least it's dry-cleaned that way ^^ | 12:22 |
| doko | Daviey, iiuc ScottK, bug 831121 and bug 831179 are on the server radar? | 12:22 |
| ubottu | 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 |
| ubottu | 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:22 |
| sgnb | Laney: and maybe frama-c as well, but I'd wait for ocamlgraph to be installable again | 12:23 |
| Laney | aye | 12:23 |
| * Laney is familiar with the dance | 12:23 | |
| Daviey | doko: dovecot-antispam wasn't | 12:23 |
| Daviey | thanks | 12:23 |
| Chipzz | cjwatson: IMO a "blog your .bashrc/.vimrc/.screenrc" meme would be interesting and useful :) | 12:24 |
| Chipzz | especially from debian/ubuntu developers | 12:24 |
| cjwatson | there was a point in job[-1] when my .vim directory was simultaneously stored in CVS and Subversion | 12:25 |
| cjwatson | that was exciting | 12:26 |
| Chipzz | exciting? sounds confusing instead | 12:26 |
| Laney | scary | 12:26 |
| Laney | I just got a prompt which just said "Password: " and kept respawning when dismissed | 12:26 |
| Nafai | 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:27 |
| Chipzz | Nafai: I recently fixed my .vimrc to work with vim-tiny | 12:28 |
| Chipzz | I was getting annoyed at vim-tiny throwing sh*tload of errors upon starting with my .vimrc | 12:28 |
| Chipzz | (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 |
| cjwatson | 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 |
| cjwatson | (the current /usr/bin/which on Debian/Ubuntu actually descends from that) | 12:29 |
| Chipzz | http://chipzz.safehex.be/docs/vimrc | http://chipzz.safehex.be/docs/bashrc | http://chipzz.safehex.be/docs/screenrc | 12:30 |
| Chipzz | hrrrrm my .bashrc is missing some useful stuff | 12:31 |
| Chipzz | http://chipzz.safehex.be/docs/bashrc | http://chipzz.safehex.be/docs/sshrc | 12:33 |
| Chipzz | [ "$SSH_AUTH_SOCK" ] && export SSH_AUTH_SOCK=$HOME/.ssh/@`hostname -s`.agent | 12:34 |
| Chipzz | that in conjunction with my .ssh/rc is a nice way of getting screen and ssh agent forwarding to work together | 12:34 |
| Chipzz | (but keep in mind to set proper permissions on ~/.ssh !) | 12:36 |
| === kentb-out is now known as kentb | ||
| dholbach | can somebody moderate my mail through u-d-a? | 13:41 |
| hallyn | 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:56 |
| hallyn | 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? | 13:58 |
| smb | 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:00 |
| smb | 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:01 |
| hallyn | 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 |
| hallyn | smb: what kills me is anytime i try to have udevd print out the list of pending events, i can't reproduce it :) | 14:03 |
| smb | 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:05 |
| smb | hallyn, And yes, a pretty Heissen-bug | 14:06 |
| hallyn | makes me feel like i wasted the afternoon, btw | 14:06 |
| hallyn | smb: are you working that bug today? | 14:06 |
| smb | hallyn, No its sort of on a backlog | 14:07 |
| hallyn | k | 14:07 |
| hallyn | smb: with xen, is there a way from the host to slow down (renice) the backign store process separately from the domain itself? | 14:07 |
| smb | hallyn, If there is I don't know of one. It seemed to happen relatively reliable on some boots on my server | 14:08 |
| smb | But I yet, have to confirm whether the dumps would be usable in crash now with the new pvgrub I got | 14:09 |
| hallyn | ok, thx smb. ttyl | 14:09 |
| ScottK | barry: I ran across something yesterday I thought you'd love: https://github.com/whymirror/unholy | 14:18 |
| barry | ScottK: oh wow | 14:19 |
| doko | ScottK, please could you have a look at the patch in bug 770975? still ftbfs for me ... | 14:21 |
| ubottu | 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:21 |
| ScottK | 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:27 |
| cjwatson | mvo: do you have any updated assessment of whether porting update-notifier to libappindicator might be feasible for oneiric (bug 779382)? | 14:45 |
| ubottu | Launchpad bug 779382 in unity (Ubuntu Natty) "update-notifier not visible under unity" [High,Triaged] https://launchpad.net/bugs/779382 | 14:45 |
| cjwatson | mvo: also I don't suppose you've managed to get anywhere with bug 848659 ... | 14:47 |
| ubottu | 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 |
| kees | 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:47 |
| mvo | cjwatson: let me check | 14:51 |
| Nafallo | 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 |
| ubottu | Launchpad bug 736743 in grub2 (Ubuntu Oneiric) "environment block not implemented on btrfs" [Wishlist,Triaged] https://launchpad.net/bugs/736743 | 14:59 |
| cjwatson | Nafallo: uh, maybe, I'm not in general comfortable with that approach but would need to look | 15:01 |
| cjwatson | I mean, it does genuinely cause limited functionality | 15:02 |
| didrocks | 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 |
| slangasek | 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:03 |
| Nafallo | 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 |
| cjwatson | Nafallo: pretty sure it makes sod-all difference to speed | 15:04 |
| didrocks | 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:04 |
| Nafallo | cjwatson: heh, you might be right. I'm happy to clock the difference if you want to give it a go :-) | 15:05 |
| cjwatson | didrocks: well, lb config *is* called before, isn't it? | 15:05 |
| cjwatson | didrocks: and yes, pretty sure it needs to be | 15:05 |
| didrocks | cjwatson: indeed, ok, so not that, I don't see any log of the package being installed | 15:05 |
| mvo | cjwatson: I'm on it, seb128 is a great help | 15:06 |
| mvo | cjwatson: on the indicator stuff | 15:06 |
| cjwatson | didrocks: it ought to work from what I can see - can you file a bug with a log? | 15:07 |
| didrocks | mvo: cjwatson: FYI, update-notifier should be visible in unity since beta2, I whitelisted it | 15:07 |
| cjwatson | mvo: great, thanks | 15:07 |
| cjwatson | didrocks: yeah, I noticed that, but not unity-2d right? | 15:07 |
| didrocks | cjwatson: sure, doing that | 15:07 |
| didrocks | cjwatson: unity-2d as well | 15:07 |
| didrocks | at least, was working when I tested it | 15:07 |
| didrocks | (if you turn the right gsettings options of course to get update-notifier showing its icon) | 15:07 |
| mvo | didrocks: ? awsome | 15:08 |
| cjwatson | oh, right, I missed that that task had been marked Invalid | 15:08 |
| mvo | didrocks: so the fix is actually not that urgent anymore? that is good news and may safe my friday | 15:08 |
| didrocks | 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 |
| ubottu | 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 |
| didrocks | mvo: yeah, you can enjoy your week-end and it's just a "nice to have" now :) | 15:09 |
| didrocks | cjwatson: if it's considered as a security issue, we should whitelist it in natty as well btw | 15:09 |
| cjwatson | we should either whitelist it or port it there, yes | 15:10 |
| didrocks | port it for natty? doesn't it sound risky? (whitelist is just a gsettings key away, not that I found the WMCLASS) | 15:10 |
| hallyn | 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:11 |
| smoser | slangasek, would you consider the trivial patch to bug 856984 for oneiric ? | 15:12 |
| ubottu | 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 |
| hallyn | 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:12 |
| ppetraki | hallyn, readily available, no, but I can spare a blade for you. | 15:13 |
| cjwatson | didrocks: yeah, agreed | 15:13 |
| slangasek | smoser: I think your { } are redundant and should be dropped, but otherwise yes, I think that looks sane | 15:14 |
| smoser | they're not redundant | 15:14 |
| smoser | to avoid the error of failed write going to stderr | 15:15 |
| smoser | you can test if you'd like | 15:15 |
| smoser | $ sh -c ': >> /etc/passwd 2>/dev/null' | 15:15 |
| smoser | sh: /etc/passwd: Permission denied | 15:15 |
| smoser | versus | 15:15 |
| smoser | sh -c '{ : >> /etc/passwd; } 2>/dev/null' | 15:15 |
| hallyn | 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 |
| ppetraki | hallyn, sounds like fun :) | 15:16 |
| hallyn | ppetraki: which, i suppose, is really a foundations team thing... | 15:16 |
| hallyn | but we can beg to be in the loop :) | 15:16 |
| ppetraki | heh | 15:16 |
| smoser | i probably *do* uses {} more than other people in shell scripts (especially around variable names), but here they're actually useful | 15:16 |
| slangasek | smoser: ah, because the redirect is done by the parent shell, not by :, check | 15:17 |
| slangasek | smoser: yes, go for it then | 15:17 |
| smoser | well, the {} mean its all one shell | 15:17 |
| smoser | no subshell | 15:17 |
| smoser | just redirect | 15:17 |
| smoser | but yeah. | 15:17 |
| smoser | thanks. | 15:17 |
| smoser | slangasek, what do you think about the general behavior of '[ -w file ]' not working during a remount,rw ? | 15:18 |
| didrocks | cjwatson: bug #857494 FYI | 15:18 |
| ubottu | Launchpad bug 857494 in live-build (Ubuntu) "package in config/chroot_packages/ isn't installed in the chroot" [Undecided,New] https://launchpad.net/bugs/857494 | 15:18 |
| slangasek | smoser: sounds like a kernel bug to me | 15:18 |
| cjwatson | thanks | 15:18 |
| cjwatson | smoser: access(3) (which is what that does) has always been a bit wonky | 15:19 |
| didrocks | yw :) | 15:19 |
| smoser | i suspect it is not a kernel bug, slangasek but user space | 15:19 |
| cjwatson | it basically tests the permission bits on the inode | 15:19 |
| cjwatson | sorry, access(2) | 15:19 |
| slangasek | smoser: I defer to cjwatson | 15:19 |
| smoser | yeah, me too | 15:19 |
| cjwatson | I think I would want to attempt an actual open(O_WRONLY|O_APPEND) or something in order to tell whether writes are really possible | 15:20 |
| cjwatson | oh, and that's what >> does | 15:20 |
| jdstrand | doko: heh, thanks for the honor of ubuntu-mir membership :) | 15:21 |
| cjwatson | hm, admittedly the man page says: | 15:21 |
| cjwatson | EROFS Write permission was requested for a file on a read-only file system. | 15:21 |
| jdstrand | doko: I guess I need to read up on the MIR docs ;) | 15:21 |
| doko | jdstrand, I thought you wouldn't mind :) | 15:21 |
| cjwatson | so maybe this is a kernel bug, although I suspect you might find they say the docs are misleading :) | 15:21 |
| cjwatson | but you can try asing | 15:21 |
| cjwatson | *asking | 15:21 |
| doko | slangasek, I'll check with mvo on Monday | 15:22 |
| tkamppeter | To the release team: I have uploaded ghostscript -0ubuntu9 and -0ubuntu10, it is important to take -0ubuntu10 as it completes an uncomplete fix in -0ubuntu9 (bug 856766). | 15:25 |
| ubottu | Launchpad bug 856766 in GS-GPL "gs crashed with SIGSEGV in gx_num_components_ICC()" [Medium,Confirmed] https://launchpad.net/bugs/856766 | 15:25 |
| dholbach | can somebody moderate my mail through u-d-a please? | 15:34 |
| cjwatson | dholbach: done | 15:41 |
| dholbach | thanks a lot cjwatson | 15:41 |
| doko | jtaylor, what about the upload for bug 845552? | 15:50 |
| ubottu | Launchpad bug 845552 in gfire (Ubuntu) "[FFE] Too old Gfire in repo for use, update version or remove from archive" [Undecided,Confirmed] https://launchpad.net/bugs/845552 | 15:51 |
| === antoniojasr_ is now known as antoniojasr | ||
| === beuno is now known as beuno-lunch | ||
| SpamapS | doko: re bug 771121 it actually just needs swig 2.0 | 16:18 |
| ubottu | 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 | 16:18 |
| doko | SpamapS, could you upload a fix for oneiric? | 16:20 |
| SpamapS | doko: in progress :) | 16:20 |
| doko | thanks! | 16:21 |
| bambee | pitivi is not installable... (it depends on python-gst0.10 >= 0.10.28, this dependency is not found) -> is it a bug or my mirrors are outdated? | 16:40 |
| bambee | http://paste.ubuntu.com/695730/ | 16:41 |
| SpamapS | gst0.10-python | 0.10.21-2ubuntu1 | oneiric | source | 16:43 |
| SpamapS | bambee: archives are up to date | 16:43 |
| bambee | 0.10.21 < 0.10.28 :) | 16:45 |
| SpamapS | yep | 16:45 |
| SpamapS | meaning its a bug | 16:45 |
| SpamapS | bambee: I suggest you report it.. I'll raise it to Critical and target to ubuntu-11.10 | 16:45 |
| bambee | SpamapS: ok | 16:46 |
| ScottK | I think that's fixed already | 16:46 |
| ScottK | bambee: Check for a newer pitivi. | 16:46 |
| SpamapS | oh like, in the last 2 hours? :p | 16:47 |
| bambee | ScottK: already tried, nothing changed | 16:47 |
| ScottK | Like earlier today. | 16:47 |
| bambee | oh | 16:47 |
| SpamapS | indeed, uploaded but not done building | 16:48 |
| SpamapS | pitivi | 0.14.91-0ubuntu2 | oneiric | source | 16:48 |
| ScottK | https://launchpad.net/ubuntu/+source/pitivi/0.14.91-0ubuntu2 | 16:48 |
| seb128 | SpamapS, that's the correct version | 16:48 |
| bambee | "Fix python-gst0.10 dependency which made PiTiVi uninstallable" <-- indeed, already fixed | 16:49 |
| SpamapS | uploaded 2 hours ago | 16:49 |
| seb128 | it's done building | 16:49 |
| bambee | ok, thanks | 16:49 |
| SpamapS | bambee: so yeah, your mirror just needs to catch up :) | 16:49 |
| bambee | hehe ;) | 16:49 |
| === beuno-lunch is now known as beuno | ||
| jtaylor | 17:50 <doko> jtaylor, what about the upload for bug 845552? <-- still no upload rights :/ | 17:03 |
| ubottu | Launchpad bug 845552 in gfire (Ubuntu) "[FFE] Too old Gfire in repo for use, update version or remove from archive" [Undecided,Confirmed] https://launchpad.net/bugs/845552 | 17:03 |
| ScottK | jtaylor: Is it in the sponsor's queue? | 17:12 |
| jtaylor | merge requests are there automatically or? | 17:12 |
| jtaylor | yup it is | 17:13 |
| ScottK | K. | 17:13 |
| tkamppeter | My upload of ghostscript 9.04~dfsg-0ubuntu9 got rejected. Is something wrong with it or is it because I have uploaded the -0ubuntu10? | 17:56 |
| seb128 | tkamppeter, 0ubuntu10 got accepted to I guess it's the later | 17:57 |
| infinity | tkamppeter: What Seb said. | 17:57 |
| seb128 | tkamppeter, no need to accept a version which is included and deprecated by the next one | 17:57 |
| infinity | tkamppeter: I rejected 9 and accepted 10. | 17:57 |
| tkamppeter | Not -0ubuntu10 appeares. Thanks and sorry for the noise. | 17:57 |
| slangasek | cjwatson: I happened to notice that I have ubuntu-xsplash-artwork installed here, and xsplash seems to be on autopilot since karmic; do you know if this package is still useful or if we should be looking at removing it? | 18:14 |
| SpamapS | smoser: nice fix on isc-dhcp-4 .. funny how there can be too very different versions of what "writable" means ;) | 18:18 |
| smoser | yeah, i'm wondering if there are other pars of boot that are making similar assumptions/mistakes | 18:19 |
| smoser | s/pars/parts/ | 18:19 |
| broder | i'm still confused why access() would say yes when open() would say no | 18:21 |
| SpamapS | you're allowed | 18:21 |
| SpamapS | you're just not ABLE | 18:21 |
| SpamapS | its like giving a two year old a driver's license. :) | 18:21 |
| broder | SpamapS: no, i don't think it's that. smoser's bug report makes it sound like there's actually a race there | 18:22 |
| smoser | no | 18:22 |
| smoser | its not a race | 18:22 |
| smoser | its consistent | 18:22 |
| smoser | [ -w file ] says yes, attempt says no | 18:22 |
| smoser | and then again | 18:22 |
| smoser | and then both say yes | 18:23 |
| broder | oh, i see. [ -w ] returns yes when it's ro? | 18:23 |
| smoser | i suspect that what is happening is this: | 18:23 |
| smoser | a.) mount is read-only (at which point both say 'not writable') | 18:23 |
| smoser | b.) mountall invokes 'mount()' system call for remount,rw | 18:24 |
| smoser | c.) [ -w file ] says "YES", but attempts to actually write fail | 18:24 |
| smoser | d.) kernel finishes actually making filesystem rw | 18:24 |
| smoser | e.) [ -w file ] says yes, attempts to write succeed | 18:24 |
| broder | right. and my question is why are the paths that access() and open() take sufficiently different that (c) is even possible | 18:24 |
| smoser | window between b and d is very small, i'm only seeing it here because i'm using qcow compressed image that is freaking crazy slow read and write | 18:25 |
| smoser | broder, well, cjwatson's comment was that 'access()' has always been 'a bit wonky' | 18:25 |
| broder | yeah, that just seems unfortunate and error-prone. even if we audit for things that depend on access() actually working, that doesn't solve the problem in the long term | 18:28 |
| broder | and it's just another thing we have to add to the list of "weird unix arcana that will bite you in the rear one day" | 18:29 |
| smoser | i recall having seen issues like this with nfs also | 18:30 |
| broder | i can accept network filesystems as being a special case | 18:30 |
| broder | maybe the better solution would be to change bash to implement -r, -w, etc. using open directly | 18:32 |
| broder | since i don't actually think people use access() that often from C | 18:32 |
| smoser | broder, the issue with open is that actually has side affects | 18:34 |
| smoser | even if file exists, you would be updating ctime. | 18:35 |
| broder | there's a O_NOATIME at least, but yeah, i guess you can't prevent it from affecting ctime | 18:36 |
| smoser | well, and you'd actually be creating it | 18:37 |
| smoser | if it did not exist | 18:37 |
| broder | only if you pass O_CREAT | 18:37 |
| smoser | but if the file did not exist, how would you know if you could write to it using open unless you passed O_CREATE? | 18:38 |
| smoser | access() i think is supposed to say "yeah, you could potentially create that file" | 18:39 |
| cjwatson | slangasek: I think we should probably kill it though I'm not certain | 18:43 |
| cjwatson | access() from C is pretty common | 18:43 |
| cjwatson | I think it's probably better to fix access(), I just don't know whether it's sanely possible | 18:44 |
| SpamapS | Somebody remind me.. a Breaks + Replaces will cause dist-upgrade to remove the broken/replaced package and install the new one, right? | 19:13 |
| micahg | SpamapS: it should and generally, breaks/replaces is versioned | 19:14 |
| SpamapS | indeed | 19:15 |
| slangasek | SpamapS: to be sure, it causes the broken/replaced package to be removed when upgrading or installing the breaking package; if the breaking package is not already going to be pulled in, having the breaks/replaces doesn't cause a dist-upgrade to pull it in | 19:25 |
| SpamapS | slangasek: right.. hm | 19:44 |
| SpamapS | slangasek: if I have a Provides does that force dist-upgrade's hand? | 19:44 |
| slangasek | SpamapS: nope | 19:59 |
| infinity | SpamapS: Provides doesn't imply a Conflict. What are you actually trying to achieve? | 19:59 |
| slangasek | SpamapS: generally for that, you add a transitional package with the name of the old one | 19:59 |
| slangasek | or you make your metapackage depend on the new one or something | 19:59 |
| slangasek | smoser: how reproducible is bug #833783? this is going to take some iterating | 20:00 |
| ubottu | Launchpad bug 833783 in initramfs-tools (Ubuntu Oneiric) "boot failure: can't open /root/dev/console: no such file" [High,Confirmed] https://launchpad.net/bugs/833783 | 20:00 |
| smoser | slangasek, hm.. | 20:00 |
| smoser | unfortunately, i dont really know. | 20:00 |
| smoser | i would have told you it was on the order of 1/30 | 20:01 |
| smoser | but the last set of tests, i believe that I saw a failure where the kernel rebooted itself. | 20:01 |
| smoser | ie, as if i a watchdog kicked in. | 20:01 |
| smoser | i didn't think that i'd seen that behavior before | 20:01 |
| smoser | but if that is happening, then we may be hitting it more than i thought, and i just didn't know it. | 20:02 |
| smoser | i know. that wasn't very helpful. | 20:02 |
| slangasek | smoser: ok. basically, my *suspicion* is that we're racing udev because the initramfs has so little to do that it gets to the bottom faster than udev can blink; but I'd like to be able to verify that | 20:02 |
| smoser | that makes sense. | 20:03 |
| slangasek | smoser: you could test this by adding [ -e /dev/console ] || udevadm settle to /usr/share/initramfs-tools/scripts/init-bottom/udev and testing | 20:04 |
| smoser | is /dev/console always the same major minor? | 20:04 |
| slangasek | if that works, it's probably the same as our other udevadm --exit bug | 20:04 |
| slangasek | (*probably*) | 20:04 |
| smoser | or does it depend on platform.... | 20:04 |
| slangasek | I think it's always the same major/minor | 20:04 |
| slangasek | so yes, this could be hacked around with hard-coding | 20:04 |
| smoser | if its always 5,1, then just having that in /dev/ would fix this issue | 20:04 |
| smoser | right | 20:05 |
| smoser | i realize htat is a hack | 20:05 |
| slangasek | in fact, you'll see initramfs scripts have code for a mknod fallback already | 20:05 |
| slangasek | right at the top of init | 20:05 |
| smoser | ok. | 20:05 |
| smoser | so we're hitting the bottom, calling udevadm --exit, before udev makes /dev/console | 20:06 |
| slangasek | I'm afraid I don't understand this bit of the kernel either, though... can we be sure that /dev/console is always there on the kernel side? | 20:06 |
| slangasek | i.e., would mknod be sufficient, or is it possible the kernel itself would throw errors? | 20:06 |
| slangasek | I'm to the point where I don't trust devices to really be there until udev tells me they are ;) | 20:06 |
| smoser | i'm not certain. but it would surely seem that /dev/console is pretty basic. the kernel has to printk to somewher,e and i always just assumed that was "dev/console" | 20:07 |
| slangasek | smoser: but definitely a '[ -e /dev/console ] || udevadm settle' is the first thing to try | 20:07 |
| slangasek | oh sure, it's pretty basic | 20:07 |
| slangasek | but everything's getting so fast now that we're racing every last bit of the kernel's init code, AFAICS | 20:07 |
| smoser | slangasek, https://bugs.launchpad.net/ubuntu/+source/linux-ec2/+bug/682831 | 20:09 |
| ubottu | Ubuntu bug 682831 in plymouth (Ubuntu Lucid) "lost console output early in boot" [Undecided,Triaged] | 20:09 |
| smoser | thats my prior experience with /dev/console, and it not always being there :) | 20:09 |
| smoser | oh, but wait, that was a plymouth issue | 20:09 |
| slangasek | see! I'm not just paranoid :) | 20:09 |
| smoser | never mind that. | 20:10 |
| slangasek | ah ;) | 20:10 |
| superm1 | archive admin, can you please axe the libhdhomerun upload that i just sponsored? Daviey raised a point that we didn't realize it was in debian and synced from there and we've got a bad delta in the debian/ stuff now for it | 20:10 |
| infinity | superm1: Sure. | 20:10 |
| slangasek | infinity: too slow | 20:10 |
| slangasek | superm1: done | 20:10 |
| superm1 | thanks slangasek | 20:10 |
| infinity | :P | 20:10 |
| * ScottK is even more too slow. | 20:10 | |
| slangasek | :) | 20:10 |
| smoser | slangasek, tell ya what. | 20:10 |
| smoser | if you can give me a diff of the file to change, then i'll attempt leave a script launching instances on CanoniStack all weekend with and without | 20:11 |
| smoser | and see if we see actual improvements | 20:11 |
| slangasek | smoser: yeh, diff is in preparation now :) | 20:11 |
| slangasek | smoser: so in general, would an initramfsless boot do you guys some good? | 20:13 |
| smoser | we've been there | 20:13 |
| smoser | and came back | 20:13 |
| slangasek | whyso? | 20:13 |
| smoser | we dont need an initramfs really. and in lucid, we didn't have it. | 20:13 |
| slangasek | the kernel package tooling needs help for supporting the initramfsless case | 20:13 |
| smoser | it was a real benefit in it was less things to manage on ec2, where you had to upload a kernel and a ramdisk separately | 20:13 |
| slangasek | but that's solvable | 20:14 |
| slangasek | and helps with several different problems in parallel | 20:14 |
| smoser | but when we moved to using pv-grub, which allowed us kenrel upgrades!!!! i never bothered to fight update-initramfs and the kernel hooks and such to stay a different path. | 20:14 |
| smoser | so we got our initramfs back. | 20:14 |
| slangasek | the other Good fix for the problems you guys've been seeing in the initramfs is to get event-based initramfs... too bad we didn't make it there for this cycle :/ | 20:14 |
| smoser | and then, i built a feature or 2 into our cloud initramfs that i'm not likely to want to give up. | 20:15 |
| slangasek | hah | 20:15 |
| SpamapS | ensemble has been renamed to juju | 20:15 |
| SpamapS | to answer the question late | 20:15 |
| === m4n1sh_ is now known as m4n1sh | ||
| SpamapS | so we want the bin package to be called juju.. but anybody who has had ensemble up to now we want to get juju to replace it. | 20:15 |
| slangasek | SpamapS: right, ensemble dummy package Depends: juju package Replaces:/Breaks: real version of ensemble package is the canonical solution | 20:16 |
| SpamapS | slangasek: ty :) | 20:17 |
| smoser | slangasek, http://ubuntu-smoser.blogspot.com/2011/07/getting-larger-root-volume-on-cluster.html is a feature that is very useful. | 20:17 |
| slangasek | SpamapS: or, if ensemble would always be installed as a dependency of some other leaf package that would be installed, you can just switch the dependency and dispense with the dummy package... but I suspect 'ensemble' will be in the name of the relevant top-level packages :) | 20:17 |
| smoser | much less so on ec2, but now on openstack all instances will take that path. | 20:17 |
| slangasek | smoser: heh, too bad. I guess we should regroup on the event-based initramfs question for next cycle then | 20:18 |
| slangasek | apw: btw, I think my black screen between grub and plymouth is an initramfs-specific issue... I can reproduce it on my T60, and should have a cryptsetup-less test soon for comparison. I think either something's missing from the initramfs, or we're again racing udev somehow | 20:19 |
| smoser | slangasek, is there a bug open that we consider *the* bug for "udev --exit does not flush queue" ? | 20:21 |
| smoser | it seems its coming up more and more often, and i think it is the root of many bugs, but i didn't know if there was one bug that those others should actually be duped to | 20:22 |
| slangasek | smoser: bug #818177 is the one I know about | 20:22 |
| ubottu | Launchpad bug 818177 in udev (Ubuntu Oneiric) "HP DL380G5 root disk mounted read-only on boot and boot fails" [High,Confirmed] https://launchpad.net/bugs/818177 | 20:22 |
| slangasek | smoser: I wouldn't start duping bugs to it until we actually prove that's what's happening though | 20:22 |
| smoser | i thought it was known fact that it does not flush queue | 20:23 |
| slangasek | not known to me | 20:24 |
| slangasek | but I'm not a udev expert, either :/ | 20:24 |
| slangasek | smoser: patch posted: https://bugs.launchpad.net/ubuntu/oneiric/+source/udev/+bug/833783/+attachment/2449493/+files/udev-must-provide-console-833783.patch | 20:24 |
| ubottu | Ubuntu bug 833783 in udev (Ubuntu Oneiric) "boot failure: can't open /root/dev/console: no such file" [High,Confirmed] | 20:24 |
| cjwatson | I think it's true that it doesn't flush the queue, but nobody worried about it before because udev in the real root was meant to catch up all events | 20:28 |
| cjwatson | but /dev/console is used between udevadm control --exit and udev starting in the real root ... | 20:28 |
| slangasek | indeed | 20:28 |
| slangasek | and previously, udev happened to always get around to creating /dev/console before being stopped | 20:28 |
| cjwatson | I don't think it would be desperately hard to fix in udev for somebody who had a spare couple of hours | 20:29 |
| cjwatson | smoser: so, speaking of Xen, today I've found and am fixing three separate bugs all of which were independently installation blockers for a friend's colo hosting company that uses Xen guests | 20:30 |
| cjwatson | smoser: I'm kind of interested that none of those bugs appeared to be biting us :-) | 20:30 |
| cjwatson | bug 720558, bug 857548, and bug 857662 | 20:30 |
| ubottu | Launchpad bug 720558 in grub (Ubuntu Natty) "Ubuntu 10.04 currently requires groot= workaround with pvgrub" [High,Triaged] https://launchpad.net/bugs/720558 | 20:30 |
| ubottu | Launchpad bug 857548 in grub-installer (Ubuntu Oneiric) "no longer possible to select GRUB Legacy by preseeding" [High,Triaged] https://launchpad.net/bugs/857548 | 20:30 |
| ubottu | Launchpad bug 857662 in hw-detect (Ubuntu Oneiric) "Should xenbus_probe_frontend be built-in?" [High,Triaged] https://launchpad.net/bugs/857662 | 20:30 |
| cjwatson | smoser: do you have workarounds for any of those that I don't know about, or is it just that your boot setup is sufficiently different that you dodge them? | 20:31 |
| cjwatson | I guess you're using preinstalled AMIs ... | 20:31 |
| cjwatson | kind of surprised that xen-netfront autoloading isn't a problem though | 20:31 |
| cjwatson | unless you use -virtual I guess | 20:32 |
| smoser | 720558 is worked around by grub-legacy-ec2 | 20:32 |
| smoser | 857548 is worked around by the presense of grub-legacy-ec2 (as it does not conflict with grub2) | 20:32 |
| smoser | 857662 we dont hit that in our installs because we dont install with installer | 20:33 |
| smoser | that said, i do know that installation as a guest under xen has been broken | 20:33 |
| smoser | i believe that xen-netfront autoloading is a problem...i think there was a discussion recently on ubuntu-server mailing list to that reguard. | 20:34 |
| cjwatson | smoser: conflicts aren't relevant to 857548, but not using d-i would be :-) | 20:35 |
| smoser | right. | 20:35 |
| cjwatson | smoser: so I wonder if grub-legacy-ec2 can go away once I've fixed that bug in grub? or is there more? | 20:36 |
| cjwatson | I'm going to work around xen-*front autoloading in hw-detect | 20:36 |
| smoser | the only real reason for grub-legacy-ec2 is to manage /boot/grub/menu.lst and install along side grub2 | 20:36 |
| cjwatson | it'll work as long as you're using the -virtual flavour | 20:36 |
| cjwatson | (for the installed system, since then we don't need userspace tweaks too) | 20:37 |
| cjwatson | can you remind me why you need grub2 installed? | 20:37 |
| smoser | because those images work with "normal bios booting" via grub2 and pv-grub booting via the managed /boot/grub/menu.lst | 20:38 |
| cjwatson | oh, dual running | 20:38 |
| cjwatson | ok | 20:38 |
| smoser | so as soon as you get me a pv-grub2, *then* we can ditch the grub-legacy-ec2 | 20:38 |
| smoser | and i'll be happy | 20:38 |
| smoser | :) | 20:38 |
| cjwatson | yeah, that's a *little* further off | 20:38 |
| cjwatson | owing to no time this cycle | 20:38 |
| smoser | oh comeon... its not like have anything else to work on | 20:38 |
| cjwatson | heh | 20:40 |
| Daviey | cjwatson: Is it too late to change the d-i background colour slightly? | 20:45 |
| * Daviey jests. | 20:46 | |
| cjwatson | ahahabonk | 20:47 |
| slangasek | blah, why is launchpad marking bugs like 798509 confirmed? | 21:13 |
| micahg | slangasek: they affect multiple people | 21:14 |
| charlie-tca | newest thing. any comment or duplicate lets launchpad automatically confirm the bug | 21:14 |
| slangasek | micahg: "like 798509" is the key expression there :) | 21:14 |
| slangasek | it's a duplicate of a fix-released bug | 21:14 |
| charlie-tca | It really fails on most, since nothing but a comment by anyone will cause it to go "confirmed" | 21:15 |
| micahg | slangasek: that should be a bug | 21:15 |
| ScottK | superm1: Is the hdhomerun-config-gui upload you just sponsored bug fix only? | 21:16 |
| micahg | slangasek: do you want to file the report or should I ? | 21:16 |
| slangasek | micahg: filing | 21:16 |
| slangasek | micahg: bug #857777 | 21:17 |
| ubottu | Launchpad bug 857777 in Launchpad itself "launchpad janitor generating noise by 'confirm'ing duplicate bugs" [Undecided,New] https://launchpad.net/bugs/857777 | 21:17 |
| micahg | slangasek: thanks | 21:18 |
| ScottK | Nice. Because it didn't send enough bugmail already, I guess. | 21:18 |
| charlie-tca | It is kind of frustrating to see a bug report, someone asks a question on it, and leaves it in "New", and launchpad confirms it because of the comment | 21:20 |
| slangasek | pitti: the fix for bug #854329 is staged in bzr for gdm and lightdm; any objections to me uploading it? (I can't upload the plymouth side until those are uploaded) | 21:22 |
| ubottu | Launchpad bug 854329 in xdm (Ubuntu Oneiric) "race condition on shutdown with more than one DM installed" [Low,Triaged] https://launchpad.net/bugs/854329 | 21:22 |
| micahg | slangasek: FYI, he's on holiday today | 21:23 |
| slangasek | oh, well, that makes it easy then... no one around to tell me no ;) | 21:24 |
| micahg | heh | 21:24 |
| slangasek | ScottK: do you know if anyone's interested in working on the kdm part of bug #854329? | 21:52 |
| ubottu | Launchpad bug 854329 in xdm (Ubuntu Oneiric) "race condition on shutdown with more than one DM installed" [Low,Triaged] https://launchpad.net/bugs/854329 | 21:52 |
| ScottK | slangasek: No. If it's cargo culting something from some other DM, I can probably manage, but maybe debfx. | 22:02 |
| slangasek | ScottK: it's pretty cargo-cult, yeah :) | 22:07 |
| superm1 | ScottK, yes, silicon dust hasn't added new features in ages | 22:14 |
| === kentb is now known as kentb-out | ||
| ScottK | superm1: Accepted. | 23:08 |
| ScottK | OK. Taking a look. | 23:16 |
| ScottK | Amazing how cleanly gdm.upstart and kdm.upstart diff against each other and yet they have completely different authors listed. | 23:31 |
| mr_pouit | Archive admins: I've synced garcon, and I guess it sits in unapproved. I can't link to the bug report though, so if needed, the FFe is Bug #857718. Thanks. | 23:32 |
| ubottu | Launchpad bug 857718 in garcon (Ubuntu) "[FFe] garcon 0.1.9" [Undecided,Confirmed] https://launchpad.net/bugs/857718 | 23:32 |
| slangasek | ScottK: there seems to have been some confusion about the meaning of the field; I'm pretty sure the gdm upstart job wasn't written by GDM upstream... | 23:34 |
| slangasek | mr_pouit: accepted | 23:34 |
| ScottK | slangasek: Seems sufficiently cargo cultable. I got it. | 23:34 |
| jbicha | ooh, dpkg 1.16.1 automatically unapplies patches at the end of building | 23:35 |
| slangasek | ScottK: yay :) | 23:35 |
| mr_pouit | slangasek: thanks! | 23:35 |
| jbicha | that should help clean up the .pc mess, right? | 23:35 |
| ScottK | Nice. Found some additional changes to steal. | 23:44 |
| ScottK | jbicha: Only if they weren't applied at the start. | 23:44 |
| * SpamapS wonders why display managers don't have one upstart job that calls the currently selected default.... | 23:47 | |
| slangasek | SpamapS: because the way you call the currently selected default varies significantly | 23:49 |
| SpamapS | of course it does, that makes perfect sense, every DM is a special snowflake | 23:50 |
| slangasek | SpamapS: feel free to impose a standard invocation on all the upstreams in your copious free time :) | 23:50 |
| SpamapS | slangasek: indeed, I will have to go in search of more round tuits. | 23:51 |
| ScottK | SpamapS: FYI, just for added fun, kdm upstream is widely viewed as one of the most socially ept KDE developers .... | 23:54 |
| ScottK | slangasek: I pushed it to kde-workspace bzr. Need to finish looking at patches to cherrypick from upstream before uploading. | 23:55 |
| slangasek | ScottK: spiff, thanks | 23:56 |
| ScottK | barry: Accepted. | 23:56 |
| barry | ScottK: awesome, thanks. i probably won't get to retrying omniorb until tomorrow | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!