[00:58] http://launchpadlibrarian.net/38689741/buildlog_ubuntu-lucid-i386.anjal_0.3.1-1_MANUALDEPWAIT.txt.gz this is failing to build because it needs evolution-data-server-dev >= 2.29.0. What's the normal course of action when that happens? Will 2.29.0 or above be in Lucid? I'm guessing not... [00:58] Do we need to revert to an older version of anjal? [01:23] funkyHat: We need to revert it. [01:23] funkyHat: See ldb for a recent example of how you have to do that. [01:24] ScottK: thanks [01:27] ScottK: do I need to do the +really bit, or just the epoch? [01:27] Not quite clear on how to do either, but I'll figure it out ⢁) [01:28] funkyHat: Do the really bit. [01:28] Could someone tell me how we get a freeze exception? [01:28] Avoid epochs at all costs. [01:28] An epoch will mess us up with Debian. [01:29] Ok, so is it as simple as grabbing the old package and messing with the version? [01:29] Freeciv, released 2.2 three days after the freeze window. [01:30] wiki.ubuntu.com/FreezeExceptionProcess [01:32] It would probably be easier for freeciv to be added to backports [01:33] Ah, someone has already packaged a fix for anjal, it seems. https://bugs.edge.launchpad.net/ubuntu/+source/anjal/+bug/518788 [01:33] Launchpad bug 518788 in anjal "cannot install in lucid" [High,Triaged] === traveller_ is now known as traveller [05:05] !info irssi [05:05] irssi (source: irssi): terminal based IRC client. In component main, is optional. Version 0.8.14-1ubuntu1 (karmic), package size 1120 kB, installed size 3024 kB [05:05] So- is there any reason truecrypt couldn't be apckaged in Ubuntu? [05:07] It has it's on license which means I'm guessing you'd need to have the user accept the terms of use when installing [05:08] Depends on what the license says. [05:08] It has to permit distribution. [05:09] At best it might be a multiverse candidate. [05:09] ScottK: as far as I can tell it does - It does say you can't modify the source and still call it truecrypt [05:10] That's fine. [05:10] I was asking because I'm sure I'm not the first to consider it [05:11] It could be fun to package this too whenever I finish up with the project I've been working on. [06:03] Hello, I have filed a sync request manually LP 557827 (since there is a problem with requestsync, for which I filed a bug), the question is: what should I do other than putting the latest changelog entries & subscribing motu-release ? [06:03] Launchpad bug 557827 in pyfribidi "FFe: Sync pyfribidi 0.10.0-2 (universe) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/557827 [06:04] AnAnt: You need to explain why we need to update it. Also, ubuntu-release, not motu-release. [06:04] sorry, I meant ubuntu-release [06:05] ScottK: I did do the explanation, but not yet upload build logs [06:26] build log uploaded [07:15] link to how to make a needs packaging bug? [07:18] daurnimator: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages [07:19] cool... the library I'm trying to compile just sent my box into a kernel panic [07:19] howw does that even happen [07:26] how do i say one bug depends on another? [07:27] daurnimator: no way to do it in launchpad [07:27] daurnimator: add a note in the description [07:28] k [07:30] filed a trio of needs-packaging: https://bugs.launchpad.net/ubuntu/+bug/557860 [07:30] Launchpad bug 557860 in ubuntu "iup" [Undecided,New] [08:07] good morning === nenolod is now known as moogle [09:59] Heya dholbach! [09:59] How's it going? [10:00] iulian: good [10:00] ScottK: Just FYI ... I can not request sync of evolution-mapi. There are package name changes in Debian. I will have to do simple upstream version update in Ubuntu. [10:00] how are you? [10:00] dholbach: Doing fine as well. I have just had breakfast. [10:00] * dholbach didn't yet :) [12:08] o [12:27] q. i need to add a path in the default PATH of the computer, how can i do that ? [12:27] (in a postinst) === quentusrex_ is now known as quentusrex [12:29] that sounds like a bad idea [12:33] that sounds like a *very* bad idea. [12:35] ok so nothing is done for that i guess, thanks [12:36] /etc/profile.d/*.sh got it! [12:37] ._. but it's a very bad idea. [12:37] what package is this? [12:37] why do you need to add things to the PATH? [12:38] i know i'd be annoyed if any package modified my PATH. [12:38] hmm speaking of /etc/profile.d, does anyone know why gvfs's bash completion is lying around in /etc/profile.d instead of /etc/bash_completion.d? [12:38] hyperair: and i do understand [12:44] where PATH is set ? this seems misterious [12:50] Packaging Training session in #ubuntu-classroom with geser in 10 mins: Q&A about the Developer Membership Board [12:50] jetienne: What are you seeking to accomplish by setting PATH? [12:51] persia: i try to require the use to modify their path by hand. [12:52] persia: i try not to require the user to modify their path by hand. [12:52] better :) [12:52] Why would the user need to modify their path? [12:52] persia: ok 42 :) [12:53] No, really. Where are you putting something that requires a specialised PATH? [12:53] persia: i dont want to enter on a lesson on "what is PATH" [12:53] I won't give you one then :) [12:53] But I'm still curious. [12:53] hehe i wasnt willing to give it :) [12:53] this is cool, i have a workaround. but im trying to do it as clean as possible [12:54] Understood, but why? [12:54] Because it's not required by any of the current packages in the archive, which makes me think there's a different solution. [12:54] persia: well you are mistaken :) [12:55] jetienne: is there a good reason why you can't put it into a directory which is in PATH? [12:55] guys guis ok [12:55] this is cool, no religion here [12:55] forget this PATH stuff [12:55] No, what are you trying to do? [12:55] PATH may be the right solution, in which case we'll share suggestions on how to do it cleanly/safely [12:56] But it's usually not the right solution, which is why we're asking. [12:56] persia: this is cool, thanks for your help [13:44] If a new version of something is released right now (drupal) - can that still find it's way into 10.04? [13:45] I'm guessing not - just making sure === hggdh_ is now known as hggdh [13:59] MTecknology: Exceedingly unlikely at this point in the cycle. [14:00] persia: ok, thanks [14:01] MTecknology: That said, if some upstream releases a new version that contains *only* stability bugfixes, and it's well documented, etc. that is a good candidate for inclusion. [14:02] But this tends to be uncommon. [14:04] persia: The only thing that's significant that I can see would be the security fix - http://drupal.org/node/731710 [14:05] persia: I had an idea for another class of automatic packcage checks perhaps we should do. Something like "If there is an Ubuntu diff and the package doesn't get merged for two relase cycles, just sync over the Ubuntu changes because better an maintained Debian version than an old unmaintained Ubuntu one." [14:07] I don't think that's a fair test. [14:07] I'd be happy if the merge had been outstanding for two release cycles, kinda [14:08] ScottK: have you a rough number of affected packages? [14:08] it would be nice if these said merges could be highlighted, so that priority can be given to them [14:08] geser: I didn't do the analysis yet, just hit a case where that had happened and syncing was clearly better. [14:08] And "kinda" because I had a counterexample, where I attemtped to adopt a package in Debian, someone else decided to adopt it after reviewing my work, included about 75% of the patches, ended up breaking it, orphaned it after 6 months, and then someone synced it (which I had to then go fix in Ubuntu) [14:09] lol [14:09] that sounds painful [14:09] persia: I'd think along the lines of what we did with supportable binaries where first you announce a list and give people a chance to reduce it. [14:10] ScottK: What I want to avoid is someone uploading an abandoned package in Debian for a library transition two days before the list is generating causing a sync that kills good Ubuntu changes for a well-maintained package. [14:10] My counterexample is painful, but I could have done better than getting annoyed and refusing to work with Debian for several months when that happened. [14:11] persia: Perhaps I didn't communicate my criteria well: I meant to say it had been needing a merge for two cycles. [14:11] Oh, I'm fine with that. [14:11] I think that would exclude packages that had any kind of maintenance in Ubuntu [14:11] needing a merge for two cycles != hasn't been merged in two cycles. [14:11] Agreed. [14:14] The package I tripped over was in the class of "Main packages that no one actually looks after." [14:16] Yeah. Those get frustrating after a couple years. Did you file the MainExclusion bug? [14:27] I discussed it with the RM who's hunting down if it can be demoted. [14:27] Also got an FFe for updating. [14:41] Hello MOTUs can anyone over here review my package for maverick???? [14:42] you people will think I am out of my mind :) [14:42] bilalakhtar: It's unlikely to happen before Lucid release. Most of us are focused on bug fixing. [14:42] No, you aren't out of your mind (good to work ahead), just optimistic. [14:43] ScottK: And, at the same time, no one knows whether the packages in maverick will have the same names or not :) [14:46] bilalakhtar: The vast majority of packages will have the same names. Things that often change (libraries) should be automatically set dependencies. [14:48] micahg, this should allow you to rebuild vlc against xulrunner 1.9.2: http://bugs.gentoo.org/attachment.cgi?id=217289 [14:48] bjsnider: thanks, will have a look [14:48] BTW, What are the reqs for becoming a MOTU? [14:51] micahg, they made several small changes that break backwards compatibility. such as utf8length becomes UTF8Length [14:51] and uint16 becomes uint16_t [14:52] bilalakhtar: The basic guideline is contribute as a MOTU sufficiently that MOTU tell you to apply to be MOTU. [14:52] I know that's vague, but if you just do a bunch of work, especially archive-quality related work, this will happen. [14:52] persia: But no one is there to see who is contributing how many times [14:53] bilalakhtar, well, people do sponsor your fixes [14:53] Actually, lots of folk see, and lots of folk watch :) [14:55] you never know who's watching :) [15:02] sorry to ask in here, i am trying to figure out what i am missing when trying to use auto confugre "autoreconf: running: aclocal -I autotools/m4; aclocal: couldn't open directory `autotools/m4': No such file or directory" [15:09] does anybody know how often the rcbugs page is update? [15:14] dholbach: if you don't get here an answer, try in #ubuntuwire [15:15] ah ok [15:20] so, what does ~motu-swat do? [15:22] we swat bugs [15:22] er i mean they [15:22] i.e. are they subscribed to bugs, etc? [15:23] The swat team is security oriented [15:23] They fix security issues [15:23] nigelb: ^ [15:23] mok0, are they subscribed to security issues in universe packages? [15:24] Not automatically. [15:24] nigelb: I guess... that seems to be a good thing [15:24] ok, context would help [15:24] I'm trying to figure out which of the bugs with patches can be ignored by ~ubuntu-reviews [15:24] so if ~motu-swat is subscribed, can we folks safely ignore? [15:25] I believe you are interested in ~ubuntu-security-sponsors. [15:25] nigelb: what bug? [15:26] mok0, no no, i'm editing the script which subscribes ~ubuntu-reviews to bugs with patchse [15:26] removing out redundant teams like u-u-s and u-m-s and adding any relevant teams [15:26] nigelb: ah... and bugs in that script will make you very unpopular :-) [15:27] yeah [15:27] hence proceeding with caution [15:27] so if ~motu-swat is subscribed, can we folks safely ignore? [15:27] nigelb: you may want to test it on the staging server [15:27] mok0, it works great already [15:27] I'm just making edits [15:28] brian wrote the script :) [15:28] nigelb: ask wgrant he owns the yeam [15:28] team [15:28] http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/annotate/head%3A/launchpadlib-scripts/patch-subscriber.py [15:28] wgrant, thoughts? [15:28] will you folks manage bugs subscribed to motu-swat? [15:28] mok0, ^ that is the script [15:29] nigelb: You could ignore bugs with ~ubuntu-security-sponsors subscribed. [15:29] ~motu-swat -- not so much. [15:29] wgrant, okay, will do :) [15:30] Looks like motu-swat is a subteam of security sponsors anyway [15:30] wgrant: is that team going away along with universe? [15:31] It is unclear. [15:31] could anyone please tell me how to get attention to bug #542185 ? there's a proposal patch to apply. the maintainer seems to be MOTU devs [15:31] Launchpad bug 542185 in holdingnuts "holdingnuts GUI badly affected by a bug in Qt 4.6.2" [Undecided,New] https://launchpad.net/bugs/542185 [16:01] wgrant: As the team owner, you have huge say in whether the team stays or goes :) [16:11] If there's someone with some understanding of autofoo, it would be useful to make our taktuk package in lucid work with the autotools-dev package we have so the build-dep version requirement can be relaxed. [16:15] If I built a script that would make working with mutliple chroots really brain deadly simple, is it something other people would use? I'm building it for myself and as I'm approaching line 200, I'm starting to wonder if it would be something others would like. [16:15] MTecknology, isn't there already something for it? [16:16] nigelb: is there? ... [16:16] I looked but didn't find one; I hope I didn't miss something [16:16] https://wiki.ubuntu.com/PbuilderHowto#Multiple%20pbuilders [16:17] MTecknology, ^ [16:17] nigelb: I found that page and assumed it's for pbuilder only [16:17] MTecknology: There is also the pbuilder-dist script in ubuntu-dev-tools [16:17] MTecknology, oh, sorry, confused multiple pbuilders with multiple chroots [16:18] And there's schroot which is specially designed for the case of working with chroots, rather than having anything to do with building stuff. [16:18] and lucid has a fancy mk-schroot script to generate all classes of schroots. [16:19] Oooh. Nice\ [16:19] so I could just as well stop now :P - that sounds like what I'm trying to do :P [16:19] (well, except I didn't manage to do the schroot-from-pbuilder-chroot bit before FF) [16:19] So maverick will *really* handle all classes of schroots :) [16:20] this kinda stinks - I looked for it before I started and didn't find it :P [16:21] would it help if my script worked with schroot and setup an X session before going into it and launch metacity once in it? [16:21] You mean something like `schroot -p` ? [16:21] "Preserve user environment" ? [16:22] Yeah. Let's you launch X stuff in your primary environment. [16:22] oh, no - like xnest [16:22] Handles all the little tricky bits like setting Xauthority, etc. [16:23] afaik, xnest launches a window for a new X session [16:24] So, `schroot -p sh -c 'apt-get -qy install xnest && xnest &'` ? [16:24] Err. [16:24] xnest on host [16:25] `schroot -p -- sh -c 'apt-get -qy install xnest && xnest &'` ? [16:25] How do you export that display into the chroot? [16:26] Xnest -ac :1 & export DISPLAY=localhost:1; schroot -- sh -c 'metacity' [16:27] You'd need a -p in there. [16:27] otherwise DISPLAY gets ignored. [16:27] oh, then toss that in there [16:28] Nifty script. Thanks :) [16:28] So maybe it won't be too horrible to finish this script [16:29] And actually, you'd want ` Xnest -ac :1 & export DISPLAY=localhost:1; schroot -c dapper -- sh -c 'metacity'` [16:29] Well, refactor it a bit. We've gone from 200 lines to 1 already :) [16:29] no, not even close [16:29] I wasn't that far yet :P [16:30] Ah, good. [16:30] Yeah, start with what schroot and mk-sbuild give you. From there, consider adding options to schroot to enable other stuff (like xnest or launch chroot in qemu/kvm, etc.) [16:31] I'll have you check it out when I'm done :) [16:32] have you/ask you to ... [16:32] I'll beg you to check it out when I'm done and be very thankful if you do and for any input you provide [16:33] ScottK: having taken a glimpse, autofoo doesn't seem to be the problem for taktuk, only dh need to be taught to call ./bootstrap manually before callling make [16:34] (/me admits to be still a debhelper v5 user *g*) [16:34] sistpoty|work: Could you deal with it? I asked lucas_, but he doesn't seem to have the time. [16:34] MTecknology: In that case, let me give you my wishlist as input: please allow Xnest with configurable resolution (so I can easily emulate e.g, 800x480), and add support for qemu/kvm so I can easily test odd X startup configs, etc. [16:35] ScottK: not too sure if I come around to it today yet, but I guess I should have time tomorrow or at least on saturday [16:35] ScottK: I'm in ENOTIME mode until tomorrow evening. but I'm fine if someone else fixes my packages :-) [16:36] sistpoty|work: Sounds good. lucas_ will be happy too. [16:36] heh [16:36] ScottK: also, doing an archive rebuild is higher on my todo list, and still not done [16:36] sistpoty|work: override_dh_auto_configure:\n\t./bootstrap or something [16:36] lucas_: Yes, we could use that. Thanks again for those. [16:36] james_w: thanks, that was the rune I was looking for :) [16:36] sistpoty|work: depending on whether you want configure to be called too [16:37] james_w: makes some sense, yes ;) [16:37] if you want configure too then + "\n\tdh_auto_configure" [16:38] persia: resolution will be easy enough - kvm i'll need to read into more - my laptop doesn't support that so I might need to figure out some way to test [16:38] MTecknology: Test with qemu then. If you get qemu working, getting kvm working is just a matter of testing if the HW supports KVM, and swapping the command name. [16:39] ok [16:40] how do I set Xnest display resolution? [16:40] And you said that was easy :) [16:40] I lied :D [16:43] persia: Is there some magically easy way to create/delete chroots? [16:44] Create, yes. Delete, not yet implemented. [16:44] Delete would require parsing schroot.conf, removing the target {file,LV,directory}, and then deleting the config stanza. === RoAk is now known as RoAkSoAx [16:45] I have ~1/2 of that done [16:52] lucas_: ok with that? http://revu.ubuntuwire.com/~sistpoty/taktuk.debdiff [16:53] sistpoty|work: probably :-) [16:53] sistpoty|work: if it works, I'm fine with it [16:53] heh :) [16:53] persia: A person should be able to run apache inside a chroot too and use xnest to open a web browser? [16:54] at least it builds fine in an completely unclean chroot (need to do a test once I'm home, signing key is at home anyways) [16:55] MTecknology: Sure, as long as it's the same chroot, but lots of services have a detect-if-this-is-a-chroot-and-don't-start facility. [16:56] persia: oh.. they break inside of it? [16:57] Some just don't start. Check your logs inside your chroot. [16:57] (this is part of why I'd like to be able to launch a virtual environment based on the contents of a chroot) [16:57] ok [16:57] (extra points for snapshot support) [16:58] :P - This is starting to sound like just using virtualbox :P [16:58] Actually: I don't care about snapshot: can be snapshot, union filesystems, etc. Just something that lets me start from a fresh state on demand. [16:58] Well, except the idea is to *reuse* the same chroot for several purposes: build-testing, app testing, virtual environments, etc. [16:58] q. i install a /etc/init.d script with dh_installinit, it got installed as expected. but it doesnt get delete when i remove the package, how come ? is that normal ? if not, how can i fix it ? [16:58] Saves disk space. [16:58] jetienne: Try purging the package [16:59] persia: ok [17:07] It looks like dh_link will only symlink files, not directories (unless I'm doing it wrong). Any suggestions on a sane way to do directory symlinking? Package is DH 7 based. [17:08] ScottK: The general advice is don't. If that doesn't work, do it in your install rule. [17:09] "override_dh_auto_install:\n\tdh_auto_install\n\tln -s ..." would be the model. [17:09] It's that or archive bloat with duplicate files in different binaries. [17:09] Or a huge input file to dh_link. [17:09] well just build that input file to dh_link each time === ttx_ is now known as ttx [17:11] The problem is that the file list would change relatively frequently, so that wouldn't be very maintainable. [17:11] ScottK, hence why you could just build it dynamically each time you run that rule. you can just pass the output of find -type f or so into it [17:11] ScottK: Well, if you generate it at build time, it can be. override_dh_auto_install:\n\t${generate-dh-link-file}\n\tdh_auto_install [17:20] hiya RainCT [17:25] ScottK: axiom builds? [17:25] sebner: No. A different one. [17:25] persia: sudo apt-get purge, does remove the init.d script, while sudo apt-get remove doesnt.... but this is a fully unmodified init.d script. how come it is not removed on apt-get remove ? [17:25] ScottK: "different"? [17:25] jetienne__: That is the difference between purge and remove [17:26] ScottK: even if the config is unmodified ? [17:26] sebner: My question wasn't about axiom [17:26] jetienne__: I believe the files under /etc are removed only in case of purge [17:26] jetienne__: Yes. [17:26] As slytherin says. [17:26] jetienne__: It7s still a configuration file. [17:26] slytherin: There are ways around that, but generally, yes. [17:26] ScottK: what question? xD [17:26] ScottK: ok, and a new reinstall be be ok if the new script is the same as the previous install, correct ? [17:27] Right. Make sure the init script doesn't assume the package is actually installed. [17:27] cool [17:27] jetienne__: Yes. If it's different and the previous was unmodified, it'll be updated. [17:27] persia: ScottK: slytherin: thanks all for the help [17:34] ScottK: I just noticed that you synced a new axiom version and the axiom I remember didn't build for years so I was wondering if this is really fixed now [17:34] sebner: It managed a test build. We'll see. [17:35] :) === yofel_ is now known as yofel [17:50] * sistpoty|work heads home... cya [17:50] ScottK: If you are not too busy can you please approve jboss binaries from new queue? [17:51] Hey mok0 :) [17:52] RainCT: long time [17:52] mok0: yeah, how are you? [17:52] RainCT: Oh, pretty good... busy [17:53] slytherin: Done. [17:53] ScottK: thanks [17:53] np [18:31] Could someone please beat configure in libuser into realizing that "checking for python script directory... ${prefix}/lib/python2.6/site-packages" is not true. [18:33] persia: well - I wrote the script - now I need to try it and make sure it works - so far the only thing I tested is --help :P [18:34] heh. [18:34] URI? [18:50] persia: http://bazaar.launchpad.net/~mtecknology/scripting/personal-scripts/annotate/head%3A/devroot [18:50] persia: It definitely won't work - but it's getting there - most of the stuff is there [18:51] MTecknology: schroot -l [18:52] MTecknology: Also, your script doesn't seem to support LV or file schroots. [18:52] MTecknology: What's ARCHIVE for? Can't you rely on the schroot's apt-cache? [18:53] MTecknology: delete looks *really* unsafe, especially for non directory schroots [18:54] MTecknology: Please use mk-sbuild to make the schroots: it supports all sorts of options well beyond those in your create function. [18:54] persia: ok [18:54] MTecknology: And schroot should already be bind-mounting /proc, etc. : unless you have a test failure, you should be able to skip that. [18:55] oh [18:55] Oh, and don't force running as root. If you need root, use sudo for that (one) command. [18:56] does schroot not require root? [18:56] Nope. [18:56] oh [18:56] so showing you was an awesome idea :D [18:56] It requires root to *create* a chroot, or to update a source, but not to use a schroot. [18:56] cool [18:57] You also want to use getopt to process your options. Take a look at mk-sbuild for an example. [18:57] http://packages.debian.org/sid/sound/madfuload [18:58] #bash said you shouldn't directly call getopt - I probably misunderstood - I'll check that out [18:58] You *shouldn't* directly call getopt :) [18:58] i think that should be synced asap since lucid and karmic's version is broken [18:58] persia: thanks for the review :D - I' [18:59] I'll work on that when I finish my report and classes (tomorrow) - times up for the day [18:59] bjsnider: I'm inclined to agree. Have you submitted a sync request? [19:05] persia, negative [19:05] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547336 [19:05] Debian bug 547336 in madfuload "Various fixes to madfuload from Ubuntu" [Grave,Fixed] [19:06] that's the debian bug report that explains the problems and fixes though [19:07] Right. It clearly needs fixing. Do you plan to file the sync request? [19:08] i can if you want. it's through launchpad right? [19:09] Either that, or run requestsync if you have ubuntu-dev-tools installed. If you don't want, I will: but if you do want, you may as well. [19:10] The idea being that if you notice stuff like that, you're a useful person to be filing syncs :) [19:10] !sync [19:10] Helpful information for filing a sync request can be found at https://wiki.ubuntu.com/SyncRequestProcess [19:11] persia, i'll take acare of it. seems easy enough [19:11] bjsnider: Thanks :) If you see more like that, please also request those. [19:12] persia, don't tempt me [19:12] Be aware that often when there is Ubuntu variation it needs a merge (but not when the Ubuntu stuff is merged back like that) [19:12] bjsnider: Please, especially for Grave stuff. Ideally we'd like to address all of that stuff pre-release. [19:12] Just take care, test, etc. [19:17] persia: hi, could you please renew my sponsorship team membership? [19:19] randomaction: No, but I'll add you to the new sponsorship team :) [19:19] persia: That'll do for me [19:20] so we're migrating to a single team as memberships expire? [19:20] Excellent :) [19:20] persia: It's still useful to have people in the old team also so they can unsubscribe bugs. [19:21] ScottK: We have a script that autounsubscribes the old teams and subscribes the new ones. Apologies that it doesn't run often enough. [19:22] Ah, OK. [19:22] Nevermind then. [19:22] http://people.canonical.com/~dholbach/resubscribe for the curious [19:30] sebner: https://launchpad.net/ubuntu/+source/axiom/20091101-7/+build/1681921 [19:47] persia: what package does mk-sbuild come in? [19:48] ubuntu-dev-tools [19:54] persia: oh- I was trying to keep the dependencies pretty light, then you can load up junk in the vm; I'm going to add an option to do just that actually. after chroot installs prompt for loading up with ubuntu dev tools [19:55] MTecknology: Except you need ubuntu-dev-tools *outside* the chroot. [19:55] why's that? [19:55] I don't expect to be able to get that script somewhere else until maverick+1. [19:55] Because you want to have mk-sbuild to create your schroot. [19:58] I'm looking at that script [20:01] persia: what benefits are there in having a single file chroot or the LV? [20:02] file schroots take up almost no space. LV schroots use LV snapshot rather than aufs/unionfs [20:03] directory schroots are fastest, but take up more space, and get a little odd when updated. [20:03] (and may actually break if lots and lots of stuff is installed on low-memory systems) [20:03] oh [20:04] So if you're low on disk-space, you want file schroots. If you're low on memory (or need it for something else), you want LV schroots. If you have bundles of both and want speed, you want directory schroots. [20:05] Note that low-on-disk-space can also be interpreted as want-schroots-for-i386/amd64/powerpc/armel/lpia for dapper/hardy/jaunty/karmic/lucid/etch/lenny/squeeze/sid [20:05] ok [20:06] (not that anyone really *needs* 39 schroots on one machine, but ...) [20:06] Err, 37. [20:07] Oh, 37 is perfectly reasonable. 39 is nuts. [20:07] soren: Indeed. 39 requires that someone have something unsupported configured. [20:07] wgrant, persia: wesnoth upstream confirmed that the patch from the Debian BTS fixes the SDL issue for wesnoth. It just takes back parts of another fix that sdl upstream wanted to fix with that, I'm not sure which one is the more relevant, though. [20:07] (actually, two things) [20:09] persia: would it be ok to say have it a config option so they pick one and that's what's used for all of the chroots? [20:10] No. [20:10] persia, wgrant: http://bugzilla.libsdl.org/show_bug.cgi?id=716 seems to be the issue that would get reverted with the mouse click fix. [20:10] bugzilla.libsdl.org bug 716 in events "Application doesn't receive SDL_ACTIVEEVENT when dragging from other window" [Normal,Resolved: fixed] [20:10] Lots of folk want several releases or several architectures. All 37 is a bit excessive, but ... [20:11] Rhonda: Do we know what software uses SDL_ACTIVEEVENT? [20:11] ScottK: nice! [20:12] persia: once you build the schroot, does the chroot command change between how it's built or does schroot just handle it? [20:13] MTecknology: schroot just handles it. [20:13] But for foreign schroots, you need qemu-kvm-extras-static installed on the host. [20:14] foreign? [20:14] Hm. 3dwm seems to use it, but I'm not sure that's as important as wesnoth :) [20:14] MTecknology: e.g. powerpc schroot on i386. [20:14] oh [20:17] wait... --config doesn't let you specify a config but rather dumps the whole config.. [20:17] Ugh. ffmpeg uses it: anyone know if drag'n'drop is critical for ffmpeg? [20:21]