[00:10] Hi. I could use a bit of help with bug #349853 [00:10] Launchpad bug 349853 in mumble "[needs-packaging] Please sync mumble 1.1.8-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/349853 [00:11] We're way past the feature freeze, so it's not going to make it into Jaunty, and as it's in unstable (and the 1.1.7-3 release is already in Ubuntu), it will be auto-synced once Jaunty is released. [00:13] First off, someone marked it "needs packaging". I thought this was reserved for packages not already in Ubuntu/Debian? Second, since this won't happen for Jaunty, and will happen automatically for Jaunty+1, what should the bug actually be marked as? [00:15] slicer, the [needs packaging] was added by Tristan Greaves [00:15] slicer, and it's entirely inappropriate to mark your bug with that tag [00:16] slicer: The autosync question is a hard one. I'm not sure whether it's better to leave it open, mark it Invalid, or add a Debian task with status Fix Released. [00:16] The last is easy to deal with later. [00:16] Because we can get a list of bugs fixed upstream but not in Ubuntu. [00:17] directhex: Ok, so I can just remove that tag? [00:18] i would [00:18] Yes. [00:18] That's clearly wrong. [00:18] And maybe email the triager, if it wasn't too long ago. [00:18] along with a grumpy "why was this inappropriate tag added? >8\/" [00:18] I'd be tempted to just invalidate it [00:19] Laney: That's not correct, but it's probably the most efficient course of action. [00:19] So it's a good idea. [00:19] wgrant: Right, it's not at all clear what is "correct" herere [00:19] -re [00:20] maybe Won't Fix is more accurate [00:20] Oh, that's true. [00:20] Laney: Uh. There is no "Won't Fix"? [00:20] slicer: For privileged users there is. [00:20] Laney: At least not on the launchpad bug interface. [00:20] wgrant: Ah. [00:21] wgrant: That doesn't help me though ;) [00:21] I'll set it with a comment [00:21] slicer: Only ~ubuntu-bugcontrol can do it. [00:21] Which includes ~ubuntu-dev and various other teams. [00:21] Laney: Thanks. [00:21] done === vorian is now known as heHATEme [02:54] Hmm, libjack0.100.0-dev depends on libjack-dev, but libjack-dev conflicts with it (no replaces). This caused pbuilder to panic when I had a package build depend on libjack0.100.0-dev, but for some reason I can install it with apt-get === heHATEme is now known as vorian [03:23] put pyglet 1.3 in repo, you only have 1.1.2 [04:10] err, jack-audio-connection-kit is somewhat special, though. [04:10] d'oh, he's not present [06:04] hi, can someone tell me where can I find the "debian/" trees for some upstream python packages? I mean the tree that is used before running "dpkg-buildpackage -us -uc". I would like to see more examples of file like {control, compat, menu, rules}. [06:05] cpscotti: e.g., http://package-import.ubuntu.com/ ? [06:08] dtchen: exactly! thanks a bunch! === bluesmoke_ is now known as Amaranth [12:23] oo-ops [12:28] quadrispro: :-) [12:33] pochu: my brain crashed with segfault, rebooting now [12:33] :) [12:40] quadrispro: you're not the first one to make that mistake though ;) [13:00] y, I know === leleobhz is now known as metilfenidato === Nicke_ is now known as Nicke === metilfenidato is now known as leleobhz === thunderstruck is now known as gnomefreak === [NIP]-AggeSerle is now known as murdok === thunderstruck is now known as gnomefreak === proppy1 is now known as proppy === ZehRique is now known as ZehRique-OFF === thunderstruck is now known as gnomefreak [16:35] >> < socinfo> "ubuntu" is Ubuntu had applied and was accepted, but they have subsequently chosen not to participate in GSoC 2009 [16:36] * RainCT wonders why he hadn't heard anything at all about this before.. yay for transparency and using the mailing lists :P [16:38] Old news. [16:39] to some maybe, i hadent heard that either [16:39] :) === RoAk is now known as RoAkSoAx [18:14] persia: Is lash a package that we care about maintaining? It hasn't been touched since Hardy (you TIL). I just tried to rebuild it for the Python 2.6 transition and it has an unrelated FTBFS now. === bastiao_ is now known as k0p === azeem_ is now known as azeem === hyperair_ is now known as Guest74075 === hyperair_ is now known as Guest540 === Guest540 is now known as hyperair === hyperair is now known as Guest92752 [19:58] OT, can someone tell me what the difference between «In the indexed addressing mode, the instruction contains a memory address to access» and «In the indirect addressing mode, the instruction contains a register that contains a pointer to where the data should be accessed.» is? Sounds like the same to me :P [20:05] RainCT: register != address [20:07] pochu: Right (register is in the CPU's memory?). What does it mean that an instruction contains a register? [20:08] RainCT: it's the opposite [20:08] err [20:08] no, that is [20:09] the instruction gives you the number of a register [20:09] eg $5 [20:09] and the register contains a memory address [20:09] Ah [20:09] RainCT: but I don't know what that is, it's just what I understand from what you've pasted [20:11] Okay, I think now I understand it :). Thanks. [20:11] pochu: those are two of several methods how the computer can access the data, as described in "Programming from the Ground Up" (http://savannah.nongnu.org/projects/pgubook/) [20:13] And if you wonder why the heck I'm reading that, it's all kirkland's fault :P, as he recommended me the book "Hackers: heroes of the computer revolution" which has just made me curious on what assembly looks like :P [20:20] I've studied MIPS assembly in uni [20:20] had to write a tetris game in mips ;) [20:25] pochu: how many LOC? [20:25] * sebner waves at pochu :) [20:26] hey sebner :) [20:26] RainCT: 937, but that includes comments et al [20:27] RainCT: it's a very basic tetris for the console [21:38] <_stochastic_> what's the command to allow me to execute a command within the pbuilder environment after it has built (or failed to build) my package? [21:40] _stochastic_: have a look at /usr/share/doc/pbuilder/examples/C10shell [21:42] <_stochastic_> pochu, thanks, that looks like it's in the right direction, but I'm somewhat of a packaging noob and it's terseness confuses me [21:43] <_stochastic_> do I need to run all those commands before executing 'sudo pbuilder build packagename.dsc' ? [21:44] no [21:44] _stochastic_: that's a hook that is automatically executed at some point [21:44] for C* hooks, it's on build failure [21:44] and for B*, on build success [21:44] you want both IIUC [21:45] so you need to add that hook as C10shell and B10shell to your hooks [21:45] <_stochastic_> I'm mostly concerned with C* hooks, but both would be nice [21:45] look for hook in pbuilderrc manpage [21:45] I only have them for C* FWIW [21:45] and pbuilder(8) also explains them [21:46] <_stochastic_> okay, now I think I understand, I'll be back if I need further assistance. thanks. [23:30] ScottK, I've been looking at that FTBFS since January, without much success, unfortunately. I'd like to see it work, but haven't had luck.