=== asac_ is now known as asac [09:12] morning everyone [09:13] lut huats [09:13] lut seb128 [09:14] I haven't forgotten all the stuffs I need to do (nautilus send to, the gucharmap SRU...). I am pretty confident for tomorrow :) [09:14] huats: no need to do nautilus-sendto now, it has been accepted since [09:15] (I was refering to checking on the hardy box) [09:16] but no pb :) [09:16] right, I understood [09:16] something to put out of my daily TODO :) [09:16] I commented on the bug and somebody else did testing [09:16] (well I misunderstood at first glance :)) [09:18] I hear you're the ones to speak to when having problems with console-kit-daemon (or so said #ubuntu-server people) - It was whining about failing to initialize libpolkit. I *seem [09:19] * to have solved this by installing policykit. Now, how does policykit work? I noticed the init script doesn't really do anything. [09:19] Oh. This channel isn't for help either? [09:20] * soren wonders if pitti has a hilight on policykit :) [09:21] Alright..noone wants to touch that. [09:22] How about CRON issues? Or is that a -server issue? Sigh [09:22] You're new to IRC? [09:22] Yes. [09:22] People are busy. It sometimes takes more than a minute for people to notice a question and type an answer. [09:22] gammy: that's not an user question channel no but pitti is nice to users and might reply when he'll be around ;-) [09:22] Lies! [09:22] I myself have 381 irc windows open. It takes time to notice stuff that way. [09:22] People are supposed to help me directly 24/7! [09:22] Everyone knows that. [09:23] seb128: User question channel? What does that mean? [09:23] soren: you are crazy [09:23] A channel for user questions, I imagine. [09:24] seb128: Quite possibly. [09:24] right, that's not a support channel, usually we direct questions to #ubuntu rather [09:24] Ah yes I see [09:24] I misread the InternetRelayChat list [09:24] I searched it for "desktop" and didn't look at the header [09:24] My apologies [09:25] (Ie, I did not know "Team Channel" was equal to "not user question channel"= [09:25] ) even [09:26] well your question is rather a technical one so that's okish [09:26] is it? I think it's a pretty straightforward question :o [09:26] User questions are usually stuff like "Hey, where'd my icons go" or some such. [09:26] Basically "why does the policykit init script not init?" [09:26] Hehe [09:27] ..and that sort of thing belongs in #ubuntu. [09:27] I'm very new to ubuntu, I'm coming from Slackware so a lot of stuff is different. [09:27] Unless it's server related in which case it's kosher in #ubuntu-server as well. [09:27] soren: Yeah so rephrasing makes it non-technical ;) [09:27] gammy: Sometimes, yes :) [09:28] policykit is used for authentification by other layers in the system, that's not a running service [09:28] it seems like the segmented channels are very "We'll tell you if it's on topic or not" without much possibility of the person asking the question figuring it out by herself :) [09:28] gammy: what's up? [09:28] soren: no, I don't [09:29] seb128: Alright. So how does it actually work? Is there an ubuntu help page about it? [09:29] read the code? ;-) [09:29] or do you have a specific question [09:29] it has mechanism to grant authorisation, what do you want to know exactly? [09:30] My specific question would be: What does console-kit-daemon use libpolkit for and why is it not a dependency if it's required? [09:31] gammy: It's really not that complicated, usually, but when it is, people are likely to tell you where to ask instead. Contrary to what you seem to believe, that is actually a more useful answer than "I don't know". [09:32] soren: People didn't tell me where to go. I asked about it and got elitist bullshit back instead. It took quite some time before anyone stopped saying "that's desktop-related" :P [09:32] But I now of course understand that I should not be speaking in anything but #ubuntu since that's the help channel. I just wish someone would have told me that. [09:33] * soren finds something better to do [09:34] gammy: that's actually a known problem: bug 275432 [09:34] Launchpad bug 275432 in policykit "libpolkit requires files from policykit for polkit_context_init to work" [Unknown,Confirmed] https://launchpad.net/bugs/275432 [09:34] gammy: CK needs PK to verify that an user is able to shutdown/reboot the machine [09:34] * gammy reads [09:34] gammy: we actually complained very loudly upstream about this dependency, but they wouldn't listen :( [09:35] so now every distro is sitting on this problem actually [09:37] pitti: Ahh James Westbys notes are very interesting [09:37] yeah, he analyzed it in detail [09:40] Very interesting. === Keybuk_ is now known as Keybuk === davmor2 is now known as davmor2_lunch === davmor2_lunch is now known as davmor2 [14:36] lool: would be nice if you could comment on ubuntu changes when they go to ubuntu rather than waiting to get the update in debian to say that should be done some other way around ;-) [14:37] seb128: How do you suggest this to happen? [14:38] My proposal was to try to keep the Debian platform in sync [14:38] lool: read -changes and when you see something which seems wrong write something on IRC? [14:39] lool: right, we try to do that but can't block on debian or intrepid would still have GNOME 2.22 because the new gtk is not available [14:39] I don't expect I'll have more time to read -changes than I did past cycle; nor do I find this a good channel to spot such changes [14:40] ok, I though you were reading the -changes lists [14:40] I do [14:40] Not in full [14:40] well I though you would read the changelog when a new gtk is landing for example [14:41] I don't :-( [14:41] especially when you said you would look at it for the fileselector changes and hildon [14:41] I guess there is no easy way to avoid such situations then [14:41] You mean hildon-fm support stuff? We dropped that completely, it was unportable [14:42] right, I just know I pinged you when I did the gtk update because the fileselector changes where breaking some patches mobile was using [14:42] I think that's quite orthogonal to the issue at hand [14:42] anyway we will probably sync debian changes if the package goes a different way there [14:43] right, I just assumed you did look at this GTK update for some reason [14:43] I'd love to be able to read the whole changes of all packages I care about, but the tempo is just too high for the time I have; would I be still in the desktop or foundations team, I might have a stronger incentive to track this closer [14:44] right, I know the issue [14:45] and I'm too busy to get new versions in debian first, especially when that requires directfb changes which I've no clue about [14:45] so I guess we either have to do with such glitches [14:45] It's unfortunate that Debian and Ubuntu diverge on package names, but the only way to avoid it for sure is to make sure the changes are accepted in Debian and Ubuntu; I don't have a better idea for this [14:45] or just stop trying to be sync if that's wasting energy rather than being useful [14:46] seb128: One point of contention is usually regressions [14:46] seb128: I know that I'm not going to upload a package with serious regressions to Debian [14:47] While in Ubuntu we might just live with them for parts of the cycle hoping they are fixed before the end of the cycle [14:47] right [14:47] Another issue is that the Ubuntu packaging changes are only visible to Ubuntu people the way we currently do [14:48] I think you experimented with keeping control-center in bzr this cycle? [14:48] mvo put a bunch of desktop packages in bzr [14:48] Would the Ubuntu packaging be "near" the Debian one in terms of VCS, it would expose such issues more evidently too [14:48] gnome-control-center being one of those [14:48] seb128: How did it go? [14:48] smoothly [14:49] I don't think it brings anything really useful but it doesn't cost a lot either [14:49] bzr-builddeb works correctly nowadays [14:49] it would be nice if we had a way to announce commits on IRC for example though [14:50] (Unfortunately in this case, bzr is a divergence between Debian and Ubuntu, but a DVCS could help solve part of the problem) [14:51] Np237 seems to hate the DVCS concept [14:51] Or having a repo per module [14:51] vcs++ [14:52] seb128: So if we could share packaging between Debian and Ubuntu in terms of tools, it would help getting the changes reviewed as they occur IMO, and not only by me; but it's not an easy task [14:52] I'm coming forth and back on those [14:52] dvcs have advantages but for packaging that's pointless since usually your changes are a few liners and that complicates things [14:53] having a source tree where we would have the upstream tarball imported in a tree, and two packaging branches (debian, ubuntu) would be really cool [14:53] with the ability to do merges between debian and ubuntu [14:54] mvo: Ack [14:54] I know that seb128 does not see a lot of benefit, but for me just having bzr diff/revert is already a great help [14:55] I also like that people can work on the package at the same time [14:55] without having to fear clashes [14:55] mvo: I personally wouldn't want to push too early for this though; one thing which would be a strong incentive to move to dvcs would be GNOME moving to one of htem [14:55] mvo: Say, GNOME moves to git or bzr, I think it would make sense for Debian and Ubuntu to follow [14:55] right [14:55] git [14:55] uuuuu [14:55] that's mainly useful if you get the full source in the dcvs then and not only the debian directory [14:56] mvo: right, when I do a typo in the "new upstream version" changlog entry I find bzr revert useful too ;-) [14:56] heh :) [14:56] Let's not enter git versus bzr; I can live with both and I find both solve our actual top problems; the problems they cause are IMO lower priority [14:56] mvo: joking but that's about the amount of changes we usually do [14:56] There's value in having the same as upstream [14:56] yeah [14:57] I agree, I think we shouldn't divert unless its totally transparent (which it will not be) [14:57] I mean, if we had a bzr-git-import that that would be totally flawless [14:57] mvo: and that doesn't avoid clashes if you don't push changes, and if you push you can as well upload [14:59] Apart of upstream moving to a DVCS, the two things which I'm looking after for Debian is: a) quality of the tools to do the job with mass-packages and b) importing pkg-gnome history [14:59] The tools for git and bzr packages are fine nowadays, except concerning mass actions [14:59] (We have 200+ packages in pkg-gnome!) [15:00] and more than 120 considered official platform/desktop stuff [15:00] right [15:00] seb128: well, a push usually has a much smaller amount of data and if its just a typo fix for example then why push it to every user and to the buidds etc. but yeah, I see your point [15:01] mvo: anyway as said the workflow nowadays is basically as easy so there is no strong reason to no use a dvcs there [15:01] it's just nice to have a consistant way to changes across the board [15:01] or at least across the team board ;-) [15:03] lool: hm, currently everything is maintained in svn, right? so where is e.g. bzr inferior to that? [15:05] mvo: You can checkout the whole tree of 120 desktop packages and work on them [15:06] I see [15:06] mvo: I think bzr is superior, but it's a lot of work to import (and fix!) the history of the packages if we want to convert the single repo to many bzr repos [15:06] Also, I'm not sure I would want the packages to be in bzr if upstream moves to git [15:07] hmm [15:07] i am certainly liking bzr more than git [15:07] you should be more active upstream and push to use bzr [15:07] :) [15:07] dobey: Step 1, being more active upstream, not being the easiest one [15:08] There's already a lot of traction to move to git upstream [15:08] it's actually really easy [15:08] From xorg, and from cairo for instance [15:08] and gtk+ [15:08] GStreamer also had plans, but I'm lost in them [15:08] yeah, because the fd.o types are using it already [15:09] and bzr seems like this canonical-only thing because people aren't being as active upstream, and launchpad seems like this big closed source monster they can't get around [15:09] * mvo -> phone === mvo_ is now known as mvo === espacious_ is now known as espacious [19:18] http://galleri.vacum.se/index.php?dir=&page=&prev=gparted.png <-- known? :-)