[00:05] infinity: Would now work for a discussion of syslog? [00:06] slangasek: I realise I never got back to you: under the prior system, after waiting for the (same class) of issues for MC quorum, applicants would need TB quorum, which was less frequent then than now. This isn't to say that current latency is good. [00:06] * slangasek nods [00:09] slangasek: Would a dh_multiarch make sense to process {install,links,maintainerscripts} in a way that doesn't bind debhelper and can be incorporated back into debhelper later once proved? Mesa's gaining far to many *.in files :( [00:11] RAOF: it's not a question of proving it, I'm afraid it became a political issue with the maintainer; there's a chance this might get sorted next week at DebConf [00:15] While there are sometimes techincal solutions to social problems, rarely are there technical solutions to political problems. :( [00:15] There's no useful distinction between "social problem" and "political problem". [00:16] Solving both means getting interested folk to agree (often on some compromise). Changing the technical environment can change the framework of the debate, and make compromise easier to achieve. [00:17] (consider $EDITOR and sensible-editor as technical solutions to political problems) [00:18] Ah, indeed. I still hold a definition of “social problem” and “political problem” that includes a useful difference, but that is indeed a fine example of a technical solution to a political problem. === jjohansen is now known as jj-afk [02:49] is there any developer from the team that decided that the 2.6.32 kernel is still the kernel on 10.04.3 update? [02:51] The decisions don't quite work like that. [02:51] 10.04.3 includes all the updates published when 10.04.3 was released. [02:52] We all agree that we don't like to change upstream versions of anything in an update, if we can help it, because there are invariably regressions for some users. [02:53] So, in some sense, all the developers are responsible for the 10.04.3 kernel being 2.6.32, and there was never significant explicit debate about the matter for any team. [02:57] persia: I thought that there was a team especially for that. I saw that it was on 10.04.3's launchpad page as a decision that it had to be clear and I wanted to learn more about that. [02:58] persia: so is it only for the reason you described before or there are more reasons? like stability, like it's tested more? and I 've not found such information on internet. [02:58] Which page? [02:58] If there was discussion, I'm also interested. [02:59] the kernel is a special case - there are backported kernels available which receive support [02:59] though I'm not sure to what degree [02:59] ajmitch: Very little. [02:59] But I can't imagine anyone generating official install images that used a backport kernel. [03:00] Support is to the degree developers are motivated. Anything else is wishful thinking. [03:00] infinity: that's useful to know [03:00] Discussion of the sources of developer motivation is left for another time. [03:01] there was some discussion at UDS about including the backport kernels with point releases, but i don't remember the details, and i don't think there were any conclusive actions [03:01] Really? More than just putting them in the pool as available? [03:01] the idea being that there's some expectation that you can take a CD, put it in a machine, and have it work [03:01] and for some hardware, you need the backport kernels to do that [03:02] but, i mean, there are obviously issues with regressions, disc space, etc. [03:02] the point release DVDs already ship with all the backport kernels, but i don't think anybody uses those [03:04] infinity, Since your idle counter is reset: I assert that systems without an installed syslog implementation are insufficiently Ubuntu to receive support through the typical channels. Refute. [03:05] persia: I assert that if you tried the usual support channels for support with a barebones rootfs, they'll fail you anyway. :P [03:05] persia: it was on the blueprints [03:05] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-kernel-decision [03:06] infinity, I can accept that assertion. Can you accept mine? [03:06] marios_manowar: That was deciding *before* lucid that it would use 2.6.32. [03:06] marios_manowar: uh, that's from back when lucid was first being developed [03:07] marios_manowar, Check the dates on that: that's from October 2009. [03:07] marios_manowar: That same discussion happens every cycle (the kernel team decides which version is their target, and works toward that) [03:07] Well, November, but it *should* have been submitted in October. [03:07] persia: Only because some of our "usual support channels" rely too heavily on scripted interactions with users, and would balk if a user said "well, I don't have logs." [03:08] ALL: ok, i feel stupid :-( [03:08] marios_manowar, And anyone is welcome to participate in the discussions as to which kernel should be used for each future release, although those planning to help maintain the kernel get more say, obviously. [03:09] infinity, Well, some of the scripts are executed on humans, but yeah, that's the source of my concern. [03:10] persia: Yes, I said scripted interaction, as in the "scripts" you get with phone support ("Have you power cycled it? We can't continue until you try that.") [03:11] I don't think the support teams are quite that bad. [03:11] persia: This is a different sort of product, which might require a different level of support, I'm personally okay with that. I mean, it doesn't have a kernel, it's not bootable, it's not installable. These seem like larger "normal support" issues than "it has no syslog by default". [03:11] Well then, any objection if I document that we can only provide support for users who have some syslog implementation installed? [03:12] People who don't need syslog probably don't need that much support, or can fake enough answers that nobody will notice. [03:12] persia: And yeah, some of the support channels are "that bad". I've seen bugs closed for "insufficient info" because people didn't respond to a request for dmesg and various unrelated logs after including CORRECT info (like, say, a gdb backtrace of an obvious null pointer segv or something). [03:14] I'm not sure that the support teams and the bugsquad still have significant membership overlap, but yeah, I've seen terrible behaviour in bugs. [03:14] It's probably worth trying to realign bugsquad and the support teams, but that requires a healthy supply of tuits. [03:14] persia: But we're planning to publish it with some sort of README to the effect of "this image will probably be useless without you doing some things to it: (list a few random things, like using it as a chroot, applying a kernel to it, whatever)" [03:15] persia: So, a mention of what might be required to make it "supportable" is fine by me, as long as the README doesn't get so long that people ignore it. ;) [03:15] I was thinking that documentation should come in two flavours: short and long. [03:16] Short is just quick sentences, and a pointer to long. [03:16] Long can be long-winded: it's not for the TL;DR crowd anyway. [03:17] infinity: these issues should be brought up on the bugsquad list so that people can learn from them [03:17] I will agree with persia in his/her documentation opinion [03:18] micahg: To be fair, I've had these issues for literally years. It's a battle I'm sick of fighting. [03:19] micahg: Culturally, top to bottom, we seem to have developed an allergy in Ubuntu to open bugs, and that colours everything we do. [03:19] micahg: And I'm from the school of "if it seems to be a legit bug, it's better to have it open for 6 years until someone gets around to fixing it than it is to close it and lose the reference because a user's report wasn't exactly what person N wanted". [03:20] infinity: well, there was a discussion about a year ago about that, and the conclusion was what you just said [03:20] and I brought this up at the last meeting to reinforce it [03:25] persia: Oh, and re: long vs short, I had planned for short to be a REAME in the publishing directory (or pretty HTML, if it lands on releases), with a wiki pointer yes. [03:26] The key is really constant vigilance. When we find such examples, we should try to recover them *and* make sure the person who made the mistake undersands their mistake *and* do so publically so that everyone else can also learn from that mistake, rather than making their own. [03:26] micahg: So, how do I go about affecting a culture shift in processes that I've considered broken for half a decade? :) [03:26] infinity, We can do pretty HTML in the publishing directory now, but yeah, that's the short, and the long would be a wiki page. [03:27] persia: The problem I've had in the past when re-opening false closures is that the triager seems to walk away with it not with a "I shouldn't have closed that bug because it was a real bug" attitude, but "I shouldn't have close that bug because that developer is insane and likes obscure bugs" attitude. [03:27] persia: IOW, I can't seem to drill the point home that a bug is a bug, even if it doesn't include the perfectly scripted question/answer that they think it should have. [03:28] infinity, We need a better way to organise the communications, but micahg is right that by sending mail to the bugsquad list with the criticism when that happens, folk are more likely to understand. [03:28] communication is important [03:29] (And I'm using the term "triager" loosely here, it's not just bugsquad, like I said, it's cultural. I've had closure/reopen wars with core-devs, bugsquad folks, random well-meaning community folk, and even the original reporters(!)) [03:29] lifeless, So, can we have a special checkbox in launchpad that indicates that the last commenter made a horrid mistake, and automatically sends the criticism to the bug contact? [03:29] oh I would love that [03:29] unsubscribed people making changes can be annoying [03:30] infinity, I suspect the majority of them are bugsquad: all developers are inherently bugsquad, and most random well-meaning folk probably clicked the "Sure, I look at bugs" button at some point. [03:30] When the original bug reporter says "well, this seems like a weird/hard/confusing bug where the solution can't be readily determined from a 5 question script sequence" and I respond with "uh, no, what you've reported is a real bug, and we'll look into it when we have time", we have a serious culture problem. [03:30] lifeless, It's not just the unsubscribed being annoying, it's also for greater cohesion in the bug contact team. [03:31] infinity, Yes. [03:31] one way would be a reply-to function 'reply to a comment' vs 'comment on the bug' [03:31] we could use that to notify even unsubsubscribed folk [03:31] Wouldn't have the same name-and-shame benefit. [03:31] needs some design work around the concept [03:31] Unless we cc: all those to the bug contact for the project. [03:32] persia: it would still show as a comment on the bug [03:32] persia: which is plenty of name and shame [03:32] lifeless, I think you underestimate how many bugs there are in Ubuntu. [03:32] persia: And okay, almost everyone may qualify as "bugsquad" if they're developers, but that doesn't mean we all dedicate time to actually doing bugsquadish things, or that we all subscribe to lists and such. [03:32] persia: I suspect I know better than you, given how much time I spend optimising LP to deal with them :> [03:32] Most active members of bugsquad only see a very limited subset, but they all ought see bug comment criticism. [03:33] infinity, OK. Fair. [03:35] lifeless, With the insight into the volume of bugs you gained there, do you still believe that a comment in a bug is likely to be seen by a majority of folk who care for bugs? [03:35] infinity: well, we have a special bugsquad team that's moderated, although the bar for entry is low [03:35] I think the real thing that I'd like to be able to communicate to anyone who does triaging is that the ultimate target audience of bug reports is developers, not triagers. I *love* that people want to help make bugs have more useful information or be reported more coherently before I get around to looking at them, but even if it's a badly-explained bug report, I'd prefer to see it and make that call than have someone else decide it's "not good enoug [03:36] infinity: and I agree with persia, we should bring up these issues when they happen on the ML and they can be discussed at the meetings as well [03:36] persia: the crucial thing is feedback to the people making mistake [03:36] s [03:36] infinity: should the standard for that be anything other than "if the bug was marked triaged, don't mark it incomplete"? [03:36] persia: so I'm not assessing the mechanism on the same metric you are [03:36] infinity: btw, have you responded to the bug workflow survey? :) [03:36] It takes me 3 seconds to read a bad bug report and decide it really is giberish, but it takes a lot more effort for me to trawl recent closures and look for ones that should be reopened. [03:36] infinity, I'd disagree with that: the ultimate audience of a bug report is someone able to provide a fix. I don't care how they self-identify, or what status they think they have, or where they found the fix. [03:37] persia: I think that qualifies as a developer in Ubuntu :) [03:37] lifeless, Ah, right. I'm considering feedback to the people that made the mistake, and also to the class of people likely to make the mistake and/or the person overseeing the folk likely to make mistakes (depending on how the specific project happens to have defined the bug contact) [03:37] persia: so the docs already guide away from this mistake [03:38] persia: Oh, sure, I don't mean capital-D Developer, whatever that might mean just, as you say "someone who might actually be able to fix the bug" (or legitimately prove that it's not a bug, not because it's short on info, but because it's obviously the user leaning on the "y" key while trying to type "q" or whatever) [03:38] micahg, I7d agree with you except for the number of bugs I've found with perfectly correct solutions to problems including a comment "I'm not a developers, but ...". [03:38] persia: overseers could probably watch (programatically) for status changes and audit easily enough [03:38] persia: right, because we overload the term developer in ubuntu and not everyone is aware of that [03:39] persia: I use the term "developer" loosely to mean "someone who's capable of working on the packages in some way", even if that's just providing a patch for a manpage (or, NOT providing a patch, but providing step-by-step instructions on how to fix it for someone who CAN patch it) [03:39] lifeless, The mistake of leaving a comment to derail a bug report? Sure, but having a bundle of specifics, and a motivation by triagers not to get their name on that list can sharpen the stake a bit. [03:39] (Another pet peeve of mine: people who think that without a well-formed patch, you don't have a fix) [03:39] slangasek: Survey? I may have missed this. [03:40] persia: I question the effect of negative reinforcement here [03:40] infinity: https://lists.ubuntu.com/archives/ubuntu-devel/2011-July/033652.html [03:40] micahg: Ahh, I haven't caught up on devel for a bit, thanks. [03:40] lifeless, I guess. I encourage peer review and peer criticism, as long as it stays respectful, and about the *mistake* rather than the person. [03:41] Without that, I fear we're all likely to just pretend everything is good all the time. [03:41] But any system that has logged peer review inherently can be described as providing negative reinforcement. [03:42] In which case, it's mostly a matter of making sure the activity is still exciting enough and rewarding enough that folks are willing to accept the potential for criticism. [03:43] persia: sure, but structuring it as 'keep your name off this list' is name-and-shame vs direct feedback (even in public) that a particular action doesn't meet expectations [03:44] slangasek: I think the problem with "incomplete" is that it's used and viewed as a negative thing. [03:44] lifeless, So, for Ubuntu, the public direct feedback belongs on the bugsquad ML (as we send criticisms of uploads to the devel ML). [03:44] why ? [03:44] lifeless, Which happens to be the bug contact for Ubuntu, so if LP cc'd the bug contact on these sorts of comments, it would work for Ubutnu. [03:44] slangasek: I prefer "moreinfo", where it's obvious that the bug is in a feedback loop with the submitter, but isn't necessarily a "bad bug" that must be purged at the earliest convenience. [03:45] so incomplete and moreinfo are separate concepts [03:45] infinity: hum; I consider it bad if a bug doesn't get the necessary information to triage it for a long time, whether that's called "incomplete" or "moreinfo", and I think it's reasonable to expire such bugs out after a while [03:45] I think we have over simplified and made the system harder to use as a result [03:45] lifeless: Incomplete is a broken-by-design concept, IMO. [03:45] infinity: in which regard? [03:46] persia: the bug contact isn't the bugsquad ML AFAICT, but the ubuntu-bugs list [03:46] slangasek: The problem I have with incomplete in a high volume system is that it's being marked that way by people who might not understand the bug in the first place. [03:46] slangasek: And possibly timing out before it ever gets to someone who COULD determine that it's "complete enough". [03:46] micahg, Ah, then Hrm. Anyway, needs user interaction design. [03:46] lifeless: ah, where "incomplete" is "insufficient info to confirm this is a real bug", and "moreinfo" is "real bug but we need help"? [03:46] slangasek: yes [03:47] infinity: you definitely need to fill out the survey :) [03:47] I've seen bugs that *are* complete enough that got timed out because nobody who could determine they were complete encountered them in the window. [03:47] ^ [03:47] lifeless: hmmm, not sure that's a nuance that makes a major difference to our effectiveness in fixing bugs, but I see the point [03:47] slangasek: for instance, 'needsverification' could be expressed as 'moreinfo flag set' + 'fixcommitted' [03:47] sure [03:47] persia: right, so it needs to be part of the culture that the person who sets it to incomplete watches for responses and acts on it [03:47] slangasek: and moreinfo wouldn't expire bugs [03:48] * micahg wonders if this isn't better served being discussed in #ubuntu-bugs [03:48] micahg: I've had people set my bugs to "incomplete" when the only response I could reasonably have was the get in a status war. [03:48] micahg, Doesn't help if the person who sets incomplete isn't capable of making that determination, which is what is often seen currently. [03:48] slangasek: incomplete can be modelled as 'NEW + moreinfo' in fact [03:48] micahg: Because the bug WAS complete, but if I didn't engage in the pointless status war, it would get timed out. :P [03:49] infinity: this is the type of thing that needs to be brought up on the ML [03:49] lifeless: I also interpret incomplete as new+moreinfo, but others seem to interpret it as a synonym of invalid. That's my issue. [03:50] infinity: filers or triagers? [03:50] lifeless: (And the practice of auto-removing incomplete reports confirms this) [03:50] lifeless: The whole system. :P [03:50] the whole system doesn't [03:50] infinity: ok, but in that case the root problem isn't that non-developers are triaging the bugs, it's that the set of people who are in a position to understand those bugs is stretched too thin to triage them in a timely manner; and that you can only address by getting more people who know what they're doing [03:50] lifeless: If we auto-remove old incompletes, they ARE being called invalid. Which may be inherently untrue once someone else reads the bug. [03:50] e.g., by working with the bug triagers to get them the tools they need to contribute effectively :) [03:51] infinity: actually, they're being expired, not invalidated [03:51] micahg: They're being closed. I didn't say they're being changed to "invalid". [03:51] marking 'triaged' bugs as 'incomplete' would be a serious problem [03:51] micahg: "no longer open" is "no longer open", regardless of the official status. [03:51] because that's undoing the work of deveolpers [03:51] slangasek: right, I brought that up at the last bugsquad meeting [03:51] but marking 'new' as 'incomplete' is not, on the whole, worse than leaving 'new' marked as 'new' [03:52] with no response, ever, from a dev [03:52] I dunno. I have old Debian bug reports I plan to get to some day when I'm bored. Or maybe some zealous community dude will send me a patch. Or something. [03:52] Old bugs aren't bad bugs. [03:52] infinity: bug in the system doesn't map directly to defect [03:53] infinity: no, but "I plan to get to some day when I'm bored" means "triaged" - if you're aware of it, you can mark it "triaged" [03:53] Just because no one's had the time to look at it and determine its actual validity doesn't make it incorrect. [03:53] infinity: thatsa the point of expiry, because we get reports that aren't bugs [03:53] infinity: the reason the *default* is NEW, is so that someone can look at it. [03:53] lifeless: Yes, but "incomplete" isn't "invalid", we've been there before. :P [03:53] lifeless: This is, again, my problem with "incomplete". [03:53] lifeless: Yes, some bugs are invalid. We agree. [03:54] lifeless: But bugs that might be valid with more info aren't invalid just because they're three months old. [03:54] If we have underskilled people asserting that the bug needs more data to be confirmed as a bug, *that* is a problem. [03:54] c [03:54] lifeless: And the triager thinking it needs more info might not be true from the POV of someonw who knows the software. [03:54] infinity: I agree re aging not implying expirable - see under 'I think we've oversimplified' [03:54] lifeless: I have "Oh, I see what's happening there" moments all the time on bugs that someone else is still arguing about "moar log filez please" on. [03:55] slangasek: I'll agree that in packages I care deeply about, I could do a bit of triaging here and there and mitigate some of these issues. [03:56] slangasek: But with our decidedly anti-ownership maintainerless culture, there will be packages where no "skilled developer" looks at the bugs for a while. [03:56] slangasek: I usually only notice bugs in various universe packages when I go to file a new one. [03:57] slangasek: And I then go through the old-and-closed list to see if this is a longstanding issue, etc. [03:58] and do you often find the bug was on the new->incomplete->invalid conveyor? [04:00] subscribe to packageset would help a little [04:01] slangasek: Or new->incomplete->expired, which has the same UI effect. [04:01] hmm, really [04:01] ? [04:02] (not the UI effect, but that you often find this to be the case) [04:02] Sadly, yes. As micahg says, I should probably start taking notes and complaining to a wider audience. [04:02] yes please :-) [04:28] but i have a question for the whole bug report system! if ubuntu tries to be more and more user friendly, the average user won't have the experience of understand bugs and report them ( or only the second section ), will he? [04:29] marios_manowar: We don't expect all users to report bugs. [04:30] marios_manowar: The nice (?) thing about software defects is that most of them impact a reasonably large enough number of people that SOMEONE will end up reporting it. Ish. Except when that's not true. :P [04:31] aka 'all software sucks' [04:31] infinity: but i think that more experienced users may move to another distro [04:31] marios_manowar: (That said, if you *are* technical enough to be reporting bugs, please don't refrain because you think someone else will be reporting it for you) [04:32] marios_manowar: I'm not sure I really agree with that assertion. People who love to fiddle with their systems might prefer other distros (and that's cool), but Ubuntu appeals not just to "new/non-technical users", but also to people who actually prefer using their computers rather than fixing them. [04:33] marios_manowar: It's honestly why I ended up with Debian way back when, too. The combination of a decent packaging system and a draconian policy made Debian much more hassle-free than other distros, so I could actually work. [04:34] marios_manowar: Ubuntu's just another step in that direction for me. I can break it when I want/need to, but its default state is meant to be the opposite. And we try hard to get there. And sometimes even succeed. ;) [04:39] infinity: i agree that the system has to be as stable as it can get. my worries are depend on that the unity for example is showing a simple interface that it 's similar to the philosophy of iPhone closed source OS. [04:40] infinity: i mean, ok, maybe this will point out that this look can be an open-source jewel too. but the actual distance from the native files is like it grows. [04:42] marios_manowar: Not everyone's a fan of Unity or GNOME shell, or iOS, or Windows8, or Android, or, or, or... I imagine there will always be a market for "power users" who like "fancier desktops". Thankfully, FLOSS operating systems allow for that quite readily. :P [04:42] Good morning [04:42] marios_manowar: (Using a classic GNOME session in Ubuntu is literally one click away on the login screen) [04:43] pitti: Guten Morgen! [04:43] hey infinity, how are you? [04:44] /c/c [04:44] gah [04:44] Melting in the heat, and looking forward to winter. :P [04:44] infinity: ok, i think i should wait for 11.10 for getting a better view in the future ;) [04:44] infinity: It's 11degC over here, want to swap? [04:44] StevenK: Gladly. That sounds LOVELY. [04:45] infinity: Actually, define "heat"? :-) [04:45] StevenK: I am thin, can I come two? [04:45] *too [04:45] StevenK: Was over 30 today, and probably closer to 40 in my office here. [04:46] That's a bit too hot [04:46] Please send AC, stat. [04:46] How about we average them, 23degC sounds nice [04:46] I'd rather have the 11. [04:46] Yes, but you enjoy -20, too. [04:46] Crazy person. [04:54] it was nice chatting with you all. have a good day! [05:06] good morning [05:30] slangasek: hah, speaking of wontfixing things wrongly: [05:30] bug 480444 [05:30] Launchpad bug 480444 in linux (Ubuntu) "packet storm with linux NFSv4 client when calling ftruncate()" [High,Won't fix] https://launchpad.net/bugs/480444 [05:31] persia: also [05:32] persia: ubuntu membership board asia. Its in your court AIUI. [05:32] lifeless: Yay automation. :/ [05:32] lifeless: And you'll note that's happened to that bug more than once. [05:33] yes [05:33] clearly noone uses NFS [05:34] lifeless: Uh? [05:35] NFSv3 is *vastly* different to NFSv4, so don't tar them with the same brush [05:35] I happy use NFSv3 and have for years. [05:36] StevenK: Upgrade and help squish bugs in the technically-superior-but-woefully-undertested successor? :P [05:36] But NFSv4 is the devil! [05:37] So is Australia, but you still live there. [05:37] So, y'know. Embrace your inner crazy. [05:38] * StevenK blinks [05:39] So I can just mount it as nfs4 [05:40] Except that returns ENOENT [05:47] steven@liquified:~% mount | tail -n 1 | cut -d\( -f1 [05:47] nfs:/ on /media/media type nfs4 [05:47] Scary [05:59] StevenK: that bug is also reproducible with NFSv3 [06:00] Oh, neat. [06:02] StevenK: am I the only one that tries to run bzr over nfs? :) [06:03] slangasek: no, kiko / async do/did [06:04] he must have a server version that doesn't trigger the bug :/ [06:04] slangasek: I certainly don't run bzr over NFS. [06:05] StevenK: pff, hardly seems like you can claim to be using NFSv3 at all then ;) [06:05] Haha [06:47] good morning [06:48] * slangasek waves to dholbach [06:48] so speaking of nfs, why does the upgrade to nfs-utils 1.2.4 cause kerberos authentication to fail. :P [06:48] hey slangasek [07:08] pitti: hello? [07:12] hey poolie [07:17] hi there [07:17] can you advise me about our SRU proposal [07:17] (thanks again in advance) [07:17] https://code.launchpad.net/~jelmer/ubuntu/natty/bzr/sru-2.3.4/+merge/68020 [07:17] i think i technically have permission to merge and upload it, but i think i should get a sru-team +1 first? === smb` is now known as smb [07:21] poolie: ubuntu-sru dropped the requirement for a pre-upload ACK a few releases ago [07:21] these days they review SRUs from the *-proposed queues [07:22] oh i see [07:22] so, just merge it and upload to proposed? [07:22] yeah [07:22] and then ping for review [07:22] thanks [07:22] it won't actually get published to proposed until they approve it [07:22] poolie: right, what broder says; we usually review from the queue === tkamppeter_ is now known as tkamppeter [07:32] RAOF, hi [07:32] tkamppeter: Hi! [07:32] RAOF, how about the colord packaging? [07:32] tkamppeter: http://anonscm.debian.org/gitweb/?p=collab-maint/colord.git [07:33] OK, thanks. [07:33] It's mostly ready. I need to discuss things with the icc-profiles maintainers, though. [07:33] RAOF, is pitti packaging that stuff? [07:34] The icc-profiles stuff? I don't believe so. [07:34] RAOF, because of "owner: Martin Pitt". [07:34] Oh. [07:34] Yeah, he created the alioth repository for me. [07:35] RAOF, OK [07:35] quick question to the kubuntu people, is "DESKTOP_SESSION" defined there (i.e. does echo $DESKTOP_SESSION print something)? [07:36] I would like pitti to give the package a review + upload to Debian at some point. I should drop the shared-color-profiles Recommends: and ask for a review. That needs a bit of a discussion, and the future rdepends of colord don't care about it. [07:39] mvo: KDM should set it last time I checked [07:41] thanks didrocks [07:43] hum, gcc issue on the buildds? [07:43] https://launchpadlibrarian.net/75493155/buildlog_ubuntu-oneiric-i386.unity_4.2.0-0ubuntu5_FAILEDTOBUILD.txt.gz just after latest publish (previous uploads worked) [07:43] RAOF, thanks for the update. [08:11] didrocks: why gcc issue? check why libcompizconfig0 can't get installed (probably a dependency issue or a conflict somewhere down the dependency chain) [08:12] geser: sorry yeah, realized afterwards that I stopped at the first warning :) [08:16] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ev [08:36] Known breakage? Oneiric xorg upgrade fails because it conflicts with /usr/share/doc/xorg which is also in xserver-xorg... [08:37] smb: yes, discussed with RAOF an hour ago [08:37] pitti, ok, ta [08:37] RAOF: just saw your xorg upload -- did you actually add preinst magic? the changelog doesn't say so [08:38] smb: bug 812665 FYI [08:38] Launchpad bug 812665 in xorg (Ubuntu) "package xorg 1:7.6 7ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/doc/xorg', which is also in package xserver-xorg 1:7.6 7ubuntu2" [Critical,Fix released] https://launchpad.net/bugs/812665 [08:39] pitti, Ok, then I don't need to bother anybody any longer. :) [08:58] Riddell: hi, so the bzr 2.3.4 sru is waiting to go into -proposed? [08:58] what's the precise term? [08:58] and what is it we need to have to progress it? [09:00] poolie: yes, it's in the queue: https://launchpad.net/ubuntu/natty/+queue?queue_state=1 [09:00] poolie: nothign, the SRU team regularly reviews the queue [09:00] oh, ok [09:00] that's great then [09:01] and then into proposed, then we can regression test, and then ask again to promote it [09:02] Good morning Ubuntu [09:04] good morning jml [09:04] poolie: hi [09:09] poolie: yes [09:09] poolie: it's in unapproved queue === doko_ is now known as doko [09:10] slangasek: I'm wondering about this change in gcc-4.x: http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.5/debian/patches/gcc-multiarch.diff?r1=4425&r2=4660&pathrev=4660 [09:10] [ Steve Langasek ] [09:11] * Don't append multiarch paths to any multilib paths except for the default; [09:11] our biarch (multilib) builds need to remain independent of multiarch in [09:11] the near term, so we want to make sure we can find /usr/lib32 without [09:11] /usr/lib/i486-linux-gnu being available. [09:13] IMO always using MULTIARCH_DEFAULTS is wrong for every multilib'ed target, but maybe I miss something [09:23] cjwatson: why does ubuntu-defaults-image call lb clean with sudo? [09:24] ah, it writes files as root during lb build, nevermind [09:25] jhunt_, hey, did you sort your /proc/$$/fd issue ? [09:28] apw: no. I might be missing something but the behaviour I'm seeing does look like a kernel bug to me. [09:29] apw: well, kernel bug, or security policy :) [09:30] jhunt_, i don't think he had enough details to pass them on accuratly [09:34] geser: had time to fix my request yet for the ftbfs page ? :) [09:46] sorry not yet, but if you have time the code is at lp:~geser/+junk/qa-ftbfs [09:53] SpamapS: bug 711425 is too late for 10.04.3 now :-( just a reminder since I think we really do want to get that fixed for 10.04.4 [09:53] Launchpad bug 711425 in sysvinit (Ubuntu Maverick) "portmap does not stop during shutdown, causing possible root fs corruption" [High,Triaged] https://launchpad.net/bugs/711425 [10:17] dholbach, should the weird paragraph signs show on the right of the headers? [10:28] cjwatson: hm, live-build doesn't automatically install a policy-rc.d file? I had to manually put it there when the chroot build failed on configuring dbus [10:30] Amoz, perhaps just on mouse-over like in the default? [10:30] i'd rather a more discreet way of doing that [10:30] just make the headings links which don't change colour? [10:31] pitti: it does [10:31] scripts/build/lb_chroot_sysv-rc [10:32] cat > chroot/usr/sbin/policy-rc.d << EOF [10:32] #!/bin/sh [10:32] echo "All runlevel operations denied by policy" >&2 [10:32] exit 101 [10:32] EOF [10:32] I noticed that when grepping, but it wasn't there; but perhaps this was an interrupted run, I just started a new one [10:32] pitti: debootstrap doesn't though; although it does replace start-stop-daemon and initctl [10:34] dholbach, I'm pushing the fixes now, except the header fix. You have to decide which one you want :P [10:35] dholbach, all code should be monospace and shaded in a box, links removed, big Index link points to the packaging guide index.html startpage === dholbach_ is now known as dholbach [10:37] dholbach, you got that last part? [10:38] Amoz, I'm just having a look at it [10:39] ah [10:39] cool [10:39] /home/laney/temp/retheming/fixing-a-bug-security.rst:72: WARNING: unknown document: udd-intro.rst [10:39] /home/laney/temp/retheming/index.rst:12: WARNING: unknown document: knowledge-base [10:40] Laney, how did you get that? [10:40] make html [10:41] Laney, I think that might have come with one of the last revisions, not necessarily Amoz's edits [10:41] yeah I wasn't trying to suggest that [10:41] :) [10:41] I still see the paragraph symbols though [10:41] yeah [10:41] I didn't fix em [10:41] ah [10:42] didn't know if you'd rather have the signs appear when mouse-over [10:42] whatever you think is best [10:42] or just anchor the headers [10:44] Amoz, it doesn't seem to have an effect if we completely remove top-login and top-related, so it might make sense to completely get rid of them - what do you think? [10:45] dholbach, so we won't publish this guide online? [10:45] apart from that I think I'm happy for now - we can always extend the main-nav area (for offline use) [10:45] I think it would be nice to have some links to other places, if they're related to the packaging guide [10:45] Amoz, sure we will [10:46] Amoz, my idea was the following: have less links in the automatically generated version as that's what we ship in a package for offline use [10:46] ah of course [10:46] Amoz, and then have a script use that package as a basis for wherever we deploy it online, so it can blend in with that site better [10:47] that's how http://people.canonical.com/~dholbach/packaging-guide/html/ is put together, just there's no modification yet ;-) [10:47] so we can manually modify the published version with links and stuff [10:47] or let a script do it in a cron-job, but yes :) [10:48] oh well [10:48] do you think the approach makes sense? [10:48] absolutely, I'll remove the div's completeley... better not fudge up the layout grrr [10:49] I mean comment out the divs* [10:49] or do you want me to remove the code, dholbach ? [10:50] I think we can just remove them, they don't seem to have any effect as far as I can see [10:52] if you want to make an online version *with* the links, it's easier just to keep the code.. you can just let a script remove the to get the online version then [10:53] works for me [10:53] I think we just have to keep main-nav? [10:53] yeah I comment out the top-login and top-related divs [10:54] oh, wait, the whole top-nav is commented [10:54] there [10:54] and how about the paragraphs? [10:55] how easy is it to make them only visible when hovering over them? === dendrobates is now known as dendro-afk [11:24] dholbach, fixed [11:24] and pushed [11:24] sweet [11:24] I'll take a look in a bit [11:28]