=== aos101_ is now known as aos101 === azeem_ is now known as azeem [00:37] jcastro: so the loco thingy is in 23 minutes? [00:37] crimsun: yep! [00:38] jcastro: okay. [00:38] crimsun: christer tells me it will be pretty q+a based [00:38] so I was thinking [00:38] if people ask about motu stuff we just shuffle them in here [00:38] jcastro: sure. [00:46] wasabi! [00:46] vista? No! [00:46] yes, I will do the vista qa [00:46] packaging for vista 101 [00:46] what chan is this loco thing in? [00:47] I'm thinking ubuntu-us [00:47] not in the topic there...heck, I can't even find info on it [00:56] Fujitsu: CVE-2006 -3122 is already fixed afaict. Did I miss something in it? [00:57] (oh, dapper, edgy.... erk) [00:57] Fujitsu: that was an oversight. [00:59] Fujitsu: CVE- 2007-6131> yeah, seems like to make it vulnerable, it'd have to be edited manually anyway. [00:59] keescook: Yep, missed a single character.. [00:59] Right. [01:00] keescook: Is there anything that needs to be done with rejects other than removing them and adding them to not-for-us? [01:03] Fujitsu: if there are no notes, etc, just bzr rm and add to not-for-us [01:04] keescook: Otherwise throw it in ignored/? [01:04] Fujitsu: if there are notes, just mark everything not-affected, replace the description with ** REJECT ** and move it to retired [01:04] Ah. [01:04] I'd use retired since it was "processed" in some way, ignored is "kinda open, but actively ignored by us"... not a clear distinction, I guess. [01:05] True. [01:06] and if it's dumb, I'm happy to re-arrange stuff. It made sense at the time. ;) [01:06] I think your way makes sense. [01:09] I think it would make sense to remove much of the information from the branch once malone gets an external API, as there is a lot of duplication at the moment. Bug URLs, assignees, release statuses are all in Malone too. [01:10] (me advocating moving stuff to LP? Never thought I'd see the day) [01:18] bug 134795 if in fact this bug can be confirmed, is it security-vulnerability worthy? [01:18] Launchpad bug 134795 in gsambad "GSAMBAD switches User and Password match levels" [Undecided,New] https://launchpad.net/bugs/134795 [01:18] sistpoty: Yes, it was on purpose: I'm not sure any of those are important enough to fix for a package that is essentially a single text file. [01:19] does not effect gutsy or hardy but does effect feisty which I believe we will support until oct 08 [01:19] apachelogger: Please don't advocate the removal or non-inclusion of menu files. While .desktop files fill the needs for many users, some people still require menu files to work around non-compliant window managers. [01:21] Fujitsu: right, I basically got sick of LP having everything we needed to track, and set up the tracker separately. Once we know "how" the tracker should work, that should hopefully help guide the LP bits when that rolls around again [01:21] keescook: LP *not* having everything, you mean? [01:22] sorry, yes [01:22] hehe [01:23] LP's CVE abilities are very unfinished. [01:23] Fujitsu: keescook: Could I ask about bug #173153? Specifically, it appears that the code path tries the user preference temp directory, then, if that fails, tries a default temp directory, and then, if that fails, asks the user to enter a new directory on the next run. I don't understand how the attack works. [01:23] Launchpad bug 173153 in audacity "[CVE-2007-6061] Denial of service and deletion of an arbitrary directory tree via symlink attack" [Undecided,Confirmed] https://launchpad.net/bugs/173153 [01:23] So yes, we'll need to kick them into doing something once we work out what needs to be done. [01:24] persia: reading... [01:24] persia: Hmm, I haven't actually tested it, but the description on the Gentoo bug makes sense to me. [01:24] gentoo bug #199751 [01:24] The symlink attack only works on quit. [01:25] Fujitsu: Right, but audacity opens the directory on start, and closes & removes on quit. Is this just a race condition on quit? [01:26] (it does use 755 strangely, rather than 700, but that's different) [01:26] persia: yeah, without reading code, it seems like a real issue, with races too maybe. [01:27] keescook: I am reading code (familiar with the codebase), but don't understand the nature of the problem well enough to fix it. [01:29] persia: okay, one sec, I'll dig in (currently research DDR2 prices...) [01:30] e.g. What should it do? On start, it tries to create (and open) two directories (primary and fallback), or asks the user. On quit, it closes the directory, and removes it. Is the problem a race condition on quit? [01:30] (and no rush :) ) [01:31] s/e.g./i.e/ [01:31] * Fujitsu just got it to eat a directory tree. [01:33] bug 134795 needs sponsor [01:33] Launchpad bug 134795 in gsambad "GSAMBAD switches User and Password match levels" [Undecided,Confirmed] https://launchpad.net/bugs/134795 [01:34] i don't really like malone [01:34] it is arguably a minor secure vulnerability too [01:34] Fujitsu: Ah. I see. Use of rm_dash_rf_execute without pre-checking. I still don't understand the denial-of-service bit, but I'll try to fix the directory eating bit in the next bit now. [01:34] LordKow, more of those bloody UI config tools [01:35] yes, its evil [01:35] s/in the next bit// [01:35] LordKow, the author of that thing claims he knows me. i don't know who he is though :/ [01:35] persia: Right, it seems to prompt here on startup if I create /tmp/audacity1.2-william as another user. I then click Yes, create a symlink as another user, and blow away some directories. I can't see the DoS. [01:35] the author of the app or the report? [01:35] LordKow, app [01:35] "GAdminTools project" [01:36] ah, yea the way the ui is handled is ridiculous. completely depends on the order of the code [01:36] and its still that way in the most current, 0.1.8 [01:36] Fujitsu: OK. I was looking too closely at the DoS, and not closely enough at the dispose of everything problem. Thanks for pushing me in the right direction. [01:37] persia: The Gentoo bug states that you need to change the owner while audacity is running. If an attacker can do that, you're already stuffed, are you not? [01:37] LordKow, i think the whole concept of UI admin tools is unsound, sorry. [01:38] Fujitsu: Essentially. If someone else has rights to change ownership on your files, there are other more critical possible vectors. [01:38] i will respectfully disagree to that :) [01:38] sometimes admins are in a huge hurry and gui is usually a lot faster than sifting through config files [01:38] persia: Yep. [01:38] LordKow, UI admin tools cause things like servers getting rooted because their admin is a stupid moron who can't admin his server without a GUI [01:39] LordKow, moreover, UI admin tools cause things like X running on a server which is inappropriate at best [01:39] So the remaining vulnerability seems to only exist if the user dismisses the initial warning, but that's not much of a warning. [01:39] nenolod: I'll agree with that, but please also consider the poor home user. [01:39] nenolod, you are probably right but its not a reason to remove it from the repos. [01:39] persia, sure for a home user it is fine [01:39] LordKow, i'm not proposing removing it from the repos [01:40] Fujitsu: No, and I don't think changing the wording is the right way to fix it. I don't see the value of rm_dash_rf_execute anyway: `rm -r` should really be the right thing to do. [01:40] ah k, i thought you were trying to go somewhere besides a rant ;-) [01:40] however, i strongly feel that ubuntu should not become the next Windows 2003 [01:40] ;p [01:40] i should send this bug upstream to debian since i see they still use 0.4 [01:41] persia: How is removing the -f going to do much? === Amaranth_ is now known as Amaranth [01:41] Fujitsu: Doesn't remove files set read only, or belonging to someone else. [01:41] Ah, I didn't know of the ownership bit. [01:41] (not that the implementation is with rm anyway) [01:42] You're right, that works. [01:44] On the other hand, digging more, it appears that it only calls wxRemoveFile(file); recursively, so the -rf is just poor nomenclature. Now I'm tempted to look at the start again, but I'm not sure how to 1) create a secure reusable temp directory that 2) can be in a user-specified location to use high-IO-speed media. [01:44] http://mange.dynalias.org/linux.html [01:44] however, i would say the attitude of this author of GADMINTOOLS might be a good justification of removing it from the repo [01:44] on his site he advocates "taking down freenode" [01:45] persia: Can you not use mktemp on any template? [01:46] re-usable temp dirs in a world-writable dir is hard to get right. :( [01:46] keescook: Mhm. [01:47] Fujitsu: mktemp and mkstemp aren't available in a way that still works for Windows :( I could hack it in, but that might break the WX file handling. [01:47] I think you can open the dir and use fdstat to determine who owns the directory in a safe way [01:47] persia: Oh, true... [01:47] portability, though, ergk [01:47] * nenolod plays with the idea of packaging BSD pcc as an alternate compiler [01:47] keescook: http://www.wxwidgets.org/manuals/2.6/wx_filefunctions.html#filefunctions are the functions available (unless we want to call this a WX bug) [01:48] persia: Ah, if I o+w the directory, audacity doesn't warn at all. That's what I missed. [01:49] persia: What does it do on Windows? There's no /tmp there... [01:50] Fujitsu: OK. So if someone sets their preferences to point at a symlink that points somewhere to which they can write, the cleanup recurise remove runs without warning. Do I have that right? [01:50] Or are there still c:\temp dirs in recent versions? [01:50] persia: No preferences required. [01:50] Fujitsu: It first tries the path in preferences. If that fails, it tries the default path. If that fails, it asks the user to change the preference. [01:51] In that case, I think you're hitting the default path. Perhaps just not try the default path, and force a preference setting? [01:51] Fujitsu, C:\Documents and Settings\Administrator\Temporary Files [01:51] persia: If login as another user, create /tmp/audacity1.2-william, chmod o+w it, create a symlink `projectsomething' to /home/william. [01:51] Then wait for them to open Audacity, close it, and watch their ~ die. [01:52] persia: Forcing a preference sounds very anti-Just Works. [01:52] if portability is the issue, see glib's g_mkstemp [01:52] Fujitsu: Right. There's definitely a problem. Further forcing a preference sounds wrong. Perhaps forcing the default to be created afresh? [01:53] the "open" needs checking, I think. If you know the directory is good with safe perms, then all the other removal stuff is safe. [01:55] Grrr.. WX doesn't support file ownership. Looking at glib. [01:55] keescook: If it's not 755, bail out? [01:55] * Fujitsu wonders why wx covers some of the stuff it does. [01:55] Fujitsu: Someone was very bored. [01:56] Fujitsu: right, or bail if fdstat owner != self or o+w [01:57] keescook: You don't regard g+w as mildly unsafe? [01:57] Hmm.. How about changing the default logic to use wxFileName::CreateTempFileName, and if that succeeds, drop it and put in the directory? There's a race condition, but it's less bad. [01:57] yeah, should probably check that too... symantics get weird for groups stuff... maybe they DO want to share their audacity temp dir. (who knows why) [01:58] keescook: Right. [01:58] There's no good reason to share an audacity temp dir: it's only currently streaming data there. [01:58] fair enough. :) [01:59] so, why is it in a static location? (i.e. why not create a new safe tempdir on each invocation?) [01:59] That's what I was wondering. [01:59] It cleans it too thoroughly on exit anyway. [01:59] keescook: That's a good question. The only static part that is interesting is allowing the user to control the device, and using tmpfs by default. [02:00] persia: What does the tempfile function you mentioned earlier do?\ [02:00] Right. Because of the aggressive cleaning, I think it should just complain if the default directory already exists, and refuse. [02:01] erm, what's the simplest solution here? Introducing races is a bad thing. [02:01] Fujitsu: creates a 600 file iff it can find a brand new location in which to do so. Looking more carefully, it's not deterministic with regards to device, so it's not a good solution. [02:01] Ah. [02:02] crimsun: I think the simplest solution is to just not use the default location unless the directory can be created at startup. [02:02] * keescook nods [02:02] persia: The directory isn't deleted on exit [02:02] (the preferences definition is the user's own problem) [02:02] Fujitsu: I can change that. [02:02] I'd say always create a temp dir [02:02] persia: Not for existing installations (although it is a tmpfs) [02:03] keescook: Even if the user specified one in preferences? Perhaps a default-named tempdir under the user-supplied path? [02:03] Fujitsu: Sure. Users who have previously run audacity since the last reboot have to delete a directory or reboot. That's what NEWS.Debian is for, no? [02:03] I think the if-not-owned-by-us test is sufficient for the set-in-prefs situation [02:04] honestly, you probably want to bring it up with upstream. [02:04] keescook: There isn't a if-not-owned-by-us test that can go upstream. [02:04] * persia decides to have breakfast, and comment on the upstream bug rather than fixing it [02:04] persia: Late breakfast. [02:05] keescook: How often do you normally wave your magic uploading wand over things? [02:05] Fujitsu: I tried to clear the REVU queue last night, and failed to notice until it was quite late :) [02:06] persia: Ah. [02:06] I do like the new segregation and ordering. [02:06] Makes it much easier to find targets for reviews. [02:06] Definitely. [02:11] moins all [02:12] Hi imbrandon. [02:12] heya [02:19] Fujitsu: I have carved a section out on mondays for it. Is there stuff waiting right now? [02:20] how do i document a program consuming 100 percent cpu? [02:20] keescook: There are a few things, but they can wait. I was just wondering if you did have a certain time for it. [02:20] Deluge-torrent is eating up an entire core [02:21] but im not sure i can duplicate it =/ [02:21] pwnguin: Have you checked what it's doing? [02:21] pwnguin: I'd run strace -f -s 1024 -p $PID 2>/tmp/whoa.log then wait a few seconds and ctrl-c it. [02:21] What keescook said. [02:21] /tmp/whoa.log should show a bit about what it's spending it's time doing, though that may not really answer the question. :P [02:22] hmm [02:22] looks like its mostly kernel mode [02:22] good idea on the strace then [02:24] heh, doesnt respond to control-c [02:32] Heya gang [02:32] bddebianisagod! [02:32] pfft [02:32] Hi Fujitsu [02:35] Evening, Hobbsee. [02:36] hi Fujitsu [02:36] i dont think it's evening yet... [02:36] It's getting there. [02:36] * persia thinks it depends on where you think you are [02:37] Evening? Its barely past lunch time. [02:37] Heh. [02:37] keescook: so how do you kill that strace? [02:37] pwnguin: normally ctrl-C just works [02:37] if not, I tend to ctrl-z, kill %1 [02:41] TheMuso: that was my thought [02:42] * Fujitsu is well known for greeting with completely bogus $TIMEOFDAY, even in real life. [02:43] Real life? THis is real life. :p [02:43] Heh. [02:43] * Fujitsu has work too, so there is some other real life. [02:43] * Fujitsu now vanishes for a couple of hours. [02:45] must be time for breakfast. [02:46] breakfast @ 1:46pm ? [02:46] Good night fujitsu [02:47] yes, and? [02:47] DarkMageZ: btw, ubuntu-main-sponsors exists [02:48] why/when did i want to know that ubuntu-main-sponsors exists? [02:50] DarkMageZ: evan's mail to -devel-discuss. although i guess you put the debdiff in after that [02:50] DarkMageZ: either way, when you put in a debdiff, you probably want to subscribe the sponsorship team for that component, so it gets in [02:50] Well, -security stuff is a little different, but otherwise... [02:50] is this in reference to what i did to rhythmbox? [02:51] DarkMageZ: yeah [02:51] ah, i c. i'll try and keep that in mind. [02:55] is there a won't fix status for lp bugs? i can't seem to set it with my limited powers. [02:55] there is, but yes it requires powers [02:55] (offhand I couldn't tell you which) [02:56] could someone kill bug #74125 with won't fix? [02:56] slangasek: being in what was -qa [02:56] Launchpad bug 74125 in libvisual-plugins "dfsg removed plugins > libvisual-plugins-multiverse?" [Wishlist,New] https://launchpad.net/bugs/74125 [02:57] i think it's -buglords now [02:58] lol [03:01] Yay. Installed. [03:01] * Hobbsee installs automatix on TheMuso's machine, to see if he says the same thing [03:02] isn't installing automatix on someone elses machine an act of terrorism? [03:03] DarkMageZ: You're pronouncing it wrong: turrsm... [03:03] DarkMageZ: listen to the state of the union address again... [03:03] DarkMageZ, sabotage at very least [03:03] it's an act of war. [03:04] jdong, where does one aquire a bush translator, do you know? [03:04] We need to defeat them at their repository before they come and invade our own repository. [03:04] ok enough Bush parody for one night :) [03:04] it hurts. [03:04] elkbuntu: foxnews.com :) [03:04] elkbuntu: what he said. [03:04] Is there an application that MOTUs and try-hard MOTUs use to create, check and build packages? Maybe integrated with REVU. [03:04] frenchy: pbuilder, lintian, linda.... [03:04] lintian/linda [03:05] there are some review tools somewhere, actually [03:05] I know there's a lot of bits and pieces that people use. But ... [03:05] Hobbsee: in the archive, not sure how upto date they are [03:05] frenchy: no, there's nothing magically integrated together yet [03:05] an integrated one? no, not unless you're talking about revutools [03:05] imbrandon: ahhh [03:05] They are just that ... bit's and pieces. [03:05] frenchy: yup [03:07] I'd like to build one (GTK based) that you can point at an upstream URL (or local) file and it takes you through a wizard asking you things like name, description. Then does the build for you and does the linda/lintian checks for you. [03:07] frenchy, would it also build it for you? [03:07] frenchy: sure, your free to doso, its been talked aobut before just not acted upon [03:07] The checking part of the application could be used to check existing packages on REVU. [03:08] * Hobbsee twitches [03:08] Hobbsee: You don't like? [03:08] sounds like the evil checkinstall. [03:08] Hobbsee: oh I've seen worse :) [03:08] frenchy: anything that involves a "wizard", instead of making you modify debian/control yourself...is bad. [03:09] Hobbsee, not if it is done correctly. [03:09] DarkMageZ: where correctly is "give a GUI to fill in the fields yourself"? [03:09] Hobbsee: I really just meant for initial creation. From then on it's the maintainers responsibility to keep it updated but the tool could still warn you about issues in the file. [03:10] frenchy: you still need to set everything in debian/control for initial creation [03:10] after htat, there's a tool called uupdate [03:11] if the tool is comprehensive it could be very useful. [03:11] otherwise it'd be a waste of time. [03:11] * Hobbsee wonders what's so unfriendly about a text editor. [03:11] Hobbsee: well if it's emacs I can understand the pain. [03:12] *hides* [03:12] jdong: sure, i meant a text editor of choice :) [03:12] There's just a lot of "bit and pieces" to put it all together. I think that it's quite daunting for a new person and wastes MOTUs time with basic questions. [03:12] * imbrandon wonders what Hobbsee has against people trying, it could be something good [03:12] imbrandon: only the crack that they'll come up with, if it's anything like checkinstall, tbh. [03:12] Hobbsee: who said it would be? we had talked about just this before [03:13] with deb checking etc [03:13] true. maybe it works. [03:13] :) [03:13] frenchy, could you include the ability to build a package and save it (as a module) and then later when you're building another package that depends on the first package that it could be easily added to the build system? [03:13] if it works well then yeah a more streamlined approach would be fantastic [03:13] it *could* work is all i'm getting at, no need to be negitive from the get go [03:13] :) [03:13] imbrandon: +! [03:13] +1 [03:14] imbrandon: Well I was thinking of calling pbuilber to do that. Will that work? [03:14] frenchy, i'm forever playing with packages that require a new library or a newer version of a library that is not part of the repos. [03:14] DarkMageZ: Sorry, that was for you ^^^ [03:14] DarkMageZ: I have my pbuilder (prevu) output to a local repo which is in turn used in subsequent builds. Works fantastically for me [03:15] frenchy: not if the debian/control isnt filled out properly, honestly the tool is a great idea, but no offence it need someone with alot of packing experince to create it [03:15] That [03:15] 's where you guys come in. [03:15] jdong: What do you use to manage your repo? [03:15] TheMuso: prevu does it with dpkg-scanpackage calls after every build [03:15] I'll learn and have a self documenting tool at the same time ... just an idea. [03:16] just dont write it in perl :) [03:16] lol [03:16] imbrandon: Although I think the best choise is python ... I'm a c/C++ guy. [03:16] jdong, interesting hack. maybe something alittle more complex could be used in frenchy's tool. [03:17] DarkMageZ: yeah, the concept is there but of course it can be done more elegantly. [03:17] imbrandon: write it in scheme!!! [03:17] jdong: Right. That is certainly quick and dirty [03:17] I'l do anything tat you guys ask. [03:17] * TheMuso has shell scripts almost complete to properly make and update a repo using apt-ftparchive. [03:18] And they use a little flat file db. [03:18] I like XML. Does anyone hate XML? [03:19] [03:19] low [03:19] [03:20] jdong: That's a no? [03:20] frenchy: meh that's just me being a smartass. I don't care :) [03:20] it just ALWAYS seems XML is ridiculously verbose without any visible benefits [03:20] jdong: Or are you just merely stating that XML is verbose. [03:20] Yeah [03:20] frenchy: there are always oponents to everything, best case is "just do it" and if someone cares enough either way they will help [03:20] :) [03:21] frenchy: don't use my opinions in deterring you from picking a format *you* like. [03:21] imbrandon: Ta [03:21] frenchy: I've used the Python editor in IDLE before. I can bear anything. [03:21] :D [03:21] IMO it should be human readable [03:22] XML is, but isn't. [03:22] XML isn't. [03:23] Hang on ... what was the DB for? === vorian_afk is now known as vorian [03:24] storing a structure of previously built packages. so i can pick bits and pieces for use in building packages later [03:24] I was thinking of using it for preferences and recently dl'ed packages list. All of which will be editable from the interface. [03:27] DarkMageZ: won't pbuilder do that for you ... I don't know .. I thought that it could. [03:27] frenchy: What interface were you thinking of [03:28] TheMuso: GTK, is that what you're asking? [03:28] frenchy: Yes. I don't see the point in having a GUI for such tools. [03:28] frenchy, it won't do it automatically. it requires a fair amount of pain. [03:28] DarkMageZ: aka ccache? [03:29] Hobbsee, na. ccache is fun [03:29] Personally, I'd be in favor of such a tool, if the focus was on a dh-make replacement to build a better sample, rather than a checkinstall replacement, to make a new package. [03:29] persia++ [03:29] s/sample/example/ [03:30] persia: ++ [03:30] i'd prefer if the tool was capable of both [03:30] * TheMuso would prefer if the tool actively discouraged checkinstall. [03:30] DarkMageZ: Just add a hook that calls lintian, linda, pbuilder/sbuild, lintian, and linda [03:31] DarkMageZ: More explicitly: the wheel shouldn't be reinvented just because it can, but dh-make is not necessarily strong enough to do the right thing in many cases. [03:32] To put it another way, I'd prefer an interactive wizard that helped the user to create a starting debian/ directory, rather than copying a bunch of examples that just have to get deleted later. [03:32] DarkMageZ: I refer you to jdong's earlier comment: "I have my pbuilder (prevu) output to a local repo which is in turn used in subsequent builds. Works fantastically for me" [03:32] persia: Yeah that sounds good. [03:33] persia: Exactly ... exactly what I mean. [03:33] I'm sure you guys must get sink of noobs, like me, getting on, asking for a REVU, without knowing all the tools/rules that I could've used. Same thing every time. [03:34] I didn't even know what linda/lintian was before I asked for my package to be reviewed. [03:36] Sure, my bad but I'd expect you see a lot of this. [03:36] frenchy: Indeed, yes. It's not so bad to explain lintian & linda, but it's frustrating to see the same dh-make induced errors on so many packages. [03:38] persia: I understand you frustration ... but people don't know until they are told or they read it ... but they've got to *know* that there's something to read. There are so many bits and pieces. [03:39] And of course, it's not all selfless ... I'll learn a shit-ang load from you guys in the process. [03:41] So, I might just start with a simple wizard that can create a debian project from an upstream. I wanted to do this for w_scan anyway. [03:42] And no, I won't call it "Me Packager"! [03:49] DarkMageZ: Do you know if jdong's solution suits you? [03:51] frenchy, it's a hack that could be potentially useful. but if your tool is going to build the packages as well. it could be very useful to integrate something like that properly and cleanly [03:52] on't forget there are also those of us who use sbuild with LVM snapshots. [03:52] don't [03:56] DarkMageZ: TheMuso: when it comes to that part I'll talk about your requirements on a little more detail. Thanks both for your comments. [03:57] TheMuso: Now, you didn't like my idea of a GTK interface. Can I ask why? [03:58] * Hobbsee bets the ansewr is "accessibility" [03:58] persia: Do you actually play conquest? [03:58] gtk is slow and flaky. etk or qt4 ftw :) [03:59] DarkMageZ: Ahhh ... are you a KDE guy? [03:59] kde rocks :) [03:59] Sorry, I've programmed and used them all and I think that GNOME is da bomb. [03:59] frenchy, nope. just anti gtk :) [03:59] although i will assume TheMuso will not like qt moreso than gtk :) [04:01] imbrandon: qt4 was one of the suggestions. [04:01] ffThats before I saw persia's suggestion of a wizard. [04:01] frenchy: Thats before I saw persia's suggestion of a wizard. [04:01] Why does ubuntu push GNOME if it's so bad? [04:02] GTK rocks. It has accessibility, something which QT can't really bost about atm. [04:02] frenchy: I thought the tool would be quite different to what it is likely going to be. [04:02] TheMuso: Yes. And I can have a non digital clock ... sorry ... little dig. [04:03] TheMuso: So are you still "anti" UI? [04:03] TheMuso: GTK UI? [04:03] frenchy: No I am not. [04:04] well if you're anti-UI then how is someone supposed to use a computer? :P [04:04] TheMuso: It will be initially aimed at noobs. [04:04] UI = User Interface [04:04] LordKow: usually i'ts referring to GUI. [04:04] frenchy: Yeah I gathered. What language are you going to use? Python? [04:04] i know im just playing with technicalities :P [04:05] Probably not even though I admit that it might be a better option. I'm a C/C++ guy. [04:05] Fair enough. [04:07] hmm i would tackle this heimdal merge but im weary of doing merges that involves libs that I dont use. and even more this is a significant version jump, 0.7 to 1.0 [04:08] Ok, have to go and meet the outlaws, then I'll get started after that. I thank you all for you comments and look forward to helping you, help me. [04:13] bug 95240 if the changes recommended in this bug report are correct I will adjust the keytouch merge i will be working on to close this bug [04:13] Launchpad bug 95240 in keytouch "keytouch user level preferences are in administration instead of preferences menu" [Undecided,Confirmed] https://launchpad.net/bugs/95240 [04:13] items in Preferences are on a per user basis, while Administration entries are system-wide correct? [04:16] http://merges.ubuntu.com/k/keytouch/REPORT *sniffle [04:16] please let them be all changes i can drop [04:19] heh all those conflicts are simply times/dates yay === vorian is now known as vorian_afk [04:57] imbrandon, debdiff so that stacktraces can be useful. http://mirror.randumb.org/darkmagez/libvisual.debdiff [05:03] what can make executable 0755 on a .dpatch? [05:03] is this normal? [05:04] ember> yes [05:16] help_button = gtk_button_new_from_stock ("gtk-help"); <-- now how is that supposed to be a valid help entry for KeyTouch? [05:17] well i guess i dont know exactly how GTK UI works, has to be event driven though [05:20] i see, keytouch has no callback for help because there is no help yet the button is there... well its the difference between a sync and a merge i shall leave it [05:23] bug 173191 [05:23] Launchpad bug 173191 in keytouch "Please sync keytouch-2.3.2-1 (universe) from Debian sid (admin)" [Undecided,New] https://launchpad.net/bugs/173191 [05:42] ugh compiz still has some minor glitches with window borders, oh well [05:46] * Hobbsee grumbles about email [05:46] motu generates too much email :P [05:49] heh Hobbsee i think the lesson is dont put anything on the internet, even if its not in the announcement list, without it being considered "released" by people [05:49] :P [05:49] What now? [05:49] (with regard to the Alpha 1 comment on the forums) [05:49] LordKow: that's not really possible.... [05:50] i know :P [05:50] you could pw protect the page until its in the announcements if it matters that much [05:50] it would, of course, help if the forum mods actually understood about release stuff [05:50] and double checked with the release team before making official statements like that... [05:51] Hobbsee: It's forums. Understand is counter productive. [05:51] ScottK: yeah well. [05:52] ScottK: i made a comment in sevilla, near a whole bunch of other forums people, to the effect of "well, there's so much misinformation on the forums, any real stuff will probably be negated by all of that, so who cares?" [05:52] neeldess to say, i had to run rather quickly :P [05:52] I second the motion. Even when I was a brand new Ubuntu user who didn't know much of anything, I didn't do much with them. [05:53] i dont consider anything on the forums "official" unless its a sticky or an announcement [05:53] * StevenK has ignored the forums [05:55] and quite honestly i never even pay attention to releases except for switching my repositories over to the new development name (i always use development repos) [05:58] But this is worth a trip to the forums to read ... http://ubuntuforums.org/showpost.php?p=3869792&postcount=16 [06:06] ScottK: Not worth a trip for me. I want my ten seconds back. :-) [06:09] "never gave me no problem" [06:09] so it has always given this person problems? [06:09] heheh [06:17] wow, I am wondering how we have a 3 year old version of mt-daapd in our repos, when they just release 0.2? [06:18] 3 year old version == 0.9 [06:19]