[00:00] <slangasek> but the short summary is, "not happening tomorrow"
[00:00] <cjwatson> libffi4 was due to gnome-python2-extras needing rebuilt; I was about to poke at that this morning and noticed that somebody else was already doing so
[00:01] <slangasek> ok; still not resolved in the archive, as of my last attempt to build a livefs a couple hours ago
[00:01] <cjwatson> installer components> now, cdrom-detect actually *is* almost done, so I'll get that uploaded tonight
[00:01] <cjwatson> well, gnome-python2-extras and then rebuilds against it ...
[00:01] <cjwatson> basically libffi4 is NBS and all dependencies on it are now bugs
[00:01] <slangasek> ah
[00:01] <doko> the excessive libffi4 deps should be fixed with a recent python-gobject, plus rebuilds
[00:05] <cjwatson> there is still a rather vast swathe of merges to be done, for which I have no small responsibility
[00:05] <cjwatson> if you're not on .1 duty or have other urgent things to do, then please do get to these as soon as you have specs written up
[00:07] <cjwatson> the only other thing I have is to draw attention to Claire's mail regarding the distro sprint
[00:07]  * TheMuso has started organising flights already.
[00:07] <cjwatson> unfortunately holding both halves of the sprint side-by-side in London didn't work out, but we will all still be in London on the previously-mentioned dates (14-18 July)
[00:08] <cjwatson> and there may be some kind of conference link to Lexington during the timezone overlap, so plan anything in advance that you need to work on with the kernel/server/mobile teams
[00:08] <cjwatson> any other business? I haven't found any in activity reports yet
[00:11] <cjwatson> I'll take that as a no, then
[00:12] <cjwatson> adjourned, not too badly over time
[00:12] <cjwatson> thanks all
[00:12] <bryce> thanks!
[00:12] <ArneGoetje> thanks
[00:12] <slangasek> thanks
[00:12] <calc> thanks
[00:12] <liw> merci boucoup
[00:12] <ogra> thanks
[00:12] <TheMuso> thanks
[00:12] <evand> thanks
[00:14] <asac> thanks
[07:52] <pitti> hi
[07:53] <slangasek> morning
[07:53]  * Hobbsee waves, throws brains around
[07:53] <evand> hello
[07:54] <TheMuso> Greetings.
[07:58] <lool> morning
[07:59] <seb128> hello
[07:59]  * slangasek waves
[07:59] <sbeattie> hey
[08:00] <kirkland> howdy
[08:02] <slangasek> bdmurray: ogasawara: there?
[08:03] <kirkland> slangasek: fwiw, ogasawara's ACTIVITY report says she's on holiday starting June 13th ...
[08:04] <kirkland> slangasek: nevermind, it's the 12th today....
[08:04] <slangasek> zul indicated earlier today that he would be in, but he's not on IRC now; pedro sends his regrets; let's go ahead and get started and we can bring the others up to speed as needed afterwards
[08:05] <slangasek> kirkland: right :-)
[08:05] <slangasek> it was fairly short notice, so I'm not terribly put out if not everyone is able to make it
[08:05] <slangasek> anyway, on with the agenda
[08:06] <slangasek> - talking through any issues that should be critical for the point release but haven't been addressed
[08:06] <slangasek> #1) pulseaudio
[08:06] <seb128> was going to mention this one
[08:06] <seb128> gvfs smb issues are really annoying too
[08:07] <slangasek> TheMuso: can you give us a summary of where you think things are right now with pulseaudio?
[08:07] <seb128> at least for corporate use which we could expect from a lts version
[08:07] <pitti> also highly popular for home users
[08:07] <slangasek> yes, but that's #2, let's try to take these one at a time :)
[08:07] <TheMuso> Ok. I think the biggest issues that users are facing with pulse, is general sound card + pulseaudio interractivity issues, performance/buffering issues, and flash + pulse.
[08:08] <pitti> are the first two actually pulse issues, or fallout from our alsa userspace/kernel desync?
[08:08] <TheMuso> The first is hard to track down as I can't reproduce it locally, and some users who have tried 1.0.16 for alsa-lib from intrepid say that it helps them, and some say it doesn't. However in general I don't know what fixes need backporting to fix the issue for those wo find using alsa-lib 1.0.16 helps.
[08:09] <TheMuso> pitti: I am enclined to think that the first is certainly a fallout from our alsa-lib and kernel being out of sync.
[08:09] <seb128> is there a lot of changes between 1.0.15 and 1.0.16, would an update be an option?
[08:09] <pitti> well, if alsa-lib .16 is a stable microrelease with only bug fixes, and since our kernel already has .16, we should at least consider+test upgrading userspace to .16 too
[08:09] <TheMuso> The second, I'm not so sure of. I/Daniel have suggested users try 1.0.16 for stuttering issues, but nobody as replied. I'll have to poke again.
[08:09] <slangasek> TheMuso: how broadly reported is the first of those issues?  (Do you have a bug number?)
[08:10] <TheMuso> slangasek: Give me a minute.
[08:10] <TheMuso> bug 191027
[08:10] <TheMuso> Some users in that bug have stated that 1.0.16 of alsa-lib from intrepid helped.
[08:11] <TheMuso> seb128: There are a lot of changes, yes.
[08:11] <TheMuso> seb128: Symbols added/removed/renamed, mostly in the plugins I think, and interfaces depricated as they were depricated/removed in the kernel code.
[08:12] <persia> FWIW, as one of the users for whom the update didn't solve the Invalid Argument issue for some hardware, it also didn't show regressions on other hardware.
[08:12] <TheMuso> The third issue is an alsa-plugins/pulse issue in general, which can be partly solved by backporting code from 1.0.16 for lib/plugins.
[08:12] <slangasek> TheMuso: application-facing interfaces deprecated?
[08:12] <TheMuso> slangasek: No.
[08:12] <slangasek> TheMuso: do we ship any alsa plugins that aren't part of the alsa-lib distribution itself?
[08:13] <TheMuso> bug 221673 is one I have worked on.
[08:14] <pitti> TheMuso: that means our userspace alsa .15 is using ABIs in the kernel (.16) which don't exist any more?
[08:14] <TheMuso> slangasek: Not that I know of, I'd have to check what packages depend on libasound2.
[08:14]  * ogasawara waves
[08:14] <TheMuso> pitti: Yes.
[08:14] <pitti> TheMuso: *gulp*
[08:14] <TheMuso> And it seems that pulse is hitting some of those issues.
[08:15] <slangasek> TheMuso: so am I right in saying that it's your assessment that alsa-lib 1.0.16 will /probably/ fix all of the major issues that we should be trying to address for 8.04.1?
[08:15] <TheMuso> slangasek: Without being able to reproduce them myself, and without having enough feedback to confirm, I would say that it might, but wouldn't want to risk it myself.
[08:16] <TheMuso> All my sound hardware works here with no issues, worst luck.
[08:16] <seb128> I think we should consider the update, the current situation seems to be broken anyway
[08:16] <slangasek> TheMuso: you wouldn't want to risk the possibility of regressions with 1.0.16, or you just wouldn't want to bet on it fixing everyone's problems?
[08:16] <pitti> TheMuso: does that include the stuttering/latency issues? or do they still need increas of the frame size?
[08:16] <TheMuso> slangasek: I don't want to risk regressions.
[08:16] <slangasek> hmm=
[08:17] <asac> as far as i understood crimsun, we still have to take care that we run set-pulseaudio for default installs once they get the new alsa+flash
[08:17] <TheMuso> pitti: The problem with stuttering is it fixes it for some, and breaks it for others. I have a range of CPU speeds here and while it works fine on faster hardware, slower hardware gets adversly affected if the frame size/fragments etc is changed.
[08:17] <asac> e.g. to make alsa use the pulse plugin
[08:17] <asac> and we need flash 10 to be able to use it
[08:17] <TheMuso> asac: Not an option. KDE and XFCE don't use pulse.
[08:17] <TheMuso> asac: Oh you don't mean by default, sorry.
[08:17] <asac> then at least the flash-blocking other apps from playing sound is not going to work
[08:18] <TheMuso> slangasek: However, I think there are only added symbols for 1.0.16, and none removed/changed, for interfacing apps at least.
[08:18] <asac> TheMuso: well ... i ment that for systems with PA we should run it
[08:18] <slangasek> TheMuso: then I am inclined to defer to you on that point, given how quickly 8.04.1 is coming up on us.  What about other options - are there any isolated fixes that it might help us to backport?
[08:18] <seb128> debian and fc9 are using 1.0.16 for a while and it seems to work fine there
[08:18] <slangasek> TheMuso: well, backing up then - what regressions are you concerned about?
[08:18] <asac> otherwise one of the major broken use-cases will stay unfixed
[08:19] <TheMuso> slangasek: Applications breaking, plugins that we don't ship in alsa-plugins breaking. As it is, we would have to update -lib and -plugins together.
[08:19] <TheMuso> But I don't see what option we have at this stage, since feedback from users is mixed, and those of us close to development can't seem to reproduce the issues.
[08:19] <seb128> do we have extra plugins shipped not in alsa-plugins?
[08:19] <TheMuso> seb128: I don't know. It would require all packages that depend on libasound2 being checked./
[08:19] <asac> fta from mozillateam complained that intrepid alsa makes flash 10 + firefox crash: too still
[08:20] <asac> firefox: pcm_pulse.c:275: pulse_write: Assertion `pcm->last_size >= (size * pcm->frame_size)' failed.
[08:20] <asac> TheMuso: i poke him to open a bug
[08:20] <TheMuso> asac: Ok.
[08:20] <slangasek> is there someone who could help TheMuso with verifying whether we have any other plugins packages that we would have to worry about updating?
[08:21] <pitti> what does "other plugins packages" mean?
[08:21] <slangasek> TheMuso: if applications were to break, how would you expect that to manifest, based on what you've seen of the diff?
[08:21] <slangasek> pitti: packages depending on libasound2 which provide plugins for alsa itself, AIUI
[08:21] <TheMuso> slangasek: Symbols not being found/calls failing and behaving oddly.
[08:21] <TheMuso> slangasek: Correct re plugins.
[08:21] <pitti> ah, like libasound2-plugins (which we don't even install by default)
[08:22] <TheMuso> pitti: Right.
[08:22] <seb128> maybe jordi has some ideas about that
[08:22] <seb128> debian did the update some months ago
[08:23] <seb128> I can ping him on the topic
[08:23] <TheMuso> I know for a fact that the alsa devs do their best to preserve binary compatibility, so symbols have not been changed or removed, just added. THings between userspace and kernelspace are constantly changing however.
[08:23] <slangasek> seb128: ok, that sounds good - if the answer is that debian didn't explicitly deal with this issue, pitti, would you be able to help with identifying the packages we need to worry about?
[08:24] <pitti> slangasek: yes, I'll find all packages which provide alsa plugins
[08:24] <pitti> I think we can take it for granted that the entire hardy.1 team will test 0.16 packages on their hardware
[08:24] <TheMuso> I think apt-file could help here.
[08:25] <slangasek> TheMuso: you talked about "symbols added/removed/renamed" earlier - does that refer only to plugin interfaces?
[08:25] <pitti> TheMuso: I'll walk though the reverse build deps, I think
[08:25] <TheMuso> slangasek: I'll double check, but I am pretty sure that is the case.
[08:25] <TheMuso> i.e only plugin interfaces.
[08:26] <TheMuso> oh...
[08:26] <TheMuso> The sequencer instrument layer was removed. I think thats something to do with app interfacing, but not sure without further digging.
[08:26] <slangasek> TheMuso: so as far as applications breaking, we can fairly easily establish whether symbol lookups will be a problem (indeed, you seem to have already done this with your statement that symbols have not been changed or removed)
[08:27] <slangasek> TheMuso: as for calls failing, that's the general, not-easily-quantifiable risk associated with any library upgrade
[08:27] <TheMuso> slangasek: This is going from the alsa 1.0.16 changelog and vcs comments.
[08:28] <slangasek> TheMuso: right; given that we have 1.0.16 in intrepid, I can fairly easily inspect the binaries to confirm this
[08:28] <TheMuso> The more I read into this the more I feel less sure about it.
[08:28] <pitti> TheMuso: we only have some 30 reverse build depends, and http://packages.ubuntu.com/search?searchon=contents&keywords=libasound_module&mode=filename&suite=hardy&arch=any isn't that long either
[08:29] <TheMuso> pitti: RIght.
[08:29] <pitti> bluez-audio, bluetooth-alsa, that's it
[08:29] <pitti> and we need to rebuild ia32-libs afterwards
[08:29]  * TheMuso nods.
[08:29] <slangasek> TheMuso: my overall conclusion is that we really should pursue 1.0.16 as a possible SRU candidate; there is some information we still need to gather as part of that process, but that's not a huge problem...
[08:30] <slangasek> TheMuso: otherwise, what alternatives would you suggest?
[08:30] <TheMuso> slangasek: I agree.
[08:30] <slangasek> ok
[08:30] <pitti> can we test hardy 0.16 packages in a PPA first?
[08:30] <slangasek> TheMuso: please go ahead with preparing the SRU itself, so we can evaluate it as soon as all the information is in place
[08:30] <pitti> if the packaging changes are negligible, we can also backport the intrepid version
[08:30] <slangasek> preparing via SRU if appropriate
[08:31] <slangasek> let's move on from here though, there are other topics to touch yet
[08:31] <pitti> but if anything moved around in the packaging, we shuold rather update hardy's version to 0.16 upstream only and keep the packaging
[08:31] <TheMuso> pitti: Sure. I know that the intrepid alsa-lib builds fine on hardy.
[08:31] <slangasek> eh, s/SRU/PPA/, whatever :(
[08:31] <slangasek> :)
[08:31] <slangasek> so, moving on
[08:31] <TheMuso> I'll check for that sort of thing as well. I think the only change is patches that hardy's version currently has that have been dropped.
[08:31] <slangasek> gvfs/samba
[08:31] <slangasek> seb128: hi :)
[08:31]  * TheMuso will start digging tomorrow.
[08:31] <seb128> hey ;-)
[08:32] <seb128> so there is several issue there for sure
[08:32] <seb128> some seem to be due to libsmbclient
[08:32] <seb128> some others due to gvfs-smb
[08:33] <seb128> http://mail.gnome.org/archives/gvfs-list/2008-May/msg00005.html summarize those
[08:34] <slangasek> gvfs-smb is based on libsmbclient, though, I'm not sure what the distinction there is
[08:34] <slangasek> I mean, before gvfs-smb, we didn't have these problems with smb...
[08:34] <seb128> the main issues are bug #207072 which is that gvfs-smb gives to way to authentificate to browse shares
[08:34] <slangasek> yes
[08:34] <seb128> that's purely a gvfs-smb issue
[08:34] <seb128> the other one is http://bugzilla.gnome.org/show_bug.cgi?id=529277
[08:35] <slangasek> I think that's a much lower-priority issue though, and don't think we should be concerned about fixing that for .1
[08:35] <seb128> alex who is upstream for gvfs (and on holidays but he replied to the mail on the list) stated that this one is a libsmbclient issue
[08:35] <seb128> "This is really a libsmbclient problem. The stat of the root is just an
[08:35] <seb128> artificial way to trigger the mount operation. The reporter seems to
[08:35] <seb128> have some ideas how we could try to work around this.
[08:35] <seb128> "
[08:36] <seb128> the lack of testcases or way to easily set up a configuration that triggers those mounts issues doesn't make the thing easy to work on
[08:36] <seb128>  
[08:36] <slangasek> mm
[08:36] <seb128> what issues would you consider that should be fixed in 8.04.1?
[08:36] <seb128> I would say that the "fail to mount" bugs are the main problem reported
[08:37] <seb128> because it means users can't access those shares at all
[08:37] <slangasek> the ADS authentication issue is a big one, as is bug #209520 (it appears)
[08:38] <seb128> right, that's my opinion too
[08:38] <seb128> the security=share bug is a mess though
[08:38] <seb128> too many random comments from people having different issues there
[08:38] <slangasek> configurations where you can mount the share but not access the root directory of that share, while not impossible, are certainly pathological from the POV of the current code
[08:38] <slangasek> yeah, I'm well aware :/
[08:39] <slangasek> I've blocked some time to go through those two bugs later this week to work on them from the samba side
[08:39] <slangasek> so if test cases are what upstream needs, I should be able to cook some
[08:39] <seb128> that would be great
[08:40] <slangasek> ok; any other issues that aren't getting enough attention for .1?
[08:40] <asac> well ... something related.
[08:40] <asac> i have some hard time getting crash feedback from -proposed users
[08:41] <asac> anyone working on getting dbgsym package for -proposed?
[08:41]  * slangasek wrinkles his nose.  Why are you having crashes in -proposed? :)
[08:41] <seb128> asac: we have dbgsym for proposed
[08:41] <asac> seb128: really? then its my fault :)
[08:42] <asac> or are they somewhere else?
[08:42] <seb128> $ apt-cache policy xulrunner-1.9-dbgsym
[08:42] <seb128> xulrunner-1.9-dbgsym:
[08:42] <seb128>   Installé : (aucun)
[08:42] <seb128>   Candidat : 1.9+nobinonly-0ubuntu0.8.04.1
[08:42] <seb128>  Table de version :
[08:42] <seb128>      1.9+nobinonly-0ubuntu0.8.04.1 0
[08:42] <seb128>         500 http://ddebs.ubuntu.com hardy-proposed/main Packages
[08:42] <seb128> asac: ^
[08:42] <seb128> asac: do you have an hardy-proposed ddeb source?
[08:42] <pitti> asac: in general we should have the .ddebs, yes; of course they are subject to the usual brittleness of the ddeb retriever
[08:42] <asac> slangasek: crashes are my daily breakfast :)
[08:43] <asac> seb128: ok thanks. I'll verify that the instructions we post have the proper ddebs lines.
[08:43] <asac> done on this topic i guess
[08:43] <seb128> asac: the wiki stock reply probably only mention the hardy ddeb sources and not the pocket ones
[08:43] <asac> yeah
[08:44] <slangasek> so I guess no one else has any bugs that they think are not way off the map for .1
[08:44] <slangasek> how about bugs that you guys need a hand with?
[08:44] <pitti> photos were one of my pet concern, but it has sufficiently be ironed out in -updates
[08:44] <slangasek> pitti: abiword 2.6 is still marked as "in progress", is that still on your radar anywhere?
[08:45] <pitti> oh, hm
[08:45] <pitti> it needs quite a few new build dependencies, which makes this somewhat tricky for -updates
[08:45] <pitti> since we'd need to promote them to main in hardy-updates (eek)
[08:45] <pitti> the package itself works quite well, no concern about that
[08:46] <seb128> having 2.6 in hardy-updates would be nice to not get upstream angry against ubuntu ;-)
[08:47] <pitti> and they aren't really optional
[08:47] <pitti> (the new build deps)
[08:48] <slangasek> seb128: well, I'm not keen on breaking the archive to keep them from being angry, either
[08:48] <seb128> right
[08:49] <pitti> in earlier times, -backports didn't care about components, but nowadays it does unfortunately
[08:49] <pitti> otherwise -backports would be a good compromise
[08:49] <slangasek> pitti: we should at least make a final decision on this from an SRU standpoint this week, deciding whether to mess with promotions or to send upstream our regrets
[08:50] <pitti> TBH I only considered this at all for SRU back then because they got so mad about us
[08:50] <slangasek> any others?  I have 53 milestoned bugs on https://bugs.launchpad.net/ubuntu/hardy/+bugs?field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.milestone%3Alist=1264 that are 'fix committed' or 'in progress' - anything that anyone wants a hand with, or are these mostly Not Yours? :-)
[08:50] <slangasek> (lots of kernel bugs in that list, of course)
[08:50]  * seb128 is looking
[08:52] <slangasek> seb128: I see bug #150187 assigned to you, still at 'triaged' - IIRC we don't have a solid patch for that yet, should we defer it until .2?
[08:53] <pitti> once we get CD images for testing, we can verify all the installer related fixes
[08:53] <pitti> so soon we should be able to do quite a few moves to -updates
[08:53] <seb128> slangasek: yes, I've been doing some poppler backporting for this one but no luck so far, I think it's not likely to me in 8.04.1
[08:54] <pitti> other than that, the things that stick out, verification-wise, are python2.5 and the -geode mess
[08:54] <seb128> we got also some angry users about DVD drives not recognizing discs in hardy but those lack details for now and pitti is looking at the issue
[08:54] <pitti> for the latter, I'll look on the patches that Q-FUNK sent and sponsor them
[08:54] <slangasek> seb128: bug #?
[08:54] <pitti> seb128: that's another messy bug :/
[08:55] <seb128> bug #220957
[08:55] <seb128> and bug #200337
[08:55] <slangasek> ok
[08:55] <slangasek> now, on the subject of CD testing
[08:56] <slangasek> http://cdimage.ubuntu.com/hardy/daily-live/current/ is up; as of today, they should be proper, CD-sized images with the right set of packages
[08:56] <slangasek> so anyone who's done with their other .1 work, it would be very helpful if you could smoke test these and also help with the verification of those installer fixes that apply to the live CD
[08:57] <slangasek> the alternate CDs are still not quite right in the head, but I'm working on those tonight still and will email the team when I have them sorted
[08:57] <evand> yay, thanks for taking care of that
[08:58] <sbeattie> that would be great. I was trying to verify a couple of installer bugs tonight, but ran into the alternative cd kernel problem
[08:58] <slangasek> ... and then, because of the OpenSSL issue, we are going to have to roll new images for pretty much everything released with 8.04, which means the iso testing matrix is again pretty substantial; so we're going to have to get testing resources lined up fairly soon here... just as soon as we get some images themselves
[08:59] <slangasek> and we're at time, and I have nothing left to cover; anyone else?
[09:00] <sbeattie> For SRU verifications, it would be great to make sure there are testcases in the descriptions
[09:00] <seb128> about updates, is that still worth to do some sru uploads now?
[09:00] <seb128> or should we stop until 8.04.1?
[09:00] <slangasek> sbeattie: I've noticed the biggest offenders there are the kernel team, you might want to take that up with them directly :)
[09:00] <sbeattie> heh
[09:01] <sbeattie> those and the generic package upgrades as well.
[09:01] <seb128> I guess we can upload and things which are not suitable can stay in hardy-proposed or unaccepted until 8.04.1?
[09:01] <ogasawara> sbeattie: I can help you with hassling them :)
[09:01] <slangasek> seb128: that's acceptable to me, if it's acceptable to pitti as well
[09:01] <asac> i might have been to busy to get the news, but which date are we now targetting for 8.04.1?
[09:02] <slangasek> seb128: of course, the major issues we identified tonight are exempt and will be approved within reason :)
[09:02] <pitti> slangasek: WFM
[09:02] <slangasek> asac: ah, good question
[09:02] <seb128> ;-)
[09:02] <slangasek> so originally, .1 was scheduled for the first week in July; then the prelim intrepid schedule came out which had alpha 2 releasing the same week
[09:03] <slangasek> Keybuk tentatively pushed .1 back to the second week in July as a result
[09:03] <pitti> hm, then we'll have the sprint
[09:03] <slangasek> but, given the current status of intrepid, I'm thinking it would be better to put .1 back on the first week and do the alpha the second week
[09:04] <slangasek> so anything else that we want to get in those images needs to be in the archive by around Monday of next week in order to keep that timeline
[09:04] <asac> ok that information is good enough for me to get the idea. thanks
[09:05] <seb128> july 7 to 12 is GUADEC in case that's revelant to this discussion
[09:05] <seb128> (ie some people will be away for the conference)
[09:05] <asac> yeah, lets release and get on holiday :)
[09:06] <slangasek> well, the week of the release should consist entirely of release engineering and QA, if a developer conference is interfering with that then we have problems :-)
[09:06] <slangasek> so, anything else?
[09:06] <slangasek> going, going...
[09:07] <slangasek> adjourned
[09:07] <slangasek> thanks, all :)
[09:07] <asac> cheers
[09:07] <seb128> thanks slangasek
[09:07] <sbeattie> thanks
[09:07] <TheMuso> Thanks.
[09:07] <pitti> thanks
[09:07] <evand> thanks
[09:07] <kirkland> thanks!
[09:07] <seb128> slangasek: btw reading the meeting summary sent this morning, those python-gnome-extras and evolution-exchange installability issues should already be fixed no?
[09:08] <seb128> slangasek: I gave a build retry yesterday to gnome-python-extras after fixing other issue and that worked and evolution-exchange built too after fixing the gtkhtml dependencies bug
[09:08] <slangasek> seb128: --> #-devel
[09:08] <seb128> right
[13:47] <pitti> hi
[13:47] <\sh> mahlzeit .)
[13:53]  * mvo waves
[13:54]  * tedg waves back
[13:59] <seb128> hey
[13:59] <pedro_> hello!
[14:00] <seb128> Keybuk: hey ;-)
[14:01] <Keybuk> good afternoon
[14:02] <pitti> hello Chief Engineer Mr. Scott
[14:02] <Keybuk> Chief Engineer? :p
[14:02] <pitti> (original Star Trek)
[14:03] <Keybuk> ahh
[14:03] <kwwii> you are supposed to say something in klingon to impress him
[14:03] <pitti> nuQneH?
[14:03] <Keybuk> tlInghan Qol ji'jatl
[14:04] <kwwii> hehe
[14:04] <Keybuk> anyway, meeting time
[14:04] <Keybuk> I didn't see any agenda items today, does anyone have anything they'd like to discuss?
[14:05] <pitti> originally I had to (gdm guest login), but I cleared it with our Gnominator already; it does mean that the spec still didn't get finished yet, though
[14:06] <pitti> but I wondered about the priority of it
[14:06] <Keybuk> pitti: what was the outcome?
[14:06] <pitti> i. e. is it worth working with upstream gdm and find a common solution, at the expense of it taking longer
[14:06] <pitti> or do we want it in intrepid, and we go for a custom solution without involving gdm?
[14:07] <Keybuk> this is Mark's spec
[14:07] <pitti> Keybuk: new gdm has preliminary infrastructure for guest account; I asked upstream about their plans on the ML, and pointed out our ideas
[14:07] <seb128> I don't think the upstream solution is going to take that longer
[14:07] <pitti> I'll wait for some answers anyway before I decide and finish the spec
[14:07] <Keybuk> I think that it is very important for intrepid
[14:08] <seb128> as said fedora is working on a guest account thing to and they have some infrastructure bit in gdm already for that, so we just need to discuss what they plan exactly and work with upstream and getting that
[14:08] <pitti> Keybuk: ok; maybe the prio should be higher than "low" then?
[14:08] <Keybuk> yes
[14:08] <pitti> so I guess I'll start with the wrapper around gnome-session and create a couple of AppArmor rules to lock it down
[14:09] <Keybuk> ok, cool
[14:09] <Keybuk> how's everyone doing with spec writing?
[14:10] <pitti> 4 review, 1 to go (guest)
[14:11] <kwwii> mine are all done :p
[14:11] <tedg> Well, did you get my e-mail about NAP Apps?
[14:11] <seb128> 3 written, the photo review experience one to convert in upstream bugs still (lot of things listed there)
[14:11]  * mvo thinks his are ok
[14:11] <Keybuk> tedg: I did, I'm speaking to Jane right after this ;)
[14:11] <mvo> I can not set packagekit-intrepid to review myself because I do not own it though
[14:11] <Keybuk> mvo: I fixed that, you can set it again
[14:11] <tedg> Keybuk: :)
[14:12] <mvo> InrepidDesktopEffects and LTSUpgrades should be good too (also the later is less urgent :)
[14:13] <seb128> mvo: oh, intrepid is not going to be a lts? ;-)=
[14:14] <Keybuk> seb128: it might be ;)
[14:14] <Keybuk> (* note: lie)
[14:14] <seb128> lol
[14:14] <mvo> heh :)
[14:14] <mvo> thanks Keybuk
[14:15] <pitti> "Lots of Trouble Software"?
[14:16] <Keybuk> "Let's Troll Seb"
[14:17] <Keybuk> once your specs are ready for review, and proposed for intrepid, and at review
[14:17] <Keybuk> please nag me
[14:17] <Keybuk> and I'll review them
[14:17]  * pitti nags Keybuk
[14:17]  * seb128 nags Keybuk
[14:17] <tedg> ITEITMFT: It's too early in the morning for this
[14:17] <Keybuk> not right _now_
[14:17] <Keybuk> when I'm less in London
[14:17]  * Hobbsee nags Keybuk anyway, although she has no specs.
[14:17] <Keybuk> Hobbsee: would you like some? :p
[14:17] <Hobbsee> Keybuk: well, you did ask :P
[14:18] <Hobbsee> Keybuk: oh, i don't know.  maybe, depending on what htey are :P
[14:18]  * seb128 gives the photo experience review to Hobbsee
[14:18] <kwwii> Hobbsee: it is my job to make Keybuk's life hard :p
[14:18] <seb128> Hobbsee: that's just a zillion f-spot bugs to file upstream and to fix then
[14:18] <Hobbsee> kwwii: only yours?
[14:19] <kwwii> Hobbsee: I am good at what I do ;-)
[14:19] <Hobbsee> seb128: enotpublic?
[14:19] <seb128> Hobbsee: the notes are on gobby.ubuntu.com
[14:19] <seb128> Hobbsee: that's a list of issues noted during the review
[14:20] <seb128> Hobbsee: that's to be converted in a list of bugs ;-)
[14:20] <Keybuk> ok, let's keep this one short then
[14:20] <Keybuk> any other business?
[14:20] <Hobbsee> oh, there it is
[14:22] <pitti> if anyone happens to have an hour when he doesn't feel like using his brain a lot, please help testing the 8.04.1 test CDs
[14:23] <lukehasnoname> any formal process to that?
[14:23] <lukehasnoname> Like a QA test?
[14:24] <pitti> lukehasnoname: for now, primarily a smoke test
[14:24] <pitti> it's definitively not the final image yet
[14:24] <pitti> just check if all images install at all
[14:24] <lukehasnoname> aka try it and report SNAFUs
[14:24] <pitti> (all packages are in place, installable, right kernel, that)
[14:25] <mvo> pitti: on the usual place on cdimage.ubuntu.com?
[14:26] <pitti> http://cdimage.ubuntu.com/hardy/
[14:26] <Hobbsee> pitti: how long do you have ot test them?
[14:27] <Hobbsee> seb128: now, you might get lucky, and i might end up helping out with that.  not for a copule of weeks, though
[14:27] <pitti> we'll build new ones in a week or two, I'd expect
[14:27]  * mvo runs rsync
[14:27] <Hobbsee> shucks.  it's the 12th of june.  last i checked, it was the second of june.
[14:28]  * lukehasnoname wishes my laptop had a VM capable CPU
[14:28] <Hobbsee> should have done an rsync before the 7th.
[14:28] <Hobbsee> lukehasnoname: ...it doesn't?
[14:28]  * seb128 hugs Hobbsee
[14:28] <pitti> ok, thanks everyone
[14:28]  * Hobbsee hugs seb128
[14:28] <lukehasnoname> T5550, I got "op not permitted" when modprobing kvm-intel
[14:29] <lukehasnoname> when sudoing
[14:29] <mvo> lukehasnoname: sounds like it might be disabled in the bios
[14:29] <lukehasnoname> unless I was just reading something wrong
[14:29] <lukehasnoname> I'll have to check when I get home
[14:29] <lukehasnoname> in 13 hours
[14:29] <mvo> lukehasnoname: for some reason a lot of models have it disabled in the bios
[14:30] <Hobbsee> lukehasnoname: you don't have to use kvm.  you can use virtualbox and such.
[14:31] <lukehasnoname> I know... but I'd like to use KVM
[14:31] <lukehasnoname> I'm trying to learn virtualization setup and admin using KVM in Ubuntu
[23:30] <udienz-> @schedule Jakarta