[04:33] <alkisg> Hi, `top`, `xrestop` etc use ncurses. I think ncurses has problems with utf8 chars, and I'm not sure if it's related to how it's compiled in Ubuntu.
[04:33] <alkisg> For example, this simple program: http://paste.ubuntu.com/1317120/
[04:33] <alkisg> Produces this output: Bad string: �~]αι, Good string: γεια
[04:37] <alkisg> Or is this by design, and these tools don't support utf8, and they should be fixed to use libncursesw5 etc?
[04:43] <alkisg> Btw, htop works just fine
[04:47] <jalcine> alkisg: might be the lack of the use of libncursesw5
[04:47] <alkisg> jalcine: I tried using libncursesw5 in my example program, and failed there as well
[04:48] <jalcine> odd.
[04:48] <alkisg> #include <ncursesw/ncurses.h>, gcc -lncursesw
[04:48] <alkisg> I don't know if my examples, and the top/xrestop etc programs do something wrong...
[04:54] <alkisg> Hmmm `watch` had the same problem, but has been solved: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=240989
[04:59] <alkisg> That probably means that I need to file bugs in debian in all the affected packages...
[07:48] <Chipzz> anyone here has any experience with or recommendations for packaging vim plugins?
[07:59] <Chipzz> aha http://pkg-vim.alioth.debian.org/vim-policy.html/
[08:13] <barry> stgraber, could you rescore https://launchpad.net/~ubuntu-rebuilds/+archive/py3.3/+build/3942297 ?
[08:13] <stgraber> barry: sure
[08:13] <barry> stgraber, thanks!
[08:13] <stgraber> done
[08:29] <pitti> YokoZar: if I did say it like that, it was wrong; I meant "for an upload we run that package's tests and all tests of its reverse depends"
[09:38] <OdyX> pitti: you there? I've been reviewing cups-1.6.1 packaging and I think we should bump the libcupsimage soname to 2debian1 or something, upstream drops symbols from 1.4.0.
[09:53] <OdyX> pitti: hrm. This might get solved by depending on the correct minimum version of libcupsfilters1. I'll do that instead, looks less intrusive.
[10:02] <vibhav> If a package has Debconf translations in a new upload, would merging it make sense?
[10:03] <geser> the only changes are just translations?
[10:04] <vibhav> geser: yes
[10:06] <geser> I'd probably only merge it if was really bored and pick an other package needing a merge otherwise
[10:22] <alexbligh1> Hi. I have a package foo, the previous version of which depended on a package bar. The new version of foo does the same job as bar, and bar should not really be installed with it. In the debian/control file for the new version of foo, should I use Provides: bar or Conflicts: bar or both?
[10:29] <geser> alexbligh1: more like Replaces and Breaks, see the Debian policy for how to replace a package
[10:35] <sivang> goodness, has nobody written something to replace taleo? :/
[10:35] <sivang> err, wrong channel , sorry.
[11:30] <alexbligh1> Earlier I asked: I have a package foo, the previous version of which depended on a package bar. The new version of foo does the same job as bar, and bar should not really be installed with it. In the debian/control file for the new version of foo, should I use Provides: bar or Conflicts: bar or both?
[11:30] <alexbligh1> geser, you said 'Replaces' and 'Breaks'
[11:31] <alexbligh1> but http://www.debian.org/doc/debian-policy/ch-relationships.html says 'Replaces' and 'Breaks' is where a package overwrites files provided by another.
[11:31] <alexbligh1> that isn't the case here.
[11:31] <alexbligh1> (7.6.1)
[11:31] <alexbligh1> Under 7.6.2 it suggests 'Provides:' 'Conflicts' and 'Replaces', but I don't know whether that is a great plan if foo previously depended on bar.
[11:32] <nthykier> alexbligh1: it sounds like you want §7.6.2 (i.e. Provides: bar, Conflicts: bar and Replaces: bar)
[11:32] <alexbligh1> All I want to do is ensure that when the new 'foo' is installed, 'bar' (which foo previously depended on) is removed. Ensuring it is purged (conffiles removed) woud be a bonys
[11:32] <alexbligh1> bonus
[11:33] <alexbligh1> nthykier, and that is safe if foo previously depended upon bar?
[11:33] <micahg> alexbligh1: is bar shipped in the same source?
[11:33] <nthykier> alexbligh1: I believe it is
[11:34] <alexbligh1> micahg, they were both in repo X. User changes to repo Y, does 'aptitude update', 'aptitude upgrade'.
[11:34] <alexbligh1> repo Y just has the (new) foo.
[11:35] <micahg> alexbligh1: that wasn't my question
[11:35] <alexbligh1> nthykier, thanks
[11:35] <alexbligh1> micahg, source package? no.
[11:35] <alexbligh1> I'm under control of the source packaging though, but the old versions of foo and bar are in the wild.
[11:36] <micahg> alexbligh1: so, if it's similar functionality, you'll want to look at policy 7.4 and 7.5 and possibly do Conflicts/Replaces/Provides, just keep in mind that update-manager isn't happy with conflicts
[11:37] <mahdy> jml: ping
[11:37] <jml> mahdy: what's up?
[11:38] <mahdy> jml: hi , i have a question about undistract me
[11:38] <micahg> alexbligh1: if it was in the same source, I would've suggested a transitional package, but that's so nice if it's someone else's package
[11:38] <jml> mahdy: sure. what's the question?
[11:38] <alexbligh1> micahg, thanks
[11:39] <micahg> *not so nice
[11:39] <mahdy> jml: i want use undistract-me with zsh , but seems it is for bash only
[11:39] <jml> mahdy: that's right.
[11:40] <mahdy> jml: can you port it for zsh too ?
[11:40] <jml> mahdy: the most interesting bit of undistract-me is hacking around bash's lack of pre-command hooks.
[11:40] <mahdy> jml: zsh dosnt have this feature ?
[11:41] <jml> mahdy: I couldn't say for sure, but I'm pretty sure that it does.
[11:41] <jml> mahdy: and that making undistract-me work for zsh would be easier than for bash.
[11:42] <mahdy> jml: well , i want to port it to bash
[11:42] <mahdy> jml: do you have any repository ?
[11:42] <jml> mahdy: you mean zsh, right?
[11:43] <mahdy> jml: yes yes , sry , typo
[11:43] <jml> mahdy: yes. it's on Launchpad. https://code.launchpad.net/undistract-me
[11:44] <mahdy> jml: thank you , im working on it
[11:45] <geser> alexbligh1: why not just simply drop the dependency on bar and let the auto-remove feature clean it up?
[11:46] <alexbligh1> geser, it doesn't seem to remove it (for reasons unknown).
[11:48] <alexbligh1> Possibly because I simplified the config. It's actually A which depends on B which depends on C and D which are installed. D's functionality is replaced by C and should be left around. It's A that's actually 'installed'. Updating then appears not to remove D.
[11:48] <jml> mahdy: cool. good luck.
[11:54] <geser> alexbligh1: is there any reason to remove D (does it cause problems) or just for clean-up?
[11:55] <geser> is there anything else that might depend on D?
[12:06] <alexbligh1> geser, yes, it causes problems. No, there is nothing else that might depend on D.
[12:32] <geser> in that case a Conflicts seems to be right
[12:33] <alexbligh1> geser, thanks. So Provides: Replaces: + Conflicts:.