[00:50] 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] onehundredthirty: what's the issue? [00:51] Some binary package of Debian uWSGI package is depends from python2.5 but it's support was officialy dropped since Lucid [00:52] onehundredthirty: that can be handled with control.in [00:53] Is it common practice? Are there packages with control.in which I could look into for example? [00:53] openjdk is the craziest example I can think of, I'm sure there are more sane ones [00:53] wait, why do you need a control.in for that? [00:53] ebroder: different binaty depends? [00:53] *binary [00:53] just build-dep on python and dep on ${python:Depends} and properly apply the python policy [00:54] hmm, yeah, that would work too :) [00:55] onehundredthirty: is that the only issue? [00:56] Could you look into my debian/control http://paste.ubuntu.com/555606/ and say is ${python:Depends} is the soultion? [00:57] Yes, modifying of debian/control in process of building is only issue [00:58] onehundredthirty: this is new package? [00:58] I'll try to download source package for openjdk now and take a look into it's debian/control [00:58] 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] onehundredthirty: openjdk won't help here I don't think [00:59] Yes, this is new package, It has an ITP bug in Debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582864 [01:00] ebroder: there's a problem with generating d/control at runtime or just the build-depends? [01:01] Just dropping 'uwsgi-python2.5' will break 'uwsgi' (as it depends on uwsgi-python2.5) [01:01] Yes, I need to generate whole debian/control in runtime [01:01] onehundredthirty: no, it looks like it's an OR, so it won't break [01:02] onehundredthirty: is there a particularly compelling reason to build it for more than just the default python version? [01:03] 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] right, but i don't think any of the other wsgi servers are packaged like that [01:04] i think they're only built to run against the default python [01:08] 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] oh, no. there is libapache2-mod-wsgi-py3 also [01:42] 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] yes, the debian ftpmasters would reject that [01:51] onehundredthirty: why not do one package that's whatever current python2 is, and one package that's whatever current python3 is? [01:51] (the debian/ubuntu python infrastructure basically considers py2 and py3 to be different languages, as well it should) [02:02] 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] bdrung: http://paste.ubuntu.com/555614/ [02:14] 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] you could use that to only build against a particular python version if that version was available [02:15] 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] 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] 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] *interpreters [02:26] 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] onehundredthirty: yes, and python2.7 is the default in natty [02:27] you could use control.in to substitute 2.7 for 2.5 [02:27] micahg: yes, but such a package couldn't be synced [02:27] ebroder: why not? [02:27] dpkg-vendor generate control on build [02:27] really? i thought that was strictly disallowed [02:28] ebroder: it might be :) [02:28] that's what I was asking before about generating control at buildtime [02:28] micahg: see "CDBS" under http://ftp-master.debian.org/REJECT-FAQ.html [02:29] ebroder: that's build-depends, not the binary packages [02:29] yeah, good point [02:29] sorry. must be running short on caffeine [02:30] I read something about that earlier today, that's why it was on my mind [02:31] ebroder: also, if d/rules with dpkg-vendor is just doing a straight substitution, it'll be the same every time [02:35] micahg: but where in d/rules should I put invocation of dpkg-vendor and instantiating of d/control? in 'clean' target? [02:36] micahg: like recommended in http://raphaelhertzog.com/2010/09/27/different-dependencies-between-debian-and-ubuntu-but-common-source-package/#comment-3744 [02:36] yes [05:06] 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:06] Ubuntu bug 704705 in Ubuntu "[needs-packaging] uwsgi" [Wishlist,Fix committed] [05:07] stevecrozz: BTW, I assume you saw the Debian packaging on mentors.debian.net and this is based on that? [05:08] micahg: yes it is if you're talking about the thread from May, 2010 [05:15] stevecrozz: I gave some initial feedback, I don't have time to run it through lintian and pbuilder ATM [05:19] micahg: is there anything i need to do at this point? [05:20] 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] micahg: you mean about using the default python right? [05:22] stevecrozz: no, I commented on revu [05:22] oh ok, thanks, have a nice night then :) [05:22] if it's still building a python 2.5 version, that will need to be fixed too [05:23] stevecrozz: if you ask here, someone should respond at some point, otherwise I will in the morning [05:37] 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? === temugen is now known as Guest85790 === ara is now known as Guest34458 [08:33] hello [08:33] i've 'debianized' a package that isn't in debian [08:34] i'm thinking to send it to debian and later request a sync from ubuntu === Guest34458 is now known as ara [08:35] any suggestions making this happen? [08:41] Rcart: you need to get a sponsor to get it into debian [08:47] billz: Yes, it is against debian policy. You don't get to work around lintian by creating directories in postinst :) [08:48] 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] RAOF: thanks just checking :) [08:50] Bachstelze: Thanks, i just need to correct one lintian check and the package will be clean [08:52] This is the error: E: menumaker: package-contains-info-dir-file usr/share/info/dir.gz someone has correct this error? [08:59] Rcart: google on the tag wil give a description of what the problem is [08:59] will* [09:04] 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] 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] 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] Bachstelze: Thanks again. [09:14] !info nginx natty [09:14] nginx (source: nginx): small, but very powerful and efficient web server and mail proxy. In component universe, is optional. Version 0.8.53-2 (natty), package size 327 kB, installed size 900 kB [09:14] :( [09:15] So... when is it too late to file a sync request for a package? [09:15] 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] 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] "a week before release" being a vague hand-wavy number [09:17] 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] but it's past 3am so I don't really know why i'm worrying about this tonight. :P [09:20] tumbleweed: I'm guessing upgrade issues are enough of a reason for a sync? [09:24] 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) === al-maisan is now known as almaisan-away [09:51] 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] 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] And creating the directory in an init script is the right way to do it. [09:57] RAOF, soren: Thanks [10:00] Sure thing! [11:06] hey [11:06] how can I reply to this list? http://lists.debian.org/debian-mentors/2011/01/msg00318.html [11:29] ScottK: ping [11:46] 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] MTecknology: it's using python2.6 intentionally, it doesn't work with 2.7 yet [11:47] tumbleweed: sad- thanks [11:48] MTecknology: that should be sorted soonish, I think [11:50] yay [12:30] 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] sup tit [14:02] persia: You didn't leave very long for people to nominate [14:04] 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] well presumably the TB could have extended the terms by a week or so [14:04] but yes, I understand why it was :) [14:04] I requested they extend them by a month, but that just covers the time I posted. [14:04] aOK [14:05] With luck, we'll get eight or nine nominees, so we have a good field for selection. [14:06] I'm not in the subject... what's going on with DMB? [14:07] see -devel [14:09] Laney: could you point me to date and time? [14:09] Date: Wed, 19 Jan 2011 22:58:41 +0900 [14:11] Laney: maybe we are on another channel... #ubuntu-devel? [14:11] ari-tczew: no, the mailing list :) [14:12] Laney: coulnd't you say that firstly? [14:13] it's not a big deal [14:14] https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2011-January/date.html [14:14] which one? [14:14] devel not devel-discuss [14:18] nice, now only bdrung is DMB [14:37] geser: The DMB ML doesn't send 'your mail has bounced' messages? [14:39] geser: un-ping, I guessed it doesn't [14:48] it accepts mails from non-subscribers [14:58] ari-tczew: Pong [15:36] 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] There wasn't a new upstream release for w3m in ages? :) [15:38] 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] "55 files changed, 32850 insertions(+), 8407 deletions(-)" is the diffstats of that patch [15:40] that's an interesting way of upgrading to a new release [15:40] Rhonda: mhm, then rather backport. But why cannot through -proposed => -updates? Not everyone has enabled -backports. [15:40] because that is not the purpose of a stable release update [15:42] Because -proposed → -updates is for SRU which are limited to important bugfixes and security updates. [15:42] nonix4: would you like to have a full w3m from natty on lucid and maverick? [15:43] 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] you weren't? There's precedent for new bugfix releases [15:44] eg banshee [15:44] chromium-browser? [15:44] docky [15:44] :-) [15:45] 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] I think they usually like a stripped down diff for review, but you can upload the full new release [15:46] 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] Rhonda, how are you trying to fundraise? i've had some experience on that [15:48] directhex: Tell people that I can hand them my amazon/paypal/flattr links in case they want me to do something specific. :) [15:49] Otherwise they have to live with how I priorize and schedule my time on my own. [15:49] ah. "packager for hire!" [15:49] 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] the badgerports model has been suspiciously successful for me, but perhaps mono folks just have loads of microsoft bribes to spend [15:53] ari-tczew: You'd need to talk to someone in ubuntu-sru about that. [15:55] 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] ari-tczew: No. I think the processes and intent of updates/backports are sufficiently different that it wouldn't be helpful. [15:57] well, I wanted to improve workflow. [16:01] also, ubuntu-sru is basically pitti at this point [16:02] micahg: I consider join to ubuntu-sru in next months. === RoAkSoAx is now known as andreserls === andreserl is now known as RoAkSoAx === andreserls is now known as andreserl === _ruben_ is now known as _ruben === apachelogger is now known as releaselogger === bilalakhtar_ is now known as cdbs [19:04] 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] https://code.launchpad.net/~kamalmostafa/ubuntu/natty/alarm-clock-applet/lp704659/+merge/46705 === stalcup is now known as v === bilalakhtar_ is now known as cdbs [23:01] tumbleweed: i finally reviewed syncpackage. here are the things i found: http://paste.debian.net/105100/ [23:07] bdrung: line 3: What's the issue? debdiff? It returns 0 or 1 depending on whether there was a diff or not [23:08] 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] tumbleweed: line 3: you should use subprocess.call and evaluate the result instead of using check_call [23:11] bdrung: re url argument, I prefer it to be clear what the argument is, even if it isn't used [23:11] hm, ok [23:12] what's wrong with using check_call? [23:12] do we want to print an error instead of a stacktrace? [23:12] yes [23:12] fair enough [23:13] 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] Launchpad bug 420387 in bittornado (Ubuntu) "[PATCH] DeprecationWarning: the sha module is deprecated; use the hashlib module instead" [Undecided,New] https://launchpad.net/bugs/420387 [23:13] the user should know what went wrong and how he may fix it instead of thinking "the program crashed -> bug" [23:13] Rcart: does it have a debian/patches/series file, or a debian/patches/00list file? [23:14] bdrung: agreed (that's why we have so many apport-filed requestsync bugs IIRC) [23:14] ebroder: series file. [23:15] Rcart: then it uses quilt. they probably switched from dpatch to quilt and were too lazy to rename files [23:16] bdrung: r893 pushed [23:17] ebroder: do i need to follow the enumerated sequence? [23:17] 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] tumbleweed: indentation: http://pastebin.com/K8ktDeLE [23:19] 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] tumbleweed: then do something like that: http://pastebin.com/VpiRcGNQ [23:23] 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] *ebroder: [23:24] Rcart: i'd try to file whatever style was used for the other patches [23:24] *follow [23:25] ebroder: Great. Thanks a lot. [23:29] bdrung: done [23:42] tumbleweed: merged [23:43] bdrung: thanks [23:43] now I must finish that other branch... [23:43] tumbleweed: no [23:43] hmm? [23:44] tumbleweed: i have a solution that goes into a slightly different direction. [23:45] 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] tumbleweed: i haven't decided yet if i rename release-info to distro-info or series-info. [23:45] bdrung: that sounds useful, thanks [23:46] tumbleweed: which name do you prefer? [23:46] bdrung: did you find someone to rewrite in perl or is that still pending? [23:47] bdrung: depends on exactly what it does. I need something like "known-suites" [23:47] micahg: it's still pending. [23:47] tumbleweed: it does that: http://git.debian.org/?p=collab-maint/release-info.git;a=summary [23:47] bdrung: ok, it's on my list at some point, don't know when though [23:48] 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. === nhandler is now known as Guest64928 [23:51] 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] tumbleweed: take a while? [23:52] bdrung: port to perl, get into devscripts, get that devscripts into Ubuntu. [23:52] bdrung: also means we have a versioned depends on devscripts, which makes backporting harder [23:52] 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] OTOH, the code is pretty simple, shouldn't be hard to port to perl [23:53] 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] tumbleweed: no. either support two places (one system and one in /etc) or do SRUs for updates [23:55] two places works for me === nhandler_ is now known as nhandler [23:56] tumbleweed: should i release the current version of u-d-t or wait for more changes? [23:57] might as well release the current version, I don't think anything is currently broken [23:59] tumbleweed: k, will do it tomorrow [23:59] tumbleweed: should we drop pbuilder-dist-simple?