[00:10] <slicer> Hi. I could use a bit of help with bug #349853
[00:11] <slicer> 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] <slicer> 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] <directhex> slicer, the [needs packaging] was added by Tristan Greaves
[00:15] <directhex> slicer, and it's entirely inappropriate to mark your bug with that tag
[00:16] <wgrant> 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] <wgrant> The last is easy to deal with later.
[00:16] <wgrant> Because we can get a list of bugs fixed upstream but not in Ubuntu.
[00:17] <slicer> directhex: Ok, so I can just remove that tag?
[00:18] <directhex> i would
[00:18] <wgrant> Yes.
[00:18] <wgrant> That's clearly wrong.
[00:18] <wgrant> And maybe email the triager, if it wasn't too long ago.
[00:18] <directhex> along with a grumpy "why was this inappropriate tag added? >8\/"
[00:18] <Laney> I'd be tempted to just invalidate it
[00:19] <wgrant> Laney: That's not correct, but it's probably the most efficient course of action.
[00:19] <wgrant> So it's a good idea.
[00:19] <Laney> wgrant: Right, it's not at all clear what is "correct" herere
[00:19] <Laney> -re
[00:20] <Laney> maybe Won't Fix is more accurate
[00:20] <wgrant> Oh, that's true.
[00:20] <slicer> Laney: Uh. There is no "Won't Fix"?
[00:20] <wgrant> slicer: For privileged users there is.
[00:20] <slicer> Laney: At least not on the launchpad bug interface.
[00:20] <slicer> wgrant: Ah.
[00:21] <slicer> wgrant: That doesn't help me though ;)
[00:21] <Laney> I'll set it with a comment
[00:21] <wgrant> slicer: Only ~ubuntu-bugcontrol can do it.
[00:21] <wgrant> Which includes ~ubuntu-dev and various other teams.
[00:21] <slicer> Laney: Thanks.
[00:21] <Laney> done
[02:54] <YokoZar> 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
[03:23] <smallfoot-> put pyglet 1.3 in repo, you only have 1.1.2
[04:10] <dtchen> err, jack-audio-connection-kit is somewhat special, though.
[04:10] <dtchen> d'oh, he's not present
[06:04] <cpscotti> 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] <dtchen> cpscotti: e.g., http://package-import.ubuntu.com/ ?
[06:08] <cpscotti> dtchen: exactly! thanks a bunch!
[12:23] <quadrispro> oo-ops
[12:28] <pochu> quadrispro: :-)
[12:33] <quadrispro> pochu: my brain crashed with segfault, rebooting now
[12:33] <quadrispro> :)
[12:40] <pochu> quadrispro: you're not the first one to make that mistake though ;)
[13:00] <quadrispro> y, I know
[16:35] <RainCT> >>  < 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] <jpds> Old news.
[16:39] <imbrandon> to some maybe, i hadent heard that either
[16:39] <imbrandon> :)
[18:14] <ScottK> 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.
[19:58] <RainCT> 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] <pochu> RainCT: register != address
[20:07] <RainCT> pochu: Right (register is in the CPU's memory?). What does it mean that an instruction contains a register?
[20:08] <pochu> RainCT: it's the opposite
[20:08] <pochu> err
[20:08] <pochu> no, that is
[20:09] <pochu> the instruction gives you the number of a register
[20:09] <pochu> eg $5
[20:09] <pochu> and the register contains a memory address
[20:09] <RainCT> Ah
[20:09] <pochu> RainCT: but I don't know what that is, it's just what I understand from what you've pasted
[20:11] <RainCT> Okay, I think now I understand it :). Thanks.
[20:11] <RainCT> 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] <RainCT> 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] <pochu> I've studied MIPS assembly in uni
[20:20] <pochu> had to write a tetris game in mips ;)
[20:25] <RainCT> pochu: how many LOC?
[20:25]  * sebner waves at pochu :)
[20:26] <pochu> hey sebner :)
[20:26] <pochu> RainCT: 937, but that includes comments et al
[20:27] <pochu> 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] <pochu> _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] <pochu> no
[21:44] <pochu> _stochastic_: that's a hook that is automatically executed at some point
[21:44] <pochu> for C* hooks, it's on build failure
[21:44] <pochu> and for B*, on build success
[21:44] <pochu> you want both IIUC
[21:45] <pochu> 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] <pochu> look for hook in pbuilderrc manpage
[21:45] <pochu> I only have them for C* FWIW
[21:45] <pochu> 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] <persia> 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.