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