[01:08] YokoZar, hey man [02:18] rickspencer3: you sure you want social-from-the-start? ;-) [02:28] LaserJock, ? [02:43] rickspencer3: the "fun" on identi.ca's !ubuntu [02:43] it's so depressing some days to watch that group [02:51] LaserJock, yeah [02:51] I should have just started blocking instead of speaking up [02:52] but if you let certain things go unchallenged, people think certain behavior is ok [02:52] yeah, it's tough to know what to do [02:53] much *more* difficult for Canonical people as well, since that often plays into the dynamic [02:53] LaserJock, yes, I fed the troll [02:53] but I don't just work for Canonical, I consider myself part of the community [02:54] since that predates me getting the job by a matter of some years [02:54] oh well [02:54] * rickspencer3 moves on [02:54] speaking of which, it would be nice to have a list of admins for that group [02:54] (to ping when spam [02:54] nigelb, yeah [02:55] I guess the ucoc doesn't extend to that group though [02:55] well, it extends to all ubuntu members who've signed the coc who're there [02:55] nigelb, good point [02:55] just like bugs [02:56] nigelb: I don't think it does. [02:56] speaking of which, I wanted to congratulate YokoZar on a well written critique [02:56] that will have more impact than any amount of trolling in !ubuntu [02:57] ScottK: "This Code of Conduct covers our behaviour as members of the Ubuntu Community, in any forum, mailing list, wiki, web site, IRC channel, install-fest, public meeting or private correspondence." [02:57] nigelb: Identi.ca isn't part of Ubuntu. [02:57] rickspencer3: I love that I'm immune to button placement controversies since I run UNE ;-) [02:58] LaserJock, oh? [02:58] I use UNE on my desktop actually, and I run the new themes [02:58] LaserJock: They just didn't get to you yet. [02:58] ScottK: I thought the coc applied to those who have signed it whereever we represented ubuntu [02:58] ironically, I button placement has no impact on me [02:58] exactly [02:58] nigelb: Certainly, but every time I mention Ubuntu, doesn't mean I'm representing Ubuntu. [02:58] I use keyboards for closing windows, and it took me less than a day to adjust to pointing with the mouse [02:59] rickspencer3: It's easy to get used to doesn't address the question of why the change is benificial. [02:59] I still didn't see that question addressed. [02:59] ScottK, I know [02:59] ScottK: ah, but if I swear at someone on the !ubuntu group that would be against coc? [02:59] ScottK: because it messes with notifications [02:59] I'm not really involved, but I wish the designers were a bit more communcative [02:59] LaserJock: But notifications are semi-transparent and click through so it doesn't matter. [03:00] That's the whole rationale for no actions. [03:00] but nasty-grams won't get them out of their shells [03:00] nigelb: I think it's orthogonal to the CoC. [03:00] orthogonal? [03:00] Unrelated [03:00] ScottK: the semi-transparent thing is sort of annoying, so if you never go up there maybe it helps? I dunno [03:00] ScottK: its kinda like a grey area to me [03:01] nigelb, perhaps someone should start a new !ubuntu group that does strive to have members that conform to the coc [03:01] and actually admin it that way [03:01] LaserJock: I agree. I tried the new notification style when we had a KDE version of it and really didn't like it. [03:01] rickspencer3: maybe !ubuntu-members? [03:01] dunno [03:01] I dunno, I'm meh about it [03:01] I just went back to using twitter more [03:02] LaserJock, but !ubuntu was a lot more interesting when it was a stream of what people were working on [03:02] agreed [03:02] rickspencer3: that's what I do. I use it to say what I'm working on [03:02] I guess there's still mostly that [03:02] nigelb, me too, mostly [03:02] it seems more like IRC+spam to me [03:02] oh well [03:02] rickspencer3: Since the Ux stuff is defined as a designer led effort, I guess I'm suprised they aren't prepared to communicate about it. [03:03] ScottK, yeah [03:03] I think it's just a really hard thing to get used to [03:03] yeah, I don't mind UI changes nearly as much as UI changes that lack rationale [03:03] like having to discuss with people who aren't just the client [03:03] Equally, I think that I can understand why people are getting upset about the lack of communication. [03:03] ScottK, ack [03:03] lack of communication is the single biggest cause of stress [03:03] I agree that reasoned discourse is better, it's just that I can understand being upset. [03:04] and when you don't speak up, you leave more room for trolls and rumor mongers [03:04] rickspencer3: perhaps it would help if their view of "client" was expanded a bit more? [03:04] and no way for anyone to defend your position [03:04] Yep. [03:04] LaserJock, yeah, it's a process though [03:04] I'm really happy to be working on distro that has a serious design team [03:04] sure [03:04] I was really impressed with mark's blog post [03:04] At this point I think they've pretty well lost public opinion on the moving the window controls. [03:05] so I expect in time we'll all figure out how this works [03:05] I don't think that they'll turn it around. [03:05] outlining what was going on, why, and most importantly going through examples [03:05] well ... tbh, I expect most folks will find in time that the window ordering thing is not as big a deal as they think [03:05] but I am biased, since I so completely don't care [03:05] and I think it looks better the new way [03:06] well, and it can be reverted at some point right? I mean we aren't technically even at Beta [03:06] LaserJock, sure [03:06] I think changing it back is still on the table tbj [03:06] tbh, even [03:06] it's going to make people gun shy if they can't even put out a design for testing without getting flamed to death [03:06] the right thing will happen [03:06] LaserJock: Probably. People usually learn the wrong lesson. [03:07] LaserJock, right, but to ScottK's point, the flaming is a bit of self-inflicted wound [03:07] true [03:07] if there were up front talking about it from the moment it released, I bet it would blow over [03:07] but the natural reaction would be to run the other way [03:07] yeah [03:07] yeah [03:07] it can be scary talking to "the community" [03:07] 1 good blog post with rationale for the changes would have done a world of good [03:08] Given the one sided nature of the discussion, if it doesn't get reverted, it will reinforce people's perceptions about Canonical not caring about community. [03:08] seeing the "community" as something other than real people that you can talk to [03:08] well, it's not one-sided, imo [03:09] (assuming you mean universal support for YokoZar's position) [03:09] rickspencer3: I've seen very little positive reaction. Most non-negative reaction seems to be "I got used to it". [03:09] it seems like everything but the button-placement has been discussed pretty well it seems to me [03:09] yeah [03:09] rickspencer3: No, it's not universal, but it's pretty strongly against the change from what I see. [03:09] I mean, man, what a small issue [03:09] but the only reasoning I've seen from a design person was something like "dunno, we're just having fun trying something out" [03:10] all the incredible stuff getting done in Lucid, and folks are so obsessed with button placement [03:10] LaserJock, I wonder if it is truly just a matter of taste [03:10] ? [03:10] rickspencer3: It's not really small. That's probably the second most common area for me to click on something. [03:10] fair enough [03:10] but still [03:10] which side is probably a matter or taste [03:10] the problem is cognitive momentum [03:10] it's a cost to change the habit [03:11] right, but that's the "you can never change UI" slippery slope [03:11] so the cost of the change needs to be lower than the benefit [03:11] yep [03:11] rickspencer3: Right, but if there was some communication of the benifit, people would be more open to it. [03:11] so the question is, is the aesthetic benefit worth the perceived cost? [03:11] that's why I think it's great to "test", but without rationale it's hard to see the benefit [03:11] ScottK, right, I think I am in raging agreement with you on that [03:12] Or if they had even said, "we're trying this out, let us know what you think" [03:12] or "we really really think foo" [03:12] instead of "new world order" [03:12] As it is, people think they are going to be stuck with it (which may be true) [03:12] where foo was pretty much anything [03:12] ScottK, well, not surprisingly, there are already two UI projects I've seen to control button placement ;) [03:13] rickspencer3: Yep. I'll be glad to grant a FFE for the first guy that packages one. [03:13] but, I think we need to figure out how to pull the design team out of their shells [03:13] I know them as specific individual people that I like [03:13] rickspencer3: I think the antecedent of we in that statement is Canonical management. [03:14] ScottK well ... [03:14] I think the community needs to figure this out as well [03:14] The community doesn't have access to them. [03:14] the Ubuntu developer community can't do much to help if DX doesn't give us anything to run with [03:14] though certainly as members of the community, folks inside canonical has a role to play [03:14] ScottK, not true [03:14] they have a channel and a list [03:14] and a lot gets done in those forums [03:15] rickspencer3: Dx does, but not the Ux people, AFAIK. [03:15] in fact, button placement has an interesting thread on their list [03:15] ScottK, #ayatana [03:15] rickspencer3: That's just Dx. [03:15] ScottK, nope [03:15] They don't decide this stuff, they just implement what they get told. [03:16] ScottK, though ironically, no on in design is online right now [03:16] one thing is the design team works co-located in rooms, not in front of their computers [03:16] so they can be hard to get on IRC [03:16] That's part of why I quit hanging out there. [03:17] * rickspencer3 nods [03:17] I don't know that the community really knows who they are, etc. [03:17] The general answer was "we just gdo what we're told" [03:17] gdo/do [03:17] ScottK, Dx or design says that? [03:17] Dx [03:17] sounds fun [03:18] ScottK, once again, you and I are in raging agreement ;) [03:18] Also, Ayatana has been defined as a design led effort, so why should they listen? They've been told it's there's to figure out. [03:18] on that note, I am going to the brew pub to fill our growler [03:19] 4 11 y.o. girls + 1 karoake machine + 1 sleepover birthday party = requirement for full growler [03:19] ;) [03:19] No kidding. [03:19] lol [03:19] good luck with that [03:24] grrrr, apps with 3+ rows of toolbars makes working on a netbook not-so-fun [03:29] later guys [07:20] hi, where i can consult about developing snmp application using snmpkit headers from libsnmp-dev? [07:24] xrc: as an Ubuntu app? [07:25] as an genereal linux app [07:25] not specific ubuntu [07:26] just ubuntu is working environment, where i develop [07:27] xrc: well, in the channel title is an ubuntu app development channel [07:28] ok, then let's talk about developing app for ubuntu [07:29] xrc: but the net snmp project is here: http://net-snmp.sourceforge.net/ and they might have their own IRC channel for general questions [07:31] they also state they have different header file structure and talk about package "net-snmp". ubuntu has differences from their perspective, so, i assume ubuntu has differences and somebody has done them [07:32] but, away from snmp: headers in /usr/include - they are just meant to be only structural headers, or are functions declared there availible somewhere? [07:32] xrc: well, we sync from debian, so I don't know about what differences we have, but maybe the #ubuntu-app-devel channel would be a good place [10:44] Guys is it known that you can't add apps to favourites in une? [11:02] questions: what is the exact definition of the "main" component? what's the exact difference with "universe"? [11:03] hi [11:03] !main [11:03] The packages in Ubuntu are divided into several sections. More information at https://help.ubuntu.com/community/Repositories and http://www.ubuntu.com/ubuntu/components - See https://wiki.ubuntu.com/RecommendedSources for the recommended way to set up your repositories [11:03] lucas: "main" is the set of stuff that is recursive dependencies, recommendations, or build-dependencies of stuff in main. [11:04] i'm quite interested in contributing in the Ubuntu projects but I don't know where to start and which one to work on, i've been reading a bit but can't seem to decide [11:04] do you have any tips and tricks about it? [11:04] you're interested in development? [11:04] yes I am [11:05] in that case most people would ask you to start bug triage [11:05] lucas: It has a loose mapping to a number of other things (e.g. Packages receiving security support, packages receiving translations in langpacks, upload permissions, packages that are used to build flavours defined as being in "main", packages supported by Canonical), but none of these are accurate descriptions. [11:05] kurapix: here you go for bug squad https://wiki.ubuntu.com/BugSquad [11:05] lucas: So there exist packages in main that do not fit into any of the more descriptive sets, and there exist packages not in main that do fit into each of those sets. [11:06] bug triage? going around launchpad and fix bugs? if I don't have a deep knowledge of the software being debugged, wouldn't it be a problem? [11:06] kurapix: you can triage bugs for some time and then slowly try to fix the ones you think you can handle [11:06] kurapix: bug triage is not fixing, bug triaging is handling bugs to confirm which of them is actually a bug and which is not a bug [11:07] oh ok [11:07] doesn't seem like a bad idea at all :) [11:07] kurapix: I myself started with bug triage and now I understand enough to fix small bugs, so I talk from experience too! [11:08] ok thank you for the tip :) [11:08] persia: so, to rephrase, there's no clear definition besides the recursive one. and the "all packages in main are supported by the Ubuntu team" claim is wrong, since there are packages in main that are not supported (except for major security problems, but clearly not for bug fixes, even important ones) [11:08] I'm quite interested in OS thing so I think it'll be a good thing to start :) and not to hide anything, I'm also interested in GSOC [11:10] lucas: Yes, I have found packages that were not being maintained at all, even with important bugfixes (in the "does not work at all for any purpose" category). [11:10] http://www.ubuntu.com/community/ubuntustory/components says: "When you install software from the main component you are assured that the software will come with security updates and technical support.". I wonder what the definition of "technical support" is. [11:10] I think it means you can purchase support from Canonical. [11:10] I see [11:10] Which is false, AFAIK. [11:11] Note that when we find packages not maintained in main, we make an effort to pull them out, and when we add new packages to main, there is a process that is supposed to make sure they are maintained. [11:11] wgrant: It is? [11:11] persia: sure, but then sometimes, you need packages in main because they are (build-)?depends that you can't drop [11:12] I don't believe commercial support is available for everything in main. [11:12] then someone uses that package directly (not as a depend) and it breaks [11:12] lucas: Indeed, and there's >1000 packages in main that were stuck in intiially, some that would most certainly not pass the MIR criteria if checked. [11:12] But my hazy memory of the hazy definition is hazy. [11:13] wgrant: too much haziness ;) [11:13] wgrant: Hrm. You might be right. I haven't investigated the options there in depth. [11:13] lucas: This complete lack of a definition for main is one of the drivers for ArchiveReorganisation. [11:13] persia: I thought that was an orthogonal issue? [11:14] ie main will stay because of the need to track (b-)?deps? [11:14] Essentially, by organising on a per-flavour basis, we can (presumably) identify sets of folk that commit to certain levels of support for sets of packages, but that's a long way off still (we're still working out how to set upload permissions, and haven't even begun the work on how to expose in the archive, or how groups can specify support) [11:14] is there a log of universe demotions avilable somewhere? [11:15] lucas: No, because seeds track (b-)deps just fine, if asked. main is going away, but it will take a while. See https://wiki.ubuntu.com/ArchiveReorganisation/Components [11:15] mr_pouit: The info is in LP: one may be able to extract with lplib. Much like MIRs, they are mostly tracked in bugs. [11:16] (although not always, when an archive admin digs at component-mismatches with a will) [11:17] persia: so it's even worse, because ruby1.8 (in main as a dep, not cared for), will be in even more sets are a dependency [11:17] s/are/as/ [11:17] persia: and a more direct way? Because someone just demoted lots of (b-)deps of abiword to universe *without warning*, and I'll have to find which ones, and rebuild them because otherwise all translations will be missing… [11:18] lucas: Well, in the short term, yes, in the longer term, perhaps not, depending on what level of "support" we expect from those who indicate that they provide support for something. [11:19] mr_pouit: I don't know of any. Sorry. [11:19] mr_pouit: Maybe an archive-admin can check some log? [11:19] You can get a list of universe publications from LP ordered by date. [11:21] ahah, ok, so I have to waste time doing that because some archive-admin thought I was a good idea to throw them to the garbage-can^W^W universe without warning [11:21] *it was [11:22] that's always the same thing [11:22] and that's aboring [11:22] We really need to sort the Rosetta part of Archive Reorg soon. There's a bunch of packages in universe with langpacks in a special list, and regular accidents with stuff moving in and out of main. [11:23] It oughtn't be hard to just drop the component check, and use lists. [11:23] How does that help this situation? [11:24] wgrant: Because the list wouldn't change when the component changed, and when the list changed, reuploading could occur if required. [11:24] Doesn't help retroactively, but avoids recurrances. [11:24] (and we already have code in place to be able to do it, which is always nice) [11:24] persia: nothing has changed since hardy. For hardy, all xubuntu was demoted to universe, and I had to rebuild everything myself, nobody helped [11:24] Well, I guess it does slightly solve it. [11:25] mr_pouit: I know. I've been in discussions about ArchiveReorg since shortly after Hardy release. Progress is just slow. [11:25] But we need a good solution to translations. [11:26] wgrant: What would you suggest, if not using lists? [11:26] persia: How do we declare which lists are included in the langpacks? [11:26] wgrant: Same as we do now. [11:27] persia: That's impossible. [11:27] * persia doesn't know the details, but was told firmly that there were override lists to permit additional packages in universe to be included in each langpack [11:27] main will cease to exist. [11:27] but there is a quick fix: communicating on ml or LP. For example when someone uploaded a new libxkavier package that bumped the soname, nobody was notified, main was fixed, and universe packages were let broken [11:27] mr_pouit: NBS is the way to handle the SONAME stuff, really. [11:27] debian people are (almost) able to coordinate transitions, so why can't we do it in ubuntu? [11:27] persia: no, bug reports are the way [11:28] mr_pouit: Let's focus on translations: that's a separately soluable issue. [11:28] but it's the same "I don't care of what could happen in universe" idea [11:28] No, bug reports are very much *not* the way. That class of bug report causes way to much mail for people who don't want it. [11:28] they should just unsubscribe then [11:28] They can't. [11:28] add mail fiters [11:28] whatever [11:29] because otherwise we're not notified [11:29] I know a number of upstream developers and Debian Developers who have decided not to subscribe to LP bugs for their packages precisely because of such bugs. [11:29] Just poll NBS regularly. [11:29] sorry, that's wrong [11:29] Using bugs for that purpose has been tried, and it went disastrously in some cases. [11:29] We often don't even know when a transition happens, because it's autosync. [11:29] so there's no person who would file the bug. [11:30] I'm supposed to read all -changes@ and NBS to detect all possible breakages caused to xubuntu by the desktop team [11:30] do you know how mcuh time I waste for that? [11:30] time that could be used better? [11:30] approximetely yes. [11:30] But note that not all breakage is caused by someone doing something specific. [11:31] When it is, and nothing gets done, and there is no notification, replying to the -changes mail asking for notification is appropriate to encourage cooperation. [11:31] But lots of transitions happen anyway, when nobody takes specific action to make them happen. [11:34] Any ubuntu-release team members here (and not busy)? [11:36] persia: bah, already tried, nothing changed. The changes in desktop files some releases ago (which broke kubuntu translations), or the "let's introduce appindicators everywhere and oversize the xubuntu cd" recently, everything has been done after the ff without warning. So everything's fine, and I'll stop complaining. [11:37] No, everything isn't fine. [11:37] That sort of intentional change needs to be communicated. [11:37] Filing a bug that affects umpteen packages just isn't the way to perform that communication. [11:37] It should be an email to ubuntu-devel@ [11:40] Right, that's precisely my point, I don't care of the way (bug report, ml, ping on irc), if there is some communication. But that's not the case. [11:41] For the set of intentional changes, I agree with you except I strongly feel it shouldn't be a bug report. [11:41] For the set of autosync changes, I don't think anyone can be expected to know to send such communications. [11:41] But after DIF, it ought be clearer, and after FF, it ought not happen. [12:04] mr_pouit: personally, when I do intentional transitions, I make an effort to fix everything, not just main - see the recent parted transition for instance. That just seems like good engineering to me. persia's right that there isn't always a deliberate action in Ubuntu associated with such changes though, unfortunately [12:07] cjwatson: Unfortunately, not all are as diligent as you, and some go so far as to share their opinion that it isn't important in public fora. I believe this to be entirely a social issue, and soluable through gentle queries (noting that there's usually a few people willing to help with any particularly large transition if it's just a volume-of-work thing). [12:09] I can understand that some transitions are more work than others, but I think wilfully ignoring it (and not at least telling people that there's something to do - you don't have to spend hours and hours on it yourself, necessarily) borders on negligence [12:10] Indeed. [12:10] to be frank [12:11] obviously sometimes it's just load-induced forgetfulness, don't assume malice when forgetfulness will do etc. [12:11] Personally, I've yet to see a case where a call for help with a transition was announced on IRC or the mailing list that didn't get at least two people helping. [12:19] Can anyone from release team take a look at this FFe - bug 534289. Without this the x264 plugin in gstreamer does not build with latest libx264. [12:19] Launchpad bug 534289 in gst-plugins-ugly-multiverse0.10 "[FFe] New upstream release 0.10.14" [Undecided,New] https://launchpad.net/bugs/534289 [13:03] on karmic, printf(3) docs say libc supports %z, but when i build with libc6 it turns out to not be supported at all. any ideas? [13:03] oh, duh, i forgot d/u [13:14] slacker_nl: FTBFS is a pretty good reason [15:31] ? [15:31] I think tabfail ;) [15:31] slacker_nl: was meant for shadeslayer I guess [15:33] nigelb: i think a tabtypo [15:33] yup [15:34] I've been trying to get a new workflow for bugs with patches attached. Its still in discussion but if anyone has any thoughts on what we're come up with, I'd be happy to hear http://etherpad.com/L6x2FUVnYi [15:34] s/'re/'ve === yofel_ is now known as yofel === geser_ is now known as geser [17:33] is it time to revamp the Gnome properties dialog box to look more like the NT Security Settings dialog box? [17:34] we've had POSIX enhanced ACLs forever [17:34] can add multiple user and group permissions to files; set the owner (user) and group; and set permissions individually [20:06] bdrung: Apparently your glib2.0 patch broke sparc. Please fix. === Jonbo is now known as Jonbo|Away [20:17] hi all. it appears that COLUMNS is not exported by bash by default. why is this? [20:18] i'm used to systems exporting COLUMNS and LINES [20:26] hdon: hello, it is exported for me in the gnome-terminal. but this is definitely the wrong channel for this question === sconklin is now known as sconklin-afk [23:28] good night [23:47] ScottK: do you have a build log?