[00:04] <jetole> hey guys, don't know if this is the right chan to ask but I will ask and you can let me know. I have to PC's each with a macintosh slim keyboard. The keyboard worked fine on both with 8.04. The one where I did a fresh install of 8.10 works fine however the one I did an upgrade to 8.10, the ctrl+alt keys don't seem to work
[00:04] <jetole> this 8.10 x86_64 on both and they are not mac computers. I just like the keyboard so I bought it for both PC
[00:06] <jetole> ctrl+alt was tested with virtual term (ctrl+alt+f1, f2, etc), X zap (ctrl+alt+backspace) and now with compiz cube rotate ctrl+alt+mouse
[00:07] <jetole> the xorg.conf shows the macintosh keyboard driver and the xev application shows Control_L, Alt_L, Control_R and Alt_R
[00:07] <jetole> any suggestions?
[01:37] <kolby> What is the normal way to get source and store code for an ubuntero?
[01:38] <kolby> this is a problem I have not solved.
[01:38] <kolby> is there a standard method?
[01:38] <kolby> I could use bazaar, apt-get, sourceforge, freshmeat... etc.
[01:40] <cjwatson> bazaar (either hosted on bazaar.launchpad.net, or a mirrored branch registered there) is about as standard as we've got
[01:40] <cjwatson> it is not universal
[01:41] <cjwatson> but it is integrated with launchpad for bug tracking and some other things already, and is likely to get more so
[01:41] <kolby> cjwatson, that bothers me...  the filesystem has many standards yet the development method is left to be foggy.
[01:42] <cjwatson> we're working on improving standardisation of this in Ubuntu by way of Bazaar
[01:42] <cjwatson> but you asked for the current state
[01:42] <kolby> cjwatson, thank you.
[01:42] <cjwatson> in any case, standardisation of the filesystem is much more important than standardisation of source control
[01:43] <cjwatson> and therefore it makes perfect sense that it was done first
[01:43] <kolby> I see
[01:43] <kolby> cjwatson, so... I have a directory called ~/Code that I use for storing my branches.  Is there a better way?
[01:43] <ebroder> kolby: Don't look for the Right And Only Way to do development - find what works for you
[01:44] <cjwatson> local names vary and the details are not important
[01:44] <cjwatson> I use ~/src but who cares what it's called
[01:44] <kolby> ebroder, Shouldn't there at least be a marked and titled "good way"
[01:44] <cjwatson> there are more important things
[01:44] <ebroder> kolby: For where you check out your source code? That's totally a personal preference thing
[01:45] <kolby> thank you both.
[01:45] <cjwatson> the layout of your local source code is likely to depend on the types of projects you contribute to
[01:45] <cjwatson> for example, I think of things largely in terms of distributions and so my local source code is organised in terms of the distribution source package names
[01:45] <cjwatson> somebody who spent more time maintaining upstream code would not think of things that way and it would make no sense to encourage them to do so
[01:46] <cjwatson> e.g. I would generally keep the upstream for an Ubuntu package foobar in ~/src/ubuntu/foobar/upstream/trunk/ or similar
[01:46] <cjwatson> but the upstream developer would find that bizarre and ~/src/foobar/trunk/ might be more natural
[01:47] <kolby> I want to contribute to Debian...  and learn how to build rpms... and possibly more exotic packages.  I'll do all that once I've mastered ubuntu packaging.
[01:47] <kolby> cjwatson, right.
[01:47] <cjwatson> I don't think it's particularly useful for us to spend time trying to standardise this; standardisation is valuable in terms of remote code access (e.g. bazaar.launchpad.net), but for local code layout it would be like fighting a blizzard uphill and wouldn't gain us anything
[01:48] <kolby> My discomfort originated by having a cluttered source code directory.
[01:48] <kolby> I would use "apt-get source" and get four similarly named package files that have different suffixes.
[01:48] <cjwatson> my trivial recommendation would be to organise it by source package
[01:49] <ebroder> Yeah, I agree
[01:49] <cjwatson> mkdir whatever; cd whatever before you apt-get source
[01:50] <kolby> cjwatson, that's what I've been doing.
[01:51] <kolby> I think enough people do this to the point where that should be what "apt-get source" does by default.
[01:51] <cjwatson> kolby: maybe if it had started that way, but at this point it would be a hideous pain to change it
[01:52]  * kolby grumbles
[01:52] <kolby> well... I'll fork.  lol.  jk
[01:52] <ebroder> Hmm...aptitude hasn't grown a source command yet, right? :)
[01:53] <kolby> ebroder, nice thinking.
[01:53] <cjwatson> I don't think fiddling about with your directory structure belongs in either apt-get or aptitude. It feels more like the sort of thing that something like wajig would like to do.
[01:53] <cjwatson> (not that I use wajig)
[01:53] <kolby> ebroder, I'll whine and complain until someone else does the work... ;)
[01:53] <kolby> (kidding)
[01:54]  * kolby googles wajig...
[01:54] <cjwatson> you could apt-cache show it instead
[01:54] <kolby> cjwatson, i see *nods*
[01:55] <cjwatson> (I have no information on whether it needs to be updated in some way to work with Ubuntu!)
[01:55] <kolby> hmm...
[01:56] <kolby> another problem I've had is finding functions in header files.  Stop;  Don't laugh at me.
[01:56] <cjwatson> but honestly, creating directories is hardly rocket science. People who download lots of files and then never do any file management have the same problem, and I don't think it's something the OS needs to solve in that case either.
[01:56] <cjwatson> ctags may be your friend
[01:56] <kolby> I want a utility to spit them out "ls" style
[01:56] <kolby> okay
[01:56] <kolby> alright.
[01:57]  * kolby wastes yet another precious irc line in agreement
[01:57] <cjwatson> also w3mman is rather good at browsing back and forth between manual pages and header files
[01:57] <kolby> ^^ that sounds cool.
[01:58] <cjwatson> and of course you have things like apropos since functions tend to match a pattern for each library
[01:58] <kolby> is it in the repository?
[01:58] <cjwatson> assuming the library ships manual pages
[01:58] <cjwatson> yes, w3m package. packages.ubuntu.com can answer this class of question
[01:59] <kolby> okay.
[01:59] <kolby> does it come preinstalled then?  I think Ubuntu ships with w3m
[02:00] <cjwatson> yes, w3m is in ubuntu-standard
[02:00] <cjwatson> though this has been controversial and might not remain the case forever (if I lose the argument)
[02:01] <kolby> I'm learning how to become more organized.  I'm going to make a tar.gz for all my preferences kept in dot-files.
[02:01] <cjwatson> check them into revision control instead
[02:01] <kolby> cjwatson, I see...
[02:01] <kolby> cjwatson, good plan...
[02:02] <kolby> since I've had so many questions answered today.  I may as well ask another.
[02:02] <kolby> would it be a good idea to have all my media files revision controlled?
[02:03] <cjwatson> I wouldn't; just back up anything you care about losing
[02:03] <ebroder> kolby: What's the point? They don't actually change - they're just big binary blobs
[02:04] <kolby> ebroder, maybe for playlists that change.
[02:04] <cjwatson> big binary files are not usually a case that revision control systems spend much time optimising for, so while it might work it would probably not be very comfortable
[02:04] <ebroder> kolby: Playlists would make sense
[02:04] <kolby> cjwatson, until I build the ultimate git extension...  nah... nvm
[02:05] <kolby> ebroder, alright.  *writes another line on todo list*
[02:05] <ebroder> kolby: I think git is currently the worst 4th gen DVCS for large binary files
[02:05] <kolby> ebroder, there are 4 gens?
[02:06] <ebroder> Err, of VCS, rather
[02:06] <kolby> CVS, SVN, git...  (well, bit-something-or-other if you want to count it)
[02:06] <ebroder> I think I count the RCS generation, the CVS generation, the SVN generation, and the DVCS generation
[02:06] <kolby> D for distributed.
[02:06] <ebroder> Right
[02:06] <ebroder> git, Bazaar, Mercurial...
[02:07] <cjwatson> DVCS is generally divided into arch-era and the modern stuff
[02:07] <kolby> is that really a next generation?  Maybe it's just a design choice.
[02:07] <cjwatson> where most of the modern stuff has a sensible UI except for git
[02:07] <ebroder> git, Bazaar, and Mercurial are definitely a generation after svn
[02:07] <kolby> alright.
[02:07] <kolby> I use bzr.
[02:07] <ebroder> Eh. git is very usable, once you get used to it
[02:07] <cjwatson> kolby: yes, it requires a significantly different underlying architecture
[02:08] <cjwatson> it's a UI you have to adapt to rather than the other way round. I'm not likely to be persuadable on this :)
[02:08] <kolby> cjwatson, this shoots down my idea for game-networking that leverages server-client and p2p traffic.
[02:08] <ebroder> cjwatson: Not here to get into a flamewar :)
[02:09]  * kolby secretly devises the ultimate opinion.
[02:09] <cjwatson> (I object to the apparently popular notion that git might be usable if only I spent time learning to love it. Actually I have spent time with it; my opinion hasn't changed in the slightest. Anyway.)
[02:11] <kolby> cjwatson, I retaliate to your completely reasonable conclusions with a very incite-full objection that brings you to question your existence as a whole.
[02:11] <kolby> ...soo... umm...  burn.  :)
[02:11] <kolby> well, I had fun with that.  Moving on.
[02:12] <ScottK-desktop> We just had a go 'round on this in Debian Python Modules Team and the conclusion was stick with svn for now.
[02:12] <kolby> If only there were a wikipedia article listing all the flame wars.  Gnome vs KDE vs fluxbox, etc... vs using a gui at all
[02:13] <ion_> Vim is better than Grub.
[02:13] <kolby> ion_, no firefox is better. ;)
[02:15] <kolby> is there a way to make a package for user's dot-files?  (ex.  .bash_aliases)
[02:16] <kolby> how _should_ I go about doing this if I wanted to?
[02:17] <kolby> I couldn't find anything on it in packaging articles.
[02:18] <RAOF> There isn't really.  You _could_ do something in a postinst maintainer script, but I'd be amazed if that was accepted into the archive.
[02:19] <kolby> RAOF, this is more for _very_ preference based things (I think the *!#@$* bike shed should be blue)
[02:19] <RAOF> kolby: Why aren't there system-wide configuration?
[02:21] <kolby> he meant "/etc/foobar-rc" stuff right?
[02:22] <Hobbsee> yes
[02:23] <terli> are there any gnome developers in here?
[02:25] <kolby> terli, I'm using gnome's libxml2.  Does that count?
[02:25] <terli> um
[02:26] <kolby> :) okay
[02:26] <terli> I need to know about gnome-shell/Clutter and if that is going to effect my future dreams of running killall gnome-panel.
[03:24] <shingen> can anyone help me out with an initramfs issue with dmraid not running before a call to /dev/mapper is made?
[03:26] <shingen> I'd like to modify the initramfs scripts to perform a dmraid -ay before it looks for the /dev/mapper assignment, and if possible, some assistance would be nice... or bumping me to the right channel would be helpful too, as #ubuntu helpers aren't quite at this level...
[03:29] <shingen> for some reason, the dmraid script in /scripts/local-top in the initramfs doesn't get run on time, so my fakeraid partitions aren't detected, thus halting the boot process... while in the initramfs busybox session, after running dmraid -ay on /dev/mapper shows my partitions just fine
[03:32] <ScottK> shingen: Is this a server or desktop install?
[03:33] <shingen> ScottK: desktop, used 8.10 64 bit alternate
[03:34] <ScottK> OK.  Well if it was a server you could ask in #ubuntu-server, but it's still a support question and not what this channel is for.
[03:34] <shingen> ok, I'll try ubuntu-server and tell a white lie, hopefully they're sharper in there :)
[03:35] <shingen> thanks
[05:22] <nhandler> emgent: pong
[09:53] <lool> Does someone happen to know why Ubuntu backports don't have NotAutomatic in their Release files?
[09:55] <persia> lool, Wouldn't that block upgrades within backports?  I know the backporters do security updates for some of the backports.
[09:56] <lool> persia: It would, but it would also prevent upgrades to all backported packages by default
[09:59] <persia> Hrm.  I thought there was another way to reduce the priority, but yes, I can see that.
[10:03] <lool> persia: In both cases, one needs to configure apt; if you fail to configure it in the current case, you get security supported packages but you might get new upstream versions at random times
[10:03] <lool> If however we would switch to NotAutomatic, then you might end up with a vulnerable package which isn't auto upgraded
[10:04] <lool> (if you didn't setup apt preferences correctly)
[10:04] <lool> There's a new package which landed recently and allows tracking packages from other repos IIRC
[10:04] <lool> Oh well /me goes configuring apt
[10:08] <persia> I think the long-term plan is to integrate with that new package, although I'm not sure.
[10:10] <lool> Well it could be an apt feature IMO; or we could setup apt preferences for backports before shipping
[10:10] <lool> (and dist upgrade them along sources.list)
[10:10]  * lool should probably discuss this with Michael
[10:10] <persia> That makes sense.  Perhaps it's just that not so many people pay much attention to backports.
[10:11] <lool> I had to use them for ... unison   :-/
[10:11] <persia> Or with jdong or ScottK or Mez or ...
[10:11]  * persia hides
[10:12] <lool> We inherit unison from Debian, and the versions in all stable releases were incompatible to each others; we're just fortunate that we have less versions across Ubuntu releases
[10:13] <lool> unison 2.9 in sarge, 2.13 in etch, 2.27 in lenny/sid...
[10:14] <persia> Well, unison is incompatible across most unison releases.  Part of the nature of how upstream does things.
[10:15] <lool> I think it's quite useful to be able to sync between say a desktop running intrepid and a server running hardy
[10:15] <persia> That we inherit from Debian is a good thing, although it hasn't always been that way, and between Breezy and Hardy, we had someone watching it.
[10:15] <persia> Actually, the decision to not upgrade unison for hardy was to support a number of users who wanted to be able to sync to older releases: maybe we chose the wrong way, but it seemed right at the time.
[10:16] <lool> What I wanted to point out is that Debian doesn't keep a source package per protocol version, that we inherit, and that is a problem in Debian in Ubuntu -- mind you would Debian have a source per protocol version in a Debian stable release we'd still have a problem in Ubuntu
[10:17] <lool> +and
[10:19] <persia> Well, I suppose we could do it that way, although I'm not terribly excited about it.
[10:20] <lool> It would obviously be easier if upstream would simply support a protocol forever or arrange to support multiple versions of the procol  :)
[10:21] <persia> Yes, but upstream is exceedingly unlikely to do that: it's a succession of research projects at a university, each release with a new author overseen by the principal investigator.
[10:22] <persia> I suppose it could be recommended, but it requires catching one of the researchers active, and convincing them to put more effort in than their advisor requires, which may be tricky.
[10:26] <lool> Yeah it didn't seem very likely to me upstream would change in this regard
[10:26]  * lool needs to riun
[10:26] <lool> *run
[10:26] <persia> Have fun :)
[10:32] <Baby> pitti: ping!
[11:02] <tjaalton> how come the adobe-flashplugin isn't built on amd64?
[11:04] <tjaalton> better ask adobe I guess..
[11:09] <gnomefreak> tjaalton: i thought adobe made a amd64 build
[11:09] <tjaalton> gnomefreak: yeah, but apparently it's still beta
[11:10] <gnomefreak> ah
[11:12] <tjaalton> the flashplugin-nonfree mess in hardy is pretty bad.. backports has the newest release, which in fact is an older, vulnerable one
[11:12] <tjaalton> ("newest" meaning the package version)
[11:15] <gnomefreak> tjaalton: we backported it way too soon we found out afterwards so name was changed to 10.X.X to 10.x.x-really9.X.X
[11:16] <tjaalton> gnomefreak: but it should be updated now to -really9.0.152.0..
[11:16] <tjaalton> since if you have backports enabled you have a broken flash
[11:16] <tjaalton> security wise
[11:17] <gnomefreak> now that 10 is final we should try it but testing 32 bit worked when i did it to begin with but 64bit failed most of time
[11:17] <tjaalton> best to just track -updates
[11:17] <gnomefreak> tjaalton: our script grabs *tar.gz and adobe names every new version the same name
[11:19] <gnomefreak> last i heard they havent changed it but i heard ubuntu packages were being worked on from adobe
[11:19] <gnomefreak> that might be a rumor
[11:20] <tjaalton> gnomefreak: so you're saying that if I reinstalled flashplugin-nonfree, it would pull the correct, current version?
[11:20] <tjaalton> gnomefreak: no, it's the adobe-flashplugin -package I asked about
[11:20] <gnomefreak> no we need to update md5sums to match new upstream tarball
[11:20] <tjaalton> ok, so I'll do it locally then
[11:20] <gnomefreak> thats most likely why its failing (without seeing errors
[11:21] <tjaalton> probably, but I'm talking about security issues ;)
[11:22] <tjaalton> lunch->
[11:48] <tjaalton> right, no flash9 available anymore
[14:16] <pitti> fta_: Miriam Ruiz contacted me, she also packaged it; we merged our packaging, and it's now standard debian/-only packaging branch with cdbs+quilt; I'm just uploading it to my PPA
[14:17] <pitti> Baby: pong
[14:17] <Baby> :)
[14:17] <pitti> Baby: oh, Miriam! nice nick :-)
[14:17] <Baby> thanks! :)
[14:17] <bardyr> wtf
[14:18] <sebner> hello to the Debian games lady :)
[14:18] <ScottK> lool: https://blueprints.launchpad.net/intrepid-backports/+spec/selective-backport-support is our attempt to address the problem
[14:18] <Baby> :)
[14:18] <Baby> hi sebner!
[14:18] <Baby> I'm having a look at those ttf replacements I wanna make in calibre :)
[14:19] <pitti> Baby: great
[14:19] <pitti> Baby: did you get along with the bzr stuff? anything major I missed in the packaging merging?
[14:20] <Baby> to be honest, I haven't downloaded it yet, I'm making local experiments :)
[14:20] <Baby> I added a logo to the Team though :)
[14:20] <pitti> yay logos
[14:20] <Baby> yup!
[14:21] <Baby> making software in fact is just an excuse for making logos ;)
[14:21] <pitti> I'll be online for another hour or so, so catch me if you need help with the bzr stuff
[14:21]  * pitti is utterly bad at graphics design
[14:22] <Baby> oki :) thanks!
[14:27] <Baby> anyway if I don't solve that ttf stuff soon, I'll upload it to NEW anyway with that quick replacement
[14:27] <pitti> Baby: you are trying to get rid of the "Pythonized ttf" stuff and just load the TTFs during runtime, as they are?
[14:27] <pitti> that would make most sense to me
[14:27] <Baby> yup
[14:28] <Baby> exactly that
[14:28] <pitti> the package would get smaller, and many people have those fonts already installed anywa
[14:28] <pitti> awesome
[14:28] <pitti> Baby: what kind of e-book reader do you have, BTW?
[14:28] <Baby> 505
[14:28] <Baby> :)
[14:28] <pitti> ok, so do I
[14:28] <pitti> Baby: then you'll enjoy working hal rules :)
[14:29] <Baby> there was someone in linuxchix asking for calibre for ubuntu for an older reader
[14:29] <Baby> so I might get feedback from her
[14:29] <pitti> the 500?
[14:31] <pitti> Baby: in the meantime, do you want me to work on an improved get-orig-source which throws out the TTFs and produces a cleaned orig.tar.gz?
[14:32] <Baby> yup, that is also needed
[14:32] <pitti> (we'll need that in either case)
[14:32]  * pitti starts fiddling
[14:32] <Baby> you can generate it by just making the suggested replacement by upstream
[14:32] <Baby> and then we patch it in the packaging
[14:33] <pitti> Baby: I think the orig.tar.gz should just have it thrown out
[14:33] <pitti> Baby: symlinking/copying should be done in debian/rules IMHO
[14:33] <pitti> no need to carry duplicate bits into the orig
[14:33] <Baby> I'd go for symlinking
[14:33] <Baby> hmm ok
[14:33] <Baby> I'd go for symlinking in orig anyway
[14:33] <pitti> roger
[14:35] <pitti> Baby: (I'm just thinking it's more flexible to do it in debian/rules, then we don't need new orig.tar.gzs when we change the patches/approach)
[14:35] <Baby> if we replace it with symlinks the orig can still stand for itself
[14:36] <pitti> back in 5
[14:36] <Baby> but it's OK any way for me :)
[14:41] <pitti> Baby: stand for itself> good point; let's do that then
[18:32] <barefoot> anyone know if/when python3-tk is gonna be created/released ?
[18:56] <lool> ScottK: Aha, thanks
[19:24] <slytherin> What is the username/password to be used for using email interface of requestsync?
[21:06] <rjune_> anybody know how I get a project out of the trash bin on source forge?
[22:02] <Uuu> Developers! Developers! Developers!
[22:03] <Uuu> Happy new year! :)