[00:04] 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] 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] 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] the xorg.conf shows the macintosh keyboard driver and the xev application shows Control_L, Alt_L, Control_R and Alt_R [00:07] any suggestions? [01:37] What is the normal way to get source and store code for an ubuntero? [01:38] this is a problem I have not solved. [01:38] is there a standard method? [01:38] I could use bazaar, apt-get, sourceforge, freshmeat... etc. [01:40] bazaar (either hosted on bazaar.launchpad.net, or a mirrored branch registered there) is about as standard as we've got [01:40] it is not universal [01:41] but it is integrated with launchpad for bug tracking and some other things already, and is likely to get more so [01:41] cjwatson, that bothers me... the filesystem has many standards yet the development method is left to be foggy. [01:42] we're working on improving standardisation of this in Ubuntu by way of Bazaar [01:42] but you asked for the current state [01:42] cjwatson, thank you. [01:42] in any case, standardisation of the filesystem is much more important than standardisation of source control [01:43] and therefore it makes perfect sense that it was done first [01:43] I see [01:43] cjwatson, so... I have a directory called ~/Code that I use for storing my branches. Is there a better way? [01:43] kolby: Don't look for the Right And Only Way to do development - find what works for you [01:44] local names vary and the details are not important [01:44] I use ~/src but who cares what it's called [01:44] ebroder, Shouldn't there at least be a marked and titled "good way" [01:44] there are more important things [01:44] kolby: For where you check out your source code? That's totally a personal preference thing [01:45] thank you both. [01:45] the layout of your local source code is likely to depend on the types of projects you contribute to [01:45] 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] 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] e.g. I would generally keep the upstream for an Ubuntu package foobar in ~/src/ubuntu/foobar/upstream/trunk/ or similar [01:46] but the upstream developer would find that bizarre and ~/src/foobar/trunk/ might be more natural [01:47] 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] cjwatson, right. [01:47] 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] My discomfort originated by having a cluttered source code directory. [01:48] I would use "apt-get source" and get four similarly named package files that have different suffixes. [01:48] my trivial recommendation would be to organise it by source package [01:49] Yeah, I agree [01:49] mkdir whatever; cd whatever before you apt-get source [01:50] cjwatson, that's what I've been doing. [01:51] I think enough people do this to the point where that should be what "apt-get source" does by default. [01:51] 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] well... I'll fork. lol. jk [01:52] Hmm...aptitude hasn't grown a source command yet, right? :) [01:53] ebroder, nice thinking. [01:53] 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] (not that I use wajig) [01:53] ebroder, I'll whine and complain until someone else does the work... ;) [01:53] (kidding) [01:54] * kolby googles wajig... [01:54] you could apt-cache show it instead [01:54] cjwatson, i see *nods* [01:55] (I have no information on whether it needs to be updated in some way to work with Ubuntu!) [01:55] hmm... [01:56] another problem I've had is finding functions in header files. Stop; Don't laugh at me. [01:56] 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] ctags may be your friend [01:56] I want a utility to spit them out "ls" style [01:56] okay [01:56] alright. [01:57] * kolby wastes yet another precious irc line in agreement [01:57] also w3mman is rather good at browsing back and forth between manual pages and header files [01:57] ^^ that sounds cool. [01:58] and of course you have things like apropos since functions tend to match a pattern for each library [01:58] is it in the repository? [01:58] assuming the library ships manual pages [01:58] yes, w3m package. packages.ubuntu.com can answer this class of question [01:59] okay. [01:59] does it come preinstalled then? I think Ubuntu ships with w3m [02:00] yes, w3m is in ubuntu-standard [02:00] though this has been controversial and might not remain the case forever (if I lose the argument) [02:01] 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] check them into revision control instead [02:01] cjwatson, I see... [02:01] cjwatson, good plan... [02:02] since I've had so many questions answered today. I may as well ask another. [02:02] would it be a good idea to have all my media files revision controlled? [02:03] I wouldn't; just back up anything you care about losing [02:03] kolby: What's the point? They don't actually change - they're just big binary blobs [02:04] ebroder, maybe for playlists that change. [02:04] 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] kolby: Playlists would make sense [02:04] cjwatson, until I build the ultimate git extension... nah... nvm [02:05] ebroder, alright. *writes another line on todo list* [02:05] kolby: I think git is currently the worst 4th gen DVCS for large binary files [02:05] ebroder, there are 4 gens? [02:06] Err, of VCS, rather [02:06] CVS, SVN, git... (well, bit-something-or-other if you want to count it) [02:06] I think I count the RCS generation, the CVS generation, the SVN generation, and the DVCS generation [02:06] D for distributed. [02:06] Right [02:06] git, Bazaar, Mercurial... [02:07] DVCS is generally divided into arch-era and the modern stuff [02:07] is that really a next generation? Maybe it's just a design choice. [02:07] where most of the modern stuff has a sensible UI except for git [02:07] git, Bazaar, and Mercurial are definitely a generation after svn [02:07] alright. [02:07] I use bzr. [02:07] Eh. git is very usable, once you get used to it [02:07] kolby: yes, it requires a significantly different underlying architecture [02:08] 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] cjwatson, this shoots down my idea for game-networking that leverages server-client and p2p traffic. [02:08] cjwatson: Not here to get into a flamewar :) [02:09] * kolby secretly devises the ultimate opinion. [02:09] (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] 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] ...soo... umm... burn. :) [02:11] well, I had fun with that. Moving on. === ScottK3 is now known as ScottK-desktop [02:12] We just had a go 'round on this in Debian Python Modules Team and the conclusion was stick with svn for now. [02:12] 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] Vim is better than Grub. [02:13] ion_, no firefox is better. ;) [02:15] is there a way to make a package for user's dot-files? (ex. .bash_aliases) [02:16] how _should_ I go about doing this if I wanted to? [02:17] I couldn't find anything on it in packaging articles. [02:18] 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] RAOF, this is more for _very_ preference based things (I think the *!#@$* bike shed should be blue) [02:19] kolby: Why aren't there system-wide configuration? [02:21] he meant "/etc/foobar-rc" stuff right? [02:22] yes [02:23] are there any gnome developers in here? [02:25] terli, I'm using gnome's libxml2. Does that count? [02:25] um [02:26] :) okay [02:26] 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] can anyone help me out with an initramfs issue with dmraid not running before a call to /dev/mapper is made? [03:26] 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] 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] shingen: Is this a server or desktop install? [03:33] ScottK: desktop, used 8.10 64 bit alternate [03:34] 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] ok, I'll try ubuntu-server and tell a white lie, hopefully they're sharper in there :) [03:35] thanks [05:22] emgent: pong === jcastro_ is now known as jcastro === Tweenaks is now known as Treenaks [09:53] Does someone happen to know why Ubuntu backports don't have NotAutomatic in their Release files? [09:55] lool, Wouldn't that block upgrades within backports? I know the backporters do security updates for some of the backports. [09:56] persia: It would, but it would also prevent upgrades to all backported packages by default [09:59] Hrm. I thought there was another way to reduce the priority, but yes, I can see that. [10:03] 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] If however we would switch to NotAutomatic, then you might end up with a vulnerable package which isn't auto upgraded [10:04] (if you didn't setup apt preferences correctly) [10:04] There's a new package which landed recently and allows tracking packages from other repos IIRC [10:04] Oh well /me goes configuring apt [10:08] I think the long-term plan is to integrate with that new package, although I'm not sure. [10:10] Well it could be an apt feature IMO; or we could setup apt preferences for backports before shipping [10:10] (and dist upgrade them along sources.list) [10:10] * lool should probably discuss this with Michael [10:10] That makes sense. Perhaps it's just that not so many people pay much attention to backports. [10:11] I had to use them for ... unison :-/ [10:11] Or with jdong or ScottK or Mez or ... [10:11] * persia hides [10:12] 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] unison 2.9 in sarge, 2.13 in etch, 2.27 in lenny/sid... [10:14] Well, unison is incompatible across most unison releases. Part of the nature of how upstream does things. [10:15] I think it's quite useful to be able to sync between say a desktop running intrepid and a server running hardy [10:15] 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] 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] 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] +and [10:19] Well, I suppose we could do it that way, although I'm not terribly excited about it. [10:20] It would obviously be easier if upstream would simply support a protocol forever or arrange to support multiple versions of the procol :) [10:21] 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] 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] Yeah it didn't seem very likely to me upstream would change in this regard [10:26] * lool needs to riun [10:26] *run [10:26] Have fun :) [10:32] pitti: ping! === thunderstruck is now known as gnomefreak === jussio1 is now known as jussi01 [11:02] how come the adobe-flashplugin isn't built on amd64? [11:04] better ask adobe I guess.. [11:09] tjaalton: i thought adobe made a amd64 build [11:09] gnomefreak: yeah, but apparently it's still beta [11:10] ah [11:12] the flashplugin-nonfree mess in hardy is pretty bad.. backports has the newest release, which in fact is an older, vulnerable one [11:12] ("newest" meaning the package version) [11:15] 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] gnomefreak: but it should be updated now to -really9.0.152.0.. [11:16] since if you have backports enabled you have a broken flash [11:16] security wise [11:17] 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] best to just track -updates [11:17] tjaalton: our script grabs *tar.gz and adobe names every new version the same name [11:19] last i heard they havent changed it but i heard ubuntu packages were being worked on from adobe === asac_ is now known as asac [11:19] that might be a rumor [11:20] gnomefreak: so you're saying that if I reinstalled flashplugin-nonfree, it would pull the correct, current version? [11:20] gnomefreak: no, it's the adobe-flashplugin -package I asked about [11:20] no we need to update md5sums to match new upstream tarball [11:20] ok, so I'll do it locally then [11:20] thats most likely why its failing (without seeing errors [11:21] probably, but I'm talking about security issues ;) [11:22] lunch-> === lfalavi is now known as DktrKranz [11:48] right, no flash9 available anymore [14:16] 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] Baby: pong [14:17] :) [14:17] Baby: oh, Miriam! nice nick :-) [14:17] thanks! :) [14:17] wtf [14:18] hello to the Debian games lady :) [14:18] lool: https://blueprints.launchpad.net/intrepid-backports/+spec/selective-backport-support is our attempt to address the problem [14:18] :) [14:18] hi sebner! [14:18] I'm having a look at those ttf replacements I wanna make in calibre :) [14:19] Baby: great [14:19] Baby: did you get along with the bzr stuff? anything major I missed in the packaging merging? [14:20] to be honest, I haven't downloaded it yet, I'm making local experiments :) [14:20] I added a logo to the Team though :) [14:20] yay logos [14:20] yup! [14:21] making software in fact is just an excuse for making logos ;) [14:21] 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] oki :) thanks! [14:27] anyway if I don't solve that ttf stuff soon, I'll upload it to NEW anyway with that quick replacement [14:27] Baby: you are trying to get rid of the "Pythonized ttf" stuff and just load the TTFs during runtime, as they are? [14:27] that would make most sense to me [14:27] yup [14:28] exactly that [14:28] the package would get smaller, and many people have those fonts already installed anywa [14:28] awesome [14:28] Baby: what kind of e-book reader do you have, BTW? [14:28] 505 [14:28] :) [14:28] ok, so do I [14:28] Baby: then you'll enjoy working hal rules :) [14:29] there was someone in linuxchix asking for calibre for ubuntu for an older reader [14:29] so I might get feedback from her [14:29] the 500? [14:31] 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] yup, that is also needed [14:32] (we'll need that in either case) [14:32] * pitti starts fiddling [14:32] you can generate it by just making the suggested replacement by upstream [14:32] and then we patch it in the packaging [14:33] Baby: I think the orig.tar.gz should just have it thrown out [14:33] Baby: symlinking/copying should be done in debian/rules IMHO [14:33] no need to carry duplicate bits into the orig [14:33] I'd go for symlinking [14:33] hmm ok [14:33] I'd go for symlinking in orig anyway [14:33] roger [14:35] 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] if we replace it with symlinks the orig can still stand for itself [14:36] back in 5 [14:36] but it's OK any way for me :) [14:41] Baby: stand for itself> good point; let's do that then === hyperair1 is now known as hyperair === hyperair1 is now known as hyperair === fta_ is now known as fta === bluesmoke is now known as Amaranth === DrKranz is now known as DktrKranz === DrKranz is now known as DktrKranz [18:32] anyone know if/when python3-tk is gonna be created/released ? [18:56] ScottK: Aha, thanks [19:24] What is the username/password to be used for using email interface of requestsync? === azeem_ is now known as azeem [21:06] anybody know how I get a project out of the trash bin on source forge? [22:02] Developers! Developers! Developers! [22:03] Happy new year! :) === dwatson is now known as davewatson