| 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:50 |
|---|---|---|
| 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:51 |
| micahg | onehundredthirty: that can be handled with control.in | 00:52 |
| 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:53 |
| micahg | hmm, yeah, that would work too :) | 00:54 |
| micahg | onehundredthirty: is that the only issue? | 00:55 |
| onehundredthirty | Could you look into my debian/control http://paste.ubuntu.com/555606/ and say is ${python:Depends} is the soultion? | 00:56 |
| onehundredthirty | Yes, modifying of debian/control in process of building is only issue | 00:57 |
| 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:58 |
| 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 | 00:59 |
| micahg | ebroder: there's a problem with generating d/control at runtime or just the build-depends? | 01:00 |
| 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:01 |
| ebroder | onehundredthirty: is there a particularly compelling reason to build it for more than just the default python version? | 01:02 |
| 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:03 |
| 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:04 |
| 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:08 |
| onehundredthirty | oh, no. there is libapache2-mod-wsgi-py3 also | 01:10 |
| 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:42 |
| ebroder | yes, the debian ftpmasters would reject that | 01:50 |
| 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) | 01:51 |
| 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:02 |
| ari-tczew | bdrung: http://paste.ubuntu.com/555614/ | 02:08 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:18 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| micahg | I read something about that earlier today, that's why it was on my mind | 02:30 |
| micahg | ebroder: also, if d/rules with dpkg-vendor is just doing a straight substitution, it'll be the same every time | 02:31 |
| onehundredthirty | micahg: but where in d/rules should I put invocation of dpkg-vendor and instantiating of d/control? in 'clean' target? | 02:35 |
| 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 | 02:36 |
| 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:06 |
| ubottu | Ubuntu bug 704705 in Ubuntu "[needs-packaging] uwsgi" [Wishlist,Fix committed] | 05:06 |
| micahg | stevecrozz: BTW, I assume you saw the Debian packaging on mentors.debian.net and this is based on that? | 05:07 |
| stevecrozz | micahg: yes it is if you're talking about the thread from May, 2010 | 05:08 |
| micahg | stevecrozz: I gave some initial feedback, I don't have time to run it through lintian and pbuilder ATM | 05:15 |
| stevecrozz | micahg: is there anything i need to do at this point? | 05:19 |
| micahg | stevecrozz: you could fix the things I mentioned (except the version, not sure about multiple uploads to revu w/the same version) | 05:20 |
| * micahg is going to get some sleep | 05:21 | |
| stevecrozz | micahg: you mean about using the default python right? | 05:21 |
| 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:22 |
| micahg | stevecrozz: if you ask here, someone should respond at some point, otherwise I will in the morning | 05:23 |
| 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? | 05:37 |
| === temugen is now known as Guest85790 | ||
| === ara is now known as Guest34458 | ||
| Rcart | hello | 08:33 |
| Rcart | i've 'debianized' a package that isn't in debian | 08:33 |
| Rcart | i'm thinking to send it to debian and later request a sync from ubuntu | 08:34 |
| === Guest34458 is now known as ara | ||
| Rcart | any suggestions making this happen? | 08:35 |
| Bachstelze | Rcart: you need to get a sponsor to get it into debian | 08:41 |
| RAOF | billz: Yes, it is against debian policy. You don't get to work around lintian by creating directories in postinst :) | 08:47 |
| 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:48 |
| billz | RAOF: thanks just checking :) | 08:49 |
| Rcart | Bachstelze: Thanks, i just need to correct one lintian check and the package will be clean | 08:50 |
| Rcart | This is the error: E: menumaker: package-contains-info-dir-file usr/share/info/dir.gz someone has correct this error? | 08:52 |
| Bachstelze | Rcart: google on the tag wil give a description of what the problem is | 08:59 |
| Bachstelze | will* | 08:59 |
| 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:04 |
| 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:06 |
| 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:07 |
| Rcart | Bachstelze: Thanks again. | 09:10 |
| MTecknology | !info nginx natty | 09:14 |
| ubottu | 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 |
| MTecknology | :( | 09:14 |
| 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:15 |
| tumbleweed | "a week before release" being a vague hand-wavy number | 09:16 |
| 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:17 |
| MTecknology | tumbleweed: I'm guessing upgrade issues are enough of a reason for a sync? | 09:20 |
| 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:24 |
| === al-maisan is now known as almaisan-away | ||
| 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:51 |
| 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:54 |
| billz | RAOF, soren: Thanks | 09:57 |
| soren | Sure thing! | 10:00 |
| 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:06 |
| ari-tczew | ScottK: ping | 11:29 |
| 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:46 |
| MTecknology | tumbleweed: sad- thanks | 11:47 |
| tumbleweed | MTecknology: that should be sorted soonish, I think | 11:48 |
| MTecknology | yay | 11:50 |
| 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. | 12:30 |
| Laney | sup tit | 13:04 |
| Laney | persia: You didn't leave very long for people to nominate | 14:02 |
| 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:04 |
| persia | With luck, we'll get eight or nine nominees, so we have a good field for selection. | 14:05 |
| ari-tczew | I'm not in the subject... what's going on with DMB? | 14:06 |
| Laney | see -devel | 14:07 |
| ari-tczew | Laney: could you point me to date and time? | 14:09 |
| Laney | Date: Wed, 19 Jan 2011 22:58:41 +0900 | 14:09 |
| ari-tczew | Laney: maybe we are on another channel... #ubuntu-devel? | 14:11 |
| Laney | ari-tczew: no, the mailing list :) | 14:11 |
| ari-tczew | Laney: coulnd't you say that firstly? | 14:12 |
| Laney | it's not a big deal | 14:13 |
| 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:14 |
| ari-tczew | nice, now only bdrung is DMB | 14:18 |
| cdbs | geser: The DMB ML doesn't send 'your mail has bounced' messages? | 14:37 |
| cdbs | geser: un-ping, I guessed it doesn't | 14:39 |
| Laney | it accepts mails from non-subscribers | 14:48 |
| ScottK | ari-tczew: Pong | 14:58 |
| 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:36 |
| Rhonda | There wasn't a new upstream release for w3m in ages? :) | 15:37 |
| 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:38 |
| Rhonda | "55 files changed, 32850 insertions(+), 8407 deletions(-)" is the diffstats of that patch | 15:39 |
| 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:40 |
| 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:42 |
| 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:43 |
| Laney | eg banshee | 15:44 |
| directhex | chromium-browser? | 15:44 |
| Laney | docky | 15:44 |
| Laney | :-) | 15:44 |
| 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:45 |
| 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:46 |
| directhex | Rhonda, how are you trying to fundraise? i've had some experience on that | 15:47 |
| Rhonda | directhex: Tell people that I can hand them my amazon/paypal/flattr links in case they want me to do something specific. :) | 15:48 |
| 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:49 |
| directhex | the badgerports model has been suspiciously successful for me, but perhaps mono folks just have loads of microsoft bribes to spend | 15:51 |
| ScottK | ari-tczew: You'd need to talk to someone in ubuntu-sru about that. | 15:53 |
| 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:55 |
| ari-tczew | well, I wanted to improve workflow. | 15:57 |
| micahg | also, ubuntu-sru is basically pitti at this point | 16:01 |
| ari-tczew | micahg: I consider join to ubuntu-sru in next months. | 16:02 |
| === 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 | ||
| 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:04 |
| kamal | https://code.launchpad.net/~kamalmostafa/ubuntu/natty/alarm-clock-applet/lp704659/+merge/46705 | 19:05 |
| === stalcup is now known as v | ||
| === bilalakhtar_ is now known as cdbs | ||
| bdrung | tumbleweed: i finally reviewed syncpackage. here are the things i found: http://paste.debian.net/105100/ | 23:01 |
| tumbleweed | bdrung: line 3: What's the issue? debdiff? It returns 0 or 1 depending on whether there was a diff or not | 23:07 |
| 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:08 |
| 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:11 |
| 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:12 |
| 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 |
| ubottu | 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 |
| 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:13 |
| tumbleweed | bdrung: agreed (that's why we have so many apport-filed requestsync bugs IIRC) | 23:14 |
| Rcart | ebroder: series file. | 23:14 |
| ebroder | Rcart: then it uses quilt. they probably switched from dpatch to quilt and were too lazy to rename files | 23:15 |
| tumbleweed | bdrung: r893 pushed | 23:16 |
| 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:17 |
| bdrung | tumbleweed: indentation: http://pastebin.com/K8ktDeLE | 23:18 |
| 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:19 |
| bdrung | tumbleweed: then do something like that: http://pastebin.com/VpiRcGNQ | 23:21 |
| 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:23 |
| Rcart | *ebroder: | 23:24 |
| ebroder | Rcart: i'd try to file whatever style was used for the other patches | 23:24 |
| ebroder | *follow | 23:24 |
| Rcart | ebroder: Great. Thanks a lot. | 23:25 |
| tumbleweed | bdrung: done | 23:29 |
| bdrung | tumbleweed: merged | 23:42 |
| tumbleweed | bdrung: thanks | 23:43 |
| tumbleweed | now I must finish that other branch... | 23:43 |
| bdrung | tumbleweed: no | 23:43 |
| tumbleweed | hmm? | 23:43 |
| bdrung | tumbleweed: i have a solution that goes into a slightly different direction. | 23:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| === nhandler is now known as Guest64928 | ||
| 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:51 |
| 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:52 |
| 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:53 |
| bdrung | tumbleweed: no. either support two places (one system and one in /etc) or do SRUs for updates | 23:54 |
| tumbleweed | two places works for me | 23:55 |
| === nhandler_ is now known as nhandler | ||
| bdrung | tumbleweed: should i release the current version of u-d-t or wait for more changes? | 23:56 |
| tumbleweed | might as well release the current version, I don't think anything is currently broken | 23:57 |
| bdrung | tumbleweed: k, will do it tomorrow | 23:59 |
| bdrung | tumbleweed: should we drop pbuilder-dist-simple? | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!