[02:28] hey guys [02:28] anybody here? [02:42] * ajmitch thinks he may have been in the wrong place if he was seeking quick answers or support [03:33] bryce_: is alberto alberto milone? [03:35] calc: Alberto Milone is tseliot on IRC [03:35] ok [03:59] calc: yes [06:54] Good morning [06:56] mornin'! (well, will be in an hour or so for me.) [06:57] hey, so I took a stab at a TODO item: https://bugs.launchpad.net/ubuntu/+source/epiphany-browser/+bug/332253 ... attached a script that I think will fix the problem if packaged, but I'm not sure what to do next (or if I should have even changed the "assigned to" field) [06:57] Launchpad bug 332253 in epiphany-browser "Epiphany doesn't mention Ubuntu in user agent string" [Wishlist,In progress] [06:57] thanks ubottu ;) [07:24] morning mpontillo pitti [07:25] hey didrocks [07:28] pitti: I was wondering about a patch in gnome-volume-manager [07:28] debian/gnome-volume-manager.links: Add gnome-volume-manager-gthumb.sh symlink to /usr/share/gnome-volume-manager/, where it had been shipped in old Ubuntu releases. Since this cannot be changed on system upgrades, this needs to be kept indefinitely. [07:29] why providing still this symlink? [07:29] didrocks: it's pretty obsolete now, since g-v-m isn't being used for handling photos etc. any more [07:29] and we don't use it at all [07:29] yes, I know. Just want to understand the remark :) [07:29] didrocks: the problem was that the path got stored in the user's gconf db [07:30] which we can't change on upgrades [07:30] pitti: we can't use g2conf-tools to update it? [07:30] in some kind of postinst script? [07:30] gconf2-tools* [07:30] no, we mustn't touch /home in maintainer scripts [07:31] pitti: ok, thanks. I understand now :) [08:00] mornin' didrocks. really morning now ;) === BugMaN1 is now known as BugMaN [09:10] hey seb128. We have to get ready for GNOME 2.27.1, right? :) [09:10] seb128: bonjour! had a good weekend? [09:10] didrocks: you can, I'm still catching up on jaunty bugs and doing merges for my part today [09:11] pitti: hello, excellent thanks! you? [09:11] seb128: great, I will follow them :) [09:11] didrocks: I see no reason to hurry in broken versions so early in the cycle, almost nobody is running karmic yet anyway [09:11] ok seb128, I will not hurry too, so :) [09:11] seb128: it was great; we did the traditional camping/hiking on May 1, and I helped my parents in the garden (oh, my back!), and we did a barbecue party [09:11] didrocks: I prefer to get merges sorted first and bugs on shape and start with .2 or .3 for the updates [09:11] karmic! [09:12] but I agree that merges are first prio now [09:12] pitti: I did some gardening too ;-) [09:12] seb128: I still have few merges to do, so, ok. I put some priority on this [09:12] didrocks: gnome-python-extras for example? ;-) debian fixed your build issue [09:12] * pitti also waits for NEW and buildds to catch up, so that he can upload the new gnome devkit crack [09:12] seb128: well... I will do gnome-python-extras :p [09:12] ;-) [09:13] pitti: how busy are buildds still? [09:13] very [09:13] https://launchpad.net/builders/ [09:13] except lpia [09:16] thoses queues are quite crazy :) [09:24] didrocks: yeah, some thousand packages synced from debian [10:02] seb128: pitti: I have an email regarding how to make progress in the compiz bugflood. What mailing list do you guys recommend I send it to for feedback? How wide is the distribution of the desktop mailing list? [10:02] robert_ancell: I'd post to u-devel@, it's of general interest [10:03] robert_ancell: is that a call for bug triagers? [10:03] robert_ancell: you might want to Cc ubuntu-bugsquad [10:03] robert_ancell: otherwise ubuntu-devel sounds good [10:04] seb128: pitti: It's more of taking a divide and conquer approach to compiz and being ruthless to maximise our effort. I'll email both of you and see what you think [10:07] ok [10:07] I think that first we should autoclose all crash bugs which didn't get any activity since hardy or something [10:07] bugsquad might have code ready for that sort of things [10:08] bryce_ also has quite some scripts to add stock replies, needinfo bugs, etc [10:08] don't spend hours on every bug trying to understand it in any case [10:08] seb128: that's exactly what I'm trying to avoid :) [10:08] success in bug triage is to triage quickly issues which don't seem worth stopping [10:08] right, it should suffice to go through and decide which are the really bad ones which affect many people [10:08] ie set those low importance and switch to the next one [10:09] then you can mostly ignore =< low [10:09] I think we have to reduce the number of bugs though - just triaging them will still leave too many bugs visible that no-one will ever get back to looking at. They may as well be closed or merged [10:10] pitti: hmm. commented on xmlrpc-c MIR ... its not the same source as the cmake - e.g. it adds a new set of libs for xmlrpc server stuff [10:11] right [10:11] that's why I suggest agressive closing of bugs which have not changed since hardy [10:11] and perhaps stock reply for bugs which seem rather video driver issues [10:11] pitti: do we care and open a bug for splitting up the binary packages? [10:11] and perhaps reply for "we don't have the manpower to work on that, please open an upstream bug" [10:12] asac: it's already split, only the base packages are in main, rest is universe [10:12] pitti: hmm. let me check [10:12] seb128: but that's passing the problem on. I think there's value in acknowledging that there are a lot of issues like this instead of closing them which sends the message "not our problem" [10:12] pitti: i thought the server libs are in the base package [10:13] robert_ancell: they can stay open [10:13] pitti: yeah so the server libs and the abyss libs are in the base package [10:13] robert_ancell: our goal can't be to have zero bugs on the package, I think [10:13] libxmlrpc-c3 [10:13] that package [10:14] asac: that's in universe [10:14] we just have the -c3-core package in main [10:14] hello rodrigo_ [10:14] hi :) [10:15] pitti: But then you can't see the forest for the trees. There needs to be a balance between having enough bugs that fixing them is accessible (ideally by third parties) but not loosing all the information that hundreds of bugs gives [10:15] pitti: hmm. so someone did the split up. nice. good [10:15] robert_ancell: indeed, but then there's also priorities and assignees [10:15] a bug which is triaged/low/unassigned is basically "shelve" [10:15] and a "high/triaged/assigned" bugs is on somebody's work list [10:16] pitti: great. so riddell did the split after i talked to him on friday [10:16] right, he mentioned it in the MIR [10:17] nevermind then [10:17] asac: the new package isn't published yet, I just NEWed it [10:17] pitti: so, to follow that strategy on compiz. If we close the bugs that are "too hard" (e.g. video drivers) and triage everything else (probably to low priority) we will still have 400 bugs with vague descriptions that will just continue to grow. Anyone not familiar with compiz will not want to put any effort into it - it will just look too hard [10:18] robert_ancell: video driver bugs should be reassigned, not closed [10:18] robert_ancell: using priorities more could help there (and being really conservative about "high") [10:19] robert_ancell: maybe you can write a spider that checks all the compiz bugs for attached xorg.log that has stacks in them and then bulk assign those to the appropriate video driver... [10:20] bryce has such scripts like those [10:22] seb128, pitti: ok, I'll talk to bryce about scripts. Do [10:22] asking people to re-test with compiz off is probably also a good thing that could transfer some bugs to xorg... not that xorg has too few bugs but :) :) [10:22] robert_ancell: "description not good enough to understand the bug = needinfo + low priority if that doesn't seem a high importance issue" [10:23] and get some autoclosing going on for all needinfo which didn't get updated for 6 weeks or something [10:23] then you can get a bookmark listing only open bugs "ie confirmed triaged" [10:23] and sorted by importance [10:24] that should give you a reasonable list [10:24] that give the "NEW" bugs which are too triage [10:25] and somebody need to go over the needinfo every now and then to close or reopen according to the new comments [10:25] I just feel it might be hiding the issues rather than than us getting valuable information on how to improve the stability of compiz (and so reduce the number of incoming bugs) [10:25] I've cleaned a bit pidgin this way [10:25] seb128: ok, will look at pidgin for ideas [10:26] half of "old bugs" got submitter replying that jaunty was fixing the issue for them [10:26] there is not too much to look at, I've been going through bugs not touched recently asking to try on jaunty [10:26] I got quite a lot of "that has been fixed in recent versions" [10:26] seb128: particularly in the case of compiz the bugs are not reproducable anyway - they're just random crashes [10:27] I tend to close one time crashers with no recent duplicates [10:27] we can still reopen if somebody else runs into the issue again [10:27] we need to do some statistical work anyway [10:27] ie we could ignore all bugs which didn't get at least confirmed by 3 users [10:28] we can't spend hours on every issue which one user got once [10:28] we have to go for things annoying a lot of users or being important issues [10:29] and in the case of compiz we have hundreds of reports, and almost none of them having reproducable conditions or likely to be reproduced [10:29] anyway, I have to go. Thanks for the feedback [10:29] you're welcome [10:30] just set those low importance [10:30] and don't bother looking to low bugs [10:30] and get them raised if there is several duplicates [10:30] we can continue chatting about that tomorrow [10:31] seb128: yup, please email me some Karmic work/pointers for tomorrow as I'm not too sure what to do / what others are currently doing [10:32] robert_ancell: ok will do [11:12] Hello [11:14] lut crevette [11:14] salut seb128 [11:38] seb128: gconf merge uploaded; so you'll take rarian in exchange? [11:39] pitti: yes [11:39] splendid; 6 merges to go then.. === dpm_ is now known as dpm === eeejay is now known as eeejay_givingup [13:26] mvo: any reason you let bug #318268 on avahi? [13:26] Launchpad bug 318268 in avahi "package libavahi-glib1 0.6.23-2ubuntu2 failed to install/upgrade: subprocess dpkg-deb --control returned error exit status 2" [Undecided,New] https://launchpad.net/bugs/318268 [13:26] mvo: that doesn't seem to be an avahi issue ... [13:28] seb128: let me have a look [13:28] mvo: thanks [13:28] no reason [13:29] I reassigned to dpkg for now, this short read on buffer copy message needs some love [13:29] mvo: ok thanks [13:52] http://3x3cut10n3r.mybrute.com/ <-- have fun & good luck [13:53] did anyone else get dependency problems / broken package for compiz when upgrading to karmic? I need working compiz to test a -ati patch for karmic [13:54] this is the concrete problem I have on karmic --> http://pastebin.com/m4d9ee54a [14:00] mnemo: well. while auto synchs are on its easy< to have dependency problems temporarily [14:01] asac: the reason i want this patch into karmic is because I need some bake time there so I can request a SRU for jaunty [14:01] asac: how long will the auto syncers be on? [14:02] mnemo: till debian import freeze [14:02] mnemo: https://wiki.ubuntu.com/KarmicReleaseSchedule [14:03] aah thats quite long [14:03] mnemo: well. a) i dont know if your problem is something else ;) ... b) if its a temporary issue because of lots of updates going on, you might be able to upgrade in a few hours a few days or so [14:03] mnemo: how do you upgrade? [14:04] asac: i had this problem for two days now.. I upgraded by "sed -i s/jaunty/karmic/ sources.list" [14:04] mnemo: and then? [14:04] what command are you using? [14:04] sudo apt-get update followed by "sudo aptitude dist-upgrade" [14:04] try apt-get dist-upgrade [14:05] aptitude can be lame ;) [14:05] ok [14:05] but look carefully if things get removed you dont want go away ;) [14:06] are you on karmic with working compiz btw? if so, then I might have some config issue related to my upgrade [14:06] i havent upgraded yet. want to do some SRU stuff first [14:06] k [14:07] asac: so, is it possible to SRU without adding patch to karmic first? [14:07] my patch causes frequent -ati crashes, its merged upstream and fix has been confirmed by a handful of people [14:08] well. this early in cycle making the SRU and uploading to karmic without using karmic makes sense [14:09] aah ok [14:09] baking in karmic is not really useful because a) its not really stable and b) not many use karmic anyway [14:09] right [14:09] mnemo: anyway, its important that the same fix goes to karmic [14:09] we want to prevent that there are regressions because the patch was forgotten to add there [14:10] its already merged to upstream mesa so it will go in there for sure [14:11] mnemo: well. unless its things like gnome which release time based, you cannot be sure that the next upstream will be ready or in karmic imo [14:11] if bryce said he will do that then just -proposed should be ok [14:11] but talk to him i would say [14:11] he should be responsible to help you get this patch in ... or tjaalton [14:12] yea im just waiting for bryce to wake up basically :) [14:12] hehe [14:12] hello rickspencer3 [14:12] hey seb128 [14:12] mnemo: so i cant speak for bryce, but i would think that you shouldnt be required to upgrade to karmic at this point ;) [14:13] hey rickspencer3, good morning [14:13] hi rickspencer3 [14:13] good afternoon pitti, asac [14:13] how was the (long) weekend? [14:13] precious [14:13] awesome [14:13] even the weather was superb friday and sat [14:14] which is kind of a lottery thing here ;) [14:14] excellent there too [14:14] and next weekend is 3 days again ;-) [14:14] oh? [14:14] typical french ;) [14:14] sweet [14:14] seb128: Friday or Monday off? [14:15] friday [14:15] it's the end of second war day [14:15] mmm [14:16] rickspencer3: I will not be there for our weekly call and the meeting tomorrow btw [14:16] rickspencer3: travelling to london to join the dxteam sprint [14:16] seb128: ok [14:16] ok [14:42] ok, so I've a todolist for the team contributors, what are the preferences to track those? wiki, bugs, txt list stored in some bzr? === rickspencer3 is now known as rickspencer3-afk [14:52] howdy, since 8.10->9.04, gdm hangs, /var/log/auth fills with pam_nogin(gdm:auth): cannot determine username [14:52] suggestions? [14:53] ktenney: can you boot the 9.04 live CD? [14:55] haven't tried, don't have one. Should [14:55] I make one and get back? [14:55] well [14:55] ,try that, and if its boots... also try logging out from the live CD [14:56] if you log out, then you should see a gdm screen and you should be automatically logged in again [14:56] as user "ubuntu" [14:56] if gdm hangs on the live CD please open a bug using the terminal command "ubuntu-bug gdm" [14:56] and describe what you said about the with logs etc [14:57] mnemo: I'll be back, thanks === rickspencer3-afk is now known as rickspencer3 [15:27] morning all [15:40] rickspencer3: FYI, I updated my specs: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-symptom-based-bug-reporting and https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-automagic-python-build-system [15:40] pitti: sweet [15:40] rickspencer3: I didn't see any other which I'm drafting, but please let me know if I forgot one [15:40] I have a lot of work to do regarding those :( [15:41] rickspencer3: I dropped the webdav debug symbols from the apport one; it's a completely separate topic [15:41] and probably not feasible time-wise in karmic anyway [15:41] ok [15:41] rickspencer3: lot of work> wrt. scheduling? [15:41] every drafter should be responsible for his own summary etc., you shouldn't do those [15:41] I have content for many bps that I haven't put in yet [15:42] * pitti proposes desktop-karmic-double-daytime, to be able to cover everything [15:42] pitti: does automagic build system include an application template [15:42] ? [15:43] rickspencer3: it shouldn't, I think [15:43] it's outside of the scope of a build system [15:43] rickspencer3: also, I had a quick discussion with this about Seb [15:43] is it? [15:43] sorry, "about this with seb" [15:43] rickspencer3: templates should be in a layer on top of this, IMHO [15:43] I think we need to create the starting place for developers [15:44] right, so a seperate blueprint then [15:44] ? [15:44] rickspencer3: that would fit into something like your "quickie" [15:44] right, but quickie needs to assume that it will feed into the automagic build system [15:44] they go hand in hand [15:44] rickspencer3: the python build system is on the same level like cdbs or automake [15:44] I'll go ahead and create another blueprint for desktop-karmic-project-templates [15:45] it doesn't have an interface for dialogs, GTK GUI, or template creation [15:45] pitti: but there needs to a be unified interface for developers [15:45] rickspencer3: yes, absolutely [15:45] rickspencer3: and these templates should use that automatic build system [15:45] so that they can create the projects and publish them from the same set of commands [15:46] but I wouldn't like it to be one big project blob, since the build system has usages outside quicke, and we shouldn't restrict the templating system to python/that build system [15:46] ok [15:46] so there should be a quickie command that invokes it [15:46] but it should be loosely coupled [15:46] rickspencer3: quickie would write the minimal setup.py [15:47] you should also be able to go $quickie publish [15:47] and the build system is clever enough to "do what I mean" with just a very small setup.py [15:47] and it uses the automagic system [15:47] right [15:47] ok [15:47] then the other blueprint will be useful [15:47] rickspencer3: so, wrt. the discussion with seb128, he mentioned that something like this was discussed before [15:47] rickspencer3: the question was, AFAIR, which scope this project should have [15:48] rickspencer3: "big": build system, .debs, packaging, PPAs [15:48] rickspencer3: "small": run from source tree, no build system/packages/PPAs [15:48] what are your thoughts? [15:48] "small" would basically operate on a tarball, with the usual limitations you get from not having packages (no i18n, no package updates, no menu entries, etc.) [15:48] the discussion 6 months ago got people agreeing that it should be an easy way to run prototype [15:48] I think it should create a deb and/or a ppa [15:49] and the last time this was discussed it was the "small" one [15:49] ie just one click on a server, download, run [15:49] deb and ppa is high barrier to start [15:49] preferably a ppa [15:49] I think from the uses point of view, the system starts from creating a project from a template [15:49] and ends with publishing to a PPA [15:50] if ppa is too much for a single release, that's fine [15:50] well, when it's good enough to be properly package you can as well get it in ubuntu [15:50] what are you trying to solve? [15:50] make easy for people to get users trying their code quickly? [15:50] seb128: that's a deep question, and I have a deep answer [15:50] or having a robust way to distribute code? [15:50] we can provide solutions for both use cases [15:50] but essentially, discovering *how* to write an app on Ubuntu is next to impossible [15:50] we already have a pretty good way to distribute code ... ;-) [15:50] and then how to distribute it is insanely complicated [15:51] rickspencer3: and by using ppa you will not make it any simpler [15:51] seb128: making a PPA is far from simple [15:51] the previous discussion we had turned around the "you should just have to write some python code and be able to distribute it in one click" [15:51] right, that's why we were against using deb packaging or ppa when we discussed that [15:52] but if we define conventions for how to write your python code, then creating a PPA could be simple [15:52] you still have to deal with the packaging [15:52] creating a source package from standard-shape python project is doable [15:52] convention over configuration [15:53] PPA is a little more than one click, because you need to register an LP account etc. [15:53] and then users need to add a deb src etc [15:53] if you follow the conventions, than a program can be written that creates a PPA for you (given that you have an account) [15:53] we can script that as well, but it's not just one click (because of authentication etc.) [15:53] if you deviate from the conventions, that's fine, but you are on your own regarding distribution [15:53] the previous discussion was "go on some website, spot something you want try, click to download, double click to try" [15:53] seb128: that part should be apt:// URLs, no? [15:54] seb128: that's on the end user side [15:54] right? [15:54] yes [15:54] I'm talking about opportunistic developers as users [15:54] making that work involves some changes in apturl itself, automatic fetching of PPA GPG keys, etc. [15:54] on the writter side it was "write some python, upload in one click" [15:54] right [15:54] I think it comes down to what we expect from this [15:54] but it's "write some python code following some defined conventions, then upload easily" [15:54] if the limitations (no i18n, no menu entries, no automatic updates) are okay, then distributing tarballs and running from source would work [15:55] I've the feeling that the while packaging, ppa thing is over-engineered [15:55] it's just not how we do things in Ubuntu [15:55] well, that's why I asked what you want to do [15:55] there are two things that we answer: [15:55] make easy to distribute and run prototype [15:55] or distribute anything this way? [15:55] 1. How the heck do a write a program that runs on Ubuntu? (quickee-like system is the answer) [15:55] fetching the ppa gpg key sounds a bit scary [15:55] 2. How they heck do I get this to my users? [15:55] we opted for the first one saying that you can turn to real packaging when it's ready to be distributed [15:56] mvo_: really? [15:56] imo anyone who figures how to package, will figure that there are PPAs ;) [15:56] mvo_: (we discussed that some days ago already) [15:56] hmmm [15:56] this sounds like a good topic for a longer discussion [15:56] rickspencer3: i agree that improving documentation for developers is important [15:56] mvo_: do you know if there was some notes from the previous uds discussion? [15:57] pitti: well, its auto-adding repositories to apturl, something we decided against some time ago [15:57] we should provide the very best to ensure that developers always end up using ubuntu [15:57] rickspencer3: we already had a full room 2 hours discussion about that at previous uds [15:57] seb128: about the download and try thing? [15:57] mvo_: yes [15:57] rickspencer3: so, even in the event that it turns out to be the "small" one-click tarball solution, the distutils thing has been one of my pet peeves for a long time, so I'll probably work on it anyway (in my CFT) [15:57] mvo_: the one where desrt wrote the server and you were supposed to write the client [15:57] mvo_: no, I meant auto-fetching a PPA's gpg key once you added it [15:58] pitti: once you added it manually? [15:58] (or via software-properties?) [15:58] rickspencer3: I'm not really convince that we should make easier for people to distribute debs [15:58] seb128: I wrote bits of that :) [15:58] mvo_: shouldn't matter how it got added; once it's there, we should verify the signature [15:58] rickspencer3: we already have tons of those and difficulties to figure what is good or not [15:58] seb128: gritty, I think desrt even came up with something working even [15:58] mvo_: "auto-fetch and fail on non-match" -> much better than "always complain about missing key" [15:59] rickspencer3: I would keep deb as a way to distribute proper software and not random quick hacks [15:59] pitti: right, this discussion. yes, we can add this [15:59] otherwise that's the door open to lot of issues [15:59] seb128: well, .debs would make sure that you can integrate into the menu, can upgrade and uninstall cleanly [15:59] one other issue is that deb packaging will require sudo rights [15:59] pitti: I thought you said "apturl should be able to add PPAs automatically (with keys)" [15:59] and it's an open door to any abuse [15:59] where the small tarball solution is user land [16:00] an no risk for the system [16:00] mvo_: perhaps, somehow; but I'm not so sure about that [16:00] seb128: agreed [16:00] re rickspencer3 [16:00] heh [16:00] someone disconnected me? [16:01] :) [16:01] mvo_: btw, where is that apturl update? i haven't seen anything in proposed for it [16:01] too many informations? ;-) [16:01] I didn't realize I was being that controversial ;) [16:02] rickspencer3: to summarize my opinion I think debs should stay a way to distribute officially supported software, we should not encourage people to install random crap this way [16:02] rickspencer3: especially that deb are system components, ie the postinst can do anything to the install [16:02] seb128: what's wrong with PPA? [16:02] it seems to me that the single point of update is of strong value to users [16:03] too much informations makes difficult to figure where to find quality softwares [16:03] I think we should not mix proper software and quick hacks [16:03] it's already difficult enough to find a software in the current list we have [16:03] are PPAs "proper" or "quick" hacks? [16:03] proper [16:03] as said it depends what you want to distribute [16:03] dobey: I uploaded it to -proposed, the masters-of-the-sru queue will have to check and approve [16:04] dobey: uploaded Wed, 29 Apr 2009 [16:04] do you want a quick way for people to distribute new cool stuff they work on [16:04] ie prototypes [16:04] or do you want it a way to distribute any software? [16:04] rickspencer3: call sounds fine to me... i hit accept but not sure if it went through [16:04] mvo_: how does a mere mortal such as myself test it then? [16:04] calc: ack [16:05] seb128: if I wrote a pencil ordering app for my office, having a single point to update to would be most useful [16:05] I would say the tarball approch is safer (nothing require sudo, nothing running at the system level) and makes easier to try things without risk of polluting your install [16:05] but such a ppa shouldn't show up for general usage [16:05] dobey: it should appear in -proposed once approved, I think the current ubuntu-sru team (that does the review/approval) is just pitti and slangasek, not sure how often they review the queue [16:05] dobey: and of course there was a long weekend now [16:06] rickspencer3: right, if that's a proper application you recommend to our lambda users [16:06] which brings we back at what we want to distribute this way [16:06] mvo_: right. i was hoping to test it and verify that it fixes the bug for my use case :) [16:06] dobey: sure, I understand :) [16:07] seb128: we need a way for application developers to get their apps to their users [16:07] rickspencer3: the tarball thing was meant as a "here is the cool python thing I started on work on a week ago, it's not really useful yet but you can try it quickly and comment by clicking there" [16:07] pitti: care to approve the apturl sru then? :) [16:07] PPA seem good for this [16:08] mvo_: I spent 1.5 hours on SRU this morning, unfortunately I didn't completely empty the queue yet [16:08] rickspencer3: one thing I don't like about ppa is that deb are system components, ie how do you make sure the postinst don't format the disk or anything? [16:08] rickspencer3: who is going to review all those to make sure they don't do anything they should not be doing? [16:08] pitti: thanks, I know that its a hard task, especially so shortly after the release, no blame on you [16:08] seb128: well, how do you make sure that the tarball doesn't wipe your home dir? [16:09] seb128: right [16:09] pitti: we limit the access to some jail? [16:09] that will be a problem when the PPAs are generally discoverable [16:09]