=== fisted_ is now known as fisted [04:33] 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] For example, this simple program: http://paste.ubuntu.com/1317120/ [04:33] Produces this output: Bad string: �~]αι, Good string: γεια [04:37] Or is this by design, and these tools don't support utf8, and they should be fixed to use libncursesw5 etc? [04:43] Btw, htop works just fine [04:47] alkisg: might be the lack of the use of libncursesw5 [04:47] jalcine: I tried using libncursesw5 in my example program, and failed there as well [04:48] odd. [04:48] #include , gcc -lncursesw [04:48] I don't know if my examples, and the top/xrestop etc programs do something wrong... [04:54] Hmmm `watch` had the same problem, but has been solved: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=240989 [04:54] Debian bug 240989 in procps "procps: watch doesn't handle UTF-8 or VT100 line-drawing characters properly" [Normal,Fixed] [04:59] That probably means that I need to file bugs in debian in all the affected packages... [07:48] anyone here has any experience with or recommendations for packaging vim plugins? === yofel_ is now known as yofel [07:59] aha http://pkg-vim.alioth.debian.org/vim-policy.html/ === dholbach_ is now known as dholbach === Ursinha-afk is now known as Ursinha [08:13] stgraber, could you rescore https://launchpad.net/~ubuntu-rebuilds/+archive/py3.3/+build/3942297 ? [08:13] barry: sure [08:13] stgraber, thanks! [08:13] done === mcclurmc_away is now known as mcclurmc [08:29] 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" === dholbach_ is now known as dholbach === stan_ is now known as stan === dholbach_ is now known as dholbach === morphis|away is now known as morphis === mcclurmc is now known as mcclurmc_away === mcclurmc_away is now known as mcclurmc === morphis is now known as morphis|away === morphis|away is now known as morphis [09:38] 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] 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] If a package has Debconf translations in a new upload, would merging it make sense? [10:03] the only changes are just translations? [10:04] geser: yes [10:06] I'd probably only merge it if was really bored and pick an other package needing a merge otherwise === morphis is now known as morphis|away === dendro-afk is now known as dendrobates [10:22] 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] alexbligh1: more like Replaces and Breaks, see the Debian policy for how to replace a package [10:35] goodness, has nobody written something to replace taleo? :/ [10:35] err, wrong channel , sorry. === dendrobates is now known as dendro-afk === dholbach_ is now known as dholbach === morphis|away is now known as morphis === Quintasan_ is now known as Quintasan === cpg is now known as cpg|away === Ursinha is now known as Ursinha-afk [11:30] 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] geser, you said 'Replaces' and 'Breaks' [11:31] 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] that isn't the case here. [11:31] (7.6.1) [11:31] 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] alexbligh1: it sounds like you want §7.6.2 (i.e. Provides: bar, Conflicts: bar and Replaces: bar) [11:32] 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] bonus [11:33] nthykier, and that is safe if foo previously depended upon bar? [11:33] alexbligh1: is bar shipped in the same source? [11:33] alexbligh1: I believe it is [11:34] micahg, they were both in repo X. User changes to repo Y, does 'aptitude update', 'aptitude upgrade'. [11:34] repo Y just has the (new) foo. [11:35] alexbligh1: that wasn't my question [11:35] nthykier, thanks [11:35] micahg, source package? no. [11:35] I'm under control of the source packaging though, but the old versions of foo and bar are in the wild. [11:36] 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] jml: ping [11:37] mahdy: what's up? [11:38] jml: hi , i have a question about undistract me [11:38] 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] mahdy: sure. what's the question? [11:38] micahg, thanks [11:39] *not so nice [11:39] jml: i want use undistract-me with zsh , but seems it is for bash only [11:39] mahdy: that's right. [11:40] jml: can you port it for zsh too ? [11:40] mahdy: the most interesting bit of undistract-me is hacking around bash's lack of pre-command hooks. [11:40] jml: zsh dosnt have this feature ? [11:41] mahdy: I couldn't say for sure, but I'm pretty sure that it does. [11:41] mahdy: and that making undistract-me work for zsh would be easier than for bash. [11:42] jml: well , i want to port it to bash [11:42] jml: do you have any repository ? [11:42] mahdy: you mean zsh, right? [11:43] jml: yes yes , sry , typo [11:43] mahdy: yes. it's on Launchpad. https://code.launchpad.net/undistract-me [11:44] jml: thank you , im working on it [11:45] alexbligh1: why not just simply drop the dependency on bar and let the auto-remove feature clean it up? [11:46] geser, it doesn't seem to remove it (for reasons unknown). [11:48] 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] mahdy: cool. good luck. [11:54] alexbligh1: is there any reason to remove D (does it cause problems) or just for clean-up? [11:55] is there anything else that might depend on D? [12:06] geser, yes, it causes problems. No, there is nothing else that might depend on D. === mcclurmc is now known as mcclurmc_away === salem_ is now known as _salem [12:32] in that case a Conflicts seems to be right [12:33] geser, thanks. So Provides: Replaces: + Conflicts:. === mcclurmc_away is now known as mcclurmc === Ursinha-afk is now known as Ursinha === mcclurmc is now known as mcclurmc_away === _salem is now known as salem_ === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === txwikinger2 is now known as txwikinger === mcclurmc_away is now known as mcclurmc === mcclurmc is now known as mcclurmc_away === mcclurmc_away is now known as mcclurmc === mcclurmc is now known as mcclurmc_away === mcclurmc_away is now known as mcclurmc === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === salem_ is now known as _salem === fisted is now known as Guest77380 === cpg|away is now known as cpg === Ursinha is now known as Ursinha-afk === morphis is now known as morphis|away === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === mcclurmc is now known as mcclurmc_away === mcclurmc_away is now known as mcclurmc