=== superm1_ is now known as superm1 [01:27] * Hobbsee waves === mneptok_ is now known as mneptok [01:59] * emgent heya === doko_ is now known as doko [03:43] * emgent heya [03:46] * Hobbsee waves [04:18] <_MMA_> Might be better to poke around later but does anyone have a clue where to look for documentation on JeOS? [04:34] I am using ati driver 7.11 and I cant change gamma in games [04:35] f0rqu3: Have you reported a bug? [04:35] no [04:36] f0rqu3: OK. Is it a regression from the previous behaviour, or do you just need help with the configuration settings? [04:36] Hardy seems to have 7.1.0 [04:36] In that case, maybe we can't do anything :( === stu1 is now known as stub [05:05] ion_: hardy has 8.42.3.... [05:06] ion_: 7-11 is actually 8.43.3 [05:06] and home of delicious iced soft drinks! [05:06] both versions are umm... crap. But anyway, too late tonight for me to gain blood pressure for AMD/ATI incompetence and broken promises [05:07] Hurrah. We can do something. Still leaves open the question of whether it's an answer or a bug. [05:07] persia: most people using 7-11 are reporting it represents no change from the hardy 8.42.3 version [05:07] so I would not expect that version bump to solve any problems [05:08] a cursory examination by me shows no difference except a broader PCI ID whitelist, i.e. more supported chipsets [05:08] jdong: Right, but we can accept bugs and answers for 7-11 (8.42.3), whereas we can't for third-party stuff. [05:08] still serious problems with AIGLX performance, xvideo flickering, memory leaks. [05:09] persia: I'd expect 7-11 (8.43.3) to be in Hardy soon-ish... but IMO both would be identical releases as far as bug triaging goes, so let's get a head start on ATI bickering ;-) [05:09] jdong: Any memory leaks as cool as nvidia's TFP leak? [05:09] RAOF: meh about 500MB in the course of one day [05:09] RAOF: not assigned to any app, seems like the leak is somewhere in kerneldom [05:09] Ah. Nevermind. I though 42=43 for some reason. We can't support it. Alas. [05:10] persia: meh what could we support in fglrx anyway? Nice soft tissues and hugs? :D [05:10] jdong: Ah. Just some random leak, rather than "anytime you need more texture memory we'll take it from the compiz process & never release it". [05:10] f0rqu3: I'd recommend using the phoronix.com forums for questions related to ATI's fglrx driver -- seems like most people knowledgeable with it hang out there. [05:11] jdong: I like to think we can provide help, and also fix issues in the packaging, even for binary blobs. [05:11] RAOF: right, just some random leak that affects some midlevel X-series PCI-X [05:11] persia: I envy your optimism :) [05:11] thanks I was at phoronix [05:11] no answer [05:12] going back to 8.40 [05:12] f0rqu3: I don't think that'll work on Hardy, our X server is too new. [05:12] f0rqu3: I did the same.... 8.42+ was lasrgely a disappointment [05:12] RAOF: did he ever say he was on hardy? [05:12] *reads scrollback* [05:12] jdong, gamma was working? [05:13] jdong: Uh, no. I just kinda assume a default of Hardy unless otherwise specified :) [05:13] f0rqu3: I don't know. The only game I played was UT2004 and it has gamma settings built into the game's settings [05:13] those did work [05:13] RAOF: ah :) [05:13] xgamma -g 1000 [05:14] nothing happens here [05:14] * jdong not at his fglrx machine currently [05:14] * jdong tries to back away from it as much as possible :D [05:49] any idea why compiz.real would slowly eat up all available memory while gnome-screensaver was running? [05:49] as of recently. This wasn't happening before last week. I'm assuming it was an update, but neither gnome-screensaver nor compiz fusion seems to have a new version listed in /var/log/dpkg.log [05:50] How about your GL drivers? [05:50] shouldn't have been, but I'll check. My card's old enough that nvidia's not supporting it with their new drivers [05:52] Hmm.... it's possible. the driver version number didn't go up, but the ubuntu package revision number went from 14.9 to 14.10 two weeks ago. Wonder what they changed, and if it's relevant [05:55] persia: d'ye ken how I might find the original version of the package? I'm assuming it's not hosted on any of the mirrors anymore [05:56] pipegeek: https://launchpad.net/ubuntu/+source/ should have some pointers. [05:57] page not found. [05:58] found it [05:59] wait, no, no I haven't [05:59] it's not listed there :-\ [06:00] hey, when i run alacarte i get "ImportError: no module named glade". i have asked this in #gnome & #ubuntu. have googled around cant find anything. just woudering weather its a known bug ? [06:02] mwansa: you broke something, there should be no way to have alacarte installed and not have python-glade2 === lc is now known as lcstudio === thegodfather is now known as fabbione [06:19] pitti! [06:20] hey pitti! [06:22] Good morning [06:23] pitti: Do you think it's safe to NBS out all of the zero sized things on the list? [06:24] StevenK: most, probably; some might actually be FTBFS or needs-build [06:25] I might dig further and feed you lists, then [06:25] pitti: Speaking of lists, bug 149275 :-) [06:25] Launchpad bug 149275 in tasks "First cut of source packages for -mobile promotions" [Undecided,New] https://launchpad.net/bugs/149275 [06:26] StevenK: ah, right [07:40] hey, pitti. [07:41] * Hobbsee waits for pitti to stop idling. [07:42] * pitti hugs Hobbsee [07:42] * Hobbsee hugs pitti back :D [07:42] Hobbsee: I'm not idling :) [07:42] pitti: i fixed some bits in your buildd.py [07:42] oh, great [07:43] what? [07:44] pitti: it now lets you give stuff back if it's in depwait (in case you want to shove stuff thru in a certain order), and failed to upload, and doesn't die if the source package is not in ubuntu at all. [07:45] Hobbsee: ah, did you introduce an option for the depwait change? [07:45] (the previous error checking only would bail if it was in ubuntu, but not in that particular release) [07:45] pitti: yes [07:45] since it's something you don't normlaly want to do [07:45] to cue something out of depwait, so it gets queued to build RSN? [07:45] s/cue/shove/ [07:46] right, because it should retry automatically [07:46] sure, but if you want to step it through sensibly. [07:46] * Hobbsee found it useful, anyway. [07:46] i. e. I don't want to trigger it without checking previously [07:46] Hobbsee: right, it is [07:46] but for the occasional "pitti: please retry foo" it isn't (since I don't want to check it closely) [07:46] * Hobbsee thought people ran status first all the time, anyway [07:47] Hobbsee: there are some people I trust enough to risk the waste of some buildd time :) [07:47] * pitti hugs geser [07:48] pitti: FWIW, http://wedontsleep.org/~sarah/buildd.py - feel free to change it as you wish [07:49] Hobbsee: I'll revert your cookiefile glob change [07:50] pitti: oh, yeah, sorry :) [07:50] Hobbsee: ah, you don't have my fix yet for version numbers with a + in it [07:50] pitti: no, i was wondering about that. [07:50] where is it? [07:50] ah, found it, i thnk [07:50] and I don't see an option for retrying depwaits [07:51] p.u.c./~pitti/scripts/ [07:51] pitti: status == 'Dependency wait' [07:52] right, but it's not an option, it's done by default [07:52] i thought i said that, yes [07:54] * pitti commits and scp's it back to p.u.c. [07:54] Hobbsee: thanks! [07:56] You guys need a bzr branch [07:56] :-P [07:57] I have my ~/bin in bzr, just not publicly on LP :) [07:58] Heh [08:05] good morning [08:06] Hi [08:06] Hi dholbach. [08:07] hey Fujitsu, hey ion_ [08:08] hey seb128 [08:08] Hi dholbach [08:08] hey dholbach [08:08] Bonjour seb128 [08:08] Hey pitti [08:10] heya pitti [08:10] * ion_ faintly recalls a bit of a Monty Python sketch of people greeting everyone. [08:10] hey ion_! [08:10] Howdy pitti [08:11] Hi Bruce [08:15] pitti: when you tag photos you usually decide what categories to use, why do you think that's not working correctly? [08:16] seb128: I didn't say that tagging photos doesn't work correctly? [08:16] I don't know how it works in f-spot etc., since I don't tag my photos [08:16] but WDYM? [08:17] pitti: well, you wrote that you don't believe in tagging [08:17] ah, right, there (but that's just my personal preference, I wasn't saying that it cannot work in general) === Traxer is now known as Traxer|on [08:17] but tags can usually be defined completely arbitrarily, which means that there is no common standard for them [08:17] pitti: oki === Traxer|on is now known as Traxer [08:18] and thus it's hard to actually use them [08:18] well, usually you tag your photos yourself so you decide of what labels make sense to you [08:18] In the case of personal photos that is a feature. In the case of shared bugs, perhaps less so. [08:18] so especially on flickr and bug trackers I do think that this is a problem [08:18] well, who cares about tags in launchpad [08:18] * persia cares [08:18] you use some you find useful, they are for you [08:19] persia: yeah, in your personal photo collection you are probably disciplined enough [08:19] those are not meant to be universal [08:19] I tag desktop bugs I want to look at for the next lts for example [08:19] some tag the build issues [08:19] seb128: right, but as the guys pointed out they create noise in the tag list, bug mail, etc. [08:19] seb128: But when you tag a bug, it sends a message to all bug subscribers, and some subscribers might not like your tags. [08:20] well, having everything listed in an UI error [08:20] persia: that would be a launchpad bug [08:20] yep; sorting those out in the UI is a great and simple solution IMHO [08:20] seb128: OK. I'll accept that. [08:20] that doesn't mean you should stop people using tagging their way [08:21] * persia suspects it's easier to ACL tag lists than to fix the UI and notification issues. [08:21] pitti: so now if I want to tag gvfs switch issues I need to ask for the tag to be defined somewhere? [08:21] we could just have usertags. [08:21] seb128: no [08:21] Mithrandir: Hard to share for teams [08:21] that creates extra work and will just make me not use tagging [08:21] seb128: but if you want to have a tag that is 'blessed' and gets into the dropdown list for commonly used tags, you need to ask [08:22] why do you need a dropdown list? [08:22] persia: No? Usertags means you have your own namespace, not that nobody can see your tags. [08:22] well, or the portlet, or whatever [08:22] just something to avoid seeing 2000 tags with 1980 of them being useless for me [08:22] Mithrandir: Hmm. I suppose teams could define team namespaces. Objection withdrawn. [08:22] why do you need a list? tags are defined by somebody who has an interest to use some tagging [08:23] persia: so I could tag all bugs whose bugnumbers are prime with "tfheen:prime" or whatever without it being annoying for anybody else, because they wouldn't see them. [08:23] seb128: of course it would be cool if everyone would see his own tags, but that's more complicated in LP, I guess [08:23] pitti: the issue is probably to list all of those, they should list none [08:23] seb128: but if nobody uses the same set of tags, what's the use of them? [08:23] seb128: I like lists because sometimes I want to share common tags when tagging a bug. [08:23] or only the one your subscribed to or are usingh [08:23] except for your own personal bug management, which could be done with more structured ways, too? [08:23] persia: there is hundred of valid tagging cases [08:23] Mithrandir: As long as the notification issue was resolved, yes. [08:24] seb128: Yes. [08:24] but if bug triagers should help with putting categories to buts, we need some common standards [08:24] we already do [08:24] we already have sru tags [08:24] persia: if you didn't subscribe to a namespace (or something like that), you wouldn't get notified about usertag changes. [08:24] if someone uses 'graphics', the next one 'picture-viewer', and yet another one the tag 'gthumb', that won't help anyone [08:24] there is ftbfs, needs-packaging, etc tags [08:24] Mithrandir: For the right spec, you're correct. [08:25] well, that's an UI probably [08:25] seb128: Right. Defined, agreed tags. The barrier can be low, but we've too many similar tags now. [08:25] seb128: right; and IMHO there's a difference in use cases and applicability for 'i-wanna-fix-in-my-next-upload' and 'patch' [08:25] when launchoad started using tags I read somewhere that they were going to display only the most used ones [08:25] which would filter all this user noise [08:26] * persia thinks that fell into the same bucket as "most recently joined groups" [08:27] persia: Heh. You mean just the first 5 alphabetically? [08:28] Fujitsu: Yes. [08:28] pitti: try to control what users are doing is likley going to be a constant battle on launchpad and lot of work too [08:28] There being more important bugs in LP that we'd all agree should be fixed first, and limited development time, little things take a while to happen. [08:29] pitti: much easier to just display the most commonly used tags which are likely the only clearly defined [08:29] seb128: I agree, that would help [08:32] hey mvo [08:32] hey seb128! [08:44] Greetings everybody! === \sh_away is now known as \sh [08:56] <\sh> moins [08:57] is there any kernel team member here? I'm trying to build a new flavour of the kernel and I was about to modify debian/binary-custom.d/myflavour/config.i386 when I noticed there is a "automatically generated make config: don't edit" at the beginning of the file. Where should I modify the config for my flavour? [09:00] hello everyone === glatzor_ is now known as glatzor [09:20] cjwatson_: I'm now happy with the SRU debdiff on bug 147800; do you have some minutes to ack the patch? or shall someone else review this? [09:20] Launchpad bug 147800 in cupsys "[Gutsy] : bluetooth printing was working but is not (at the beginning of september)." [Undecided,Confirmed] https://launchpad.net/bugs/147800 [09:21] cjwatson_: (rather, ack the SRU itself; I'm quite confident about the AA changes themselves) === Hobbsee_ is now known as Hobbsee [09:33] what's this on ubuntu-devel-announce? [09:33] someone who didn't follow the reply-to, it appears, and someone else who accepted the mail [09:33] Ah simply a moderation slip === cjwatson_ is now known as cjwatson [09:42] ArneGoetje: is the merge of ttf-arphic-uming still on your list? [09:43] pitti: I will build a new version anyways [09:43] ArneGoetje: right, but it should still be merged with Debian for mutual patch exchange [09:44] pitti: the new version goes into debian and ubuntu at the same time. [09:44] ah [10:00] pitti, hi [10:00] hi tkamppeter [10:20] pitti: Hi, doesn't dh_strip like it when a package uses debian/tmp for install? see http://launchpadlibrarian.net/10688624/buildlog_ubuntu-hardy-amd64.gtk-engines-mono_0.0.5-1build1_FAILEDTOBUILD.txt.gz [10:23] any xen feisty or gutsy git branches exist or not ? [10:25] geser: ah, seems, pkg-create-dbgsym doesn't get along with compat 3; I do have test cases for level 1 and 4, but apparently this is another corner case [10:26] hm, correction, I do have a test case for compat 3 [10:26] geser: can you please file a bug about this? [10:27] against pkg-create-dbgsym? [10:27] yes, please [10:28] it might very well be that this is actually a packaging error of gtk-engines-mono [10:28] but we should get along with those in pkg-create-dbgsym [10:33] pitti: bug #173631 [10:33] Launchpad bug 173631 in pkg-create-dbgsym "dh_strip if package uses debian/tmp for installation" [Undecided,New] https://launchpad.net/bugs/173631 [10:33] kernel-xen have a git repository for feisty and gutsy ? [10:35] thanks [10:38] Don't we have any cross compilers? I need a ppc compiler on i386. [10:43] soren: qemu? [10:44] geser: I'm not entirely comfortable build-depending on qemu :) === cjwatson_ is now known as cjwatson === pedro is now known as pedro_ [11:22] do archive admins receive emails sent to archive@ubuntu.com ? [11:23] norsetto: no [11:23] Ng: reads it, and steals it all instead [11:24] Hobbsee: naughty ng .... [11:24] norsetto: You may want ubuntu-archive@l.u.c [11:24] Ng: I'm having a problem with an upload, and replied to that address. Was the right thing to do or should I talk with, say, Hobbsee, about it? [11:25] persia: thats moderated I think? Seems I'm (quite rigthly) moderated everywhere :-) [11:25] norsetto: if you've replied to archive@ it'll have been eaten by the black hole of doom I'm afraid [11:26] norsetto: Moderated, but you can join. Also, moderators can be poked. [11:26] Ng: oh well, I'm not going in there .... [11:26] Ng: That sounds like a very silly address to have it come from, then... [11:27] haha, the black hole of doom :) [11:27] anyhow, what should we do when the tarball in debian and the one in ubuntu differs? keep fakesyncing ad libitum or ? [11:27] yes [11:27] norsetto: Keep fake-syncing until there is a new Debian upload. [11:27] persia: yes, thats the proble, upstream is no more so there won't be any new Debian upload I'm afraid [11:28] norsetto: In one case where upstream is no more, the Debian maintainer has grabbed some patches from the -users ML and made a new (false) upstream release to address that. Alternately, someone could re-host upstream somewhere. [11:28] norsetto: an archive admin might consent to removing the packge, so you could merge it with teh debian tarball. *shrug* [11:29] norsetto: become upstream and release a new upstream version. problem solved :) [11:29] Well, I've got my package ready but wanted to make sure it is the right thing to do to keep fakesyncing [11:29] * persia thinks that is an ugly solution [11:30] Err. I think removing & syncing is ugly. Becoming upstream is good. [11:34] Hobbsee: would that really work? as LP has to store the old tar.gz for the old releases and the new one with the same filename [11:35] geser: oh, there's a thought. er...it might. the old link to librarian would just get lost [11:35] unsure [11:36] * persia thinks pool would get annoyed [11:40] removing and syncing can easily break mirroring, so we won't do that === dholbach_ is now known as dholbach [11:41] cjwatson: in the spirit of making more things open w.r.t. release, where is the blacklist's bzr repo? [11:41] cjwatson: and why isn't it using LP? [11:43] hysterical raisins - it's just a local bzr repository on drescher, not pushed anywhere [11:43] I saw your comment the other day, but you weren't around to reply :) [11:43] I'll arrange to have it pushed somewhere more sensible [11:43] cjwatson: yeah, i don't live on irc all the time. i usually have a logger, though :) [11:43] seems logical for it to be on bazaar.lp/~ubuntu-archive [11:43] the actual files are public, so it wasn't a problem until recently ... [11:44] probably only wasn't because that didn't exist at the time [11:44] Keybuk: yeah [11:44] I think it did, but all of ~ubuntu-archive had drescher accounts :) [11:44] yeah yeah :) [11:44] turn it into a bind-checkout [11:44] cjwatson: the plebs don't. we know. but i'm not stepping out of archive yet :) [11:44] but then you'd have to make sure "bzr update" gets called somewhen useful [11:44] does anyone have a clue how to solve stuck loop mounts like: http://paste.ubuntu-nl.org/46671/ [11:44] ? [11:45] the awkwardness with moving it to LP is that we'd have to start editing it locally and updating on drescher, rather than editing and updating on drescher [11:45] since I bet ssh agent forwarding doesn't work to drescher, and certainly won't work once you've done sudo -u lp_archive -i [11:51] hm [11:51] ogra: does 'losetup -d /dev/loop0' help? [11:52] cjwatson, nope, because the stack still sits on top ... [11:52] /tmp/test1 is the unionfs mount [11:53] below there is /tmp/.test1-{ro,rw} [11:53] but there is nothing accessing /tmp/test1 anymore [11:53] can you clean up any parts of that stack? [11:53] nope [11:53] the toplevel is stuck [11:53] then you might be screwed :) [11:54] i can forcefully unmount the unionfs .... with the result that the loopdevice stays stuck [11:54] i.e. get rid of everything in mtab but that still hogs loop0 [11:54] forceful unmounting probably just means that userspace forgets about it but the kernel bit is still there [11:54] ltsp-image-shell is a script ... it works perfectly if i run it in a shell [11:55] its purpose is to run in an embedded pathon vte though ... [11:55] the process you showed in that paste looks like a kernel thread [11:55] as soon as i use it there i cant unmount the unionfs and get this strage effect [11:55] uuuh ... [11:55] i want a new keyboard ...(and new fingers ...grmbl) [11:56] perhaps 'sudo lsof | grep /tmp/test' to see if anything's still using that [11:56] * Hobbsee slices off ogra's fingers [11:56] Hobbsee: now for step 2 ... [11:56] * cjwatson passes the sewing kit [11:56] * Hobbsee can sew, but would prefer to use a sewing machine :P [11:56] ogra@laptop:~/devel/hardy/ltsp-image-shell$ sudo lsof | grep /tmp/test [11:56] ogra@laptop:~/devel/hardy/ltsp-image-shell$ mount|grep test [11:56] tmpfs on /tmp/.test1-rw type tmpfs (rw) [11:56] /opt/ltsp/images/test1.img on /tmp/.test1-ro type squashfs (rw,loop=/dev/loop0) [11:56] unionfs on /tmp/test1 type unionfs (rw,dirs=/tmp/.test1-rw=rw:/tmp/.test1-ro=ro,delete=whiteout) [11:57] intresting :) [11:57] lsof | grep test? [11:57] gains the result from the paste above [11:57] anyway, that's clearly what's keeping the loop device busy [11:57] OH !! [11:58] no its different [11:58] ogra@laptop:~/devel/hardy/ltsp-image-shell$ sudo lsof | grep test [11:58] nbd-serve 8075 nobody 4r REG 3,4 151134208 783528 /tmp/images/test1.img (deleted) [11:58] geez [11:58] aha [11:58] how does that happen [11:58] nbd shouldnt even know about it [11:58] didn't bind-mount /proc so it couldn't find the process to kill, maybe? [11:58] as in, is that nbd-serve running in the chroot? [11:59] no, i usually mount and unmount /proc chrooted ... [11:59] no, nbd-server is started by inted.conf usually [11:59] and there is no line at all for /tmp/images/test1.img [11:59] thats very strange [11:59] well, its my spare time project from the weekend ... i'll investigate more later ... back to regular work now :) [12:20] seb128: do you remember the reason why you moved the dbus HTML documentation from usr/share/doc/dbus-1-doc/api/ to usr/share/doc/dbus-1-doc/html/api ? [12:20] seb128: (just merging dbus and wondering about this delat) [12:21] delta, even [12:21] oh, sorry, seems you didn't [12:21] I was just confused: [12:21] -doc/api/html usr/share/doc/dbus-1-doc/api/ [12:21] +doc/api/html/* usr/share/doc/dbus-1-doc/html/api [12:30] doko: which is better, python-support or python-central? [12:31] Package: python-central [12:31] Maintainer: Matthias Klose [12:31] ;-) [12:31] Riddell: you'll get a biased answer from me ;-P [12:32] doko: think of it this way... [12:32] doko: if you say py-central, he's going to ask you how to use it [12:32] doko: is there a quick guide to how to use it? [12:32] doko: if you say py-support, he'll go and bug someone else. [12:32] doko: pick wisely :) === dendro-away is now known as dendrobates [12:43] enrico: have you tried libwibble with gcc 4.3? [12:45] In #ubuntu-motu we're discussing analysis of the packages that haven't been rebuilt against the current toolchain. What do buildd-admins / archive-admins think about a scripted upload rebuilding these rather than a manual effort? [12:46] persia: what would be the need for that? [12:46] persia: what numbers are involved? [12:46] Riddell: I've found at least some packages that FTBFS when they haven't been updated for the most current release. [12:46] and yes, there should be an actual need [12:46] persia: it's reasonable to do a test-build but not actually upload the results [12:47] cjwatson: We're currently looking at about half the archive not yet built for hardy, although we're working to refine the numbers. [12:47] a scripted upload of half the archive is definitely unacceptable [12:47] by all means, test-build and fix the ones that fail [12:47] but there's no need to put that kind of load on mirrors just for a test-build [12:47] We've done half the archive in the last 7 weeks, so if we paced it, I wouldn't expect too much impact on development. [12:47] Further, it's not just test-build: we get the new CDBS stuff, etc. [12:48] for a relatively small number of packages, yes [12:48] not to mention the stress that would be put on the buildds [12:48] I'm not denying that there are advantages, just saying that dumping in new versions of half the archive in one go is not kosher [12:49] the buildds, as pitti says, are already having serious trouble keeping up [12:49] At. I don't mean one go. I was thinking something like 500 a week. [12:49] persia: please keep in mind that buildds never dropped below 2900 needs-build records ever since we opened hardy [12:49] persia: it just sounds gratuitous to me [12:49] persia: but what's the point in rebuilding a working package? [12:49] pitti: Yes, but most of that looks like it's one arch. [12:49] pitti: yeah, but how much of that refers to arches like hppa, and how much of that is actually hardy? [12:49] persia: after all, the pool structure was designed to avoid this kind of thing [12:50] (and how much of it is not superceeded source, that has never even tried to be built?) [12:50] Hobbsee: I don't know exact numbers [12:50] pitti: To be able to support it. There were a few packages in feisty that I needed to fight with quite a bit to get to compile for either feisty or gutsy, but I don't touch that many packages. [12:50] pitti: i386 was at 0 last night. *shrug* [12:50] pitti: i'ts the belated arches, iirc [12:50] persia: it is a bug if packages do not test-build successfully; you're entirely welcome to file those and have them milestoned for hardy [12:50] persia: that still doesn't answer the question why all packages need an upload [12:51] instead of just fixing the ones that FTBFS [12:51] pitti: I agree about pool: I only think it's worth it because it's LTS. [12:51] persia: why is it worth it? [12:51] buildds and mirrors aside, I fail to see the need [12:51] pitti: dbus, you need to install things to the standard location so devhelp find those [12:51] there are clearly some fixed cases where uploads would be worthwhile [12:52] those can and should be enumerated and handled [12:52] seb128: oh, isn't that what the usr/share/doc/dbus-1-doc/html usr/share/gtk-doc/html/dbus link is for? [12:52] I think a significant number will fail, and that it's easier to track FTBFS from LP. Separately, I think we've improved the build-support scripts, and want e.g. ddebs for everything. [12:52] so why not just do the fixed cases where they're known to be worthwhile? [12:52] uploading everything should not be on the table [12:52] cjwatson: Mostly a matter of identification. [12:53] persia: it should be trivial [12:53] I don't accept that you need to upload everything. We have done plenty of this sort of thing in the past without needing that [12:53] pitti: not sure about the details now, but like the tutorial need to be in the directory and the html in a api subdirectory [12:53] Riddell: don't recall. Does it give problems? [12:53] cjwatson: I will at least want to upload everything that could produce a ddeb, for which there isn't a reliable one, which definitely means most arch:any not uploaded since mid-gutsy. [12:53] seb128: I mean, what did this patch actually change? [12:53] -doc/api/html usr/share/doc/dbus-1-doc/api/ [12:53] +doc/api/html/* usr/share/doc/dbus-1-doc/html/api [12:54] persia: right, that's a much-reduced set, and that sort of thing only needs to be done around feature freeze [12:54] ah, api/html -> html/api, I see [12:54] pitti: install those in html/api rather than api/html [12:54] give us as much time as possible for packages to be uploaded in the normal course of events [12:54] seb128: right, sorry; I'm blind :) [12:54] cjwatson: I still think it's thousands, and wanted to start earlier to reduce churn around feature freeze, but in principal I agree with you. [12:54] Is there any plan to get GIMP off of release candidate 3 in Gutsy? I'm kind of sick of random crashes. 2.4.1 is a stability improvement [12:54] s/principal/principle/ [12:55] persia: churn will be reduced naturally by packages getting normal uploads [12:55] pitti: no worry, that's just not obvious, I tweaked until having something correctly listed in devhelp in fact [12:55] enrico: we currently have this patch http://kubuntu.org/~jriddell/tmp/wibble.diff [12:55] Just want to know, before I go screwing around with 3rd party repos as a fix on the various ubuntu machines I support. [12:55] enrico: but it's possible it's not needed any more, I think gcc 4.3 changed since it was made [12:55] nemo_home: if you have crashes open a bug with a clear description on how to trigger it and we might backport the corresponding change [12:55] cjwatson: OK. We'll refine the numbers, and push things that have a clear value around FF. [12:56] seb128: oh. that's just silly. there are plenty of documented upstream bugfixes [12:56] seb128: the crashes have been various, and will be rough to track down [12:56] nemo_home: we don't upload new versions to stable, there is reason for that, you can argue that the new version is a bug fix only one but sometimes they have regressions [12:56] nemo_home: Many of them are in the released package. [12:56] seb128: there's a reason it was a release candidate [12:56] nemo_home: and a said there is a reason stable is stable [12:56] seb128: ALTER [12:56] persia: meh. reason I'm here is I just ran into a script-fu one that blew up my gimp a few moments ago [12:56] gicmo: Alter! [12:57] how is it going? [12:57] seb128: well, you put an unstable product in a stable release, then didn't update it with the bugfixes :-p [12:57] nemo_home: Great. File a bug. [12:57] seb128: hell. Firefox gets updated regularlyt [12:57] nemo_home: there is not so many change between rc and 2.4 so maybe your bug is still there [12:57] rc and *2.4.1* [12:57] seb128: got it now; I'll prepare a patch for Debian and upstream and forward it (sjoerd expressed interest in it) [12:57]