[01:32] <ikesire> is it true that gutsy won't include ntfs-3g?
[01:32] <ikesire> (by default)
[01:40] <calc> crimsun: you here?
[01:40] <calc> crimsun: got some alsa devel questions for you
[01:42] <calc> crimsun: eg what is NID in reference to patch_realtek.c
[01:45] <jdahlin> Why isn't a package's source code included in the -dbg deb?
[01:46] <calc> jdahlin: why would it be?
[01:46] <calc> jdahlin: you can easily get the source via apt-get source
[01:46] <jdahlin> calc, for tools such as gdb where the source code is useful
[01:46] <jdahlin> well, the complete source tree is not necessary only the .c files (and perhaps the .h)
[01:48] <minghua> jdahlin: but as calc said, it's easy to get the source with "apt-get source", .c, .h, everything.
[01:48] <jdahlin> I know that fedora has .debuginfo packages which provides the libraries/programs compiled with debugging symbols in addition to the source code
[01:48] <jdahlin> minghua, *I* am not interested in reading the source code, I programs that uses the debugging symbols to be able to read it
[01:48] <persia> jdahlin: A couple other reasons are 1) archive space, and 2) reduction of redundancy.  The -dbg package is useful for those generating stack traces.  The source is useful for those investigating the issue.  These are not always the same person, and the source must be distributed separately in any case.
[01:50] <minghua> I don't see the point.  The -dbg package should give you the function name and the filename and line number
[01:50] <jdahlin> persia, -dbg doesn't seem to be something the normal user installs, I can't quite why the source shouldn't be shipped together, it makes it easier for developers to use tools which depends on them (gdb, valgrind for instance)
[01:50] <minghua> that's all you need to identify the problem in the source, if you want to
[01:50] <jdahlin> minghua, right, but you're still missing the point. I do not want to track this down manually, I'd like tools to be able to use the references
[01:51] <minghua> jdahlin: it also duplicate the source several times (once for each architecture) and consume a lot of archive space
[01:51] <persia> jdahlin: Matter of preference I suppose.  I often don't need the -dbg or -dbgsym package when working on a stacktrace generated by someone else, and don't always try to fix stacktraces I generate.
[01:51] <jdahlin> the -dbg package for glib points to a path inside a buildd root, it's not very useful...
[01:51] <jdahlin> minghua, that could be solved by having a separate repository for debugging packages
[01:52] <minghua> honestly I don't see how that would help anything
[01:53] <jdahlin> minghua, I guess you don't use gdb a lot do you?
[01:53] <minghua> It's probably a little more convenient for those who do debugging, but the downside is not worth it
[01:53] <minghua> jdahlin: no I don't
[01:53] <ikesire> is it true that gutsy won't include ntfs-3g by default (on the install cd)?
[01:53] <jdahlin> persia, the -dbg packages are already quite heavy and contains redudant information, I can't see why it shouldn't contain all necessary information to make life easier for developers
[01:54] <minghua> jdahlin: what redundant information do the -dbg packages contain?
[01:54] <jdahlin> minghua, gdb is very painful to use without access to the sources, it's like walking blind folded, you can't really see what you're doing without the source code
[01:55] <jdahlin> minghua, a completely new binary!
[01:56] <Fujitsu> apt-get source somepackage
[01:56] <Fujitsu> Done.
[01:56] <persia> jdahlin: Aside from archive space, personal preferences, reduction of redundancy, and different (but overlapping) target audiences, I don't have any explanations.
[01:56] <minghua> jdahlin: I don't quite know about the -dbgsym packages for Ubuntu, but for Debian, the -dbg packages, if built correctly (with dh_strip, for example), don't contain completely new binaries, only the debug symbols
[01:56] <jdahlin> persia, I can't see who's the target audience for -dbg packages without source code included.
[01:56] <minghua> jdahlin: and I believe the -dbgsym packages are the same
[01:56] <persia> minghua: The Ubuntu -dbg and -dbgsym packages also follow that model.
[01:57] <minghua> persia: do ubuntu have different/separate -dbg packages?  I thought not.
[01:57] <Fujitsu> We keep most that Debian has, but -dbgsym makes them redundant.
[01:58] <persia> jdahlin: Those generating backtraces for bug reports.  These people may not be developers, but they may have just the right environment to generate a crash that cannot be replicated by a developer.  Also, the apport retracing service.
[01:59] <persia> minghua: Sometimes.  Generally the dbgsym packages are enough, but many packages (especially Debian imports) have -dbg packages defined as well.
[01:59] <calc> crimsun: ah NID == Node ID
[02:00] <jdahlin> persia, remember that source package is not the same as the source code as I am refering to
[02:00] <jdahlin> persia, the source code I'd like to have included is just all the source files which the debugging symbols refers to
[02:01] <jdahlin> persia, which in general is very small compared to the size of the complete source package
[02:05] <jdahlin> sorry, it's not that small I compared compressed vs uncompressed. it appears to be about the same size as the object files.
[02:09] <Fujitsu> Ouch.
[02:15] <LongPointyStick> why use a pointy end when you can use a person-projectile?
[02:16] <LongPointyStick> at least some of the time
[02:23] <Nafallo> grrr
[02:23] <Nafallo> something has put folders in my homedir!
[02:24] <persia> Nafallo: xdg-user-dirs
[02:25] <Nafallo> but... why?! :-)
[02:26] <LaserJock> my money is on "because it's fun" ;-)
[02:35] <Burgundavia> Nafallo: to make nice default locations for crap
[02:37] <Nafallo> Burgundavia: I already have those, and it's not the new folders :-P
[02:37] <Nafallo> they use big Capitals ffs ;-)
[04:28] <superm1> hi guys, I was wondering if anyone could speak to casper and the requirements for the hooks to properly work
[04:35] <sbalneav> Booyeah.  fixed nbd-server
[04:56] <calc> ScottK: hi :)
[04:56] <ScottK> Hello calc.
[05:06] <calc> ScottK: yea
[05:06] <calc> ScottK: just replied to it
[05:06] <ScottK> OK.
[05:08] <ScottK> calc: Sounds reasonable.  It's just a little odd for a community driven process when someone shows up and says (essentially, although very politely) I need to be annointed because of the job Canonical gave me.  
[05:10] <calc> ScottK: well i was hired for OOo but all of my other debian packages are in core as well
[05:10] <calc> though since i am in debian already i could probably manage to maintain them directly in debian such that they only need sync on ubuntu side
[05:10] <ScottK> Interested in fixing any KDE related bugs?
[05:11] <StevenK> ScottK: Oh no, get your hooks off him. :-P
[05:11] <ajmitch> hah
[05:11] <calc> heh
[05:11] <ajmitch> maybe he's ran away from KDE to preserve sanity?
[05:11] <calc> i haven't used KDE in several years, stuck with gnome in Ubuntu :)
[05:11] <ScottK> calc: Actually I think that's preferred (work in Debian) that way more people benifit.
[05:11] <calc> ajmitch: yes thats part of it ;)
[05:11] <ajmitch> calc: and yet you do OOo...
[05:11] <calc> ajmitch: hehe
[05:12] <calc> ajmitch: OOo can't be as insane as KDE, er right? ;)
[05:12] <calc> lmao
[05:12] <calc> ok so i'm not sane, but its fun anyway
[05:12] <ajmitch> that's probably why they hired you
[05:12] <ajmitch> sanity doesn't seem to be a common trait
[05:12] <calc> number one thing for me is to do work that benefits a lot of people and promotes oss
[05:13] <calc> the best way i saw to do that was to become the OOo guy :)
[05:13] <calc> i took over KDE when the previous debian guy got burned out on it and orphaned it at all at once
[05:14] <calc> while i had a full time job and full time school on top of that, heh
[05:14] <calc> so i think i am slowly becoming less insane
[05:16] <calc> my current pet bug is to fix the alc268 codec
[05:18] <Fujitsu> That really can't be pleasant :(
[05:20] <calc> superm1: my sound doesn't work :)
[05:21] <calc> so i am going to fix it myself
[05:23] <calc> learning enough about hda to actually understand whats going on takes a while though
[06:11] <calc> ok i think i have the beginnings of a clue about how this audio stuff works after reading this datasheet
[07:13] <calc> whee i understand this stuff now
[07:13] <calc> now the question is whether i can figure out what is wrong with the patch so i can fix it
[07:19] <jetscreamer> \o/
[08:59] <pygi> morning folks
[09:00] <Hobbsee> hiya
[09:51] <Fujitsu> Hi popey.
[09:51] <Fujitsu> Why do we deserve such hugs?
[09:52] <Hobbsee> hello popey 
[09:55] <pygi> Hobbsee, !!! :)
[09:55] <Hobbsee> hi pygi :)
[09:58] <pygi> Hobbsee, just looking over some other stuff ... mhm, most of the bugs are either fixable in 5 minutes, or closable already
[09:58] <Hobbsee> pygi: yay :)
[09:58] <pygi> Hobbsee, but nobody is working on those :(
[09:59] <Hobbsee> pygi: yell if/when you need a sponsor
[09:59] <pygi> looking at this right now: https://bugs.launchpad.net/ubuntu/+source/nautilus-cd-burner/
[09:59] <Hobbsee> are they coding bugs, or packaging bugs?
[09:59] <pygi> both
[09:59] <Hobbsee> right
[10:00] <pygi> Hobbsee, wanna work on that one? I have two hours, we might solve n-c-b as well today
[10:00] <pygi> (and yes, I know it's sunday :P)
[10:01] <Hobbsee> mind you...reading this blog i wont either...
[10:02] <Hobbsee> pygi: yeah, why not.  at least a bit.
[10:02] <pygi> Hobbsee, k, blue ones and grey ones are yours
[10:02] <Hobbsee> of n-c-b?
[10:03] <Hobbsee> and it was the colourless ones that were mine, yesterday
[10:03] <pygi> Hobbsee, yea, but grey is a color =)
[10:03] <Hobbsee> indeed :P
[10:03] <pygi> see? I learn :p
[10:03] <pygi> Hobbsee, we'll take some package of your choice after exams then :)
[10:03] <pygi> we could fix-up amarok or something ^_^
[10:04] <Hobbsee> cool
[10:04] <pygi> btw. blue are mostly trivial, it's a wishlist
[10:05] <Hobbsee> true
[10:05] <pygi> if there are some things we can easily implement, do poke about the bug number, and I'll see what can we do
[10:15] <pygi> Hobbsee, https://bugs.launchpad.net/ubuntu/+source/nautilus-cd-burner/+bug/49127
[10:15] <ubotu> Launchpad bug 49127 in nautilus-cd-burner "Long file names are truncated without warning" [Low,Confirmed]  
[10:15] <pygi> interesting bug ^_^
[10:16] <Hobbsee> pygi: indeed
[10:17] <pygi> Hobbsee, good that I know about that standard ^_^
[10:17] <Hobbsee> :)
[10:17] <pygi> finally something useful out of it :p
[10:23] <Hobbsee> pygi: did you need to do an upload of k3b from yesterday?  I found another patch
[10:23] <pygi> Hobbsee, patch for what? Point me ?
[10:23] <Hobbsee> pygi: https://bugs.launchpad.net/ubuntu/+source/k3b/+bug/109968
[10:23] <ubotu> Launchpad bug 109968 in k3b "K3b shows an inexact information if MP3 plugin not installed" [Wishlist,Confirmed]  
[10:23] <pygi> why didn't we saw that before?
[10:24] <Hobbsee> pygi: because i rejected it, adn didnt see the patch.  *shrugs*
[10:24] <pygi> Hobbsee, ah, we've got similar bug which is assigned on me
[10:24] <pygi> gimme a sec
[10:24] <Hobbsee> pygi: yeah, thoguht so.
[10:25] <pygi> Hobbsee, https://bugs.launchpad.net/ubuntu/gutsy/+source/k3b/+bug/121877
[10:25] <ubotu> Launchpad bug 121877 in k3b "K3b doesnt prompt the user to install kubuntu-restricted-extras for codecs" [High,Confirmed]  
[10:25] <Hobbsee> pygi: true that.  want me to mark as a dupe?
[10:25] <pygi> Hobbsee, yup
[10:26] <pygi> Hobbsee, and AFAIK that patch is useless for us
[10:26] <Hobbsee> done
[10:26] <pygi> thanks
[10:27] <pygi> Hobbsee, I'm done with mine n-c-b bugs
[10:27] <pygi> you?
[10:27] <Hobbsee> pygi: i was done a while ago - based on the fact that i don trun the software, so could only do packaging bugs
[10:27] <pygi> Hobbsee, hehe, oki :)
[10:27] <Hobbsee> sarah@liquified:~/current/k3b-1.0.1$ pl-feisty
[10:28] <pygi> it should afaik build
[10:28] <Hobbsee> oops
[10:28] <pygi> and I *want* it in feisty-updates :(
[10:28] <Hobbsee> is it a SRU candidate?
[10:28] <pygi> no idea :p
[10:28] <pygi> but if not, it should be
[10:28] <pygi> it fixes some important bugs
[10:28] <Hobbsee> if it's a new upstream version, then no, it isnt.  you'd have to cherry pick
[10:28] <Hobbsee> or at least, tha'ts hte usual case
[10:29] <Hobbsee> (see dapper xorg breakage for the reson why)
[10:29] <Hobbsee> !sru
[10:29] <ubotu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates for main and restricted, while https://wiki.ubuntu.com/MOTU/SRU is for universe and multiverse.
[10:29] <pygi> meh :P
[10:29] <pygi> I know what a SRU is, thank you :)
[10:29] <Hobbsee> way cool.  another LP bug.
[10:29] <Hobbsee> right
[10:29] <Hobbsee> this newest rollout has had a whole lot of new bugs.  brilliant.
[10:29] <pygi> hehe :)
[10:30] <pygi> Hobbsee, I've suggested workarounds on number of n-c-b bugs
[10:30] <Hobbsee> pygi: workarounds or fixes?
[10:30] <pygi> let's hope they work. If they do, we can just package it with the workaround probably
[10:30] <Hobbsee> jdong: recurring ping
[10:30] <pygi> Hobbsee, workarounds, by using cdrskin instead of wodim
[10:30] <Hobbsee> pygi: ah right
[10:30] <pygi> not sure if it'll work, but worth to try
[10:31] <Hobbsee> :)
[10:32] <pygi> Hobbsee, wake up =)
[10:32] <pygi> ergh
[10:32] <pygi> jdong, wake up :P
[10:32] <pygi> brasero and k3b backports awaiting you :)
[10:32] <pygi> Hobbsee, sorry ^^
[10:32] <Hobbsee> no problem
[10:33] <pygi> talking too much with you lately is bad :P
[10:34] <Hobbsee> haha
[10:34] <Hobbsee> i wish this exam tomorrow was actually on something interesting.
[10:36] <pygi> Hobbsee, what is it?
[10:36] <Hobbsee> pygi: it's electronics
[10:37] <Hobbsee> pygi: unfortunately, i had only very small amounts of interest in it when i *started* the subject this semester.
[10:37] <pygi> o yes, you told me about that
[10:37] <Hobbsee> then i just didnt understand it, went to spain, got so far behind, etc, that i definetly lost all interest in it.
[10:38] <pygi> hehe :)
[10:38] <pygi> meh, LP interface is messy :(
[10:38] <pygi> no idea how to add upstream tracking
[10:38] <pygi> o well
[10:39] <Hobbsee> pygi: the "upstream" section
[10:39] <Hobbsee> which bug?
[10:39] <realist> https://bugs.launchpad.net/ubuntu/+source/nautilus-cd-burner/+bug/49127 - could that be filesystem related?
[10:39] <ubotu> Launchpad bug 49127 in nautilus-cd-burner "Long file names are truncated without warning" [Low,Confirmed]  
[10:40] <pygi> realist, afaik it's mkisofs related =)
[10:40] <Hobbsee> pygi: you want Also affects:  +   Upstream
[10:40] <pygi> Hobbsee, I can't find neither kde or gnome on the list of upstream projects
[10:40] <pygi> meh
[10:40] <Hobbsee> pygi: gnome should be there
[10:40] <pygi> Hobbsee, I got that, but still :p
[10:40] <Hobbsee> which bug?
[10:40] <pygi> sec
[10:40] <Hobbsee> oh, the project is n-c-b
[10:41] <pygi> nah, it's brasero now
[10:41] <pygi> but still can't find anything useful
[10:41] <pygi> https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/120322
[10:41] <Hobbsee> does lp.net/brasero exist?
[10:41] <ubotu> Launchpad bug 120322 in brasero "Add functionality to make multiple copies of a disk" [Wishlist,Confirmed]  
[10:41] <pygi> needs watch on:
[10:41] <pygi> http://bugzilla.gnome.org/show_bug.cgi?id=447399
[10:41] <ubotu> Gnome bug 447399 in general "Add functionality to make multiple copies of a disk" [Enhancement,Resolved: duplicate]  
[10:41] <Hobbsee> pygi: instead of what's there already?
[10:42] <pygi> Hobbsee, yup, instead of the old upstream bug watch
[10:42] <Hobbsee> pygi: right.  click on the old bug watch, change it to GNOME Bug tracker, and add the new number
[10:42] <Hobbsee> it's there - scroll down a bit
[10:43] <pygi> Hobbsee, and yay for us, so much k3b bugs closed
[10:43] <Hobbsee> :D
[10:44] <pygi> yay, I fixed the upstream tracker!!!
[10:44] <pygi> :)
[10:44] <Hobbsee> woo!
[10:46] <pygi> realist, why do you think it's a FS problem?
[10:46] <pygi> well, truncating does need to happen indeed, but the bug has two problems:
[10:46] <pygi> a)mkisofs should have more intelligent truncating algorithms
[10:46] <pygi> b)n-c-b should provide a way for renaming
[10:47] <pygi> the ISO9660 does indeed impose length limit which can be extended with joliet/rockridge, but still .... 
[10:47] <realist> I was just assuming that certain filesystems would have a limit on path/filename lengths
[10:47] <pygi> two above problems still stand :)
[10:47] <pygi> read what I just said ^_^
[10:47] <Hobbsee> realist: so fix those filesystems :P
[10:48] <realist> Hobbsee: I'd rather not :-)
[10:48] <pygi> be good Hobbsee :P
[10:48] <mhb> Hobbsee: are you sure about bug 121877 ?
[10:48] <ubotu> Launchpad bug 121877 in k3b "K3b doesnt prompt the user to install kubuntu-restricted-extras for codecs" [High,Confirmed]  https://launchpad.net/bugs/121877
[10:48] <realist> pygi: so basically, the bug relates to handling potential truncation, before it actually happens, and giving sane options/alternatives?
[10:49] <pygi> realist, I've explained the problem a bit in my latest comment, but mostly ... yes
[10:49] <mhb> Hobbsee: what I think is that the user should not *get* any unsupported software he does not request.
[10:49] <Hobbsee> mhb: what about it?
[10:49] <pygi> Hobbsee, will do :)
[10:50] <realist> Reading the bug comments now.
[10:50] <mhb> Hobbsee: and k-r-e is not just k3b encoding/decoding, right?
[10:50] <Hobbsee> good pygi.  you'll save me from killing the stupid people
[10:50] <Hobbsee> mhb: this is correct.
[10:50] <Hobbsee> mhb: i'm going off the easy-codec-installation and common-customisations spec
[10:51] <Hobbsee> pygi: maybe a thing to say "this will install the most commonly used stuff, if you wish to only install components, please install x,y,z manually"
[10:51] <pygi> Hobbsee, meh, useless
[10:51] <pygi> IMHO ofcourse
[10:51] <Hobbsee> pygi: well, yeah.  but it is possible that they may only want certain codecs.
[10:52] <Hobbsee> i'd have to check the two specs for it
[10:52] <pygi> Hobbsee, do check, and report to me :)
[10:52] <Hobbsee> as i never saw what the outcome was fro gnome
[10:52] <pygi> Tell me what "manual stuff" we want mentioned there then
[10:53] <Hobbsee> liblame0 and libk3b-mp3*whateveritis, iirc
[10:53] <pygi> Hobbsee, just mention it there pls :P
[10:53] <Hobbsee> ok
[10:53] <pygi> I can''t track everything in my head =
[10:53] <pygi> =)
[10:54] <Hobbsee> :P
[10:54] <Hobbsee> why not?
[10:55] <mhb> Hobbsee: to be honest, I don't believe in pop-ups at first-startup-time
[10:55] <Hobbsee> mhb: was that what the spec specified?
[10:55] <pygi> mhb, this isn't popup at first-startup-time ?
[10:55] <Hobbsee> mhb: i would assume it's for the first time a codec-required app is started.
[10:55] <pygi> it's just a change in the dialog that k3b regulary shows
[10:55] <mhb> pygi: at first-startup-time
[10:56] <pygi> ok, I don't get you :P
[10:56] <pygi> we aren't introducing any new dialogs at startup time :)
[10:56] <pygi> (when it's first ran :P)
[10:56] <mhb> Hobbsee: I might be wrong, but Ubuntu apps I ran offered to install the codecs only if I played any non-free media
[10:56] <pygi> ok, now I'm seriously confused
[10:57] <pygi> someone fill me in on what we're talking about
[10:57] <Hobbsee> mhb: this isnt the restricted manager here
[10:57] <mhb> no, it isn't
[10:57] <mhb> Hobbsee: restricted-manager is also something completely different
[10:57] <Hobbsee> exactly
[10:58] <mhb> Hobbsee: why aren't we discussing this in #kubuntu-devel?
[10:58] <realist> What's the best way of approaching upstream authors, about providing bug/security patches that you've written?
[10:58] <realist> Just a straight-forward email, with the patch?
[10:59] <pygi> realist, mailing them politely with a patch, with GPG encrypted message? :)
[10:59] <pygi> if it's a security patch ^_^
[10:59] <Hobbsee> mhb: because pygi is here, and we've had various burning related discussions here in the past few days.
[10:59] <realist> encrypted? is signing enough?
[10:59] <Hobbsee> mhb: and it's quiet
[10:59] <pygi> Hobbsee, I'm there as well if you really want to do it in #k-d
[10:59] <Hobbsee> realist: usually.  i dont bother encrypting, for the most part
[10:59] <Hobbsee> pygi: makes no difference to me.  go for it
[11:00] <pygi> Hobbsee, same to me :P
[11:00] <pygi> everyone is quiet anyway =)
[11:00] <realist> Okay, so just say, upstream author rejects patch, is it still okay to apply our own patches for ubuntu packages?
[11:01] <realist> Or is it preferred for package to be inline with upstream source?
[11:01] <pygi> realist, it is ok to apply own patches, depending on the patch
[11:01] <ajmitch> ~/win 28
[11:01] <pygi> ajmitch, ? ^_^
[11:02] <ajmitch> that's ok
[11:02] <realist> So I guess it's our job to make sure that our patch doesn't conflict with any changes subsequently made to upstream sources?
[11:02] <pygi> realist, we can just drop the patch later on
[11:05] <realist> Okay, next silly question. It's okay to be both debian _and_ ubuntu developer?
[11:06] <pygi> ofcourse
[11:07] <realist> Good, because I was having a difficult time deciding where to direct my efforts :-)
[11:07] <pygi> hehe :)
[11:07] <realist> Now, if only I can pick up an orphaned package that exists in _both_ distros
[11:07] <realist> Is there an easy way to find such packages in ubuntu?
[11:08] <realist> i.e. no maintainer?
[11:08] <pygi> realist, in ubuntu we don't have maintainers
[11:09] <Hobbsee> although there are plenty of packages which arent being kept up to date in ubuntu
[11:09] <pygi> or properly maintained (i.e. no patching to make sure everything works, and stuff)
[11:09] <realist> pygi: that's a concept I can't understand
[11:10] <pygi> realist, there's MOTU which maintain universe and multiverse packages, and core devs which maintain Main and Restricted
[11:10] <realist> So the MOTU don't look after _specific_ packages?
[11:11] <pygi> nop
[11:11] <realist> They just contribute where ever, and when ever they want?
[11:11] <pygi> not exactly like that, but ...
[11:11] <pygi> there's ofcourse coordination, talks, decisions, arguments, and stuff
[11:11] <Hobbsee> realist: basically
[11:11] <Hobbsee> realist: often people work in teams - or have sets of packages taht they touch
[11:11] <realist> Chaos theory!
[11:11] <Hobbsee> realist: but anyone can touch anything, yes
[11:12] <Hobbsee> realist: not really.  it works reasonably well.
[11:12] <realist> I can see how that'd work actually
[11:12] <realist> So people just start these 'teams' on launchpad?
[11:12] <Hobbsee> realist: i mean, there's social protocol that says "if a person has done the last few uploads of this, i should ask them first before i touch it"
[11:12] <Hobbsee> realist: a lot goes on in #ubuntu-motu, via email, whatever
[11:12] <realist> And focus on certain sets of bugs/requests, etc?
[11:13] <Hobbsee> well, for kde, for eg, we tend to have a group of people who works with debian kde extra team, who keeps control of all the kde packages in ubuntu
[11:13] <realist> Hobbsee: but it's not written in stone
[11:13] <Hobbsee> realist: not currently
[11:13] <realist> This will take me some getting used to :-)
[11:13] <Hobbsee> realist: i mean, people go inactive
[11:14] <Hobbsee> and if there's no response, then feel free to go and change it
[11:14] <realist> Is there official protocol for those cases?
[11:14] <realist> Like, no response within X days/weeks, etc?
[11:14] <pygi> realist, not really
[11:14] <Hobbsee> and most people will say "feel free to patch this", or in some cases "dont bother to merge this, i've looked at it already, and it's broken"
[11:14] <pygi> we just know when and how to handle it
[11:14] <realist> Just wondering where the ownership, or accountability is
[11:14] <Hobbsee> realist: nope.  it's really just a free-for-all.
[11:15] <Hobbsee> realist: the MOTU team takes responsibility of them, really.
[11:15] <realist> Perhaps I've been in a commercial environment too long already ;p
[11:15] <Hobbsee> realist: it's not main, whihc is commercially supported
[11:15] <realist> This "free-for-all" I could get used to
[11:15] <pygi> Hobbsee, it mostly works really good
[11:15] <StevenK> realist: Loosely organised choas. It's fun.
[11:15] <Hobbsee> realist: but even that - there are teams of people who do variosu bits
[11:15] <realist> More eyes and hands on the code, has to be a "good thing" right?
[11:16] <Hobbsee> exactly
[11:16] <realist> So how are arguments/debates resolved?
[11:16] <ion_> With guns.
[11:16] <Hobbsee> ion_: *grin*
[11:16] <Fujitsu> ion_ is correct.
[11:16] <Hobbsee> realist: cant say there have been many, actually.  very few.
[11:16] <Hobbsee> realist: ther'es one on what to do about clamav stuff
[11:16] <Fujitsu> There are too few of us to have debates.
[11:16] <realist> What if someone disagrees with changes I've made?
[11:17] <Hobbsee> realist: but the people get on reasonably well - you've seen the COC, i presume, which everyone is under?
[11:17] <Hobbsee> realist: then they'll politely tell you, usually with reasons about why it's incorrect
[11:17] <realist> I've already _signed_ the CoC
[11:17] <realist> Is there avenues for arbitration?
[11:17] <pygi> realist, everything can be agreed on, and there are policies on sane and insane stuff :p
[11:17] <Hobbsee> realist: right.  i was merely pointing to it, and saying taht that stops a lot of flames, etc
[11:17] <pygi> mostly unwritten, but they do exist
[11:17] <Hobbsee> realist: motu mailing list is a good start - if it really escalates, there's the community council or tech board.  
[11:17] <realist> Mmmm it's the "unwritten laws" I'm uncomfortable with
[11:18] <realist> Hobbsee: that sounds sensible
[11:18] <Hobbsee> (which is written, in the procedures of ubuntu)
[11:18] <realist> I should probably get on that mailing list
[11:18] <realist> Any others I should be interested in?
[11:18] <Hobbsee> ubuntu-devel, maybe ubuntu-devel-discuss too
[11:19] <Hobbsee> ubuntu-devel-announce and ubuntu-announce are low traffic, and are useful
[11:19] <realist> I'm already on security-announce, is there a place for security related discussion?
[11:19] <Hobbsee> realist: ask keescook 
[11:19] <Hobbsee> when he's here
[11:19] <realist> I'm actually more interested in security related fixes, than anything else
[11:20] <pygi> realist, nice :)
[11:20] <Hobbsee> realist: he's the security guy.  i beleive there is stuff, but i dont remember exactly what, offhand
[11:20] <Hobbsee> realist: have you come from debian, or what?
[11:20] <realist> I vaguely remember a security-discuss, but I think it's dead
[11:20] <realist> I've been using debian for, umm 10+ years
[11:20] <Hobbsee> i meant a developer of it
[11:20] <realist> But never an 'official developer'
[11:20] <Hobbsee> right
[11:21] <realist> It's about time I started giving back
[11:21] <Hobbsee> realist: you'll find there's a collaborative attitude here, rather than an "it's my package, and if you touch it, then i'm going to come and hunt you down", as is often (it seems, from an outsiders POV) the case in debian.
[11:21] <realist> Also a fan of OpenBSD
[11:22] <realist> Hobbsee: there's just more organisational structure in debian, relating to single packages
[11:22] <Hobbsee> realist: indeed.
[11:22] <realist> Although, nothing stopping anyone else from contributing code to that particular developer
[11:22] <Hobbsee> realist: which is why i've never gotten involved particularly much in debian.
[11:22] <Hobbsee> true - they just can reject it, and be a right pain
[11:23] <realist> Having said that though, I could see the benifit in a 'free-for-all' approach
[11:23] <realist> Hobbsee: indeed
[11:23] <Hobbsee> hiya mvo 
[11:23] <realist> Although, if your suggestion/contribution is good enough, they could accept it
[11:23] <mvo> hey Hobbsee
[11:24] <realist> So, in order to upload, you need to be either MOTU, or core dev?
[11:24] <Hobbsee> realist: this is true.  i've submitted a couple of packages back to debian.
[11:24] <realist> But for now, what can I do to contribute?
[11:24] <Hobbsee> realist: technically, yes.  there are sponsorship processes, though
[11:24] <realist> Submit packaged work to existing MOTU?
[11:24] <Hobbsee> realist: check https://wiki.ubuntu.com/MOTU
[11:25] <Hobbsee> hmmm.  persia's guide isnt in there yet, for sponsorship
[11:25] <realist> Hobbsee: a more useful link, would be a list of willing mentors/sponsors :-)
[11:25] <Hobbsee> realist: https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue is the info about the sponsorship queue
[11:25] <realist> Woot!
[11:26] <realist> Thanks :-)
[11:26] <Hobbsee> realist: this is true - but there arent a lot of mentors around.  and the current lot of mentorees seem to go "i want a mentor, to tell me what to do, in everything"
[11:26] <pygi> realist, if you need anything, just ask
[11:26] <Hobbsee> which is...less than useful.  you'll do better if you've already got something that you'd like to work on - either a package or an area
[11:26] <pygi> we're always willing to help :)
[11:28] <realist> I guess it's time for me to debootstrap a chroot dev environment now :-)
[11:28] <realist> Get some actual _work_ done
[11:28] <pygi> realist, pbuilder might work good as well =)
[11:29] <Hobbsee> realist: or use a pbuilder
[11:29] <Hobbsee> realist: dual booting, etc, is often a good way to test
[11:33] <mhb> hi mvo 
[11:34] <mvo> hey mhb, thanks for your mail
[11:34] <Hobbsee> mhb: pygi mvo can probably provide input about the restricted stuff - or maybe not during a sunday
[11:35] <pygi> Hobbsee, let's not do it today, and let's keep it simple :)
[11:36] <mhb> mvo: check the code once you have time. If you could manage to look at it so we could upload a package in time for Tribe 2, that would be awesome.
[11:36] <Hobbsee> depends what mvo wants.
[11:36] <Hobbsee> if he can keep his connectoin for long enough
[11:37] <ajmitch> hey mvo/mvo_ :)
[11:38] <Hobbsee> case in point.
[11:39] <mvo__> mhb: I will answer to your mail, network is way too unstable again here (but I was promised that it get fixed on monday, yay!)
[11:39] <ajmitch> Hobbsee: maybe he's just having a multiple personality day?
[11:39] <Hobbsee> mvo__: hooray!
[11:39] <Hobbsee> ajmitch: heh, perhaps.  but this happens most days :P
[11:40] <mvo_____________> ...
[11:40] <ajmitch> hah
[11:41] <Hobbsee> haha
[11:41] <Hobbsee> poor mvo
[11:44] <TheMuso> c
[11:44] <mhb> mvo: uh oh, that sounds like you hated the code :o)
[11:44] <TheMuso> ugh
[11:45] <Hobbsee> TheMuso: you really do love the "c" key, dont you...
[11:46] <TheMuso> Hobbsee: You know what the reason is for that.
[11:46] <TheMuso> I nedant mention it again.
[11:47] <Hobbsee> TheMuso: i used to.  unfortunately, exams have killed my brain or something.
[11:47] <Hobbsee> i've forgotten :(
[11:47] <TheMuso> Hobbsee: Speakup + kvm
[11:47] <Hobbsee> TheMuso: ahhh.  right
[11:48] <Hobbsee> TheMuso: i figured it was likely something to do with speakup
[11:52] <realist> what's "speakup"?
[11:52] <realist> Oh cool :-)
[11:59] <TheMuso> realist: At this point of time, I would call it a piece of crap code that does its best to screw your system if its loaded.
[12:04] <Enola_Gay> hi all
[12:09] <Enola_Gay> I think that support is very important for Linux/Ubuntu. Since many people are behind routers/firewalls it isn't so easy to help them with vnc. People who need support doesn't often know how to open ports. Another group are people behind a firewall which can't be changed by them. For all them it would be great to have GUI for connection to listen vnc. People who give support know how to forward ports so it makes much more 
[12:09] <Enola_Gay> sense to let supported connect to vnc listen clients. This also makes things more secure since they don't need to open ports. Should I make a feature request or are there several reasons why this isn't already implemented?
[12:12] <Enola_Gay> And please don't forget to fix the vnc compiz bug until Gutsy release. Otherwise vnc support isn't possible anymore.
[12:23] <Hobbsee> Enola_Gay: --> ubuntu-devel-discuss mailing list, please
[12:23] <Hobbsee> !weekend
[12:23] <ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
[12:23] <Enola_Gay> thx
[12:23] <Hobbsee> no problem
[12:24] <Enola_Gay> I post it to launchpad so if someone is interested ...
[12:25] <realist> Enola_Gay: To be honest, I'm not entirely sure what you're proposing.
[12:25] <Enola_Gay> realist: Atm it is only possible to connect to someones computer to help him with vnc
[12:25] <Enola_Gay> So there have to be a port forwarded
[12:25] <Enola_Gay> But vnc has an option listen so the clients wait for connections and the remote desktop connects to the client
[12:26] <realist> Ahhh I see.
[12:26] <Enola_Gay> So everyone who needs support behind a firewall doesn't need to forward anything just insert the ip and connect to the support who of course is able to forward ports.
[12:26] <Enola_Gay> Much more easier.
[12:26] <Enola_Gay> But without a gui it isn't so easy.
[12:28] <realist> Might actually be easier for someone providing the support, to instruct someone to use the CLI, than a GUI
[12:29] <realist> I know this is the case for me, since I can remember CLI better, as opposed to GUI navigation
[12:30] <realist> You could even post the CLI instructions, where the support client could copy/paste
[12:30] <realist> That'd be my workaround, but your suggestion is still a good one, so definately post to the mailing list
[12:31] <Enola_Gay> this is true but many people who needs support doesn't like the console :)
[12:34] <Enola_Gay> Do you know svnc? This is a great program for windows. It consists a little vnc server and all information needed to connect to the supporter. So if someone needs support you send him this file and he needs nothing more than just start it. It even supports encryption.
[12:42] <Enola_Gay> And it is open source :)
[12:45] <Enola_Gay> Ok, I have made the feature request. By the way the program is called scvnc. Thanks for your support. Cu
[12:45] <popey> they dont need to use the console, you can do ALT+F2 and type the command in the box
[12:45] <Enola_Gay> popey: :)
[12:46] <Enola_Gay> But I have to send them per Mail. Most of the old ones don't use im
[12:46] <Enola_Gay> And it would be very hard through a telephone
[12:49] <Enola_Gay> This is needed to convince them from Linux imho since they need much support at first. The great thing is that they didn't play 3D games and most of the time only surf, write or print something but if they have i.e. a Canon printer it would be a problem too.
[12:54] <Enola_Gay> Btw does anyone know if Java would be OpenSOurce in Gutsy and main?
[12:55] <pygi> Enola_Gay, no
[12:55] <Enola_Gay> Because it isn't ready?
[12:56] <pygi> it isn't open source
[12:56] <pygi> not completely
[12:57] <Enola_Gay> ok
[12:57] <Enola_Gay> thanks
[12:57] <Enola_Gay> cu
[01:37] <StevenK> pitti: Hi!
[01:38] <pitti> hello
[01:38] <pitti> Hi StevenK 
[01:44] <StevenK> pitti: Is archive-cruft-checker still busted?
[01:44] <pitti> StevenK: yes, I doubt that someone fixed it over the weekend
[01:45] <StevenK> It's becoming a little hard to juggle state about it in my head.
[01:45] <tsmithe> are there any archive admins able to look at http://revu.tauware.de/revu1-incoming/ubuntustudio-sounds-0706231730/ubuntustudio-sounds-0.5/debian/copyright (the debian/copyright file for ubuntustudio-sounds), and tell me if it is acceptable?
[01:49] <Hobbsee> hi pitti!
[01:51] <pygi> pitti, hey ho
[02:06] <pitti> StevenK: are you interested in a particular package? I can generate the rdepends per-package manually
[02:07] <pitti> StevenK: bah, I just regenerate them all
[02:07] <Hobbsee> pitti: he's watchign tv
[02:13] <pitti> StevenK: all updated
[02:13] <pitti> siretart, gpocentek: can I poke you again about the ffmpeg / libgoffice transition?
[02:16] <StevenK> pitti: Thanks!
[02:16] <pitti> StevenK: http://people.ubuntu.com/~pitti/scripts/checkrdepends, BTW
[02:17] <pitti> StevenK: that's the scripts which generates the output per package (source, or binary with -b)
[02:18] <StevenK> pitti: I'm a bit loath to just blindly rebuild the packages for ppc and ia64 for jasper without checking, but I am without ppc and ia64.
[02:18] <pitti> StevenK: no big problem; at worst it doesn't work and we need to build them again; no big deal
[02:19] <StevenK> pitti: Well, I'm happy to do so if you like.
[02:19] <pitti> StevenK: great, thank you
[02:24] <StevenK> Ugh. Some of the sources are huge.
[02:25] <StevenK> pitti: Your script seems to write out empty files, too.
[02:25] <StevenK> pitti: libtotem-plparser1 is zero size
[02:25] <pitti> StevenK: yeah, I didn't remove packages without rdepends
[02:27] <StevenK> checking whether system headers can cope with -O2 -fno-inline... irrelevant
[03:53] <davmor2> Hi Devs  Ubiquity and deb-installer are both failing on iso's for the 24/06/07.  Ubiquity gets a bugreport but it is empty.  deb-installer fails on debchroot ?  I think it is called.
[03:55] <Hobbsee> davmor2: ok.  not sure if the candidate cds are being spun and such yet - main's not frozen yet
[03:57] <davmor2> I know but it definitely is something that needs to be worked on.  That's my reason for highlighting it.
[03:59] <Hobbsee> thanks :)
[04:00] <davmor2> well what else is the isotesting team here for ;)
[04:00] <Hobbsee> davmor2: i doubt all the stuff is in, if main's not frozen - which is when the real tribe 2 candidates testing will start.  so hang around for a couple of days, and please test again :)
[04:00] <Hobbsee> main freezes on tuesday, then they'll spin iso's and whatnot from there
[04:05] <davmor2> Hobbsee:  Yes my main testing is on tuesday evening/ Wednesday.  but I was having bother with updating nm-applet and it not working well with gnome-keyring-manager.  So I was hoping that an update cd would solve the issue.  It's works fine on live I just can't install :(
[04:06] <Hobbsee> ahhh
[04:06] <davmor2> but it has at least highlighted the issue with the installer
[04:07] <Hobbsee> true
[04:07] <davmor2> bye for now
[04:30] <afflux> TheMuso: Hobbsee sent me to you because of bug 121937. Someone requests a way to let blind people decide in what language the live-cd should boot up.
[04:30] <ubotu> Launchpad bug 121937 in Ubuntu "live-cd should ask for the language country (and maybe keyboard)" [Undecided,New]  https://launchpad.net/bugs/121937
[04:31] <Hobbsee> afflux: he's asleep
[04:31] <afflux> uh.
[04:31] <afflux> I tend to forget that it's 16 o'clock only in central europe ;)
[04:31] <Hobbsee> lol
[04:41] <pygi> ogra, ! :)
[04:41] <pygi> afflux, 4:40 to be precise =)
[04:41] <ogra> hey
[04:41] <ogra> 42 here :P
[04:41] <pygi> ok, ok, germany is always special :p
[04:41] <ogra> indeed
[04:42] <afflux> now 42 in germany :D
[04:42] <afflux> (it's the answer!)
[04:42] <ogra> yeah
[04:42] <pygi> how are you doing?
[04:42] <ogra> playing with hal ...
[04:42] <ogra> http://people.ubuntu.com/~ogra/ltspfs-hal-root.png
[04:42] <pygi> uh, that must be interesting
[04:42] <pygi> it always is :)
[04:43] <ion_> 17:41:36 < pygi> afflux, 4:40 to be precise =)  17:41:44 < ogra> 42 here :P
[04:43] <ogra> hehe
[04:43] <pygi> ion_, but, but ...
[04:43] <pygi> you're *wrong*
[04:43] <ion_> My ntpd should be working, unless it has became b0rked.
[05:12] <sim2> who knows why /var/run and /var/lock are excempted from umounting in /etc/init.d/umountfs
[05:14] <ion_> They are mounted as tmpfs.
[05:14] <sim2> no they are specifically filtered based on their name
[05:17] <sim2> but why, it keeps my /var mounted during shutdown
[05:58] <Kmos> keescook: are you there?
[08:43] <silvertip257> good day everyone
[08:43] <silvertip257> I doubt I'm in the right place, but I'd like to learn how to put together a live cd
[08:46] <mc44> silvertip257: https://help.ubuntu.com/community/LiveCDCustomization ?
[08:46] <silvertip257> mc44:  I tried that, but to no avail ... i'm lookin into making one from the foundation up
[08:47] <pygi> silvertip257, try reconstructor
[08:47] <silvertip257> hmm ok pygi
[08:48] <silvertip257> thank you ... I will check that out .. bye
[09:42] <imachine> Hi
[09:42] <imachine> would this be the place devs sit about ?
[09:43] <pygi> imachine, what ya need?
[09:43] <imachine> pygi: dude, I need to know what patches apply against vanilla on ubuntu kernel
[09:43] <imachine> talking about standard normal amd64 kernel that gets installed, 7.04
[09:44] <pygi> ah
[09:44] <pygi> you could apt-get source the kernel package, and get the source
[09:44] <imachine> I'd like to use them maybe on the distro I use currently, but I don't know what they are. I need I guess acpi-asus patches.
[09:44] <imachine> yeah, but I use archlinux ;)
[09:44] <imachine> so no apt-get about ;] 
[09:44] <pygi> ah
[09:44] <imachine> pygi: wouldn't that provide me with the ready sources anyway, and not vanilla + patches lying about in some patches/ dir ?
[09:45] <pygi> ubuntu holds it's own kernel tree
[09:45] <imachine> cuz I could always download them just from some ubuntu mirror manually, whatever files apt-get source would provide me with.
[09:45] <pygi> I'm really not the right kernel person you should talk to :)
[09:45] <imachine> well, don't you guys patch the vanilla stuff? I think you have to one way or the other no ?
[09:46] <crimsun> of course.  Its public via kernel.ubuntu.com/git/
[09:46] <pygi> ofcourse that patching happens
[09:46] <crimsun> It's, even.
[09:46] <pygi> but don't ask me :P
[09:46] <pygi> there, crimsun :)
[09:46] <imachine> oic.
[09:46] <imachine> ta
[09:47] <imachine> well. ultimately, I'd just like a directory I could get to ? and see stuff in there?
[09:47] <imachine> uh I'm feeling dumbified, if that's even a word.
[09:47] <imachine> this whole ubuntu business, sorry guys I mean no offence, but it's on f..... mess for me.
[09:47] <imachine> I could never dev for you ;P
[09:47] <imachine> respect for finding your way about.
[09:48] <bhale> it isnt so hard if you have the tools and the will to learn them
[09:49] <imachine> well it's not hard. it just seems overly complicated for no reason.
[09:49] <crimsun> you need the git-core package or its equivalent on arch
[09:49] <imachine> feels like you guys have levels of awareness ;)
[09:49] <crimsun> then just clone the appropriate tree
[09:49] <imachine> crimsun: well I guess I can use git yeah
[09:50] <imachine> crimsun: and what will git pull in? will it pull in what I want, that is, vanilla + patches aside ?
[09:50] <imachine> I'm used to a PKGBUILD + patches and stuff in the PKGBUILD mentioning them.
[09:50] <crimsun> I recommend you read the documentation on using git.
[09:50] <imachine> bsd style Makefile. emerge files.
[09:50] <imachine> whatever like that.
[09:50] <crimsun> cloning a git tree pulls the entire tree
[09:51] <imachine> yeah that's okay. just what will I get there.
[09:51] <imachine> i.e. , what does your git tree contain.
[09:51] <crimsun> the entire Linux tree
[09:51] <imachine> does it contain what I need, that is, vanilla + patches ?
[09:51] <crimsun> are you even looking at kernel.ubuntu.com/git/ ?
[09:51] <imachine> do you even have patches aside ?
[09:51] <imachine> or you just dev and submit.
[09:51] <crimsun> patches are in git changesets.  There is no separate patch repository.
[09:51] <crimsun> Seriously, read the git documentation.
[09:52] <imachine> well you don't understand what I'm saying I guess. because I understand patches to git, and to certain next/before versions of the tree. that's one thing.
[09:52] <imachine> but what I'm talking about is Ubuntu patches to the vanilla kernel.
[09:52] <imachine> that's what I ultimately need.
[09:53] <imachine> i just need the ubuntu patches, nothing more. the stuff that makes ubuntu kernel an ubuntu kernel.
[09:53] <imachine> like I said somewhere else, I *could* just get your kernel through git like you said, and diff the files I want against a clean vanilla kernel
[09:53] <imachine> that way I'd get patches.
[09:53] <crimsun> then execute a recursive unified diff over the source and the origin.
[09:53] <imachine> but that's overhead I think.
[09:53] <imachine> yeah, so no other way then I reckon ?
[09:54] <superm1> crimsun, do you have a copy of that script that you use for collecting alsa related info?  I have a friend who is having troubles with gutsy and alsa, so I was going to have him run that and file a bug
[09:54] <imachine> crimsun: have you got no build files? or would those build files use the already patched kernel sources.
[09:55] <crimsun> superm1: linked from my LP profile.
[09:55] <superm1> thx crimsun 
[09:56] <crimsun> imachine: "build files"?
[09:56] <imachine> yeah.
[09:56] <imachine> I mean, how do you build your packages?
[09:56] <crimsun> see debian/rules
[09:56] <imachine> not interested.
[09:56] <imachine> anyway.
[09:56] <crimsun> um, you asked how they're built, and that's what you would need to see...
[09:57] <imachine> a build file is a file which contains information as to how a package is supposed to be built.
[09:57] <crimsun> that's precisely debian/rules
[09:57] <imachine> well, that was sort of a rhethorical question I guess.
[09:57] <imachine> I see, I thought that was some disclaimer ;)
[09:57] <imachine> sorry.
[09:58] <imachine> ok.
[09:59] <imachine> crimsun: so normally, I'd expect a line somewhere in this rules file that orders the build process to patch. since it would normally fetch vanilla sources, and patch them locally. that's how I'm used to doing stuff at least.
[10:00] <imachine> but in your case I take it sources are fetched already patched, even worse, there's a source package for that matter which includes the rules.
[10:00] <crimsun> imachine: the entire git tree is, using standard terminology, "patched"
[10:00] <imachine> this is like those dogs with fur over their eyes, you can't say whether they're barking with their arse. at least for me that's how I see it ;)
[10:00] <superm1> crimsun, are there any known bugs in that script?  It is hanging for both my friend and I when trying to run it following the directions listed on linux-sound.info
[10:00] <crimsun> superm1: how is it being invoked?
[10:00] <superm1> bash alsa-info.sh
[10:01] <imachine> crimsun: where could I see those patches? or do you just dev this stuff in such a fasion, that there simply isn't some general place one could get patches ?
[10:01] <crimsun> superm1: pastebin.ca may have high latency depending on his source
[10:01] <imachine> yeah I guess I'll just git your tree
[10:01] <imachine> and diff locally.
[10:01] <crimsun> superm1: have him use --no-upload and --debug, then pastebin the file generated in /tmp
[10:01] <imachine> this is more work than I thought.
[10:01] <superm1> K
[10:01] <crimsun> imachine: it's precisely how all git trees that clone from Linus operate
[10:01] <crimsun> see www.kernel.org/git/
[10:01] <pygi> imachine, just because ubuntu != arch doesn't mean that it's bad
[10:02] <imachine> pygi: I never said that.
[10:02] <pygi> not directly
[10:02] <imachine> arch is what I like not because it's called 'arch' but because it keeps to the KISS way.
[10:02] <crimsun> whatever floats your boat.
[10:02] <imachine> as, in the end, your ways of doing things is probably not far different in consequences, it's mostly a matter of preference.
[10:03] <imachine> if you can get the same end funcionality, more-less, with a more simplistic apporach however, in my opinion that's better. hence I use arch. and not only because of that, actually I never knew how your development goes on until today ;)
[10:03] <imachine> so yeah, use whatever you like.
[10:03] <imachine> anyway I have to look through the files. I think it shouldn't be a lot of work anyway ;)
[10:04] <imachine> crimsun: thanks for the info so far lad.
[10:04] <pygi> imachine, let's not discuss arch and it's development :)
[10:04] <pygi> I know much more about it then you think ^^_
[10:04] <pygi> ^_^
[10:05] <imachine> pygi: you're right, let's not.
[10:05] <imachine> also, I didn't mention how things are done basing on human factor, rather than on how the ways things could be done on it.
[10:06] <imachine> I'm sure there is plenty of rreasons to not choose arch or whatever other distro. But luckily for that, there is other possibilities.
[10:06] <pygi> yes
[10:09] <imachine> ok, tas lads. that's helpful info. have a good one I might drop by sometime if noone minds ;] 
[10:09] <imachine> laters.
[10:32] <draik> To everyone who worked on Feisty...
[10:32] <draik> THANK YOU!
[10:32] <draik> My laptop works much cleaner and smoother than with Edgy. No complaints about Edgy, mind you. I'm just saying Edgy was great, but Feisty is Excellent!
[10:32] <draik> Thank you all
[10:44] <alex_mayorg1> Hello all, any dev can have a look at bug# 121111
[10:45] <alex_mayorg1> please
[10:46] <ScottK> alex_mayorga: There aren't likely to be many around on a Sunday afternoon/evening.
[10:46] <ScottK> Bug #121111
[10:46] <ubotu> Launchpad bug 121111 in linux-source-2.6.22 "Gutsy Tribe 1 CD don't load on Dell Inspiron 1501" [Medium,Confirmed]  https://launchpad.net/bugs/121111
[10:46] <alex_mayorga> ScottK, fair enough
[10:47] <alex_mayorga> I do most of my Ubunting on the weekends though
[10:47] <ScottK> alex_mayorga: There is also a separate #ubuntu-kernel channel that might work better for you (at a better time).
[10:50] <alex_mayorga> ScottK, I'll give it a try, thanks
[10:54] <alex_mayorga> Is there a plan to do an Ubuntu like http://www.puppyos.com/flash-puppy.htm
[11:15] <Toxicity999> alex_mayorga That's sort of a novelty project, I've seen individuals do it with great success though.
[11:33] <superm1> alex_mayorga, an ordinary ubuntu install can be installed onto a flash drive or usb hard drive and bootable
[11:34] <superm1> the only problem is that different systems will refer to it is hd0 or hd1 or hd2 depending on what other things are plugged in
[11:34] <Mithrandir> it'll usually be hd0 if you boot off it.
[11:34] <superm1> and depending on what the bios is currently set as the primary drive to boot from
[11:35] <superm1> Mithrandir, my intel mobo installs grub onto the usb drive thinking its hd1, but really its hd0 unless i change the boot order in the bios
[11:35] <superm1> in which case its a bit difficult to boot from :)
[11:44] <Nafallo> hmm
[11:44] <Nafallo> my home on lvm are named dm-0 :-P
[11:44] <Nafallo> confusing :-)
[11:45] <Nafallo> /dev/dm-0 that is
[12:00] <Daviey> Hi, I have a USB module that i'm trying to write drivers for.  It is a hub & two devices.  It seems it's poorly implemented and it has a broken port 3.  Can i stop the kernel trying to enable the port?
[12:01] <Daviey> getting repeated; "hub 4-8:1.0: Cannot enable port 3.  Maybe the USB cable is bad?"