| persia | infinity: Would now work for a discussion of syslog? | 00:05 |
|---|---|---|
| persia | 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:06 | |
| RAOF | 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:09 |
| slangasek | 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:11 |
| RAOF | While there are sometimes techincal solutions to social problems, rarely are there technical solutions to political problems. :( | 00:15 |
| persia | There's no useful distinction between "social problem" and "political problem". | 00:15 |
| persia | 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:16 |
| persia | (consider $EDITOR and sensible-editor as technical solutions to political problems) | 00:17 |
| RAOF | 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. | 00:18 |
| === jjohansen is now known as jj-afk | ||
| marios_manowar | 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:49 |
| persia | The decisions don't quite work like that. | 02:51 |
| persia | 10.04.3 includes all the updates published when 10.04.3 was released. | 02:51 |
| persia | 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:52 |
| persia | 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:53 |
| marios_manowar | 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:57 |
| marios_manowar | 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 |
| persia | Which page? | 02:58 |
| persia | If there was discussion, I'm also interested. | 02:58 |
| ajmitch | the kernel is a special case - there are backported kernels available which receive support | 02:59 |
| ajmitch | though I'm not sure to what degree | 02:59 |
| infinity | ajmitch: Very little. | 02:59 |
| persia | But I can't imagine anyone generating official install images that used a backport kernel. | 02:59 |
| persia | Support is to the degree developers are motivated. Anything else is wishful thinking. | 03:00 |
| ajmitch | infinity: that's useful to know | 03:00 |
| persia | Discussion of the sources of developer motivation is left for another time. | 03:00 |
| broder | 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 |
| persia | Really? More than just putting them in the pool as available? | 03:01 |
| broder | 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 |
| broder | and for some hardware, you need the backport kernels to do that | 03:01 |
| broder | but, i mean, there are obviously issues with regressions, disc space, etc. | 03:02 |
| broder | the point release DVDs already ship with all the backport kernels, but i don't think anybody uses those | 03:02 |
| persia | 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:04 |
| infinity | 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 |
| marios_manowar | persia: it was on the blueprints | 03:05 |
| marios_manowar | https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-kernel-decision | 03:05 |
| persia | infinity, I can accept that assertion. Can you accept mine? | 03:06 |
| infinity | marios_manowar: That was deciding *before* lucid that it would use 2.6.32. | 03:06 |
| broder | marios_manowar: uh, that's from back when lucid was first being developed | 03:06 |
| persia | marios_manowar, Check the dates on that: that's from October 2009. | 03:07 |
| infinity | marios_manowar: That same discussion happens every cycle (the kernel team decides which version is their target, and works toward that) | 03:07 |
| persia | Well, November, but it *should* have been submitted in October. | 03:07 |
| infinity | 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:07 |
| marios_manowar | ALL: ok, i feel stupid :-( | 03:08 |
| persia | 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:08 |
| persia | infinity, Well, some of the scripts are executed on humans, but yeah, that's the source of my concern. | 03:09 |
| infinity | 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:10 |
| persia | I don't think the support teams are quite that bad. | 03:11 |
| infinity | 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 |
| persia | Well then, any objection if I document that we can only provide support for users who have some syslog implementation installed? | 03:11 |
| persia | People who don't need syslog probably don't need that much support, or can fake enough answers that nobody will notice. | 03:12 |
| infinity | 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:12 |
| persia | 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 |
| persia | It's probably worth trying to realign bugsquad and the support teams, but that requires a healthy supply of tuits. | 03:14 |
| infinity | 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:14 |
| infinity | 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 |
| persia | I was thinking that documentation should come in two flavours: short and long. | 03:15 |
| persia | Short is just quick sentences, and a pointer to long. | 03:16 |
| persia | Long can be long-winded: it's not for the TL;DR crowd anyway. | 03:16 |
| micahg | infinity: these issues should be brought up on the bugsquad list so that people can learn from them | 03:17 |
| marios_manowar | I will agree with persia in his/her documentation opinion | 03:17 |
| infinity | micahg: To be fair, I've had these issues for literally years. It's a battle I'm sick of fighting. | 03:18 |
| infinity | 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 |
| infinity | 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:19 |
| micahg | infinity: well, there was a discussion about a year ago about that, and the conclusion was what you just said | 03:20 |
| micahg | and I brought this up at the last meeting to reinforce it | 03:20 |
| infinity | 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:25 |
| persia | 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 |
| infinity | micahg: So, how do I go about affecting a culture shift in processes that I've considered broken for half a decade? :) | 03:26 |
| persia | 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:26 |
| infinity | 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 |
| infinity | 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:27 |
| persia | 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 |
| lifeless | communication is important | 03:28 |
| infinity | (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 |
| persia | 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 |
| lifeless | oh I would love that | 03:29 |
| lifeless | unsubscribed people making changes can be annoying | 03:29 |
| persia | 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 |
| infinity | 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 |
| persia | lifeless, It's not just the unsubscribed being annoying, it's also for greater cohesion in the bug contact team. | 03:30 |
| persia | infinity, Yes. | 03:31 |
| lifeless | one way would be a reply-to function 'reply to a comment' vs 'comment on the bug' | 03:31 |
| lifeless | we could use that to notify even unsubsubscribed folk | 03:31 |
| persia | Wouldn't have the same name-and-shame benefit. | 03:31 |
| lifeless | needs some design work around the concept | 03:31 |
| persia | Unless we cc: all those to the bug contact for the project. | 03:31 |
| lifeless | persia: it would still show as a comment on the bug | 03:32 |
| lifeless | persia: which is plenty of name and shame | 03:32 |
| persia | lifeless, I think you underestimate how many bugs there are in Ubuntu. | 03:32 |
| infinity | 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 |
| lifeless | persia: I suspect I know better than you, given how much time I spend optimising LP to deal with them :> | 03:32 |
| persia | Most active members of bugsquad only see a very limited subset, but they all ought see bug comment criticism. | 03:32 |
| persia | infinity, OK. Fair. | 03:33 |
| persia | 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 |
| micahg | infinity: well, we have a special bugsquad team that's moderated, although the bar for entry is low | 03:35 |
| infinity | 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:35 |
| micahg | 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 |
| lifeless | persia: the crucial thing is feedback to the people making mistake | 03:36 |
| lifeless | s | 03:36 |
| slangasek | infinity: should the standard for that be anything other than "if the bug was marked triaged, don't mark it incomplete"? | 03:36 |
| lifeless | persia: so I'm not assessing the mechanism on the same metric you are | 03:36 |
| slangasek | infinity: btw, have you responded to the bug workflow survey? :) | 03:36 |
| infinity | 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 |
| persia | 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:36 |
| micahg | persia: I think that qualifies as a developer in Ubuntu :) | 03:37 |
| persia | 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 |
| lifeless | persia: so the docs already guide away from this mistake | 03:37 |
| infinity | 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 |
| persia | 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 |
| lifeless | persia: overseers could probably watch (programatically) for status changes and audit easily enough | 03:38 |
| micahg | persia: right, because we overload the term developer in ubuntu and not everyone is aware of that | 03:38 |
| infinity | 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 |
| persia | 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 |
| infinity | (Another pet peeve of mine: people who think that without a well-formed patch, you don't have a fix) | 03:39 |
| infinity | slangasek: Survey? I may have missed this. | 03:39 |
| lifeless | persia: I question the effect of negative reinforcement here | 03:40 |
| micahg | infinity: https://lists.ubuntu.com/archives/ubuntu-devel/2011-July/033652.html | 03:40 |
| infinity | micahg: Ahh, I haven't caught up on devel for a bit, thanks. | 03:40 |
| persia | 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:40 |
| persia | Without that, I fear we're all likely to just pretend everything is good all the time. | 03:41 |
| persia | But any system that has logged peer review inherently can be described as providing negative reinforcement. | 03:41 |
| persia | 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:42 |
| lifeless | 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:43 |
| infinity | slangasek: I think the problem with "incomplete" is that it's used and viewed as a negative thing. | 03:44 |
| persia | 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 |
| lifeless | why ? | 03:44 |
| persia | 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 |
| infinity | 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:44 |
| lifeless | so incomplete and moreinfo are separate concepts | 03:45 |
| slangasek | 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 |
| lifeless | I think we have over simplified and made the system harder to use as a result | 03:45 |
| infinity | lifeless: Incomplete is a broken-by-design concept, IMO. | 03:45 |
| lifeless | infinity: in which regard? | 03:45 |
| micahg | persia: the bug contact isn't the bugsquad ML AFAICT, but the ubuntu-bugs list | 03:46 |
| infinity | 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 |
| infinity | slangasek: And possibly timing out before it ever gets to someone who COULD determine that it's "complete enough". | 03:46 |
| persia | micahg, Ah, then Hrm. Anyway, needs user interaction design. | 03:46 |
| slangasek | 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 |
| lifeless | slangasek: yes | 03:46 |
| micahg | infinity: you definitely need to fill out the survey :) | 03:47 |
| persia | 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 |
| infinity | ^ | 03:47 |
| slangasek | 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 |
| lifeless | slangasek: for instance, 'needsverification' could be expressed as 'moreinfo flag set' + 'fixcommitted' | 03:47 |
| slangasek | sure | 03:47 |
| micahg | 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 |
| lifeless | slangasek: and moreinfo wouldn't expire bugs | 03:47 |
| * micahg wonders if this isn't better served being discussed in #ubuntu-bugs | 03:48 | |
| infinity | 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 |
| persia | 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 |
| lifeless | slangasek: incomplete can be modelled as 'NEW + moreinfo' in fact | 03:48 |
| infinity | micahg: Because the bug WAS complete, but if I didn't engage in the pointless status war, it would get timed out. :P | 03:48 |
| micahg | infinity: this is the type of thing that needs to be brought up on the ML | 03:49 |
| infinity | lifeless: I also interpret incomplete as new+moreinfo, but others seem to interpret it as a synonym of invalid. That's my issue. | 03:49 |
| lifeless | infinity: filers or triagers? | 03:50 |
| infinity | lifeless: (And the practice of auto-removing incomplete reports confirms this) | 03:50 |
| infinity | lifeless: The whole system. :P | 03:50 |
| lifeless | the whole system doesn't | 03:50 |
| slangasek | 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 |
| infinity | 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 |
| slangasek | e.g., by working with the bug triagers to get them the tools they need to contribute effectively :) | 03:50 |
| micahg | infinity: actually, they're being expired, not invalidated | 03:51 |
| infinity | micahg: They're being closed. I didn't say they're being changed to "invalid". | 03:51 |
| slangasek | marking 'triaged' bugs as 'incomplete' would be a serious problem | 03:51 |
| infinity | micahg: "no longer open" is "no longer open", regardless of the official status. | 03:51 |
| slangasek | because that's undoing the work of deveolpers | 03:51 |
| micahg | slangasek: right, I brought that up at the last bugsquad meeting | 03:51 |
| slangasek | but marking 'new' as 'incomplete' is not, on the whole, worse than leaving 'new' marked as 'new' | 03:51 |
| slangasek | with no response, ever, from a dev | 03:52 |
| infinity | 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 |
| infinity | Old bugs aren't bad bugs. | 03:52 |
| lifeless | infinity: bug in the system doesn't map directly to defect | 03:52 |
| slangasek | 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 |
| infinity | Just because no one's had the time to look at it and determine its actual validity doesn't make it incorrect. | 03:53 |
| lifeless | infinity: thatsa the point of expiry, because we get reports that aren't bugs | 03:53 |
| lifeless | infinity: the reason the *default* is NEW, is so that someone can look at it. | 03:53 |
| infinity | lifeless: Yes, but "incomplete" isn't "invalid", we've been there before. :P | 03:53 |
| infinity | lifeless: This is, again, my problem with "incomplete". | 03:53 |
| infinity | lifeless: Yes, some bugs are invalid. We agree. | 03:53 |
| infinity | lifeless: But bugs that might be valid with more info aren't invalid just because they're three months old. | 03:54 |
| lifeless | If we have underskilled people asserting that the bug needs more data to be confirmed as a bug, *that* is a problem. | 03:54 |
| TheMuso | c | 03:54 |
| infinity | lifeless: And the triager thinking it needs more info might not be true from the POV of someonw who knows the software. | 03:54 |
| lifeless | infinity: I agree re aging not implying expirable - see under 'I think we've oversimplified' | 03:54 |
| infinity | 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:54 |
| infinity | 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:55 |
| infinity | 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 |
| infinity | slangasek: I usually only notice bugs in various universe packages when I go to file a new one. | 03:56 |
| infinity | slangasek: And I then go through the old-and-closed list to see if this is a longstanding issue, etc. | 03:57 |
| slangasek | and do you often find the bug was on the new->incomplete->invalid conveyor? | 03:58 |
| micahg | subscribe to packageset would help a little | 04:00 |
| infinity | slangasek: Or new->incomplete->expired, which has the same UI effect. | 04:01 |
| slangasek | hmm, really | 04:01 |
| slangasek | ? | 04:01 |
| slangasek | (not the UI effect, but that you often find this to be the case) | 04:02 |
| infinity | Sadly, yes. As micahg says, I should probably start taking notes and complaining to a wider audience. | 04:02 |
| slangasek | yes please :-) | 04:02 |
| marios_manowar | 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:28 |
| infinity | marios_manowar: We don't expect all users to report bugs. | 04:29 |
| infinity | 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:30 |
| lifeless | aka 'all software sucks' | 04:31 |
| marios_manowar | infinity: but i think that more experienced users may move to another distro | 04:31 |
| infinity | 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:31 |
| infinity | 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:32 |
| infinity | 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:33 |
| infinity | 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:34 |
| marios_manowar | 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:39 |
| marios_manowar | 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:40 |
| infinity | 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 |
| pitti | Good morning | 04:42 |
| infinity | marios_manowar: (Using a classic GNOME session in Ubuntu is literally one click away on the login screen) | 04:42 |
| infinity | pitti: Guten Morgen! | 04:43 |
| pitti | hey infinity, how are you? | 04:43 |
| TheMuso | /c/c | 04:44 |
| TheMuso | gah | 04:44 |
| infinity | Melting in the heat, and looking forward to winter. :P | 04:44 |
| marios_manowar | infinity: ok, i think i should wait for 11.10 for getting a better view in the future ;) | 04:44 |
| StevenK | infinity: It's 11degC over here, want to swap? | 04:44 |
| infinity | StevenK: Gladly. That sounds LOVELY. | 04:44 |
| StevenK | infinity: Actually, define "heat"? :-) | 04:45 |
| marios_manowar | StevenK: I am thin, can I come two? | 04:45 |
| marios_manowar | *too | 04:45 |
| infinity | StevenK: Was over 30 today, and probably closer to 40 in my office here. | 04:45 |
| StevenK | That's a bit too hot | 04:46 |
| infinity | Please send AC, stat. | 04:46 |
| StevenK | How about we average them, 23degC sounds nice | 04:46 |
| infinity | I'd rather have the 11. | 04:46 |
| StevenK | Yes, but you enjoy -20, too. | 04:46 |
| StevenK | Crazy person. | 04:46 |
| marios_manowar | it was nice chatting with you all. have a good day! | 04:54 |
| didrocks | good morning | 05:06 |
| lifeless | slangasek: hah, speaking of wontfixing things wrongly: | 05:30 |
| lifeless | bug 480444 | 05:30 |
| ubottu | 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:30 |
| lifeless | persia: also | 05:31 |
| lifeless | persia: ubuntu membership board asia. Its in your court AIUI. | 05:32 |
| infinity | lifeless: Yay automation. :/ | 05:32 |
| infinity | lifeless: And you'll note that's happened to that bug more than once. | 05:32 |
| lifeless | yes | 05:33 |
| lifeless | clearly noone uses NFS | 05:33 |
| StevenK | lifeless: Uh? | 05:34 |
| StevenK | NFSv3 is *vastly* different to NFSv4, so don't tar them with the same brush | 05:35 |
| StevenK | I happy use NFSv3 and have for years. | 05:35 |
| infinity | StevenK: Upgrade and help squish bugs in the technically-superior-but-woefully-undertested successor? :P | 05:36 |
| StevenK | But NFSv4 is the devil! | 05:36 |
| infinity | So is Australia, but you still live there. | 05:37 |
| infinity | So, y'know. Embrace your inner crazy. | 05:37 |
| * StevenK blinks | 05:38 | |
| StevenK | So I can just mount it as nfs4 | 05:39 |
| StevenK | Except that returns ENOENT | 05:40 |
| StevenK | steven@liquified:~% mount | tail -n 1 | cut -d\( -f1 | 05:47 |
| StevenK | nfs:/ on /media/media type nfs4 | 05:47 |
| StevenK | Scary | 05:47 |
| slangasek | StevenK: that bug is also reproducible with NFSv3 | 05:59 |
| StevenK | Oh, neat. | 06:00 |
| slangasek | StevenK: am I the only one that tries to run bzr over nfs? :) | 06:02 |
| lifeless | slangasek: no, kiko / async do/did | 06:03 |
| slangasek | he must have a server version that doesn't trigger the bug :/ | 06:04 |
| StevenK | slangasek: I certainly don't run bzr over NFS. | 06:04 |
| slangasek | StevenK: pff, hardly seems like you can claim to be using NFSv3 at all then ;) | 06:05 |
| StevenK | Haha | 06:05 |
| dholbach | good morning | 06:47 |
| * slangasek waves to dholbach | 06:48 | |
| slangasek | so speaking of nfs, why does the upgrade to nfs-utils 1.2.4 cause kerberos authentication to fail. :P | 06:48 |
| dholbach | hey slangasek | 06:48 |
| poolie | pitti: hello? | 07:08 |
| pitti | hey poolie | 07:12 |
| poolie | hi there | 07:17 |
| poolie | can you advise me about our SRU proposal | 07:17 |
| poolie | (thanks again in advance) | 07:17 |
| poolie | https://code.launchpad.net/~jelmer/ubuntu/natty/bzr/sru-2.3.4/+merge/68020 | 07:17 |
| poolie | i think i technically have permission to merge and upload it, but i think i should get a sru-team +1 first? | 07:17 |
| === smb` is now known as smb | ||
| broder | poolie: ubuntu-sru dropped the requirement for a pre-upload ACK a few releases ago | 07:21 |
| broder | these days they review SRUs from the *-proposed queues | 07:21 |
| poolie | oh i see | 07:22 |
| poolie | so, just merge it and upload to proposed? | 07:22 |
| broder | yeah | 07:22 |
| poolie | and then ping for review | 07:22 |
| poolie | thanks | 07:22 |
| broder | it won't actually get published to proposed until they approve it | 07:22 |
| pitti | poolie: right, what broder says; we usually review from the queue | 07:22 |
| === tkamppeter_ is now known as tkamppeter | ||
| tkamppeter | RAOF, hi | 07:32 |
| RAOF | tkamppeter: Hi! | 07:32 |
| tkamppeter | RAOF, how about the colord packaging? | 07:32 |
| RAOF | tkamppeter: http://anonscm.debian.org/gitweb/?p=collab-maint/colord.git | 07:32 |
| tkamppeter | OK, thanks. | 07:33 |
| RAOF | It's mostly ready. I need to discuss things with the icc-profiles maintainers, though. | 07:33 |
| tkamppeter | RAOF, is pitti packaging that stuff? | 07:33 |
| RAOF | The icc-profiles stuff? I don't believe so. | 07:34 |
| tkamppeter | RAOF, because of "owner: Martin Pitt". | 07:34 |
| RAOF | Oh. | 07:34 |
| RAOF | Yeah, he created the alioth repository for me. | 07:34 |
| tkamppeter | RAOF, OK | 07:35 |
| mvo | quick question to the kubuntu people, is "DESKTOP_SESSION" defined there (i.e. does echo $DESKTOP_SESSION print something)? | 07:35 |
| RAOF | 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:36 |
| didrocks | mvo: KDM should set it last time I checked | 07:39 |
| mvo | thanks didrocks | 07:41 |
| didrocks | hum, gcc issue on the buildds? | 07:43 |
| didrocks | 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 |
| tkamppeter | RAOF, thanks for the update. | 07:43 |
| geser | didrocks: why gcc issue? check why libcompizconfig0 can't get installed (probably a dependency issue or a conflict somewhere down the dependency chain) | 08:11 |
| didrocks | geser: sorry yeah, realized afterwards that I stopped at the first warning :) | 08:12 |
| ev | @pilot in | 08:16 |
| === 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 | ||
| smb | Known breakage? Oneiric xorg upgrade fails because it conflicts with /usr/share/doc/xorg which is also in xserver-xorg... | 08:36 |
| pitti | smb: yes, discussed with RAOF an hour ago | 08:37 |
| smb | pitti, ok, ta | 08:37 |
| pitti | RAOF: just saw your xorg upload -- did you actually add preinst magic? the changelog doesn't say so | 08:37 |
| pitti | smb: bug 812665 FYI | 08:38 |
| ubottu | 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:38 |
| smb | pitti, Ok, then I don't need to bother anybody any longer. :) | 08:39 |
| poolie | Riddell: hi, so the bzr 2.3.4 sru is waiting to go into -proposed? | 08:58 |
| poolie | what's the precise term? | 08:58 |
| poolie | and what is it we need to have to progress it? | 08:58 |
| pitti | poolie: yes, it's in the queue: https://launchpad.net/ubuntu/natty/+queue?queue_state=1 | 09:00 |
| pitti | poolie: nothign, the SRU team regularly reviews the queue | 09:00 |
| poolie | oh, ok | 09:00 |
| poolie | that's great then | 09:00 |
| poolie | and then into proposed, then we can regression test, and then ask again to promote it | 09:01 |
| jml | Good morning Ubuntu | 09:02 |
| poolie | good morning jml | 09:04 |
| jml | poolie: hi | 09:04 |
| Riddell | poolie: yes | 09:09 |
| Riddell | poolie: it's in unapproved queue | 09:09 |
| === doko_ is now known as doko | ||
| doko | 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 |
| doko | [ Steve Langasek ] | 09:10 |
| doko | * Don't append multiarch paths to any multilib paths except for the default; | 09:11 |
| doko | our biarch (multilib) builds need to remain independent of multiarch in | 09:11 |
| doko | the near term, so we want to make sure we can find /usr/lib32 without | 09:11 |
| doko | /usr/lib/i486-linux-gnu being available. | 09:11 |
| doko | IMO always using MULTIARCH_DEFAULTS is wrong for every multilib'ed target, but maybe I miss something | 09:13 |
| pitti | cjwatson: why does ubuntu-defaults-image call lb clean with sudo? | 09:23 |
| pitti | ah, it writes files as root during lb build, nevermind | 09:24 |
| apw | jhunt_, hey, did you sort your /proc/$$/fd issue ? | 09:25 |
| jhunt_ | apw: no. I might be missing something but the behaviour I'm seeing does look like a kernel bug to me. | 09:28 |
| jhunt_ | apw: well, kernel bug, or security policy :) | 09:29 |
| apw | jhunt_, i don't think he had enough details to pass them on accuratly | 09:30 |
| dupondje | geser: had time to fix my request yet for the ftbfs page ? :) | 09:34 |
| geser | sorry not yet, but if you have time the code is at lp:~geser/+junk/qa-ftbfs | 09:46 |
| cjwatson | 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 |
| ubottu | 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 | 09:53 |
| Amoz | dholbach, should the weird paragraph signs show on the right of the headers? | 10:17 |
| pitti | 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:28 |
| dholbach | Amoz, perhaps just on mouse-over like in the default? | 10:30 |
| Laney | i'd rather a more discreet way of doing that | 10:30 |
| Laney | just make the headings links which don't change colour? | 10:30 |
| cjwatson | pitti: it does | 10:31 |
| cjwatson | scripts/build/lb_chroot_sysv-rc | 10:31 |
| cjwatson | cat > chroot/usr/sbin/policy-rc.d << EOF | 10:32 |
| cjwatson | #!/bin/sh | 10:32 |
| cjwatson | echo "All runlevel operations denied by policy" >&2 | 10:32 |
| cjwatson | exit 101 | 10:32 |
| cjwatson | EOF | 10:32 |
| pitti | 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 |
| cjwatson | pitti: debootstrap doesn't though; although it does replace start-stop-daemon and initctl | 10:32 |
| Amoz | dholbach, I'm pushing the fixes now, except the header fix. You have to decide which one you want :P | 10:34 |
| Amoz | dholbach, all code should be monospace and shaded in a box, links removed, big Index link points to the packaging guide index.html startpage | 10:35 |
| === dholbach_ is now known as dholbach | ||
| Amoz | dholbach, you got that last part? | 10:37 |
| dholbach | Amoz, I'm just having a look at it | 10:38 |
| Amoz | ah | 10:39 |
| Amoz | cool | 10:39 |
| Laney | /home/laney/temp/retheming/fixing-a-bug-security.rst:72: WARNING: unknown document: udd-intro.rst | 10:39 |
| Laney | /home/laney/temp/retheming/index.rst:12: WARNING: unknown document: knowledge-base | 10:39 |
| Amoz | Laney, how did you get that? | 10:40 |
| Laney | make html | 10:40 |
| dholbach | Laney, I think that might have come with one of the last revisions, not necessarily Amoz's edits | 10:41 |
| Laney | yeah I wasn't trying to suggest that | 10:41 |
| dholbach | :) | 10:41 |
| Laney | I still see the paragraph symbols though | 10:41 |
| Amoz | yeah | 10:41 |
| Amoz | I didn't fix em | 10:41 |
| Laney | ah | 10:41 |
| Amoz | didn't know if you'd rather have the signs appear when mouse-over | 10:42 |
| Laney | whatever you think is best | 10:42 |
| Amoz | or just anchor the headers | 10:42 |
| dholbach | 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:44 |
| Amoz | dholbach, so we won't publish this guide online? | 10:45 |
| dholbach | apart from that I think I'm happy for now - we can always extend the main-nav area (for offline use) | 10:45 |
| Amoz | I think it would be nice to have some links to other places, if they're related to the packaging guide | 10:45 |
| dholbach | Amoz, sure we will | 10:45 |
| dholbach | 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 |
| Amoz | ah of course | 10:46 |
| dholbach | 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:46 |
| dholbach | that's how http://people.canonical.com/~dholbach/packaging-guide/html/ is put together, just there's no modification yet ;-) | 10:47 |
| Amoz | so we can manually modify the published version with links and stuff | 10:47 |
| dholbach | or let a script do it in a cron-job, but yes :) | 10:47 |
| Amoz | oh well | 10:48 |
| dholbach | do you think the approach makes sense? | 10:48 |
| Amoz | absolutely, I'll remove the div's completeley... better not fudge up the layout grrr | 10:48 |
| Amoz | I mean comment out the divs* | 10:49 |
| Amoz | or do you want me to remove the code, dholbach ? | 10:49 |
| dholbach | I think we can just remove them, they don't seem to have any effect as far as I can see | 10:50 |
| Amoz | 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 <!-- comment tags --> to get the online version then | 10:52 |
| dholbach | works for me | 10:53 |
| dholbach | I think we just have to keep main-nav? | 10:53 |
| Amoz | yeah I comment out the top-login and top-related divs | 10:53 |
| Amoz | oh, wait, the whole top-nav is commented | 10:54 |
| Amoz | there | 10:54 |
| Amoz | and how about the paragraphs? | 10:54 |
| dholbach | how easy is it to make them only visible when hovering over them? | 10:55 |
| === dendrobates is now known as dendro-afk | ||
| Amoz | dholbach, fixed | 11:24 |
| Amoz | and pushed | 11:24 |
| dholbach | sweet | 11:24 |
| dholbach | I'll take a look in a bit | 11:24 |
| Amoz | dholbach, just an idea, maybe a bad one, when ppl comment on merge proposals, like Iain did, it would be nice to have some todo-list for the proposal, automatically collecting todolists from the comments | 11:28 |
| dholbach | maybe a whiteboard on the branch? | 11:29 |
| Amoz | something like that yeah | 11:29 |
| Amoz | would be easier if a few ppl make comments of improvements todo | 11:29 |
| Amoz | maybe the comments are enough.. | 11:30 |
| dholbach | I agree that it'd be good to collect TODO items somewhere, as opposed to having them spread in various comments/emails/... | 11:31 |
| Amoz | dholbach, i.e when I visist my retheming branch, I see a "needs fixing" from Iain, but I need to visit the actual merge proposal and browse to his comment to see what he wants me to fix. And if a lot of ppl comment on the branch... wow | 11:34 |
| dholbach | yes | 11:34 |
| Amoz | maybe place a box on the right, containing all the parsed lines from comments after a todo tag, a star * followed by one todo step/item | 11:35 |
| Amoz | heh, hope you understand what I mean .. | 11:36 |
| RAOF | pitti: Yes. I repurposed the existing maintainer script generation infrastructure in debian/rules to generate the preinst foo. | 11:36 |
| dholbach | Amoz, heh, you should have a chat with the launchpad team about this :) | 11:36 |
| Amoz | dholbach, yeah I know this is not the right place, but an idea needs to be criticized | 11:37 |
| dholbach | I'm on your side :) | 11:37 |
| pitti | RAOF: ah, clever | 11:42 |
| * cjwatson edits the 10.04.3 change summary and continues to wish that developers would actually explain what changes do in their changelogs | 11:46 | |
| cjwatson | instead of (anonymised) "Upstream patch 128691629716294.patch from 0.9 branch; LP: #nnnnnn" | 11:46 |
| cjwatson | (well, OK, in the current case there was sort of a description embedded in the patch name, but really) | 11:47 |
| Laney | where, what, why | 11:47 |
| cjwatson | and the audience for SRU changelogs on the whole does not care what files you changed in the source package to effect the change | 11:51 |
| === MacSlow is now known as MacSlow|lunch | ||
| === dendro-afk is now known as dendrobates | ||
| === dendrobates is now known as dendro-afk | ||
| dupondje | Aha a new natty kernel :D | 12:27 |
| dupondje | lets hope this fixes my issue :D | 12:27 |
| brendand | if a system has no dedicated video memory, does it take part of the regular RAM for video memory? | 12:31 |
| dupondje | ye | 12:33 |
| brendand | any fixed amount, or a percentage? | 12:33 |
| Amoz | brendand, for me (nVidia ION) it's a fixed 256MB | 12:34 |
| Amoz | I never heard of a percantage, but I might be wrong | 12:34 |
| brendand | Amoz - hmmm, shouln't your NVidia card have dedicated memory for video? | 12:34 |
| dupondje | think its always a fixed amount | 12:35 |
| dupondje | cause the os can't even use it | 12:35 |
| brendand | to really get to the point, a system has 4GiB of RAM, but /proc/meminfo reports ~2.8GiB. It's using the 64-bit kernel | 12:36 |
| brendand | why? | 12:36 |
| Amoz | brendand, my system (asus 1201n) has 2GB | 12:36 |
| brendand | bug, or something else | 12:36 |
| Amoz | but only ~1700MB is showing | 12:36 |
| Amoz | brendand, free -m gives me 1754MB total | 12:37 |
| brendand | and i get 3990GiB from free -m | 12:38 |
| Amoz | brendand, sounds reasonable | 12:38 |
| Amoz | what line at proc/meminfo are you referring to? | 12:38 |
| pitti | brendand: wow, 4 TB? :-) | 12:39 |
| brendand | pitti - no :P | 12:39 |
| brendand | it's like the old 0.02c mistake | 12:39 |
| brendand | Amoz - now i've started to referring to two different systems | 12:40 |
| brendand | the 3990 is from the one i'm on now | 12:40 |
| Amoz | 3990 MB | 12:40 |
| brendand | the other one is actually a bug report i'm looking at | 12:41 |
| brendand | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/812499 | 12:41 |
| ubottu | Ubuntu bug 812499 in linux (Ubuntu) "Just 2,8 of 4 GB RAM shown by Ubuntu." [Undecided,Incomplete] | 12:41 |
| Amoz | brendand, when you say proc/meminfo reports ~2.8GiB, what line are we talking about? | 12:41 |
| Amoz | ah | 12:41 |
| brendand | MemTotal | 12:42 |
| Daviey | jelmer: Hola, seeing a bunch of bzr uploads in Debian at the moment.. Does this mean bug #788533 is close to a fix? | 12:50 |
| ubottu | Launchpad bug 788533 in bzr-svn (Ubuntu) "bzr-svn incompatible with bzr 2.4 or higher" [High,In progress] https://launchpad.net/bugs/788533 | 12:50 |
| jelmer | Daviey: hi | 12:57 |
| jelmer | Daviey: not yet, there's a bug in subvertpy that's blocking bzr-svn at the moment | 12:58 |
| Daviey | jelmer: :(.. thanks. | 12:58 |
| brendand | looks like Radeon cards can be configured to 'steal' some RAM as video memory... | 12:59 |
| === Ursinha is now known as Ursinha-bbl | ||
| jelmer | Daviey: (bug 803353) | 13:03 |
| ubottu | Launchpad bug 803353 in subvertpy "segfault during iconv close from ra cleanup" [High,Triaged] https://launchpad.net/bugs/803353 | 13:03 |
| === MacSlow|lunch is now known as MacSlow | ||
| Daviey | jelmer: who cares about memory leaks? :).. thanks | 13:07 |
| geser | install more RAM :) | 13:18 |
| jelmer | SpamapS: hi | 13:19 |
| === carif__ is now known as carif-is-sprinti | ||
| === zyga is now known as zyga-food | ||
| === mbarnett` is now known as mbarnett | ||
| cjwatson | micahg: I've switched the lm-sensors and lm-sensors-3 source overrides around now | 13:39 |
| SpamapS | cjwatson: re bug 711425 .. right.. 10.04.3 has just crept up on me.. :-P | 13:54 |
| ubottu | 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 | 13:54 |
| SpamapS | jelmer: Hi... not forgetting you.. I need to run off and do some things.. be back in about an hour. | 13:56 |
| cjwatson | SpamapS: me too, and I'm release-engineering it :-/ | 13:57 |
| === zyga-food is now known as zyga | ||
| bdmurray | ev: could you look at sponsoring my debdiff in bug 811419? | 14:40 |
| ubottu | Launchpad bug 811419 in kerneloops (Ubuntu) "/etc/default/kerneloops executable" [Low,In progress] https://launchpad.net/bugs/811419 | 14:40 |
| ev | sure thing | 14:40 |
| ev | bdmurray: uploaded | 14:43 |
| bdmurray | ev: thanks! | 14:43 |
| === cmagina_ is now known as cmagina | ||
| micahg | cjwatson: thanks! | 15:15 |
| jelmer | slangasek: hi | 15:17 |
| jelmer | slangasek: I'm looking at bug 812704 and was wondering what package you were running it against? | 15:17 |
| ubottu | Launchpad bug 812704 in bzr-builddeb "backtrace with 'bzr bd --package-merge'" [Medium,In progress] https://launchpad.net/bugs/812704 | 15:17 |
| seb128 | hey | 15:21 |
| chrisccoulson | hi! | 15:21 |
| seb128 | should user admin frontends (let's say gnome-control-center user account) use adduser or useradd to add users? | 15:22 |
| pitti | hmm; useradd is portable, adduser better for Debian/Ubuntu, but specific for tehse | 15:23 |
| chrisccoulson | pitti - yeah, we mentioned that in #ubuntu-desktop too | 15:23 |
| seb128 | pitti, ok, I'm coming from the g-c-c side, the new user admin makes the default shell for users be sh | 15:23 |
| seb128 | i.e dash | 15:23 |
| pitti | eww | 15:23 |
| chrisccoulson | pitti - the issue is that accountsservice doesn't override defaults for the login shell | 15:23 |
| seb128 | since it calls useradd which default to sh | 15:23 |
| pitti | seb128: we should certainly patch that to bash | 15:24 |
| seb128 | that's one bug | 15:24 |
| chrisccoulson | and the default when using useradd is /bin/sh, but it is /bin/bash when using adduser | 15:24 |
| seb128 | right | 15:24 |
| chrisccoulson | ok | 15:24 |
| seb128 | still does adduser add other value? | 15:24 |
| chrisccoulson | i don't think so | 15:24 |
| pitti | beyond that, I don't think that we need an UI to select the shell | 15:24 |
| seb128 | like dealing with copying default content to the user dir | 15:24 |
| pitti | users who really want to can use chsh, and it's a special enough case IMHO | 15:24 |
| chrisccoulson | seb128, accountservice users "useradd -m", which appears to do the same thing | 15:24 |
| chrisccoulson | (ie, create the home directory) | 15:24 |
| seb128 | well the useradd manpage recommends using adduser | 15:25 |
| seb128 | so I guess there are difference between the two | 15:25 |
| pitti | seb128: adduser copies skel, respects the system/user ID ranges, and creates proper usergroups | 15:25 |
| pitti | ah, useradd also creates usergroups | 15:25 |
| seb128 | pitti, ok, so we should either ensure that accountsservices deal with all those or switcht o adduser | 15:26 |
| chrisccoulson | pitti - it also copies /etc/skel | 15:26 |
| pitti | chrisccoulson: right, I mention that | 15:26 |
| tkamppeter | mpt, hi | 15:26 |
| pitti | seb128: I guess calling adduser would be the smaller patch, and more robust? | 15:26 |
| chrisccoulson | pitti - i meant that useradd copies that (as well as adduser) | 15:26 |
| pitti | ah | 15:26 |
| chrisccoulson | (when you use -m) | 15:26 |
| chrisccoulson | or, at least that's what the manpage suggests. perhaps i should try it ;) | 15:27 |
| pitti | "sudo useradd foo" doesn't | 15:27 |
| pitti | useradd -m foo does, including skel | 15:27 |
| chrisccoulson | yeah, i just tried that here too | 15:28 |
| chrisccoulson | so, i'm not sure there's a need to patch accountsservice to user adduser is there? | 15:28 |
| chrisccoulson | (but we need to change the login shell somehow) | 15:28 |
| chrisccoulson | **to use | 15:28 |
| pitti | patch it to use useradd -s /bin/bash? | 15:29 |
| chrisccoulson | pitti - i think the issue with that is the default can't be changed by the administrator then | 15:29 |
| pitti | perhaps we should also just change /etc/default/useradd to use SHELL=/bin/bash | 15:29 |
| chrisccoulson | yeah, that's what i was thinking | 15:29 |
| pitti | but that might affect system users, too | 15:30 |
| pitti | not that it matters much for them | 15:30 |
| seb128 | well, do we want to default to dash for system users? | 15:30 |
| seb128 | I would like to get opinion from some of the foundation guys on that at least ;-) | 15:30 |
| seb128 | i.e cjwatson or slangasek | 15:30 |
| seb128 | ^ | 15:30 |
| pitti | might be a tad more efficient in corner cases, but not a big deal, I think | 15:30 |
| chrisccoulson | that only changes the login shell though doesn't it? ie, the default shell (/bin/sh) will still be dash | 15:31 |
| pitti | slangasek: do you think it would be correct to change the SHELL default in /etc/default/useradd to bash? | 15:31 |
| pitti | chrisccoulson: yes, of cours | 15:31 |
| pitti | e | 15:31 |
| bdmurray | pitti: I'm looking at the match-error_messages function in the ubuntu general hook again an realized that VarLogDistupgradeApttermlog isn't check at all. Do you have any thoughts on how to handle that well? | 15:34 |
| cjwatson | interactive shells should be bash, not dash | 15:34 |
| cjwatson | system users or no system users | 15:34 |
| cjwatson | well, except that when creating a system user it generally doesn't really want an interactive shell | 15:34 |
| cjwatson | so let me revise that, just leave it at the default for system users, but non-system users should get bash | 15:35 |
| cjwatson | I don't think it would be correct to change /etc/default/useradd | 15:35 |
| cjwatson | why can't accountsservice just use adduser though? | 15:36 |
| cjwatson | that would be a sensible distribution patch | 15:36 |
| cjwatson | and it would respect adduser.local which is impossible to do with useradd | 15:36 |
| pitti | I tend to agree; we can also patch it in debian | 15:37 |
| Amoz | uhm, guys, my bash path contains no sbin dirs, how did that happen? seems to be a permission problem | 15:40 |
| pitti | Amoz: gdm/lightdm bug; it was fixed recently | 15:40 |
| pitti | Amoz: are you on current oneiric? | 15:40 |
| Amoz | nope | 15:40 |
| Amoz | UGR | 15:40 |
| Amoz | if that makes sense to you | 15:40 |
| pitti | ? | 15:41 |
| * Amoz likes gnomeshell, ubuntu gnome remix | 15:41 | |
| pitti | ah | 15:41 |
| Amoz | natty | 15:41 |
| pitti | Amoz: bug in gdm 3 | 15:41 |
| Amoz | -rwxr-xr-x 1 root root 71K 2010-07-02 09:28 ifconfig | 15:41 |
| pitti | or, in Fedora terms, a feature | 15:41 |
| Amoz | lol | 15:41 |
| Amoz | is there a fix for it? | 15:42 |
| seb128 | pitti, chrisccoulson: btw bug #64700 is similar | 15:42 |
| ubottu | Launchpad bug 64700 in puppet (Ubuntu) "newly added users have sh instead of bash shell" [Low,Triaged] https://launchpad.net/bugs/64700 | 15:42 |
| pitti | Amoz: the Ubuntu package now configures with --with-default-path=/usr/local/bin:/usr/bin:/bin:/usr/games | 15:42 |
| pitti | you need that | 15:42 |
| cjwatson | um, doesn't he also need /usr/local/sbin:/usr/sbin:/sbin | 15:44 |
| Amoz | O_O | 15:44 |
| cjwatson | or, you know, honouring pam_env | 15:44 |
| Amoz | yeah that's what I thought.. | 15:44 |
| cjwatson | https://wiki.ubuntu.com/OneTruePath | 15:44 |
| Amoz | lol | 15:45 |
| cjwatson | (i.e. we fixed this in dapper, please can people not regress it) | 15:45 |
| pitti | lightdm seems to DTRT | 15:45 |
| Amoz | DTRT? | 15:45 |
| cjwatson | hardcoding the default path in multiple places is explicitly contrary to that specification | 15:45 |
| pitti | "do the right thing" | 15:45 |
| Amoz | a | 15:45 |
| pitti | cjwatson: *nod*; it was a quickfix in Debian to get back /sbin | 15:46 |
| Amoz | my god... this router is killing me. no DNS | 15:46 |
| slangasek | jelmer: 812704> that would have been rpcbind again - trying to use --package-merge was probably an error, it was the first thing I tried after getting the reject from LP | 15:58 |
| slangasek | jelmer: so it may be sensible that the command doesn't work, but a nicer error would be helpful :) | 15:58 |
| jelmer | slangasek: which branch/revno is that, just ubuntu:rpcbind? | 15:58 |
| slangasek | jelmer: lp:ubuntu/rpcbind, -rtag:0.2.0-6ubuntu1 | 15:59 |
| jelmer | slangasek: merci | 15:59 |
| alex__ | if I'm packaging a gnomeshell extension (just some javascript and a python script) it should be packaged as a single binary? | 16:02 |
| === alex__ is now known as Amoz | ||
| Amoz | ls | 16:02 |
| === Ursinha-bbl is now known as Ursinha | ||
| slangasek | doko: the gcc-multiarch.diff is combined with a configure argument that sets MULTIARCH_DEFAULTS to *our* idea of a multiarch path. I don't know if that's sensible from an upstream design POV, but I think that's inherited from aloiret's patches and I didn't see any reason to change it | 16:03 |
| slangasek | doko: so for the default target, we do need to use the multiarch path because that's where all our system libraries are; and this is how we get it | 16:04 |
| slangasek | pitti: /etc/default/useradd> I defer to cjwatson :) | 16:05 |
| pitti | slangasek: ok, thanks | 16:05 |
| pitti | seems we should just call adduser there, and be done with it, and do that right in Debian | 16:05 |
| seb128 | pitti, will open a bug in the bts about that | 16:11 |
| slangasek | anyone else seeing some evolution component (probably the calendar factory) blowing up in oneiric, causing dbus to spin @ 100% CPU? | 16:13 |
| seb128 | no | 16:13 |
| chrisccoulson | slangasek, yeah. every time i click on the datetime indicator | 16:13 |
| seb128 | I've seen evolution components blowing up but no dbus spinning | 16:14 |
| chrisccoulson | indicator-datetime-service and e-calendar-factory flood the session bus here | 16:14 |
| slangasek | chrisccoulson: right, that sounds like what I'm seeing. | 16:14 |
| slangasek | chrisccoulson: is there a bug for it, by chance? Also, do you use evolution google calendar support, or does this happen regardless of calendar contents? | 16:15 |
| chrisccoulson | slangasek, i don't think there's a bug atm | 16:16 |
| chrisccoulson | but yeah, i use it to access my google calendar too | 16:16 |
| slangasek | I'll try to file one today | 16:16 |
| slangasek | chrisccoulson: thanks | 16:16 |
| seb128 | slangasek, chrisccoulson: I'm using google calendar and don't get that issue | 16:19 |
| pitti | for me it takes ages to load the google cals, but it doesn't spin the CPU | 16:23 |
| seb128 | same here | 16:24 |
| mvo | in my upgrade tester the machien will not find the rootfs anymore on the first reboot, has anyone seen something similar? | 16:39 |
| doko | slangasek: it works for the default multilib, but not for the non-default multilib. x86-64-linux-gnu is wrong for gcc -m32, it has to be i386-linux-gnu | 16:42 |
| slangasek | doko: well, -m32 still uses only /usr/lib32, which is ok at least on a transitional basis - I don't think we have all the existing biarch packages transitioned to multiarch yet, do we? | 16:44 |
| slangasek | I wasn't expecting biarch packages to start disappearing until multiarch provides a complete replacement | 16:45 |
| doko | no, but this case is already handled by MULTILIB_OSDIRS. but you should be able to find things in the new location too. just seen when building multilib for armel | 16:47 |
| tkamppeter | mpt, ping | 16:48 |
| slangasek | doko: however, if you think that we should start using multiarch paths for the non-default multilib, I am not strongly opposed to this :) | 16:48 |
| slangasek | doko: yes, I guessed that was the context | 16:49 |
| === mnepton is now known as mneptok | ||
| === cr3_ is now known as cr3 | ||
| bdmurray | ev: https://code.launchpad.net/~brian-murray/ubuntu/oneiric/plymouth/bug-787685/+merge/68429 mind reviewing that? | 17:04 |
| ubottu | Ubuntu bug 68429 in flashplugin-nonfree (Ubuntu) "CRLF injection vulnerability in Adobe Flash Player plugin" [Medium,Fix released] | 17:04 |
| bdmurray | heh that's kind of funny | 17:05 |
| Amoz | lol | 17:06 |
| Amoz | stupid bot! | 17:07 |
| doko | thank you lintian | 17:12 |
| doko | E: libhfgcc1: triplet-dir-and-architecture-mismatch lib/arm-linux-gnueabihf/ is for armhf | 17:12 |
| ev | bdmurray: done | 17:14 |
| ev | @pilot out | 17:14 |
| === 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: | ||
| === serue_ is now known as hallyn | ||
| Amoz | I'm trying to create a native debian package, but somehow this is a bit over my knowledge | 17:29 |
| kees | hallyn: so, it looks intentional, but can you confirm that the change to CAP_SETPCAP is intentional? (LP: #810022) | 17:30 |
| === beuno is now known as beuno-lunch | ||
| hallyn | kees: I vaguely recall a patch by eric paris to that effect | 17:36 |
| === davmor2_ is now known as davmor2 | ||
| hallyn | kees: found it (commenting) | 17:38 |
| kees | hallyn: a3232d2fa2e3cbab3e76d91cdae5890fee8a4034 | 17:39 |
| kees | hallyn: just found it too | 17:39 |
| hallyn | :) | 17:40 |
| kees | oh, you found the correct one, though. | 17:40 |
| kees | ffa8e59df047d57e812a04f7d6baf6a25c652c0c | 17:40 |
| kees | hallyn: so what's possible now that init has that cap by default? | 17:41 |
| kees | hallyn: the meaning of the cap hasn't changed, so why is it suddenly safe to have? | 17:41 |
| hallyn | kees: it's not sudden, it just wasn't done back when it was sudden. What changed was cap_setpcap no longer allows you to pass capabilities to another task | 17:43 |
| === cking is now known as cking-afk | ||
| kees | hallyn: well that was pre-fscaps | 17:46 |
| kees | hallyn: but, I guess that was actually kind of recent (intrepid and later) | 17:47 |
| kees | hallyn: okay, cool. I'm satisfied :) thanks! | 17:47 |
| === Zic_ is now known as Zic | ||
| === manjo` is now known as manjo | ||
| === abhinav- is now known as NetBSD | ||
| === NetBSD is now known as abhinav- | ||
| === beuno-lunch is now known as beuno | ||
| kees | @pilot in | 18:58 |
| === 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: kees | ||
| kees | man, merges are so ugly in bzr :) | 19:03 |
| Laney | the launchpad diff is, but bzr itself can be used to get the diffs you want out | 19:06 |
| kees | Laney: yeah, that's true. it's much nicer looking in actual bzr | 19:06 |
| pdtpatrick | Why is it dual screen on ubuntu .. it treats the screens almost like separate X windows. With the message status menu on both screen? Is this part of the design and if so --- plans to try something else in the future? | 19:38 |
| bryceh | pdtpatrick, is that with unity or "gnome classic (no effects)"? | 20:02 |
| mdeslaur | Sweetshark: I think the libreoffice package currently in natty-proposed seems to have reverted to the default theme. Is this a known issue? What's the bug # for the SRU? | 20:10 |
| === fenris_ is now known as Guest70853 | ||
| SpamapS | jelmer: Can I assume you were pinging me earlier today to discuss the natty-proposed bzr upload? | 20:28 |
| jelmer | SpamapS: hi | 20:28 |
| SpamapS | jelmer: anyway, I notice that there's already a version in natty-proposed, 2.3.3 .. is this meant to supersede that? | 20:28 |
| jelmer | SpamapS: your mind reading powers are working :) | 20:29 |
| jelmer | SpamapS: yes, this supersedes the 2.3.3 SRU, in which we found a small regression | 20:29 |
| jelmer | SpamapS: bug 786980 | 20:30 |
| ubottu | Launchpad bug 786980 in Bazaar 2.4 "bzr: ERROR: bzrlib.errors.ReadOnlyError: A write attempt was made in a read only transaction" [High,Fix released] https://launchpad.net/bugs/786980 | 20:30 |
| SpamapS | Alright, by the powers vested in me by the SRU team and in you by the micro release exception, I accept your upload, and pronounce you in need of verification. | 20:30 |
| jelmer | SpamapS: Thank you sir. | 20:31 |
| * jelmer bows | 20:32 | |
| mdeslaur | Sweetshark: never mind, found it | 20:36 |
| pdtpatrick | bryceh, it is with unity | 20:37 |
| * micahg hugs jelmer for remembering -v in th SRU | 20:41 | |
| SpamapS | micahg: indeed, thats been added to my list of checks to do during SRU. I wonder if there is an automatic way to flag this. :-P | 20:42 |
| jelmer | SpamapS: if you use UDD then "bzr builddeb -S --package-merge" will do the right thing | 20:44 |
| SpamapS | good tip | 20:44 |
| SpamapS | I'm more coming at it from the reviewer's angle though.. how do I make sure you used --package-merge :) | 20:45 |
| micahg | SpamapS: not offhand, you could check if there's a version in -proposed and if that version is included in source.changes | 20:45 |
| === Guest70853 is now known as ejat | ||
| lifeless | cjwatson: ping; bug 802985 | 20:48 |
| ubottu | Launchpad bug 802985 in eglibc (Ubuntu Hardy) "[lucid] /var/lib/dpkg/tmp.ci/preinst: 399: arithmetic expression: expecting EOF: "3.0-0-generic"" [High,Triaged] https://launchpad.net/bugs/802985 | 20:48 |
| lifeless | cjwatson: hallyn and I were just talking about this in -server; in the LP team we're doing a push on LXC for testing - both integration and local developer stories. | 20:50 |
| lifeless | cjwatson: that bug will mean all the team members needing a workaround, which we can put in our PPA; do you have any thoughts about which workaround is best - or can we be confident the bug will be fixed before oneiric release? | 20:50 |
| === yofel_ is now known as yofel | ||
| === kentb_ is now known as kentb-out | ||
| * SpamapS starts reconsidering his idea to add a feature to ifupdown after seeing the code... GAH | 22:09 | |
| === zyga is now known as zyga-afk | ||
| * SpamapS finds a way to do it cleaner w/o a mod to ifupdown.. thank god | 22:16 | |
| infinity | lifeless: Fixing debootstrap to fetch from -updates is the correct solution; patches welcome. Makes more sense than wasting time on workarounds, IMO. | 22:20 |
| davmor2 | kenvandine: you around still dude? | 22:39 |
| kees | @pilot out | 22:55 |
| === 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: | ||
| mwhudson | i want to build my own kernel (basically, the kernel that's in natty now + 2 patches) | 23:14 |
| mwhudson | is there a bluffers guide to doing this sort of thing? | 23:14 |
| poolie | yeah | 23:14 |
| poolie | https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel | 23:15 |
| lifeless | git clone the tree, install kernel-wedge and run it, then fakeroot debian/rules binary-generic | 23:15 |
| mwhudson | poolie: ah hey, guess which bug is motivating me :) | 23:15 |
| poolie | oh, external laptop displays? | 23:15 |
| mwhudson | yeah | 23:15 |
| poolie | I tremble for my country when I reflect that God is just -- tj | 23:15 |
| mwhudson | sigh, the build-dep step is finally installing texlive on my system | 23:18 |
| mwhudson | i avoided it for a while :) | 23:18 |
| poolie | heh, i know | 23:18 |
| poolie | also, the kernel is a lot bigger than it used to be | 23:18 |
| mwhudson | yeah | 23:20 |
| mwhudson | Receiving objects: 3% (64614/1983159), 21.44 MiB | 161 KiB/s | 23:20 |
| mwhudson | this is going to take a while | 23:20 |
| lifeless | yes | 23:20 |
| lifeless | I can probably send it to you faster | 23:20 |
| lifeless | SpamapS: yo | 23:20 |
| mwhudson | actually, i might have a git clone of some random kernel version lying around somewhere | 23:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!