[00:50] <onehundredthirty> Hi, I'm a maintainer of uWSGI package for Debian and co-maintainer of the same package for Ubuntu. I'm here to elaborate needing of separate package for Ubuntu.
[00:51] <micahg> onehundredthirty: what's the issue?
[00:51] <onehundredthirty> Some binary package of Debian uWSGI package is depends from python2.5 but it's support was officialy dropped since Lucid
[00:52] <micahg> onehundredthirty: that can be handled with control.in
[00:53] <onehundredthirty> Is it common practice? Are there packages with control.in which I could look into for example?
[00:53] <micahg> openjdk is the craziest example I can think of, I'm sure there are more sane ones
[00:53] <ebroder> wait, why do you need a control.in for that?
[00:53] <micahg> ebroder: different binaty depends?
[00:53] <micahg> *binary
[00:53] <ebroder> just build-dep on python and dep on ${python:Depends} and properly apply the python policy
[00:54] <micahg> hmm, yeah, that would work too :)
[00:55] <micahg> onehundredthirty: is that the only issue?
[00:56] <onehundredthirty> Could you look into my debian/control http://paste.ubuntu.com/555606/ and say is ${python:Depends} is the soultion?
[00:57] <onehundredthirty> Yes, modifying of debian/control in process of building is only issue
[00:58] <ari-tczew> onehundredthirty: this is new package?
[00:58] <onehundredthirty> I'll try to download source package for openjdk now and take a look into it's debian/control
[00:58] <micahg> onehundredthirty: well, if that's the only issue, the worse thing would be to drop the python2.5 package when syncing, there's probably a better solution I'm not aware of
[00:59] <micahg> onehundredthirty: openjdk won't help here I don't think
[00:59] <onehundredthirty> Yes, this is new package, It has an ITP bug in Debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582864
[01:00] <micahg> ebroder: there's a problem with generating d/control at runtime or just the build-depends?
[01:01] <onehundredthirty> Just dropping 'uwsgi-python2.5' will break 'uwsgi' (as it depends on uwsgi-python2.5)
[01:01] <onehundredthirty> Yes, I need to generate whole debian/control in runtime
[01:01] <micahg> onehundredthirty: no, it looks like it's an OR, so it won't break
[01:02] <ebroder> onehundredthirty: is there a particularly compelling reason to build it for more than just the default python version?
[01:03] <onehundredthirty> Yes, the binary of uWSGI is directly linked with libpython*. So for serving with different Python versions I need to build different binaries.
[01:04] <ebroder> right, but i don't think any of the other wsgi servers are packaged like that
[01:04] <ebroder> i think they're only built to run against the default python
[01:08] <onehundredthirty> you are right (just look at libapache2-mod-wsgi and it has only version linked with libpython2.6), but nevertheless I believe that providing package for each available Python version gives more pretty user expirience
[01:10] <onehundredthirty> oh, no. there is libapache2-mod-wsgi-py3 also
[01:42] <onehundredthirty> as I see, in openjdk there is an debian/control target but it's invoked manually by maintainer. autogeneration of debian/control in process of building is a bad practice. am I right?
[01:50] <ebroder> yes, the debian ftpmasters would reject that
[01:51] <ebroder> onehundredthirty: why not do one package that's whatever current python2 is, and one package that's whatever current python3 is?
[01:51] <ebroder> (the debian/ubuntu python infrastructure basically considers py2 and py3 to be different languages, as well it should)
[02:02] <onehundredthirty> ebroder: well, I could go this way. But it doesn't seems like my original intention of packaging uWSGI for all available python versions.
[02:08] <ari-tczew> bdrung: http://paste.ubuntu.com/555614/
[02:14] <ebroder> onehundredthirty: so, if you're going to insist on it, it is possible to define packages in debian/control that don't actually get built. you can look at the zephyr package for an example
[02:15] <ebroder> you could use that to only build against a particular python version if that version was available
[02:15] <ebroder> but that'll be more of a maintenance burden as new versions of python are introduced than if you just use the default python version
[02:16] <ebroder> if you do the latter, then the package can be updated as the python defaults change using the binNMU process - without any intervention on your (or your sponsor's) part
[02:18] <ebroder> and as a point of reference, it doesn't look like there are currently any packages in the maverick archive that depend on libpython2.7, so i don't think anybody is really linking against multiple python interpreteres
[02:18] <ebroder> *interpreters
[02:26] <onehundredthirty> wow, python2.7 is in maverick already. I didn't notice it (in Debian python2.7 is in experimental, so I forgot it). so, there is one more difference between Ubuntu and Debian regarding uWSGI package (I think about uwsgi-python2.7)
[02:26] <ebroder> onehundredthirty: yes, and python2.7 is the default in natty
[02:27] <micahg> you could use control.in to substitute 2.7 for 2.5
[02:27] <ebroder> micahg: yes, but such a package couldn't be synced
[02:27] <micahg> ebroder: why not?
[02:27] <micahg> dpkg-vendor generate control on build
[02:27] <ebroder> really? i thought that was strictly disallowed
[02:28] <micahg> ebroder: it might be :)
[02:28] <micahg> that's what I was asking before about generating control at buildtime
[02:28] <ebroder> micahg: see "CDBS" under http://ftp-master.debian.org/REJECT-FAQ.html
[02:29] <micahg> ebroder: that's build-depends, not the binary packages
[02:29] <ebroder> yeah, good point
[02:29] <ebroder> sorry. must be running short on caffeine
[02:30] <micahg> I read something about that earlier today, that's why it was on my mind
[02:31] <micahg> ebroder: also, if d/rules with dpkg-vendor is just doing a straight substitution, it'll be the same every time
[02:35] <onehundredthirty> micahg: but where in d/rules should I put invocation of dpkg-vendor and instantiating of d/control? in 'clean' target?
[02:36] <onehundredthirty> micahg: like recommended in http://raphaelhertzog.com/2010/09/27/different-dependencies-between-debian-and-ubuntu-but-common-source-package/#comment-3744
[02:36] <micahg> yes
[05:06] <stevecrozz> micahg: I've uploaded a uwsgi package to revu in attempt to close the needs packaging bug https://bugs.launchpad.net/ubuntu/+bug/704705
[05:07] <micahg> stevecrozz: BTW, I assume you saw the Debian packaging on mentors.debian.net and this is based on that?
[05:08] <stevecrozz> micahg: yes it is if you're talking about the thread from May, 2010
[05:15] <micahg> stevecrozz: I gave some initial feedback, I don't have time to run it through lintian and pbuilder ATM
[05:19] <stevecrozz> micahg: is there anything i need to do at this point?
[05:20] <micahg> stevecrozz: you could fix the things I mentioned (except the version, not sure about multiple uploads to revu w/the same version)
[05:21]  * micahg is going to get some sleep
[05:21] <stevecrozz> micahg: you mean about using the default python right?
[05:22] <micahg> stevecrozz: no, I commented on revu
[05:22] <stevecrozz> oh ok, thanks, have a nice night then :)
[05:22] <micahg> if it's still building a python 2.5 version, that will need to be fixed too
[05:23] <micahg> stevecrozz: if you ask here, someone should respond at some point, otherwise I will in the morning
[05:37] <Rcart> hello. i'm packaging an app that's complaining about info related documents. Can somebody take a look to the lintian and the doc/package.texi output please?
[08:33] <Rcart> hello
[08:33] <Rcart> i've 'debianized' a package that isn't in debian
[08:34] <Rcart> i'm thinking to  send it to debian and later request a sync from ubuntu
[08:35] <Rcart> any suggestions making this happen?
[08:41] <Bachstelze> Rcart: you need to get a sponsor to get it into debian
[08:47] <RAOF> billz: Yes, it is against debian policy.  You don't get to work around lintian by creating directories in postinst :)
[08:48] <RAOF> billz: You should create a directory in the appropriate FHS directories; if you need to patch the software to make this work, you need to patch the software.
[08:49] <billz> RAOF: thanks just checking :)
[08:50] <Rcart> Bachstelze: Thanks, i just need to correct one lintian check and the package will be clean
[08:52] <Rcart> This is the error: E: menumaker: package-contains-info-dir-file usr/share/info/dir.gz   someone has correct this error?
[08:59] <Bachstelze> Rcart: google on the tag wil give a description of what the problem is
[08:59] <Bachstelze> will*
[09:04] <billz> I need to create a folder "/var/run/myapp/" as part of my setup where should this be triggered? lintian complains if i add this to package.dirs
[09:06] <RAOF> billz: I believe that you should create that as a part of your init script, as I think /var/run is allowed to be a tmpfs.
[09:07] <RAOF> billz: And, as such, you can't expect any subdirectory of /var/run that you create at install time to still be there when the program gets run. :)
[09:10] <Rcart> Bachstelze: Thanks again.
[09:14] <MTecknology> !info nginx natty
[09:14] <MTecknology> :(
[09:15] <MTecknology> So... when is it too late to file a sync request for a package?
[09:15] <billz> RAOF: Looking at other applications like apache or asterisk i cant see them creating the init creating the folder in /var/run. so where do they do that?
[09:15] <tumbleweed> MTecknology: you can file them after freeze, but then you may need an FFe. We can sync all the way up to a week before release, but it gets harder to justify it
[09:16] <tumbleweed> "a week before release" being a vague hand-wavy number
[09:17] <MTecknology> tumbleweed: thanks! I was gunning for the end of the week; there's some icky packaging bugs that I'm trying to fix right now and once I fix them I want to get the package sync'ed asap. :)
[09:17] <MTecknology> but it's past 3am so I don't really know why i'm worrying about this tonight. :P
[09:20] <MTecknology> tumbleweed: I'm guessing upgrade issues are enough of a reason for a sync?
[09:24] <tumbleweed> MTecknology: use the same justification you would for an upload. Fixing a bug and probably not introducing a worse one is good (for most universe packages, just having someone look at the package is better than nothing)
[09:51] <RAOF> billz: I don't know about apache or asterisk, but http://www.debian.org/doc/debian-policy/ch-opersys.html#s-writing-init says ‘you can't rely on subdirectories of /var/run persisting, so do it in initscripts’.
[09:54] <soren> RAOF, billz: Not only is /var/run *allowed* to be a tmpfs. It's actually been a tmpfs in Ubuntu for years and years and years.
[09:54] <soren> And creating the directory in an init script is the right way to do it.
[09:57] <billz> RAOF, soren: Thanks
[10:00] <soren> Sure thing!
[11:06] <ari-tczew> hey
[11:06] <ari-tczew> how can I reply to this list? http://lists.debian.org/debian-mentors/2011/01/msg00318.html
[11:29] <ari-tczew> ScottK: ping
[11:46] <MTecknology> I'm noticing that the only thing left on my system that depends on python2.6 in 11.04 is bzr. Any chance that'll get rebuilt before natty is released?
[11:46] <tumbleweed> MTecknology: it's using python2.6 intentionally, it doesn't work with 2.7 yet
[11:47] <MTecknology> tumbleweed: sad- thanks
[11:48] <tumbleweed> MTecknology: that should be sorted soonish, I think
[11:50] <MTecknology> yay
[12:30] <ari-tczew> micahg: I considered full backport w3m from natty. I think it's better way. However, I'd like to push package to -proposed as SRU instead -backports.
[13:04] <Laney> sup tit
[14:02] <Laney> persia: You didn't leave very long for people to nominate
[14:04] <persia> Laney, in 13 hours, there will be 6 less DMB members :)  If we don't get enough nominations, we might send out another request.
[14:04] <Laney> well presumably the TB could have extended the terms by a week or so
[14:04] <Laney> but yes, I understand why it was :)
[14:04] <persia> I requested they extend them by a month, but that just covers the time I posted.
[14:04] <Laney> aOK
[14:05] <persia> With luck, we'll get eight or nine nominees, so we have a good field for selection.
[14:06] <ari-tczew> I'm not in the subject... what's going on with DMB?
[14:07] <Laney> see -devel
[14:09] <ari-tczew> Laney: could you point me to date and time?
[14:09] <Laney> Date: Wed, 19 Jan 2011 22:58:41 +0900
[14:11] <ari-tczew> Laney: maybe we are on another channel... #ubuntu-devel?
[14:11] <Laney> ari-tczew: no, the mailing list :)
[14:12] <ari-tczew> Laney: coulnd't you say that firstly?
[14:13] <Laney> it's not a big deal
[14:14] <ari-tczew> https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2011-January/date.html
[14:14] <ari-tczew> which one?
[14:14] <Laney> devel not devel-discuss
[14:18] <ari-tczew> nice, now only bdrung is DMB
[14:37] <cdbs> geser: The DMB ML doesn't send 'your mail has bounced' messages?
[14:39] <cdbs> geser: un-ping, I guessed it doesn't
[14:48] <Laney> it accepts mails from non-subscribers
[14:58] <ScottK> ari-tczew: Pong
[15:36] <ari-tczew> ScottK: Case: w3m package. I would like to backport package from natty, but push it through -proposed instead -backports. There is no new upstream release. What do you think?
[15:37] <Rhonda> There wasn't a new upstream release for w3m in ages? :)
[15:38] <Rhonda> ari-tczew: Actually "debian/patches/010_upstream.patch: Sync with the upstream development snapshot on 2010-10-11" sounds like a "hidden" new upstream release to me.
[15:39] <Rhonda> "55 files changed, 32850 insertions(+), 8407 deletions(-)" is the diffstats of that patch
[15:40] <Laney> that's an interesting way of upgrading to a new release
[15:40] <ari-tczew> Rhonda: mhm, then rather backport. But why cannot through -proposed => -updates? Not everyone has enabled -backports.
[15:40] <Laney> because that is not the purpose of a stable release update
[15:42] <Rhonda> Because -proposed → -updates is for SRU which are limited to important bugfixes and security updates.
[15:42] <ari-tczew> nonix4: would you like to have a full w3m from natty on lucid and maverick?
[15:43] <Rhonda> I consider it unlikely that you'll be able to get this w3m diff in for SRU when I wasn't able to get in a stable wesnoth update in. ;)
[15:43] <Laney> you weren't? There's precedent for new bugfix releases
[15:44] <Laney> eg banshee
[15:44] <directhex> chromium-browser?
[15:44] <Laney> docky
[15:44] <Laney> :-)
[15:45] <Rhonda> Laney: I think it was blocked on the grounds that I would have needed to strip down the changes a fair bit, I think even translation updates would had been blocked
[15:45] <Laney> I think they usually like a stripped down diff for review, but you can upload the full new release
[15:46] <Rhonda> I just know that it was too much effort for me to pick up at that time, and given that my sponsoring funds for this work isn't really taking off I have to priorize my efforts.
[15:47] <directhex> Rhonda, how are you trying to fundraise? i've had some experience on that
[15:48] <Rhonda> directhex: Tell people that I can hand them my amazon/paypal/flattr links in case they want me to do something specific. :)
[15:49] <Rhonda> Otherwise they have to live with how I priorize and schedule my time on my own.
[15:49] <directhex> ah. "packager for hire!"
[15:49] <Rhonda> Actually qcake is the only package that was ever "funded".  Upstream approached me, I told them that I don't have a 3d card to properly test it, and got one through that.
[15:51] <directhex> the badgerports model has been suspiciously successful for me, but perhaps mono folks just have loads of microsoft bribes to spend
[15:53] <ScottK> ari-tczew: You'd need to talk to someone in ubuntu-sru about that.
[15:55] <ari-tczew> ScottK: what do you think about merge ubuntu-sru and ubuntu-backports into one team? Members could decide which one is better way.
[15:55] <ScottK> ari-tczew: No.  I think the processes and intent of updates/backports are sufficiently different that it wouldn't be helpful.
[15:57] <ari-tczew> well, I wanted to improve workflow.
[16:01] <micahg> also, ubuntu-sru is basically pitti at this point
[16:02] <ari-tczew> micahg: I consider join to ubuntu-sru in next months.
[19:04] <kamal> I've got a LP merge proposal that I want to mark as "no longer proposed" -- must I actually delete the proposal (and so lose its comment history) or is there another way to mark it so?
[19:05] <kamal> https://code.launchpad.net/~kamalmostafa/ubuntu/natty/alarm-clock-applet/lp704659/+merge/46705
[23:01] <bdrung> tumbleweed: i finally reviewed syncpackage. here are the things i found: http://paste.debian.net/105100/
[23:07] <tumbleweed> bdrung: line 3: What's the issue? debdiff? It returns 0 or 1 depending on whether there was a diff or not
[23:08] <tumbleweed> bdrung: line 208-209: that's the only sane indentation, otherwise it's at the same level as the block inside the if
[23:11] <bdrung> tumbleweed: line 3: you should use subprocess.call and evaluate the result instead of using check_call
[23:11] <tumbleweed> bdrung: re url argument, I prefer it to be clear what the argument is, even if it isn't used
[23:11] <bdrung> hm, ok
[23:12] <tumbleweed> what's wrong with using check_call?
[23:12] <tumbleweed> do we want to print an error instead of a stacktrace?
[23:12] <bdrung> yes
[23:12] <tumbleweed> fair enough
[23:13] <Rcart> Hello. bittornado (bug #420387) seems to have dpatch system in debian/patches/,  but what-patch returns quilt system. How can i apply patches to this "thing" ?
[23:13] <bdrung> the user should know what went wrong and how he may fix it instead of thinking "the program crashed -> bug"
[23:13] <ebroder> Rcart: does it have a debian/patches/series file, or a debian/patches/00list file?
[23:14] <tumbleweed> bdrung: agreed (that's why we have so many apport-filed requestsync bugs IIRC)
[23:14] <Rcart> ebroder: series file.
[23:15] <ebroder> Rcart: then it uses quilt. they probably switched from dpatch to quilt and were too lazy to rename files
[23:16] <tumbleweed> bdrung: r893 pushed
[23:17] <Rcart> ebroder: do i need to follow the enumerated sequence?
[23:17] <ebroder> Rcart: i'm not sure i understand the question. debian/patches/series contains the order in which patches are applied. any ordering in the filenames is incidental
[23:18] <bdrung> tumbleweed: indentation: http://pastebin.com/K8ktDeLE
[23:19] <tumbleweed> bdrung: I don't like that, it's ambiguous with the block inside the if. I double-indent to avoid it if I can't naturally align it somewhere far away
[23:21] <bdrung> tumbleweed: then do something like that: http://pastebin.com/VpiRcGNQ
[23:23] <Rcart> broder: sorry, i meant if i should rename the new patch with the same sequence as they are in the debian/patches directory. i.e 09_timtuckerfixes.dpatch
[23:24] <Rcart> *ebroder:
[23:24] <ebroder> Rcart: i'd try to file whatever style was used for the other patches
[23:24] <ebroder> *follow
[23:25] <Rcart> ebroder: Great. Thanks a lot.
[23:29] <tumbleweed> bdrung: done
[23:42] <bdrung> tumbleweed: merged
[23:43] <tumbleweed> bdrung: thanks
[23:43] <tumbleweed> now I must finish that other branch...
[23:43] <bdrung> tumbleweed: no
[23:43] <tumbleweed> hmm?
[23:44] <bdrung> tumbleweed: i have a solution that goes into a slightly different direction.
[23:45] <bdrung> tumbleweed: it's ~ a year old and called release-info. i am going to include that script into u-d-t, which you can use in your branch then.
[23:45] <bdrung> tumbleweed: i haven't decided yet if i rename release-info to distro-info or series-info.
[23:45] <tumbleweed> bdrung: that sounds useful, thanks
[23:46] <bdrung> tumbleweed: which name do you prefer?
[23:46] <micahg> bdrung: did you find someone to rewrite in perl or is that still pending?
[23:47] <tumbleweed> bdrung: depends on exactly what it does. I need something like "known-suites"
[23:47] <bdrung> micahg: it's still pending.
[23:47] <bdrung> tumbleweed: it does that: http://git.debian.org/?p=collab-maint/release-info.git;a=summary
[23:47] <micahg> bdrung: ok, it's on my list at some point, don't know when though
[23:48] <bdrung> micahg: once it's rewritten it perl and accepted in devscripts, only the data and the scripts will go, but the python object will stay.
[23:51] <tumbleweed> bdrung: ok, I guess I'd better redo the rest of that builders branch without that bit then. This sounds like it'll take a while to be a usable option.
[23:51] <bdrung> tumbleweed: take a while?
[23:52] <tumbleweed> bdrung: port to perl, get into devscripts, get that devscripts into Ubuntu.
[23:52] <tumbleweed> bdrung: also means we have a versioned depends on devscripts, which makes backporting harder
[23:52] <bdrung> tumbleweed: that's the long term, but until then there will be a complete python solution in u-d-t (python object, data files, and scripts)
[23:52] <tumbleweed> OTOH, the code is pretty simple, shouldn't be hard to port to perl
[23:53] <tumbleweed> I'm tempted to say put the data files in /etc, then we don't need to backport u-d-t just to update release names, users can do that themselves
[23:54] <bdrung> tumbleweed: no. either support two places (one system and one in /etc) or do SRUs for updates
[23:55] <tumbleweed> two places works for me
[23:56] <bdrung> tumbleweed: should i release the current version of u-d-t or wait for more changes?
[23:57] <tumbleweed> might as well release the current version, I don't think anything is currently broken
[23:59] <bdrung> tumbleweed: k, will do it tomorrow
[23:59] <bdrung> tumbleweed: should we drop pbuilder-dist-simple?