=== nixternal_ is now known as nixternal
=== apachelogger is now known as fdsafdsafdsafdsa
=== fdsafdsafdsafdsa is now known as darthlulu
=== darthlulu is now known as apachelogger
[05:27] <kaushal> hi
[05:28] <kaushal> when would Openoffice 3.3 will be ported to 10.10 ?
[05:36] <RAOF> To 10.10?  I'd guess it won't be; it's pretty big and serious.
[05:37] <micahg> kaushal: there's a PPA for backports, https://launchpad.net/~openoffice-pkgs/+archive/ppa, no guarantee on when
[05:37] <RAOF> Once it (or LibreOffice) is in Natty it might get backported.
[05:37] <micahg> or if for that matter
[05:40] <kaushal> ok
[07:31] <kunal> hello
=== jussi01_ is now known as jussi
[08:40] <udienz> bug 692457
[08:40] <ubottu> Launchpad bug 692457 in bash (Ubuntu) "Please merge bash 4.1-3 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/692457
[09:12] <geser> udienz: why bumping the Standards-Version?
[09:14] <udienz> geser: as far as i know, debian-policy is 3.9.1
[09:14] <Rhonda> udienz: Yes, but it's an unneeded change
[09:14] <Rhonda> Keeping diffs to a minimum helps future merges
[09:15] <Rhonda> What does "enhached" mean?
[09:15] <udienz> Rhonda: but someone ask me to write it at changelog
[09:16] <udienz> Rhonda: i mean enhanced
[09:16] <geser> udienz: we usually don't bump the Standads-Version as it's a "useless" change (it gives us no benefit, only a larger delta)
[09:16] <Rhonda> udienz: If you change something, of course it has to be written in the changelog. But the thing is, you didn't need to bump the standards-version in the first place.
[09:17] <Rhonda> There is no need at all to change the Standards-Version in a package coming from Debian.
[09:19] <udienz> geser, Rhonda: okay i change it now
[09:19]  * Rhonda . o O ( it's interesting that a package maintained by a canonical person within Debian would actually need a merge instead of a simple sync … )
[09:20] <udienz> :)
=== bigon__ is now known as bigon
[11:02] <bdrung> tumbleweed: will we loose python 2.5 compatibility with the u-d-t change?
[11:03] <tumbleweed> bdrung: no, dh_python2 arrived during default python = 2.6, supported pythons = 2.5 + 2.6 in debian
[11:04] <bdrung> tumbleweed: where can i read more about dh_python2?
[11:05] <tumbleweed> POX's brain / the source code. It has a basic manpage too
[11:06] <tumbleweed> I guess the best palce to read about it is the debian-python list archive
[11:06] <bdrung> tumbleweed: isn't there a policy document describing what you have to write into d/control, etc.?
[11:07] <tumbleweed> yes, in the python package. IIRC it has some cobwebs, though.
[11:08] <tumbleweed> it still says you should have XB-Python-Version, which has been deprecated
[11:09] <bdrung> tumbleweed: debian has python-all (2.6.6-3+squeeze4) in unstable
[11:10] <tumbleweed> whoops, 2.6.5-13
[11:12] <bdrung> tumbleweed: should we use ${python:Versions}?
[11:13] <bdrung> tumbleweed: can we use setup.py for creating symlinks and installing the bash completion to get rid of d/links d/*.install d/*.examples?
[11:15] <tumbleweed> bdrung: re python:Versions (XB-P-V) the deperecation is discussed here: http://lists.debian.org/debian-release/2010/06/msg00211.html
[11:15] <tumbleweed> re setup.py: yes, should be able to
[11:16] <tumbleweed> although I'd say it's arguably more correct to install manpages, bash_completion, and examples via debhelper helpers
[11:25] <udienz> Hi, i want to ask about patch. Upstream have a patch, but a patch not yet apllied at debian. can i submit a patch to ubuntu?
[11:26] <tumbleweed> if there's a good reason for ubuntu to have this patch. If we can wait for it to filter down, why not wait.
[11:26] <geser> udienz: yes
[11:27] <udienz> ok thanks
[11:27] <geser> udienz: and document it properly in the debian/changelog. it will make is easier during merging later to decide that we can drop the patch (when it got included in the new upstream release or Debian package revision)
[11:28] <tumbleweed> while we are on that topic, if the package has a patch system, please put headers on the patch http://dep.debian.net/deps/dep3/ so people can see where it came from
[11:31] <udienz> tumbleweed: linke this? http://launchpadlibrarian.net/60875721/fix-one_addr.patch
[11:31] <udienz> *like
[11:33] <tumbleweed> udienz: that's not quite compliant ("Bug URL"), but it's better than nothing. One really wants to know if the patch came from upstream or debian, and if its been applied upstream.
[11:33] <tumbleweed> err, "upstream or ubuntu"
[11:45] <udienz> tumbleweed: hm.. so a patch become like this? http://paste.ubuntu.com/545918/
[11:48] <tumbleweed> udienz: yes, that's the way to make the next person to touch that package love you
[11:48] <udienz> tumbleweed: :) thanks, i'm working at nginx for lucid now
[11:49] <udienz> rr... lucid-proposed
[12:57] <TeTeT> hi, there's a potential buffer overflow in opensc in universe. I took the upstream patches and applied them to Ubuntu Lucid, Maverick and Natty, see bug 692483 for details. What is the next step? Asking for sponsorship?
[12:57] <ubottu> Launchpad bug 692483 in opensc (Ubuntu) "Buffer overflow" [Undecided,New] https://launchpad.net/bugs/692483
[13:00] <Bachstelze> TeTeT: subscribe ubuntu-sponsor
[13:01] <geser> TeTeT: yes, you might also try to talk someone from the security team (and read the wiki page about SRUs)
[13:02] <tumbleweed> bdrung: re dh_python2, before I forget. POX gave a talk at debconf on it, and those slides are probably the best current documentation.
[13:02] <TeTeT> geser: isn't an SRU only for main?
[13:02] <Laney> no
[13:02] <TeTeT> thanks
[13:22] <geser> mdeslaur: would bug 692483 qualify for a -security upload?
[13:22] <ubottu> Launchpad bug 692483 in opensc (Ubuntu) "Buffer overflow" [Undecided,New] https://launchpad.net/bugs/692483
[13:23] <bdrung> tumbleweed: do you have a link to those slides?
[13:24] <mdeslaur> geser: sure
[13:24] <mdeslaur> geser: follow the procedures here: https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures
[13:24] <geser> TeTeT: ^^
[13:25] <tumbleweed> bdrung: http://penta.debconf.org/dc10_schedule/events/570.en.html
[13:25] <tumbleweed> (predates X-P-V, though)
[13:27] <TeTeT> geser, mdeslaur: thanks
[13:28] <TeTeT> just discovered another problem on Natty, opensc doesn't build anymore, complains about a missing symbol
[13:29] <tumbleweed> TeTeT: that's listed here: http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi
[13:30] <tumbleweed> fixes obviously welcome :)
=== RainCT_ is now known as RainCT
=== RainCT is now known as C
=== C is now known as RainCT
[14:16] <bdrung> tumbleweed: is it a final decision to move to X-P-V?
[14:18] <tumbleweed> yes, python3 is only supported via X-P3-V. And that decision actually did make it into the python-policy
[14:21] <bdrung> tumbleweed: merged
[14:22] <TeTeT> tumbleweed: I fixed the build failure, hopefully the correct way and filed it as a patch to newly submitted bug 692571
[14:22] <ubottu> Launchpad bug 692571 in opensc (Ubuntu) "FTBFS natty " [Undecided,New] https://launchpad.net/bugs/692571
[14:22] <tumbleweed> bdrung: thanks
[14:25] <tumbleweed> TeTeT: seems reasonable, please forward it to the upstream
[14:26] <TeTeT> tumbleweed: is debian concered about a ftbfs for Ubuntu?
[14:26] <TeTeT> concerned
[14:26] <tumbleweed> TeTeT: the patch headers contain boilerplate, and when you are ready, subscribe ubuntu-sponsors
[14:27] <tumbleweed> they will be concered about these failures, as their are the result of linker changes that Debian will make as well, after squeeze has released
[14:27] <TeTeT> ok
[14:28] <tumbleweed> TeTeT: http://wiki.debian.org/ToolChain/DSOLinking
=== Quintasan_ is now known as Quintasan
[14:34] <tumbleweed> TeTeT: oh, also: please close the bug in the changelog entry, and your debdiff contains leaked testing version-number
[14:38] <TeTeT> tumbleweed: what does 'leaked testing version-number' mean?
[14:39] <tumbleweed> ~tetet in the version number
[14:40] <TeTeT> tumbleweed: so the debiff should just be version 0.11.13-1ubuntu3?
[14:40] <tumbleweed> yes, otherwise the sponsor has to manually edit it
[14:45] <TeTeT> tumbleweed: I think I'm ready, thanks for your pointers, way faster to fix it this way than via bug mail
[14:47] <tumbleweed> np. We try to encourage mentorship in public, where it can benefit lurkers (and you are less likely to get bad advice). But once it hits the sponsorship queue, discussion tends to happen on the bug where other sponsors are sure to see it.
[14:56] <tumbleweed> TeTeT: W: opensc: debian-changelog-line-too-long line 1
[14:57] <tumbleweed> also please link the lp bug to any debian / upstraem bug you file, otherwise, you'll probably be asked if you've forwarded it or not.
[14:59] <TeTeT> tumbleweed: I've not filed a debian bug, just sent an email to eric dorland directly, taking his email from the changelog
[15:00] <tumbleweed> TeTeT: cool, in that case it's great if you can note that in the bug
[15:04] <TeTeT> tumbleweed: fixed the too long line, thanks, will add a note on the email
[15:05] <TeTeT> tumbleweed: thanks again for your help, now back to my original task on the buffer overflow fix :)
[15:05] <tumbleweed> yeah, sorry, we should have rolled them into one. I only started paying attention at the FTBFS stage
[15:10] <tumbleweed> TeTeT: so, all three of your patches contain two changelog entries. The stable release patches should be targeted at the -security pocket, and be versioned according to https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Packaging
[15:13] <TeTeT> tumbleweed: the two changelog entries come from two calls of edit-patch. Found this cleaner than mixing the buffer overflow fix with the helper macro. I guess it's safe to combine them in one changelog?
[15:17] <tumbleweed> yes, one changelog entry for each upload
=== JanC_ is now known as JanC
[15:41] <TeTeT> tumbleweed: I'm not sure about the version number in Maverick. It would be the same as the updated one in Natty. So according to the wiki page of versioning, should it be: 0.11.13-1ubuntu3.10.10.1 ?
[15:42] <tumbleweed> TeTeT: we already have a ubuntu3 in natty (we just uploaded it) so you can use ubuntu2.1 for maverick
[15:44] <tumbleweed> normally if natty had the version (say 1.2-1) as maverick, we'd uplead 1.2-1ubuntu1 to natty and 1.2-1ubuntu0.1 to maverick
[15:45] <tumbleweed> if maverick had the same version as lucid, ubuntu0.10.04.1 to lucid and ubuntu0.10.10.1 to maverick
[15:48] <TeTeT> ok
[15:49] <TeTeT> updated the debdiff for maverick and lucid on bug 692483
[15:49] <ubottu> Launchpad bug 692483 in opensc (Ubuntu) "Buffer overflow" [Undecided,New] https://launchpad.net/bugs/692483
[15:49] <TeTeT> I'm waiting for the updated package to appear in Natty and will base another debdiff on that next
[15:57] <tumbleweed> TeTeT: look good (although https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation also recommends a changelog format). I'm not a security-team member, so I can't really comment more than that.
[16:18] <bdrung> tumbleweed: can you update your config-681693 branch?
[16:19] <bdrung> tumbleweed: you can't change the license of common.py without asking the previous authors.
[16:19] <tumbleweed> bdrung: I checked, I can.
[16:19] <tumbleweed> the previous copyright statement refers to code that got moved elsewhere
[16:20] <bdrung> tumbleweed: and the remaining code is from you?
[16:21] <bdrung> tumbleweed: i don't think that command line checking should be done in get_value
[16:22] <tumbleweed> excepting the negligable bit of code remaining there. I can ask jpds if he's ok with relicensing it, but it's debatably too small to be copyrightable (depending on your jurusdiction, I guess)
[16:23] <tumbleweed> bdrung: it simplifies the API (and is the same approach that devscripts uses), but it could be handled by a module-wide variable
[16:23] <tumbleweed> s/wide/level
[16:24] <bdrung> tumbleweed: what do you think about a config object instead of function?
[16:26] <tumbleweed> I don't see it buying us that much, this isn't really an OOish problem, unless we subclass OptionParser
[16:30] <tumbleweed> bdrung: branch updated.
[16:32] <tumbleweed> bdrung: another question is whether it's ok to use get_value() for OptionParser's default parameter, because that affects --help
[16:36] <bdrung> tumbleweed: that will generate a cyclic dependency if we allow --no-conf
[16:38] <tumbleweed> bdrung: sorry, not too sure what you are saying
[16:40] <bdrung> tumbleweed: i think that we should parse --no-conf with OptionParser
[16:41] <tumbleweed> ok, coming up soon.
[16:45] <ScottK> tumbleweed: The notion of "too small to copyright" is a myth.
[16:46] <tumbleweed> ScottK: I know that's certainly the case in ZA.
[16:46] <tumbleweed> (a myth, that is)
[16:46] <micahg> MTecknology: once nginx is sync'd, future versions will come in automatically until Debian Import Freeze, so unless you think 0.8.53-2 is broke, it can be sync'd
[16:46] <tumbleweed> btw, that code can almost certainly be removed, it's a workaround for a fixed bug in python.
[16:46] <MTecknology> micahg: oh.. i had it in my head we already passed that point
[16:47] <micahg> MTecknology: Dec 30
[16:48] <MTecknology> alrighty, thanks   0.8.54-1 is going have to be reviewed after kartik uploads it tomorrow, but it should be ready pretty soon.
[16:49] <MTecknology> oh crap... I wanted to get lal in- but i guess i'll need to get it done before 11.10
[17:06] <bdrung> tumbleweed: only requestsync uses the code. maybe we should move it into requestsync and get rid of common.py completely
[17:12] <tumbleweed> bdrung: removing it doesn't seem to break requestsync, when using https_proxy
[17:13] <tumbleweed> and bug 94130 is fixed
[17:13] <ubottu> Launchpad bug 94130 in apport (Ubuntu) "HTTPS over proxy fails" [Undecided,Triaged] https://launchpad.net/bugs/94130
[17:18] <bdrung> tumbleweed: so we can drop it
[17:19] <tumbleweed> pretty sure. The reason I put that memoize thing there is that I remembered lots of manual memoization elsewhere in u-d-t, but I haven't done anything about that yet.
=== Lutin is now known as Guest43017
[19:14] <bdrung> tumbleweed: what does memoize_noargs do?
[19:16] <tumbleweed> bdrung: caches the value of a fuction after the first run
[19:16] <tumbleweed> a generic memoization decorator would be a little more complex
[19:17] <bdrung> tumbleweed: can't we create a object that runs this function on __init__?
[19:17] <tumbleweed> yeah, can do
=== yofel_ is now known as yofel
[19:41] <highvoltage> I'm still getting the hang of quilt patches, what am I doing wrong here?
[19:41] <highvoltage> http://paste.ubuntu.com/546070/
[19:41] <ebroder> highvoltage: You need to add the file before you modify it
[19:41] <ebroder> Because when you add it, quilt snapshots the old state of the file, and that's what it diffs against
[19:43] <highvoltage> ebroder: ok. I'm not modifying, just adding.
[19:44] <highvoltage> (and not quite sure what you meant)
[19:44] <highvoltage> ah, I think I do now
[19:44] <ebroder> highvoltage: Creating a file is a sort of modification of it
[19:45] <highvoltage> I just got that, thanks :)
[20:19] <bdrung> tumbleweed: isn't the test run automatically?
[20:23] <tumbleweed> bdrung: no, setup.py test isn't supported by Debhelper's python_distutils yet
[20:24] <bdrung> tumbleweed: why? autotool tests are run if they exit.
[20:24] <ebroder> bdrung: Because there's no way to detect if setup.py supports a test argument
[20:24] <bdrung> is there a bug report requesting support?
[20:24] <ebroder> bdrung: No way at present, at least
[20:24] <tumbleweed> probably because it's new feature in distribute, and many many pcakages don't use it (yet?)
[20:26] <tumbleweed> bdrung: r874 btw. I'm about to start bolting it into other scripts
[20:30] <bdrung> tumbleweed: please let me review it before you gonna spread it everywhere
=== ximion1 is now known as ximion
[20:30] <tumbleweed> doing so :)
[20:31] <bdrung> tumbleweed: reviewing small changes is easier than reviewing big changes
[20:31] <tumbleweed> yeah, unfortunatley there was some heavy lifting there
[20:32] <ari-tczew> ScottK: what's the next step of backport procedure?
[20:36] <ScottK> ari-tczew: Needs time for an archive admin to look at it in New.  Let me see where it is.
[20:37] <ScottK> ari-tczew: I accepted the source.  It'll build now and then hit binary New again.
[20:38] <ari-tczew> ScottK: thanks!
[20:38] <ScottK> You're welcome.
=== ximion is now known as ximion1
[20:41] <bdrung> tumbleweed: i think you should select one of '--no-conf', '--noconf'
[20:41] <bdrung> having both is inconsistent
[20:42] <tumbleweed> ok, we don't need to carry other people's warts
[20:46] <tumbleweed> bdrung: pushed r877
[20:46] <bdrung> tumbleweed: d/rules: the for loop should be indented one tab less
[20:47] <bdrung> tumbleweed: and you could pull override_dh_auto_test: into the ifeq block
[20:48] <tumbleweed> ok. I suppose so.
[20:50] <tumbleweed> bdrung: r879
[20:51] <bdrung> tumbleweed: and the indentation?
[20:51] <tumbleweed> r878
[20:52] <bdrung> aha, you pushed two revisions ;)
[20:54] <bdrung> tumbleweed: why do we need debian/clean?
[20:55] <tumbleweed> distribute (setuptools) likes writing files in .egg-info
[20:55] <bdrung> tumbleweed: and dh_python2 doesn't clean that up?
[20:56] <tumbleweed> it's not dh_python2's job. If anything it's the python_distutils buildsystem's job
[20:56] <bdrung> tumbleweed: can it cleaned by setup.py?
[20:57] <tumbleweed> I suppose so, never seen anyone do that, hough
[20:57] <bdrung> tumbleweed: i prefer having that in setup.py instead of the packaging part
[20:59] <bdrung> tumbleweed: doc/ubuntu-dev-tools.5 -> as the \fIfirst\fR command\-line
[21:00] <tumbleweed> bdrung: I removed that, if we are using optparse to parse them, we don't have that restriction
[21:02] <ebroder> tumbleweed: Is parse_devscripts_config just stripping quotes?
[21:03] <tumbleweed> ebroder: yes, do we really want to match bash variable assignment syntax exactly?
[21:04] <ebroder> tumbleweed: I wonder if you want to use ' '.join(shlex.split(m.group(2)) or something
[21:04] <ebroder> Otherwise you'll get caught by screw cases like "foo"'bar' or whatever
[21:05] <tumbleweed> ebroder: seesm reasonable
[21:06] <ebroder> tumbleweed: And why use a regex instead of something like .split('=')?
[21:06] <tumbleweed> although the ' '.join() bit is dodgy, because foo=bar baz is interpreted as running baz (in sh)
[21:06] <ebroder> tumbleweed: Hmm, good point
[21:06] <tumbleweed> but we currently have that problem
[21:07] <ebroder> tumbleweed: On the terrible ideas front, you could parse the output of `bash -c '. /etc/devscripts.conf; . ~/.devscripts; set'` :)
[21:07] <tumbleweed> eek :) no, shlex is exactly what I need, thank
[21:08] <tumbleweed> ebroder: the re saves on having to detect comments, and strip everywhere
[21:09] <bdrung> tumbleweed: backportpackage.1: it's not clear with env of BACKPORTPACKAGE_BUILDER and UBUNTUTOOLS_BUILDER is preferred if both are provided
[21:11] <ebroder> tumbleweed: I feel like ubu_email is way too automagical. I can set DEBEMAIL='Evan Broder <evan@ebroder.net>', but it'll only parse an e-mail address out of that?
[21:12] <ebroder> Do people do that? And expect that behavior?
[21:12] <tumbleweed> ebroder: see the linked bug for it, somebody did expect that, yes
[21:12] <ebroder> If I set DEBEMAIL to that, I'd be expecting it to guess both a name and an e-mail address, not only one
[21:13] <tumbleweed> so what if you've set DEBFULLNAME too?
[21:13] <ebroder> Then I'm setting myself up for broken behavior of some sort
[21:14] <tumbleweed> hehe. Actually that behavior matches devscripts
[21:14] <ebroder> I'm less concerned with what happens if I set both variables, because clearly something screwy will happen in that case. But only setting one in that form seems more likely
[21:14]  * ScottK routinely only has DEBEMAIL set with just the email address.
[21:15] <ScottK> Since the system name on my account is correct, it just uses that in devscripts
[21:16] <tumbleweed> hmm, I didn't test fully enough, it doesn't quite match devscripts. DEBFULLNAME="Name <a@name.org>" DEBEMAIL="Email <b@email.com>" dch => Name <a@name.org> <b@email.com>
[21:18] <ebroder> tumbleweed: Like I said, it's clear what you do if you set DEBFULLNAME="Name" and DEBEMAIL="b@email.com". And (I think) it's clear what you should do if you set DEBEMAIL="Name <b@email.com>". I think those are the only specs that matter
[21:18] <ebroder> If something screwy happens in any cases other than those, I think it's the user's fault, and not our problem to work around
[21:19] <bdrung> tumbleweed: we should have testcases for the two use cases mentioned above
[21:19] <tumbleweed> OK, and both specs for UBUEMAIL
[21:20] <ScottK> ebroder: I think DEBEMAIL set to an email address and DEBFULLNAME is a common use case and should be supported.
[21:20] <ScottK> ... DEBFULLNAME not set ...
[21:20] <tumbleweed> ScottK: already handling that fine
[21:21] <tumbleweed> (although I suppose this discussion is about handling too much)
[21:21] <ebroder> ScottK: Err, yeah. And any combination of other variables. What I'm saying I *don't* think we should have any sort of support for is setting multiple variables to Foo <bar@baz.com>. One of the variables should just win in that case
[21:21] <ScottK> OK
[21:22] <bdrung> tumbleweed: i don't think that we should always have UBUNTUTOOLS_*, because some values could be script specific
[21:23] <tumbleweed> bdrung: yes, I was assuming I'd get there, but hadn't hit any scripts needing that yet
[21:24] <bdrung> tumbleweed: get_value(self, key, default=None, foobar=True, compat_keys=[]):
[21:24] <bdrung> tumbleweed: and a good name for foobar
[21:24] <tumbleweed> package_wide
[21:25] <tumbleweed> another option is to have a list of blessed package-wide variables
[21:25] <bdrung> tumbleweed: that's better
[21:26] <bdrung> tumbleweed: add this testcase: PREFIX_KEY in config file should win against UBUNTUTOOLS_KEY in the environment
[21:27]  * tumbleweed now has a reasonable todo list again :)
[21:28] <bdrung> tumbleweed: "def getBuilder(builder='pbuilder'):" -> "def getBuilder(builder):"
[21:28] <bdrung> tumbleweed: we don't want to set the default in two places
[21:29] <tumbleweed> ok, it can pull it out of defaults.
[21:29] <bdrung> yes
[21:39] <bdrung> tumbleweed: test_any_environment_precedence is wrong
[21:40] <bdrung> PREFIX_KEY should always win against UBUNTUTOOLS_KEY
[21:41] <tumbleweed> my reasoning for that was for variables like BUILDER, but I suppose we are deprecating those (and not documenting them any more)
[21:42] <bdrung> did we had BUILDER?
[21:43] <tumbleweed> hmm, why did I think we did
[21:57] <tumbleweed> ebroder: r883, toned down ubu_email magic
[21:58] <bdrung> tumbleweed: please let me know once you processed your toto
[21:58] <tumbleweed> will do
[21:58] <ebroder> tumbleweed: Where are the name and email args to ubu_email supposed to come from? Comamnd-line args?
[21:58] <bdrung> s/toto/todo list and have the branch updated for the next cycle of review/
[21:59] <tumbleweed> ebroder: yes, i.e. ack-sync
[21:59]  * ebroder nods
[22:00] <tumbleweed> bdrung: is it plausible that if something appears in defaults it's package-wide?
[22:01] <bdrung> tumbleweed: yes
[22:01] <tumbleweed> yeah, I think we want defaults for all package-wide variables, and other defaults belong in thier scripts anyway
[22:01] <ebroder> tumbleweed: I still think it's weird that you ignore components of A <b@c> style variable values. Let me try to sketch up what I think it should do...
[22:02] <tumbleweed> ebroder: e.g. UBUEMAIL=joe@ubuntu.com DEBEMAIL="Joe <joe@debian.org>"
[22:03] <ebroder> No, I'm thinking of if just DEBEMAIL="Joe <joe@debian.org>" is set. You'll extrapolate an e-mail address out of that, but drop the name
[22:03] <ebroder> tumbleweed: I would do something like http://pastebin.com/9vmdthFT for that inner loop
[22:04] <ebroder> That will have slightly screwy behavior if you do something like UBUEMAIL=joe@ubuntu.com DEBEMAIL="Joe <joe@debian.org>", but I think you're setting yourself up for that if you set your variables up that screwily
[22:04] <tumbleweed> ebroder: with your loop, DEBEMAIL overwrites UBUEMAIL
[22:04] <ebroder> (That being said, I think it'll still do what I would consider to be the "right" thing - take the e-mail from UBUEMAIL and the name from DEBEMAIL)
[22:04] <ebroder> No, it would only overwrites the name component
[22:05] <ebroder> Oh, hmm. One moment to make a slight tweak
=== ximion1 is now known as ximion
[22:05] <tumbleweed> also, you can't write to locals, but I know what you mean :)
[22:05] <ebroder> tumbleweed: http://pastebin.com/G1ChmX7Y
[22:06] <ebroder> tumbleweed: You can totally write to locals
[22:06] <ebroder> http://pastebin.com/srVSBq8J
[22:06] <ebroder> (It's terrifying that you can do so, and I don't really encourage it, but it can be done)
[22:07] <tumbleweed> sorry, what I meant is, writing to locals won't affect the same variable outside th eloop, IIRC
[22:07] <ebroder> tumbleweed: I don't see why it wouldn't. Python doesn't have a concept of scope at any finer granularity than the function level
[22:08] <tumbleweed> I'm pretty sure I tried it
[22:08] <tumbleweed> oh, and "Note The contents of this dictionary should not be modified; changes may not affect the values of local and free variables used by the interpreter"
[22:09] <ebroder> Maybe just store the values you want to return in a dict and manipulate that, then?
[22:09] <tumbleweed> or spend an extra three lines of code :)
[22:09] <ebroder> Or that
[22:18] <tumbleweed> ebroder: r885 has your version
[22:20] <ebroder> tumbleweed: Thanks. I like that logic much better
[22:21] <ebroder> tumbleweed: Do we care about backporting u-d-t to Python 2.4? If not, can you use the named fields for pwd.getpwuid?
[22:22] <ebroder> (e.g. pwd.getpwuid(os.getuid()).pw_name)
[22:22] <tumbleweed> we declare ourselves as >= 2.6, so sure
[22:22] <bdrung> tumbleweed: >= 2.5
[22:22] <ebroder> I find those much more informative than [0], etc.
[22:22] <tumbleweed> err, that, yes
[22:31] <tumbleweed> bdrung: r888 meets everything we've been discussing, short of changes to setup.py
[22:31] <ScottK> Last LTS has 2.6, so you may as well got 2.6+ if it's convenient.
[22:31] <ScottK> got/go
[22:32] <tumbleweed> yeah, no real need to yet
[22:34] <bdrung> tumbleweed: my proposal was "def getBuilder(builder):"
[22:34] <bdrung> tumbleweed: the caller will have already pulled the config value if not passed via command line
[22:35] <tumbleweed> ok
[22:39] <tumbleweed> bdrung: clean is acknowledged as a bug in distribute https://bitbucket.org/tarek/distribute/issue/122/setuppy-clean-should-delete-sourcestxt
[22:48] <akoskm> hi!
[22:54] <akoskm> does it possible to create a link to a library what I'm installing as build-dependency but I have to use it under different a name?
[22:57] <akoskm> that actual file is /usr/lib/qt4/plugins/phonon_backend/phonon_gstreamer.so, but the package what I'm building tries to find it as libphonon_gstreamer.so
[22:59] <RAOF> akoskm: phonon_gstreamer is a phonon plugin, right?  What are you packaging such that it wants to link against a plugin?
[22:59] <akoskm> RAOF, qtjambi-4.7
[23:00] <RAOF> And what *is* it?  ☺
[23:00] <akoskm> java binding for Qt.
[23:00] <RAOF> Ah.
[23:00] <RAOF> Um, why would that link to a phonon plugin?
[23:01] <RAOF> I was very much under the impression that phonon abstracted the backends away.
[23:01] <RAOF> Indeed, if it *doesn't* why would you bother using gstreamer through phonon rather than just gstreamer directly?
[23:02] <akoskm> there is module called multimedia. since we aren't implemented the modularized building yet I have all the libraries installed
[23:02] <akoskm> and this multimedia modules requires the phonon plugin
[23:02] <ebroder> RAOF: Maybe Java has limited dlopen'ing capabilities or something?
[23:03] <RAOF> ebroder: But java wouldn't be dlopening, would it?  It'd just be libphonon-ing, and libphonon can certainly dlopen its plugins.
[23:03] <ebroder> Oh, good point
[23:06] <RAOF> akoskm: Anyway, it sounds like the package bulid system is wrong :)
[23:09] <bdrung> tumbleweed: ./backportpackage --no-conf ubuntu-dev-tools 2>&1 | pastebinit
[23:09] <bdrung> http://pastebin.com/NRppV9Ax
[23:15] <akoskm> RAOF, what do you mean by the package build system is wrong? Do we need to change our reference from libphonon_gstreamer.so to phonon_gstreamer.so ?
[23:16] <tumbleweed> bdrung: thanks
[23:17] <RAOF> akoskm: It sounds like something is trying to do -lphonon_gstreamer, which will look for libphonon_gstreamer.so.  That's incorrect.
[23:18] <RAOF> As the file is phonon_gstreamer.so :)
[23:19] <RAOF> akoskm: At this point it might be useful to pastebin relevant build logs and makefiles.
[23:20] <bdrung> tumbleweed: i have more:
[23:20] <bdrung> Set more values in setup.py for egg info?
[23:20] <bdrung> backportpackage: WORKDIR not documented
[23:20] <bdrung> should we move ubuntutools/test/* to test/*?
[23:20] <bdrung> UPDATE_BUILDER not in ubuntu-dev-tools(5)
[23:20] <bdrung> backportpackage.1: CONFIGURATION VARIABLES not sorted alphabetical
[23:24] <tumbleweed> our egg info is relatively unimportant, as don't care much about non-deb distribution
[23:24] <tumbleweed> Python test suites should generally be within the code's namespace, and distributed with the source code
[23:27] <bdrung> tumbleweed: the tests should be in the installed binary package?
[23:28] <tumbleweed> that's generally what's done
[23:28] <bdrung> tumbleweed: i see no reason for putting in the binary
[23:29] <bdrung> *it
[23:30] <tumbleweed> I assume the reason for it is that users may want to run the test suite if they suspect misbehavior. I don't know much about the history of this.
[23:31] <ebroder> I think it's a good idea to leave it in, if the test suite does run successfully when it's installed (I've seen installed test suites that will only run from a source checkout)
[23:32] <bdrung> tumbleweed: three point left
[23:32] <bdrung> ebroder: do you want to review tumbleweed's branch too?
[23:32] <bdrung> s/point/points/
[23:33] <tumbleweed> bdrung: I'm dealing with two of those. The sorting in backportpackage matches the configuration options. I suppose there's no harm in sorting them alphabetically.
[23:37] <ebroder> bdrung: Sure, but I can't now
[23:39] <bdrung> tumbleweed: "Boolean." is not specific enough. true/false, 0/1, yes/no?
[23:40] <tumbleweed> ok. Should probably improve boolean handling anyway.
[23:43] <bdrung> tumbleweed: do we want a global workdir variable?
[23:44] <tumbleweed> that would require a global default workdir policy
[23:44] <tumbleweed> (which is a reasonable thing to have)
[23:45] <bdrung> tumbleweed: i propose the behaviour of backportpackage
[23:46] <bdrung> /tmp/scriptname-XXXXXXX
[23:47] <tumbleweed> works for me
[23:47] <bdrung> defaults = {..., "WORKDIR": None}
[23:49] <ebroder> behavior of backportpackage> +1
[23:50] <udienz> micahg: are you there?
[23:52] <micahg> udienz: yep
[23:53] <bdrung> tumbleweed: we should define this rule: UBUNTUTOOLS_* variables are only allowed if at least two script uses them
[23:53] <udienz> micahg: from latest merge, both patch already apllied at upstream
[23:54] <bdrung> tumbleweed: (which will be the case for those four variables)
[23:54] <udienz> but not in natty
[23:54] <tumbleweed> bdrung: sounds good, I'll add a comment stating that
[23:54] <micahg> udienz: right, so we need them in natty before they can go into lucid-proposed
[23:54] <udienz> micahg: ok, so i can proposed both patch to natty now?
[23:55] <micahg> udienz: so I was told 0.8.54 will be in Debian soon, I suggest talking to MTecknology about any other patch you'd like to have SRUd so that it can get in through Debian
[23:55] <micahg> udienz: since we just sync'd nginx and have active Debian maintainers, I'd prefer the patches to go through Debian
[23:56] <bdrung> tumbleweed: i will go to bed soon. if you address the remaining points before, i will do the merge before laying down.
[23:56] <micahg> udienz: MTecknology is part of the Debian team for nginx I believe
[23:57] <udienz> micahg: okey, thats mean only one patch is not apllied yet in natty (i asumsed id 0.8.54 is landed in natty)
[23:57] <micahg> udienz: no, 0.8.53-2
[23:57] <udienz> micahg: yup, MTecknology is debian team for nginx
[23:57] <micahg> but 0.8.54 should be coming soon
[23:57] <tumbleweed> bdrung: r895. I'm going to make a fair amount of noise in trunk when I add support script by script, then.
[23:58] <micahg> udienz: so, just coordinate with him about the other patch so it lands in natty with 0.8.54-1 and you should be fine