[00:07] heya [00:07] hey emgent [00:07] hey NCommander [00:07] emgent, what be up? [00:07] i saw your private message about utu [00:08] one moment :) [00:08] fixed [00:11] Cool [00:11] * NCommander eyes #4 on the list === Pici` is now known as Pici [01:51] anyone familiar with inoticoming? [01:52] is it possible to watch an nfs-mounted directory? [02:21] if you get "warning: format not a string literal and no format arguments" for a printf(foo); call then the fix is printf("%s", foo); isn't it? [02:21] I mean, the two printfs are equivalent, correct? [02:21] I think so. [02:22] The latter will not do formatting if foo has %'s. [02:22] But that's the point. [02:23] but formatting would require subsequent arguments wouldn't it? [02:24] Yes. [02:25] ok, thanks [02:25] The warning is there because printf(foo); is dangerous if foo is a user-inputted string. It would probably crash the program if there were %'s in the string. There are worse things that could happen, though. [02:49] I am trying to compile a program but it is giving a version mismatch error on libtool. I have libtool 2.2.4 but the program may be expecting the old 1.5, what can I do? [02:53] relibtoolize. [02:54] that didn't work I have tried libtoolize and libtoolize --force, I have also tried aclocal to rebuild aclocal.m4 as the error suggests but nothing works [02:55] they developers say they have got it to compile on the same version of linux I have Ubuntu 8.10, so I guess it is something about my system [03:05] ScottK, feel like sponsoring an upload? [03:06] what files besides ltmain.sh have commands or directives that pertain to libtool that I may need to update to match ltmain.sh? [03:08] phirestalker, what package is it? [03:09] it is oreka from oreka.sourceforge.com [03:09] (usually you can get away with libtoolize --force --install --verbose in the source code folder) [03:11] the only complaint seems to be about install-sh: libtoolize: `/usr/share/libtool/config/install-sh' is serial 2006.12.25.00, greater than 0 in `./install-sh' === asac_ is now known as asac === beuno_ is now known as beuno [06:25] Anyone with a WP installation that gets the WP update announcement that can test something for me? === doko_ is now known as doko [08:32] how can i make a changelog ? is there any tool to create a standard changeLog ? [08:33] it seems i should ask my question in #ubuntu-motu ! [08:34] or not !? [08:38] just write yours in the standard [08:38] way [08:39] it's pretty trivial... [08:40] i do that already :) [08:46] there's an emacs helper dpkg-dev-el [08:46] it has a changelog mode [08:46] might help [08:54] legreffier: thinkgnu dch (dch -i is also useful) [08:58] it's not in my ubuntu :/ [08:58] (using hardy currently) [08:58] me too ! :P [09:01] legreffier: it seems you need ubuntu-dev-tools [09:06] apt-cache search dch didn't show the way, thanks [09:07] np ;) === thinkgnu_ is now known as thinkgnu [09:13] Hobbsee: it seems what i want , thanks. === gouki_ is now known as gouki [10:04] man, still with the a1? o_o === thinkgnu1 is now known as thinkgnu === arthur_ is now known as arthur- [11:29] hi there, is it the right place to ask for advice about packaging for ubuntu ? [11:30] deufrai: #ubuntu-motu is more used to doing mentoring work [11:30] cjwatson: thank you === cjwatson changed the topic of #ubuntu-devel to: Archive: open, MoM running | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs [11:32] directhex: ^- [11:36] urgh [11:37] so how am i supposed to handle a patch in a quilt package that needs an autoreconf run ? [11:37] afaik quilt requires me to add all touched files to the patch, how would i know which these were ? [11:38] * ogra curses quilt once again === Michiel__ is now known as Eghie [12:20] ogra: What I've done on a few occasions is to do all the patching I wanted, dpkg-buildpackage -S, run debdiff between the previous version and this one, filterdiff -x '*debian/*'.. That's usually the stuff that ought to be in the quilt patch... So I pipe it to a file and quilt import that, and "patch -R -p1" it on the dev tree. Presto. [12:20] phew [12:20] lots of work induced by a silly patch system :) [12:20] It sounds bad, yes. [12:20] but right, that would indeed work [12:20] You get used to it, though :) [12:21] Have fun! :) [12:21] well, i ry to stay away from quilt, but wanted to see whats up with rpm (keeps alien from armel) [12:21] rpm itself is weirdly packages though [12:21] *packaged [12:22] soren, thanks for the hint [12:22] :) [12:22] Quilt is growing on me, actually. It's very good when patches need to be refreshed. [12:22] ogra: sure thing. [12:22] * soren wanders off again [12:22] right, but in cases like the above i would just liked dpatch or even cdbs-edit-patch === cjwatson_ is now known as cjwatson [15:16] cjwatson, yay! of course, now someone needs to ack the mono upload. where's pitti hiding... [15:19] directhex, NEW or upload? [15:20] directhex, Reason being that most of the archive admins won't NEW stuff they upload, so if it needs both, you might do better to find a non-archive-admin uploader. [15:21] persia, name names. the longer this takes, the more painful it is for everybody [15:22] directhex, See, it's not about names. It's about teams. [15:22] I think you already subscribed ubuntu-main-sponsors. From there, someone ought get it. [15:22] Mentioning the bug and asking generally for an upload is one way to escalate, but doing that too much tends to bother people. [15:23] Asking each of the main sponsors individually is very likely to bother people. [15:23] My main recommendation is that if you are going to poke specific individuals, it might be fastest to not poke the archive-admins until the new package split is waiting in NEW, just because of the multistep process involved. [15:24] (and launchpad does have a list of main sponsors, if you're *really* curious) [15:30] persia, it's not my intention to be more obnoxious than my natural baseline level, i'm just a bit fed up with queues at the moment - especially on a package which experience says a lot of people don't want to be associated with. the last thing i want to see is a release turn up halfway through a package transition, gnat-style [15:31] hi there [15:31] iam searching for the gnome-volume-control maintainer [15:31] in my defence, pitti IS in u-m-s, and has been helpful in the past when i've needed merges and updates to get pushed through [15:32] Silicium, Ubuntu Desktop Team [15:32] ok i will try [15:33] so maybe anoyne know that bug [15:33] directhex, Sorry if I came off wrong: I don't mean to attack you: it's just that because I know you're doing a source split, and because the set of archive-admins is smaller than the set of main sponsors, I thought you'd be faster with another. [15:34] gnome setting "detachable menubars" was set, and the menubar of gnome-volume-control has been detached, and now it coulnt be attached again, the app faults with the following msg: [15:34] Bonobo:ERROR:(bonobo-dock-item.c:1342):bonobo_dock_item_get_child: code should not be reached [15:34] i think i should directly contact the gnome-dev ml [15:35] persia, s'okay. what with ubuntu-motu@lists and boycottnovell.com, i assume a baseline level of attack at all times :p [15:35] directhex, I can see that. [15:35] Silicium: file a bug, rather === njpatel is now known as njpatel_away [16:29] I've just had usb-creator hang, and I think it's because I was using a USB stick that turns out to be preformatted *without* an MBR: i.e. /dev/sdb is a vfat FS, *not* /dev/sdb1 ! [16:38] maxb_, i've lost track of whether you're meant to do that or not, in general. i know i've had devices which looked at me funny for not doing what they expected [16:39] maxb_, If you can recreate with it formatted that way, and the same key works with partitions, please file a bug. usb-creator is expecting partitions, but it's not supposed to hang. [16:56] cjwatson, Riddell: is there a reason not to enable mono in P-a-s? just seen that kde4bindings does ftbfs on lpia (NCommander mentioned that) [16:57] Scratch that [16:57] SOmeone added lpia support a few commits back [16:57] * NCommander hasn't recently checked the file [16:57] Someone needs to change the build-dependences on kde4bindings then [16:58] NCommander, they do anyway. [16:59] ?? [16:59] NCommander, kde4bindings is affected by the 2.0 transition [16:59] oh yay [17:00] NCommander, it has no rdepends though AFAIK, so it ought to be possible to make those changes pretty much immediately, ignoring the "wait for apps to transition first" rule. once mono 2.0 lands [17:01] directhex, kde4bindings are libraries :-P [17:01] Its depressing though if nothing uses them [17:01] NCommander, the cli bindings are pretty new [17:01] NCommander, meebey, who as well as being the main mono packager is upstream on an irc client called smuxi, was considering playing with them to make a kde frontend as well as gtk [17:02] ah cool [17:02] Just keep me apprised, if you need a sponsor, ping me [17:02] NCommander, really though, i don't know what more i can do to keep people informed about this, other than mass-filing 90 odd bugs on packages :/ [17:03] The changes are non-trivial (more than changing a build-dep, and bumping the changelog) [17:03] It will be slow going [17:04] NCommander, some packages are worse tha others. let me take a peek at kdebindings for you. not like i have much else to do at this moment in time [17:04] kde4bindings :-) [17:05] (kdebindings is another package ;-)) [17:05] yes yes i know. it's kdebindings on debian [17:05] directhex@mortos:~$ monodis --assemblyref /usr/lib/cli/qyoto-4.3/qt-dotnet.dll | grep -B1 corlib [17:05] 1: Version=2.0.0.0 [17:05] Name=mscorlib [17:06] NCommander, good news, that means there's no additional testing needed, nor any reason to delay the transition, as it's already building against clr 2.0 [17:06] someone just needs to attempt the merge [17:07] i.e. the only changes are the build-dep, and making sure it uses 'csc' instead of 'gmcs' when building [17:07] of course, it's blocked on mono 2.0 itself, but it means it should be a *relatively* stress-free one [17:08] directhex: does it make sense to start with mono before we have a base kde4 built? [17:09] doko, w.r.t. to KDE, a new version going up on monday, so aside from the base libraries, I'm going to wait for that to land before running around fixing stuff [17:09] doko, other than kde4bindings (and i don't know how important that package is), it should be pretty unrelated. all mono apps in ubuntu are gtk-based [17:12] doko, as long as the appropriate parties understand that kde4bindings will FTBFS until it's been transitioned, once mono 2.0 lands, then i don't want to tell people how to do their jobs nor insist they alter their workflow [17:13] directhex: ahh, ok I'll stay out of the loop then. [17:14] directhex: does openoffice build with mono-2.0? [17:14] doko, i;ll check that for you [17:14] that would be nice [17:15] * NCommander wonders if OOo will explode [17:15] o_o [17:16] :-) [17:16] doko, OOo looks like it'll be rather less simple than kde4bindings [17:17] directhex: because I would like to get OOo on armel first built ... if it doesn't work with mono-2.0 [17:18] doko, okay, looking at it, you're only attempting to build the mono bindings on [i386 amd64 ia64 lpia sparc] [17:18] I know ... [17:19] doko, i can let you in on how to make it not ftbfs on other platforms, but please, it still needs to be transitioned [17:19] but it doesn't help if the binary-indep packages cannot be built on the i386 buildd [17:21] doko, 's/mono-2.0-devel/mono-devel/' will fix FTBFS, but please, those libs really need to be built against the 2.0 runtime (currently it seems OOo builds three 1.0 libs, and a 2.0 lib - all four should be 2.0) [17:22] directhex: a bug report including a patch would be fine, hint, hint ;) [17:22] calc: ^^^ [17:22] doko, i'll start on an apt-get source. it might be done by tomorrow [17:27] what build system does OOo use? [17:34] hm, i need a faster archive [17:34] oh bugger, forgot to change my mirror on this install [17:47] howto unbind the "Menu" key on the right side near the STRG key from gnome-terminal [17:54] a 100 meg diff.gz is officially insane [17:59] directhex: where did you get that? [18:03] hyperair, OOo [18:03] good grief [18:04] o_O [18:26] so i have this 8.04 system here that can't be upgraded to 8.10 [18:27] update-manager tells me 8.10 is available, so i click on it, see the README, click on upgrade, and then it just exits [18:28] it prints to the console: [18:28] extracting 'intrepid.tar.gz' [18:28] authenticate 'intrepid.tar.gz' against 'intrepid.tar.gz.gpg' [18:28] and then just exits [18:30] madduck: possibly related to https://bugs.edge.launchpad.net/ubuntu/+bug/245219 ? [18:30] Ubuntu bug 245219 in ubuntu "Ubuntu archive server returning incorrect content-encoding" [Undecided,New] [18:31] madduck: ie, are you behind some sort of a proxy? [18:31] no, it works when I run do-release-upgrade by hand [18:31] i just didn't know about that. [18:32] yes, a transparent http proxy [18:32] actually, do-release upgrade does an apt-get update with hardy, not intrepid [18:32] aha, now it's coming int... [18:32] anyway, works for me now, sorry for the noise. [18:35] madduck: not that this conversation has to take place now, but I'm working on merging mdadm again for ubuntu, and i'm curious if you're interested in getting this package somewhat closer to being 'in sync' [18:36] madduck: i did some work to improve booting on degraded devices for intrepid, which may or may not be of interest to you [18:43] kirkland: absolutely. I am talking to doug kirkland @redhat too about merging [18:44] kirkland: i saw your work. I would love to make use of most of it, but I have not found the time to wade through the entire huge patch [18:44] I do want to convert mdadm to quilt soon [18:44] madduck: that would be nice ;-) [18:44] (quilt) [18:44] based on a topgit repo [18:44] madduck: or git would be even better [18:44] don't you have to use launchpad? [18:45] madduck: i'm happy to help work through the diff with you at some point [18:45] kirkland: if i added quilt to mdadm post-lenny, would you be prepared to split the changes into quilt patches? [18:45] madduck: when's "post-lenny"? [18:45] kirkland: when it's ready. ;) [18:46] madduck: (trick question) :-) [18:46] kirkland: I am happy to do so earlier if I find the time, targetting experimental [18:46] madduck: sure, i think quilt would be a big improvement [18:46] It shouldn't even be a lot of work, but it is still time that's needed [18:46] and i am about 160% loaded these days [18:47] madduck: i'm certainly most familiar with the boot-degraded changes; i'd have to do some research about the rest of the changes ubuntu carries on mdadm [18:47] madduck: understood. [18:47] madduck: i got a little burnt out with users complaining about RAID 24x7, so i was happy to step away from RAID for a little while :-) [18:47] kirkland: would you send me an email to madduck@d.o so I get your details? [18:47] madduck: you bet. [18:48] madduck: i'm happy to work through Debian BTS, but looking at the size of the mdadm debian/ubuntu diff, it might take a few irc conversations to peel through everything [18:48] sweet. maybe i can find the time to give you an update on the cooperation with doug and maybe some time, ubuntu, fedora, redhat, and debian will all build their mdadm packages from the same repo. [18:48] madduck: remarkable ... Red Hat has a "Doug Kirkland" working on RAID? [18:48] kirkland: yeah, and as I said, I am very pressed for time up until around May. [18:48] madduck: and Canonical has a "Dustin Kirkland" :-) [18:49] no, [18:49] Ledford [18:49] madduck: fair enough [18:49] Doug Ledford [18:49] ah [18:49] kirkland: absolutely. I am talking to doug kirkland @redhat too about merging [18:49] freudian slip i know [18:49] ;-) [18:49] do you read pkg-mdadm-devel? [18:50] madduck: i haven't, to date. i certainly can subscribe. [18:50] well, might be useful if you track mdadm for Ubuntu... [18:51] there's also pkg-mdadm-commits [18:52] madduck: well, i haven't been really "tracking mdadm for Ubuntu" ... but I did decide to fix booting degraded RAID for Ubuntu, which put me deep into mdadm, initramfstools, and grub [18:52] lovely world, ey? [18:52] in a sentence or less, what is booting degraded RAID? [18:52] madduck: and i have a priority of trying to simplify the mdadm diff betwix debian/ubuntu, per request by jcastro [18:52] i mean, mdadm on Debian can boot degraded raids, no? [18:53] kirkland: awesome. hug jcastro from me. now it seems like i owe him another beer. :) [18:53] madduck: i'm not sure ... this might be a result of Debian/Ubuntu forkage [18:53] madduck: he's been on us about syncing back up, in a good way ;-) [18:53] that's great news. [18:53] you do know about http://vcs-pkg.org, yes? [18:54] madduck: so when a RAID becomes degraded (loses a disk) in Ubuntu, on the next boot, the mdadm --assemble with be tried a number of times (3 minutes in Hardy, 30 seconds in Intrepid), waiting for all the disks to spin up [18:54] madduck: in Hardy, when that timer expires, if disks are missing, the user gets dropped to an initramfs shell [18:55] madduck: the work i've done in Intrepid (and backported to hardy) includes: [18:55] madduck: a debconf question "Do you want to boot if your RAID becomes degraded?" (more or less the question) [18:55] damnit, i have to help my mother. i'll be back later to read this, ok? sorry about that. keep writing. [18:55] madduck: (sorry, not less than 1 sentence -- not possible :-) [18:56] madduck: the answer to that question is written to a file in /etc/initramfs-tools/conf.d/mdadm, which get's added to the initramfs [18:57] madduck: and in the initramfs, if the wait for all disks to spin up expires, the BOOT_DEGRADED value is read from file [18:57] madduck: if it's "true" or "yes" or whatever, the system RAID is assembled in degraded mode, and the system boots [18:58] madduck: if it's "false" or "no" or undefined, a message will be displayed, informing the user that a new RAID degrade event has been detected; do you want to boot on a degraded RAID [y/N]: [18:59] madduck: after 15s, "N" is assumed, and the system drops to an initramfs (busybox) shell, which is the legacy ubuntu behavior [18:59] madduck: dpkg-reconfigure mdadm can be used to change the value of your BOOT_DEGRADED selection [19:00] madduck: and we've added that debconf question to the debian-installer/partman if you're installing onto a RAID [19:00] madduck: beyond that, i also made some changes to grub (and grub-installer), to write the bootloader to each disk in an array [19:03] madduck: perhaps the most "compressed" patches for this functionality are the ones attached to https://bugs.edge.launchpad.net/ubuntu/+source/mdadm/+bug/290885 [19:03] Ubuntu bug 290885 in initramfs-tools "SRU: Backport of Boot Degraded RAID functionality from Intrepid to Hardy" [Wishlist,Fix committed] [19:03] madduck: that was the "backport" of the functionality, as contained as possible, to Hardy [19:04] madduck: the mdadm portion is http://launchpadlibrarian.net/19438493/mdadm.290885.debdiff [19:04] madduck: most of which is PO/translation noise [19:07] madduck: pruning out the i18n distractions, the functional patch looks more like this: http://pastebin.ubuntu.com/75724/ [19:10] madduck: that patch is dependent on an initramfs-tools patch, http://launchpadlibrarian.net/19438280/initramfs-tools.290885.debdiff , which provides a "mount root failure" framework whereby hooks can be defined and executed [19:18] madduck: all in all, udev will likely be the biggest hurdle === njpatel_away is now known as njpatel [19:39] calc, ping [20:14] directhex: hi [20:14] directhex: whats up? [20:14] calc, i wanted to ask when debian/control is rebuild on OOo [20:14] seems it's when i hoped, so only debian/rules needs patching [20:14] which means..... [20:14] directhex@mortos:/tmp$ diffstat openoffice.org-2.4.1_mono2.0transition.diff [20:14] rules | 7 +++---- [20:14] 1 file changed, 3 insertions(+), 4 deletions(-) [20:15] in THEORY that's correct & valid [20:15] debian/control gets rebuilt when you run debian/rules control [20:16] ok [20:16] yea i uploaded a new version of OOo 3.0 to the ppa last night waiting on doko to do some testing [20:16] i'm on vacation/holiday all next week [20:16] calc, well, i hope this section of debian/rules hasn't changed in 3.0 :/ [20:16] but i could do a new upload if needed [20:16] directhex: if it has it should be simple enough for me to port [20:17] directhex: you can email it to me at ccheney@u.c [20:17] calc, yeah, i reckon you can handle things like [20:17] -MONO_MINVER= (>= 1.2.3) [20:17] +MONO_MINVER= (>= 2.0) [20:17] yea :) [20:19] calc, OOo appears to have the build system from hell, but underneath it all, it smells like autofoo. and the transition with autofoo is pretty simple as long as you know the AC_PATH_PROGs to override [20:20] oh [20:20] yea OOo is very confusing in that it has two different configures [20:21] no, OOo is confusing as it seems to have three different patches for adding mono to the build [20:21] mono-build.diff, mono-build-m14.diff, mono-build-m15.diff [20:22] oh heh, yea it has many different confusing bits :\ [20:22] there are no apparent mono patches for 3.0 not sure if they were integrated or not [20:23] at least none named *mono* under ooo-build/patches/dev300/ [20:23] calc, anyway, i'll mail you this patch, but please be aware that i've neither tested it (partly because i don't like mucking with 'pristine' pbuilders, partly because i only just wrote it and don't have the 600ghz needed to have been able to test it by now), and it can't be applied until mono 2 is in jaunty [20:23] directhex: ok no problem [20:24] calc, i want to keep my transition wiki page updated. shall i assign OOo to you or me on it, to show that work is being done? [20:25] leave it as yourself but i will look into as i get time, i will be on vacation most of the rest of the year though (other than during UDS) [20:25] calc, who else should i speak to r.e. OOo/mono issues (or who should be speaking to me?) [20:26] i think there is a week after UDS that i will be around, so i could look at it then if i am not too slammed with other work [20:26] directhex: maybe doko, but he will probably be away a lot as well [21:16] Can a core developer give-back k3b on armel [21:17] evenin' NCommander! [21:17] evening [21:17] * NCommander preparing for his company's turkey party [21:18] yay, turkey [21:22] Free boozie === njpatel is now known as njpatel_away [21:23] * NCommander is going to discover if balmer's peak exists [21:24] do I resolve this correctly to http://xkcd.com/323/? [21:48] awalton__: oh, hi :) [21:51] awalton__: wouldn't it be better if your patch (nautilus scripts) also looked for deleted and modified files? [21:51] geser, yes, you do [22:00] anyone know of software for head tracking using a laptop camera? [22:01] ianm_: me not, but tell me if you find out ;P [22:07] RainCT: oh you'll hear about it... you already package my screenruler app ;) [22:09] opencv! [22:10] :) [22:12] * directhex wonders who's about this evening [22:14] * RainCT is to stupid to parse directhex's sentence :P [22:15] yo, directhex [22:16] Mithrandir! long time, no see. man, how long is it since i loitered in #debian-amd64? [22:17] long enough I have to look at another machine's irc logs. :-P [22:17] how's life? [22:18] good, good! looking after a LOT of kit these days [22:18] working on mono packaging in my spare time, it seems [22:18] yeah, I've noticed you asking about bits and pieces [22:18] kit> any fun, or just much of it? [22:20] Mithrandir, ehm... a 128-box xeon cluster, a 128-box opteron cluster, a new 66-blade SGI cluster, and a 256-core itanium SGI box [22:20] NCommander: k3b given back [22:21] directhex: ok, so what needs to go first? [22:21] directhex: mono itself? [22:22] directhex: wow. [22:22] cjwatson, yes, that's the important one [22:22] directhex: is http://launchpadlibrarian.net/19799395/mono_2.0.1.orig.tar.gz definitely bitwise-identical to what will end up in Debian? [22:22] ah. hm. let me triple-check that [22:24] hey cjwatson [22:24] cjwatson, I dunno if you caught the conversation between me and doko, but I'm going to hold off any more KDE-core FTBFS fixes until Monday when Beta 1 gets uploaded [22:24] *KDE4 [22:24] * RainCT feels ignored by directhex *g* [22:25] RainCT, sorry [22:26] NCommander: yeah, I saw, thanks [22:26] directhex: heh just joking ;) [22:28] cjwatson, it seems not. shite. hold on... [22:33] RainCT or others, is it hard to make a PPA .deb of a C app that uses a version of the liblo library that isn't in the repos yet? (0.25) [22:33] ianm_: it requires the liblo package to be uploaded to the PPA too [22:34] Mithrandir: would that interfere with enduser systems at all? [22:34] ianm_: the newer version would obviously be installed on the user's system. [22:34] assuming it works fine, that's not a problem [22:35] two versions of the same library installed is ok? [22:37] if the soname is different, yes. [22:38] directhex: there's at least one Ubuntu change missing here [22:38] + + libmono-mozilla0.2-cil: Drop libgluezilla to Suggests, it is in universe [22:38] + and pulls in the old xulrunner. [22:39] RainCT: there's also this http://code.google.com/p/ehci/ [22:39] cjwatson, gluezilla no longer needs xul 1.8. i'll file a MIR [22:40] ah yes, so it doesn't [22:41] directhex: what about the doc directory symlinking? [22:42] cjwatson, the patch for it is badly written and will never be accepted in debian. given the multi-meg savings elsewhere, i don't see it as a good reason to merge instead of syncing, for the sake of tens of k [22:45] I think it was more like 1.8MB, as it happens, though less compressed [22:46] but I'm OK with that rationale given that the number of binary packages is shrinking (isn't it?) [22:47] the number produced is *increasing*. the number needed for tomboy/f-spot is decreasing by about 50% [22:47] oh, hmm [22:48] I suppose it's more the latter we care about [22:49] as written the patch goes to more work than it needs to, certainly (I think it came from an implementation in cdbs); I would suggest that you should consider the idea (not necessarily the specific implementation) in Debian anyway, since symlinking documentation directories to a common base package is a perfectly reasonable thing to do there too [22:50] yes, i'll add it to the TODO [22:50] ianm_: thanks :) [22:50] directhex: ta [22:51] ianm_: btw, have you tried out touchlib/tbeta? [22:56] cjwatson, i don't think me or meebey realised the little issue w/ gzip reproducibility. i'm asking him to upload a copy of what will be uploaded to debian. [22:56] oh, upstream only releases bz2, I see [22:56] ok [22:58] i wonder if the debian archive will properly handle bz2 any time soon [22:58] should do with dpkg-source v3 [22:59] iirc, anyway [23:00] directhex, Debian has handled bzr2 for ages [23:01] I think they even handle lzma [23:01] NCommander, *all* of it? iirc some of the toolchain has gaps [23:01] NCommander: not as orig.tar compression methods [23:01] which is the matter at hand [23:02] I was fairly sure this feature was properly implemented [23:02] If not, well, I have a dak installation + source [23:02] * NCommander queues the evil laugh [23:03] it's rather easy to verify that it is not supported by Debian; you could for example search for files ending with .orig.tar.bz2 in a Debian mirror ... [23:04] my mistake [23:04] I was sure it was supported though :-/ [23:04] http://liorkaplan.wordpress.com/2008/01/31/origtarbz2-packages-in-debian/ [23:04] RainCT: not yet [23:06] cjwatson, I thought I already admitted they are not supported ;-) [23:07] just some verification [23:08] cjwatson, shall i upload the new orig to the LP bug? wait, i need to re-do the dsc too don't i [23:08] directhex: don't worry about the dsc [23:08] directhex: either upload it there or give me a URL [23:08] http://www.meebey.net/temp/debian/mono_2.0.1.orig.tar.gz [23:09] grabbing [23:13] ianm_: do you know if there's some .deb with OpenCV 1.1? [23:14] RainCT: nope. I got the same "Requested 'opencv >= 1.1.0' but version of OpenCV is 1.0.0" [23:14] * RainCT sighs and installs CVS [23:15] directhex: hmm, does this have stuff stripped out of the tarball as well as simply changing the compression type? [23:15] cjwatson, no, not anymore. the +dfsg was previously due to some non-dfsg-free licenses on some code (a CC license, i forget which). it was relicensed to expat at meebey's request [23:16] directhex: meebey seems to have repacked the tar as well, though [23:16] which seems a bit gratuitous? [23:16] yes, i've told him off about that. he'll be using bunzip2 | gzip in future [23:17] ok [23:17] apparently it never used to be an issue, which is technically true... [23:18] it's not an issue as such, it just makes it more effort to independently verify the status of divergence from upstream [23:19] if there's no +dfsg on it, assume it's just a workflow glitch by meebey [23:20] "independently verify" ;-) [23:20] (I've already checked myself [23:20] ) [23:32] kirkland: why would a user not want to assemble a degraded array? [23:33] anyway i need to sleep. we'll talk again, thanks for the explanation! :) [23:37] directhex: mono uploaded [23:37] directhex: what else can/should be done in the first stage before that builds? [23:38] directhex: libgdiplus? [23:38] cjwatson, yes, please sync it [23:38] cjwatson, i know it's possible to use mismatched versions of some packages like libgdiplus, but i don't know if there are side-effects [23:39] directhex: do you want to keep bug 300133 open to track this, or shall I close it? [23:39] Launchpad bug 300133 in mono "Mono 2.0.1 package (triggers major packaging transition, please read in full)" [Undecided,New] https://launchpad.net/bugs/300133 [23:39] cjwatson, close it - i'm tracking it on wiki.debian.org, and i don't want to crapflood people who aren't me by tracking 90 packages from one bug [23:40] ok [23:40] cjwatson, thanks very much for your help [23:41] directhex: done [23:42] directhex: xsp/mod-mono/mono-debugger now or later? [23:42] cjwatson, is dep-wait a problem in the real archive? [23:42] in what sense? [23:43]