| YokoZar | savvas: That's obviously a hard problem, as different websites will have different demographics and some will have incentives to lie. It's a similar problem to television ratings. That said, there are groups out there that do try and get wide, representative statistics by polling a whole bunch of different "representative" websites to some extent. Not surprisingly, their estimates of Linux usage vary, but generally not by mor | 00:01 |
|---|---|---|
| YokoZar | ajmitch: I imagine Ubuntu is more popular in regions of the world where internet access is really awful. I could be wrong about that though. | 00:02 |
| savvas | YokoZar: then the only way is to get out there and ask :) | 00:03 |
| YokoZar | savvas: pretty sure polling websites that have millions of visitors is a bit easier than asking millions of people ;) | 00:03 |
| ajmitch | I would have thought that at least in countries with more developed infrastructure that ubuntu is more popular amongst the technically literate | 00:03 |
| mathiaz | is invoke-rc.d supposed to be run by sysadmin or its usage is mainly reserved for maintainer scripts? | 00:03 |
| ajmitch | whether they balance out, I don't know :) | 00:04 |
| YokoZar | ajmitch: yeah, it's a good point. It's not clear at all which way it'll go | 00:04 |
| ajmitch | mathiaz: I believe it's to be used by the sysadmin instead of calling the initscript directly | 00:04 |
| ajmitch | at least I regularly use it :) | 00:04 |
| james_w | mathiaz: it's there so that the admin can enforce policy via. policy-rc.d I believe, so an admin probably knows their policy and doesn't need to use it | 00:05 |
| james_w | mathiaz: I don't think there would be an issue with them using it though | 00:05 |
| james_w | mathiaz: does kirkland use it for the service command? | 00:05 |
| mathiaz | james_w: good question I was looking into that as well | 00:06 |
| james_w | mathiaz: nope, he uses calls invoke-rc.d | 00:07 |
| ajmitch | the manpage doesn't say anything either way about it, but there is bash completion for invoke-rc.d which indicates that at least a few people use it directly | 00:08 |
| mathiaz | james_w: ajmitch: ok - thanks for your input :) | 00:09 |
| jelmer | slangasek, I think I've got that grub branch working | 00:43 |
| slangasek | oooooh | 00:43 |
| jelmer | slangasek, I'll put my copy of the svn repository up somewhere - any chance you can double-check? | 00:44 |
| slangasek | jelmer: sure; what am I double-checking? | 00:45 |
| jelmer | slangasek, basically the way bzr-svn does the operations on history | 00:46 |
| jelmer | http://samba.org/~jelmer/tmp/pkg-grub-svn-log | 00:46 |
| slangasek | jelmer: I guess that looks sensible to me; why does it look all svn-y, though? That would seem to be the opposite of anything I would ever be doing with it | 00:50 |
| jelmer | slangasek, this is the svn log | 00:50 |
| jelmer | slangasek, not the bzr log | 00:51 |
| slangasek | well, yes, I can see that it's an svn log, I just have no idea what that should signify :) | 00:51 |
| jelmer | the bzr log just looks like the bzr branch you provided to me | 00:51 |
| jelmer | slangasek: these operations match what's being done in bzr | 00:53 |
| jelmer | slangasek, If it looks ok, I'll push these changes | 00:54 |
| slangasek | jelmer: ok, then I think it looks right from what I can see | 00:56 |
| cjwatson | we aren't going to lose the committer information, are we? (noting that all the committers are "jelmer" there) | 01:05 |
| slangasek | Keybuk: I like that you uploaded nut to fix the udev rule paths, but didn't notice it was calling udevtrigger :-) | 01:05 |
| jelmer | cjwatson: The committer information from bzr will still be there, in revision properties (that bzr-svn will read back) | 01:06 |
| jelmer | cjwatson, the person pushing the bzr revisions into svn will be marked as author of those revisions in svn though | 01:06 |
| slangasek | jelmer: we never push any of this into svn | 01:07 |
| slangasek | not sure if you missed that point? | 01:07 |
| slangasek | (or if it matters to what you're doing) | 01:07 |
| jelmer | slangasek, it's never been pushed in the past, but you intend to push it into svn now though, right? | 01:08 |
| slangasek | no | 01:10 |
| slangasek | I don't have write access to the svn repo | 01:10 |
| slangasek | and am not seeking it | 01:10 |
| slangasek | my concern is being able to /pull/ from svn | 01:11 |
| jelmer | ahhh | 01:11 |
| jelmer | I misunderstood then, sorry | 01:11 |
| slangasek | does that change the scope of the problem? | 01:12 |
| jelmer | yeah, I was fixed pushing the current bzr branch back into svn (which is also a nice feature :-) | 01:13 |
| slangasek | right :) | 01:13 |
| jelmer | s/was// | 01:14 |
| jelmer | slangasek: So what is it exactly you'd like to get working? | 01:26 |
| jelmer | basically "bzr merge <svn-url>" ? | 01:26 |
| slangasek | jelmer: yes | 01:26 |
| jelmer | so there are two things I can do | 01:26 |
| jelmer | either merge in the existing revisions that were merged in previously. that'll duplicate the revisions in the log (once merged by you, once merged by me) | 01:27 |
| jelmer | or I can fix up the revisions that were merged earlier, but that'll change the revision ids of the branch | 01:27 |
| jelmer | the latter would require everybody who is using the branch to drop their old copies and refetch the bzr branch | 01:28 |
| jelmer | is there either you'd prefer? | 01:28 |
| jelmer | slangasek, ^ | 01:29 |
| slangasek | jelmer: I'm checking whether there are any other branches published on LP that #2 would disrupt | 01:29 |
| slangasek | kirkland: do you care if jelmer makes a change that breaks your existing branches on LP? | 01:30 |
| slangasek | lool: do you have any outstanding changes based on the LP grub package branch? | 01:30 |
| slangasek | jelmer: we might have to wait 18h or so to get those answers :) I'd prefer option 2 myself, is it ok to wait until we hear back from lool and kirkland before going ahead with this? | 01:32 |
| jelmer | slangasek, yeah, no problemo | 01:33 |
| TheMuso | Is it just me, or is sudo broken on the latest amd64 alternate CD? I just did a fresh install on a box, to find that /etc/sudoers didn't have the admin group added. Could be either sudo or user-setup. | 01:34 |
| slangasek | it shouldn't be user-setup; surely sudoers should ship right out-of-the-box in the sudo package? | 01:34 |
| TheMuso | well it appears that the admin group wasn't in sudoers, and I am not in the admin group. | 01:36 |
| slangasek | oh | 01:36 |
| slangasek | user-setup, then :-) | 01:36 |
| * TheMuso enters recovery mode to fix things. | 01:37 | |
| slangasek | not sure why we don't patch the sudoers generation in sudo itself, though | 01:37 |
| === jcm is now known as jonmasters | ||
| pwnguin | fun tip: migrating from ext3 to ext4 changes the partition's uuid | 03:10 |
| === hyperair_ is now known as hyperair__ | ||
| === hyperair__ is now known as hyperair | ||
| [reed] | hmm, three kernels just today? | 04:58 |
| [reed] | (intrepid) | 04:58 |
| === bluesmoke_ is now known as Amaranth | ||
| dholbach | good morning | 06:15 |
| highvoltage | and so it is | 06:18 |
| superm1 | pitti, i was wondering if i could pick your brain for other ideas you had (but just hadn't implemented) for jockey's package installation method. since switching to dbus, you lost package the progressive package install status (and support for a vte widget etc). is that stuff not passable over dbus at all easily? | 06:19 |
| superm1 | pitti, i'm looking at needing something similar for a rewrite of another application that i've been working on and would like to policykitify it move the installation routines to a dbus spawned service | 06:20 |
| superm1 | pitti, what i was thinking (but hadn't looked into much yet) was passing the DISPLAY and necessary X auth information over dbus to the service. if the service could then gain access to the display, it could spawn it's own methods for displaying status, and then when it finishes, send another dbus message telling the client to come back to life | 06:53 |
| kirkland | slangasek: hmm, i'm curious what branches in LP would be affected | 07:13 |
| kirkland | slangasek: i'll try to read some more back scroll | 07:13 |
| kirkland | slangasek: i'm sort of on vacation today in Germany/Austria | 07:13 |
| kirkland | james_w: mathiaz is right, i only use invoke-rc.d in /usr/bin/service | 07:15 |
| kirkland | jelmer: slangasek: oh, if this would only affect my grub branches, go right ahead... i don't think i have anything un-merged in there | 07:16 |
| pwnguin | what's this about grub? | 07:16 |
| kirkland | well, i do have an ubuntu logo'd grub splash screen, that hasn't been merged :-) | 07:16 |
| kirkland | but that's fine | 07:16 |
| pwnguin | im having a great time with grub and ext4 right now. im assuming currently im doing it wrong | 07:17 |
| dholbach | kirkland: where are you hanging out atm? | 07:18 |
| kirkland | dholbach: munich atm, heading to innsbruck in a few minutes | 07:18 |
| dholbach | enjoy :) | 07:18 |
| kirkland | dholbach: cheers, see you in berlin ;-) | 07:29 |
| dholbach | take care :) | 07:30 |
| pitti | Good morning | 07:31 |
| pitti | superm1: I have partial progress report, but it isn't very accurate (just what apt gives me) | 07:34 |
| pitti | superm1: no, unfortunately the backend doesn't have any connection to the frontend at all, same problem as with packagekit | 07:35 |
| pitti | superm1: passing $DISPLAY and cookie would certainly work, but it's really quite hackish and not really intended to be used that way | 07:35 |
| pitti | superm1: what happens in jockey is that the backend sends progress signals to the frontend, and the frontend listens to those and updates the UI accordingly | 07:35 |
| pitti | superm1: thus the lack of good progress information is really a packagekit/python-apt problem, not an intrinsic one of d-bus backends | 07:36 |
| === hyperair_ is now known as hyperair__ | ||
| === hyperair__ is now known as hyperair | ||
| === hyper323 is now known as hyperair | ||
| tkamppeter_ | pitti, hi | 08:28 |
| === tkamppeter_ is now known as tkamppeter | ||
| pitti | hey tkamppeter | 08:34 |
| tkamppeter | piiti, why did you reject bug 321164 for Intrepid? It is exactly this bug which caused the regression in the original SRU. The second SRU fixes exactly this bug. | 08:35 |
| ubottu | Launchpad bug 321164 in foomatic-filters "Ubuntu 9.04 has a problem with Laser Printer HL-1435" [High,Fix released] https://launchpad.net/bugs/321164 | 08:35 |
| pitti | tkamppeter: right, but there was another bug for this regression already, which was reported against jaunty | 08:35 |
| tkamppeter | Bug 318614 was originally reported about another segfault which the first SRU perhaps already fixed, but the original poster never answered. Later someone discovered the other problem in 4.0.0 final and hijacked this bug. I told him where "his" bug is to continue discussion there. | 08:38 |
| ubottu | Launchpad bug 318614 in foomatic-filters "foomatic-rip crashed with SIGSEGV" [Undecided,Fix committed] https://launchpad.net/bugs/318614 | 08:38 |
| tkamppeter | What confused you was probably that both bugs are segfaults.. | 08:38 |
| tkamppeter | The segfault which caused me to fix the SRU was a bug which was perhaps already in the BZR rev 177 which came with Intrepid, but to trigger it one needs a driver which puts at least seven lines of PJL into its output or a PPD with at least seven PJL options. This is rather rare and by accident this was a user who downloaded the first SRU of foomatic-filters. It was not in the code which I added between 177 and 195 (final) but perhaps m | 08:43 |
| tkamppeter | y code additions raised the probability to hit it. | 08:43 |
| pitti | tkamppeter: the changelog made it sound like it was the same bug | 08:45 |
| pitti | tkamppeter: okay, asking for testing on 321164 then | 08:46 |
| tkamppeter | pitti, I have already asked for testing there, simply open the Intrepid task and add the tags. | 08:46 |
| === thekorn_ is now known as thekorn | ||
| tkamppeter | pitti, thanks. | 08:47 |
| lool | slangasek: I actually have one grub patch in my mailbox, but I don't think it should block any grub upload if that's the reason you're asking | 09:33 |
| slangasek | lool: it's not about grub uploads, it's about rebasing the ~ubuntu-core-dev grub branch to fix some bzr-svn brokenness and invalidate any branches based on it | 09:34 |
| doko_ | slangasek, lool: 299847: only builds because test suite results are ignored. how do you want to track this? | 09:37 |
| slangasek | doko_: oh. Ok, do we have any idea what the root cause is? Is it really related to this package..? | 09:38 |
| doko_ | slangasek: no, I didn't check | 09:38 |
| slangasek | ok | 09:38 |
| slangasek | then reopen it, I guess :/ | 09:38 |
| lool | slangasek: That's fine, I have the file as a patch | 09:38 |
| slangasek | I thought it was a build failure earlier, though, and the version number has only incremented by 1x build? | 09:39 |
| lool | Not a branch | 09:39 |
| slangasek | lool: ok, thanks | 09:39 |
| lool | slangasek: thanks for checking | 09:39 |
| slangasek | jelmer: please go ahead with fixing up the repo using method #2 | 09:39 |
| === seb128_ is now known as seb128 | ||
| doko_ | retitled and reopened | 09:42 |
| seb128 | slangasek: hi | 09:45 |
| slangasek | seb128: heya | 09:45 |
| seb128 | slangasek: about your gnome-screensaver issue do you set some im method setting? there is a recent gtk+2.0 similar to your gnome-screensaver one where user state they have issues only when changing im settings | 09:46 |
| seb128 | I didn't investigate yet though | 09:46 |
| slangasek | seb128: heh | 09:46 |
| RAOF | So! Who wants to make f-spot and banshee simultaneously installable? | 09:46 |
| slangasek | $ env|grep IM | 09:46 |
| slangasek | GTK_IM_MODULE=xim | 09:46 |
| slangasek | seb128: ^^ | 09:46 |
| seb128 | slangasek: ok, you can dup the gtk+2.0 bug of yours which was opened before and reassign to gtk+2.0 then ;-) | 09:46 |
| seb128 | slangasek: check before that you don't get the issue if you unset that | 09:47 |
| slangasek | seb128: because the default GTK IM reinvents the wheel on compose sequences - I'd love to not have to set that :P | 09:47 |
| slangasek | yep, testing now | 09:47 |
| RAOF | bug #314516 has a nice big debdiff for it. | 09:47 |
| ubottu | Launchpad bug 314516 in tomboy "gnome-sharp2 transition" [Medium,Confirmed] https://launchpad.net/bugs/314516 | 09:47 |
| slangasek | dup which bug? | 09:47 |
| seb128 | slangasek: the newest gtk+2.0 bug in the list if you ignore the installation bugs listed there iirc, let me check | 09:48 |
| seb128 | just reassign yours to gtk+ if you want | 09:49 |
| seb128 | I will do cleaning | 09:49 |
| slangasek | ok, will test first | 09:49 |
| slangasek | seb128: yep, works now :( | 09:49 |
| seb128 | slangasek: ;-) | 09:49 |
| slangasek | hmm, it's possible that I don't need GTK_IM_MODULE set anymore for my env, the compose settings seem to have caught up with iso8859-2 | 09:51 |
| slangasek | but that's still a pretty big bug for CJK, I guess | 09:52 |
| Keybuk | slangasek: I wasn't looking for that at the time ;) | 09:53 |
| lool | doko_, slangasek: libipc-sharelite-perl on my armel babbage: All tests successful. | 09:53 |
| doko_ | lool: maybe it is fixed. re-upload and see if it testsuite results are ok on the buildds? | 09:54 |
| lool | pushed | 09:56 |
| slangasek | seb128: ok - which direction will you dupe them? I want to make sure the release-manager-y tags are all set right afterwards :) | 09:57 |
| seb128 | slangasek: I will keep yours open which already has a jaunty task | 09:57 |
| slangasek | ok | 09:58 |
| * slangasek heads off to bed to get a few hours of shut-eye before the release meeting | 09:59 | |
| seb128 | 'night slangasek | 09:59 |
| slangasek | 'night! | 09:59 |
| tkamppeter | pitti, what about the CUPS SRU? Can we already put ...ubuntu7 into -updates and let ...ubuntu8 into -proposed? | 10:00 |
| pitti | tkamppeter: no, the bug wasn't verified yet | 10:23 |
| pitti | cjwatson, Riddell: (preparing release team meeting) -- question about bug 310575, is it in the pipe, or blocked by something? | 10:24 |
| ubottu | Launchpad bug 310575 in cups "A3 pdf file is cropped and printed on A4 paper" [Undecided,Fix committed] https://launchpad.net/bugs/310575 | 10:24 |
| pitti | cjwatson, Riddell: sorry, bug 309482 | 10:25 |
| ubottu | Launchpad bug 309482 in oem-config "jaunty: Kubuntu OEM enduser setup fails" [Undecided,New] https://launchpad.net/bugs/309482 | 10:25 |
| Riddell | pitti: I've not seen that bug, but I can try and look into it | 10:27 |
| tkamppeter | pitti, it is bug 310575, the one who reported the bug was not available thios week, he will be back only next week. Should we give the next week only to him to verify and release the other fixes for verification only the week after or should we release the other fixes now (superceding the current -proposed package) so that all four bug reporters can verify? | 10:27 |
| ubottu | Launchpad bug 310575 in cups "A3 pdf file is cropped and printed on A4 paper" [Undecided,Fix committed] https://launchpad.net/bugs/310575 | 10:27 |
| cjwatson | pitti: I'd been planning to today, but of course it would probably be quicker if somebody who knows KDE did so | 10:28 |
| lool | doko_, slangasek: Failed on the buildd; it could be a SHM conflict, but this would fail *all* tests, so it might be some missing underlying SHM support; this might be board specific | 10:29 |
| lool | I'm trying on my evm | 10:29 |
| === asac_ is now known as asac | ||
| pitti | Riddell: was there a decision about IRC client in the recent Kubuntu meeting? (for https://blueprints.edge.launchpad.net/ubuntu/+spec/kubuntu-jaunty-kde-packaging) | 10:37 |
| lool | doko_: So it passed on my evm as well; I think this kind of renders the bug slightly less important, but it's blocked until we can have a look at the failure in the buildd's environment | 10:38 |
| tkamppeter | pitti, it is bug 310575, the one who reported the bug was not available thios week, he will be back only next week. Should we give the next week only to him to verify and release the other fixes for verification only the week after or should we release the other fixes now (superceding the current -proposed package) so that all four bug reporters can verify? | 10:47 |
| ubottu | Launchpad bug 310575 in cups "A3 pdf file is cropped and printed on A4 paper" [Undecided,Fix committed] https://launchpad.net/bugs/310575 | 10:47 |
| Riddell | pitti: we want to go for Quassel | 10:47 |
| pitti | Riddell: ah, cool; can you please update the spec accordingly? I'll review it immediately, so that we have this off the table | 10:48 |
| Riddell | yep | 10:48 |
| pitti | Riddell: cheers | 10:48 |
| Riddell | pitti: done | 10:51 |
| pitti | Riddell: and approved | 10:53 |
| tkamppeter | pitti, what about my question concerning the CUPS SRU? | 10:56 |
| pitti | tkamppeter: getting to it, still finishing the release report | 10:56 |
| lool | asac: FYI ogra tested firefox on armel and it worked fine in his experience (but it was a little while ago) | 10:56 |
| ogra | asac, you can test yourself next week :) | 10:57 |
| pitti | tkamppeter: yes, I prefer to not stack multiple updates on top of each other; by now, really none of intrepid's bugs are high-urgency | 11:07 |
| pitti | tkamppeter: if you want, you can upload ubuntu8 as ubuntu8~till1 into your intrepid PPA and ask reporters to test that (if you are unsure whether the patches really help) | 11:08 |
| asac | lool: ogra: thanks. | 11:10 |
| tkamppeter | pitti, I think this is not needed. So let us leave this week for getting an answer on bug 310575 and depending on whether we get the answer you advance the CUPS SRU queue on one of your next scheduled SRU day. In the time being I will simply commit SRU fixes as they come to the BZR. | 11:11 |
| ubottu | Launchpad bug 310575 in cups "A3 pdf file is cropped and printed on A4 paper" [Undecided,Fix committed] https://launchpad.net/bugs/310575 | 11:11 |
| pitti | tkamppeter: right; but please keep in mind that we really must slow down SRUs for intrepid; only truly major fixes | 11:11 |
| tkamppeter | I hope there are no more SRU fixes needed, though. I think now all issues are covered. | 11:11 |
| lool | mvo, seb128: the trigger upgrade issues with libxine segfaulting seem awfully similar to the xine-lib crash we had in intrepid-proposed: under some locales, xine will crash | 12:07 |
| seb128 | lool: is there any xine code run during the install? | 12:09 |
| lool | seb128: There's a trigger related to xine I think | 12:11 |
| lool | seb128: There was a security update of xine, it would well have cause the problematic code to be run under a non-C locale | 12:11 |
| seb128 | lool: ok, I see | 12:12 |
| jelmer | slangasek, ok | 12:21 |
| kwwii | asac: stupid question, but where does nm-applet keeps it's icons? | 12:21 |
| asac | kwwii: http://pastebin.com/fe73ebf2 | 12:23 |
| kwwii | asac: sweet, thanks | 12:28 |
| mdeslaur | lool, seb128: Is there something wrong with the xine-lib security update? | 12:55 |
| lool | mdeslaur: The upload I did to -proposed was addressing a crash when xine scans for plugins under some locales; I suspect your security update triggers this bug | 12:59 |
| === thekorn_ is now known as thekorn | ||
| mdeslaur | lool: oh, and you now pushed another to -proposed to fix it again? | 13:02 |
| lool | mdeslaur: Yes, but it will take ~10 days | 13:03 |
| lool | Since we need to retest | 13:03 |
| lool | mdeslaur: Actually we pushed two fixes for this issue, either suffices | 13:04 |
| lool | mdeslaur: https://bugs.launchpad.net/bugs/290768 | 13:04 |
| ubottu | Launchpad bug 290768 in xine-lib "C format string specifications mismatch in translations crashes libxine based apps in some loales" [Undecided,Fix committed] | 13:04 |
| lool | Oh you know about it already | 13:05 |
| lool | Since you sent the debdiff there | 13:05 |
| mdeslaur | lool: yeah, that's what our procedure is...release a security update without what's in -proposed | 13:06 |
| lool | cjwatson, slangasek, pitti: I uploaded langpacks 10 days ago | 13:06 |
| mdeslaur | sorry about that | 13:06 |
| lool | cjwatson, slangasek, pitti: Might be worth promoting the langpacks to -updates now | 13:06 |
| lool | Context: 290768 might have been triggered in a new way via a -security update | 13:06 |
| lool | mdeslaur: Not your fault; it's unfortunate but it's a race between fixing the crash and fixing the security holes | 13:07 |
| mdeslaur | hehe | 13:07 |
| cjwatson | lool: main problem is that there seems to be no independent verification that the new language packs alone fix this | 13:23 |
| lool | cjwatson: I sent an update to the TB thread | 13:23 |
| lool | cjwatson: I find it weird that the installed xine version is the old -proposed one and the locales don't seem to be either german or italian | 13:24 |
| lool | cjwatson: But it's really suspicious | 13:24 |
| ogra | asac, hmm, shouldnt FF offer me some gnash or swfdec love if i go to youtube (on armel) | 13:47 |
| ogra | all i get is the link to adobe that only offers x86 versions indeed | 13:48 |
| * ogra tries video.google.com instead | 13:48 | |
| ogra | aha, there i get the proper thing | 13:49 |
| * ogra wonders if it will ever find something ... still checking for available plugins | 13:51 | |
| asac | ogra: no | 13:52 |
| asac | ogra: yeah. video google works | 13:52 |
| asac | ogra: unlikely | 13:52 |
| asac | ogra: is armel on archive.ubuntu.com yet? | 13:52 |
| asac | or ports? | 13:53 |
| ogra | asac, ports | 13:53 |
| ogra | and it will stay there | 13:53 |
| asac | yeah. we currently dont index those | 13:53 |
| asac | hmm | 13:53 |
| ogra | oh, we need to | 13:53 |
| ogra | lets talk about that next week then | 13:53 |
| ogra | there is also a flash for arm (maemo uses it) but not publically downloadable afaik | 13:54 |
| asac | ogra: yes. needs a fix of the database updater. | 13:54 |
| asac | lpia is also on ports afaik | 13:54 |
| ogra | right | 13:54 |
| lool | cjwatson: I tried to reproduce the original xine-lib issue in a vm with the it langpack, the it locale generated, and running "xine-list-1.1 --all" under LANG=it_IT.UTF-8 to no luck (I even installed libxine1-all-plugins) | 13:58 |
| lool | cjwatson: I suspect it might be ~/.xine/config or similar pointing at additional plugins to load | 13:58 |
| lool | I couldn't find a way to trigger more verbose behavior | 13:58 |
| lool | cjwatson: So I can't check whether the gxine issue relates | 13:59 |
| __Ali__ | how can i access the source directory name in debian/rules? | 14:10 |
| lool | __Ali__: $(CURDIR) | 14:12 |
| __Ali__ | lool: $(CURDIR) doesnt work? dpkg-buildpackage extracts the source into a temp dir | 14:13 |
| ScottK | james_w: Do you have a moment to discuss your latest changes to your DD/DebianImport spec? | 14:13 |
| james_w | ScottK: I have a moment, but little more right now I'm afraid | 14:14 |
| james_w | I'm happy to start discussing it, but we may have to take it to email if it's a longer discussion | 14:14 |
| ScottK | Sounds good. | 14:14 |
| ScottK | james_w: OK. The concern I have is social, not technical. I think that while you make a good technical argument for basing the Debian branches off the Ubuntu ones, I think it is likely to be perceived unfortunately in Debian. | 14:15 |
| ScottK | If the DistributedDevelopment model is successful, it will be with us for a very long time. | 14:15 |
| lool | __Ali__: I'm afraid I don't see what you're talking about then | 14:16 |
| * broonie seconds ScottK - that's going to play rather poorly with a lot of people. | 14:16 | |
| ScottK | And so it seems to me like your proposal, while technically sound, trades short term expediency for a long term source of friction with our major upstream. | 14:16 |
| james_w | ScottK: but these branches won't be. Whenever we rewrite, which has to be done at some point, it will end up the right way round | 14:16 |
| ScottK | So this is a temporary, experimental set of branches? | 14:17 |
| james_w | not so much experimental | 14:17 |
| james_w | but it trades short-term expediency for possible medium-term friction | 14:17 |
| ScottK | I think the friction will be immediate and ongoing. | 14:18 |
| ScottK | You just got some. | 14:18 |
| __Ali__ | lool: i followed this instruction: http://www.debian.org/doc/manuals/maint-guide/ , it should be valid for ubuntu as well? | 14:18 |
| ScottK | james_w: So that's my concern. Please consider it and we can discuss via email. | 14:19 |
| cjwatson | __Ali__: no, dpkg-buildpackage doesn't extract the source into a temporary directory. Some debian/rules implementations do that. | 14:19 |
| cjwatson | ScottK: heh, I was just making a fairly similar point to James by /msg :-) | 14:19 |
| ScottK | ;-) | 14:19 |
| lool | __Ali__: Perhaps you can be more specific in the error you see, which package, what you're trying to do etc. | 14:19 |
| ScottK | cjwatson: I've got a thought for you on archive reorg too that I'd like to discuss when you have a moment. | 14:20 |
| cjwatson | ScottK: sure | 14:20 |
| ScottK | IIRC, the discussion to date on sub-teams has been around seeds. | 14:20 |
| ScottK | But in many cases I don't know that will be the best model. | 14:21 |
| cjwatson | ScottK: Mark feels quite strongly that we should also have the ability to have layers formed from hand-maintained lists of packages; I don't see that we lose anything by having that flexibility and so the spec does mention that possibility | 14:21 |
| ScottK | As an example, currently clamav is in Main and only seeded on Server. I do most of the maintenance work on that and it's rdepends. | 14:21 |
| __Ali__ | cjwatson and lool: after running debhelper, I get mylib/debian dir, then i cd to mylib dir and run dpkg-buildpackage, obviously there is no source file in mylib dir which is $(CURDIR) | 14:22 |
| ScottK | If I were not a core-dev, but only interested in server, with the current proposal, I'd lose access to upload all the non-server rdepends. | 14:22 |
| cjwatson | although there is also no reason we couldn't have extra miniature seed collections that correspond to things like clamav-and-friends | 14:22 |
| ScottK | Alternatively, for the Kubuntu team, if someone is good enough to have upload rights to the KDE stuff we ship on CD, it makes no sense they can't upload the stuff that's not seeded. | 14:23 |
| cjwatson | __Ali__: your statement is very confusing on a number of levels. The debian/ subdirectory is typically a child of the top-level directory where the upstream package is extracted. | 14:23 |
| ScottK | The more I think about what I think are the likely areas of interest, the less I think they are really likely to correspond well with seeds. | 14:23 |
| cjwatson | __Ali__: so if upstream ships foo_1.0.orig.tar.gz extracting into foo-1.0/, then you'd have foo-1.0/debian/ | 14:23 |
| cjwatson | there are plenty of cases that do, and plenty that don't | 14:24 |
| ScottK | OK. | 14:24 |
| cjwatson | also, you're looking at the current set of seeds which are very very broad | 14:24 |
| cjwatson | if we were actually using them for access control, we'd have finer-grained sets, I think | 14:24 |
| ScottK | OK. | 14:24 |
| __Ali__ | cjwatson: foo-1.0/ has only debian, nothing else, do i have to extract the source manually to foo-1.0/? | 14:24 |
| cjwatson | __Ali__: normally you would extract the upstream source *before* running dh_make or whatever | 14:25 |
| cjwatson | if you've just created a blank directory and run dh_make in that, you're doing it wrong | 14:25 |
| __Ali__ | cjwatson: i fed the tarball to debhelper, it wasnt extracted initially | 14:26 |
| cjwatson | you "fed the tarball to debhelper"? using what command? | 14:26 |
| cjwatson | ScottK: I think where the spec says "seeds", my intent was that people think of abstract seeds (i.e. list of top-level packages, dependency-expanded) rather than the ones we have now | 14:27 |
| __Ali__ | cjwatson: dh_make -f ../foo-1.0.tar.g | 14:27 |
| cjwatson | ScottK: maybe I was underestimating people's mental link with the current model | 14:27 |
| ScottK | cjwatson: OK. That makes sense. | 14:27 |
| ScottK | Mine in any case .... | 14:27 |
| ScottK | cjwatson: Also I think one should also be able to do reverse dependency expansion. | 14:28 |
| ScottK | That would cover most of the cases I was considering. | 14:28 |
| cjwatson | __Ali__: the manual page says that it extracts it; but if it doesn't, then extract it yourself | 14:28 |
| __Ali__ | cjwatson: thanks | 14:28 |
| ScottK | cjwatson: For example for the Kubuntu/KDE team, I think it'd be reasonable to describe it's area of interest of the depends of the KDE library packages and all the things that in turn depend on them. | 14:29 |
| cjwatson | hmm | 14:30 |
| cjwatson | that's interesting, although I would say that it might have unexpected results | 14:30 |
| ScottK | It might. | 14:30 |
| cjwatson | particularly when you consider source packages that build both GNOME and KDE variants | 14:30 |
| cjwatson | I think it's likely to suck in much of the archive | 14:31 |
| ScottK | True, but if you think of a team that 'knows how to package KDE stuff', that's what their interest would cover. | 14:31 |
| cjwatson | my inclination would be to give the Kubuntu/KDE team the ability to nominate stuff they're interested in, and for the archive admins to be very liberal about acknowledging basically anything with a k at the front :) | 14:31 |
| ScottK | Now the ones that support both, then fall into the the multi-seeded set. | 14:31 |
| ScottK | I'm using that as an example, but I think it's a general case. | 14:32 |
| cjwatson | it's also worth noting that germinate has absolutely no idea how to do this - it would be a complicated development project | 14:32 |
| ScottK | It might be that in the overlap case you'd have to look at which way to push it. | 14:32 |
| cjwatson | and I'm already aware that this is a complicated project as it is and am striving for simplification | 14:32 |
| ScottK | Understand. | 14:33 |
| ScottK | Maybe this is a future capability then and we do manual adjustments as needed in the meantime. | 14:33 |
| ScottK | cjwatson: So that's my thought. Up to you what of it you find worth taking up. | 14:34 |
| pitti | tseliot, bryce: do you know if there's anything like an ETA for nvidia/fglrx drivers which work with our X.org? | 15:17 |
| pitti | tseliot, bryce: i. e. do we have a contact to them? | 15:17 |
| tseliot | pitti: I'm working on the nvidia right now | 15:17 |
| pitti | tseliot: oh, it's in the open source bits? | 15:18 |
| pitti | or upstream has a new release? | 15:18 |
| tseliot | new upstream releases | 15:18 |
| tseliot | pitti: but I want to make sure that other fixes are included in the new packages before an upload | 15:18 |
| pitti | tseliot: rock, thanks (just needed a quick status update for release meeting) | 15:19 |
| * pitti hugs tseliot | 15:19 | |
| tseliot | np | 15:19 |
| Amaranth | tseliot: catalyst 9.1 doesn't support the new ABI? | 15:33 |
| tseliot | Amaranth: I don't know. You should ask superm1 since he's the maintainer. | 15:34 |
| === mbiebl_ is now known as mbiebl | ||
| tkamppeter | pitti, can you have a look at bug 323224? | 16:13 |
| ubottu | Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/323224/+text) | 16:13 |
| pitti | tkamppeter: in meeting, please subscribe me and ask your question there | 16:13 |
| slangasek | mvo: ping | 16:18 |
| mvo | slangasek: pong | 16:18 |
| slangasek | mvo: hi, did you happen to see my followup to bug #318442? Do you think my proposal is the right solution? | 16:19 |
| ubottu | Launchpad bug 318442 in command-not-found "openjdk-6-jdk should be the default/priority for javac" [Undecided,Confirmed] https://launchpad.net/bugs/318442 | 16:19 |
| mvo | slangasek: I looked at your changes in bzr | 16:20 |
| mvo | slangasek: I agree with your reasoning | 16:21 |
| slangasek | ok | 16:21 |
| mvo | slangasek: adding it to the database should be fine | 16:21 |
| slangasek | cool; I'll try to come up with some code for that in my copious free time then :-) | 16:22 |
| superm1 | Amaranth, as far as i'm aware it doesn't still. | 16:23 |
| mvo | slangasek: nice, thanks. we can do a bit of work on this on the sprint if you want | 16:23 |
| slangasek | sounds good | 16:23 |
| === dholbach_ is now known as dholbach | ||
| pitti | slangasek: fix for bug 314263 uploaded, FYI (the "apport opens file:///" one) | 16:32 |
| ubottu | Launchpad bug 314263 in glib2.0 "regression - URIs opened with firefox %u load as local files (file:///...)" [High,Triaged] https://launchpad.net/bugs/314263 | 16:32 |
| slangasek | pitti: sweet \o/ | 16:32 |
| dholbach | superm1: coolbhavi has updated firmware-tools to 2.1.5 in bug 321866 for jaunty - is that alright? | 16:40 |
| ubottu | Launchpad bug 321866 in firmware-tools "Please update firmware-tools to the latest version 2.1.5" [Undecided,Confirmed] https://launchpad.net/bugs/321866 | 16:40 |
| superm1 | dholbach, yeah should be fine | 16:41 |
| dholbach | rock on | 16:41 |
| dholbach | I'll sponsor it in a bit then | 16:41 |
| superm1 | dholbach, that reminds me i need to double check on libsmbios to see if debian pulled in the new version too | 16:41 |
| superm1 | thanks dholbach | 16:41 |
| __Ali__ | isn't dpkg-source supposed to create the .dsc file? | 16:50 |
| __Ali__ | it does not generate it for me | 16:51 |
| tseliot | __Ali__: debuild -S will do it | 16:51 |
| __Ali__ | tseliot: debuild? | 16:52 |
| tseliot | __Ali__: yes, install the "devscripts" package, then enter the directory with the source and type debuild -S | 16:54 |
| tseliot | __Ali__: for further information: https://wiki.ubuntu.com/PackagingGuide/Complete | 16:54 |
| __Ali__ | tseliot: does debuild call dpkg-source or do i have to call debuild after dpkg-source? | 16:54 |
| __Ali__ | ok thanks | 16:55 |
| tseliot | __Ali__: just use debuild | 16:56 |
| __Ali__ | tseliot: i dont want to build the package, i just want to create orig.tar.gz and diff.tar.gz and .dsc to upload them to opensuse build service | 16:58 |
| __Ali__ | i just need to package the source and create the required files, not actually compiling | 16:58 |
| cjwatson | debuild -S does what you ask | 16:58 |
| cjwatson | as tseliot already told you | 16:58 |
| __Ali__ | cjwatson: so it doesnt actually build? | 16:59 |
| ogra | alternatively dpkg-buildpackage | 16:59 |
| cjwatson | no. read the documentation | 16:59 |
| tseliot | __Ali__: if you read where it says "Building the Source Package" in that guide you will see why I suggested to use debuild -S | 16:59 |
| cjwatson | ogra: just one option I think, to avoid confusion | 16:59 |
| __Ali__ | ok ok | 16:59 |
| fta2 | is there a known problem with sasldb2? it makes sendmail-mta crash so no SMTP AUTH is possible (jaunty) | 17:01 |
| fta2 | hm, sasldblistusers crashes too | 17:02 |
| bluefoxicy | PID USER PR NI VIRT RES SHR S PU %MEM TIME+ COMMAND | 17:22 |
| bluefoxicy | 30779 root 20 0 2296m 2.2g 4756 R 98 59.5 7:12.21 rsvg-convert | 17:22 |
| bluefoxicy | as soon as I get logged in, I hit 100% usage OF 4 GIGS OF RAM | 17:22 |
| bluefoxicy | oh, my fault. It's boot chart throwing a fit. | 17:22 |
| maxb | Hrm. screen-profiles has tweaked my .screenrc without informing me what it was doing. I find that a little intrusive | 17:24 |
| bluefoxicy | how long is this supposed to take? bootchart is still eating several gigs of RAM generating a chart of boot o_O | 17:26 |
| bluefoxicy | wait, it just flatlined at only 1 gig of RAM and 100% CPU,ok. | 17:26 |
| bluefoxicy | <_< finished in almost 13 minutes of full-utilization CPU time | 17:27 |
| kees | pitti: what is dhcp3 upstream's position on interface-mtu? | 17:32 |
| pitti | kees: oh, hang on; I just checked again, and it seems that upstream's default is actually to not request it | 17:33 |
| pitti | kees: it was done in debian bug 372689 | 17:33 |
| pitti | bdmurray: ^ | 17:33 |
| pitti | kees: seems I don't quite remember any more then | 17:33 |
| ubottu | Debian bug 372689 in dhcp3-client "default dhclient.conf does not request interface-mtu" [Wishlist,Closed] http://bugs.debian.org/372689 | 17:33 |
| bdmurray | I found some discussion about it - https://lists.ubuntu.com/archives/ubuntu-devel/2007-December/024845.html | 17:34 |
| kees | okay, so we'll follow suit and stop requesting it? | 17:34 |
| pitti | kees: as I said, fine for me | 17:35 |
| kees | cool | 17:36 |
| cjwatson | err. on my network I *have* to use interface-mtu or things randomly break. | 17:38 |
| cjwatson | why are we dropping it? | 17:38 |
| cjwatson | I can't be the only one, I'm sure | 17:38 |
| pitti | hah | 17:38 |
| cjwatson | I know that there are some silly MTUs advertised (as I mentioned in that post), but surely we could just tweak the "insane" range | 17:39 |
| pitti | that's what I meant with "damned if you do, damned if you don't" :( | 17:39 |
| pitti | cjwatson: that's the problem, 576 isn't "insane" at all | 17:39 |
| pitti | (I think) | 17:39 |
| pitti | the lowest legal one is 68 | 17:39 |
| cjwatson | no - although it is the absolute minimum allowed | 17:39 |
| cjwatson | is it? | 17:39 |
| pitti | which of course is unrealistic for today's systems | 17:40 |
| pitti | cjwatson: just parroting the manpage (dhclient.conf) | 17:40 |
| pitti | dhcp-options, I mean | 17:40 |
| cjwatson | from the point of view of somebody who actually needs an MTU of 576, there is no difference between us not requesting the MTU at all and ignoring MTUs less than (randomly) 1000 | 17:40 |
| pitti | cjwatson: which one do you need for your system? | 17:41 |
| cjwatson | 1380 | 17:41 |
| cjwatson | err, I think | 17:41 |
| kees | it seems there are a large number of people for which requesting interface-mtu breaks their network. given this, I'd advocate following upstream, which also matches what Ubuntu has always done (excepting intrepid) | 17:41 |
| Lure | any X developer around? I raised priority of bug 322155 as it is nasty regression... | 17:41 |
| ubottu | Launchpad bug 322155 in xserver-xorg-input-synaptics "laptop touchpad button shows unreliable behaviour after package upgrade in Jaunty" [High,Confirmed] https://launchpad.net/bugs/322155 | 17:41 |
| cjwatson | kees: what MTUs are these people getting? | 17:41 |
| kees | 576. | 17:42 |
| bdmurray | cjwatson: I've gotten 576 | 17:42 |
| kees | on comcast | 17:42 |
| cjwatson | kees: honestly, I think there are plenty in the other direction too, who obviously aren't speaking up right now because their network works | 17:42 |
| cjwatson | kees: is that consistent? if so, s/576/577/ in dhcp3 and people will be happy | 17:42 |
| RainCT | mvo: hey | 17:42 |
| kees | cjwatson: i.e. ignore 576 as a response? | 17:42 |
| cjwatson | kees: I would rather that we tried harder to find a working compromise, than flip-flopped between breaking different people's networks from release to release | 17:42 |
| cjwatson | kees: yes | 17:42 |
| cjwatson | we already ignore <576, it's only a one-byte leap :) | 17:43 |
| kees | cjwatson: hm, well it seems it would certainly unbreak comcast | 17:43 |
| pitti | cjwatson: (s/68/577/, but all the same) | 17:43 |
| pitti | well, not quite | 17:44 |
| pitti | we don't want to lock out people who do need < 576 | 17:44 |
| kees | seems like a config option is best? | 17:45 |
| cjwatson | $ grep 575 debian/dhclient-script.linux | 17:45 |
| cjwatson | if [ -n "$new_interface_mtu" ] && [ $new_interface_mtu -ge 575 ]; then | 17:45 |
| cjwatson | pitti: ^- | 17:45 |
| cjwatson | pitti: are such people shouting about the problem right now? | 17:45 |
| RainCT | mvo: adding PPAs requires quite some clicks now (get to the key, copy it to a file, import it..), so what do you think about adding an option to apturl to enable an additional repostitory (also adding its key)? | 17:45 |
| cjwatson | because they should be - we're already locking them out | 17:45 |
| * ScottK has seen 1 second dhcp cycling sometime on Verizon FIOS too. | 17:46 | |
| kees | (i've seen some reference to 576 being a dialup setting hm) | 17:46 |
| cjwatson | we could be cleverer yet - allow 576, but only if it's a PPP interface | 17:46 |
| cjwatson | oh, no, that doesn't help DSL | 17:47 |
| cjwatson | still, I do think we should be trying harder here rather than alternately giving up in one direction or the other! | 17:47 |
| cjwatson | perhaps we could make it work for NM-managed interfaces | 17:48 |
| cjwatson | given that NM should know more about the connection type | 17:48 |
| kees | hm, sounds like "dial" really means "19200 or lower serial and X.25" | 17:48 |
| kees | and for serial, it sounds like it's just a patch for latency issues | 17:49 |
| cjwatson | well, the effect of having a higher MTU than you ought to is (in practice) that web pages sometimes work and sometimes randomly stall | 17:50 |
| kees | cjwatson: I think we're safe with the 577 or higher | 17:50 |
| cjwatson | particularly if it's only slightly higher, as in my case | 17:50 |
| kees | from the looks of it, people wanting 576 have already configured their interfaces to 576, so ignoring the interface-mtu sent of "576" is fine, since they'll already be at 576. | 17:50 |
| cjwatson | do dialup tools know to force the MTU to 576? | 17:51 |
| kees | it appears to be strictly a latency preference; there's no protocol reason I've seen yet to drop it to 576. | 17:52 |
| kees | cjwatson: e.g. http://www.tldp.org/HOWTO/text/Leased-Line | 17:52 |
| cjwatson | except for UDP, as mentioned there, since it can't be fragmented | 17:54 |
| cjwatson | so for UDP you do want to have a reasonably accurate MTU, although I suppose that also depends on the application | 17:54 |
| kees | right, the discussion on mtu focuses around interactivity not protocol reasons. in fact, they recommend trying to use 1500 because of the UDP issues. | 17:55 |
| kees | i.e. I think we're safe requiring higher than 576. | 17:55 |
| kees | (in dhclient) | 17:55 |
| * cjwatson nods | 17:57 | |
| cjwatson | cool | 17:57 |
| kees | shall I patch dhcp3 or does someone else have an update in progress? | 17:58 |
| maxb | Where do I report paste.ubuntu.com breakage? | 18:11 |
| jpds | maxb: rt AT ubuntu.com | 18:15 |
| Keybuk | bryce: I have an interesting bug on jaunty | 18:18 |
| Keybuk | well, actually, I'd go as far as to describe jaunty as a collection of interesting bugs, _but_ ... | 18:18 |
| Keybuk | this one is with the X server | 18:19 |
| ogra | like ctrl-alt-bkspc stopped working ? | 18:19 |
| ogra | :) | 18:19 |
| Keybuk | no, thanks to Mark talking to Aberto and managing to cc everyone in core-dev, I knew about that ;) | 18:19 |
| Keybuk | this one is that the X server uses 50-100% of the CPU continuously | 18:19 |
| ogra | yeah, its quite annoying to use the branch notification for it | 18:20 |
| Keybuk | fortunately it's logging things to Xorg.0.log | 18:20 |
| Keybuk | what is says is | 18:20 |
| Keybuk | "Oh, a monitor" | 18:21 |
| Keybuk | "Oh, a monitor" | 18:21 |
| Keybuk | "Oh, a monitor" | 18:21 |
| Keybuk | (I'm paraphrasing here) | 18:21 |
| bryce | Keybuk: sounds like you've got some app polling the xserver with XRandR queries | 18:21 |
| bryce | Keybuk: https://wiki.ubuntu.com/X/Troubleshooting/HighCPU | 18:22 |
| pitti | Keybuk: happens when you pull the power plug and run on battery, for example? | 18:23 |
| Keybuk | I am on battery, yes | 18:23 |
| pitti | Keybuk: that's been reported and argued since last UDS, when it happened the first time | 18:23 |
| pitti | Keybuk: bug 307306 | 18:23 |
| ubottu | Launchpad bug 307306 in gnome-power-manager "upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow" [High,In progress] https://launchpad.net/bugs/307306 | 18:23 |
| Keybuk | pitti: yes, killing gnome-power-manager does help ;) | 18:27 |
| Keybuk | that just made everything funny | 18:27 |
| maxb | Keybuk: There's a workaround patch that you can apply to gnome-desktop which changes from eating all of one core continuously to eating too much CPU for about 2-3 minutes whilst g-p-m initializes | 18:33 |
| Keybuk | that doesn't sound like a fix | 18:34 |
| maxb | No, but it helps you actually manage to use Jaunty to do other work | 18:34 |
| Keybuk | I just killed gnome-power-manager | 18:34 |
| Keybuk | which turns out to make suspend work again | 18:35 |
| LaserJock | any dutch (or whatever NL is) speakers around? | 18:40 |
| cjwatson | nl is Dutch, yes | 18:40 |
| BUGabundo | apw: ping | 18:40 |
| BUGabundo | apw bug 319505 | 18:41 |
| ubottu | Launchpad bug 319505 in linux "In Jaunty Alpha3 release 32 bit and 64 bit versions the sound is not work." [Medium,Invalid] https://launchpad.net/bugs/319505 | 18:41 |
| LaserJock | nvm, google did it for me | 18:42 |
| BUGabundo | apw its looking like a regression | 18:43 |
| BUGabundo | the change mess my system | 18:43 |
| pitti | calc: wrt. bug 305790, do we actually still need jaxme and xom? apparently current OO.o builds fine without them? | 18:51 |
| ubottu | Launchpad bug 305790 in suitesparse "MIR - move to main for openoffice.org 3 build-depends" [Undecided,Fix released] https://launchpad.net/bugs/305790 | 18:52 |
| pitti | calc: oh, nevermind, they were temporarily promoted to get it to build, but they still need to be fixed | 18:53 |
| pitti | bryce, tjaalton: how come that xserver-xorg-input-vmmouse wants to go to universe? | 19:05 |
| Keybuk | hmm, now compiz is dog-slow :-/ | 19:13 |
| pwnguin | heh | 19:13 |
| * Keybuk likes how everything breaks just before the sprint | 19:13 | |
| Keybuk | (or any other travel, for that matter) | 19:13 |
| pwnguin | presumably it has to do with what scottK mentioned | 19:13 |
| ScottK | That's been for a while now. | 19:14 |
| Keybuk | what did ScottK mention? | 19:14 |
| pwnguin | http://www.kitterman.org/ScottK/2009/01/bug_254468_momentary_video_gar.html | 19:14 |
| ScottK | The Fedora xorg-server patch that was dropped (finally) in Jaunty. https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/254468 | 19:15 |
| ubottu | Launchpad bug 254468 in xorg-server "MASTER: momentary video garbage upon drawing new objects (particularly in KDE)" [High,Confirmed] | 19:15 |
| tjaalton | pitti: looks like -input-all no longer depends on it.. I'll investigate | 19:18 |
| Keybuk | I'm not sure I'd describe this as lower performance | 19:20 |
| Keybuk | taking eight seconds to switch a workspace at the moment | 19:20 |
| * cody-somerville is still running hardy. | 19:20 | |
| isaac | yeah, i have had to disable compiz completely | 19:21 |
| isaac | with an up-to-date jaunty | 19:21 |
| maxb | huh, what video hardware, I have it working fine on an nvidia, an ATI (with radeonhd), and an intel | 19:22 |
| Keybuk | intel | 19:22 |
| isaac | intel here too, 945GM | 19:23 |
| isaac | but well, in alpha-3 it made my computer hang completely | 19:23 |
| isaac | so it's getting better :P | 19:23 |
| maxb | egads, it's a lot worse on my intel than I remember it being a few days ago | 19:23 |
| tjaalton | Keybuk: it's a bug in drm, you can work around it by disabling vblank, see bug 320813 | 19:24 |
| ubottu | Launchpad bug 320813 in mesa "[GM45] with EXA compiz animations cause temporary freezes" [High,Confirmed] https://launchpad.net/bugs/320813 | 19:24 |
| isaac | tjaalton: awesome | 19:24 |
| tjaalton | I've got a patch for the kernel which fixes it for me, but upstream is still fighting if it's the correct fix | 19:24 |
| syldeb35 | Une partie de messagerie musicale a été demandée. Veuillez cliquer sur l'icône MM pour l'accepter. | 19:26 |
| Keybuk | tjaalton: random Q - we're not using GEM yet, are we? | 19:26 |
| tjaalton | Keybuk: sure are | 19:27 |
| Keybuk | ahh, but KMS comes in the next release with .29+ ? | 19:28 |
| tjaalton | yes | 19:28 |
| Keybuk | hmm, I need to restart X after the .drirc ? | 19:28 |
| tjaalton | GEM came with .28, enables DRI2 (but only if using UXA, not EXA which is the default) | 19:28 |
| tjaalton | .drirc doesn't work, you need to put it as /etc/drirc | 19:29 |
| Keybuk | do I need to change the driver="i965" to driver="i945" | 19:29 |
| tjaalton | debian will release mesa 7.3 in a moment, so we might just disable vblank again until the patch is in the kernel | 19:29 |
| grndslm | Could anybody help me figure out how to set Ubiquity's first three variables (English, Chicago, USA) and not have the program ask for them?? | 19:29 |
| tjaalton | Keybuk: actually, the dri driver is i915 | 19:30 |
| tjaalton | for you | 19:30 |
| Keybuk | ah, that works | 19:31 |
| Keybuk | thanks | 19:31 |
| grndslm | I'm assuming to accomplish my goal, I'll need to download the source for ubiquity?? | 19:32 |
| grndslm | i tried looking at /usr/bin/ubiquity & ubiquity-dm ... but they didn't look like what i was really after | 19:32 |
| Keybuk | grndslm: you can use debconf seeding for that, I believe | 19:33 |
| grndslm | Keybuk: care to explain? | 19:33 |
| grndslm | never heard of that | 19:33 |
| Keybuk | https://wiki.ubuntu.com/Ubiquity/Automation | 19:34 |
| grndslm | Keybuk: thanks!! | 19:34 |
| Keybuk | and try google "ubuntu preseed" | 19:34 |
| Keybuk | basically any question asked, you can pre-supply the answer | 19:34 |
| Keybuk | including questions that you didn't realise were asked, because ubiquity was already giving the answer | 19:34 |
| grndslm | Keybuk: most of this preseeding stuff has to do with debian-installer... are you sure it works with ubiquity? | 19:44 |
| ogra | ubiquity is a frontend to debian-installer | 19:45 |
| cjwatson | https://wiki.ubuntu.com/Ubiquity/Automation is specifically about ubiquity ... | 19:46 |
| cjwatson | actually, I think there's better documentation than that | 19:46 |
| grndslm | hmm... never realized that... thought d-i actually unpacked/installed packages, whereas ubiquity just copied the filesystem | 19:46 |
| grndslm | that wiki doesn't get too much into instructions, tho | 19:46 |
| ogra | heh, the spec is still pending approval :) | 19:46 |
| cjwatson | hah | 19:46 |
| cjwatson | https://wiki.ubuntu.com/UbiquityAutomation | 19:46 |
| cjwatson | a single character makes a big difference | 19:47 |
| grndslm | cjwatson: thanks a bunch! | 19:47 |
| cjwatson | grndslm: yes, that part of d-i and ubiquity is of course entirely different; but much of the configuration code is shared | 19:47 |
| grndslm | sweet... learn somethin' new everyday | 19:47 |
| cjwatson | you do need to run with the automatic-ubiquity flag, otherwise all you'll achieve is setting different defaults but still having the questions asked :) | 19:49 |
| * ogra ponders how to fit all the HW in his trunk | 19:52 | |
| ogra | .oO( and i thought working with mobile makes everything become smaller ) | 19:53 |
| ScottK | bryce: alt-sysrq-k isn't new is it? It doesn't do anything on my Intrepid latop. | 20:30 |
| mvo | lool: do oyu have any idea about the crash in gxine (bug #323316)? | 20:30 |
| ubottu | Launchpad bug 323316 in gtk+2.0 "package libgtk2.0-dev 2.14.4-0ubuntu2 failed to install/upgrade: package libgtk2.0-dev is already installed and configured" [Undecided,Incomplete] https://launchpad.net/bugs/323316 | 20:30 |
| tjaalton | ScottK: what about altgr? | 20:31 |
| tjaalton | ScottK: and do you use dvorak? | 20:31 |
| bryce | ScottK: alt-sysrq-k has been around quite a while | 20:31 |
| bryce | heya ogasawara | 20:32 |
| ogasawara_ | bryce: hiya | 20:32 |
| ScottK | tjaalton: No, regular qwerty. | 20:33 |
| ScottK | Not sure what key altgr would be? | 20:34 |
| ScottK | bryce: IIRC I saw at least one other reference to it not working in the discussion. I think maybe we ought to understand more about how widespread it's working is before we declare victory | 20:35 |
| pochu | ScottK: the one next to the space, on the right | 20:35 |
| pochu | probably not on US keyboards I think | 20:35 |
| davertron | hi, can anyone help me out with a postfix install on intrepid? | 20:38 |
| === thekorn_ is now known as thekorn | ||
| redvamp128 | davertron: I sent you here and since these guys develop here-- they should know how to debug-- kernel panics | 20:43 |
| redvamp128 | I am actually curious myself | 20:44 |
| davertron | it looks like the issue is i'm not using postfix or something | 20:44 |
| davertron | that's what the guys in #postfix said anyway :) | 20:44 |
| davertron | must be even after installing postfix with apt-get, the MTA is different or something | 20:44 |
| redvamp128 | though I have only had one thus far on ubuntu -- but only with 8.10 though | 20:44 |
| davertron | i'm still trying to keep up with all of the mail acronyms... | 20:44 |
| rbrunhuber | davertron: Did you already write a bugreport about this? | 20:44 |
| davertron | kernel panics? | 20:44 |
| davertron | am i the right person? | 20:45 |
| davertron | ha | 20:45 |
| === csrealized7_ is now known as csrealized7 | ||
| davertron | was the error i reported a kernel panic? | 20:45 |
| ScottK | #ubuntu-server is a much better place for this discussion. | 20:45 |
| redvamp128 | however though for me-- I just booted to the prior one and deleted the link to the current one- then the next update it didn't | 20:45 |
| redvamp128 | Though since then I have went back to 8.04 which is now 8.04.2 and stable as can be | 20:46 |
| lamont | davertron: this would be the channel to discuss your patch for fixing whatever you found, #ubuntu-server would be a better place for getting help with an unknown issue | 20:51 |
| JacobBrown | Hi. I'm making an ubuntu package for the software I'm working on, and I'm wondering how ubuntu has the mysql server setup so that my post install script can install the user/database/schema for my application | 21:14 |
| === RainCT_ is now known as RainCT | ||
| Amaranth | hrm | 21:41 |
| Amaranth | someone said my name, it fell off my scrollback | 21:41 |
| maxb | JacobBrown: request-tracker3.6 is a package which does this. You may be able to use it as a guide. | 21:43 |
| maxb | 16:23 < superm1> Amaranth, as far as i'm aware it doesn't still. | 21:44 |
| maxb | (That's UTC) | 21:44 |
| Amaranth | yeah, I got it already, thanks though | 21:44 |
| * maxb hugs irssi /sb search | 21:44 | |
| Amaranth | I have a funny feeling we're going to end up with a 'private' beta of fglrx again | 21:44 |
| TheMuso | /c/c | 21:47 |
| maxb | The lack of the regular monthly releases for the last two months doesn't seem to bode well, does it :-/ | 21:47 |
| Laney | Anyone seen unupgradability with latest vim from -security? http://pastebin.ubuntu.com/111877/ | 22:10 |
| jdstrand | Laney: please file a bug | 22:11 |
| Laney | jdstrand: Sure, I'm just doing it. I just wanted to smoke test | 22:11 |
| jdstrand | though I have not seen that problem myself | 22:12 |
| Laney | jdstrand: bug 296324 is similar | 22:13 |
| ubottu | Launchpad bug 296324 in vim "dpkg-divert: rename involves overwriting `/usr/share/vim/vim71/doc/help.txt' with different file `/usr/share/vim/vim71/doc/help.txt.vim-tiny', not allowed" [High,Fix released] https://launchpad.net/bugs/296324 | 22:13 |
| Laney | can probably steal the fix from there | 22:14 |
| Laney | jdstrand: bug #323381 | 22:16 |
| ubottu | Launchpad bug 323381 in vim "[intrepid] Cannot upgrade between vim-{tiny,runtime} 1:7.1.314-3ubuntu3 to 1:7.1.314-3ubuntu3.1" [Undecided,New] https://launchpad.net/bugs/323381 | 22:17 |
| jdstrand | Laney: thanks! | 22:18 |
| Laney | I'll knock up a debdiff for the conflicts if you think that's correct? | 22:18 |
| jdstrand | Laney: feel free to post it in the bug with your findings. It sounds like it existed before the security fix, so it'll likely be an SRU | 22:19 |
| tjaalton | ScottK: so none of the sysrq shortcuts work for you? is it a mac?-) | 22:25 |
| LaserJock | tjaalton: what's the one to kill X | 22:29 |
| ScottK | tjaalton: It's a Dell Latitude D430. | 22:29 |
| LaserJock | I thought I tried it an it almost crashed my machine by taking ~50 screenshots | 22:29 |
| tjaalton | LaserJock: alt+sysrq+k | 22:31 |
| tjaalton | it'll kill every process on the current VT | 22:31 |
| LaserJock | tjaalton: ok, then it doesn't work for me either | 22:31 |
| tjaalton | tough :) | 22:31 |
| LaserJock | heh | 22:32 |
| bryce | do we have kernel bug reports open yet on these sysrq-no-workee issues? | 22:32 |
| tjaalton | LaserJock: one combo should print the help screen.. you could try it on a VT | 22:32 |
| tjaalton | a sec | 22:32 |
| tjaalton | to see if it works on the console but not X | 22:33 |
| LaserJock | hmm, I see if I can get a VT, most often I can't | 22:33 |
| LaserJock | that's the other problem | 22:33 |
| tjaalton | KMS ftw | 22:33 |
| LaserJock | I rely on the 3-finger-salute because most often I cant get a VT | 22:34 |
| LaserJock | tjaalton: ok, from a VT it changes the log level | 22:35 |
| tjaalton | hmm | 22:35 |
| LaserJock | on my machine sysrq is acting like prtscrn | 22:35 |
| LaserJock | so I hit alt-sysrq and it takes a screenshot | 22:35 |
| andersk | Go to console 1 (Ctrl+Alt+F1) and try again. | 22:36 |
| tjaalton | I need to use altgr | 22:36 |
| tjaalton | on my laptop | 22:36 |
| LaserJock | andersk: what do you mean? that's what I did and it changes the log level | 22:36 |
| LaserJock | or are you saying I need to do it twice? | 22:36 |
| LaserJock | part of the problem may be that sysrq on my laptop is a function key | 22:37 |
| ScottK | tjaalton: I think if it's one of several possibilities it's not a reasonable substitute for ctrl-alt-backspace, | 22:37 |
| LaserJock | so I actually press Alt-Fcn-Del-k | 22:37 |
| ScottK | LaserJock: It's a function key on mine too. | 22:37 |
| ScottK | Mine is Fn-F11-Alt-k | 22:38 |
| ScottK | Fn/Fcn | 22:38 |
| LaserJock | argg, that's awful, stupid screenshots :-) | 22:39 |
| ScottK | bryce: No. I didn't file bugs. This discussion I didn't even know about the 'feature'. | 22:40 |
| LaserJock | ScottK: same here | 22:40 |
| hyperair | mine's fn+screenshot so multiple windows of gnome-screenshot open when i try to use it | 22:40 |
| dtchen | LaserJock: keep in mind that on some hardware you need both r and k sysrq | 22:40 |
| hyperair | i mean fn+printscreen | 22:40 |
| LaserJock | I didn't know I had a sysrq key | 22:40 |
| dtchen | LaserJock: (and in such cases, bug reports are much appreciated; those are kernel issues) | 22:41 |
| ScottK | dtchen: All the more reason this isn't a user appropriate alternative. | 22:41 |
| LaserJock | hyperair: mine is the same but they're different keys | 22:41 |
| LaserJock | dtchen: what does that mean? Alt-sysrq-k-r ? | 22:42 |
| dtchen | ScottK: fixing bugs in the stack(s) are going to cause regressions, but they need to be fixed. if dontzap is a step toward it, then we'll have to suffer. | 22:42 |
| dtchen | (oh do i know the pain in the audio realm) | 22:42 |
| Laney | cjwatson: You might be interested to know that the conflicts mentioned in the changelog to bug 296324 don't seem to have made their way in (http://git.debian.org/?p=pkg-vim/vim.git;a=commitdiff;h=f0116b4ca5a40a2147c6ccc01abd0e013fea0295) | 22:43 |
| ubottu | Launchpad bug 296324 in vim "dpkg-divert: rename involves overwriting `/usr/share/vim/vim71/doc/help.txt' with different file `/usr/share/vim/vim71/doc/help.txt.vim-tiny', not allowed" [High,Fix released] https://launchpad.net/bugs/296324 | 22:43 |
| dtchen | LaserJock: alt+sysrq+r then alt+sysrq+k | 22:43 |
| tjaalton | ScottK: well, alt works now. no need to use fn even though the key might suggest that | 22:43 |
| slangasek | ScottK: well, I knew about Alt+SysRq+k, but I didn't know until now that it only killed things on the current VT | 22:43 |
| dtchen | LaserJock: (and, as tjaalton alluded to, you probably need to use altgr) | 22:43 |
| LaserJock | dtchen: what's altgr? | 22:43 |
| tjaalton | dtchen: not anymore | 22:43 |
| slangasek | but anyway, SysRq+K as a method of killing X toasts my VTs, so that's not nice | 22:44 |
| tjaalton | slangasek: on intel? sometimes yes, not always | 22:44 |
| ion_ | That probably should not happen anymore after kernel mode setting has been implemented everywhere. | 22:44 |
| LaserJock | at this point I can't imagine that recommending alt-sysrq+k is a good option | 22:44 |
| ScottK | It really doesn't seem suitable, but I need to go get ready for the KDE 4.2 release party. | 22:44 |
| LaserJock | dontzap sound like the best | 22:44 |
| slangasek | tjaalton: that it does it at all appears to make it an inferior choice in comparison with Ctrl+Alt+BkSp | 22:44 |
| slangasek | ion_: which isn't happening this cycle, at least | 22:45 |
| ion_ | Yep | 22:45 |
| tjaalton | slangasek: well, it's still there. who needs VT's anyway :) | 22:45 |
| slangasek | tjaalton: the very people who are trying to debug the X problems that cause them to need to kill the X server? | 22:46 |
| tjaalton | slangasek: are you sure zapping doesn't mess the VT's? | 22:46 |
| tjaalton | maybe I'll do some testing.. bbl | 22:47 |
| LaserJock | does anybody know what xorg upstream's rationale was for removing zapping? | 22:47 |
| LaserJock | was it that alt-sysrq-k was available, or that X never needs killing, or ... | 22:47 |
| slangasek | tjaalton: when I had occasion to use it in intrepid, it didn't break my VTs | 22:48 |
| LaserJock | it seems like it must have been more drastic than "people accidentally zapp X" | 22:48 |
| slangasek | you're saying "people accidentally pressing a key combo that loses their current session and not knowing why" is insufficient reason to be dissatisfied with the status quo? | 22:51 |
| LaserJock | no | 22:51 |
| LaserJock | I mean, that's a keybinding issue, not a feature issue, it would seem | 22:52 |
| LaserJock | so I can totally understand "dang, this is too easy to hit" | 22:52 |
| LaserJock | but "yeah, nobody needs to kill X anyway" is a bit different | 22:52 |
| LaserJock | seems like fixing the wrong problem | 22:52 |
| slangasek | it is fixing the wrong problem | 22:53 |
| slangasek | that doesn't imply upstream had a more cohesive rationale for the change... | 22:53 |
| LaserJock | most people I've talked to accidently hit it because they us Ctrl-Alt a lot | 22:53 |
| LaserJock | I just wondered | 22:53 |
| tjaalton | slangasek: so, it seems like a bug in the intel drm driver then | 22:54 |
| tjaalton | the suse patch was proposed to upstream, and they rejected it | 22:55 |
| tjaalton | this was discussed Sep-Oct '08 | 22:55 |
| tjaalton | LaserJock: and it wasn't removed, the default was changed | 22:58 |
| __Ali__ | why is dh_install commented out in debian/rules? | 22:58 |
| tjaalton | some still believe it was removed completely.. | 22:58 |
| __Ali__ | is dh_install necessary for the actual binaries to be included in deb? | 22:59 |
| LaserJock | tjaalton: I thought it was removed and we patched it back in | 22:59 |
| bryce | tjaalton: yep. And I notice many are misperceiving that xorg upstream removed it, and it was Ubuntu that patched it back in | 22:59 |
| LaserJock | __Ali__: try #ubuntu-motu | 23:00 |
| __Ali__ | ok | 23:00 |
| bryce | LaserJock: nope. What we're carrying currently is 100% what upstream provides, no patches. | 23:00 |
| LaserJock | bryce: that's what was floating around at UDS | 23:00 |
| * LaserJock notes if people would publish UDS results a bit better things might be clearer | 23:01 | |
| tjaalton | hm, an unfortunate misconception | 23:01 |
| fta | pitti, is apport broken? I wanted to report a crash, i got an url like: file:///ubuntu/+source/cyrus-sasl2/+filebug/PBwouks3QeVaVpymxUTDGODffC while it should be launchpad or something | 23:01 |
| dtchen | slangasek: before i propose bug 107687 for hardy, what are your thoughts? should i push a patch to BTS and into jaunty, first? (the reason i haven't done so is because none of the supported Debian versions have the older xfonts-scalable that hardy does.) | 23:01 |
| ubottu | Launchpad bug 107687 in xfonts-scalable "missing versioned dependency of xfonts-utils aborts distribution upgrade from dapper/edgy at xfonts-scalable" [High,Fix committed] https://launchpad.net/bugs/107687 | 23:01 |
| slangasek | dtchen: bugs should certainly be fixed in jaunty before being proposed for SRUs | 23:01 |
| slangasek | or if there's a reason not to fix it in jaunty (the upgrade issue may no longer be applicable for instance), then 'wontfix' it for jaunty and explain why in the SRU request | 23:02 |
| dtchen | slangasek: ok, i'll use the wontfix, then. thanks. | 23:02 |
| andersk | fta: bug 314263? | 23:02 |
| ubottu | Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/314263/+text) | 23:03 |
| fta | d'oh | 23:03 |
| fta | andersk, thanks, i'll have a look | 23:03 |
| dtchen | slangasek: my main concern is the versioning; 1:1.0.0-6 is in gutsy, hardy, intrepid, and jaunty, which makes that approach hairy | 23:04 |
| comradekingu | My tracks are listed multiple times in the new rhythmbox | 23:04 |
| slangasek | dtchen: ah; in that case we could upload to hardy-proposed, and when it's validated we can down-copy to the later releases | 23:04 |
| dtchen | slangasek: ok, great | 23:05 |
| comradekingu | Rhytmbox 0.11.6svn20081008-0ubuntu4.3 (intrepid-proposed) | 23:06 |
| === cody-somerville_ is now known as cody-somerville | ||
| fta | anyone using sasl2 here? | 23:32 |
| fta | bug 323409 | 23:32 |
| ubottu | Launchpad bug 323409 in cyrus-sasl2 "sasl2-bin broken, segfaulting during install" [Undecided,New] https://launchpad.net/bugs/323409 | 23:32 |
| === blueyed_ is now known as blueyed | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!