| calc | slangasek: you normally see them on your desktop also if so | 00:00 |
|---|---|---|
| slangasek | ah - yes, but it wasn't clear to me that this uses fuse | 00:00 |
| calc | those use gio/gvfs | 00:00 |
| calc | but you can grab the fuse path out of the GFile object as well and have it use fuse instead | 00:01 |
| calc | since they weren't working properly using the native gio/gvfs i wrote a patch to pull out the fuse path | 00:01 |
| calc | not too much trouble if you know what you are doing but took me a while since i had never done anything with gio/gvfs before, heh | 00:02 |
| * calc wishes debian would update to current bzr on bzr.d.o | 00:08 | |
| slangasek | is bzr.d.o even running a smartserver? | 00:09 |
| slangasek | last I checked, I don't think it was | 00:09 |
| james_w | it is over ssh | 00:09 |
| calc | it constantly complains to me that it needs to be upgraded but that has to be done on the server side :\ | 00:10 |
| calc | and debian doesn't have current bzr packaged in unstable last i checked | 00:11 |
| james_w | it does now | 00:11 |
| calc | james_w: ah ok | 00:11 |
| james_w | but alioth runs stable | 00:11 |
| calc | james_w: oh | 00:11 |
| james_w | it will be upgraded to lenny at some point presumably | 00:11 |
| calc | so bzr on bzr.d.o is currently 0.11? | 00:12 |
| slangasek | 1.5 | 00:16 |
| Nafallo | stable = lenny no? :-) | 00:16 |
| nhandler | Correct Nafallo | 00:17 |
| StevenK | james_w: alioth is probably still running oldstable | 00:17 |
| slangasek | yes, it is | 00:17 |
| Nafallo | so it didn't use "stable" in sources.list then ;-) | 00:19 |
| * Nafallo have heard horror stories about that one :-P | 00:20 | |
| calc | slangasek: ah so it is running 1.5 so repos could be upgraded i guess? | 00:23 |
| slangasek | they could be upgraded to the 1.5 level, at least :) | 00:23 |
| calc | too bad the error messages don't tell you the minimum bzr revision needed to make the messages go away | 00:30 |
| directhex | hm. can anyone determine why a package was rejected from NEW, if no explanation seems to have been sent? in theory it was done on tuesday, which means Riddell was on archive duty | 00:53 |
| Riddell | directhex: there was a mono package that had two versions, I think I rejected the older one and accepted the newer one | 00:53 |
| directhex | Riddell, there were two debugger plugins for monodevelop - one for mdb (mono debugger, for mono apps) and one for gdb (um... gdb is gdb) | 00:57 |
| directhex | Riddell, the mdb plugin was accepted, the gdb plugin was rejected | 00:58 |
| comradekingu | I updated the roadmap-wiki with a link to the alpha 6 site. Hope it will trigger a few downloads. | 01:00 |
| Riddell | directhex: ok I think I messed up due to soyuz's annoying name trunkating bug | 01:04 |
| Riddell | directhex: I've accepted it now | 01:04 |
| directhex | Riddell, oh, you can do that without a re-upload? thanks! | 01:05 |
| jdong | :( | 01:05 |
| Riddell | I hope I can, let me know if it doesn't appear | 01:05 |
| jdong | alpha-6 still has the hardlock-on-login bug | 01:05 |
| directhex | Riddell, mildly amusing circumstances, but thanks ;) | 01:05 |
| ScottK | directhex: One can acept from rejected. | 01:05 |
| ScottK | accept even. | 01:05 |
| jdong | bryce_: Are there any known bugs with GMA950 hardware hardlocking X when compiz tries to start? | 01:05 |
| jdong | I am reproducing this with Jaunty AMD64, on login it simply hangs where I'd expect compiz to be started | 01:06 |
| bryce_ | jdong, don't know offhand, try looking in launchpad | 01:06 |
| directhex | ScottK, handy! | 01:07 |
| jdong | bryce_: heh I tried looking through and couldn't tell if I had a dupe of an existing Jaunty intel problem or a new one... | 01:07 |
| jdong | hmm I think bug 259385 sounds right | 01:09 |
| ubottu | Launchpad bug 259385 in compiz "[i845] Intrepid Compiz hangs on login for i830MG, i845, (and i945GM?) video cards" [Medium,Fix released] https://launchpad.net/bugs/259385 | 01:09 |
| jdong | wrong release though :-/ | 01:09 |
| bryce_ | jdong, if you're asking is it worthwhile to file a bug report about the issue, almost certainly yes | 01:10 |
| jdong | bryce_: alright, I'll do so then | 01:10 |
| * ScottK tosses fta a reminder about mozilla-devscripts and python2.4.... | 01:10 | |
| bryce_ | jdong, see the troubleshooting page off of http://wiki.ubuntu.com/X/ as well | 01:11 |
| bryce_ | the reporting page is good to review too, else your bug may just get lost in the noise | 01:11 |
| jdong | bryce_: will do; it seems upstream; I've been able to reproduce this on Fedora 10 too... | 01:12 |
| bryce_ | jdong, if you also file it upstream, that would help a lot. I'm way behind on -intel and probably won't catch up on newly filed stuff any time soon. | 01:13 |
| jdong | ok | 01:16 |
| ScottK | If apt-get -f install (after installing a local .deb via dpkg) wants to pull in more packages than apt-get install all the depends (python2.4 and python2.4-minimal), any suggestions on where to look for trouble? | 02:06 |
| JanC | ScottK: they aren't recommends? | 02:40 |
| ScottK | JanC: Nope. | 02:47 |
| ScottK | After I let it install once I tried aptitude why python2.4 and it didn't know why. | 02:48 |
| JanC | I guess sometimes "-f" tries to be too clever then ;) | 02:49 |
| ScottK | I think I'm going to guess environmental leakage from the base Intrepid system into the chroot. | 02:52 |
| slangasek | ScottK: heh, so even trying to build python-4suite against python2.6 fails miserably here, consuming RAM and never doing anything - but that's not the problem reported upstream? | 03:07 |
| ScottK | slangasek: I don't recall the exact problem. The apt-get -f install problem I was whining about earlier is a different package. | 03:12 |
| * ScottK has also been up for 18 hours after 3 hours of sleep, so don't expect great coherency. | 03:13 | |
| === cody-somerville_ is now known as cody-somerville | ||
| Mavericks | ever been up for 24 hours or more? | 04:01 |
| ScottK | Certainly. | 04:07 |
| ajmitch | last time I did that was probably before/after a UDS, I think | 04:07 |
| * ScottK too. | 04:08 | |
| calc | if i just want fuse paths passed to my application (OOo) should i change the .desktop file to %F instead of %U ? | 04:08 |
| * ScottK has done 96 hours on 3 hours of sleep too, but doesn't recommend it. | 04:08 | |
| calc | for the exec line | 04:08 |
| calc | Mavericks: at around 36hr i am not good for anything | 04:08 |
| calc | Mavericks: my wife was awake for around 500hr | 04:09 |
| calc | Mavericks: hint... being awake 500hr is NOT good | 04:09 |
| Mavericks | ScottK: excellent. although you can definitely beat those 3 hrs to go 99 - real fun ;) | 04:10 |
| ScottK | I was also in the military and we were expending ordnance (for training) at the time, so it was a mix of extreme fatigue and high explosives. | 04:11 |
| Mavericks | calc: *Time for high school questions* fill in the blank - 500 hr is putting _____ at jeopardy. | 04:11 |
| calc | Mavericks: when even high level insomnia drugs don't work you can't do much about it :-\ | 04:11 |
| Mavericks | ScottK: oof | 04:11 |
| calc | Mavericks: they _attempted_ to a sleep study but she failed... due to lack of sleep | 04:12 |
| Mavericks | calc: Nice - haha - Stay away from ______. Ta daaaa. | 04:12 |
| ajmitch | calc: for a minute I thought you must had made a typo & meant 50 hours, but 500? ouch | 04:12 |
| calc | ajmitch: yea roughly 3 weeks without sleep | 04:12 |
| ScottK | I give. She wins. | 04:13 |
| calc | ajmitch: even with the drugs they put her on she could only sleep maybe 1hr before popping back up | 04:13 |
| calc | i'm not sure what actually ended up fixing the issue, or if it just resolved itself | 04:13 |
| ScottK | Longest I've gone straight was ~50 hours. Slept once I realized the people giving me advice on the programming project were hallucinations. | 04:14 |
| calc | so no one knows about %F vs %U in desktop files? | 04:17 |
| * calc thinks he will leave it at %U since it seems to work, though %F is probably more correct | 04:17 | |
| * ScottK votes for working over correctness. | 04:18 | |
| calc | it works both ways but with %U it seems that burn:// urls are passed to OOo still | 04:19 |
| calc | i don't know if switching it to %F will cause any problems though | 04:19 |
| * ScottK also favors leaving well enough alone. | 04:22 | |
| calc | uploading new OOo now with gnome-vfs disabled and set to use gvfs fuse :) | 04:26 |
| shaya | anyone have an idea on how to go about debugging X, in that it freezes regularly in jaunty on an r300 card (T42p laptop w/ firegl card) | 04:31 |
| dholbach | good morning | 05:16 |
| cooloney | dholbach, good morning | 05:37 |
| dholbach | hiya cooloney | 05:37 |
| pitti | Good morning | 08:31 |
| Mavericks | good morning | 08:32 |
| imachine | hello | 08:36 |
| imachine | I have some issues with evolution in jaunty. | 08:36 |
| imachine | it says I can't get imap since there's no provider available. | 08:36 |
| imachine | is that normal jaunty behaviour and I should just wait for a fix, or something is off with my local system? | 08:36 |
| imachine | (had some nastiness during updates/upgrades, so it might be that some packages weren't completely installed) | 08:37 |
| pitti | james_w: did you thoroughly test bzr 1.13 already? | 08:39 |
| sbeattie | pitti: have you thought about privilege escalation for apport? I'd like to do a package hook for apparmor, but one of the things I'd like to collect requires root privs. | 08:49 |
| pitti | sbeattie: right, for some cases we need hooks which run when the program crashes, not when you report it | 08:53 |
| sbeattie | pitti: hrm, that, too. But I'm thinking more along the lines of including the output of apparmor_status, which requires root equivalent access. | 08:56 |
| === tkamppeter_ is now known as tkamppeter | ||
| pitti | sbeattie: right, if you do "ubuntu-bug" as user, you can't have that | 08:59 |
| pitti | sbeattie: if you ask people to "sudo ubuntu-bug", it'll work | 08:59 |
| seb128 | pitti: ls -l `locate coreutils.mo` | 09:32 |
| seb128 | pitti: do you know what is to blame for that? | 09:32 |
| seb128 | doko: ^ or you | 09:33 |
| pitti | seb128: the symlinks you mean? | 09:33 |
| seb128 | pitti: the broken ones yes | 09:33 |
| pitti | seb128: they are shipped in coreutils | 09:33 |
| pitti | indeed, they should point to locale-langpack/ | 09:33 |
| pitti | they look pretty weird in the first place, though | 09:34 |
| pitti | thekorn: FYI, I uploaded a new p-lp-bugs with another fix for parsing duplicates | 09:41 |
| pitti | thekorn: and yesterday night I hacked a lot on the launchpadlib branch (just to avoid duplicate work by you) | 09:41 |
| cody-somerville | mvo, ping | 09:45 |
| === mpt_ is now known as mpt | ||
| mvo | pong | 09:54 |
| * asac still wonders which package could have broken his nfs mount :( | 10:02 | |
| thekorn | pitti, yes, I've seen your bug mails, thanks for the upload | 10:03 |
| pitti | no problem | 10:03 |
| tseliot | asac: is it something that you mount manually? If yes, go to System/Administration/Authorisation and check that you have the authorisation (for policykit) to mount | 10:13 |
| asac | tseliot: no its a /etc/fstab setup mount | 10:17 |
| tseliot | asac: ah, ok | 10:17 |
| asac | it worked for a decade ... now its gone. and i cannot read email anymore :( | 10:17 |
| tseliot | :-/ | 10:17 |
| asac | hmm ... saw strange modprobe issues during this boot | 10:18 |
| asac | output looked similar to what you get when you run modprobe without any module (e.g. --help) | 10:18 |
| asac | tseliot: but a good idea. any idea where i setup such a manual mount ;) | 10:21 |
| * asac found Network | 10:21 | |
| asac | thats not it ... | 10:23 |
| tseliot | asac: sorry but I've never used nfs therefore I have no idea | 10:23 |
| pitti | seb128: if the gdm transition code is available, what's left for https://blueprints.edge.launchpad.net/ubuntu/+spec/gdm-upgrade ? | 10:46 |
| seb128 | pitti: updating that was on my todo I just tested the transition code to make sure it worked before going to bed this night and I wanted to update the blueprint today, let me do that now | 10:47 |
| pitti | seb128: ah, no hurry; I'm just updating the ReleaseStatus page (release meeting today) | 10:48 |
| pitti | seb128: yay | 10:48 |
| seb128 | pitti: changed to implemented | 10:49 |
| seb128 | pitti: should I upload gdm-new to universe now? or is that late in the cycle? | 10:49 |
| pitti | seb128: fine for me | 10:49 |
| seb128 | ok, let's do that | 10:49 |
| seb128 | few people find the ppa and it has other cracks too now | 10:49 |
| pitti | tseliot: what's left for https://blueprints.edge.launchpad.net/ubuntu/+spec/xorg-options-editor ? | 10:50 |
| tseliot | pitti: just a UI cleanup, which won't take place in Jaunty | 10:51 |
| pitti | Riddell: can you please update the status of the kubuntu jaunty specs? | 10:51 |
| pitti | tseliot: can you please update the status of the spec, and separate the remaining UI bits, e. g. into bug reports? Or do you think it's incomplete enough so that we have to pull it? | 10:52 |
| tseliot | pitti: I think it's usable, it just doesn't have the best looking UI ever created. I'll update the status of the spec and file a bug report. | 10:54 |
| Riddell | ok | 10:54 |
| pitti | tseliot: thanks; please then refer to the bug report and set it to implemented, if all the functionality in the spec is covered now | 10:54 |
| pitti | Riddell: thanks | 10:54 |
| tseliot | pitti: ok | 10:55 |
| tseliot | pitti: done | 11:18 |
| pitti | tseliot: cheers | 11:19 |
| tseliot | pitti: :-) | 11:19 |
| Laney | doko: Is it intentional that python-support always makes public modules available for the current version, regardless of what pycompat says? | 11:30 |
| pitti | thekorn: adding/removing tags on staging doesn't seem to work for me with p-lp-bugs; did you happen to notice that as well? | 11:38 |
| pitti | thekorn: I tried for half an hour to find the bug in my test suite, but it really just gets swallowed, it seems | 11:38 |
| pitti | thekorn: trying with launchpadlib now | 11:38 |
| thekorn | pitti, no, can have a look at it in a bit | 11:39 |
| thekorn | does it work on edge | 11:40 |
| pitti | thekorn: no, just asking | 11:40 |
| pitti | thekorn: haven't checked edge yet, let me try | 11:40 |
| pitti | >>> b = Bug(89040) | 11:41 |
| pitti | >>> b.tags | 11:41 |
| pitti | ['apport'] | 11:41 |
| pitti | >>> b.tags.append('testsuite') | 11:41 |
| pitti | >>> b.commit() | 11:41 |
| pitti | thekorn: shouldn't that work? | 11:42 |
| pitti | thekorn: ^ edge now | 11:42 |
| thekorn | pitti, yes, this should work this way | 11:42 |
| pitti | thekorn: hang on, perhaps for adding it stumbles over that silly new dialog box which asks you about "new tag OMG!" for every new pacakge | 11:42 |
| pitti | but removing tags should work.. | 11:42 |
| pitti | hm, doesn't work on edge either | 11:43 |
| pitti | seb128: ^ I think this is serious enough that we have to stop the retracers; otherwise they'll just retrace the same thing over and over | 11:43 |
| * pitti checks the logs | 11:43 | |
| thekorn | pitti, removing works for me on edge | 11:43 |
| seb128 | pitti: ack | 11:43 |
| directhex | hm. according to my figures, jaunty is 44 meg smaller than intrepid | 11:44 |
| directhex | excluding a kernel | 11:44 |
| pitti | thekorn, seb128: hm, it seems to work on ronne | 11:45 |
| pitti | WTH? | 11:45 |
| thekorn | pitti, adding too, | 11:45 |
| pitti | thekorn: ok, thanks for checking; must be something on my end then | 11:46 |
| thekorn | if you would like to add a 'new' tag, you can use b.commit(force_changes=True) | 11:46 |
| pitti | oh, should I always use that? | 11:46 |
| pitti | thekorn: anyway, I now have the test suite succeed in the launchpadlib branch, so I'm going to switch over soon anyway | 11:47 |
| pitti | just figuring out why the last set of tests I wrote fails | 11:47 |
| thekorn | yuhu | 11:47 |
| panesar_sandeep | what should be prerequisites in terms of prog languages that one should hv to start ubuntu developing?? | 11:58 |
| Keybuk | panesar_sandeep: it depends on the software you want to work on | 11:59 |
| maxb | That's not really a meaningful question - Ubuntu is a combination of so many pieces of software. You need to know the languages used in the bits you intend to work on. | 12:00 |
| Keybuk | much of the core of Linux is written in C | 12:00 |
| panesar_sandeep | ok but still, i am intrested in debugging, but am not able to workout gdb well | 12:00 |
| Keybuk | various add-on pieces use Perl or Python, and Bourne Shell is a must | 12:00 |
| Keybuk | Desktop environments might use something like C# (GNOME pieces) or C++ (KDE) | 12:01 |
| bigon | cjwatson: any news about the cleanup of the buildd chroots? | 12:01 |
| panesar_sandeep | where can i get help/docs about using gdb or debugging in ubuntu... | 12:02 |
| cjwatson | bigon: no | 12:02 |
| Keybuk | panesar_sandeep: gdb includes its own manual | 12:02 |
| Keybuk | panesar_sandeep: install gdb-doc and run "info gdb" | 12:02 |
| directhex | panesar_sandeep, this isn't really the channel for learnign to program with ubuntu, as stated in /topic | 12:02 |
| panesar_sandeep | keybuk, thnx :) | 12:02 |
| panesar_sandeep | keybuk, sory too | 12:02 |
| panesar_sandeep | :) | 12:02 |
| directhex | or use monodevelop-debugger-gdb! \o/ | 12:03 |
| directhex | gotta test that | 12:03 |
| === davidm_ is now known as davidm | ||
| === asac_ is now known as asac | ||
| === sabdfl1 is now known as sabdfl | ||
| james_w | pitti: I run bzr.dev, as do many people. There have been a few issues arise during testing this week, with fixes being cherry-picked to the release branch. | 12:47 |
| directhex | james_w, we have monodevelop-debugger-gdb now, tested & working | 12:48 |
| james_w | I saw, thanks | 12:48 |
| directhex | hm, that was meant to be in #ubuntu-motu | 12:48 |
| james_w | well, I didn't see it was tested and working, so even better :-) | 12:48 |
| directhex | james_w, by "tested and working" i mean "setting breakpoints in a 10-line hello world app works" | 12:53 |
| directhex | ditto for hello.cs with monodevelop-debugger-mdb | 12:53 |
| Keybuk | directhex: there's still no way to import an existing project though? | 12:54 |
| james_w | If you are skilled enough to write more than 10 lines of C you shouldn't need a debugger anyway | 12:54 |
| directhex | Keybuk, no. but it's already buckets sexier than monodevelop 1.0 was | 12:57 |
| directhex | Keybuk, that might even be a gsoc suggestion - autofoo import wizard | 12:57 |
| Keybuk | directhex: it's a complete mystery to me how to even start a new autofoo C project in monodevelop | 13:04 |
| PecisDarbs | hi people, tracker won't be installed by default in Jaunty anymore? | 13:10 |
| directhex | Keybuk, i can't see how to do it fully. makefile stuff is under project options, but i get an error when i enable it & click ok. might be a bug. i'll ask upstream | 13:12 |
| MacSlow | pitti, did you already touch the new notify-osd release? | 13:32 |
| seb128 | MacSlow: did you see my comment on #dx? | 13:33 |
| seb128 | MacSlow: where I was asked if we should look at updating notify-osd in jaunty | 13:33 |
| MacSlow | seb128, sure I've done a 0.9.3 release which includes the fixes for the kerneloops-applet issue and the "epiphany-download" crasher | 13:34 |
| seb128 | MacSlow, pitti: ok, I'm looking at the update | 13:34 |
| MacSlow | seb128, btw https://edge.launchpad.net/notify-osd/trunk/0.9.3 | 13:34 |
| seb128 | thanks | 13:35 |
| MacSlow | seb128, where do I indicate on LP that other packages are affected by changes to notify-osd? | 13:35 |
| soren | MacSlow: "Also affects distribution" | 13:35 |
| soren | MacSlow: And then find the package from there. | 13:35 |
| seb128 | MacSlow: open bugs on those or add task by click the "also affect" below the table | 13:35 |
| pitti | seb128: re from lunch; shall I do the update, or are you on it? | 13:59 |
| seb128 | pitti: notify-osd? I'm on it | 13:59 |
| pitti | seb128: okay; have release team meeting now | 13:59 |
| seb128 | pitti: feel free to tackle some other sponsoring request if you want, I cleaned some yesterday but there is still a few pending ones and 2.26 is due next week | 14:00 |
| pitti | seb128: check if the packaging branch already has 0.9.3 first; if so, please merge from that, instead of just updating the ubuntu branch yourself | 14:00 |
| pitti | seb128: right; bit crammed today | 14:00 |
| seb128 | pitti: no hurry don't worry, will do for the notify-osd update | 14:00 |
| === azeem_ is now known as azeem | ||
| ogra | cjwatson, Keybuk ... do we already have a bug for the 1970 prob and useradd ? | 14:09 |
| Keybuk | ogra: I didn't file one | 14:25 |
| Keybuk | I'd suggest the bug is actually in useradd not adduser | 14:25 |
| cjwatson | ogra said useradd ... | 14:25 |
| Keybuk | so he did | 14:25 |
| ogra | thats why i said so :) | 14:25 |
| Keybuk | sorry, dunno how I read that wrong ;) | 14:25 |
| cjwatson | (and I agree) | 14:25 |
| * ogra has to run out for 1h | 14:26 | |
| mathiaz | ttx: it may be better to just upload/merge samba 3.3.2 | 14:34 |
| Aquina | I don't wanna be a nag but why is gFTP still unavailable with compiled SSL? It's no prob for me to do it but the n00bs out there probably can't. You think I should file that on launchpad? Yes, no, maybe? :-) | 14:37 |
| beuno | Aquina, yes | 14:37 |
| ttx | mathiaz: looking... | 14:40 |
| mathiaz | ttx: there are a couple of major bug fixes included in 3.3.2 | 14:41 |
| ttx | mathiaz: yes... but it's a bigger change, then | 14:43 |
| mathiaz | ttx: right - however most of the change seem to be bug fixes only. | 14:43 |
| mathiaz | ttx: may at we should include the patches for the main issues? | 14:44 |
| RainCT | Keybuk: hey | 14:44 |
| mathiaz | ttx: may *be* | 14:44 |
| RainCT | Keybuk: about bug #339612, which console? there's usplash so I don't see anything *g* | 14:45 |
| ubottu | Launchpad bug 339612 in upstart "[jaunty] poweroff doesn't work, but halt does" [Low,Incomplete] https://launchpad.net/bugs/339612 | 14:45 |
| ttx | mathiaz: probably makes more sense to move to 3.3.2. I won't have time to pull it off before the end of the day though. | 14:45 |
| mathiaz | ttx: sure. | 14:47 |
| ttx | mathiaz: I guess we need an Ffe for that move as well. | 14:48 |
| mathiaz | ttx: why? | 14:50 |
| mathiaz | ttx: it seems that this is a bug fix only release | 14:50 |
| ttx | mathiaz: hm, yes, indeed. | 14:51 |
| cjwatson | mvo: http://people.ubuntu.com/~mvo/automatic-upgrade-testing/ looks sort of out of date. Does it do any testing with more recent releases? | 14:56 |
| cjwatson | mvo: (and should we add something to NewReleaseCycleProcess to remind you to update it?) | 14:57 |
| soren | Would anyone mind if I added "karmic" to the list of acceptable distributions in vim's debchangelog syntax file now? It's always bugged me that it doesn't work when we get started on a new release. | 15:01 |
| * soren glances at cjwatson | 15:01 | |
| pitti | soren: if we do it, it should be done in debchange and lintian as well IMHO | 15:02 |
| soren | pitti: Indeed. | 15:02 |
| pitti | and for the record, I wouldn't mind | 15:02 |
| calc | anyone know of a reliable way to add a pre-depends package or a pre-depends line with package to a control file if the line doesn't exist? | 15:04 |
| calc | i have a way to add it without checking but that isn't very good | 15:04 |
| calc | eg: sed -i '/^Architecture:/a Pre-Depends: dpkg (>= 1.14.12ubuntu3)' debian/control | 15:04 |
| pitti | calc: you mean with seddery? | 15:04 |
| calc | pitti: yea or something similarly automated | 15:04 |
| pitti | calc: I was using the same | 15:04 |
| hyperair | \j #vartakblogs | 15:05 |
| calc | pitti: i dropped my pre-depends for lzma because i needed another pre-depends on a package but need it still since soyuz still does the check | 15:05 |
| hyperair | shit | 15:05 |
| cjwatson | soren: fine by me | 15:05 |
| soren | cjwatson: Cool. | 15:05 |
| calc | pitti: so now for one of my packages in OOo there is already a pre-depends line so the second pre-depends line causes an error | 15:06 |
| pitti | calc: you could run above once, and then vi over it, searching for /\nPre-Depends:.*\nPre-Depends/ ? | 15:10 |
| Riddell | pitti: I just committed a small but important fix to jockey, will that be uploaded sometime before beta? | 15:11 |
| calc | pitti: automated or do you mean to manually fix it up? | 15:12 |
| pitti | Riddell: yes, I need to fix some things anyway | 15:12 |
| calc | pitti: manual would probably work since i have a bug open on soyuz already | 15:12 |
| pitti | calc: manually; I guess there won't be that many pre-depends duplications? | 15:12 |
| calc | pitti: yea just one | 15:12 |
| calc | pitti: hmm couldn't i do something like the above to merge the two lines in sed? | 15:14 |
| pitti | calc: well, it's not that reliable, since it's not guaranteed that existing Pre-Depends: fields are always directly below Architecture: | 15:16 |
| pitti | calc: there's certainly some seddery to do that, with using its buffer | 15:16 |
| pitti | but my sed fu isn't that great, I'm afraid | 15:16 |
| calc | ok | 15:17 |
| soren | pitti: Thanks for reminding me of debchange. I wouldn't have thought of that one. I've uploaded all three (vim, devscripts, and lintian) now. | 15:18 |
| pitti | soren: yay koalas! | 15:18 |
| soren | Go go gadget dput! | 15:21 |
| seb128 | Keybuk: did you open bugs about those "don't do fading effect on login" changes btw? | 15:29 |
| Keybuk | seb128: not yet, perfecting the patches | 15:32 |
| seb128 | Keybuk: ok, would be nice to get before beta if you can get those ready for next week | 15:32 |
| Keybuk | RainCT: boot without "splash" > | 15:32 |
| Keybuk | seb128: yeah, definitely will :p | 15:32 |
| seb128 | cool | 15:32 |
| RainCT | Keybuk: heh ok.. | 15:33 |
| pitti | mvo: aaah! mystery in bug 315571 solved | 15:38 |
| ubottu | Launchpad bug 315571 in python-apt "[jaunty] causes random Launchpad timeouts with python-apport" [High,New] https://launchpad.net/bugs/315571 | 15:38 |
| cjwatson | ScottK,doko: bug 342335 is the ICE blocking KDE on powerpc | 15:52 |
| ubottu | Launchpad bug 342335 in gcc-4.3 "ICE compiling qt4-x11 on powerpc" [Undecided,New] https://launchpad.net/bugs/342335 | 15:52 |
| doko | cjwatson: I'll have a look tomorrow. does lowering optimizations help? using gcc-snapshot? | 15:54 |
| cjwatson | haven't yet tried gcc-snapshot, I'll ask for that to be installed on davis | 15:55 |
| * calc did the crappy edit a generated file way to fix the problem | 15:55 | |
| cjwatson | doko: -O2 -> -O1 does make it go away, so I'll try to bisect optimisations | 15:56 |
| cjwatson | doko: from the source it appears to be something to do with PLT generation in PIC mode | 15:57 |
| doko | cjwatson: works with 4.4 | 16:00 |
| cjwatson | -foptimize-sibling-calls appears to be relevant | 16:04 |
| cjwatson | I'll lower optimisation for now | 16:04 |
| mvo | pitti: yeah, it should be fixed | 16:21 |
| wwoods | lazynet, I have a question: are ubuntu binaries built using BuildIDs? (e.g. if you do readelf -n /bin/sleep is there a build ID note)? | 16:22 |
| ion_ | Doesn’t apt-cache policy coreutils suffice? | 16:23 |
| wwoods | ion: long story short: no. | 16:25 |
| wwoods | gdb (in RHEL/Fedora at least) uses the build IDs to get debugging symbols from files with unique filenames | 16:25 |
| ion_ | launchpad resolves the debugging symbols, it seems to work well. | 16:26 |
| wwoods | retracing the debugging symbols server-side requires sending core dumps to a third party | 16:26 |
| wwoods | that does not fly for me, or Fedora, or RHEL | 16:26 |
| wwoods | so back to my simple yes-or-no question: can someone run readelf -n /bin/sleep and thus tell me if there's BUILD_ID notes in the binaries? | 16:27 |
| calc | wwoods: no, is that a specific Fedora patch? | 16:28 |
| calc | wwoods: you may want to propose a discussion for UDS about doing retracing the fedora way... | 16:28 |
| calc | wwoods: assuming the features needed are available it probably wouldn't be too hard to implement if people can come to a consensus this a better way | 16:29 |
| wwoods | calc: AFAIK it's in upstream ld but I might be wrong - still doing research, and I figured I could answer "does Ubuntu already use --build-id"? quickly | 16:29 |
| calc | wwoods: it appears jaunty does not have build id in sleep | 16:30 |
| calc | readelf -n /bin/sleep | 16:30 |
| calc | Notes at offset 0x00000254 with length 0x00000020: OwnerData sizeDescription GNU0x00000010NT_GNU_ABI_TAG (ABI version tag) | 16:30 |
| calc | that is all that it returned for me | 16:30 |
| wwoods | does ld --help mention build-id at all? | 16:31 |
| slangasek | yes | 16:31 |
| slangasek | I don't follow how that has anything to do with server-side retracing, though | 16:31 |
| wwoods | I'm trying to eliminate server-side retracing | 16:31 |
| wwoods | retrace on the client-side by downloading only the required debuginfo data over the internet | 16:32 |
| pitti | yeah, it's pretty irrelevant for server-side retracing, since the problem isn't the debug symbols but the core dump | 16:32 |
| wwoods | if you have unique build IDs it's trivial to determine exactly which individual files are necessary to retrace a core | 16:32 |
| pitti | wwoods: that's actually one of apport's long-term wishlist bugs | 16:32 |
| calc | wwoods: yea ld has build-id support | 16:32 |
| pitti | wwoods: but since debugsyms are so terribly huge, there's not a lot of interest in it | 16:32 |
| slangasek | wwoods: it's already trivial because you already know what libraries are loaded, what packages they come from, and what versions those packages are at | 16:33 |
| wwoods | sooo if you have, say, a webdav share with all the debugging data for every binary | 16:33 |
| slangasek | so you just install the corresponding -dbgsym packages | 16:33 |
| wwoods | slangasek: installing the entire package is insanely wasteful | 16:33 |
| wwoods | typically 95% of the installed data goes unused | 16:33 |
| wwoods | not to mention the overhead of doing all the metadata parsing | 16:33 |
| wwoods | package database updates | 16:33 |
| wwoods | etc | 16:33 |
| === amitk_ is now known as amitk | ||
| wwoods | so instead you have a webdav share with all the debugging data on it - they all have unique filenames, so you can have debugging data for multiple versions of the same package | 16:34 |
| wwoods | the client mounts that share at /usr/lib/debug/.build-id, gdb only pulls the files it needs | 16:34 |
| wwoods | voila - full retraces, client-side, without installing anything | 16:35 |
| pitti | wwoods: that sounds like a fine idea | 16:35 |
| pitti | wwoods: is the build ID any more fine-grained than the package version? | 16:35 |
| wwoods | pitti: each individual binary gets its own UUID | 16:36 |
| wwoods | so each bin in coreutils has its own build-id | 16:36 |
| pitti | how does that help, though? | 16:36 |
| pitti | since in a package build, all binaries get built at the same time anyway? | 16:36 |
| wwoods | well, you need to be able to discern which file corresponds to /bin/sleep and which one is /bin/ls | 16:37 |
| wwoods | I've got a working (albeit experimental) implementation of this in Fedora | 16:37 |
| pitti | wwoods: right, I figured that would end up as something like /debugsyms/coreutils/1.2.3-4/bin/ls | 16:37 |
| wwoods | it's one of the big roadblocks that keeps us from attempting to use Apport | 16:37 |
| pitti | wwoods: are the build IDs a checksum, or a really uniqye number? | 16:38 |
| wwoods | really unique | 16:38 |
| pitti | wwoods: with a checksum I see the benefit of sharing identical files, but with UUIDs we could just as well use the package version? | 16:38 |
| pitti | or is it just to avoid figugring out all the package versions? | 16:39 |
| wwoods | AFAICT, anyway. | 16:39 |
| wwoods | mostly it's such that gdb doesn't need to try to read the rpm database to figure out what version a package is | 16:39 |
| wwoods | to figure out where to look for its debuginfo | 16:39 |
| wwoods | anywya computer is freaking out, I will be back in a little bit | 16:39 |
| wwoods | but you might ask google to give you the fedora wiki pages on buildid | 16:39 |
| pitti | wwoods: anyway, I could see this getting abstracted in apport/packaging.py, such as a function that maps an ELF in the system to an URL for its debugging symbols | 16:39 |
| wwoods | and debuginfofs | 16:39 |
| pitti | wwoods: right, intersting idea; thanks! | 16:40 |
| LaserJock | doko: so is this site-packages -> dist-packages change in python the same in Debian? | 16:43 |
| === mkrufky is now known as mkrufky-away | ||
| === DRebellion is now known as ssb_ | ||
| === robbiew1 is now known as robbiew | ||
| === fader is now known as fader|lunch | ||
| Keybuk | bryce_: right | 17:23 |
| bryce_ | Keybuk: what? | 17:23 |
| Keybuk | why does it take 5 seconds to get to the userspace for Ubuntu | 17:23 |
| Keybuk | but only 1s in Moblin | 17:23 |
| Keybuk | that's kinda the question really | 17:23 |
| Keybuk | something about their X server makes it start a hell of a lot faster than ours :-/ | 17:24 |
| bryce_ | Keybuk: did you see my email where I discussed this? | 17:24 |
| bryce_ | Keybuk: it looks to me like hal is delaying things | 17:25 |
| Keybuk | it isn't | 17:25 |
| Keybuk | I can put a sleep 10 there, and X still takes that long to start | 17:25 |
| bryce_ | Keybuk: well there's nothing in the X log between like 2.7 sec and the 5.8 sec mark. I don't think X is doing anything during that period. | 17:26 |
| bryce_ | Keybuk: _I don't know_ what's going on during that period, but I don't think it's X doing anything particular | 17:26 |
| Keybuk | 2.7s is still twice as long as Moblin ;) | 17:27 |
| ion_ | I don’t know if that’s relevant, but it seems X changes the screen mode to something, then switches back to the virtual console for a second, then changes the screen mode again and keeps doing that a couple of times, and then finally shows a cursor and gets to GDM. | 17:28 |
| ion_ | ...greeter | 17:28 |
| slytherin | Keybuk: have some time? need help debugging "inaccessible DVD" problem again. Totem/VLC/Mplayer both complain and I have libdvdcss installed. | 17:29 |
| Keybuk | ion_: it doesn't do that here | 17:30 |
| Keybuk | slytherin: doesn't sound like I'm the right person | 17:30 |
| Keybuk | unless you're getting Permission Denied | 17:31 |
| slytherin | Keybuk: yes, totem says "you may not have permission to view". I thought this might have something to do with udev. | 17:31 |
| Keybuk | most likely HAL | 17:32 |
| Keybuk | udev doesn't assign permissions a user is expected to have | 17:32 |
| slytherin | Keybuk: hmm. About a month ago we discussed similar issue, the device for DVD drive is /dev/hdc. | 17:33 |
| slytherin | and at that time we concluded that the group for the device was set wrong by udev | 17:34 |
| slytherin | or hal as you say | 17:34 |
| Keybuk | slytherin: what does ls -l /dev/hdc say? | 17:35 |
| slytherin | Keybuk: brw-rw----+ 1 root cdrom 22, 0 2009-03-13 22:29 /dev/hdc | 17:35 |
| Keybuk | looks right to me | 17:35 |
| Keybuk | slytherin: getfacl /dev/hdc | 17:35 |
| Keybuk | bryce_: could it be simply that gdm starts the X server, and is waiting too long before starting clients in it? | 17:35 |
| wwoods | pitti: back - so, our gdb has some support for build-id - if it sees a build-id note in a binary, it assumes that the debuginfo can be found at e.g. /usr/lib/debug/.build-id/XX/XXX...X.debug | 17:36 |
| wwoods | so gdb already automatically maps ELF->path | 17:36 |
| slytherin | Keybuk: http://paste.ubuntu.com/130712/ | 17:36 |
| pitti | wwoods: ah, sweet | 17:36 |
| wwoods | mount the debuginfo files at that path and you're done | 17:36 |
| bryce_ | Keybuk: is it the 0-2.7sec part you're asking about, or the 2.7-5.0 post-X stuff? | 17:37 |
| wwoods | I think it uses just random UUIDs because, generally, the linker doesn't know the unique package ID that it's building | 17:37 |
| pitti | wwoods: so I assume you can tell gdb to use a different basedir, such as ~/.gvfs/webdav-debugsyms/ or so | 17:37 |
| Keybuk | bryce_: why it takes that long | 17:37 |
| wwoods | pitti: exactly | 17:37 |
| bryce_ | Keybuk: which one? | 17:37 |
| Keybuk | slytherin: the "onkar" user has access to that cdrom drive | 17:37 |
| pitti | wwoods: that sounds like a nice way to speed up the version matching indeed | 17:37 |
| Keybuk | bryce_: the problem I'm trying to solve is that our X takes longer than Moblin's X to start | 17:37 |
| wwoods | although in the initial implementation I'm using the systemwide dir, so it works for all users | 17:37 |
| Keybuk | nothing more than that | 17:37 |
| bryce_ | Keybuk: arghhh | 17:37 |
| wwoods | esp. since debuginfo data isn't private or unique per-user | 17:37 |
| Keybuk | bryce_: I'm not being clear? | 17:38 |
| wwoods | we also cache the data very aggressively, so e.g. libgcc's debuginfo only gets pulled down the first time you attempt a trace | 17:38 |
| bryce_ | Keybuk: far from it! | 17:38 |
| slytherin | Keybuk: yes, still it gives me this problem. I am not able to understand why. | 17:38 |
| Keybuk | slytherin: then it's not a bug in udev or HAL but in whatever else you're using | 17:38 |
| Keybuk | bryce_: ok | 17:38 |
| bryce_ | Keybuk: is your question, "Why does xorg take 2.7 sec to start up" or "what is happening after the 2.7 mark that is delaying xsession to start until after 5 sec?" | 17:38 |
| Keybuk | bryce_: *both* | 17:38 |
| wwoods | (plus fedora/red hat debuginfo is packaged with symlinks for those unique filenames) | 17:39 |
| Keybuk | bryce_: the Moblin X server completes init at fwict 1.76s and the first client runs by 1.901s | 17:39 |
| === mkrufky-away is now known as mkrufky | ||
| wwoods | pitti: so, anyway, I'd suggest that step 1 toward doing retracing client-side would be to turn on --build-id for new builds.. someday | 17:39 |
| Keybuk | bryce_: our X server completes init at 2.74s and the first client doesn't run until 5.8s! | 17:40 |
| Keybuk | on identical hardware | 17:40 |
| Keybuk | both of these things are problems | 17:40 |
| pitti | wwoods: right; however, with the myriad of ddebs existing already I guess we'd have a fallback to version-based paths at least for some time | 17:40 |
| slytherin | Keybuk: gxine is playing the DVD. So I am wondering if it has anything to do with the libdvdread transition. | 17:40 |
| bryce_ | Keybuk: yes but I think they're _separate_ problems | 17:40 |
| Keybuk | slytherin: no idea | 17:40 |
| Keybuk | bryce_: sure, I'm happy to believe that ;) | 17:40 |
| slytherin | I will check any similar bugs in Debian | 17:41 |
| bryce_ | but so far when I've talked about one, you've brought up the other, and vice versa, which is making me pull my hair out talking with you :-) | 17:41 |
| Keybuk | bryce_: (#1) X server startup takes too long and (#2) X clients take too long to start | 17:41 |
| Keybuk | bryce_: ok :p | 17:41 |
| bryce_ | Keybuk: for #2, what I've said is that it appears from the boot chart that HAL is doing a LOT of activity during that period, so I suspect it | 17:41 |
| Keybuk | bryce_: it's not related to HAL | 17:41 |
| bryce_ | Keybuk: you've said that | 17:42 |
| === thekorn_ is now known as thekorn | ||
| bryce_ | Keybuk: you've not explained why it's not | 17:42 |
| wwoods | pitti: yeah, you'd need a fallback somewhere. does your gdb have build-id magic? (try: gdb, "show build-id") | 17:42 |
| Keybuk | bryce_: because almost all the activity you're seeing HAL do is *caused* by the various bits starting up | 17:42 |
| pitti | wwoods: "undefined command" | 17:42 |
| Keybuk | mostly gnome-power-manager | 17:42 |
| Keybuk | and because | 17:42 |
| Keybuk | if I start gdm by hand after the boot has long since finished | 17:43 |
| Keybuk | then it still takes just as long | 17:43 |
| wwoods | pitti: alas, that's a no | 17:43 |
| wwoods | I'll have to ask if/when that's going upstream | 17:43 |
| bryce_ | ok | 17:44 |
| Keybuk | bryce_: for example, http://people.ubuntu.com/~scott/mini9_jaunty-20090218-7.png | 17:46 |
| Keybuk | bryce_: Xorg starts at 12.5s, "finishes" at 16s | 17:46 |
| Keybuk | but all the HAL stuff is well done by 11.5s | 17:46 |
| Keybuk | (I think the post-init delay might be gdm/ConsoleKit related | 17:47 |
| Keybuk | since both times I see a gdm burst of I/O right after the X init finishes | 17:48 |
| Keybuk | so I can rule that one out for now | 17:48 |
| Keybuk | so it's just the #1 issue - 2.7s init vs. 1.7s init for allegedly identical code that interests me | 17:48 |
| bryce_ | ok, the #1 issue I can deal with more easily, since it's all outlined in the X log | 17:49 |
| Keybuk | sorry for being overly confusing, but X is a big mystery to me still ;) | 17:49 |
| bryce_ | I guess the #2 issue is really 2.7->3.5sec but we lack log info so it's sort of a mystery at this point | 17:49 |
| ion_ | Is our X server slower than the rest, or is Moblin’s faster than the rest? | 17:50 |
| wwoods | pitti: hrm. it's in the docs on sourceware.org, and I see patches sent upstream in Sep. 2007; I have to assume it's in upstream gdb | 17:50 |
| pitti | wwoods: might need a configure option which we just didn't turn on | 17:50 |
| wwoods | pitti: either way, if you have a way to map from a unique ELF file to a unique path name, then this method should work | 17:50 |
| pitti | wwoods: either way, if there's a patch, that part should be easy | 17:50 |
| bryce_ | Keybuk: well fwiw, I notice just at the very tip start of the log file that already it's faster by 2x | 17:50 |
| bryce_ | [ 0.017635] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Mar 12 14:15:49 2009 | 17:50 |
| bryce_ | vs | 17:51 |
| bryce_ | [0 sec: 005113 usec](==) Log file: "/var/log/Xorg.0.log", Time: Thu Mar 12 15:22:41 2009 | 17:51 |
| wwoods | I'm trying to make it as simple as possible to port the debuginfofs stuff for other distros | 17:51 |
| wwoods | so we can all share.. and so apport can stop sending cores upstream. heh. | 17:51 |
| bryce_ | and actually in this case the Moblin case has printed out more lines of text into the log file, but X hasn't really even begun to do anything | 17:51 |
| bryce_ | Keybuk: have you ruled out other things like caching or compiler optimization or other system effects? | 17:52 |
| Keybuk | bryce_: what kind of caching? | 17:52 |
| Keybuk | the one thing I haven't tried is building our X packages with -march set to i686+sse2 | 17:52 |
| Keybuk | (their binary doesn't even work for some ddx-related reason) | 17:53 |
| === fader|lunch is now known as fader | ||
| calc | uh translate-toolkit appears broken on the buildds | 18:24 |
| calc | who needs to be made aware of this issue, IS? | 18:25 |
| calc | or is it already being worked on? | 18:25 |
| calc | __main__.PyCentralError: package has no field Python-Version | 18:27 |
| calc | hmm | 18:27 |
| calc | mvo: ping | 18:28 |
| calc | mvo: looks like you were the one that broke it? :) | 18:28 |
| mvo | calc: eh | 18:29 |
| mvo | calc: could you give me the buildlog please? | 18:29 |
| mvo | calc: I fixed a bunch of stuff, I would not call that "broke it" ;) | 18:29 |
| calc | mvo: heh :) | 18:29 |
| calc | mvo: log is here http://launchpadlibrarian.net/23831853/buildlog_ubuntu-jaunty-amd64.openoffice.org_1%3A3.0.1-5ubuntu2_FAILEDTOBUILD.txt.gz | 18:30 |
| calc | mvo: if i am reading that correctly now with new python-central translate-toolkit needs updating? | 18:30 |
| mvo | calc: sounds like it, I can have a look. lots of package need updates | 18:31 |
| calc | mvo: ok :) | 18:31 |
| calc | mvo: i don't know what to do wrt fixing it so if you can fix it that would be great :) | 18:31 |
| * calc hugs mvo | 18:31 | |
| pitti | jdstrand: would you have a minute to review gnome-themes-ubuntu in source NEW? | 18:33 |
| * ogra sighs deeply about missing ctrl-alt-bkspc ... having a live image where gdm is constantly crashing and only one console makes that really needed | 18:37 | |
| jdstrand | pitti: sure | 18:38 |
| ogra | bryce_, we really really hould consider keeping ctrl-alt-bkspc unitl RC during development releases, it has bitten me really often now that i was screwed through it missing on live images i worked on | 18:38 |
| fader | ogra: +1 | 18:40 |
| ogra | i totally agree its not needed in releases ... but during development its a helpful safety net | 18:41 |
| calc | ogra: its not needed in releases only in the all bugs are fixed case... (which in reality is never) | 18:41 |
| calc | and sysrq-k doesnt work nearly as well | 18:42 |
| calc | since it messes up the framebuffer, maybe KMS will fix that bit though | 18:42 |
| ogra | well, its not *that* necessary in releases ... and you can easily install dontzap in the released version | 18:42 |
| LaserJock | or doesn't work at all | 18:42 |
| calc | ogra: you don't know you need it until its too late, generally | 18:43 |
| calc | i guess once you get bitten once you then turn it on for recurrent cases | 18:43 |
| ogra | but if i try to debug an X issue on a liveimage where my ttys die and i have to call all initscripts manually (which takes 30min or so) from single user mode ... and then ralize i have to start over because i cant kill X thats kind of wasting my dev time | 18:43 |
| mvo | doko: is "Python-Version: current" something that python-central should support? the change I did to make invalid python-versions fail (in my recent upload) seems to now reject checkbox. do you have any hints for me? | 18:44 |
| ogra | i didnt really need it yet on my work machine ... | 18:44 |
| ogra | but i need it during work on images | 18:44 |
| calc | ogra: i had to use it a few times already in the past month or so | 18:45 |
| calc | ogra: i don't remember why anymore but i remember turning it back on after wishing it was still enabled | 18:45 |
| ogra | i used it when i tested out UXA vs EXA here, and it was very handy ... | 18:46 |
| ogra | but beyond that i dont need zapping for normal operation | 18:46 |
| LaserJock | ogra: it'd make sense to turn it on during devel but I think it'd be good to have a wiki page or something that describes a devel -> stable delta so we know what things are bugs/regressions and which aren't | 18:46 |
| ogra | right | 18:47 |
| LaserJock | like if we want to bump up U-M checking frequency during devel | 18:47 |
| * ogra wont comment on u-m anymore :P | 18:48 | |
| ogra | getting on lwn with my comment was really enough ... i'll keep away from that topic | 18:48 |
| * ogra doesnt like being quoted as a CoC violation | 18:49 | |
| LaserJock | I can imagine | 18:49 |
| calc | ogra: heh :) | 18:50 |
| mvo | calc: almost done (I hope). the update to 2.6 requires quite a bit of manual labor for earch source | 19:03 |
| mvo | calc: how can I test that? | 19:03 |
| mvo | other than that it installs | 19:03 |
| maswan | is there a mirror available that has intrepid-proposed included into intrepid? (trying to netinst test with the netinst images from -proposed isn't working all that great when trying to download modules from normal intrepid) | 19:05 |
| cjwatson | maswan: have you tried booting with apt-setup/proposed=true? | 19:06 |
| cjwatson | that's available for this purpose | 19:06 |
| maswan | cjwatson: ah, right. sorry, that might have been too sane for me. :) | 19:06 |
| cjwatson | might not, er, be documented anywhere | 19:07 |
| mvo | calc: uploaded, good luck | 19:08 |
| calc | mvo: if it installs then it probably works i guess, many programs use it for building | 19:08 |
| calc | mvo: all i really know about it is it is needed for OOo | 19:08 |
| * mvo wonders if there is a bzr tree for pycentral to figure out certain changes | 19:08 | |
| cjwatson | maswan: oh, https://wiki.ubuntu.com/Testing/EnableProposed | 19:08 |
| cjwatson | I'll put it on Installer/FAQ too | 19:09 |
| maswan | cjwatson: oh, look, there it is. I didn't see it for all the repo instructions, or something. :) | 19:09 |
| tormod | Keybuk: how is the desktop user added to the /dev/dri/card0 ACL? | 19:13 |
| Keybuk | tormod: is there one? | 19:16 |
| tormod | I think so. Otherwise how do users (who should not be in "video" group) access it? | 19:17 |
| tormod | I am not a video member, but the ACL has user:tormod:rw- | 19:17 |
| Keybuk | ah | 19:17 |
| Keybuk | it's done by HAL | 19:17 |
| tormod | when I log in? | 19:18 |
| Keybuk | yes | 19:18 |
| tormod | is that a dbus request from gdm or something? | 19:19 |
| Keybuk | gdm creates you a new ConsoleKit session | 19:19 |
| Keybuk | ConsoleKit informs PolicyKit of the new session | 19:19 |
| Keybuk | since HAL uses PolicyKit to apply ACLs, and generally has "current session" authorisation | 19:19 |
| Keybuk | it is alerted that the ACLs needed to change | 19:19 |
| tormod | thanks, lots of new stuff to learn I see | 19:20 |
| Keybuk | it's made of lots of awesome | 19:20 |
| Keybuk | since if you logout, your acls go away ;) | 19:21 |
| Keybuk | CK/PK do much, much more of course | 19:21 |
| tormod | in the end, we just need to fix users-admin to not show and create the "video" group then. | 19:22 |
| tormod | s/create/add | 19:22 |
| Keybuk | none of those groups are relevant anymore | 19:22 |
| Keybuk | other than perhaps "admin" :p | 19:23 |
| tormod | where is this stuff configured, now that it's not in /etc/group any longer? | 19:23 |
| Keybuk | tormod: System -> Administration -> Authorizations | 19:23 |
| tormod | thanks, I meant file-wise | 19:24 |
| Keybuk | the defaults are in /etc/PolicyKit/PolicyKit.conf | 19:25 |
| Keybuk | granted authorisations are in /var/lib/PolicyKit | 19:25 |
| wwoods | there's also the polkit-auth tool for managing them | 19:25 |
| === mthaddon_ is now known as mthaddon | ||
| mvo | calc: I fixed a issue in pycental as well, I hope things are more happy when that is all published | 19:45 |
| calc | mvo: ok | 19:47 |
| ogra | mvo, wow, thats really cute ... ! | 20:26 |
| * ogra hugs mvo for getting rid of the need for KVM for sandbox upgrade tests | 20:27 | |
| * Nafallo_ ponders if ext4 is stable enough yet. | 21:24 | |
| === Pricey is now known as EvilChild | ||
| === Amaranth is now known as EvilAm | ||
| === EvilAm is now known as Amaranth | ||
| mvo | ogra: heh :) glad that you like it | 22:34 |
| adelie42 | Hello, I am a long time hobby programmer, but new to this collaborative environment. I just spent today fixing some bugs, but I think I "did it wrong". I used 'apt-get source' to get the package, but now it looks like I should have gotten the source via 'bzr branch'. I have been following http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html but still feel a bit lost. Any assistance? | 22:41 |
| === cody-somerville_ is now known as cody-somerville | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
