| 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:04 |
| 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:06 |
| 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? | 00:07 |
| kolby | What is the normal way to get source and store code for an ubuntero? | 01:37 |
| 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:38 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| ebroder | Yeah, I agree | 01:49 |
| cjwatson | mkdir whatever; cd whatever before you apt-get source | 01:49 |
| kolby | cjwatson, that's what I've been doing. | 01:50 |
| 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:51 |
| * 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:52 |
| 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:53 |
| * kolby googles wajig... | 01:54 | |
| cjwatson | you could apt-cache show it instead | 01:54 |
| kolby | cjwatson, i see *nods* | 01:54 |
| cjwatson | (I have no information on whether it needs to be updated in some way to work with Ubuntu!) | 01:55 |
| kolby | hmm... | 01:55 |
| 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:56 |
| * 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:57 |
| 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:58 |
| kolby | okay. | 01:59 |
| kolby | does it come preinstalled then? I think Ubuntu ships with w3m | 01:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| * 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:09 |
| 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:11 |
| === ScottK3 is now known as ScottK-desktop | ||
| 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:12 |
| ion_ | Vim is better than Grub. | 02:13 |
| kolby | ion_, no firefox is better. ;) | 02:13 |
| kolby | is there a way to make a package for user's dot-files? (ex. .bash_aliases) | 02:15 |
| kolby | how _should_ I go about doing this if I wanted to? | 02:16 |
| kolby | I couldn't find anything on it in packaging articles. | 02:17 |
| 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:18 |
| 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:19 |
| kolby | he meant "/etc/foobar-rc" stuff right? | 02:21 |
| Hobbsee | yes | 02:22 |
| terli | are there any gnome developers in here? | 02:23 |
| kolby | terli, I'm using gnome's libxml2. Does that count? | 02:25 |
| terli | um | 02:25 |
| 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. | 02:26 |
| shingen | can anyone help me out with an initramfs issue with dmraid not running before a call to /dev/mapper is made? | 03:24 |
| 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:26 |
| 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:29 |
| ScottK | shingen: Is this a server or desktop install? | 03:32 |
| shingen | ScottK: desktop, used 8.10 64 bit alternate | 03:33 |
| 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:34 |
| shingen | thanks | 03:35 |
| nhandler | emgent: pong | 05:22 |
| === jcastro_ is now known as jcastro | ||
| === Tweenaks is now known as Treenaks | ||
| lool | Does someone happen to know why Ubuntu backports don't have NotAutomatic in their Release files? | 09:53 |
| persia | lool, Wouldn't that block upgrades within backports? I know the backporters do security updates for some of the backports. | 09:55 |
| lool | persia: It would, but it would also prevent upgrades to all backported packages by default | 09:56 |
| persia | Hrm. I thought there was another way to reduce the priority, but yes, I can see that. | 09:59 |
| 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:03 |
| 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:04 |
| persia | I think the long-term plan is to integrate with that new package, although I'm not sure. | 10:08 |
| 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:10 |
| lool | I had to use them for ... unison :-/ | 10:11 |
| persia | Or with jdong or ScottK or Mez or ... | 10:11 |
| * persia hides | 10:11 | |
| 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:12 |
| lool | unison 2.9 in sarge, 2.13 in etch, 2.27 in lenny/sid... | 10:13 |
| persia | Well, unison is incompatible across most unison releases. Part of the nature of how upstream does things. | 10:14 |
| 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:15 |
| 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:16 |
| lool | +and | 10:17 |
| persia | Well, I suppose we could do it that way, although I'm not terribly excited about it. | 10:19 |
| lool | It would obviously be easier if upstream would simply support a protocol forever or arrange to support multiple versions of the procol :) | 10:20 |
| 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:21 |
| 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:22 |
| 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:26 |
| Baby | pitti: ping! | 10:32 |
| === thunderstruck is now known as gnomefreak | ||
| === jussio1 is now known as jussi01 | ||
| tjaalton | how come the adobe-flashplugin isn't built on amd64? | 11:02 |
| tjaalton | better ask adobe I guess.. | 11:04 |
| gnomefreak | tjaalton: i thought adobe made a amd64 build | 11:09 |
| tjaalton | gnomefreak: yeah, but apparently it's still beta | 11:09 |
| gnomefreak | ah | 11:10 |
| 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:12 |
| 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:15 |
| 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:16 |
| 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:17 |
| gnomefreak | last i heard they havent changed it but i heard ubuntu packages were being worked on from adobe | 11:19 |
| === asac_ is now known as asac | ||
| gnomefreak | that might be a rumor | 11:19 |
| 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:20 |
| tjaalton | probably, but I'm talking about security issues ;) | 11:21 |
| tjaalton | lunch-> | 11:22 |
| === lfalavi is now known as DktrKranz | ||
| tjaalton | right, no flash9 available anymore | 11:48 |
| 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:16 |
| pitti | Baby: pong | 14:17 |
| Baby | :) | 14:17 |
| pitti | Baby: oh, Miriam! nice nick :-) | 14:17 |
| Baby | thanks! :) | 14:17 |
| bardyr | wtf | 14:17 |
| 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:18 |
| pitti | Baby: great | 14:19 |
| pitti | Baby: did you get along with the bzr stuff? anything major I missed in the packaging merging? | 14:19 |
| 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:20 |
| 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:21 | |
| Baby | oki :) thanks! | 14:22 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:35 |
| pitti | back in 5 | 14:36 |
| Baby | but it's OK any way for me :) | 14:36 |
| pitti | Baby: stand for itself> good point; let's do that then | 14:41 |
| === 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 | ||
| barefoot | anyone know if/when python3-tk is gonna be created/released ? | 18:32 |
| lool | ScottK: Aha, thanks | 18:56 |
| slytherin | What is the username/password to be used for using email interface of requestsync? | 19:24 |
| === azeem_ is now known as azeem | ||
| rjune_ | anybody know how I get a project out of the trash bin on source forge? | 21:06 |
| Uuu | Developers! Developers! Developers! | 22:02 |
| Uuu | Happy new year! :) | 22:03 |
| === dwatson is now known as davewatson | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!