=== bjf is now known as bjf-afk [00:20] re [00:20] Laney, still there? [00:21] RAOF, who complained about the f-spot update exactly? [00:21] Laney. [00:21] bah [00:22] please take it constructively [00:22] I just read the meeting logs [00:22] I can't believe me fixing bugs for lucid is a troll subject now [00:23] * Laney rolls eyes [00:23] Laney, most of the changes are upstream git backports and I got the most of the other ones commited after the upload [00:23] I'm not sure what we would win by us to open every upstream bug and git commit in the bts too [00:23] I know you work with upstream, but you could also work with Debian too [00:23] I can start doing that if you want [00:24] I can open every bug with get in launchpad in the bts [00:24] and a bug in the bts for every git commit too [00:24] but I fail to see that as a good use of my time or of yours [00:27] I'm sorry that you can't see that I was trying to be constructive [00:27] well so tell me what I should have done there [00:28] knowing I had closing those hundredpapercut bugs on my todolist for weeks and I managed to free one hour to do that [00:29] ie I don't have enough free time to start argue in the bts for every choice we take in ubuntu [00:32] Laney, ? [00:32] Laney, would you be happier with me sending a debdiff in the bts? or a bug for each changeset? [00:32] Laney, or me pinging you guys with a list of changes I want to upload [00:32] in which case how long do you want us to wait if you are busy or not interested to get those uploaded? [00:33] you can even just talk to us directly, yes [00:33] and of course it is your right to upload what you need to [00:33] hopefully we will be able to give you some kind of indication as to our thoughts [00:33] seb128: "knowing I had closing those hundredpapercut bugs on my todolist for weeks and I managed to free one hour to do that" [00:34] if you had mentioned the patches a week ago, could you have synced today instead? [00:34] james_w, the patches are sitting in upstream git and launchpad for weeks [00:34] I did comment on the bug saying that if upstream doesn't roll a tarball I would upload those before beta [00:35] on the bug*s* rather [00:35] which I did [00:35] we could even think about pushing a snapshot of the stable branch [00:35] which we did for mono [00:35] I did considering doing one [00:35] So, perhaps what could happen here is actually the reverse? That pkg-cli-apps should be subscribed to the packages in Launchpad, and proactively pulling bugs from there? [00:36] but I didn't want to fight autotools for that [00:36] and there was some hundredpapercut fixes which were not in git anyway [00:36] though I did ping #f-spot again and got 3 of those commited since [00:37] also I fail to see those change as interesting for debian, that's purely doing some upstream fixes snapshothing to match your schedule [00:38] debian will probably be better to just wait the next tarball in some weeks [00:38] and we can sync again after lucid [00:38] right, but if they were to say they were interested, and do the snapshot themselves, they you would have less work? [00:38] there is no reason to play backport every git commit when you are not about to freeze [00:39] james_w, could be but I doubt it [00:39] most of the active members of the team are Ubuntu users, you know [00:40] as said those changes where sitting there for weeks [00:40] anybody could have picked and uploaded to debian [00:41] I did it yesterday because now was time to get those in lucid [00:41] seb128: but you were just saying that they had no need to for Debian's sake. Knowing that it would be useful to Ubuntu may have been a trigger. [00:42] well I wanted to get that done yesterday [00:42] I didn't want to dump a list of 15 bugs on debian and say "get that uploaded today or I will upload to lucid" [00:43] I would consider that rude, they don't have to react to our schedule or me wanting to get changes in lucid [00:43] I'm fine for them to pick that when they want or wait for next tarball and we can sync again next cycle [00:44] it would have been as much work to open debian bugs than just upload and let them cherrypick if they want from the upload [00:45] right, I was just asking as you said that you had been wanting to get the papercut bugs uploaded for weeks [00:45] which implied you had a list of bugs you were going to look at and asses patches from [00:45] so taking 10 minutes to ask if someone else could go over that list might have saved you some effort [00:46] https://bugs.edge.launchpad.net/hundredpapercuts/+milestone/lucid-round-7 was the list [00:46] and I've been pointing it regularly on #f-spot [00:47] but anyway troll aside it doesn't really reply to my question from before [00:47] Laney, how would you like me to process next time I've a list of changes or bugs we want to fix? [00:48] drop you the list by email? on IRC? [00:48] wait for you guys to do the work? how long? [00:48] I'm sorry but I don't see why you couldn't pick patches from an upload rather than from bugs [00:49] it's quicker for me to upload that to open bugs for every issue in the bts [00:49] and it shouldn't be extra work for you either [00:51] you should think of working with the Debian maintainers as a helpful thing, not a hindrance. If you want us to consider including a patch then just let us know. We are quite able to communicate sensibly. [00:52] and if we ever disagree then of course you can upload what you need to [00:52] ok fine [00:52] what is your prefered way to know about a patch? [00:52] IRC ping? being subscribed on launchpad and who? bug in the debian bts? [00:52] IRC is fine. [00:52] note that I usually do [00:53] And, I guess in future, subscribing the pkg-cli team on launchpad might be worthwhile? [00:53] but I didn't think dropping 10 git commit or bug numbers out of the blue to you would be useful [00:53] I don't know how that will work, but maybe [00:53] we'll have to work this out [00:53] as said Debian can as well wait 10 days for the next tarball and spare all the extra work [00:54] right, we might have done that indeed. [00:54] but we didn't get the chance in this case :) [00:54] ;-) [00:54] well I didn't want to block on anybody or pressure anybody [00:55] but I note for next time to try to schedule earlier and ask when we have time [00:55] so we can sit a bit on people to pick changes or not [00:55] and then decide on what we need to do [00:55] we never had real issues keeping f-spot in sync and I see no reason why we should have some now ;-) [00:57] generalising somewhat, there are also some gbrainy changes that you guys did which Debian certainly would take [00:57] anyway I must go to bed [00:57] goodnight [00:58] goodnight Laney [00:58] 'night Laney [00:58] Night [00:58] I think there will be a better time to address this issue [00:58] and I'm not responsive for those ;-) [00:58] yes [00:58] as we are in beta 1 time, I think tensions will run high, and focus needs to be on Ubuntu quality [00:58] and I think we also need to discuss Debian pulling our work [00:58] let's solve this at UDS [00:58] yes [00:58] rather than always expecting us to ask them before [00:59] at UDS or the right venue [00:59] this is not the time or place [00:59] * rickspencer3 points to Ubuntu users waiting for Lucid LTS [00:59] :) [00:59] ;-) [01:01] seb128: have you seen build failures in lucid on packages that use scrollkeeper for docs because the build tries to get scrollkeeper-omf.dtd from the net? [01:02] LaserJock, no [01:02] hmm, weird [01:04] it's weird the dtd should be installed locally [01:04] rarian-compat: /usr/share/xml/scrollkeeper/dtds/scrollkeeper-omf.dtd [01:06] yeah ... except my package doesn't have a dep on rarian-compat [01:06] but this thing builds in Debian fine [01:13] weird [01:13] anyway time to go to bed there [01:13] 'night [02:51] mclasen: hey [02:51] yes ? [02:51] talked to company a bit earlier today [02:51] did you see it? [02:51] I saw him do my work for me, yeah [02:51] :) [02:52] i'm going to merge a substantial simplification to the API [02:52] all memory management is being removed [02:52] and it's going stack-allocated [02:52] I'm all for simple [02:52] then open() and close() are going to become solely operations on the builder itself -- no constructing new builders [02:53] it will have _init(&builder) / _clear(&builder) API style [02:54] do you feel that this is acceptable? [02:55] a bit different from GString then [02:55] there's another alternative [02:55] do the same thing but make it trivially heap-allocated [02:56] this reintroduces the problem of if end() should do a free or not... [02:56] the nice thing about the stack-allocated approach is that if you try to clear it twice you just see a bunch of zeros the second time [02:56] instead of trying to access invalid memory [02:57] is there a strong danger of freeing twice here ? [02:57] yes [02:57] I mean, any stronger than for any other _unref function ? [02:57] yes [02:58] gstring has exactly the same problem [02:58] but it is mitigated by being able to directly access the ->str [02:58] the "official" way to get the finished string is to call _free() with the 'free_contents' set to FALSE [02:58] then use the return value [02:58] this has the side-effect that the GString structure itself is freed [02:59] that really can't be bound... [02:59] direct access is totally a supported operation for GString [02:59] so, will the stack-based approach be ok for bindings ? [02:59] yes. but it doesn't exist for gvariantbuilder [02:59] i'm inclined to think yes because it's very similar to other APIs that we already have [02:59] GValue comes to mind [03:00] a stack-allocated structure that needs to be 'unset' in order not to leak [03:00] might be worth having some binding guys look at it [03:00] but it sounds ok to me [03:00] i might just go shopping for other examples [03:00] and see how they get dealt with [03:04] RAOF, ping [03:04] kenvandine: Pong. [03:04] hey [03:04] Howdie. [03:04] so are you interested in hacking on f-spot? [03:04] :) [03:04] It'd likely be fun :) [03:05] http://people.canonical.com/~kenvandine/patches/f-spot/ubuntu-edit-in-view-mode.patch [03:05] :) [03:05] Where are you up to, and what needs work? [03:05] that is the current patch [03:05] it is crashy [03:05] Ah. The *best* form of patch! [03:05] :) [03:05] it is something sde worked on in a branch of master back in nov [03:06] i back ported it to 0.6 [03:06] it is equally as crashy in his branch :) [03:06] Do we have a bzr branch to collaborate on? [03:06] nope :/ [03:06] we don't have a ~ubuntu-desktop branch for it [03:06] one sec [03:06] Well, I'll create one then. Is there particularly that makes it crash? [03:07] i did create my own bzr branch from the 0.6.1.5 tarball [03:07] https://code.edge.launchpad.net/~ken-vandine/f-spot/edit_in_view [03:07] you can branch that and just diff against -r 1 [03:07] to apply to the package [03:07] to use it [03:08] run f-spot --view [03:08] for example f-spot -b /tmp --view /some/path/to/some/photos [03:08] the -b is so it doesn't mess with your library, just in case [03:08] Ah, thanks for the heads up. [03:08] you will get a sidebar with edit operations [03:09] some of them work fine [03:09] like crop, red eye [03:09] etc [03:09] but the ones that have live preview updates blow up [03:09] like straighten [03:09] or color adjust [03:09] as you move a slider it updates the view dynamically [03:10] and i think it has a problem doing that because there are still places that seem to assume you are in a library view [03:10] instead of browse [03:10] Ok. [03:10] also, there is no notion of undo for edits [03:10] since f-spot depends on maintaining revisions [03:10] Yeah. [03:11] anyway... i'll owe you if you can get it further [03:11] i am over whelmed with the social from the start stuff [03:11] RAOF, btw... welcome! [03:11] kenvandine: Thanks :) [03:13] The next task in my nouveau stuff requires someone from the kernel team to be awake :). I'm happy to help. [03:13] awesome! [03:13] well, awesome for me :) [03:27] RAOF: what kernel stuff do you need? [03:27] TheMuso: I need lbm_nouveau to end up in modules.order before vga16fb. [03:28] Otherwise, vga16fb claims fb0 and badness occurs. [03:28] RAOF: ah ok [03:29] RAOF: I am assuming this needs to be done in lbm. [03:30] I'm not really sure. modules.order is built during the kernel build, and the kernel package owns it. It'd be pretty hacky to have to try to patch it once it's installed for lbm. [03:34] RAOF: ah right. [03:34] RAOF: and a dempod doesn't overwrite that change? [03:35] TheMuso: I'm pretty sure it doesn't. [03:35] No, depmod in fact uses it as an input file. [03:36] http://lwn.net/Articles/260856/ [03:36] ah ok. [03:37] It's remotely possible we might want some of extensible solution for dealing with this, but I think it's pretty niche, and we'll just need to cook something up specially for nouveau. [03:37] mclasen: looks unbindable, actually [03:37] mclasen: not to say that it can't be bound -- but rather that ever other case we have of a similar API appearing in our libraries is unbound [03:38] mclasen: i'll add the _new()/_free() [03:38] desrt: thats ok for me too [03:38] mclasen: bindings can _new()/_free() as they'd expect [03:39] mclasen: C users can _init() and not worry about the free [03:46] RAOF: right [04:13] kenvandine: I can see why you'd have problems working on f-spot :/ [04:14] Consistent indentation is for people who don't have in-built C# parsers. [04:31] Well, that's significantly less crashy... [04:32] Ah. Export will be broken because we don't actually have a database, I guess. [04:38] RAOF, indeed [04:39] Well, editing now works at least. [04:39] excellent [04:40] RAOF, another thing to test is in library mode [04:40] does editing still work? [04:41] Let's see! The patch ended up being annoyingly small, given the time investment. On the plus side, at least my changes shouldn't break anything :) [04:42] good :) [04:46] Whoops. Crash! [04:48] RAOF: I see xserver-xorg-video-nouveau 1) doesn't depend on server backports modules for nouveau 2) doesn't have a system in place to choose the correct backports oduleto depend on, depending on the architecture. [04:48] gah [04:48] 2) doesn't have a system in place to choose what backports modules to depend on, given different architectures and kernel flavours. [04:50] RAOF: oh and 3) the depends for generic or generic-pae probably won't work properly if a user has a generic-pae kernel but gets -generic installed. Haven't looked at this closely, but at a glance I suspect that won't work. [04:50] TheMuso: These are both correct. One of the things I want to discuss with the kernel team is whether linux-meta could simply depend on the appropriate lbm-nouveau package. [04:51] RAOF: ah [04:51] makes sense. [04:51] Because x-x-v-nouveau depending on *any* kernel-like package has unwanted side-effects. [04:51] yep agreed. [05:56] * RAOF wonders if f-spot needs *quite* so much state distributed across files/components/space/time [06:25] Ok. Time for a walk & some shopping. I'll be back later to finish f-spot and catch apw. [06:30] gdm2setup being proposed for Lucid Universe - bug #531138 [06:30] Launchpad bug 531138 in ubuntu "[needs-packaging] gdm2setup" [Wishlist,Triaged] https://launchpad.net/bugs/531138 [06:30] please review and comment [07:10] robert_ancell: hi... the ayatana mail requesting review for simple scan would be better dealt in gnome usability mailing list [07:10] vish, ok, thanks [07:32] good morning [07:39] didrocks: Good morning! [07:40] Man, HP work really hard to tailor their invoice mails to look almost *exactly* like spam. [07:41] Good morning [07:42] hi there [07:42] I didn't see pedro for a while, does he lives in chile ? [07:43] Keybuk: I get it with 100% reliability on the mini if I remove S50cups; otherwise just with ~ 50% [07:52] hey RAOF, pitti, baptistemm! [07:52] heya didrocks [07:57] bonjour didrocks [08:01] didrocks: Congrats! [08:01] lool: thanks ;) [08:02] lool, hi [08:03] didrocks, what is the job involved when your're in the technical board? [08:03] baptistemm: hum, I'm not in the technical board. I guess that's a question for pitti who was, rather ^^ === cypher___ is now known as czajkowski [08:21] is there a way to disable the fusa-functionality on lucid? /desktop/gnome/lockdown/disable_user_switching doesn't seem to have an effect [08:22] I don't want to see any local users on the list [08:22] seems indicator-session should respect this key [08:23] ok.. well it does list the guest session and some local pseudo users there [08:24] and selecting one of them does something, but then I get the "vt on xorg" bug [08:31] pitti: I'll file a bug [08:32] hmm, apparently it was fixed a couple of weeks ago.. I'll try a relogin [08:32] tjaalton: that vt on xorg is bug 511134, will fix in a bit [08:32] Launchpad bug 511134 in gdm "get a text vt over xorg when trying to switch users" [High,In progress] https://launchpad.net/bugs/511134 [08:33] pitti: yeah I sub'd to it already === tkamppeter_ is now known as tkamppeter [08:39] mpt: good morning - did you had a chance to play with the software-center.menu file, i.e. is the categorization for the subsections of graphics and internet in s-c final now? [08:39] (me wants to do a upload today for this) [08:41] hey pitti, mvo [08:42] bonjour seb128 [08:43] pitti, how are you by the fine day? ;-) [08:43] I'm great, thanks! [08:44] hey seb128 [08:45] pitti, so the compiz bug was not a bug but a syntax issue? [08:45] apparently so [08:47] ok, good to know [08:47] bryceh: xorg-options-editor-gtk, is that still something that's working/supported? [08:47] bryceh: it's using the old policykit and all that [08:52] seb128: I just commented on bug 530829; do you have an opinion and yay or nay on that cleanup? [08:52] Launchpad bug 530829 in policykit-gnome "Authorizations is old and should be hidden" [Medium,Triaged] https://launchpad.net/bugs/530829 [08:53] let me look [08:54] I read comments yesterday but I was not sure why we would care about an universe leftover [08:54] or why it would be assigned to our team [08:54] it won't be cleaned up on upgraes [08:54] and xubuntu-desktop still pulls it in (which should be fixed either way, I added a task) [08:55] pitti, why not cleaned on upgrade? [08:55] I though update-manager removed things which are in universe [08:55] seb128: nothign conflicts to it, does it? [08:55] mvo, ^ [08:55] hey seb128 and mvo [08:56] seb128: it proposes that, but doesn't enforce it; it just asks you [08:56] mvo, will the dist-upgrader remove policykit-gnome if it has been moved to universe? [08:56] seb128: but it wouldn't work for xubuntu anyway, since they kept the dependency in karmic [08:56] it was moved to universe in karmic already [08:56] pitti, well if an user decide to keep it nothing we can really do [08:56] seb128: well, I'd still like to remove it from the archive entirely [08:57] pitti, I'm a bit unsure about g-v-m there [08:57] others seem fine [08:57] * pitti drops g-v-m dep from libipoddevice [08:57] seb128: you want to keep g-v-m? [08:58] hey [08:58] hey chrisccoulson [08:58] I can understand some user want to be able to automount things without nautilus running [08:58] or without having nautilus installed [08:58] hey chrisccoulson [08:58] but it's using really outdated stuff which we stopped supporting ages ago [08:58] i was going to ask g-v-m to be removed from the archive last cycle [08:58] hey seb128 [08:58] I don't know if we have a better alternative that gvm [08:58] seb128: ivman [08:58] also using old stuff (hal), but with a lot fewer outdated depends [08:58] pretty much just hal [08:58] hello chrisccoulson [08:59] hey didrocks [08:59] but not gnomevfs, g-v-m, etc. [08:59] ok, fine with me [08:59] pitti, +1 for your summary on the bug [08:59] seb128: ok, cheers [09:11] pitti - i just noticed you've removed libipoddevice [09:11] tseliot: good morning [09:11] i'm not sure why that ended up in the archive again [09:11] chrisccoulson: I didn't -- I just dropped the depends [09:11] morning pitti [09:11] oh [09:12] pitti - i had that removed last cycle [09:12] and then it appeared again [09:12] chrisccoulson: perhaps it wasn't blacklisted then? [09:12] chrisccoulson: but "hilo" depends on it [09:12] pitti - perhpaps [09:12] oh, is that a new package? [09:12] chrisccoulson: oh, indeed [09:12] chrisccoulson: so should i remove it again? that'd break hipo, though [09:12] (not "hilo") [09:13] ah, hipo, that's why i couldn't find it ;) [09:13] so it seems hipo was just broken in karmic [09:15] tseliot: is xorg-options-editor-gtk still something relevant? [09:15] tseliot: it's one of the two remaining packages which use the old policykit [09:15] pitti: no, I guess you can safely remove it [09:15] ah, pitti: https://edge.launchpad.net/ubuntu/+source/hipo/0.6.1-2.1ubuntu1 [09:15] that's how i got around it ; [09:15] i had a look and it looked like it wasn't used anywhere [09:16] but somebody sync'd it from debian again [09:16] ah [09:16] chrisccoulson: mind to reupload it? I'll remove libipoddevice and blacklist it [09:16] pitti - it uses ipod-sharp really [09:16] yeah, i'll reupload that again [09:17] libipoddevice has been dead for ages, and it's not even hosted anywere upstream any more [09:17] (it used to be used by banshee many cycles ago, and was hosted there too) [09:19] ok, zapped and blacklisted [09:19] thanks [09:19] i will reupload hipo now [09:21] meh, so if it weren't for gnome-lirc-properties, we could remove policykit-gnome [09:21] good riddance g-v-m :) [09:23] that was a nice cleanup [09:24] back in a bit, I bring my wife to the train station [09:29] bryceh: X crashing really bad on and frequently on Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) ... known? [09:29] i think its for a week that bad now ... /me gets updates from today [09:30] * ogra has a rev 03 of the same chip which works rock solid [09:33] been fine for me [09:33] hmmm .... so how can crash it is with gnome-terminal ... ssh to a box where i have a screen with irssi running [09:33] plymouth? [09:33] sometimes typing something just crashes it :( [09:33] ah yeah sounds like you got that plymouth bug [09:34] uninstall plymouth [09:34] bryceh: ;) [09:34] bryceh: why the hell are you awake? ;) [09:34] what has plymouth to do with a running X session? [09:34] heh [09:34] i thought that is bootish stuff [09:34] thats what i'm asking myself all the time if i end up on the wrong tty after booting [09:35] during boot i dont even have a aplash [09:35] and then have X crashing after passphrase typing [09:35] asac, how fast do you boot ? [09:35] asac, was actually just on my way to bed, but wanted to check messages ;-) [09:35] * ogra only has the splash flashing by very fast [09:36] bryceh: heh. wy to bed ... wasnt there the idea of reasonable work times ;)? [09:36] good night [09:36] asac, what does plymouth-set-default-theme return ? [09:36] ogra: i have splash removed from my grub conf [09:36] ah [09:36] usually i want to see whats going on if nothing happens :) [09:36] let me try [09:36] ubuntu-logo [09:36] night [09:36] (plymouth-set-default-theme) [09:36] well, if you disabled it in grub you wont see it [09:36] indeed [09:37] asac, xorg and plymouth fight over vt [09:37] and that creates weird bugs [09:37] maybe the problem is that i turned it off? [09:37] like xorg crashing on enter [09:37]