=== rextsai is now known as chihchun [02:10] I am an administrator of a team on launchpad, and I would like to promote myself to owner and thus displace the current owner without bothering him about it/without waiting for him to do it. Is this possible? [02:10] Hm, I suppose I could remove him from the team... [02:11] But that might hurt his feelings. [02:11] Maybe I can remove him from the team and then put him back. [02:11] that won't change the owner of the team [02:11] Thus hurting and then unhurting his feelings. [02:11] Ah, nevermind then. [02:12] you'd need to ask #launchpad, who'd probably get you to put in a request on answers.launchpad.net/launchpad [02:12] you'd also need to justify why you could take over the team, I think [02:15] I'll try getting ahold of the current owner first. [02:15] Thanks! [02:16] zooko: no, its not possible. [02:16] zooko: administrators cannot privilege escalate. [02:17] zooko: as ajmitch says you need an appeal to authority to do it. Either the owners, or lp support. [02:17] lifeless: thanks! [03:46] hello, can someone remind me of the sponsorship process? i've attached a patch for a FTBFS: LP: #770833 [03:47] i now should subscribe ubuntu-sponsors (i think), but my question is more around how to properly forward to debian? [03:47] achiang: submittodebian in the new source dir [03:48] micahg: ok, thanks [03:48] micahg: hm, the "new" source dir? i only have an existing source directory [03:48] (after apt-get source ) [03:48] achiang: the one that you use to create the source package and subsequently the debdiff [03:49] micahg: ah, ok, thanks [03:50] micahg: for the current "cure the FTBFS plague", should i be trying to get the packages fixed in ubuntu first, or in debian first? my reading of the mail from this AM made it seem like "let's get oneiric fixed, and in parallel, forward to debian, let them fix at their own pace" [03:50] achiang: at this point in the cycle, oneiric first [03:50] i think that's generally a good plan, especially at this point of the cycle [03:50] ok, thx [04:12] ah, submittodebian is quite nice, once one configures smtp correctly in reportbug. :) [04:16] micahg: if a package is patchless, and the fix can be trivial, is it worth adding a patch system to fix a FTBFS? [05:03] achiang: no, just patch the source [05:05] micahg: thanks [05:05] * achiang fixes 4 for today, but it's bed time now [05:07] achiang: awesome, thanks! === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [06:28] NCommander: Sure think, you know where the source code is? Actually it should be ready for that because I wouldn't expect it to be too much different than debports? [07:39] good morning [07:51] http://qa.ubuntuwire.com/uehs/no_updated.html seems to be out of date, seems to be pointing to natty, can anyone check on this? === dholbach_ is now known as dholbach [09:28] wgrant: ^ do you run that? [09:29] Laney, micahg: Indeed. Thought I fixed that, but apparently not. [09:29] * wgrant fixes. [09:52] Laney, micahg: Fixed and rerun. [09:52] cheers [10:35] * cjwatson wonders if he can displace james_w on http://udd.debian.org/cgi-bin/ubuntu_usertag.cgi by the end of the FTBFS-fixing project :-) [10:51] debfx, hello :), do you know when virtualbox is coming with xserver 1.11 support? [10:52] oh, I never remember to use the usertags :( [10:55] ricotz: I assume you are using the xorg-edgers ppa? you'd have to ask them to put virtualbox into the ppa [11:07] Hi, I need help verifying that my "debian/copyright" file is correct in regards to the file specs. Plz can anyone revise it ? Thankx. http://pastebin.com/2uLaFZiV === ryanakca_ is now known as ryanakca === chuck_ is now known as zul === almaisan-away is now known as al-maisan === kentb is now known as kentb-afk === kentb-afk is now known as kentb [16:17] wgrant: awesome, thanks === al-maisan is now known as almaisan-away [18:02] Rhonda: I do, but I don't know how in sync it is with Debian [18:25] NCommander: Quite. Most development happen on master branch and get merged both into debian-master and ubuntu-master [18:26] And if you are interested, I am still looking for someone who would apply the new ubuntu theme to the packages site ;) [18:42] Rhonda: I'm not much of a HTML guru or artist :-/ [18:42] Rhonda: that being said, if the codebases are more or less in sync with each other, it should be straightforward to add ports as Debian already has the necessary architecture to pull in d-ports.org into their codebase [18:45] Right. [18:48] Hello folks. Could someone volunteer to upgrade Tahoe-LAFS in Ubuntu to the latest release in order to fix a security bug? [18:48] If it were done, 'twere best done quickly. [18:48] zooko: that sounds like somethingbest handled by the dsecurity team [18:48] NCommander: not for the devel release [18:49] Well, tahoe-lafs is community-supported, not core, so ... ? [18:49] zooko: I'd suggest asking Debian to upgrade and then use requestsync from ubuntu-dev-tolls [18:49] zooko: does the security bug exist in previous releases of Ubuntu? [18:49] *ubuntu-dev-tools [18:50] NCommander: yes [18:50] micahg: I've sent email to the debian security team with GPG encryption but haven't heard back. [18:50] micahg: maybe I'll send another... [18:50] zooko: if you're asking for the latest version, that can only happen in the dev release [18:50] or unstable for Debian [18:51] zooko: is the bakport of the fix hard? [18:51] jtaylor: no, it is not. [18:51] jtaylor: what's your launchpad id again? [18:51] which versions are affected? [18:51] same as my nick here [18:51] Ah. :-) [18:52] jtaylor: I subscribed you to https://bugs.launchpad.net/ubuntu/+source/tahoe-lafs/+bug/848476 where you can see the patches. [18:52] Error: launchpad bug 848476 not found [18:52] tahoe-lafs isn't in stable so I don't see what the security team have to do [18:52] just get the fix into unstable and testing [18:52] right, it's just the maintainer uploading the latest release, then you can request a sync to Ubuntu [18:52] for ubuntu stable releases you need to follow the security sponsorship procedure yeah [18:53] micahg: can tell you all about that :-) [18:53] -: [18:54] * micahg guesses he didn't do such a good job with that last time since it was very late at night [18:56] So, I should write to team@security.debian.org again? [18:57] Maybe I should try security@debian.org instead. [18:57] zooko: no, ask the maintainer to upload the latest release with the fix [18:57] Ah. [18:57] the security team usually only gets involved for stable [18:58] Hey wait, *you* are listed as one of the maintainers! [18:59] I'll write to the other one. ;-) [18:59] zooko: sorry, wrong micah :) [18:59] no its a different micah [18:59] or rather that's micah, not micahg [18:59] I'll prepare some branches [19:01] micahg: oooh. :-) [19:01] Thanks. [19:01] jtaylor: sweet! Thank you! [19:01] * micahg looks forward to jtaylor's MOTU application [19:02] unfortunatly I've put than on hold for a while [19:02] just started a new job and don't know how much time I have [19:02] :( [19:04] jtaylor: well, whenever you're ready, good luck with the new job [19:04] thx [19:06] actually we don't really need to bother fixing tahoe in natty as its still broken [19:07] I should bug release about that at some point :/ === almaisan-away is now known as al-maisan [19:08] jtaylor: well, is that just an rdepend that needs fixing? [19:08] s/rdepend/dependency/ [19:08] yes but the ideal fix is to upgrade the version of that depend [19:08] that's a mess [19:09] but I guess that does make the task invalid for natty [19:10] not release, sru [19:10] yes meant that [19:10] Bah. [19:10] Is there something I could do to help with that? [19:10] jtaylor: actually, no the task should still be open...not sure about the whole thing [19:14] urg tahoes testsuite does not run [19:15] What's that you say. [19:15] 'module' object has no attribute 'bench_dirnode' [19:15] Run the test suite with "python setup.py test" [19:16] tried that [19:16] And is that the one with that attribute error? [19:16] yes [19:16] Is this with the upstream tarball or with patches? [19:16] Oh yes the patches change the setup.py so you should run the tests with trial instead. [19:16] ubuntu oneiric package [19:17] trial allmydata.test [19:17] But, I'm not sure if it will import a version that is installed in your system and run those tests instead of running the tests of the version in your current working directory. [19:18] In fact, "make test" might do the right thing... [19:19] Ah, no that runs python setup.py test [19:19] Oh, but there is "make quicktest". [19:19] That bypasses "python setup.py test" because it is slow to start up. [19:19] Fortunately that also means it will probably work even though "python setup.py test" doesn't work in that version. [19:20] all don't work [19:20] I'll try it in debian [19:21] no luck [19:23] What does "trial allmydata.test" do? [19:23] Let's see... What does "python setup.py build" do? In upstream, that builds a lot of things in ./support. [19:23] does not find allmydata.test even though I set pythonpath to pwd [19:23] Then you can do "PYTHONPATH=./support/lib/python2.7/site-packages trial allmydata.test" [19:24] It would be nice if we could get "python setup.py test" to work in the Ubuntu and Debian version... [19:24] does also not work, there is no support/.. in the tree after build [19:25] Okay, so that is changed too.\ [19:25] How about PYTHONPATH=`pwd`/src trial allmydata.test [19:25] hm [19:25] there is some weird patch in the debian package [19:26] exclude_buildtest_package.patch, lets see what happens if I remove that [19:26] does not fix it [19:28] What happens with PYTHONPATH=`pwd`/src trial allmydata.test [19:28] The "allmydata" python packagedirectory is inside ./src/ [19:28] a that works thx [19:28] Okay, good. [19:28] We should probably add a note to the Debian/Ubuntu packaging telling people how to run the tests. [19:29] setup.py test should get fixed [19:29] and the debian package use it during build [19:29] I would be willing to help with that. [19:31] is it sure no one uses the removed function? [19:31] jtaylor: yes === chrisccoulson_ is now known as chrisccoulson [19:32] No one has *ever* used it, actually. [19:32] So it is a case of "YAGNI" which turned out to be part of a vulnerability. :-( [19:33] hurray maverick testsuite: errors=683, successes=457 :( [19:33] Hm. [19:34] and oneirics testsuite seems to have deadlocked [19:34] Is it possible that the Debian/Ubuntu patches actually cause the tests to fail? [19:34] That would be unfortunate. [19:34] Could you share the errors? Just email the whole test output to zooko@zooko.com or pastebin some part of it... [19:34] in maverick there are no patches that change any code [19:34] only setup.cfg [19:35] Where can I see the patch? [19:35] oneiric is hanging in test_download_from_only_3_shares_with_good_crypttext_hash since ~ 10 minutes [19:36] Hm. [19:36] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/tahoe-lafs/maverick/view/head:/debian/patches/reduce_build_dependencies.patch [19:36] Well, please show me the test errors. [19:36] I don't immediately see why that reduce_build_dependencies.patch would lead to test failures. [19:36] no error displayed just hanging [19:37] let me test something with that version first [19:37] What about on Maverick -- there were errors there. [19:37] This reminds me that there was some movement on getting automated testing for Debian recently, wasn't there? That would be awesome. [19:37] yes there was some work done, dep8 I think [19:38] http://dep.debian.net/deps/dep8/ [19:38] excellent [19:39] davidsarah: jtaylor volunteered to update debian/ubuntu Tahoe-LAFS v1.8.3. [19:39] And the test suite doesn't work! [19:39] I suspect that it doesn't work for the debian/ubuntu package of Tahoe-LAFS v1.8.2, either. [19:39] (Since nothing we've done for 1.8.3 is likely to change that behavior.) [19:40] davidsarah: http://codepad.org/JKdC0orz [19:42] ok it got past the deadlock test this time [19:42] What did you change? [19:42] oh, that's unfortunate [19:42] nothing just ran it again [19:42] That's the word I used. [19:42] "unfortunate" [19:42] I'm sure I've seen the tests pass using the Ubuntu package before now [19:42] yes me too [19:42] you have to run 'tahoe debug trial', though [19:43] so that you're using the correct installed tahoe [19:43] test ran this time on oneiric [19:44] What did you change on oneiric? [19:44] Oh, try "tahoe debug trial". [19:44] nothing [19:44] maverick rerun (in maverick instead of oneiric....): errors=7, successes=727 [19:44] paste the errors? [19:44] http://paste.ubuntu.com/688581/ [19:44] Oh yeah, I really want tahoe-lafs (and all other software I contribute to) to integrate with this: http://dep.debian.net/deps/dep8/ [19:45] one of them due to a missing dep I forgot [19:45] hmm, must be an incompatibility with the installed simplejson [19:45] It isn't necessarily json related. [19:46] The error message should print out the thing that it failed to decode as json. [19:46] I'll bet it is an HTTP error message or something. [19:46] do the tests need internet acccess? [19:46] No. [19:46] what does 'python -c "import simplejson; print simplejson.__version__" say? [19:46] 2.1.1 [19:50] it gets 403 Prohibited port (configure Remap-...) instead of a json [19:50] ah [19:51] I think the tests only try to listen on a kernel-assigned port, no? [19:51] i.e. "port 0" [19:52] port 57639 [19:52] jtaylor: after this is fixed, tell me how to make tahoe-lafs work with http://dep.debian.net/deps/dep8/ . :-) [19:53] so, there's an error-reporting bug there in the CLI, we should print the thing we failed to decode [19:54] its probably unrelated to the security fix [19:54] so I'll ignore it for now [19:55] but it also affects the version in lucid [19:56] lol unexpectedSuccesses=1 [19:59] Heh heh [20:00] what was the unexpected success? [20:00] allmydata.test.test_cli.Cp.test_unicode_filename [20:01] ah. can you paste the output so I can fix it? [20:02] there was no output only the reason [20:03] See issue ticket #534 [20:03] ok, thanks === A7med is now known as Neo31 [20:04] Hee's a patch against 1.7.1 which makes tahoe_mv tell what it got that failed to decode. [20:04] http://codepad.org/PVOSm0B2 [20:05] ok good the patch applies with fuzz on maverick and lucid and the testsuite gives the same result [20:05] (= same number of errors) [20:05] I guess that can be uploaded, the testsuite seems very thourough [20:06] Bah! [20:06] Errors! [20:06] Down with test suite errors. [20:06] But yeah maybe upload the safer version first then fix test suite errors. [20:07] if you come up with a fix and its worth an SRU please come back, for now only the sru is on my agenda [20:07] sru=sec-fix [20:08] the testsuite in oneiric works (although apparently not always, I'll rerun it a few times later) [20:13] zooko: when did you inform the debian maintainers? [20:16] devfil: do you plan on fixing fillmore-lombard? [20:17] * Laney has a patch that at least makes it build (for Oneiric), but you should just upgrade it in Debian [20:17] jtaylor: I wrote to the security team (at least to one address that I got from a debian.org web page that said it was the security team) yesterday. [20:17] I wrote to the maintainers -- bertagaz and micah -- today about 4 or so hours ago. [20:17] k [20:18] Laney: nope, I have to orphan it [20:18] oh [20:19] well please do so then, I'll probably do a QA upload at least === al-maisan is now known as almaisan-away [20:50] zooko: pushed branches for lucid maverick and natty, it would be great if you could check if they are correct [20:51] bzr branch lp:~jtaylor/ubuntu/natty/tahoe-lafs/fix-848476 in debian/patches [20:52] Thanks! [20:53] I was just wondering today what it would take to get automated import of our patches from our darcs repository into bzr. [20:56] I only know those tricks for git :/ [20:57] Hm, how about darcs -> git -> bzr... [20:57] anyway I removed all the doc updates, they just increase the diff and make applying it to older versions harder [20:57] Ok. [20:58] How do I view your patch using bzr? === almaisan-away is now known as al-maisan [21:00] its in debian/patches [21:01] http://bazaar.launchpad.net/~jtaylor/ubuntu/lucid/tahoe-lafs/fix-848476/revision/6 [21:02] ups there is still some doc diff in it [21:12] zooko: I have to leave, please try to get it fixed in debian via the maintainers and ask here to get it synced to oneiric when thats done [21:13] jtaylor: thanks! Will do. [21:14] jtaylor: which doc diffs did you remove precisely? [21:14] I think the diff to known_issues.rst should be kept [21:15] it does not affect the patched version so its no known issue [21:15] (known_issues.rst hasn't changed very much since 1.6.1, so it should be easy to apply to older versions) [21:15] hmm [21:15] CREDITS, NEWS , docs/garbage-collection.rst, docs/quickstart.html, relnotes.txt, docs/known_issues.rst [21:16] docs/quickstart.html will point to a .zip of an unpatched release, in that case [21:16] I'm not seeing why doc changes are difficult to backport [21:17] surely they're the easiest things to backport, since you can't get it wrong in the sense of breaking code [21:17] they aren't I just didn't care fixing them all up to match the correct versions [21:18] the link in quickstart points to an old version in all packages, maybe you should put some latest link in that folder and point quickstart to that [21:18] or just point to the folder and let the user figure that out themself [21:18] but that leaves the package with incorrect documentation :-( [21:19] yes that could be fixed, but I doubt many read that without checking if what is linked there is really the newest [21:19] the reason for people following the link is to get the newest because the package is too old [21:20] it's not just quickstart; the docs in each version are supposed to document *that version* [21:20] yes so a naive backport is wrong [21:20] they hen document the wrong version [21:20] the only difference is the sec backport which is documented in changelog.Debian [21:21] * davidsarah feels as though we are talking at cross-purposes [21:21] lucid has 1.6, you can't patch the doc to at once talk about 1.8 in some parts [21:22] take the change in garbage-collection.rst, for example. if you don't backport that change, then the doc is incorrect because it says that you can cancel leases, when you can't in the patched version [21:23] in the case of quickstart.html, that says what the latest stable upstream version was at the time of the release you're looking at [21:23] yes that I should ahve left in [21:24] I'll not patch quistart as it will be outdated on 1.9 release again anyway ... [21:24] the change to CREDITS is not important [21:25] but it makes sense to change NEWS so that it describes the version you're looking at [21:25] isn't that the normal policy for changelogs (which is what NEWS is) in security releases? [21:26] similarly, relnotes.rst describes the current version, so to have it describe some different version is just wrong [21:27] news describes what upstream says, changelog.Debian describes what is different [21:27] or README.Debian [21:28] why is it a problem to update the documentation? because you're not making all of the changes therein? [21:28] because I'm lazy [21:28] I guess I have some pretty strong philosophical disagreements with some of the Debian/Ubuntu packaging policies [21:28] erm, this isn't a policy [21:28] Laney: true, in this case [21:29] more generally I think debian/ubuntu packages are unnecessarily different from upstream in many cases [21:29] which increases the support burden [21:31] yeah, that's unfortunate -maintainers shouldn't be making unnecessary changes (patches should be forwarded back) [21:31] (debian social contract #2) [21:32] perhaps I should have said "practices" rather than "policies" (the policies certainly allow you to produce a package that is very close to upstream) [21:34] but I doubt it's the intention of any maintainer to cause upstreams more work, and a little bit of communication can often resolve problems [21:34] "your patch foo-bar is changing behaviour and causing x y z effects, plz kill it" [21:35] davidsarah: updated garbage-collection docs [21:36] please update the link in qickstart to something more distribution friendly or bug the debian maintainers about patching it [21:37] ok, I'll open a ticket for that [21:39] just linking to http://tahoe-lafs.org/source/tahoe-lafs/releases/ should be enough [21:39] anyone able to use tahoe hould be able to find the latest version himself [21:40] there's a usability issue of needing to wade through a directory listing and possibly getting the wrong file... [21:41] but that's something we can discuss on the ticket [21:41] better than having a link to an outdated version there [21:42] I agree, but possibly better still would be to have a stable URL that points to the zipfile for the latest release [21:42] symlink? [21:42] / redirect [21:42] that's just an implementation detail [21:43] I mean that I don't see why it's a problem at all [21:43] it isn't, but our practice is to discuss these things on tickets [21:44] righto === al-maisan is now known as almaisan-away [23:53] Rhonda: poking the packages.git the config files are MIA