[00:01] <Turl1> anyone?
[00:06] <calc> grr stupid delta codeshared flights can't do online checkin :\
[00:06] <calc> which means they are now going to weigh my carryon and ban it to checked baggage :\
[04:35] <Sarvatt> ‏
[04:55] <what_if> Is there currently any project to make a ubuntu install on an external HD "highly portable" between machines? ie, copying the PortableSUSE project ?
[04:56] <superm1> if you dont need nvidia or fglrx, installs should already be very portable
[04:59] <what_if> superm1: was thinking framebuffer...
[04:59] <what_if> superm1: opinions on that?
[04:59] <superm1> what_if, poor performance likely
[05:00] <superm1> but really if you just have a vanilla install onto an external hard drive, not much should stop you from moving it around.  you just wouldn't have whizz bang 3d effects on machines that would need -nvidia or -fglrx
[05:01] <persia> For such an environment, you might want to use usb-creator to create a persistent live environment.  That way you get HW detection, etc. cleanly.
[05:01] <persia> No reason that the "USB stick" can't be a 1TB drive, after all.
[05:02] <superm1> HW detection is a bit of a misnomer though too. xorg.conf generation used to be the biggest point there, but now that it's a common xorg.conf for different graphics installs, less of an issue
[05:03] <persia> superm1, Isn't there still libGL diversion though?
[05:03] <superm1> persia, that's why i'm saying to stay away from -nvidia and -fglrx
[05:03] <persia> Ah :)
[05:03] <superm1> no real way to keep a portable install that supports any of the 3 possible libGL's
[05:04] <what_if> superm1: I was going to go the framebuffer route simply to keep a static xorg.conf and simplify my life
[05:04] <superm1> what_if, take a look at a vanilla 9.04 xorg.conf. you don't need to
[05:04] <slangasek> hmm, I think it was kirkland who said he had such a thing, but blessing something that evil would be paradoxical :)
[05:04]  * what_if googles
[05:05] <superm1> slangasek, kirkland had a nice way to work with all 3 libGL's at once?
[05:05] <persia> slangasek, That was an internal hard drive that switched between two machines (but yes, it included some diversion-managing scripts)
[05:06] <superm1> well there is registering libGL.so.1 with alternatives, which i started to look at what was involved last year
[05:07] <superm1> it could potentially make for a nicer experience for bulletproof X, and letting bulletproof X's failsafe session change the alternative to try to get the X session started back up
[05:08] <calc> or just get noveau working and get rid of the two binary servers :)
[05:11] <what_if> so, from a feasibility standpoint, does everyone think this is viable? (minus 3D support)
[05:11] <persia> what_if, Minus 3D support, it's trivial,as long as you only try to support a single architecture.
[05:12] <what_if> persia: yes, would be X86 only
[05:12] <persia> Then, aside from 3D support, Wacom support, and a few other corner cases, every install is portable.
[05:21] <Sarvatt> ‏
[05:22] <what_if> brb, smoke break / reboot
[05:46] <Sarvatt> ‏
[05:48] <Sarvatt> ‏
[05:49] <Sarvatt> ‏
[05:49] <Sarvatt> ‏
[05:50] <ion_> !ops
[06:36] <dholbach> good morning
[06:37] <highvoltage> good morning dholbach
[06:37] <dholbach> hiya highvoltage
[07:02] <amitk> morning
[08:35] <hakkav> hi
[08:35] <hakkav> anyone used  Complete Fair Queueing in kernel development
[08:37] <ogra> hakkav, thast the default in ubuntu since a few releases already
[08:37] <hakkav> ah
[08:37] <hakkav> also do you guys use Broadcom b43 driver?
[08:38] <ogra> for item in "$(find /sys -name *scheduler*)";do cat $item;done
[08:38] <ogra> to find the currently used scheduler
[08:39] <hakkav> sweet thanks
[08:39] <hakkav> its been a few yrs
[08:39] <hakkav> btw is the L7 firewall still being licenced?
[08:40] <hakkav> ogra without the quotes right? " "?
[08:40] <hakkav> for i in $(find /sys -name *scheduler); do cat $i; done ?
[08:40] <ogra> no
[08:40] <ogra> just as it is there
[08:40] <soren> Um.. No?
[08:40] <soren> Oh, right.
[08:40] <ogra> soren, ??
[08:40] <soren> That happens to work :)
[08:40] <ogra> works here :)
[08:40] <ogra> i dont paste stuff i didnt check
[08:41] <LordKow> i think you are both wrong. should be for banana in $(find /sys -name *scheduler); do cat $banana; done
[08:41] <ogra> LordKow, damned you got me :P
[08:41] <LordKow> ;)
[08:41] <hakkav> it may go with " "
[08:41] <hakkav> no?
[08:41] <soren> It happens to work, yes.
[08:41] <hakkav> LordKow: thats what i did
[08:41] <hakkav> for i in $(find /sys -name *scheduler); do cat $i; done ?
[08:41] <ogra> both will work
[08:42] <hakkav> ah
[08:42] <soren> Putting ogra's quotes there render the for-loop rather useless, though.
[08:42] <soren> As it'll be treated as a single argument.
[08:42] <LordKow> yea then you just got yourself a string
[08:42] <ogra> yeah
[08:42] <ogra> indeed
[08:42] <hakkav> but im thiniing
[08:42] <hakkav> if one is working with files that have spaces
[08:43] <ogra> both wont :)
[08:43] <hakkav> like say blabla - blabla.info
[08:43] <hakkav> that must be enclosed into quotes
[08:43] <hakkav> no?
[08:43] <ogra> cat $(find /sys -name *scheduler*) works as well ...
[08:43] <\sh> hakkav: if you have those filenames, kick the guy who created them...
[08:43] <hakkav> for each item found in /sys where the name is scheduler, you must cat it
[08:43] <hakkav> right?
[08:43] <geofft> find /sys -name "*scheduler*" -print0 | xargs -n1 -0 cat
[08:43] <LordKow> hakkav: where the name includes scheduler
[08:44] <LordKow> (note wildcards)
[08:44] <hakkav> \sh why
[08:44] <hakkav> here I have /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/queue/scheduler
[08:45] <hakkav> LordKow: yeah i know
[08:45] <LordKow> if anyone has any thoughts on this matter feel free to type them: which is better (1) /usr/bin/env <interpreter> or (2) /usr/bin/<interpreter>
[08:45] <\sh> hakkav: because those filenames gave me problems in the past...when it all was "new" ;) and it's too MS...and typically managment like...
[08:45] <hakkav> ah
[08:45] <hakkav> but there';s no issues
[08:45] <ogra> it makes your disk wear a tie ?
[08:45] <geofft> LordKow: neither, /usr/bin/env LD_LIBRARY_PATH=/home/geofft <interpreter> :)
[08:46] <LordKow> hah :P
[08:46] <\sh> ogra: yes ;)
[08:46] <hakkav> LordKow: 1
[08:46] <LordKow> im just thinking of the person who puts python in his home directory, updates the path but wonders why a particular package keeps looking for non-existent python in /usr/bin ;)
[08:47] <ogra> i doubt its easily possible to have an ubuntu without python in /usr/bin
[08:47] <hakkav> dont you think 1 is better?
[08:47] <hakkav> you can define a new environment for the script you are running
[08:48] <LordKow> indeed ogra, but it is possible
[08:48] <bigon> could someone accept gst0.10-python in karmic?
[08:48] <ogra> (indeed it theoretically is possible, but surely requires a lot of fiddling)
[08:48] <hakkav> cant you just define a new env?
[08:48] <geofft> #!/usr/bin/env env python, so you can install your own version of env
[08:49] <LordKow> heh yea
[08:49] <ogra> LordKow, you dont need to update the path btw, just create ~/bin, put python in there and re-login
[08:49] <hakkav> is what i said
[08:49] <LordKow> ogra: oh true indeed, never crossed my mind.
[08:49] <ogra> ~/bin is automatically in your path if it exists
[08:49] <LordKow> but im pretending im john doe who does crazy things
[08:49] <ogra> poor john
[08:49] <hakkav> BUT
[08:49] <hakkav> it's not as safe as we wish, but for development and multiple versions, I find it useful ;-)
[08:50] <hakkav> not safe though
[08:50] <LordKow> exactly. and python is one where multiple versions is a very real possibility
[08:50] <ogra> as any other intrepreter ...
[08:50] <LordKow> alternatives *should* be taking care of those symlinks so /usr/bin/python should still work so long as alternatives are updated accordingly
[08:51] <hakkav> nothing that the user can modify is safe; if the library path points to rootkits kept by others... or so...
[08:51] <ogra> well, if you package the executable, you should make sure to use /usr/bin/python ... simply to make sure you use the python version the package was built against
[08:52] <ogra> else the world might break through incompatibilities
[08:52] <hakkav> LordKow: yeah
[08:52] <hakkav> or what i'd do is
[08:52] <hakkav> change the executable name according to the env.
[08:53] <hakkav> is that what ogra is saying?
[08:53] <hakkav> (i did it with php) though
[08:53] <hakkav> worked
[08:53] <ogra> if its for your own development and you want to use a newer python, use env ... and put the new python version into 7usr/local
[08:53] <ogra> or into ~
[08:53] <ogra> (with LD_LIBRARY_PATH set for ~/lib though)
[08:54] <LordKow> it's for packaging to the masses
[08:54] <ogra> then use the full path to the binary
[08:54] <hakkav> so change the exe name to the env
[08:54] <ogra> that way you make sure john doesnt break it
[08:55] <LordKow> yea
[08:55] <LordKow> john owes me
[08:55] <ogra> well, the packaging policy :)
[08:55] <ogra> i think its written donw there somewhere
[08:55] <hakkav> ogra
[08:55] <hakkav> the library path has to be the lib you want to use with python
[08:55] <hakkav> riht/
[08:55] <hakkav> right?
[08:55] <ogra> right
[08:56] <ogra> if you use ~ you might get into other weird issues though ... python will want ~/share too etc ... i would use /usr/local if i would want to use a different py version
[08:57] <hakkav> if you keep python in /usr/share/backgrounds/python/blah...
[08:57] <hakkav> LD_LIBRARY_PATH must be /usr/share/backgrounds/python/blah.../lib (or whatever you indicated when ./configureD ?
[08:57] <hakkav> ogra: the user's home?
[08:57] <hakkav> wouldnt the weird issues depend on the rest of the config and not just ~
[08:57] <hakkav> as i understand it some systems forbid to execute things in /home directories
[08:58] <hakkav> and i think relative paths are icky for anything
[08:58] <hakkav> ~ is a relative path
[08:59] <hakkav> so folks
[08:59] <persia> hakkav, ~ isn't relative to me $(echo ~)
[08:59] <hakkav> im sorry?
[09:00] <persia> ~ expands to an absolute path (by default)
[09:00] <hakkav> it's kinda alias?
[09:00] <hakkav> its like an alias?
[09:01] <hakkav> that absolute path changes
[09:01] <maco> i thought "relative path" always meant "relative [to the current directory] path"
[09:01] <hakkav> maco: relative to the user that is currently executing the script
[09:01] <hakkav> being careless
[09:01] <persia> maco, Can be relative to some operating directory as well.
[09:01] <maco> ~ doesn't change when you cd, only when you su
[09:01] <hakkav> from one user to another
[09:02] <hakkav> persia erm interesting point
[09:03] <ogra> everything is relative :P
[09:03] <persia> ogra, You win :)
[09:03] <ogra> not me ... just quoting freaks with weird haircuts here ;)
[09:04] <hakkav> easy i got a weird one
[09:27] <seb128> bigon: accepted
[09:34] <bigon> seb128: thx
[09:35] <seb128> you're welcome
[09:39] <bigon> seb128: could you also sync libchamplain and libchamplain-gtk which are in debian's incoming?
[09:40] <seb128> bigon: will sync when they reach the mirrors that's easier and there is no hurry
[09:40] <bigon> seb128: ok
[11:12] <vital> odd question mayhaps, but why boost-library 1.35 still, when 1.39 is available since beginning of month, and 1.38 since a tad bit longer?
[12:48] <slangasek> Riddell, ScottK: Debian has dropped boost1.35, and kde appears to still build-dep on it; is there a transition plan there for karmic?
[13:30] <ScottK> slangasek: We need to decide what the target is (and it's more than just KDE).   It'll be 1.37 or 1.38.
[13:30]  * slangasek nods
[13:31] <slangasek> boost-defaults seems to be pointing at 1.38, now
[13:31] <ScottK> Last I looked 1.38 was still FTBFS in Ubuntu.
[13:31] <slangasek> ah
[13:32] <ScottK> I'd prefer 1.38 since that's what Debian is aiming for for Squeeze, but I don't know of that's Karmic or Karmic +1.
[14:12] <iskywalker> hi!
[14:13] <iskywalker> i am developing a daemon, is there any guidelines? i need mysql already running is there any standard way for that, like gentoo require?
[14:15] <persia> iskywalker, Depends ought to do the latter.  For the former, mostly try not to be root, and avoid non-local sockets by default.
[14:18] <iskywalker> persia: i was hoping a book or so, i must create a user and run the daemon on that useraccount, like www-data
[14:20] <geofft> iskywalker: have you seen the Debian policy manual? It's worth at least skimming
[14:20] <iskywalker> it is huge also :)
[14:20] <persia> iskywalker, Hrm.  I don't know of one (but I'm not the best person to ask for book recommendations).  I suspect you'll find more success from a more general forum, rather than something so Ubuntu focused (as I expect your daemon ought work for any linux, if not any unix)
[14:21] <geofft> :) that's why you skim it and know where things are, and later read the sections that apply to you
[14:21] <iskywalker> persia: sure, but i would maintain an ubuntu not an general daemon...
[15:29] <Awsoonn> bryce: Bug 347569 http://ubuntu.pastebin.com/d58789f5b could I test this patch and if it works just post that to LP or would you prefer a debdiff?
[15:32] <Awsoonn> That was not ver gramatical of me... The question is would you prefer a .patch file or a debdiff? The .deb on this bug report made a significant differance in fps for me and I'd love to get this fix out to the greater good.
[15:32] <ion_> A debdiff ready to be uploaded is prefered.
[15:32] <Awsoonn> alright
[15:33] <ion_> You might want to follow the original code’s indentation and bracket style.
[15:35] <Awsoonn> I have a question though, how do you magical guys behind the curtian accully 'upload' to -updates? do you just upload teh debdiff and the build system applys it for you or do you need to apply is then submit the whole source deb to the build system?
[15:35] <ion_> The uploader will apply the debdiff to the extracted source package, build a new source package and upload that one.
[15:36] <Awsoonn> I see, so me doing that extra work making the debdiff really does make a differance then? :)
[16:32] <lesshaste> hi all
[16:58] <ScottK> If there's a buildd admin about I'd appreciate having qt4-x11 on armel and kdebase-workspace on ia64 and sparc rescored so I'll know in less than several days if I've fixed problems there.
[17:12] <Awsoonn> I decided to test radeon rewrite and would love to help out a bit if possible. Who should I ping?
[17:54] <henux> If I want to integrate my own app to the new notification system in Ubuntu 9.04, which library should I use?
[18:03] <ScottK> henux: #ayatana is probably a better channel for that question.
[18:07] <kirkland> superm1: slangasek: hmm, not sure if i know what you guys are talking about ... ?
[18:08] <kirkland> superm1: i have a little hack that generates a md5sum "signature" of my hardware configuration, and the associated xorg
[18:08] <kirkland> superm1: hardware configuration as shown by lshw
[18:09] <kirkland> superm1: i do this nasty thing when i travel ... i physically move my hard drive from my 14" thinpad to my 11" thinkpad, for portability purposes
[18:09] <kirkland> one of which has an nvidia card, and the other an intel card
[18:10] <kirkland> superm1: and I have an init script that computes my current hw config, and looks for a "signed" xorg.conf that works with it
[18:10] <Awsoonn> Bug #126774 would someone please check my statement and provide some guideance
[18:20] <superm1> kirkland, what do you do about libGL though?
[18:23] <kirkland> superm1: that's the sore point ... install/uninstall
[18:24] <superm1> kirkland, so there are two solutions that i've been pondering about with that kind of scenario
[18:24] <superm1> 1) alternatives system for libGL.so.1
[18:24] <superm1> 2) automatically try to use "nvidia" driver if it's available. there was a patch proposed for this a long time ago, but it didn't make it upstream
[18:25] <superm1> and doesn't work as it should currently
[19:24] <ebroder> Any dpkg wizards around? I'm having a hard time working out the interactions between python-xen-3.3 and xen-utils-3.3 on upgrades
[20:16] <calc> hmm i started using ext4 and now i see 4 new bugs fixed in ext4 for 30-rc6
[20:16]  * calc wonders if it was a good idea for him to switch to ext4 already
[20:24] <directhex> calc, "no". next question?
[20:28] <calc> directhex: heh
[20:28] <calc> directhex: i guess to late for me at least until after UDS
[21:01] <maxb> Would there perchance be any cdbs experts around? I'm looking at the current Ubuntu delta in the python-distutils cdbs class, and it looks wrong to me
[21:02] <ScottK> maxb: What specifically?
[21:05] <maxb> It replaces --root=$(cdbs_python_destdir) with --root=$(CURDIR)/debian/$(cdbs_curpkg) which seems a bit wrong, since the first is derived from potentially user-specified variables
[21:06] <ScottK> What is the default for cdbs_python_destdir?
[21:06] <james_w> maxb: bug 374892
[21:06] <james_w> that's why the change was made it appears
[21:07] <maxb> I see the bug, but I'm not really convinced that the fix is corretc
[21:08] <maxb> I'm trying to get mercurial to build with the newer cdbs - which I have, by way of a slightly dodgy hack, but this Ubuntu change has broken it
[21:10] <ScottK> So what would you recommend instead?
[21:12] <maxb> Well, the "obvious" solution would be to have fixed the disparity between the upstream rules and the added ubuntu-specific fragment by making the ubuntu-specific fragment conform
[21:12] <maxb> I'm just not sure if there are nonobvious problems with that
[21:24] <reece> greetings
[21:24] <reece> I am in the process of creating a front-end UI for espeak and other text-to-speech engines
[21:25] <reece> Is there anywhere that has guidelines / requirements for what a package needs to support
[21:26] <reece> in order for it to be included in Ubuntu?
[21:27] <persia> reece, How do you mean?  As in which engines, or something else?  The main requirement (aside from packaging details) is that it compile and work on the current development release.
[21:28] <reece> I mean things like being localised (which it isn't at the moment, but I am working on this)
[21:29] <reece> Ok, so you just need to provide the details on how to build the package then?
[21:38] <persia> reece, Being localised is better, of course :)  But yeah, just have a well-written INSTALL file that explains how to build and install, and make sure your licensing is all correct.
[21:39] <reece> ok, cool
[21:41] <reece> does the standard autotool INSTALL file count? I am using an autogen.sh script to generate the configure, et. al. files
[21:43] <Elbrus> Adam Conrad here?
[21:43]  * Elbrus doesn't know his nickname
[21:49] <Elbrus> infinity: ping
[21:50] <Elbrus> bugging about bug 2253
[21:50] <Elbrus> or actually bug 67544
[21:53] <persia> reece, As long as the file correctly describes how to do it, it doesn't matter if it's lovingly hand-crafted, or boilerplate.
[21:54] <reece> ok, thanks
[22:00]  * maxb determines that the cdbs change is in fact a regression bug, and starts to put together a bug report
[22:10] <maco> can someone explain something about uds?
[22:10] <seb128> if you don't ask probably not
[22:11] <mbana> hi, does anyone use xmonad?
[22:11] <seb128> mbana: hi, try #ubuntu
[22:11] <mbana> that won't help.   there's something with the package i believe
[22:12] <seb128> so the question you want to ask is not if somebody uses it
[22:12] <mbana> i've even tried the official xmonad channel, they don't seem to have a solution either.  i've been told it's packing issue or something wrong with gnome
[22:12] <seb128> what about asking your question directly?
[22:12] <mbana> because if no one responds, there's no point in me asking typing a long a detailed problem ;)?
[22:13] <Tm_T> mbana: perhaps someone reads log and give you the answer later?
[22:13] <seb128> and you expect people to reply if you don't ask the question?
[22:13] <Tm_T> those things happen (;
[22:13] <mbana> ok i'll ask on the ML.  which one would you guys recommend?
[22:13] <seb128> you could probably have described the bug in the same time you are asking those question and explaining why
[22:14] <seb128> what about opening a bug on launchpad?
[22:16] <maco> mbamford, i'm using xmonad
[22:16] <maco> bah
[22:16] <maco> mbana, ^
[22:17] <mbana> maco: hi there, would you prefer that i file a bug report?
[22:18] <maco> i think whomever packages it would prefer a bug report if its actually a bug
[22:18] <Tm_T> or even possible bug
[22:18] <maco> what's going on that you think's a bug or that you'd like to have reproduced?
[22:26] <mbana> maco: https://bugs.launchpad.net/ubuntu/+source/xmonad/+bug/378111
[22:27] <maco> which desktop environment are you using?
[22:27] <maco> it starts automatically in kubuntu just fine
[22:27] <maco> and i believe it starts automatically for dtchen in ubuntu
[22:27] <mbana> maco: gnome.  it was working perfectly in intrepid
[22:28] <maco> well i had it working in 9.04 w/ gnome then reinstalled and switched to kde and it starts automatically just fine in kde too. dtchen's using it in gnome and it starts automatically for him
[22:29] <maco> something changed in gnome so you have to set it up differently, but it does work
[22:29] <maco> i think there are directions on xmonad.org for how to make it work with current gnome
[22:29] <mbana> it's interesting to note that i used the jaunty instructions whilst on intrepid and it workedd, here's the link http://www.haskell.org/haskellwiki/Xmonad/Using_xmonad_in_Gnome#Ubuntu_Jaunty
[22:30] <maco> did you blast away .gconf?
[22:30] <mbana> hell no
[22:31] <maco> did you read the paragraph you linked that says intrepid's .gconf isn't compatible with jaunty?
[22:32] <mbana> i'm not using .gnomerc.  it seems rather odd that i have to clear out the entire .gconf
[22:32] <maco> ohok
[22:32] <maco> i didnt have to get rid of it...i think i just put the "killall metacity ; xmonad &" in the autostart thing
[22:32] <mbana> autostart thing?
[22:37] <geofft> does this apply to all window managers set in gconf, not just xmonad?
[22:38] <geofft> (that upgrading from Intrepid to Jaunty causes you to lose your WM?)
[22:42] <mbana> i can't confirm, i only use xmonad
[23:03] <maco> mbana, system -> preferences -> session -> autostart
[23:08] <mbana> maco: i'm afraid i don't have that.  do you mean startup applications?
[23:08] <maco> yes
[23:08] <maco> and i'm AFK now