[01:02] <magdalena> hello\
[06:05] <RoAkSoAx> ScottK, ping?
[07:14] <dholbach> good morning
[07:15] <poolie> lifeless (or anyone): when james_w says "updated package targeted to -proposed" what does that mean?
[07:16] <poolie> in what way is the package, as opposed to the upload, targeted to -proposed?
[07:20] <persia> poolie: the targeted suite for an upload is typically defined in the most recent entry of the debian/copyright file in the package.  It's possible to override it in various ways during package construction, but the tools don't do this by default.
[07:21] <jmarsden> persia: Most recent entry of the debian/changelog file... right?
[07:22] <persia> jmarsden: Right.
[07:29] <poolie> oh so that can just change from karmic to karmic-proposed for example?
[07:30] <poolie> hello btw
[07:32] <persia> poolie: Right.  karmic is closed to upload.  Best to change in the changelog rather than faking it, just so that the code has the appropriately documented history.
[07:36] <poolie> ok thanks
[10:11] <Rhonda> hmm. Now it's dec 7th, I was told that I can expect the CoC 1.0 on the 5th. Any reason for why it's still not there? :/
[10:11] <Rhonda> https://launchpad.net/codeofconduct that is, still links the old CoC :/
[11:13] <Laney> Rhonda: I got some bugmail over the weekend saying it was fixed in launchpad-devel
[11:13] <dholbach> Laney: it's on staging
[11:13] <Laney> indeed it is on edge
[11:13] <dholbach> ah ok
[11:13] <Laney> dunno when the next rollout to production is
[11:14] <jpds> 16th.
[11:14] <Laney> \o
[11:25] <Rhonda> Laney, dholbach, jpds: Thanks for the heads-up :)
[11:31] <dholbach> no worries
[11:49] <rc55> Are universe packages considered untested / unsupported?
[11:49] <jpds> They're supported and tested by the community.
[11:53] <alkisg> Can I somehow share code between my package and its postrm script?
[11:53] <alkisg> E.g. afaik I can't include other scripts from my-package.postrm script... I can only do that from the .prerm script, right?
[11:54] <persia> alkisg: The trick is that at the time the postrm runs, the package has been removed from the system.
[11:55] <alkisg> persia: right... :( so could I do the opposite? Have a function in the .postrm script, and call it from a regular script of mine? Can I rely on /var/lib/dpkg/info/sch-server.postrm being there? (I guess not, I just want to verify it :))
[11:56] <persia> I don't actually know.  I suppose you might be able to do that, but I'd not want to rely on it.  What are you trying to accomplish?
[11:56] <alkisg> There's a purging function that would be ran on postrm, but the user may also want to run it without removing the package
[11:57] <alkisg> And I was trying to see if there's some way to not duplicate code
[11:57] <persia> What does the purging function do?
[11:57] <alkisg> Remove some files in /etc/ (non-conffiles), un-registers some settings (e.g. in /etc/ssh/sshd_config) ...
[11:58] <persia> Your package is ssh?
[11:58] <alkisg> No, it just tries to help the user configure some servers (sshd, apache etc) so it writes on other packages files :D
[11:59] <soren> /etc/ssh/sshd_config is not a conffile.
[11:59] <alkisg> Not the best thing to do, but I don't think there's another way...
[11:59] <alkisg> soren: right, I just put some entries there and remove them when my package is purged
[11:59] <soren> alkisg: My comment was meant for persia, actually :) I knew where he was going.
[12:00] <alkisg> Ah, sorry, I don't quite get it yet
[12:00] <persia> alkisg: I do believe that is in contravention to policy, but 10.7.4 might offer a loophole
[12:00]  * alkisg looks...
[12:00] <persia> That said, I don't think you want to do that as a shared function.
[12:00] <soren> 10.7.4 is about packages that offer a utility to change their config isn't it?
[12:01] <persia> soren: 10.7.4 has a section about sharing configuration files
[12:01] <persia> It has "The maintainer scripts must not alter a conffile of any package, including the one the scripts belong to."
[12:01] <persia> But it seems to be looser for non-conffile configuration files.
[12:01] <soren>  The owning package should also provide a program that the other packages may use to modify the configuration file.
[12:02] <persia> alkisg: So, anyway, back to my line of reasoning.  Is there a case where you would want to preserve the modifications to /etc/ssh/sshd_config, etc. when your package isn't installed?
[12:02] <persia> soren: Right, but it's only a should.
[12:02] <soren> meh
[12:03] <persia> heh
[12:03] <alkisg> persia: e.g. my package puts the server ssh keys to the client so that the teacher has complete control over the client PCs. It also does a lot of other stuff, messing around with configuration files (non conffiles, mostly). Now, it's possible that some teachers doesn't want all 100% of the settings I do for him, so I'd like to allow him to undo some changes without uninstalling the whole package
[12:04] <persia> alkisg: careful about the "mostly" with the non-conffiles bit: touching those violates 10.7.4
[12:04] <persia> alkisg: I think it's a good idea to have a purge, but I'd run that at uninstall, rather than purge.
[12:04] <persia> It's not necessarily safe to assume that the modifications are applicable after the package is removed (even if the package is not yet purged)
[12:05] <alkisg> persia: I know, but I couldn't find any other way to make it easy for teachers that don't have support tech around. Would you have some idea that would help here?
[12:05] <persia> So, stick it in your prerm
[12:05] <alkisg> I don't want to remove the settings on plain package removal, because most times the teacher will want to keep them
[12:05] <alkisg> Ah, you mean prerm / purge... hm... right
[12:05] <persia> alkisg: Sure.  Modify the packages that provide the conffiles to make them non-conffiles (which basically means creating a configuration file management mechanism)
[12:06] <alkisg> I'd hate to have to do that for every version of openssh-server, apache2, php, etc etc that comes out
[12:06] <persia> alkisg: Right.  The difference between uninstalled and purged is tricky to get right.
[12:06] <persia> alkisg: No, just for all the ones in the repo, and document it well as best practice for future maintained versions.
[12:06] <persia> If you work with the relevant Debian maintainers, this tends not to be complicated.
[12:07] <persia> soren: Just as a counter-example to "The owning package should also provide a program that the other packages may use to modify the configuration file.", many packages provide the management functionality thorough a conf.d mechanism so that other packages don't have to have anything special in the postinst.
[12:07] <alkisg> Sorry, I don't get this last one. Suppose I want to do this:
[12:07] <alkisg> sed -i -e 's/MaxStartups 20:30:60/#MaxStartups 10:30:60/' /etc/ssh/sshd_config
[12:07] <alkisg> How should I do it?
[12:08] <soren> persia: in that case they're not sharing a configuration file.
[12:08] <alkisg> (that's on postrm, and I do the opposite on postinst)
[12:08] <persia> soren: depends on how conf.d is implemented.  I've seen cases where cat is used :)
[12:08] <soren> persia: Ah, right. I may actually be guilty of something like that :)
[12:10] <persia> soren: Actually, I suppose that appropriate implementation with cat would be to cat into /var/cache/${package}/conffile and target that or something similarly wonky, but I may be mistaken.
[12:11] <soren> persia: Sounds sound.
[12:11] <soren> :)
[12:11] <persia> alkisg: Ask yourself two questions: 1) why should the value not be 20:30:60 for every installation, and 2) is there a way that ssh could read a config produced from a collection of files rather than a single file (as does, say, apache).
[12:12] <persia> alkisg: If the value could reasonably *always* be set, arrange for it to be changed by default.
[12:13] <alkisg> persia: it'd be a bless if all the packages I was trying to mess with provided a conf.d directory, or even if they were accepting proposals about default values. Unfortunately, I don't think that's feasible (at least for a newbie developer/teacher like me) :-/
[12:13] <persia> If not, prepare a configuration file management system (there are several extent, with apt, cron, and apache all being interesting examples) that allows you to place a file containing the desired configuration change separate from the files provided by the managing package.
[12:14] <persia> alkisg: This is Ubuntu.  Everything is subject to proposals, by anyone willing to defend their reasoning.
[12:15] <persia> Changing defaults tends to be fairly easy.  Typical successful procedure is to find relevant developers on IRC, and chat about it a bit to understand what needs researching, and then file a bug with the proposed change, rationale, and other support from the research.
[12:16] <alkisg> I've done that many times, and I was succesful on some of them. But only some.
[12:16] <persia> Implementation of configuration file management mechanisms are often gleefully accepted by the relevant Debian maintainers, unless there's some specific reason why doing so may break the package.
[12:16] <alkisg> There are times where "good defaults for schools" aren't "good defaults for everybody"..
[12:17] <alkisg> And unfortunately, I only have some hours to invest on this per day. Implementing file management mechanisms for other packages would divert me from my real purpose, helping teachers...
[12:18]  * alkisg shrugs
[12:18] <persia> alkisg: In those cases, you want the configuration management facility.  Having already taken the first path, you're well armed with arguments as to why the defaults should differ under differing circumstances in common enough cases that it makes sense to be able to alter them programatically.
[12:19] <persia> alkisg: Don't discount yourself.  A few hours a day is many more than many people have to spend on this stuff.  Also, there are some fairly easy to implement conf.d mechanisms (e.g. the weak cat implementation I described earlier).
[12:20] <alkisg> I'm trying to push changes upstream or to package maintainers wherever I think it'll be easily accepted, but I have to make do when that's not possible .... :(
[12:20] <alkisg> persia: thanks a lot for your advice, and your time :)
[12:21] <persia> alkisg: And thank you for spending time to make Ubuntu better for teachers.  I often hear favorable reports from educators I know, and I presume that's in part from what you've done.
[12:21] <alkisg> :)
[12:29] <thekorn> hello MOTUs! if anybody of you has a bit of spare time, can you please have a look at http://revu.ubuntuwire.com/p/python-fusepy ?
[12:29] <thekorn> thanks you so much ;)
[13:25]  * Yagisan sighs
[13:27]  * Yagisan is sure buildbot hates him
[13:29]  * slytherin kicks buildbot for hating Yagisan
[13:29] <Yagisan> thanks slytherin
[13:29] <Yagisan> I think it needs a few more
[13:29] <Yagisan> just until it actually starts working
[13:31] <slytherin> Yagisan: what problem are you facing?
[13:31] <Yagisan> slytherin, I just reported bug #493575
[13:32] <Yagisan> slytherin, in a nutshell - it crashes
[13:32] <Yagisan> slytherin, and google didn't help :/
[13:34] <slytherin> I was confused. I thought you were calling out build servers as buildbot. I did not know you were referring to buildbot software.
[13:37] <feasty> When doing some bug fixes is it preferable to do multiple fixes in one package or one for each bug ID? I have a fix done but there is another one for the same package I think I may work on after but wondered if I should do them together in one or separate them?
[13:38] <directhex> feasty, multiple bugs can be closed by a single upload, so work with that in mind
[13:38] <Yagisan> slytherin, not a problem - although the reason for sighing was that I had build 16 slaves machines before I noticed the "bug"
[13:39] <slytherin> feasty: multiple fixes in one upload is nice. That means users will get more bug fixes in single download.
[13:40] <feasty> directhex, slytherin ok thanks for that. I'll try and get this other one in the same upload then. Thanks again.
[13:51] <Yagisan> O-o wow, it's been 3 and a half years since my last upload to Ubuntu
[15:16] <mok0> Testing... 1, 2, 3, testing
[15:17] <ScottK> mok0: You're on.
[15:17] <mok0> :)
[15:17]  * geser waits on what mok0 has to say
[15:18] <mok0> (uhm, just testing... to see what my nick was :-] )
[15:18] <geser> mok0: that's easy: your nick is mok0 :)
[15:18] <mok0> Hehe :-P
[15:50] <MenZa> Are there plans to package Pidgin 2.6.4 in Karmic?
[15:51] <Laney> pidgin is routinely backported
[15:52] <Laney> (if someone does the work)
[15:53] <micahg> MenZa: there's a pidgin developers ppa
[15:53] <micahg> https://launchpad.net/~pidgin-developers/+archive/ppa
[15:53] <MenZa> micahg: Aye, I found that
[15:53] <MenZa> It was more of a question whether it was going to be packaged, er, properly for Ubuntu
[16:32] <LaserJock> what's a good programmatic way to tell if a package is in main or universe?
[16:33] <pochu> doesn't 'apt-cache show' say it?
[16:33] <jpds> LaserJock: apt-cache policy|madison <package>, rmadison <package>,
[16:34] <achadwick> apt-cache show $PKG | grep -q 'Section: universe'
[16:34] <LaserJock> but I need to do it programmatically, i.e. in a shell script
[16:34] <LaserJock> ok, that's pretty good
[16:35] <achadwick> '^Section: *universe' for a little more robustness maybe
[16:35] <pochu> '^Section: universe$' rather? :)
[16:36] <geser> no, this will fail at "Section: universe/devel"
[16:36] <pochu> ah right
[16:56] <CarlFK> what is the name of the script that converts diff files to debpatch ?
[16:57] <pochu> debpatch?
[16:58] <CarlFK> pochu: the patch file format found in debian/patches
[16:59] <geser> CarlFK: dpatch as patch system or an other patch system?
[16:59] <CarlFK> i think debpatch is the name of the scrip I am looking for :)
[16:59] <dholbach> debdiff maybe?
[17:00] <CarlFK> maybe..
[17:00] <dholbach> https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
[17:00] <geser> what are you wanting to do?
[17:03] <CarlFK> get a gtk patch applied to karmic
[17:03] <mok0_> What's the deal with that Python discussion on dd?
[17:04] <kklimonda> mok0_: now there is a discussion about python on dd when I've unsubscribed? ;)
[17:04] <kklimonda> damn
[17:04] <mok0_> kklimonda: yep. I've followed it with shock and awe
[17:04] <kklimonda> mok0_: it's a discussion about why isn't python 2.6 in unstable yet?
[17:04] <mok0_> kklimonda: you got it
[17:05] <mok0_> The maintainer is getting many coarse words
[17:05] <mok0_> and the anger is spilling over onto Canonical
[17:05] <micahg> don't know if bug 493649 would interest anyone
[17:10] <ScottK> There isn't any new information in the d-d thready on Python 2.6 except that some people are trying to get things resolved in private.
[17:10] <ScottK> thready/thread
[17:11] <mok0_> ... but what's the problem upholding the upload?
[17:11] <av`> mok0, missing maintainer's communication and willing to do it :)
[17:12] <mok0_> av`: that doesn't make sense
[17:12] <av`> mok0, I know, but it's what is currently happening
[17:12] <mok0_> Perhaps Debian should sync from Ubuntu, LOL
[17:13] <av`> don't propose that or you gonna get flamed like hell :)
[17:13] <ScottK> Yeah.  Please don't.
[17:14] <mok0_> I wont
[18:41] <highvoltage> hi. any REVU admins around?
[19:25] <akheron> motus around? http://revu.ubuntuwire.com/p/jansson
[19:29] <kklimonda> why does opts="uversionmangle=s/(b[0-9]+)$/~\1/" change 1.80b1 into 1.80~1 ?
[19:31] <geser> too less escaping perhaps?
[19:31] <geser> try "~\\1"
[19:33] <kklimonda> hmm.. thanks
[19:35] <kklimonda> and the second question - if I work on an update to the package and in the meantime the never version is released can I add the new changelog entry and leave the old one UNRELEASED?
[19:35] <ScottK> I generally prefer to merge them.
[19:36] <av`> kklimonda, I would say yes, saw some packages with UNRELEASED
[19:36] <av`> kklimonda, just be sure your current changelog's entry is targeted to the right place
[19:37] <av`> kklimonda, just be sure your current changelog's entry is targeted to the right place = otherwise it will be hopefully rejected
[19:37] <kklimonda> ScottK: but is this a matter of preference or is there a rule somewhere for ubuntu developers? in Debian I've seen some UNRELEASED entries but there every package have a maintainer so it's his choice
[19:39] <av`> kklimonda, leaving UNRELEASED in Ubuntu doesnt make sense
[19:39] <av`> kklimonda, it is on Debian but not on Ubuntu
[19:39] <av`> kklimonda, so merging would be nice as ScottK suggested
[19:39] <kklimonda> av`: why it doesn't make sense? Just curious
[19:40] <av`> kklimonda, packages are not personally maintained here, so someone at the next revision upload will start asking 'hey, why did you left UNRELEASED here?'
[19:41] <av`> kklimonda, also UNRELEASED is quite alwais meant for vcs purposes
[19:42] <av`> kklimonda, e.g for multiple maintainers and for big packages with big changes, having a small package with UNRELEASED is usually not the best, that's why merging should be the right thing to do in these cases
[19:43] <av`> but anyway really up to you
[19:43] <av`> kklimonda, :)
[19:44] <kklimonda> heh
[19:47] <ScottK> kklimonda: debian/changelog is a record of the changes of the package in the archive.  Almost never does it make sense to track intermediate changes that never got into the archive.
[19:48] <kklimonda> ScottK: so UNRELEASED is used by developers who want to keep a track of their changes but aren't willing to move to vcs?
[19:48] <ScottK> kklimonda: Usually when I've seen it in the archive, I'd consider it a mistake.
[19:49] <ScottK> IMO it's used by lazy maintainers who won't go to the effort to make a proper changelog entry.
[19:55] <kklimonda> ScottK: ok, thanks :)
[20:23] <pting> can someone confirm this for me as a bug... apt-get source php5 && cd php5-5.2.10.dfsg.1 && ./debian/rules configure-cli-stamp && ./debian clean ... errors with: Patch suhosin.patch does not remove cleanly (refresh it or enforce with -f) make: *** [unpatch] Error 1 i'm on karmic amd64
[20:25] <ScottK> Yes.  It's a bug.
[20:26] <pting> cool, i guess i'll submit it
[20:57] <pting> yeah, my first bug creation https://bugs.launchpad.net/ubuntu/+source/php5/+bug/493761 ... it's beautiful
[21:06] <Flannel> What's the rationale behind "recommends" being treated as required for universe/main/etc classification stuff?
[21:09] <ScottK> Flannel: Look at the policy manual at the definition of Recommends.  I think it's pretty self evident.
[21:12] <Flannel> ScottK: Ah, thanks
[22:20] <MTecknology> Time to learn how to package...
[22:29] <Amaranth> MTecknology: you guys getting any snow?
[22:43] <mdc_laptop> where can i find info about packaging a openoffice extensions? (in this case a better dictionary)
[22:54] <RoAkSoAx> Hey guys, is there automatic renaming from XX/python2.6/site-packages to XX/python2.6/dist-packages ??
[22:58] <kklimonda> RoAkSoAx: automatic?
[23:00] <RoAkSoAx> kklimonda, as in during build process something that is in  XX/python2.6/site-packages will be renamed to XX/python2.6/dist-packages
[23:14] <RoAkSoAx> ScottK, during build process something that is in  XX/python2.6/site-packages will be renamed automatically to XX/python2.6/dist-packages ??
[23:18] <ScottK> RoAkSoAx: It depends.  Often yes.  I can't promise it in all cases.
[23:20] <RoAkSoAx> ScottK, so it would be better to not rely on that, and just do whatever change is needed to make it install directly into XX/python2.6/dist-packages ??
[23:20] <ScottK> RoAkSoAx: No, test and see if it works without customization and if it does, be happy.  If not, then do that.
[23:21] <RoAkSoAx> ScottK, ok, awesome. Thanks :)
[23:33] <pting> i'm trying to build php5 from source with some custom patches, how do i build a specific .deb file without building it? for example, how would i only build the deb for the cgi build?
[23:36] <dtchen> cjwatson: hi, do you mind if I work with bddebian on the libsdl1.2 merge from experimental? The ALSA and PulseAudio backends are in serious need of help, and that work has been done in experimental's upload.