[05:56] <alkisg> I have a package mahara-el, which wants to depend and also *preseed* some debconf values for package mahara.
[05:56] <alkisg> Unfortunately calling debconf-set-selections from mahara-el.preinst happens too late, after mahara is installed.
[05:56] <alkisg> I guess I could write yet another package, mahara-el-configuration, and predepend on that... but isn't there any better way to do it?
[05:58] <ScottK> You can't really do that in a policy compliant way.  Mahara needs to provide an interface for you to change it's configuration.
[05:59] <alkisg> ...provide a way to change its debconf configuration _before_ it's installed?
[06:00] <alkisg> I don't want to change anything in /etc/, I just want to modify the setup dialogs displayed upon mahara installation by debconf
[06:02] <alkisg> Here's my preinst, i.e. a single debconf-set-selections call: http://paste.ubuntu.com/822227/
[06:04] <alkisg> And even if mahara provided a way to change its configuration, how would I do that from mahara-el, _before_ mahara.postinst is called?
[06:06] <alkisg> My problem is that the dependency postinst gets installed before any of my package code runs, so I don't have any control over the dependency's postinst.
[06:12] <alkisg> Hmm... So if package A depends on B and predepends on C, it's not guaranteed that C.preinst will be called before B.postinst? :(
[06:47] <RAOF> alkisg: Right.  If package A's script needs to run before package B's script, the proper dependency is B Depends: A.  Obviously that's not available to you, though.
[06:48] <alkisg> RAOF: got it, thank you. I'll just remove any preseeding attempts. :)
[06:48] <RAOF> I don't think it makes sense to preseed without Depends, anyway.  What happens if a user installs mahara-el *after* they install mahara, for example.
[06:48] <micahg> alkisg: you might be interested in this: https://juju.ubuntu.com/
[06:50] <alkisg> RAOF: it's just a helper package to ease the installation for local teachers, I'm not planning to put it to universe or anything, so if they have mahara installed they're not interested in getting help for the installation anyway
[06:50] <alkisg> So they're not interested in mahara-el. In any case, I can check if mahara debconf values are there before setting them
[06:50] <RAOF> alkisg: Then you could document / script that you need to install maraha-el first, and…  yeah, check.
[06:51] <alkisg> Although I still think it would make sense for the Pre-Depends packages to be installed before the Depends packages, if possible.
[06:51] <alkisg> That would give me a way to do preseeding.
[06:52] <RAOF> True.  Pre-Depends means something different, though.
[06:52] <alkisg> Gotcha
[06:52] <alkisg> micahg: I heard about juju in BTS, yeah I should probably read more about it...
[06:53] <RAOF> (IIRC, “A Pre-Depends B” means “A's pre-inst script requires B to be fully configured”)
[07:09] <alkisg> micahg: teachers would need to be able to run console commands to use juju, right? That's even more difficult for them than selecting "mysql" instead of the preselected "postgresql"... :-/
[08:04] <dholbach> good morning
[08:05] <ajmitch> morning dholbach
[08:05] <dholbach> hey ajmitch
[08:15] <geser> good morning
[08:16] <ajmitch> hi geser
[08:19] <dholbach> hey geser
[14:44] <mhall119> what's the process for getting a package into Universe?
[14:44] <mhall119> I guess REVU is gone?
[14:46] <mhall119> didrocks: trying to get Singlet available to the masses
[14:49] <Rhonda> mhall119: best option is to get the package into debian and simply get it synced afterwards
[14:49] <mhall119> well it's Unity centric and depends on unity packages, so that won't work
[14:49] <Rhonda> That will benefit a more bigger audience, and the actual work for maintaining the package isn't really more dificult
[14:49] <Rhonda> ah, alright
[14:50] <mhall119> it's a python library for developing lenses and scopes
[14:50] <mhall119> and I don't want to put it in extras, because other packages aren't supposed to depend on stuff in extras
[14:51] <ScottK> REVU isn't actually gone and in any case it was only a tool for get two Ubuntu developers to review and upload.
[14:51] <ScottK> Find someone to review/upload it.
[14:53] <mhall119> ScottK: ok, thanks
[17:32] <micahg> dholbach: any idea why we have the diff for s/libfam/ligmain/ on gnubiff?
[17:33] <micahg> as both are in universe now, I don't see that it necessarily matters
[17:33] <micahg> that should be libgamin, not libmain
[17:41] <dholbach> micahg, hum, maybe you're right - do we have much stuff build-depending on libfam-dev?
[17:48] <dholbach> ok, micahg was right :)
[22:06] <micahg> just checking, but is preinst in the new package run before the old files are removed from the old package?
[22:09] <Laney> micahg: http://wiki.debian.org/MaintainerScripts
[22:09] <Laney> yes
[22:10] <micahg> I read that :), just wanted to make sure
[22:10] <Laney> just giving you it incase you didn't have it
[22:10] <Laney> it's the best link ever about maintainer scripts
[22:11] <Laney> although the layout is more unfortunate than i remember it being
[22:14] <ajmitch> I suspect the layout has got a bit mangled on that wiki
[22:15] <Laney> it was always there, probably some new-stylesheet fail
[22:16] <Laney> ye, classic looks fine
[22:44] <l3on> Hi all... I'm trying to fix a bug in apt-lucid... But I'm a bit in trouble with the version :/
[22:44] <l3on> first of all:
[22:44] <l3on>        apt | 0.7.25.3ubuntu7 |         lucid | source, amd64, armel, i386, ia64, powerpc, sparc
[22:44] <l3on>        apt | 0.7.25.3ubuntu9.9 | lucid-security | source, amd64, armel, i386, ia64, powerpc, sparc
[22:44] <l3on>        apt | 0.7.25.3ubuntu9.9 | lucid-updates | source, amd64, armel, i386, ia64, powerpc, sparc
[22:45] <l3on> which branch I should download? :)
[22:45] <l3on> second: the version should be ubuntu9.10, right ?
[22:45] <l3on> the bug is → 917845
[22:46] <l3on> and the patch here → http://anonscm.debian.org/loggerhead/apt/debian-sid/revision/2013
[22:46] <l3on> suggestions?  :)