[00:00] Oh, so it does actually redirect to the right place. [00:00] yeah [00:37] Keybuk: would your plan help upstreams who want to just be able to maintain their packages in Ubuntu? [00:38] for instance could they be given their own seed for there little set of packages? or does that become waaay to many seeds [00:40] I suspect my plan would actually involve some kind of Soyuz feature where it had a link between people and source packages in distributions [00:40] so you could set a maintainer team for any package [00:40] and we'd keep them up to date through the seeds [00:40] so in theory, a non-seeded package could be owned by a team consisting of the upstream and ubuntu-dev, yeah [00:40] *shrug* [00:40] or you could just make a small seed :) [00:41] but yes [00:41] I know Mark was keen on allowing upstreams to have a sane path for uploading their packages [00:41] the idea is to make it easier for people to start contributing to Ubuntu on a more limited set of packages than "here's 10,000" [00:41] and Debian seems to be doing similar stuff with Debian Maintainers [00:42] "here's 10,000" scares the shit out of me :P [00:42] oh come on, it's fun :-) [00:42] but also, we wouldn't want "maintainers" in the debian sense - which is why ubuntu-dev should be in all of the teams [00:42] yeah, that's why i'm motu but haven't uploaded a single package yet :P [00:44] Keybuk: exactly [00:44] Hm, why would a package FTBFS here without libxext-dev, but not in Debian? I thought our X stuff was fairly similar. [01:31] Fujitsu: for some reason, the Debian libx11-dev depends on libxext-dev and the Ubuntu one does not [01:32] slangasek, I was doing some goggling today and you can be mean :P [01:32] somerville32: why yes, I can :) [01:32] slangasek: Aha. Would that be a bug on our side? [01:33] Fujitsu: I don't know; I haven't looked closely to see if there's bugginess anywhere, or just a difference in how the packages are built [01:37] Fujitsu: it's not the first one.. i've a similar one this week, let's find it [01:38] Kmos: Not the first one of what? [01:39] [00:44] Hm, why would a package FTBFS here without libxext-dev, but not in Debian? I thought our X stuff was fairly similar. [01:39] it's xdemineur package [01:40] I know there are quite a number, and we carry diffs for several. [01:40] That being the only delta. [01:40] And Debian rejecting said delta when you (Kmos) forward it to them. [01:42] for example.. libx11 in debian experimental doesn't depends on libxext-dev, but the version at unstable depends on it [01:42] so, debian maintainer of xdemineur, updated the package and added libxext-dev to b-d [01:42] :)) [01:42] so we have synced it [01:43] Fujitsu: well, in general if a package references xext directly, and doesn't build-depend on it, this is a bug in that package regardless of whether libx11-dev should have a dep on libxext-dev. === DrPepperKid is now known as MacSlow [01:43] Fujitsu: so if Debian is rejecting these fixes, please point me at them :) [01:43] * Fujitsu digs up that bug. [01:44] Debian bug #455224 is an example of a rejection (one of Kmos', in fact) [01:44] Debian bug 455224 in bbkeys "Please add libxext-dev to build depends" [Normal,Open] http://bugs.debian.org/455224 [01:45] ah, well [01:45] Fujitsu: that one is very aggressive from Bruno :( it's one of the debian developers that doesn't care about ubuntu [01:46] Kmos: but it's a strategic error on your part to submit a bug to Debian saying "we did this in Ubuntu, please do it too" instead of explaining why it's also a bug in the Debian package :) [01:47] slangasek: you're right [01:48] i need to go.. 2 am here [01:48] cya [01:54] ok, Debian bug #455224 reopened with commentary [01:54] Debian bug 455224 in bbkeys "Please add libxext-dev to build depends" [Normal,Open] http://bugs.debian.org/455224 [01:54] slangasek: Danke. [01:55] * StevenK waits for the BTS to catch up [02:01] * persia admires slangasek's skill with a laser pointer [02:02] Hrm. Is the autosync likely to be run before DIF? [02:02] * persia hopes so, as otherwise DIF would already be in place. perhaps at DIF? [02:03] * StevenK waits for Bruno to reply to slangasek, "My packages don't have bugs. This is Debian." [02:07] StevenK: that would be unfortunate, because then I would have to give somerville32 another example of my meanness [02:08] Haha [02:08] If a conffile gets renamed, that should be handled in preinst, right? [02:08] * soren is allowed to ask stupid questions at this hour [02:08] soren: in order to allow the dpkg conffile handling to trigger during the unpack phase, ye [02:08] hey soren [02:08] s [02:08] zul: Ahoy. [02:08] slangasek: Maybe you could take a leaf out of my book and reply back, "Bruno, I am going to eat your liver." ? :-P [02:08] slangasek: Thanks. === mjg59` is now known as mjg59 [02:10] now, which was the package I NMUed where I handled conffile migration on downgrades.. :) [02:11] Hah [02:16] \o/ multipath-tools uploaded. [02:16] * soren needs sleep... badly. [02:22] lamont: looks like gettext hasn't been uploaded yet? [02:33] Does the linux packages not use a patch system? [02:33] somerville32: It's in git. [02:33] I mean, our linux packages [02:33] or do we have it in bazaar or something? [02:33] It's also in git [02:34] Why are we using git? [02:34] Because upstream does. [02:34] for easier interop with upstream [02:34] Where is it hosted? [02:35] kernel.ubuntu.com [02:35] https://wiki.ubuntu.com/KernelGitGuide [02:35] * Fujitsu points at https://wiki.ubuntu.com/KernelGitGuide [02:35] Blergh. [02:35] :) [02:35] * somerville32 goes to patch the kernel! :) [03:42] slangasek: it was a bad day. doing gettext now. === panchoat is now known as iE17 [04:14] slangasek: did someone do libtool already, I wonder? [04:15] gettext testbuild running === asac_ is now known as asac === calc_ is now known as calc === Shely is now known as Schneeflocke [06:17] lamont: libtool is still on the menu [06:17] but it's a -1 increment, so I'm not too worried [06:35] what is up with the gnome-orca package in hardy? [06:35] suckers been broke for weeks [06:51] Howdy everyone! [07:03] TheMuso: do you merge espeak as well? === doko_ is now known as doko [07:06] Hi all! [07:14] doko: I don't see the point, as we've essentially got the same changes as Debian. I'm going to work with Debian for the next upstream release so we can just sync. [07:15] TheMuso: ok, thanks === antdedyet is now known as jtraylor === jtraylor is now known as antdedyet === antdedyet is now known as jtraylor === jtraylor is now known as jonathant === jonathant is now known as jtraylor === jtraylor is now known as antdedyet [07:39] Good morning [07:41] good morning [07:42] Hey dholbach. [07:42] Hi [07:42] heya TheMuso, hey ion_ [07:42] hey dholbach [07:42] hi kagou === Shely is now known as iSchnee === pbn_ is now known as pbn [08:14] Good morning [08:14] hey pitti, mvo [08:15] hey Burgundavia! [08:16] Morning pitti [08:17] hey pitti === \sh_away is now known as \sh === \sh is now known as \sh_away === DrPepperKid is now known as MacSlow [08:53] Greetings everybody! [09:04] hi MacSlow [09:04] Tag pitti [09:06] dholbach: do you mind if I do your gnome-mag merge? [09:07] mvo: not at all [09:07] * dholbach hugs super-mvo [09:07] thanks dholbach! [09:07] * mvo hugs dholbach [09:07] :-) [09:11] is there any one person that takes care of abiword? [09:12] mvo: I'm already half way hrough it, if you've got more important things to do, I can finish what I've started. [09:12] through it [09:12] TheMuso: sure, I leave it then [09:13] I am delighted by the BT engineer's disbelief at how my house is wired [09:13] Keybuk: the sheer number of devices or the amount of network cable? [09:14] the fact that apparently one of the last endless procession of BT engineers wired it so that the phone line comes into the master socket, goes upstairs to another socket there, and then comes back to the master socket again [09:14] That is crazy. [09:14] wow [09:17] lamont: did you look at bug #175775 or did you re-do the gettext update? [09:17] Launchpad bug 175775 in gettext "Please merge gettext 0.17-2 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/175775 [09:17] anyone working on the hotkey-setup merge? [09:18] hi mvo [09:19] dholbach, Aaaalter... Schwede! :) [09:19] TheMuso: Hi there; just sent a proposal for promotion to main of colorblind; I heard you were interested with this subject [09:20] lool: Ah right. Funny you should mention that, as if colorblind was in main, gnome-mag could be synced. :) [09:20] As the only ubuntu change is to not build against it. [09:20] TheMuso: It's because I wanted to work on the gnome-mag merge that I noticed actually ;) [09:20] hey MacSlow [09:21] So, depending on how quick a turn around an MIR for something like that is, I may wait on the merge, and just sync when colorblind is in main. [09:21] lool: Right. [09:21] lool: Ubuntu already has the same upstream as Debian, so I think waiting for colorblind to come in and syncing makes more sense actually. [09:31] .c [09:31] ugh typo [09:59] cjwatson: do we use the dash udeb? it got removed from debian [09:59] I thought we used busybox? [10:00] I think so too, but I'm not sure enough [10:00] mvo: Me either. [10:03] Not available because: [10:03] Builder returned BUILDERFAIL when asked for its status [10:04] kohnen builld machine [10:04] *buildd [10:04] infinity: you already know about this error :) [10:04] Kmos: Yeah, but it's 3am where infinity is. [10:05] oh god :( sorry [10:05] I doubt an IRC message will get him out of bed. [10:05] me too [10:05] StevenK: aren't you in the same TZ as him? === \sh_away is now known as \sh [10:51] dholbach: the vinagre sponsorship request is on hold because it requires a new gtk-vnc and this one is buggy, should I do something to get vinagre out of the "waiting on sponsor" stats? [10:54] seb128: no that's fine, I'll just ignore it on the list as I know you're handling it - that's fine [10:54] if you want, you can unsub the sponsors team [10:54] ok [10:54] but it's not necessary, I'm sure it'll be done soon [10:55] yeah, I'll not unsubscribe [10:55] the things is that the gtk-vnc upstream tarball is buggy === pedro is now known as pedro_ [10:55] I'm wondering how the guy who did the update managed to build it [10:55] oh nice [10:55] my guess is that he didn't even try [10:55] because ./configure doesn't work, the tarball lacks an install-sh [10:56] ARG [10:56] and he did a bunch of other updates, I'm wondering if he's testing anything [10:56] best to add that comment to the bug [10:56] or just running dch and opening bugs [10:56] I did, waiting for a reply now [11:01] dholbach: will you care about your three outstanding merges, or shall I help you? [11:01] pitti: the platform team splitted the remaining merges during the meeting yesterday [11:01] ok, thanks [11:01] thanks :) [11:04] we might actually be able to sync libgnomemm2.6, but I didn't check the small patch details [11:07] pitti: lool said he would do this one, you might want to ask him if he had a look yet [11:08] ok [11:11] Keybuk: python-distutils-extra is a nice corner case; 1.91ubuntu3 is in Debian unstable, so the package is actually synced; could MoM be taught to not display those? [11:12] not easily [11:15] ok; easy enough to ignore === pedro is now known as pedro_ [11:27] * pitti holds up a transparent "geser for core-dev!" === cjwatson_ is now known as cjwatson === \sh is now known as \sh_away === cprov is now known as cprov-out === kiko is now known as kiko-fud === Kmos_ is now known as Kmos [13:25] So MeMaker is getting REALLY busy and we need a list... how can this happen? Does ubuntu provide any, or is there some place we can use to make a list? === cprov-out is now known as cprov [13:31] <_MMA_> encompass: A list of? [13:32] _MMA_: mail list, sorry for not being clear enough [13:32] encompass: Ubuntu has mailing lists, but only for Ubuntu. Do you mean for https://launchpad.net/memaker? [13:33] persia: yeah... things are getting very busy and we need to get things organized before we get burned out [13:33] <_MMA_> encompass: PM. [13:34] encompass: I think it might be tricky to get a mailing list on lists.ubuntu.com (but I'm not an expert). You might ask in #launchpad if there is any support there. [13:34] persia: thanks I will [13:35] encompass: Good luck. [13:35] re === se2 is now known as seb129 [13:35] re [13:36] I've issue with dapper being very slow to boot on a recent enough computer (PIV 2.4GHz), each boot line is taking some seconds [13:36] did anybody already had a similar case or any idea on what could create that and fix it? [13:36] windows works correctly on the box [13:36] debian has the same slow boot issue [13:37] the issue is not only at boot, it's a slow when using [13:37] seb129: it's very disconcerning when you have a off-by-one bug in your nick. [13:38] Bwahaa [13:39] Mithrandir: write to the correct nickname I'll read it anyway :p [13:41] seb128: I applied our patch to gettext 0.17-2 [13:43] ok, nobody has an idea about that? [13:45] * lamont notes that someone bumped kde up to 5000 in the queues... I guess that means they're done uploading kde 16 times. :-) [13:45] lamont: no, just parts of it sorry [13:45] lamont: but i've put in the hope of that, yes. [13:45] lamont: whether the uploaders do it is another story, perhaps. [13:45] and the fact that hppa hasn't launched a build in about 12 hours means that it's academic until we figure that out [13:46] Hobbsee: given that pretty much any package whose name starts 'kde' takes 1-5 hours to build, and the burstiness of the uploads, I have been known to smack them down to a build pri of 300 so that hppa can get through the queue [13:46] lamont: by all means, but make sure the base packages get built before the rest do. [13:46] OTOH, it's only fair to let them in sometime, and besides, LP keeps reprioritizing them. [13:46] which is why some of them got bumped in that order. [13:47] ah, makes sense... so they don't do versioned build-deps either, eh? [13:47] well, sure they do [13:47] but LP of course goes and tries the others, before the base ones. [13:47] which still takes time and such [13:51] hi, is it normal that there is no more usbfs mounted on hardy? [13:52] bigon: Mostly. There's a /dev/usb/ tree that contains much of that information. [13:52] bigon: not just since hardy; we got rid of that in feisty or so [13:53] * persia thought it was early gutsy [13:53] bigon@imladris:/dev/usb$ ls -la [13:53] total 0 [13:53] drwxr-xr-x 2 root root 60 2007-12-13 07:42 . [13:53] drwxr-xr-x 13 root root 14420 2007-12-13 14:52 .. [13:53] crw-rw---- 1 root root 180, 96 2007-12-13 07:42 hiddev0 [13:54] there is nothin usefull in /dev/usb [13:54] bigon: My mistake: /dev/bus/usb [13:54] persia: /dev/bus/usb doesn't exist [13:55] bigon: Does for me, but my system is known to be odd. [13:55] lsusb says nothing [13:55] mm [13:55] * bigon reboot [13:55] bigon: Do you have the right modules loaded? === dholbach_ is now known as dholbach [14:00] pitti, mvo: ping [14:00] hello Keybuk === kiko-fud is now known as kiko [14:05] ok it's a kernel issue with 2.6.24 [14:05] with 2.6.22 I get /dev/bus/usb, with 2.6.24 i don't === Kmos_ is now known as Kmos [14:16] bigon: Likely a udev / kernel coordination thing. Do you get /sys/bus/usb? [14:18] that's correct === \sh_away is now known as \sh [14:19] Keybuk: Is there another transition planned for that information, or is this just expected hardy breakage while development is underway? [14:20] ? [14:20] it's expected breakage for running non-default kernels ;) [14:21] Keybuk: Ah. Right :) [14:21] the userspace bits haven't caught up yet [14:37] persia: yes I have a /sys/bus/usb directory [14:37] bigon: Then the kernel is doing it's job. udev should catch up soon (likely around the same time as linux-meta) [14:38] ok [14:38] thx [14:43] * Riddell bigs up Kubuntu Tutorials Day in half an hour in #kubuntu-devel https://wiki.kubuntu.org/KubuntuTutorialsDay [14:43] * dholbach passes on the message :) === kiko is now known as kiko-phone === cprov is now known as cprov-lunch === Hobbsee_ is now known as Hobbsee [15:17] soren: so, does the consolekit upgrade fix your issue? [15:18] pitti: can you give a build retry to gdm on the archs where it didn't build? [15:19] seb128: done [15:19] pitti: thanks [15:25] seb128: I haven't tried it yet. I'm a few days behind on updates on this box.. [15:25] soren: ok [15:49] hi, is there people involve in the rt kernel? [15:51] <_MMA_> wip: #ubuntu-kernel is the place. [15:52] _MMA_: thanks === cprov-lunch is now known as cprov === \sh is now known as \sh_away [16:30] mvo: hm, your python-apt merge looks like it shuold have been a sync? [16:30] pitti: it needs to build against the right version of apt [16:30] pitti: but yeah, its *very* close [16:31] mvo: ah, just b-dep version change? [16:31] well, that's just a timing issue :) but nevermind [16:35] pitti: heh :) === cpro1 is now known as cprov [17:20] lamont: can you give-back librpcsecgss and biloba? (FTBFS due to chroot problems on hppa) [17:21] geser: are they chroot-problems, or are they build failure? [17:23] lamont: both are CHROOTWAIT: http://launchpadlibrarian.net/10192942/buildlog_ubuntu-hardy-hppa.biloba_0.4-2_CHROOTWAIT.txt.gz and http://launchpadlibrarian.net/10374771/buildlog_ubuntu-hardy-hppa.librpcsecgss_0.17-1ubuntu1_CHROOTWAIT.txt.gz [17:24] there are 3 that are chroot-failure, I'll give all 3 back once we make sure it's working again [17:24] ok and thanks [17:28] mvo: any idea what might cause -rw------- 1 root root 4,0G 2007-12-13 06:39 /var/log/apt/term.log [17:28] ? [17:31] is DIF already in effect? [17:34] lamont, mind give-back yorick-curses yorick-hdf5 yorick-imutil yorick-soy yorick-yeti ? [17:35] DktrKranz: architecture? [17:35] Mithrandir: I'm gonna bet "something looping asking a question." How'd I do? [17:35] lamont: not too bad, I believe. [17:35] ^5 [17:36] lamont, each for yorick-yeti, lpia and hppa for yorick-curses yorick-hdf5 yorick-imutil yorick-soy [17:37] lamont: it's filled with ^G, though, which is special [17:37] oh... loop of beeping. cool. [17:37] for (;;) { printf("\a\n");} [17:38] indeed [17:38] if { for (;;) { printf("\a\n");} } [17:40] DktrKranz: it'll take me a bit - I need to go heads down on something for about an hour and a half or so, it'll be top-of-list after that (any and all yorick-* packages on any architecture that are failed and current) [17:40] * lamont iconifies xchat [17:40] lamont, no hurry. thanks. [17:50] my daughter has reviewed "Ubuntu for non-geeks, second edition": "The back of the book is completely unhelpful. It tells us nothing of why the walruses are in the cover art." [17:59] hello. need to use gtk glib functions, but can't seem to find a package named glib or import library. What's the package name in Ubuntu please? [18:01] Asulao: libglib2.0-dev [18:01] pochu: sorry I didn't explain... I want to use glib from python [18:02] have gtk installed, but can't seem to find glib functions (if they do exist) [18:02] pygtk [18:03] Asulao: then probably python-gtk2 [18:04] geser: python-gtk2 does not contain any files with glib in their name [18:04] geser: I do have that installed, but can't seem to find a glib.pyc or the sort. [18:04] nor documentation for the glib module [18:05] Asulao: what functions do you need exactly? [18:05] g_timeout_add and so [18:07] I think you should use gtk.timeout_add [18:08] that's what ggogling suggests anyway [18:08] *googling [18:08] Asulao: anyway, I think #pygtk on irc.gnome.org would be a more appropriate place to ask [18:09] ok. great. I'll go there. many thankses. :-) === pedro is now known as pedro_ [18:45] Mithrandir: woah, that is impressive. what does it look like inside? [18:46] Mithrandir: and where do you see it? [18:53] mvo: on a gutsy amd64 server. It mostly contained ^G-s [18:54] looks like the last dash upgrade broke the sparc buildd :( === Kmos_ is now known as Kmos [18:56] geser: yep.. [18:56] http://launchpadlibrarian.net/10890584/buildlog_ubuntu-hardy-sparc.nginx_0.5.33-1_CHROOTWAIT.txt.gz [19:03] geser: ohhhh [19:04] geser: Mithrandir is fixing it [19:05] Mithrandir: could I get access to a compressed version? I assume it compresses quite well ... === pedro is now known as pedro_ [19:09] mvo: sorry, I needed the disk space so I nuked it. :-( [19:09] mvo: I'll make sure to tell you if I see it again [19:09] Mithrandir: ok, sorry for the trouble :/ [20:16] cjwatson: where do I submit a patch for bug #38442 ? [20:16] Launchpad bug 38442 in ubiquity "Ubiquity dialogues too large for 800x600 display" [High,Confirmed] https://launchpad.net/bugs/38442 [20:21] CarlFK: attach it to the bug [20:22] thanks [20:23] CarlFK: I love you [20:23] well, lets see if it is acceptable before we rush into things :) [20:30] can't this just be fixed in the glade file or something [20:30] oh and btw [20:31] CarlFK: on a seperate note [20:31] CarlFK: gtk+ devel had patches for natural size for widgets [20:31] *has [20:31] maybe these could be an improvement too? [20:33] CarlFK: please take a look at: http://mail.gnome.org/archives/gtk-devel-list/2007-November/msg00145.html [20:33] (and following messages) [20:33] looking [20:33] slangasek: I can write the release notes for alpha2 [20:34] cjwatson: ping [20:36] I'm trying to rebuild my hardy pbuilder tree, however when I run `sudo pbuilder --create hardy`, I get this error: [20:36] The following packages have unmet dependencies: [20:36] aptitude: Depends: libapt-pkg-libc6.6-6-4.5 but it is not installable [20:36] E: Unmet dependencies. Try using -f. [20:36] any ideas what's wrong? [20:37] Burgundavia: yes please :) [20:37] Burgundavia: but where is the camera that lets you see I was just writing mail to ubuntu-marketing? [20:38] slangasek: don't need a camera. I have a direct brain feed of every Canonical employee [20:38] is that what that tickle is [20:38] heya tor [20:38] heya tormod [20:38] hi bryce [20:38] slangasek: send the email anyway, it will help me remember to do it [20:39] Burgundavia: right-o [20:46] any archive admins hiding around here? we are having problems with hardy and main...can't pbuild with hardy, not can we update hardy pbuilder...404 on main [20:47] bryce: a new apt in hardy, all reverse depends needs to be rebuild [20:49] geser: ah, is this something I can work aroudn on my end, or just wait for it to finish? is there an eta known for when it'll be working? [20:50] bryce: looks like you need to wait for the next publisher run, see https://edge.launchpad.net/ubuntu/hardy/+source/aptitude/+builds [20:50] thanks === warp10_it is now known as warp10 [23:19] Can somebody please decide if Gimp final (2.4.2) should go through -updates/SRU or -backports, please? See bug 157642 and bug 164795. 2.4 is a bugfix only branch and users are quite embarrassed to have a buggy rc in gutsy. [23:19] Launchpad bug 157642 in gimp "gimp 2.4 *final* in gutsy" [Undecided,New] https://launchpad.net/bugs/157642 [23:19] Launchpad bug 164795 in gutsy-backports "Please backport gimp 2.4.2 from hardy to gutsy" [Undecided,New] https://launchpad.net/bugs/164795 [23:19] blueyed: what is the nature of its bugginess? [23:19] I still note that "buggy RC" is yet to followed up with other bug reports. [23:20] zless /usr/share/doc/gimp/NEWS.gz for a start [23:24] It might be OK to decline it for SRU, but somebody should do so. [23:25] blueyed: You still haven't answered my question. [23:25] StevenK: I don't see any question from you. And I've provided a list of bugfixes, as you've requested. [23:26] blueyed: Ah, I wasn't talking about bug fixes, I was talking about bug reports on Launchpad. [23:26] In fact, I said "bug reports" [23:29] StevenK: An unreported bug which got fixed is no bug? Anyway, I've not triaged gimp yet much (but enough to have seen the cry for an update). I'm just asking for a decision. === cheguevara_ is now known as CheGuevara [23:30] I'm yet to be completly convinced aside from users saying "How unprofessional is shipping an RC of gimp?" [23:32] blueyed: well if there's a huge shotgun list of bugs/defects that users are experiencing, then I think the argument can be made, but I don't see that so far.... [23:32] Exactly my point. [23:32] blueyed: it'd also depend on how much testing the new version has gotten, and how much the interface/plugin-API changed [23:33] I understand. [23:33] jdong: it's bugfix-only. [23:33] how large is the debdiff between the RC and final? [23:33] the one from hardy? [23:34] well... I guess? [23:34] Yes, but saying it's bugfix only and pointing at real, Confirmed high-impact bugs on Launchpad are two *very* different things [23:35] 881 files changed, 81411 insertions(+), 105144 deletions(-) [23:35] Right, "bug fixes" [23:35] jdong: the debdiff is 50M, but most is moved changelogs and .po stuff. [23:36] holy crap [23:36] blueyed: ok, do you know what number of bugs people are actively experiencing in our RC of gimp? [23:36] oops, sorry there [23:36] blueyed: if it's a small SRU-able number I think they should be individually targeted.... this big of a change is hard to argue for -updates unless the package is totally dysfunctional to begin with [23:36] (well all releases of gimp are dysfunctional in my hands but that's a different matter :D) [23:37] jdong: yes, I understand. I'll then just add a comment to the -updates-bug and ask people to name/triage real bugs. I'm not a gimp user really either. [23:38] we should take care of the SRU bug though [23:38] blueyed: right, I think that's a good start. Let's estimate the impact then decide what needs to be fixed. [23:38] we tend to leave things linger [23:38] +ing [23:38] StevenK: I have "1009 files changed, 606889 insertions(+), 371127 deletions(-)" btw (more) [23:38] I will deal with it when seb128 has turned up and I've spoken to him about it. [23:38] haha [23:38] "Attached is the debdiff for review....." :D [23:39] Oh god, we aren't using that [23:39] I think this beats my Xgl debdiff record :)