=== kassetra [~kassetra@c-67-171-201-213.hsd1.or.comcast.net] has joined #ubuntu-meeting === lips [~lips@132-bem-14.acn.waw.pl] has joined #ubuntu-meeting === lips [~lips@132-bem-14.acn.waw.pl] has left #ubuntu-meeting ["Leaving"] === mgalvin [~mgalvin@cpe-69-205-46-35.nycap.res.rr.com] has joined #ubuntu-meeting === slomo [~slomo@p5487EE87.dip.t-dialin.net] has joined #ubuntu-meeting === robitaille [~daniel@d154-5-117-228.bchsia.telus.net] has joined #ubuntu-meeting === Simira [~Simira@194.24.252.250] has joined #ubuntu-meeting === jonathan_ [~jonathan@host81-158-251-218.range81-158.btcentralplus.com] has joined #ubuntu-meeting === mvo [~egon@ip181.135.1511I-CUD12K-01.ish.de] has joined #ubuntu-meeting === FLeiXiuS [~fleixius@pcp0010497935pcs.essex01.md.comcast.net] has joined #ubuntu-meeting === rob^ [~rob@rob-ubuntu.student.supporter.pdpc] has joined #ubuntu-meeting === FLeiXiuS [~fleixius@pcp0010497935pcs.essex01.md.comcast.net] has joined #ubuntu-meeting === jonathan_ [~jonathan@george.kkhotels.co.uk] has joined #ubuntu-meeting === jonathan_ [~jonathan@george.kkhotels.co.uk] has joined #ubuntu-meeting === robitaille [~daniel@d154-5-117-228.bchsia.telus.net] has joined #ubuntu-meeting === JanC [~janc@dD5764BEC.access.telenet.be] has joined #ubuntu-meeting === FLeiXiuS [~fleixius@pcp0010497935pcs.essex01.md.comcast.net] has joined #ubuntu-meeting === FLeiXiuS [~fleixius@pcp0010497935pcs.essex01.md.comcast.net] has joined #ubuntu-meeting === seb128 [~seb128@ANancy-151-1-31-215.w83-196.abo.wanadoo.fr] has joined #ubuntu-meeting === seb128 [~seb128@ANancy-151-1-31-215.w83-196.abo.wanadoo.fr] has left #ubuntu-meeting ["I] === JaneW [~JaneW@george.kkhotels.co.uk] has joined #ubuntu-meeting === JaneW [~JaneW@george.kkhotels.co.uk] has left #ubuntu-meeting ["Leaving"] === pitti [~pitti@195.227.105.180] has joined #ubuntu-meeting === infinity [~adconrad@loki.0c3.net] has joined #ubuntu-meeting === elmo [~james@83-216-141-215.jamest298.adsl.metronet.co.uk] has joined #ubuntu-meeting === Kinnison [~dsilvers@haddenham.pepperfish.net] has joined #ubuntu-meeting [11:49] Hi [11:51] I sent a mail to Scott, maybe he will read them in the next minutes [11:51] otherwise we just tell him we do the stuff in dpkg and he's supposed to implement it :) [11:52] I'll be here in 7 minutes. Just finishing up some dinner. [11:53] (And I don't think assigning work to Scott that he objects to will fly, so hopefully he shows up to defend his position) [11:53] where's the spec? === rob^ [~rob@rob-ubuntu.student.supporter.pdpc] has joined #ubuntu-meeting [11:53] pitti: have you talked to him before about this meeting? I can ring him, if it's important [11:53] http://udu.wiki.ubuntu.com/AuxiliaryBuildFiles [11:54] elmo: not in depth, I intended to talk together here [11:54] yeah, a phone ping would rock [11:54] meh, we have too many wikis [11:54] well, somebody suggested that existing changes files can be used for our purpose [11:55] Easily. katie just needs to know what to do with an uploaded package_version.lang file that's mentioned in a .changes. [11:56] no response on his landline, guess he's asleep/busy elsewhere [11:56] But how we get those files (a debhelper hack is lame, since not all packages have to use debhelper) is where Scott comes in. [11:56] But we can do this in two stages, only discussing the .changes/archive side for now, since elmo and Kinnison are the important parties for that. [11:56] fine for me [11:57] infinity: vast majority of packages use debhelper tho [11:57] I can discuss the hook place with Scott [11:57] infinity: and the advantage is it's transparent; having to add per-rules files hack is ugly [11:57] so far debhelper is a reasonably good solution IMHO [11:57] elmo : Yes, but it's still the incorrect place to be stripping files out, technically. [11:57] just Joey Hess doesn't like it [11:57] and mdz asked me to remove it from debhelper [11:57] either ubuntu carries a maintenance burden or it gets merged into debian as a ugly no-op [11:57] elmo : having it in dpkg-deb with a hook is more correct, in my mind. [11:57] pitti: did he say why? [11:58] either of them, in fact [11:58] elmo: not really, because it's "ugly" [11:58] joeyh certainly did [11:58] on debian-devel [11:58] he favors sbuild, I think [11:58] but hooking in sbuild is really hard, I guess [11:58] the whole "what if someone else calls something pkgtripstranlations" joke? [11:58] but it's somewhere in the enormous Ubuntu-is-evil thread of death [11:58] or something more substantial? [11:59] infinity: would it be possible at all to define hooks in sbuild [11:59] to be fair, it *is* a foul hack :-) [11:59] Kinnison: .. or in the launchpad infrastructure? [11:59] We need hooks after preparing debian/PACKAGE, but before actually building debs [11:59] hooking in sbuild is REALLY WRONG [11:59] or launchpad or whatever [11:59] bah phone, brb [11:59] elmo: that's my feeling, too === pitti hopes Scott is phoning :-) [12:00] I asked Scott about a dpkg hook, but he felt it was wrong, too [12:00] The higher level it is, the worse it is. [12:00] debhelper is a compromise because we can't/won't put it in dpkg-deb, where it (IMO) belongs. [12:01] infinity: the reverse conclusion would be that sbuild is the right place? [12:01] And as for the Debian case, one of my motivations for this is to make it elegant enough to use in Debian as well, should that time come. [12:01] infinity: does sbuild have control about the build process at all? [12:01] No. [12:01] It calls dpkg-buildpackage. [12:01] that's what I expected [12:02] And that shouldn't change. [12:02] Putting it into sbuild feels wrong to me [12:02] did we ever discuss doing DEB_BUILD_OPTIONS=striptranslations or similar? [12:02] that's sort of an established mechanism === seb128_ [~seb128@ANancy-151-1-37-108.w83-196.abo.wanadoo.fr] has joined #ubuntu-meeting [12:02] Hi seb128_ [12:02] hey :) [12:02] Kamion: sounds fine, too [12:03] Kamion: however, it should be a bit more generic [12:03] it would certainly be better than "if you happen to install this package, translations go bye-bye" which is the current situation [12:03] DEB_PREDEB=/usr/bin/pkgstriptranslations? [12:03] pitti: DEB_BUILD_OPTIONS is generic, you just allocate a variable for each. I don't like putting commands in there [12:03] DEB_POSTBUILD=... and so on? [12:03] er s/variable/name/ [12:04] hm, but D_B_O is only evaluated in debian/rules, not in dpkg, right? [12:04] yes [12:04] so wouldn't that still require a debhelper hack? [12:04] D_B_O is wrong, wrong. [12:04] dpkg-dev could inspect it [12:04] infinity: why? [12:04] dpkg-dev doesn't currently touch D_B_O [12:04] true [12:04] But, okay. I'm all for making it do so. [12:05] I suppose it ought to be a different name [12:05] I thought we were looking at the "evaluate it in debian/rules" option. === pitti still favors /etc/dpkg/predeb.d hooks [12:05] And, yeah, since debian/rules currently "owns" that variable, people could be unsetting it or doing other insane things to it. [12:05] So we can't count on it being sane. [12:05] But however that happens, I still see dpkg-deb as the correct place to do the actual stripping. [12:06] Whether with a config file, a variable, or whatever. [12:06] pitti: I still don't like the "install random package and build behaviour totally changes" thing - I'd rather have it be at least controlled by an environment variable so that you have to explicitly request it === doko [~doko___@dsl-084-059-084-138.arcor-ip.net] has joined #ubuntu-meeting [12:06] But, since the man who will argue vehemently against that isn't here, perhaps we should be talking about the archive. :) [12:06] and then put that into our buildd configuration [12:06] Kamion: you currently have to explicitly enable pkgstriptranslations in a conffile (default off) [12:06] elmo : DO you have any qualms about dealing with in-band uploads of foo.lang files in katie? [12:06] pitti: well, ok [12:06] Kinnison : And you replicating said functionality in soyuz? [12:06] ok, let's defer the hook discussion [12:07] http://udu.wiki.ubuntu.com/AuxiliaryBuildFiles still mentions a separete changes file [12:07] infinity: so we can put "not for the archive" files into the normal .changes? [12:07] infinity: I'd rather see the translations come in the same .changes file [12:07] pitti : Of course we can. [12:07] Kinnison : Yes, I meant in the same .changes. THe same as by-hand stuff is currently done. === Kinnison nods [12:08] nice [12:08] infinity: come in .changes, and katie does what with them ? [12:08] That's how I'd prefer to absorb it [12:08] Kinnison : SO a binary .changes would have foo.deb and foo.lang, or whatever. [12:08] and what form are they coming in? [12:08] infinity: is there already an interface for that? [12:08] is this a replacement for the existing .debs? [12:08] dpkg-*addfile or whatever? [12:08] oir a replacement for the hacktastic system lamont put in place to get the tarballs to rosetta/pitti/whatever? [12:08] elmo: the latter [12:08] elmo : These will get shunted off to somewhere where pitti's magical tools can use them to construct langpackgs. [12:08] langpacks, too. [12:08] elmo: yes, it's meant to be a replacement for lamont's hack [12:09] yeah, that's fine, I guess [12:09] lamont didn't want to replicate the hack for e. g. stripped debug symbols [12:09] elmo: what do you think about sth like aux.ubuntu.com [12:09] with an archive-like structure [12:09] which contains the translation tarballs, debug symbols, etc.? [12:09] pitti: I don't particularly want to publish anything except the debug symbols? [12:10] and that pretty much needs a proper archive, if they're in .deb format? [12:10] it would be more regular than people.u.c./~lamont [12:10] elmo: I didn't think about the format of the debug symbols yet [12:10] Yeah, translation tarballs shouldn't be public. [12:10] elmo: if debug symbols should come in deb format, that's fine for me; I don't want to install them, though [12:10] But they need a nice home that's not the current hack. [12:10] k [12:10] w/w, sorry [12:10] sure, the nice home can be langtarballs.internal tho [12:10] :) [12:10] elmo: ok, debug.ubuntu.com then? [12:11] elmo : Indeed. [12:11] pitti: we really want to use debs for this? [12:11] pitti: yes, that's fine, but I'd prefer something less hand-wavy for the debug stuff [12:11] seb128: I don't *want* debs [12:11] why not? [12:11] well, they are not installed [12:11] why not? [12:11] because the goal is to make automatic debug, not to say to people to install debug packages [12:11] you know about /usr/lib/debug/ or whatever it's called right? [12:11] that doesn't work fine [12:11] a crashed process downloads them from debug.u.c, and adds them to the current gdb session [12:11] not more [12:12] right [12:12] elmo: because half of the bug reply atm are "please install blabla-dbg an try to get the bug again" [12:12] seb128: why can't a post-morten analysis do apt-get install from debug.u.c ? [12:12] elmo: no root [12:12] elmo: this should be possible for any user [12:12] rather than inventing yet another transport, download, mirror, etc. system? [12:12] meh [12:12] well, this should be lightweight [12:12] lightweight? [12:13] have you seen the size of -dbg packages? :P [12:13] if the download fails, we forget about the symbols [12:13] it's just a "nice to have them if we can get them" [12:13] elmo: that's why we don't want -dbg debs :-) [12:13] pitti: dude, we can't just have them on one server, that's not scalable [12:13] lightweight in the protocol sense, I mean [12:13] pitti : detached symbols can be up to 10 times larger than the binary they're detached from. [12:13] ok [12:13] esp. if some core gnome component breaks and a million users all start requesting 10Mb -dbg packages at once [12:13] pitti : It's almost never going to be "lightweight". [12:13] pitti: you don't necessarily have to apt-get install debug .debs, you could unpack them and use LD_LIBRARY_PATH or whatever [12:14] elmo: as I said, it's not a problem to store them in debs [12:14] elmo: right, as Kamion says [12:14] elmo: deb is a reasonable container and would be compatible for mirrors, etc. [12:14] I'm not convinced the .debug.ubuntu.com system is going to be particularly ideal either mind you [12:15] but the target audience is not going to be configuring this first, so ... [12:15] kamion: that's not a good long term solution for archive.u.c either [12:15] no, but I don't think that we really need to mirror debug.u.c [12:15] eventually we'll have to do something better [12:15] pitti: dude, you're on crack [12:15] we can't plan a service and deliberately not consider how it's going to be mirrored [12:16] no, that's not what I said/meant [12:16] pitti : Software segfaults a lot. This service will get hammered, no matter how much we'd prefer to think it won't. [12:16] with a normal deb-like archive structure it *can* be mirrored, right? [12:16] not when that service involves huge files that are very likely to be concurrently requested by a LOT of users [12:16] ok [12:16] elmo: so an archive-like debug.u.c with debs as containers and Packages.gz files would be the right thing? [12:16] I don't think that's a lot of users [12:17] seb128: so when the panel gets a segfault bug ... ? [12:18] you know how many warty + hoary CDs we've shipped right? :-P [12:18] elmo: I read upstream bug, even on major crasher there is like 5 dups/day or something like that [12:18] 3? [12:18] most of people don't use bug-buddy or whatever [12:18] seb128: that's the people who report bugs [12:18] they just restart the app [12:18] seb128: I thought the plan for this was to be entirely automatic? [12:18] no need to get the symboles if you don't send a bug [12:18] at worst a user has to click ok type thing? [12:18] Yeah. [12:18] you can't do that without asking user ... [12:18] elmo: well, the user still have to confirm that the report is sent, for privacy reasons [12:19] that's like bug-buddy [12:19] It'd be like bug-buddy, or the Microsoft SEGV-hunter thingee. [12:19] we could ship a debug dvd together with the install cd :-/ [12:19] Fully automating something that could involve dumps of sensitive bits of userspace memory isn't nice. [12:19] (Or kernel memory, if it's a really GOOD bug!) [12:20] yeah, we have a dialog (also for entering additional comments) [12:21] elmo: so an archive-like debug.u.c with debs as containers and Packages.gz files would be the right thing? [12:21] ok, look, here's my perspective: if this is significantly easier than reporting a bug in bugzilla -> a lot of people are going to potentially use it -> if a lot (and remember if we have millions of users, even 10% or 5% is A LOT for one apache instance), we have to plan for this to be scalable [12:21] ^ fine for everybody? [12:21] we already have the deb + archive system, so if we don't want to use that, I'd like to see compelling reasons NOT to use it [12:22] How do you decide what goes in which archive? [12:22] is a build going to produce two .changes files? [12:22] that was my initial idea, but infinity has a better one obviously [12:23] infinity? [12:23] I do? :) [12:23] Kinnison: no [12:23] Kinnison: plan is to (ab)use the section/type field [12:23] in the same way as d-i stuff does for 'byhand' [12:23] Can katie be taught to bounce certain types of files to a different archive? (much as by-hand stuff does whacky things) [12:23] (or 'raw-installer' these days) [12:23] elmo: to put stuff into a different archive?! [12:23] There. What elmo said. [12:24] Kinnison: sure? [12:24] elmo: *groan* [12:24] Note that it's only a different archive froma publishing perspective. [12:24] that would also work for translation tarballs? [12:24] In other ways (like version tracking), it's the same archive. [12:24] infinity: Joy of Joys [12:24] pitti: translation tarballs, just go somewhere internal [12:24] ie: You want foo.deb foo_debug.deb and foo_lang.tgz to match. [12:24] this is going to make launchpad *incredibly* more complex [12:24] they don't need an archive, and they're going on a public server like debug.u.c [12:24] yay [12:25] pitti : Yeah, langpacks are easier than the debug stuff, really. They can be thrown just about anywhere with very little thought. [12:25] elmo: right, but still katie has to handle these files, so that works? [12:25] pitti : Bringing up the debug stuff made this conversation much nastier. :) [12:25] pitti: yes [12:25] Kinnison: don't you need separate published views of the one archive anyway, in order to track archive.u.c versus ports.u.c? === Kinnison was expecting langpacks to simply be fed to rosetta [12:25] great [12:25] Kinnison: we need a staging area [12:25] Kinnison: Rosetta imports once a day, and right now I need the tarballs, too [12:26] Kamion: ports.u.c ? [12:26] s/imports/will import/ [12:26] Kinnison: contains hppa, ia64, sparc binaries [12:26] pitti: the plan was for rosetta to import when it becomes available [12:26] Kinnison: only amd64/i386/powerpc/source are visible on archive.u.c [12:26] infinity: well, we have to make it generic enough to also support debug symbols :-) that's why we have that discussion in the first place [12:27] Kinnison: well, fine for me [12:27] Kamion: Surely that's the job of something to split up the published stuff afterwards [12:27] Kinnison : I see no reason why soyuz couldn't feed things directly to rosetta when the time comes. But katie needs a facility to throw them somewhere else for now, so we need that too. :) [12:27] infinity: I see [12:27] Kinnison: well, ok, it happens to be implemented by mirroring from a complete published archive on jackass at the moment [12:28] pitti : I don't necessarily see how the two relate much, except that in both cases we're uploading "random crap to the archive"... But we already do that (byhand tgzs, udebs, etc) [12:28] udebs aren't really all that random nowadays; byhand tgzs, sure [12:28] Kamion: only because I'm not meant to be doing any serious work on katie that'd be better done in launchpad .. [12:28] the current implementation is a hideous hack, and launchpad really shouldn't rely on it long term [12:29] (ports.u.c I mean) [12:29] Yay for hideous hacks. [12:30] elmo : How much effort will it take to get langpacks accepted by katie in a .changes?... That seems a viable first step. [12:30] elmo : Then put them somewhere that isn't lamont's ~ ... :) [12:30] so since we don't want to handle translation tarballs and debug symbols uniformly, that also puts an end to the "dpkg-addauxfile" idea? [12:31] pitti : dpkg-distaddfile hardly needs to be reinvented. [12:31] infinity: erm, I thougt that adds a file to a deb, not to a changes? [12:31] pitti: nope [12:31] infinity: not too much, couple of days to do it + test [12:32] elmo : Sweet. [12:32] but this is a really bad time for me [12:32] elmo : Isn't any time a bad time? :) [12:32] I'm moving sometime between now and debconf, and then there's well debconf [12:32] as in, moving 200 miles [12:32] elmo : Would it make it easier/harder if we had a specific file type for them (like .lang), or does it not matter one iota, so long as we abuse section stuff violently? [12:32] mmm. firealarm. bbiab [12:33] infinity: ah, cool. So pkgstrip{translations,debug} should just call dpkg-distaddfile for the tarball/debug deb and that will DTRT? [12:33] elmo : Timing's not terribly important. We can talk about rolling this out post-Debconf. [12:33] pitti : That would do 'er, yeah. [12:33] pitti : Once elmo and you argue and decide on the right section/priority for these to make katie happy, the rest is simple. [12:34] pitti : And when we roll it out, I can remove one more hideous hack from the buildds. [12:34] infinity: but translation tarballs don't have a debian control directory, and thus no section... [12:34] pitti : man dpkg-distaddfile. [12:34] pitti : It takes section and prio on the command line. [12:34] ah, cool. sorry [12:35] yeah, that sounds indeed nice [12:35] (It really just writes to debian/files, which you could do by hand, but using higher level tools always feels less dirty...) [12:36] Then genchanges reads debian/files and debian/changelog to construct the .changes. [12:36] And now I'll stop giving dpkg-dev lessons. [12:36] thanks anyway :-) [12:37] cool :) [12:37] ok, so the plan would be [12:37] 1) negotiate appropriate section/prio [12:37] (And, possibly, filetype, if that makes life easier for katie) [12:37] 2) put the tarballs/debug debs into a separate place in katie [12:38] 3) change pkgstriptranslations to use dpkg-distaddfile [12:38] 4) remove the current sbuild hack [12:38] ? [12:38] Pretty much, yup. [12:38] 5) Profit [12:38] pitti: so we have decided than debug use deb format? [12:38] 6) conquer the world [12:38] 7) beer [12:38] seb128: yes [12:38] I like 7. [12:38] I have some in the fridge. [12:38] Should we call this meeting more or less adjourned? [12:38] pitti: 7) is a sort of 5) :p [12:39] for my part, yes [12:39] I can follow up with elmo about the katie bits post-debconf. [12:39] I'll talk to scott about the hook thing [12:39] great [12:39] And when katie's ready, I'll ping pitti about changing pkgstrip [12:39] pitti: hum ... how do get these deb installed? [12:39] infinity: can you ping me after 1) and 2) are done? [12:39] hehe, thanks [12:39] And yeah, talking about moving the hack from debhelper to dpkg-dev can happy out of band from the other bits. [12:39] seb128: we extract them in /tmp [12:39] s/happy/happen/ === infinity stares at his fingers. [12:40] pitti: ugly, but why not [12:40] seb128: they are just the container [12:40] seb128 : unpack in /tmp, use LD_PRELOAD, profit. [12:40] pitti: and that allow to apt-get them too which is bonus [12:40] seb128: I think using the mirror infrastructure is sane [12:40] infinity: not LD_PRELOAD [12:40] yep, I agree [12:40] LD_LIBRARY_PATH [12:40] infinity: just tell gdb to use the symbols in that file [12:40] Err, yeah. [12:40] My LD_'s got confused. [12:40] Gimme a break, I just typed "happy" when I meant "happen". [12:40] I'm clearly not all here. :) [12:40] pitti: dh_strip does that magic, no? [12:41] would "apt-get download" be handy for that? [12:41] gdb) help add-symbol-file [12:41] mvo: what is "download" ? [12:41] mvo! [12:41] seb128: for now, yes [12:41] mvo : I wanted to yell at you about something in apt. [12:41] seb128: maybe later in a dpkg hook, but for now dh_strip has to do [12:41] it would just download a deb into the current dir [12:41] pitti: k [12:42] mvo: that would rock. definitively more sophisticated than calling urllib.urlretrieve... === mvo runs from infinity [12:42] mvo: would be nice [12:42] mvo : Why does apt insist on reading the default config file BEFORE taking commang line args (specifically '-o Dir=foo') into account? [12:42] mvo: I've already asked, but any plan to make synaptic handling deb files ... ? :) [12:42] mvo : THat just seems so hideously broken, since you then end up with two overlapping configs. [12:42] mvo: well, there already is apt-get install --download-only [12:43] infinity: historical reasons probably *cough* [12:43] don't block on me for the section/type [12:43] mvo: but it doesn't do exactly what we want, but the code can be stolen from that I guess [12:43] I hate naming stuff, someone else decide and just tell me [12:43] pitti: that will download into /var/cache/apt [12:43] mvo: right, that's what I meant [12:43] infinity: is there a bug open for it yet= [12:43] elmo : Will a different file type help, or will _lang.tgz be fine? [12:43] s/=/?/ [12:43] mvo : Not sure. I just ran into it recently, and I'm a notoriously lazy bug reporter. [12:43] elmo: would priority "aux" do? and then decide by section debug/translation? [12:44] infinity: a decided scheme would be helpful for sanity checking purposes, but other than that I don't care [12:44] pitti: it needs to be a separate section for each type of aux [12:44] aux-lang [12:44] aux-debug [12:44] whatever [12:45] priority: aux -> not for the archive [12:45] section: translation -> internal [12:45] Can I please ask someone who know what "odd" things ubuntu has archive-wise to compile a list of them all and email it to me? [12:45] section: debug -> debug.u.c. [12:45] ? [12:46] pitti: priority is irrelevant afa katie is concerned, you can have priority: bananas for all I care [12:46] you don't want normal section names that might be confused with sections [12:47] like real sections [12:47] elmo: just to avoid name overlaps (e. g. we already have an "optional"-priority translation) [12:47] so, I suggest someprefix-translation [12:47] so, I suggest someprefix-debug [12:47] ok === FLeiXiuS [~fleixius@pcp0010487351pcs.essex01.md.comcast.net] has joined #ubuntu-meeting [12:47] shrug, I suppose there's no compatability constraints, we could key of the priority if you want [12:48] hadn't we sort of settled on raw-* for general stuff-that's-not-debs? [12:48] well, stuff-that's-not-debs-for-the-main-archive [12:48] yeah. raw-translation might make sense [12:48] ok [12:48] raw-debug seems a bit strange, but either works [12:48] and raw-debug? [12:48] raw-lang? [12:48] as I said, I hate naming :/ === infinity hates long names. [12:48] infinity: so just make it filter on section raw-lang and raw-debug for now [12:48] I'm so old skool UNIX. [12:48] r-l! [12:49] ok, raw-dbg [12:49] r-d! [12:49] n [12:49] :-) [12:49] y a t s [12:49] Feh. [12:49] anyway, are we wrapped up here? I need to go to Angel [12:49] We're wrapped. [12:49] I think so, yes [12:49] thanks for your time, guys [12:49] next meeting: pizza [12:49] Beer, yo. [12:50] not for lunch [12:50] I wrap that stuff up in the wiki === ajmitch_ [~ajmitch@port164-167.ubs.maxnet.co.nz] has joined #ubuntu-meeting [12:52] thanks pitti, thanks everybody [12:52] lunch time :) === rob^ [~rob@rob-ubuntu.student.supporter.pdpc] has joined #ubuntu-meeting === infinity [~adconrad@loki.0c3.net] has left #ubuntu-meeting [] === Kinnison [~dsilvers@haddenham.pepperfish.net] has left #ubuntu-meeting [] === FLeiXiuS [~fleixius@pcp0010487351pcs.essex01.md.comcast.net] has joined #ubuntu-meeting === ..[topic/#ubuntu-meeting:Seveas] : Calendar -- https://wiki.ubuntu.com/Calendar || Logs -- http://people.ubuntu.com/~fabbione/irclogs || Tue 5 July 22:00 UTC Community Council -- http://wiki.ubuntu.com/CommunityCouncilAgenda || Tue 12 July 22:00 UTC: Tech Board -- https://wiki.ubuntu.com/TechnicalBoardAgenda || Thu 14 July 22:00 UTC Documentation Team -- https://wiki.ubuntu.com/DocteamMeetingAgenda || This is NOT #ubuntu, or #ubuntu-devel === rob^ [~rob@rob-ubuntu.student.supporter.pdpc] has joined #ubuntu-meeting === pitti [~pitti@195.227.105.180] has left #ubuntu-meeting ["Have] === rob^ [~rob@rob-ubuntu.student.supporter.pdpc] has joined #ubuntu-meeting === elmo [~james@83-216-141-215.jamest298.adsl.metronet.co.uk] has left #ubuntu-meeting [] === mgalvin [~mgalvin@host-66-202-95-170.spr.choiceone.net] has joined #ubuntu-meeting === seb128 [~seb128@ANancy-151-1-37-108.w83-196.abo.wanadoo.fr] has left #ubuntu-meeting ["I] === FLeiXiuS [~fleixius@pcp0010487351pcs.essex01.md.comcast.net] has joined #ubuntu-meeting === highvoltage [~jonathan@george.kkhotels.co.uk] has joined #ubuntu-meeting === mvo [~egon@ip181.135.1511I-CUD12K-01.ish.de] has joined #ubuntu-meeting === mvo [~egon@ip181.135.1511I-CUD12K-01.ish.de] has joined #ubuntu-meeting === smurfix [~smurf@run.smurf.noris.de] has joined #ubuntu-meeting === robitaille [~daniel@d154-5-117-228.bchsia.telus.net] has joined #ubuntu-meeting === mvo [~egon@ip181.135.1511I-CUD12K-01.ish.de] has joined #ubuntu-meeting === FLeiXiuS [~fleixius@pcp0010487351pcs.essex01.md.comcast.net] has joined #ubuntu-meeting === JanC [~janc@dD5764BEC.access.telenet.be] has joined #ubuntu-meeting === mvo [~egon@ip181.135.1511I-CUD12K-01.ish.de] has joined #ubuntu-meeting === JanC [~janc@dD5764BEC.access.telenet.be] has joined #ubuntu-meeting === dato [~adeodato@dato.developer.debian] has joined #ubuntu-meeting === dato_ [~adeodato@84-120-66-144.onocable.ono.com] has joined #ubuntu-meeting === ajmitch [~ajmitch@port161-243.ubs.maxnet.co.nz] has joined #ubuntu-meeting