| === superm1_ is now known as superm1 | ||
| * Hobbsee waves | 01:27 | |
| === mneptok_ is now known as mneptok | ||
| * emgent heya | 01:59 | |
| === doko_ is now known as doko | ||
| * emgent heya | 03:43 | |
| * Hobbsee waves | 03:46 | |
| _MMA_ | Might be better to poke around later but does anyone have a clue where to look for documentation on JeOS? | 04:18 |
|---|---|---|
| f0rqu3 | I am using ati driver 7.11 and I cant change gamma in games | 04:34 |
| persia | f0rqu3: Have you reported a bug? | 04:35 |
| f0rqu3 | no | 04:35 |
| persia | f0rqu3: OK. Is it a regression from the previous behaviour, or do you just need help with the configuration settings? | 04:36 |
| ion_ | Hardy seems to have 7.1.0 | 04:36 |
| persia | In that case, maybe we can't do anything :( | 04:36 |
| === stu1 is now known as stub | ||
| jdong | ion_: hardy has 8.42.3.... | 05:05 |
| jdong | ion_: 7-11 is actually 8.43.3 | 05:06 |
| jdong | and home of delicious iced soft drinks! | 05:06 |
| jdong | both versions are umm... crap. But anyway, too late tonight for me to gain blood pressure for AMD/ATI incompetence and broken promises | 05:06 |
| persia | Hurrah. We can do something. Still leaves open the question of whether it's an answer or a bug. | 05:07 |
| jdong | persia: most people using 7-11 are reporting it represents no change from the hardy 8.42.3 version | 05:07 |
| jdong | so I would not expect that version bump to solve any problems | 05:07 |
| jdong | a cursory examination by me shows no difference except a broader PCI ID whitelist, i.e. more supported chipsets | 05:08 |
| persia | 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 |
| jdong | still serious problems with AIGLX performance, xvideo flickering, memory leaks. | 05:08 |
| jdong | 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 |
| RAOF | jdong: Any memory leaks as cool as nvidia's TFP leak? | 05:09 |
| jdong | RAOF: meh about 500MB in the course of one day | 05:09 |
| jdong | RAOF: not assigned to any app, seems like the leak is somewhere in kerneldom | 05:09 |
| persia | Ah. Nevermind. I though 42=43 for some reason. We can't support it. Alas. | 05:09 |
| jdong | persia: meh what could we support in fglrx anyway? Nice soft tissues and hugs? :D | 05:10 |
| RAOF | 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 |
| jdong | 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:10 |
| persia | jdong: I like to think we can provide help, and also fix issues in the packaging, even for binary blobs. | 05:11 |
| jdong | RAOF: right, just some random leak that affects some midlevel X-series PCI-X | 05:11 |
| jdong | persia: I envy your optimism :) | 05:11 |
| f0rqu3 | thanks I was at phoronix | 05:11 |
| f0rqu3 | no answer | 05:11 |
| f0rqu3 | going back to 8.40 | 05:12 |
| RAOF | f0rqu3: I don't think that'll work on Hardy, our X server is too new. | 05:12 |
| jdong | f0rqu3: I did the same.... 8.42+ was lasrgely a disappointment | 05:12 |
| jdong | RAOF: did he ever say he was on hardy? | 05:12 |
| jdong | *reads scrollback* | 05:12 |
| f0rqu3 | jdong, gamma was working? | 05:12 |
| RAOF | jdong: Uh, no. I just kinda assume a default of Hardy unless otherwise specified :) | 05:13 |
| jdong | 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 |
| jdong | those did work | 05:13 |
| jdong | RAOF: ah :) | 05:13 |
| f0rqu3 | xgamma -g 1000 | 05:13 |
| f0rqu3 | 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:14 | |
| pipegeek | any idea why compiz.real would slowly eat up all available memory while gnome-screensaver was running? | 05:49 |
| pipegeek | 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:49 |
| persia | How about your GL drivers? | 05:50 |
| pipegeek | shouldn't have been, but I'll check. My card's old enough that nvidia's not supporting it with their new drivers | 05:50 |
| pipegeek | 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:52 |
| pipegeek | 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:55 |
| persia | pipegeek: https://launchpad.net/ubuntu/+source/<packagename> should have some pointers. | 05:56 |
| pipegeek | page not found. | 05:57 |
| pipegeek | found it | 05:58 |
| pipegeek | wait, no, no I haven't | 05:59 |
| pipegeek | it's not listed there :-\ | 05:59 |
| mwansa | 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:00 |
| Amaranth | mwansa: you broke something, there should be no way to have alacarte installed and not have python-glade2 | 06:02 |
| === lc is now known as lcstudio | ||
| === thegodfather is now known as fabbione | ||
| StevenK | pitti! | 06:19 |
| Hobbsee | hey pitti! | 06:20 |
| pitti | Good morning | 06:22 |
| StevenK | pitti: Do you think it's safe to NBS out all of the zero sized things on the list? | 06:23 |
| pitti | StevenK: most, probably; some might actually be FTBFS or needs-build | 06:24 |
| StevenK | I might dig further and feed you lists, then | 06:25 |
| StevenK | pitti: Speaking of lists, bug 149275 :-) | 06:25 |
| ubotu | Launchpad bug 149275 in tasks "First cut of source packages for -mobile promotions" [Undecided,New] https://launchpad.net/bugs/149275 | 06:25 |
| pitti | StevenK: ah, right | 06:26 |
| Hobbsee | hey, pitti. | 07:40 |
| * Hobbsee waits for pitti to stop idling. | 07:41 | |
| * pitti hugs Hobbsee | 07:42 | |
| * Hobbsee hugs pitti back :D | 07:42 | |
| pitti | Hobbsee: I'm not idling :) | 07:42 |
| Hobbsee | pitti: i fixed some bits in your buildd.py | 07:42 |
| pitti | oh, great | 07:42 |
| pitti | what? | 07:43 |
| Hobbsee | 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:44 |
| pitti | Hobbsee: ah, did you introduce an option for the depwait change? | 07:45 |
| Hobbsee | (the previous error checking only would bail if it was in ubuntu, but not in that particular release) | 07:45 |
| Hobbsee | pitti: yes | 07:45 |
| pitti | since it's something you don't normlaly want to do | 07:45 |
| Hobbsee | to cue something out of depwait, so it gets queued to build RSN? | 07:45 |
| Hobbsee | s/cue/shove/ | 07:45 |
| pitti | right, because it should retry automatically | 07:46 |
| Hobbsee | sure, but if you want to step it through sensibly. | 07:46 |
| * Hobbsee found it useful, anyway. | 07:46 | |
| pitti | i. e. I don't want to trigger it without checking previously | 07:46 |
| pitti | Hobbsee: right, it is | 07:46 |
| pitti | 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:46 | |
| pitti | Hobbsee: there are some people I trust enough to risk the waste of some buildd time :) | 07:47 |
| * pitti hugs geser | 07:47 | |
| Hobbsee | pitti: FWIW, http://wedontsleep.org/~sarah/buildd.py - feel free to change it as you wish | 07:48 |
| pitti | Hobbsee: I'll revert your cookiefile glob change | 07:49 |
| Hobbsee | pitti: oh, yeah, sorry :) | 07:50 |
| pitti | Hobbsee: ah, you don't have my fix yet for version numbers with a + in it | 07:50 |
| Hobbsee | pitti: no, i was wondering about that. | 07:50 |
| Hobbsee | where is it? | 07:50 |
| Hobbsee | ah, found it, i thnk | 07:50 |
| pitti | and I don't see an option for retrying depwaits | 07:50 |
| pitti | p.u.c./~pitti/scripts/ | 07:51 |
| Hobbsee | pitti: status == 'Dependency wait' | 07:51 |
| pitti | right, but it's not an option, it's done by default | 07:52 |
| Hobbsee | i thought i said that, yes | 07:52 |
| * pitti commits and scp's it back to p.u.c. | 07:54 | |
| pitti | Hobbsee: thanks! | 07:54 |
| StevenK | You guys need a bzr branch | 07:56 |
| StevenK | :-P | 07:56 |
| pitti | I have my ~/bin in bzr, just not publicly on LP :) | 07:57 |
| StevenK | Heh | 07:58 |
| dholbach | good morning | 08:05 |
| ion_ | Hi | 08:06 |
| Fujitsu | Hi dholbach. | 08:06 |
| dholbach | hey Fujitsu, hey ion_ | 08:07 |
| dholbach | hey seb128 | 08:08 |
| seb128 | Hi dholbach | 08:08 |
| pitti | hey dholbach | 08:08 |
| pitti | Bonjour seb128 | 08:08 |
| seb128 | Hey pitti | 08:08 |
| dholbach | heya pitti | 08:10 |
| * ion_ faintly recalls a bit of a Monty Python sketch of people greeting everyone. | 08:10 | |
| pitti | hey ion_! | 08:10 |
| ion_ | Howdy pitti | 08:10 |
| persia | Hi Bruce | 08:11 |
| seb128 | pitti: when you tag photos you usually decide what categories to use, why do you think that's not working correctly? | 08:15 |
| pitti | seb128: I didn't say that tagging photos doesn't work correctly? | 08:16 |
| pitti | I don't know how it works in f-spot etc., since I don't tag my photos | 08:16 |
| pitti | but WDYM? | 08:16 |
| seb128 | pitti: well, you wrote that you don't believe in tagging | 08:17 |
| pitti | ah, right, there (but that's just my personal preference, I wasn't saying that it cannot work in general) | 08:17 |
| === Traxer is now known as Traxer|on | ||
| pitti | but tags can usually be defined completely arbitrarily, which means that there is no common standard for them | 08:17 |
| seb128 | pitti: oki | 08:17 |
| === Traxer|on is now known as Traxer | ||
| pitti | and thus it's hard to actually use them | 08:18 |
| seb128 | well, usually you tag your photos yourself so you decide of what labels make sense to you | 08:18 |
| persia | In the case of personal photos that is a feature. In the case of shared bugs, perhaps less so. | 08:18 |
| pitti | so especially on flickr and bug trackers I do think that this is a problem | 08:18 |
| seb128 | well, who cares about tags in launchpad | 08:18 |
| * persia cares | 08:18 | |
| seb128 | you use some you find useful, they are for you | 08:18 |
| pitti | persia: yeah, in your personal photo collection you are probably disciplined enough | 08:19 |
| seb128 | those are not meant to be universal | 08:19 |
| seb128 | I tag desktop bugs I want to look at for the next lts for example | 08:19 |
| seb128 | some tag the build issues | 08:19 |
| pitti | seb128: right, but as the guys pointed out they create noise in the tag list, bug mail, etc. | 08:19 |
| persia | seb128: But when you tag a bug, it sends a message to all bug subscribers, and some subscribers might not like your tags. | 08:19 |
| seb128 | well, having everything listed in an UI error | 08:20 |
| seb128 | persia: that would be a launchpad bug | 08:20 |
| pitti | yep; sorting those out in the UI is a great and simple solution IMHO | 08:20 |
| persia | seb128: OK. I'll accept that. | 08:20 |
| seb128 | that doesn't mean you should stop people using tagging their way | 08:20 |
| * persia suspects it's easier to ACL tag lists than to fix the UI and notification issues. | 08:21 | |
| seb128 | pitti: so now if I want to tag gvfs switch issues I need to ask for the tag to be defined somewhere? | 08:21 |
| Mithrandir | we could just have usertags. | 08:21 |
| pitti | seb128: no | 08:21 |
| persia | Mithrandir: Hard to share for teams | 08:21 |
| seb128 | that creates extra work and will just make me not use tagging | 08:21 |
| pitti | 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:21 |
| seb128 | why do you need a dropdown list? | 08:22 |
| Mithrandir | persia: No? Usertags means you have your own namespace, not that nobody can see your tags. | 08:22 |
| pitti | well, or the portlet, or whatever | 08:22 |
| pitti | just something to avoid seeing 2000 tags with 1980 of them being useless for me | 08:22 |
| persia | Mithrandir: Hmm. I suppose teams could define team namespaces. Objection withdrawn. | 08:22 |
| seb128 | why do you need a list? tags are defined by somebody who has an interest to use some tagging | 08:22 |
| Mithrandir | 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 |
| pitti | 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 |
| seb128 | pitti: the issue is probably to list all of those, they should list none | 08:23 |
| pitti | seb128: but if nobody uses the same set of tags, what's the use of them? | 08:23 |
| persia | seb128: I like lists because sometimes I want to share common tags when tagging a bug. | 08:23 |
| seb128 | or only the one your subscribed to or are usingh | 08:23 |
| pitti | except for your own personal bug management, which could be done with more structured ways, too? | 08:23 |
| seb128 | persia: there is hundred of valid tagging cases | 08:23 |
| persia | Mithrandir: As long as the notification issue was resolved, yes. | 08:23 |
| persia | seb128: Yes. | 08:24 |
| pitti | but if bug triagers should help with putting categories to buts, we need some common standards | 08:24 |
| seb128 | we already do | 08:24 |
| seb128 | we already have sru tags | 08:24 |
| Mithrandir | persia: if you didn't subscribe to a namespace (or something like that), you wouldn't get notified about usertag changes. | 08:24 |
| pitti | if someone uses 'graphics', the next one 'picture-viewer', and yet another one the tag 'gthumb', that won't help anyone | 08:24 |
| seb128 | there is ftbfs, needs-packaging, etc tags | 08:24 |
| persia | Mithrandir: For the right spec, you're correct. | 08:24 |
| seb128 | well, that's an UI probably | 08:25 |
| persia | seb128: Right. Defined, agreed tags. The barrier can be low, but we've too many similar tags now. | 08:25 |
| pitti | 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 |
| seb128 | when launchoad started using tags I read somewhere that they were going to display only the most used ones | 08:25 |
| seb128 | which would filter all this user noise | 08:25 |
| * persia thinks that fell into the same bucket as "most recently joined groups" | 08:26 | |
| Fujitsu | persia: Heh. You mean just the first 5 alphabetically? | 08:27 |
| persia | Fujitsu: Yes. | 08:28 |
| seb128 | 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 |
| persia | 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:28 |
| seb128 | pitti: much easier to just display the most commonly used tags which are likely the only clearly defined | 08:29 |
| pitti | seb128: I agree, that would help | 08:29 |
| seb128 | hey mvo | 08:32 |
| mvo | hey seb128! | 08:32 |
| MacSlow | Greetings everybody! | 08:44 |
| === \sh_away is now known as \sh | ||
| \sh | moins | 08:56 |
| pgquiles | 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? | 08:57 |
| luisbg_ | hello everyone | 09:00 |
| === glatzor_ is now known as glatzor | ||
| pitti | 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 |
| ubotu | 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:20 |
| pitti | cjwatson_: (rather, ack the SRU itself; I'm quite confident about the AA changes themselves) | 09:21 |
| === Hobbsee_ is now known as Hobbsee | ||
| lool | what's this on ubuntu-devel-announce? | 09:33 |
| Hobbsee | someone who didn't follow the reply-to, it appears, and someone else who accepted the mail | 09:33 |
| lool | Ah simply a moderation slip | 09:33 |
| === cjwatson_ is now known as cjwatson | ||
| pitti | ArneGoetje: is the merge of ttf-arphic-uming still on your list? | 09:42 |
| ArneGoetje | pitti: I will build a new version anyways | 09:43 |
| pitti | ArneGoetje: right, but it should still be merged with Debian for mutual patch exchange | 09:43 |
| ArneGoetje | pitti: the new version goes into debian and ubuntu at the same time. | 09:44 |
| pitti | ah | 09:44 |
| tkamppeter | pitti, hi | 10:00 |
| pitti | hi tkamppeter | 10:00 |
| geser | 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:20 |
| saispo | any xen feisty or gutsy git branches exist or not ? | 10:23 |
| pitti | 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:25 |
| pitti | hm, correction, I do have a test case for compat 3 | 10:26 |
| pitti | geser: can you please file a bug about this? | 10:26 |
| geser | against pkg-create-dbgsym? | 10:27 |
| pitti | yes, please | 10:27 |
| pitti | it might very well be that this is actually a packaging error of gtk-engines-mono | 10:28 |
| pitti | but we should get along with those in pkg-create-dbgsym | 10:28 |
| geser | pitti: bug #173631 | 10:33 |
| ubotu | 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 |
| saispo | kernel-xen have a git repository for feisty and gutsy ? | 10:33 |
| pitti | thanks | 10:35 |
| soren | Don't we have any cross compilers? I need a ppc compiler on i386. | 10:38 |
| geser | soren: qemu? | 10:43 |
| soren | geser: I'm not entirely comfortable build-depending on qemu :) | 10:44 |
| === cjwatson_ is now known as cjwatson | ||
| === pedro is now known as pedro_ | ||
| norsetto | do archive admins receive emails sent to archive@ubuntu.com ? | 11:22 |
| Ng | norsetto: no | 11:23 |
| Hobbsee | Ng: reads it, and steals it all instead | 11:23 |
| norsetto | Hobbsee: naughty ng .... | 11:24 |
| persia | norsetto: You may want ubuntu-archive@l.u.c | 11:24 |
| norsetto | 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:24 |
| norsetto | persia: thats moderated I think? Seems I'm (quite rigthly) moderated everywhere :-) | 11:25 |
| Ng | norsetto: if you've replied to archive@ it'll have been eaten by the black hole of doom I'm afraid | 11:25 |
| persia | norsetto: Moderated, but you can join. Also, moderators can be poked. | 11:26 |
| norsetto | Ng: oh well, I'm not going in there .... | 11:26 |
| Fujitsu | Ng: That sounds like a very silly address to have it come from, then... | 11:26 |
| Hobbsee | haha, the black hole of doom :) | 11:27 |
| norsetto | anyhow, what should we do when the tarball in debian and the one in ubuntu differs? keep fakesyncing ad libitum or ? | 11:27 |
| Hobbsee | yes | 11:27 |
| persia | norsetto: Keep fake-syncing until there is a new Debian upload. | 11:27 |
| norsetto | persia: yes, thats the proble, upstream is no more so there won't be any new Debian upload I'm afraid | 11:27 |
| persia | 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 |
| Hobbsee | norsetto: an archive admin might consent to removing the packge, so you could merge it with teh debian tarball. *shrug* | 11:28 |
| geser | norsetto: become upstream and release a new upstream version. problem solved :) | 11:29 |
| norsetto | 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:29 | |
| persia | Err. I think removing & syncing is ugly. Becoming upstream is good. | 11:30 |
| geser | 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:34 |
| Hobbsee | geser: oh, there's a thought. er...it might. the old link to librarian would just get lost | 11:35 |
| Hobbsee | unsure | 11:35 |
| * persia thinks pool would get annoyed | 11:36 | |
| cjwatson | removing and syncing can easily break mirroring, so we won't do that | 11:40 |
| === dholbach_ is now known as dholbach | ||
| Hobbsee | cjwatson: in the spirit of making more things open w.r.t. release, where is the blacklist's bzr repo? | 11:41 |
| Hobbsee | cjwatson: and why isn't it using LP? | 11:41 |
| cjwatson | hysterical raisins - it's just a local bzr repository on drescher, not pushed anywhere | 11:43 |
| cjwatson | I saw your comment the other day, but you weren't around to reply :) | 11:43 |
| cjwatson | I'll arrange to have it pushed somewhere more sensible | 11:43 |
| Hobbsee | cjwatson: yeah, i don't live on irc all the time. i usually have a logger, though :) | 11:43 |
| Keybuk | seems logical for it to be on bazaar.lp/~ubuntu-archive | 11:43 |
| cjwatson | the actual files are public, so it wasn't a problem until recently ... | 11:43 |
| Keybuk | probably only wasn't because that didn't exist at the time | 11:44 |
| cjwatson | Keybuk: yeah | 11:44 |
| cjwatson | I think it did, but all of ~ubuntu-archive had drescher accounts :) | 11:44 |
| Hobbsee | yeah yeah :) | 11:44 |
| Keybuk | turn it into a bind-checkout | 11:44 |
| Hobbsee | cjwatson: the plebs don't. we know. but i'm not stepping out of archive yet :) | 11:44 |
| Keybuk | but then you'd have to make sure "bzr update" gets called somewhen useful | 11:44 |
| ogra | does anyone have a clue how to solve stuck loop mounts like: http://paste.ubuntu-nl.org/46671/ | 11:44 |
| ogra | ? | 11:44 |
| cjwatson | 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 |
| cjwatson | 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:45 |
| Hobbsee | hm | 11:51 |
| cjwatson | ogra: does 'losetup -d /dev/loop0' help? | 11:51 |
| ogra | cjwatson, nope, because the stack still sits on top ... | 11:52 |
| ogra | /tmp/test1 is the unionfs mount | 11:52 |
| ogra | below there is /tmp/.test1-{ro,rw} | 11:53 |
| ogra | but there is nothing accessing /tmp/test1 anymore | 11:53 |
| cjwatson | can you clean up any parts of that stack? | 11:53 |
| ogra | nope | 11:53 |
| ogra | the toplevel is stuck | 11:53 |
| cjwatson | then you might be screwed :) | 11:53 |
| ogra | i can forcefully unmount the unionfs .... with the result that the loopdevice stays stuck | 11:54 |
| ogra | i.e. get rid of everything in mtab but that still hogs loop0 | 11:54 |
| cjwatson | forceful unmounting probably just means that userspace forgets about it but the kernel bit is still there | 11:54 |
| ogra | ltsp-image-shell is a script ... it works perfectly if i run it in a shell | 11:54 |
| ogra | its purpose is to run in an embedded pathon vte though ... | 11:55 |
| cjwatson | the process you showed in that paste looks like a kernel thread | 11:55 |
| ogra | as soon as i use it there i cant unmount the unionfs and get this strage effect | 11:55 |
| ogra | uuuh ... | 11:55 |
| ogra | i want a new keyboard ...(and new fingers ...grmbl) | 11:55 |
| cjwatson | perhaps 'sudo lsof | grep /tmp/test' to see if anything's still using that | 11:56 |
| * Hobbsee slices off ogra's fingers | 11:56 | |
| cjwatson | 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 | ogra@laptop:~/devel/hardy/ltsp-image-shell$ sudo lsof | grep /tmp/test | 11:56 |
| ogra | ogra@laptop:~/devel/hardy/ltsp-image-shell$ mount|grep test | 11:56 |
| ogra | tmpfs on /tmp/.test1-rw type tmpfs (rw) | 11:56 |
| ogra | /opt/ltsp/images/test1.img on /tmp/.test1-ro type squashfs (rw,loop=/dev/loop0) | 11:56 |
| ogra | unionfs on /tmp/test1 type unionfs (rw,dirs=/tmp/.test1-rw=rw:/tmp/.test1-ro=ro,delete=whiteout) | 11:56 |
| ogra | intresting :) | 11:57 |
| cjwatson | lsof | grep test? | 11:57 |
| ogra | gains the result from the paste above | 11:57 |
| cjwatson | anyway, that's clearly what's keeping the loop device busy | 11:57 |
| ogra | OH !! | 11:57 |
| ogra | no its different | 11:58 |
| ogra | ogra@laptop:~/devel/hardy/ltsp-image-shell$ sudo lsof | grep test | 11:58 |
| ogra | nbd-serve 8075 nobody 4r REG 3,4 151134208 783528 /tmp/images/test1.img (deleted) | 11:58 |
| ogra | geez | 11:58 |
| cjwatson | aha | 11:58 |
| ogra | how does that happen | 11:58 |
| ogra | nbd shouldnt even know about it | 11:58 |
| cjwatson | didn't bind-mount /proc so it couldn't find the process to kill, maybe? | 11:58 |
| cjwatson | as in, is that nbd-serve running in the chroot? | 11:58 |
| ogra | no, i usually mount and unmount /proc chrooted ... | 11:59 |
| ogra | no, nbd-server is started by inted.conf usually | 11:59 |
| ogra | and there is no line at all for /tmp/images/test1.img | 11:59 |
| ogra | thats very strange | 11:59 |
| ogra | well, its my spare time project from the weekend ... i'll investigate more later ... back to regular work now :) | 11:59 |
| pitti | 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 |
| pitti | seb128: (just merging dbus and wondering about this delat) | 12:20 |
| pitti | delta, even | 12:21 |
| pitti | oh, sorry, seems you didn't | 12:21 |
| pitti | I was just confused: | 12:21 |
| pitti | -doc/api/html usr/share/doc/dbus-1-doc/api/ | 12:21 |
| pitti | +doc/api/html/* usr/share/doc/dbus-1-doc/html/api | 12:21 |
| Riddell | doko: which is better, python-support or python-central? | 12:30 |
| cjwatson | Package: python-central | 12:31 |
| cjwatson | Maintainer: Matthias Klose <doko@ubuntu.com> | 12:31 |
| cjwatson | ;-) | 12:31 |
| doko | Riddell: you'll get a biased answer from me ;-P | 12:31 |
| Hobbsee | doko: think of it this way... | 12:32 |
| Hobbsee | doko: if you say py-central, he's going to ask you how to use it | 12:32 |
| Riddell | doko: is there a quick guide to how to use it? | 12:32 |
| Hobbsee | doko: if you say py-support, he'll go and bug someone else. | 12:32 |
| Hobbsee | doko: pick wisely :) | 12:32 |
| === dendro-away is now known as dendrobates | ||
| Riddell | enrico: have you tried libwibble with gcc 4.3? | 12:43 |
| persia | 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:45 |
| Riddell | persia: what would be the need for that? | 12:46 |
| cjwatson | persia: what numbers are involved? | 12:46 |
| persia | Riddell: I've found at least some packages that FTBFS when they haven't been updated for the most current release. | 12:46 |
| cjwatson | and yes, there should be an actual need | 12:46 |
| cjwatson | persia: it's reasonable to do a test-build but not actually upload the results | 12:46 |
| persia | 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 |
| cjwatson | a scripted upload of half the archive is definitely unacceptable | 12:47 |
| cjwatson | by all means, test-build and fix the ones that fail | 12:47 |
| cjwatson | but there's no need to put that kind of load on mirrors just for a test-build | 12:47 |
| persia | 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 |
| persia | Further, it's not just test-build: we get the new CDBS stuff, etc. | 12:47 |
| cjwatson | for a relatively small number of packages, yes | 12:48 |
| pitti | not to mention the stress that would be put on the buildds | 12:48 |
| cjwatson | 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:48 |
| cjwatson | the buildds, as pitti says, are already having serious trouble keeping up | 12:49 |
| persia | At. I don't mean one go. I was thinking something like 500 a week. | 12:49 |
| pitti | persia: please keep in mind that buildds never dropped below 2900 needs-build records ever since we opened hardy | 12:49 |
| cjwatson | persia: it just sounds gratuitous to me | 12:49 |
| pitti | persia: but what's the point in rebuilding a working package? | 12:49 |
| persia | pitti: Yes, but most of that looks like it's one arch. | 12:49 |
| Hobbsee | pitti: yeah, but how much of that refers to arches like hppa, and how much of that is actually hardy? | 12:49 |
| pitti | persia: after all, the pool structure was designed to avoid this kind of thing | 12:49 |
| Hobbsee | (and how much of it is not superceeded source, that has never even tried to be built?) | 12:50 |
| pitti | Hobbsee: I don't know exact numbers | 12:50 |
| persia | 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 |
| Hobbsee | pitti: i386 was at 0 last night. *shrug* | 12:50 |
| Hobbsee | pitti: i'ts the belated arches, iirc | 12:50 |
| cjwatson | 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 |
| pitti | persia: that still doesn't answer the question why all packages need an upload | 12:50 |
| pitti | instead of just fixing the ones that FTBFS | 12:51 |
| persia | pitti: I agree about pool: I only think it's worth it because it's LTS. | 12:51 |
| pitti | persia: why is it worth it? | 12:51 |
| pitti | buildds and mirrors aside, I fail to see the need | 12:51 |
| seb128 | pitti: dbus, you need to install things to the standard location so devhelp find those | 12:51 |
| cjwatson | there are clearly some fixed cases where uploads would be worthwhile | 12:51 |
| cjwatson | those can and should be enumerated and handled | 12:52 |
| pitti | 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 |
| persia | 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 |
| cjwatson | so why not just do the fixed cases where they're known to be worthwhile? | 12:52 |
| cjwatson | uploading everything should not be on the table | 12:52 |
| persia | cjwatson: Mostly a matter of identification. | 12:52 |
| cjwatson | persia: it should be trivial | 12:53 |
| cjwatson | 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 |
| seb128 | 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 |
| enrico | Riddell: don't recall. Does it give problems? | 12:53 |
| persia | 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 |
| pitti | seb128: I mean, what did this patch actually change? | 12:53 |
| pitti | -doc/api/html usr/share/doc/dbus-1-doc/api/ | 12:53 |
| pitti | +doc/api/html/* usr/share/doc/dbus-1-doc/html/api | 12:53 |
| cjwatson | persia: right, that's a much-reduced set, and that sort of thing only needs to be done around feature freeze | 12:54 |
| pitti | ah, api/html -> html/api, I see | 12:54 |
| seb128 | pitti: install those in html/api rather than api/html | 12:54 |
| cjwatson | give us as much time as possible for packages to be uploaded in the normal course of events | 12:54 |
| pitti | seb128: right, sorry; I'm blind :) | 12:54 |
| persia | 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 |
| nemo_home | 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 |
| persia | s/principal/principle/ | 12:54 |
| cjwatson | persia: churn will be reduced naturally by packages getting normal uploads | 12:55 |
| seb128 | pitti: no worry, that's just not obvious, I tweaked until having something correctly listed in devhelp in fact | 12:55 |
| Riddell | enrico: we currently have this patch http://kubuntu.org/~jriddell/tmp/wibble.diff | 12:55 |
| nemo_home | 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 |
| Riddell | enrico: but it's possible it's not needed any more, I think gcc 4.3 changed since it was made | 12:55 |
| seb128 | 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 |
| persia | cjwatson: OK. We'll refine the numbers, and push things that have a clear value around FF. | 12:55 |
| nemo_home | seb128: oh. that's just silly. there are plenty of documented upstream bugfixes | 12:56 |
| nemo_home | seb128: the crashes have been various, and will be rough to track down | 12:56 |
| seb128 | 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 |
| persia | nemo_home: Many of them are in the released package. | 12:56 |
| nemo_home | seb128: there's a reason it was a release candidate | 12:56 |
| seb128 | nemo_home: and a said there is a reason stable is stable | 12:56 |
| gicmo | seb128: ALTER | 12:56 |
| nemo_home | 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 |
| seb128 | gicmo: Alter! | 12:56 |
| gicmo | how is it going? | 12:57 |
| nemo_home | seb128: well, you put an unstable product in a stable release, then didn't update it with the bugfixes :-p | 12:57 |
| persia | nemo_home: Great. File a bug. | 12:57 |
| nemo_home | seb128: hell. Firefox gets updated regularlyt | 12:57 |
| seb128 | nemo_home: there is not so many change between rc and 2.4 so maybe your bug is still there | 12:57 |
| nemo_home | rc and *2.4.1* | 12:57 |
| pitti | seb128: got it now; I'll prepare a patch for Debian and upstream and forward it (sjoerd expressed interest in it) | 12:57 |
| nemo_home | not *2.4* | 12:57 |
| seb128 | nemo_home: firefox is a special case, it's because it's almost impossible to backport cleanly the fixes there | 12:57 |
| seb128 | pitti: ok, thanks | 12:58 |
| seb128 | nemo_home: 2.4.n same story | 12:58 |
| seb128 | nemo_home: we put in a stable whatever was available and a candidate is not exactly an unstable version | 12:58 |
| nemo_home | seb128: seems to be making more work for you and the users, just to patch in stuff already solved in an upstream version that is clearly identified as being for fixes, not features | 12:58 |
| nemo_home | but whatever | 12:58 |
| seb128 | nemo_home: the changelog between rc3 and 2.4 is not that many changes | 12:58 |
| seb128 | nemo_home: well, been there, got screwed by regression in bug fix versions | 12:59 |
| seb128 | nemo_home: we just don't backport to new version for the sake of changing the version, if there is a fix required we will backport it and test against regressions | 13:00 |
| seb128 | pitti: there might be a fix upstream already, the change has been copied on the fedora package | 13:02 |
| pitti | seb128: ah, we wondered why it isn't in 1.1.2 yet | 13:03 |
| seb128 | pitti: well, fedora has it for like 1 year so maybe they just didn't bring it upstream for whatever reason | 13:03 |
| Hobbsee | rob: since when do you let servers get stoned? | 13:04 |
| pitti | seb128: nope, not in git head either; I'll send it there then | 13:04 |
| seb128 | pitti: ok, thanks | 13:04 |
| Riddell | doko: if I'm merging a package with one of your gcc 4.3 changes, should I submit the patch to the debian BTS if it isn't in there? | 13:05 |
| seb128 | Riddell: looks like a good idea to send build fixes there | 13:05 |
| nemo_home | seb128: http://developer.gimp.org/NEWS | 13:06 |
| nemo_home | seb128: and they are planning a bugfix 2.4.2 | 13:07 |
| seb128 | nemo_home: I know the NEWS files, I had this discussing already several times | 13:07 |
| nemo_home | seb128: the one I ran into was in script-fu | 13:07 |
| doko | Riddell: please do; however I did file for every package a bug report ... | 13:07 |
| seb128 | nemo_home: that's true for lot of project, you could argue we should get GNOME 2.21 to gutsy because it fixes bugs you are having | 13:07 |
| nemo_home | seb128: well, typically there is a difference between major/minor release numbers and devs honour it | 13:08 |
| nemo_home | it is why, presumably, you won't bring FF3 into Gutsy | 13:08 |
| seb128 | nemo_home: and stable bug fixes versions already had ugly bugs which have been embarassing | 13:08 |
| === pedro__ is now known as pedro_ | ||
| seb128 | nemo_home: we have already been screwed by stable bug fix updates, we learnt | 13:08 |
| nemo_home | seb128: but you know, not a big deal. Answer for me is, I should test GIMP off one of the non-gutsy repos, if that fixes the issues I and other users are running into, I'll make that standard | 13:08 |
| nemo_home | no worries. | 13:08 |
| nemo_home | seb128: thanks for your time | 13:08 |
| seb128 | nemo_home: we don't push new versions to stable, there is reasons to that, no point to argue there | 13:09 |
| nemo_home | not arguing anymore. conceded point :) | 13:09 |
| nemo_home | not going to waste a dev's time. if that's the way it, that's the way it is. | 13:09 |
| nemo_home | I'll work around it. | 13:09 |
| seb128 | nemo_home: using non standard repositories your might break your next updates and drop official ubuntu support for issues you have there | 13:09 |
| nemo_home | I know, unfortunate, but what can you do. | 13:09 |
| nemo_home | later | 13:09 |
| seb128 | nemo_home: the right way to do is to report your issues | 13:09 |
| nemo_home | these have already been reported upstream, kind of pointless. | 13:10 |
| seb128 | nemo_home: so we can backport corresponding fixes and you can use the official version | 13:10 |
| seb128 | nemo_home: report it to launchpad saying it's fixed upstream and needs to be backported to stable | 13:10 |
| seb128 | nemo_home: or request an official gutsy-backport for the hardy version | 13:10 |
| nemo_home | basically, requiring users who encounter bugs with software to report in multiple places. seems having a simple bugzilla query tagging fixed crashers in upstream stable branch might not be a bad idea | 13:11 |
| nemo_home | but, yeah. understand the process you want done | 13:11 |
| nemo_home | anyway. need to get to work | 13:11 |
| nemo_home | later | 13:11 |
| === nemo_home is now known as nemo_work | ||
| persia | cjwatson: Just for reference, what volume do you think would be acceptable? | 13:13 |
| enrico | Riddell: looks like the uisual missing header | 13:17 |
| enrico | Riddell: worth applying | 13:17 |
| Riddell | enrico: certainly doesn't do any harm | 13:18 |
| cjwatson | persia: I'm not sure I'm prepared to give a number that will no doubt be quoted :) | 13:29 |
| cjwatson | I think it ought to be comparable to normal upload volume | 13:29 |
| persia | cjwatson: I understand. I think we're probably looking at around three thousand, but will keep trying to refine it tighter. I'm just concerned about waiting to FF for that many. as that won't be "normal upload volume". Maybe we'll start pushing some of them after DIF? | 13:31 |
| seb128 | persia: why do you need to rebuild those? | 13:33 |
| persia | Also, I'm curious about scripted vs. manual. | 13:34 |
| persia | seb128: Still working on specific cases, but CDBS improvements, ddeb generation, SSP, docbook updates, and possibly others. | 13:34 |
| seb128 | persia: there is no cdbs improvement worth rebuilding afaik | 13:34 |
| jdstrand | slangasek: cool by me. thanks! | 13:35 |
| persia | seb128: Since when? Since warty? | 13:35 |
| seb128 | persia: right | 13:35 |
| persia | OK. That was the small number anyway. | 13:36 |
| seb128 | things like calling dh_icons should have been fixed already | 13:36 |
| persia | seb128: Well, it's not, for various reasons, but that is also true for packages that don't use CDBS, so I'm less concerned: that falls under normal bugfix maintenance in my book. | 13:37 |
| cjwatson | there are 9 packages using cdbs that have not changed since warty | 13:37 |
| persia | cjwatson: Right. Like I said, it was the small number anyway :) | 13:37 |
| seb128 | I'm fine with rebuild 9 packages ;-) | 13:37 |
| seb128 | rebuilding | 13:37 |
| cjwatson | (csound-doc gkrellm-i8k ldapdiff libmidi-perl mathwar serveez vrflash xmmplayer xzip) | 13:37 |
| persia | OK. Specifics aside (I need to get the reasons, and the counts, and present them), is it better to start early if the volume is high? Also, should it be a scripted rebuild, or coordination of volunteers for manual rebuilds? | 13:38 |
| seb128 | better to start early if you touch packages will are not likely to be uploaded during the cycle | 13:39 |
| persia | It would also be nice to get a guideline on volume, but I don't want one for the reasons cjwatson mentions above. | 13:39 |
| cjwatson | 12 more than that since hoary, 30 more than that since breezy, 77 more than that since dapper, 154 more than that since edgy, 334 more than that since feisty, 969 more than that since gutsy | 13:39 |
| cjwatson | persia: it should only be scripted if FTBFS are dealt with at the same time | 13:39 |
| cjwatson | there's no point in throwing something at the buildds that you can already know is going to fail | 13:39 |
| persia | gutsy/feisty had dh_icons / dh_iconcache, so it's only 572 CDBS packages. | 13:40 |
| cjwatson | persia: why 572? the count not rebuilt since edgy is 282 | 13:40 |
| persia | cjwatson: OK. That makes sense. build-test, and push fixes for FTBFS. Once that's sorted, rerun the counts, and look at the other reasons, present numbers, and possibly script. Thanks | 13:41 |
| cjwatson | and I'm sure a number of CDBS packages don't care about icons | 13:41 |
| persia | Because I can't count (oops) | 13:41 |
| seb128 | persia: I'm not sure we will win a lot of rebuilds, fixing ftbfes would be nice though | 13:41 |
| persia | seb128: I think ddebs are a win, but the rest deserve investigation, and I agree FTBFS is a priority. | 13:42 |
| seb128 | ddebs are nice, but it's likely that the packages not touched in months are not used a lot or maintained actively and don't get that many crash bugs | 13:43 |
| persia | seb128: Maybe. I tend to go hunt universe crash bugs when I'm bored, and point new contributors at them if they've a bit of coding knowledge, and am often frustrated by the lack of symbols. | 13:47 |
| * Hobbsee thinks persia should be bored more often, then | 13:47 | |
| seb128 | persia: ok, I used to look at the apport crash bugs and my impression was that most of the crashes where on packages which have ddebs, that's just an impression though | 13:49 |
| seb128 | persia: anyway having ddebs for everything would be cool, I just don't think it's a priority | 13:50 |
| saispo | plop seb128 :) | 13:51 |
| seb128 | hi saispo | 13:51 |
| persia | seb128: I suspect that's because you're closely maintaining a bunch of packages that get uploaded frequently. I agree it's not a priority, but would find it nice. I was hoping for a mass-upload of everything to make it easy to force them and find the FTBFS issues, but I understand the counter-arguments, so will resort to manual hunting. | 13:51 |
| seb128 | persia: when I wrote that I used to look at the apport crash bugs, that means all the bugs sent, not the one on packages I maintain, which I'm still doing | 13:52 |
| seb128 | persia: I did some round of "closing bugs with broken .crash" before feisty | 13:52 |
| persia | seb128: Ah. You're more ambitious than I thought :) | 13:52 |
| seb128 | and retracing, tagging (when we had to manually tag those) | 13:53 |
| === Fujitsu_ is now known as Fujitsu | ||
| mvo | RAOF_: hello! do you mind if I upload a new xserverx-gl that blacklists radeonhd? | 14:06 |
| soren | If a package has replaced files from another package and is then removed, what will happen? Will the files be missing or will they somehow magically be reinstated from the "original" package? | 14:19 |
| seb128 | soren: no, it'll just not be there | 14:19 |
| soren | Ew. | 14:20 |
| soren | seb128: Ok, thanks. | 14:20 |
| seb128 | soren: that's why some people use Conflicts,Replaces | 14:20 |
| soren | Sure. That's just not applicable here. | 14:20 |
| ScottK | soren: I think you can manage this with update-alternatives. | 14:20 |
| soren | I'll probably go with dpkg-divert or something. | 14:20 |
| seb128 | no alternatives when not required | 14:20 |
| * soren looks forward to the days of declarative diversions.. | 14:21 | |
| persia | dpkg-divert? | 14:22 |
| soren | persia: Yes? | 14:22 |
| persia | I just thought that dpkg-divert was "declarative diversions", but will go read documentation :) | 14:23 |
| cjwatson | dpkg-divert is imperative, not declarative | 14:23 |
| soren | persia: It allows you to move files out of the way in a way that dpkg understands so that you can replace certain files and have them properply reinstated, when you remove the diverting package. | 14:23 |
| persia | Ah. | 14:23 |
| soren | Right. The thing is that almost every package using dpkg-divert copies the magic bits from other packages' maintainer scripts. | 14:24 |
| soren | But since almost every use case is the same, it'd be a lot easier if you just had a DEBIAN/diversions or something, which dpkg would handle for you directly instead of you having to deal with dpkg-divert. | 14:25 |
| persia | Or even a Diverts: header that would auto-calculate DEBIAN/diversions based on the current filesystem and listed package names to divert. I see the difference. Thanks. | 14:26 |
| pitti | soren: as a mitigation, a dh_diversions would probably help a lot already | 14:27 |
| soren | pitti: Good point. | 14:27 |
| cjwatson | Debian bug 41642 | 14:27 |
| ubotu | Debian bug 41642 in debhelper "debhelper: dh_diversions script?" [Wishlist,Open] http://bugs.debian.org/41642 | 14:27 |
| soren | Wow. 5 digit bug numbers. | 14:28 |
| cjwatson | (some recent patches in there from Matt Proud) | 14:28 |
| cjwatson | any long-time Debian maintainer has plenty of hard 5-digit bugs around | 14:28 |
| === cprov is now known as cprov-lunch | ||
| cjwatson | I have 8 myself, discounting wontfix/forwarded | 14:29 |
| StevenK | I think I managed to get rid of all of my 5 digit bugs | 14:29 |
| dholbach | 4 one-digit LP bugs are still open :-) | 14:30 |
| soren | dholbach: *g* | 14:30 |
| StevenK | bug 1, and which others? | 14:30 |
| ubotu | Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,Confirmed] https://launchpad.net/bugs/1 | 14:30 |
| StevenK | shut up ubotu | 14:30 |
| dholbach | bug 3, bug 7, bug 8 | 14:30 |
| ubotu | Launchpad bug 3 in rosetta "Custom information for each translation team" [Wishlist,Confirmed] https://launchpad.net/bugs/3 | 14:31 |
| ubotu | Launchpad bug 7 in rosetta "Need help for novice translators" [Medium,Confirmed] https://launchpad.net/bugs/7 | 14:31 |
| ubotu | Launchpad bug 8 in rosetta "Translator forums/means of communication" [Wishlist,Confirmed] https://launchpad.net/bugs/8 | 14:31 |
| StevenK | Ah | 14:31 |
| === marcel__ is now known as marcel | ||
| * Hobbsee wonders why the 7.10 example content mentions 7.04 cds | 14:53 | |
| seb128 | Hobbsee: because nobody updated those? | 14:54 |
| Hobbsee | surprised it didn't get checked, i guess | 14:54 |
| tjaalton | evand: re syslinux merge. please go ahead :) | 14:54 |
| seb128 | Hobbsee: I think some people mentionned it before gutsy, not sure now | 14:55 |
| seb128 | Hobbsee: still the same "too much to do and limited ressources" issue | 14:55 |
| Hobbsee | seb128: well understood that problem, yes. | 14:55 |
| evand | tjaalton: will do, thanks | 14:55 |
| lool | pitti, seb128: devhelp generation in dbus merged in SVN, thanks | 15:01 |
| pitti | lool: thanks, you beat sjoerd to it then, it seems :) | 15:02 |
| seb128 | lool: are you upstream? | 15:02 |
| seb128 | oh, speaking about debian | 15:02 |
| seb128 | cool ;-) | 15:02 |
| * sjoerd is not hard to beat these days :p | 15:03 | |
| lamont | mvo: network issues at the house this week (resolution ETA saturday), I may just hold off on the ia64 dist-upgrade until that's done. | 15:03 |
| lamont | or I may find a machine at the office to abuse, and add some creative iptables rules. :-) | 15:03 |
| lamont | is the list of URLs that must work documented anywhere? | 15:04 |
| mvo | lamont: heh :) ok | 15:06 |
| ogra | mvo, did you already take a look at the classmate wrt g-a-i speed ? | 15:07 |
| mvo | ogra: no :( sorry | 15:07 |
| mvo | Amaranth: I just checked xset q, its a missing b-d on x11-server-utils | 15:08 |
| * emgent hi | 15:28 | |
| tjaalton | pitti: sorry for being a bit vague about the i810/intel situation :/ | 15:37 |
| pitti | tjaalton: no problem, it's restored | 15:38 |
| tjaalton | pitti: yep, thanks | 15:40 |
| Keybuk | pitti: the sky falls every time I press Play | 15:44 |
| Keybuk | apparently playing "The Chicken Song" will cause my laptop to overheat, the sky to fall and the world to end | 15:44 |
| pitti | Keybuk: --debug --verbose? | 15:45 |
| pitti | Keybuk: does it freeze your laptop/spin 100% CPU? which process? | 15:46 |
| pitti | Keybuk: you are playing back in rhythmbox? | 15:46 |
| Keybuk | pitti: it seems that rhythmbox when you play a media file uses D-BUS to tell GNOME Power Manager not to suspend the laptop if I should close my lid | 15:46 |
| Keybuk | GNOME Power Manager throws up a very very bad sounding bubble to warn me that the end is nigh | 15:46 |
| pitti | chuckle | 15:47 |
| Keybuk | also, how do I get sound in flash-in-firefox ? | 15:47 |
| pitti | Keybuk: hm, it just works for me (adobe plugin) | 15:50 |
| Keybuk | doesn't for me today | 15:51 |
| === cprov-lunch is now known as cprov | ||
| === \sh is now known as \sh_away | ||
| stgraber | Any known issue with Compiz+Firefox on Hardy ? Scrolling is extremely slow (smooth scrolling is disabled) ? | 17:03 |
| mjg59 | Try disabling EXA? | 17:03 |
| stgraber | mjg59: any magic xorg.conf option for that ? | 17:05 |
| mjg59 | Option "AccelMethod" "XXA" | 17:05 |
| stgraber | trying | 17:07 |
| nxvl_work | jono: around? | 17:08 |
| jdong | mjg59: you mean XAA? | 17:10 |
| mjg59 | Yes | 17:11 |
| jdong | mjg59: and curiousity-wise, is it generally true that disabling EXA improves Compiz/Firefox scrolling performance? | 17:11 |
| mjg59 | It depends on your driver | 17:13 |
| jdong | which drivers do? | 17:14 |
| jdong | The new fglrx'es have horrible compiz+Firefox performance | 17:14 |
| mjg59 | I've no idea if fglrx even implements EXA | 17:14 |
| jdong | :) | 17:15 |
| stgraber | mjg59: worked | 17:16 |
| jono | nxvl_work: hey | 17:16 |
| stgraber | mjg59: thanks | 17:16 |
| nxvl_work | jono: hi, i'm part of the Peruvian LoCo and we are planning getting official, since we are working for some time now, can you help me on that? | 17:18 |
| jono | nxvl_work: read the docs about how to become an approved team | 17:18 |
| slangasek | jdstrand: I am currently filled with love for libtool, which seems to require rewriting half its guts to be able to support this use case | 17:19 |
| jono | https://wiki.ubuntu.com/LoCoGettingApproved | 17:19 |
| jono | :) | 17:19 |
| nxvl_work | jono: yes, i'm on that, but what i don't understand is about the membership | 17:20 |
| jono | membership? | 17:20 |
| nxvl_work | jono: members are the ones who work helping on the events and projects, didn't they? | 17:20 |
| jono | nxvl_work: members of the loco, yes | 17:20 |
| jono | whats the problem? | 17:20 |
| jdstrand | slangasek: :( | 17:21 |
| jdstrand | slangasek: incidentally, these are the tests that fail: test030-relay test035-meta test036-meta-concurrency | 17:21 |
| cjwatson | slangasek: sigh, you just reminded me I have a postponed mail to bug-libtool from Friday about the horrendous way it gets shell feature checks wrong | 17:22 |
| nxvl_work | jono: now i'm clear, that point i was a little unsure, because i have a lot of members on the mailing list, but not all them help on the projects, so what i don't know is if i include them as members or not | 17:22 |
| jono | nxvl_work: right, the word 'members' usually refers to people on the mailing list :) | 17:22 |
| nxvl_work | jono: so i need to include them? | 17:23 |
| jono | nxvl_work: what do you mean by include them? | 17:23 |
| nxvl_work | jono: there is a point on https://wiki.ubuntu.com/LoCoGettingApproved in which i need to put the number of members we have | 17:24 |
| jono | nxvl_work: right - thats the number of mailing list members too :) | 17:24 |
| nxvl_work | jono: ok, thnx :D | 17:25 |
| jono | :) | 17:25 |
| slangasek | jdstrand: sure, that list looks consistent to me. Solving this requires having a way to declare that back_meta depends on back_ldap, and libtool isn't happy doing this when the module name being linked against doesn't have a name starting with "lib" | 17:30 |
| === blueyed__ is now known as blueyed | ||
| cjwatson | http://algebraicthunk.net/~dburrows/blog/entry/installing-packages-in-safe-upgrade/ <- yay for Daniel Burrows | 17:58 |
| ogra | mvo, is there a secret way to use --root= with gdebi-gtk ? | 18:13 |
| ogra | (at least there is no obvious one) | 18:13 |
| pitti | BenC: do you think that the 2.6.17.1-50.50 edgy-proposed kernel is still useful for anything? If not, I'd like to remove it to clean up the SRUs | 18:16 |
| mvo | ogra: I could make you one if you need one | 18:16 |
| ogra | mvo, would be helpful | 18:16 |
| BenC | pitti: nope, feel free to remove it | 18:17 |
| mvo | ogra: but I need to run for the shop before it closes, please tell me afterwards, should be straightforward | 18:17 |
| ogra | i was surprised gdebi and gdbi-gtk are so different | 18:17 |
| ogra | mvo, fine with me | 18:17 |
| ogra | doesnt need to happen *now* :) | 18:17 |
| === ogra1 is now known as ogra | ||
| pitti | mvo: any chance you could look at bug 163794? it's in -proposed for 14 days | 18:32 |
| ubotu | Launchpad bug 163794 in tzdata "New timezone data 2007i" [Undecided,Fix committed] https://launchpad.net/bugs/163794 | 18:32 |
| calc | can someone process libfonts-java and libxml-java, they are in NEW | 19:17 |
| seb128 | calc: accepted | 19:24 |
| calc | seb128: thanks :) | 19:25 |
| seb128 | you're welcome | 19:25 |
| === chuck is now known as zul | ||
| === cprov is now known as cprov-out | ||
| Riddell | mvo: is I branch a debian package that's maintained in bzr what do I set XS-VCS-Bzr: to? | 20:06 |
| Kmos | Riddell: XS- for VCS is deprecated.. | 20:08 |
| Riddell | good thing I'm branching the packaging then :) | 20:09 |
| slangasek | Riddell: the logical value to use would be the bzr branch corresponding to what gets uploaded to Ubuntu | 20:09 |
| mvo | Riddell: what slangasek said, your branch. what package is it? you may want to put it into ~ubuntu-core-dev or something similar | 20:15 |
| === asac_ is now known as asac | ||
| Riddell | mvo: amarok, I'm putting it into ~kubuntu-members | 20:22 |
| mvo | Riddell: yeah, something like this sounds appropriate | 20:22 |
| mvo | Riddell: nice to see that its maintained in bzr in debian | 20:22 |
| slangasek | dato's rather pro-bzr | 20:22 |
| Riddell | mvo: yes, makes using revision control with packaging seem attractive | 20:23 |
| mvo | :) | 20:23 |
| === \sh_away is now known as \sh | ||
| === \sh is now known as \sh_away | ||
| * jdong pats mjg59's back regarding the MPAA takedown :) | 20:55 | |
| ion_ | jdong: ? | 20:57 |
| alex_joni | hello.. if I build a new LiveCD and want to add a custom GPG key to apt, what would be the steps? | 21:00 |
| * jdong pats mjg59's back regarding the MPAA takedown :) | 21:01 | |
| jdong | aah | 21:01 |
| jdong | stoopid ssh lag | 21:01 |
| jdong | ion_: planet. | 21:01 |
| calc | seb128: can you process liblayout as well? :) | 21:39 |
| frafu | Hello, If I remember correctly, some time ago I downloaded the changes of which revision of a project in launchpad as a diff file; unfortunately I cannot find anymore how to do it. Has that possibility been removed? | 21:42 |
| seb128 | calc: accepted too now | 21:43 |
| calc | seb128: thanks :) | 21:43 |
| cjwatson | frafu: are you thinking of codebrowse.launchpad.net? | 21:53 |
| cjwatson | frafu: if you go to code.launchpad.net for a project, you should find a "browse code" link on the left | 21:54 |
| cjwatson | at least once you get to the page for a branch | 21:54 |
| cjwatson | and, even without going to "browse code", the revision numbers are links to diffs | 21:54 |
| nixternal | mjg59: good work! | 21:54 |
| cjwatson | for example, try https://code.launchpad.net/~ubuntu-installer/ubiquity/trunk - "2372" links to http://codebrowse.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/2372 | 21:55 |
| frafu | cjwatson: yes, but if I remember correctly, I could download it as a patch file | 21:57 |
| frafu | but I cannot find anymore how to do it | 21:58 |
| frafu | :-( | 21:58 |
| cjwatson | frafu: not sure - #launchpad would be a better place to ask | 21:59 |
| frafu | If I remember correctly, I did it a month ago | 21:59 |
| frafu | cjwatson: Thanks; I am going to launchpad... | 22:00 |
| cjwatson | there could easily be a way to do it I'm unaware of | 22:00 |
| frafu | cjwatson: maybe it was only a test, as I am using launchpad beta (ppa) | 22:03 |
| cjwatson | as am I | 22:03 |
| === rob is now known as youdoknow | ||
| === youdoknow is now known as udoknow | ||
| === udoknow is now known as rob | ||
| cjwatson | doko_: I stole your libwps merge, noticing that it was a sync | 23:15 |
| cjwatson | hope that's ok | 23:16 |
| doko_ | cjwatson: many thanks! | 23:17 |
| cjwatson | lamont: ditto for m4 | 23:20 |
| cjwatson | lamont: what's the state of hppa java nowadays? | 23:25 |
| cjwatson | lamont: we seem to be carrying a fair few patches to disable it | 23:25 |
| slangasek | last I pinged him about that, he said it was a bootstrapping matter | 23:26 |
| slangasek | it's bootstrapped in Debian, so I think it's just waiting for someone to do it in Ubuntu | 23:26 |
| cjwatson | doko_: ditto portmap | 23:34 |
| cjwatson | doko_: and genromfs. Done for tonight now :-) | 23:36 |
| doko_ | cjwatson: do we want libssh2 in main (curl wants to introduce it)? | 23:36 |
| cjwatson | I don't mind, I don't think it's really duplicating anything | 23:37 |
| cjwatson | openssh is unlikely to ever provide or use a shared library | 23:37 |
| cjwatson | and it seems useful for there to be one | 23:37 |
| doko_ | ok | 23:38 |
| doko_ | cjwatson, lamont: still getting bus errors, so it may be disabled for debian as well. I think jbailey did want to look at the problems | 23:39 |
| TheMuso | If I've found a problem with the seeds, where is the best place to file a bug? Its not a big change, just a slight package name adjustment. | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!