=== 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 | ||
Kinnison | Hi | 11:49 |
---|---|---|
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:51 |
infinity | I'll be here in 7 minutes. Just finishing up some dinner. | 11:52 |
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 |
=== rob^ [~rob@rob-ubuntu.student.supporter.pdpc] has joined #ubuntu-meeting | ||
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:53 |
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:54 |
infinity | Easily. katie just needs to know what to do with an uploaded package_version.lang file that's mentioned in a .changes. | 11:55 |
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:56 |
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:57 |
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:58 |
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 | 11:59 |
=== pitti hopes Scott is phoning :-) | ||
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:00 |
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:01 |
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 |
=== seb128_ [~seb128@ANancy-151-1-37-108.w83-196.abo.wanadoo.fr] has joined #ubuntu-meeting | ||
pitti | Hi seb128_ | 12:02 |
seb128_ | hey :) | 12:02 |
pitti | Kamion: sounds fine, too | 12:02 |
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:03 |
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:04 |
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 |
=== pitti still favors /etc/dpkg/predeb.d hooks | ||
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:05 |
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 |
=== doko [~doko___@dsl-084-059-084-138.arcor-ip.net] has joined #ubuntu-meeting | ||
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:06 |
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:07 |
=== Kinnison nods | ||
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:08 |
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:09 |
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:10 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
elmo | seb128: so when the panel gets a segfault bug ... ? | 12:17 |
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:18 |
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:19 |
pitti | yeah, we have a dialog (also for entering additional comments) | 12:20 |
pitti | <pitti> 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:21 |
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:22 |
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:23 |
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:24 |
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 |
=== Kinnison was expecting langpacks to simply be fed to rosetta | ||
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:25 |
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:26 |
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:27 |
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:28 |
elmo | (ports.u.c I mean) | 12:29 |
infinity | Yay for hideous hacks. | 12:29 |
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:30 |
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:31 |
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:32 |
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:33 |
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:34 |
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:35 |
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:36 |
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:37 |
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:38 |
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:39 |
=== infinity stares at his fingers. | ||
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:40 |
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:41 |
pitti | mvo: that would rock. definitively more sophisticated than calling urllib.urlretrieve... | 12:42 |
=== mvo runs from infinity | ||
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:42 |
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:43 |
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:44 |
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:45 |
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:46 |
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 |
=== FLeiXiuS [~fleixius@pcp0010487351pcs.essex01.md.comcast.net] has joined #ubuntu-meeting | ||
elmo | shrug, I suppose there's no compatability constraints, we could key of the priority if you want | 12:47 |
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 |
=== infinity hates long names. | ||
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:48 |
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:49 |
pitti | not for lunch | 12:50 |
pitti | I wrap that stuff up in the wiki | 12:50 |
=== ajmitch_ [~ajmitch@port164-167.ubs.maxnet.co.nz] has joined #ubuntu-meeting | ||
seb128 | thanks pitti, thanks everybody | 12:52 |
seb128 | lunch time :) | 12:52 |
=== 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 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!