[03:43] Hello all [03:43] I'm having an issue with the alpha release of 12.04, and I was wondering if this is an appropriate place to ask for help? [03:43] kpennalt: #ubuntu+1 [03:43] would be better [03:44] but you should be able to ask here too [03:44] appreciate the advice - I'll try the other channel first === almaisan-away is now known as al-maisan === Tonio__ is now known as Tonio_ [10:20] next time somebody who can use syncpackage has a sync request to do, would you mind doing it with requestsync instead just the once and letting me know? [10:21] I'm working on converting the requestsync backend to syncpackage, and would appreciate a real test case [10:22] cjwatson: if sponsors can syncpackage it themselves, will the archive admins still be handling requestsync bugs? [10:22] Hopefully not [10:22] But I'd like to keep that code around for a while to deal with any that come through sponsors who are less up-to-date [10:23] yeah, I'm sure there'll be a few.. [10:23] there are some syncs in the queue currently [10:23] well, we haven't gone out of our way to annunce syncpackage... [10:24] Laney: one, and it's one I need to check with Kubuntu people first [10:24] unless you mean you just added some [10:24] no [10:24] I see quite a few though [10:24] the sponsor queue, not the AA one [10:24] ah [10:30] OK, I'll review/steal one off the sponsor queue then [11:03] excellent, https://bugs.launchpad.net/ubuntu/+source/git/+bug/913977 worked [11:03] Ubuntu bug 913977 in git (Ubuntu) "Sync git 1:1.7.8.3-1 (main) from Debian unstable (main)" [Undecided,Fix released] [11:04] nice [11:05] committed to ubuntu-archive-tools [11:11] can any developer (with access) use mass-sync now? [11:13] I'd hope not. [11:16] I don't see how it's any worse than sponsoring syncs manually [11:28] Laney: Yes, should be possible [11:28] StevenK: What Laney said [11:28] Laney: Although as tumbleweed says, the entire "feed sync requests to ubuntu-archive" system should basically be considered deprecated at this point [11:29] right. I wasn't suggesting that (although we really ought to announce this), just that mass-sync might be convenient for more general use. [11:29] StevenK: You aren't confusing mass-sync with auto-sync, are you? [11:29] Laney: mass-sync's interface is a right mess. It's probably easier to just use syncpackage directly. [11:30] Most people aren't in the position of needing to use it in bulk after somebody else has reviewed bugs one by one. [11:30] cjwatson: Oh, mass-sync is not sync-source -a? [11:30] StevenK: That's auto-sync. [11:30] fair [11:30] cjwatson: Right, complaint withdrawn [11:30] StevenK: Launchpad doesn't have any particular access control on Archive.copyPackages AFAICT, which is the backend for auto-sync; but I put a guard in the API script itself. [11:30] We ought to [11:31] (Obviously you can remove that if you know what you're doing, but I'm more worried about the people who don't.) [11:31] I'd have called auto-sync mass-sync, but the name was already in use [11:32] StevenK: Mm. Archive owner? [11:33] (That's what auto-sync currently checks for.) [11:34] cjwatson: But that doesn't work either [11:35] Why not? [11:35] cjwatson: copyPackages is called by mortals [11:35] Example? [11:35] And we'd like the security team to use it instead of whatever create delayed copies [11:36] Surely the security team would use copyPackage, not copyPackages. [11:36] The latter being the mass interface that e.g. doesn't send notifications. [11:36] Oh, right [11:36] Naming FTW [11:36] Damnable interfaces that are almost identicaly named [11:36] Right, archive owner for copyPackages sounds okayish [11:37] Feels like copyPackage should be as it is now and copyPackages should be launchpad.Edit. [11:37] (Which is archive owner or admins. [11:37] ) [11:38] That said I don't know how derived distributions are using copyPackages. [11:38] Possibly. Sadly, my head is full of CSS garbage so I can't really comment. [11:38] I was still thinking about extending syncpackage to support syncing multiple sources at once. That would have to use copyPackage then, although I imagine the batches used would be small enough not to be a problem. [11:39] maybe a -y flag would be better [11:42] Laney: This is one reason the naming is misleading. Even if syncpackage supports syncing multiple sources, it should use Archive.copyPackage one at a time, because you still want the notifications. [11:44] cjwatson: Sure. The consideration would have been the impact on LP vs. the utility of the notification email. [11:45] I doubt LP will particularly notice the impact of multiple copyPackage calls vs. one big copyPackages call. [11:45] right, particularly at the sizes individual developers will be using it at. [11:46] Unless it's actually a full auto-sync, which I still maintain belongs in a separate tool even if it shares more code with syncpackage than it currently does. [11:53] One of the main benefits is being able to open up this task to non-canonical AAs, which you still get. [11:54] Seems like a sane change to me. [12:08] Laney: Right. [12:09] Laney: Also security. The processes involved in supporting sync-source.py mean, as a side-effect, that archive admins can currently almost certainly forge uploads from any developer if they try hard enough. [12:09] (I mean Canonical-employed AAs.) [12:10] https://code.launchpad.net/~cjwatson/launchpad/remove-sync-source/+merge/88190 up now to kill it with fire === al-maisan is now known as almaisan-away [12:12] where could I find a list of packages that are included on cd ? === 94SAAEC2F is now known as Zhenech_ [12:27] broder: So, what do we need to do to have backports no longer going through archive admins? [12:30] broder: backportpackage looks mostly OK, but (a) I think it should probably use debuild -nc if you're going to be using it for actual uploads, (b) does it need to handle correct versioning of successive backports of the same package?, (c) do you (plural) reliably have privileges to upload the result?, (d) there's still a warning in backportpackage(1) about uploading to Ubuntu although I guess ~ubuntu-backporters can ... [12:30] ... disregard that [12:30] (I know there's the queue admin issue as well, but I don't mean that bit of the process for the moment) [12:54] cjwatson: -nc has already been committed to the repo [12:56] dpkg-architecture -qDEB_HOST_MULTIARCH doesn't work in pbuilder ? [12:57] tumbleweed: oh good [13:03] cjwatson: I'm not sure if anybody found out what the actual effective ACL of -backports is. [13:03] I understand it to be ~motu, but that could be folklore [13:03] ScottK: any clue? [13:04] I'm reasonably certain that's more than folklore, but I've been core-dev so long, I've no actual knowledge. [13:04] Upload a backport from a Main package and see. I can always reject it. [13:05] sure. [13:06] * cjwatson digs through LP code [13:06] It seems unlikely. The do-you-have-permission-to-upload type methods don't generally take pockets. [13:07] I think it was ScottK that told me this initially, so that might explain why he believes it to be the case… [13:07] It probably was me. [13:08] all backports uploads go to unapproved, yes? [13:08] I thought we tested it, but I could be wrong. Not sure who the other part of we was either. [13:08] They do. [13:08] right. uploading. [13:08] To what series? [13:08] oneiric-backports [13:08] ScottK: backports? that was me :) [13:08] Ah. Right. I remember now. [13:08] UDS-N [13:09] The checks are (1) can *anyone* upload to this pocket (i.e. not RELEASE for stable release, or whatever); (2) ACL for sourcepackagename; (3) ACL for packageset/distroseries; (4) ACL for component [13:09] AFAICS [13:09] lib/lp/soyuz/model/archive.py:verifyUpload [13:11] Rejected: [13:11] Signer is not permitted to upload to the component 'main'. [13:11] so I wouldn't be a fully effective backporter. [13:12] Right. So I propose: [13:12] (1) Somebody should file a Launchpad bug to let us have per-pocket ACLs, if there isn't such a bug already. [13:12] Laney: Most backports aren't uploaded by hand. It's relatively rare. [13:12] (2) We look into changing mass-sync.py to use backportpackage (i.e. called by archive admins). [13:12] * ScottK looks at Laney for (1). [13:13] ScottK: Right, but I was asking whether we could have backporters use backportpackage and upload directly rather than going through ubuntu-archive. [13:13] I see. [13:13] I missed the first part of the conversation. [13:13] I want to kill the backdoor interface currently used by backport-source [13:13] It was piggybacking on top of sync-source, and that's in the process of dying [13:14] Unfortunately (2) would mean that archive admins would have to sign backports, which is less than ideal [13:15] (1) isn't trivial; the ArchivePermission model would need to be extended [13:15] But seems like the right answer, ultimately [13:17] Would per-pocket ACLs be required for -security moving to copyPackage too? [13:18] required in as far as there could be security team members without core-dev [13:19] Laney: there are 3 at present [13:20] micahg: how do you handle copies from the security PPA? Have an archive admin do them (using syncSource?)? [13:20] Laney: no, we can copy into -security ATM as long as the API doesn't time out [13:21] so long as you have upload access to the package? [13:21] They have a script that calls an LP API method that has a hardcoded -security check. [13:21] Which is disgusting. [13:21] oh, yikes [13:21] Laney: no, ubuntu-security owns the security pocket AFAIK [13:21] StevenK: so that method checks the person is in ~ubuntu-security? [13:21] I don't recall, and I'm juggling eggs. [13:21] k [13:23] micahg: could you check your script to see which API method it pokes? [13:24] archive.syncSource [13:24] While I wait for 'make' -- we, as in LP devs, want to kill that method. [13:25] Shortly followed by destroying delayed copies. [13:25] hey guys I worked on merging zabbix 1.8.9 [13:26] there is a new version 1.8.10 that fixes a CVE, should we adopt it ? [13:29] cjwatson, Laney, ScottK: changing to per-pocket upload ACLs would contradict the TB's decision about pre-release backports [13:29] (on a train at the moment; wifi is spotty; may come and go) === almaisan-away is now known as al-maisan === dholbach_ is now known as dholbach [13:40] since when did a univeristy need internet access anyway? [13:41] sounds like your sysadmins are learning from ours [13:48] cjwatson: i'm not sure what you meant by "(b) does it need to handle correct versioning of successive backports of the same package?" [13:54] broder: contradict TB> hm, you'll have to remind me how? [13:55] broder: backport-source currently has a thing where if you try to backport the same thing twice you'll get ~oneiric1, ~oneiric2, etc., presumably for rebuilds [13:55] backportpackage only does ~oneiric1 [13:56] cjwatson: https://lists.ubuntu.com/archives/technical-board/2011-November/001137.html [13:57] TB's decision was that the upload ACL for backports should match the rest of the archive === jasox_ is now known as jasox [13:57] dpkg-architecture -qDEB_HOST_MULTIARCH doesn't work in pbuilder ? [13:58] cjwatson: i haven't run into successive backports like that in practice, but it sholudn't be too hard to modify backportpackage to handle it [13:58] broder: "as opposed to " ;-) [13:59] I think I'd like to revisit that given that it was based on a false premise [13:59] and I find the notion of something that a team must approve but cannot directly perform to be a bit bizarre [14:00] I can imagine that we might have wanted to fix the situation where MOTU could upload any package to -backports, but we've just determined by both code inspection and experiment that that isn't the case [14:00] sure :) [14:00] so i guess in that case the goal would be for ubuntu-backporters to be able to upload anything? that certainly seems acceptable to me [14:01] If they're the sole approver for -backports in practice, then that seems sensible [14:01] but if you like, I'll run that by the TB list [14:03] i guess i haven't really dealt directly with enough TB decisions to have a sense of when that's appropriate - whatever you think is reasonable is fine with me [14:33] cjwatson: #914779 [14:33] bug #914479 [14:33] Launchpad bug 914479 in dh-make-perl (Ubuntu Oneiric) "dh-make-perl cache is broken in oneiric" [Undecided,New] https://launchpad.net/bugs/914479 [14:33] erm [14:33] bug #914779 [14:33] Launchpad bug 914779 in Launchpad itself "Pocket maintainers cannot always upload to their pocket" [Undecided,New] https://launchpad.net/bugs/914779 [14:35] ta [15:27] ScottK: do you have an opinion on bug 848916 [15:27] ? [15:27] Launchpad bug 848916 in webkitkde (Ubuntu) "Sync webkitkde 1.1.0git80efcf77-1 (universe) from Debian experimental (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/848916 [15:27] I've been deferring it until I got a chance to talk with somebody who knew about Kubuntu to ack it ... [15:30] cjwatson: It's got no external rdepends or reverse build depends and the reason not to sync has gone away (Debian badly versioned an svn snapshot at one point). [15:30] No objection from me (seems like a good idea) [15:30] OK, great - thanks [15:30] You're welcome. [15:34] Thinking about it, I think I initially deferred that bug because I first saw it when oneiric was frozen and it seemed like a "no way" then [15:37] There was a time when syncing it would have been really bad because it would have replaced a release with a pre-release svn snapshot. [15:37] Nice that's over. [15:42] hi/win 3 === andreas__ is now known as ahasenack [16:04] Hi all... hey guys, there some my merging bugs still pending... is there a motivation why they do not get attention by sponsors, or it's just the queue ? [16:07] l3on: just the queue [16:08] l3on: patch pilots will be back next week as well [16:08] ah ok :) thanks micahg, so I can continue about merging :P [16:08] l3on: please, also, did you get an answer to your zabbix query? [16:09] micahg, nu, I have written again in -devel about some mins ago... still waiting [16:09] l3on: so, to answer your question, you can just wait until 1.8.10 is uploaded to Debian if you believe it'll happen soon [16:10] micahg, Ok, in fact I emailed maintainer, wait for a reply... [16:11] I also have the 1.8.9 debdiff, it introduces a patch to fix FTBFS with ld --as-needed, should I request an upload in Ubuntu ? [16:11] l3on: if you believe 1.8.10 to be coming soon, maybe upstream the ld --as-needed fix to Debian [16:12] ok, I'll do it [16:18] cjwatson: Backporters who are also core-devs could also do (1). I think that's everyone active except me. [16:20] Laney: well, yeah, it winds up much the same thing. Still, the fact that backporters isn't a subset of core-devs indicates that the model needs fixing, IMO [16:22] Right, but it's better than requiring archive admins to be more involved [16:23] also, the number of main backport requests should be on the lower side as they'd be more likely to break things [16:24] hmm. i'm actually kind of curious about that [16:24] * broder runs to hte udd-mobile [16:29] http://pastebin.ubuntu.com/800727/ [16:29] Laney: Isn't that equivalent to (2) anyway? [16:29] Laney: I suppose you might subscribe ubuntu-archive to the backports you approve, or something [16:29] Seems a bit roundabout though :-) [16:31] Should backportpackage gain an option to close bugs, like syncpackage has? [16:31] indeed, just that I wouldn't block it on the permissions bug being fixed though [16:31] (It could do that by putting the bugs in the changelog, which might be more sensible than API closures) [16:31] Laney: oh, right, I don't want to block this on that either way [16:31] Yeah, since we're already adding a changelog entry for backports, I think I'd just as soon do this with changelog closers than separately [16:32] Having mass-sync.py run backportpackage isn't particularly worse than what we have now, and we can incrementally improve from there [16:32] (Except for archive admins who aren't core devs, but realistically, I don't think they're processing backports anyway) [16:33] cjwatson: bugs in changelog won't clost backports bugs. [16:33] Oh really? Bugger [16:33] That'd be another LP change. [16:33] as in you could do 2 right now, and remove the AAs already [16:33] I guess that sort of makes sense [16:33] Ish [16:33] apart from the queue bit I suppose [16:34] broder: I wonder how many of those are ScottK backporting clamav :) [16:34] micahg: 71 :) [16:34] Laney: Right - but we need something equivalent to mass-sync.py until nobody's processes involve subscribing ubuntu-archive to sync/backport bugs any more, anyway [16:35] only backporters should be doing that [16:35] cjwatson: Switching to backportpackage for AAs does have the problem that you now have 2 AA actions to process a backport [16:35] Since it would land in UNAPPROVED [16:35] True, but they often enough land in NEW anyway [16:36] admin [16:36] My motivation is not so much reducing AA workload as weaning us off shell access [16:37] I'm willing to accept some small inconveniences as part of that (not large ones, though) [16:38] More random backports stats, for people who are as easily entertained as me: http://pastebin.ubuntu.com/800738/ [16:40] o/ === al-maisan is now known as almaisan-away [16:41] weird, from intrepid-maverick, main backports outnumbered universe [16:41] oh, except for lucid [16:42] clamav moved to main in Intrepid. ... [16:43] micahg, patch forwarded to upstream and debian :) [16:43] l3on: thanks [16:43] ScottK: ah, that explains it :) [16:43] I suspect it explains some fraction of it. [16:44] well, it won't explain karmic [18:30] hm python and python2.7 provide argparse [18:30] it should only be provided by one of them or? === Quintasan_ is now known as Quintasan [18:37] hm yes as you know can't build the rdepends anymore :( [19:43] so... my sync request for ZNC was approved... broder, if i wanted to have natty and oneiric backports updated for the new release, would i just submit a new backport request bug, and add both natty-backports and oneiric-backports to the bug? [19:43] stating that the backport request is to address a vulnerability in the version that already exists and contains a fix? [19:44] yeah, that sounds right [19:44] mmm [19:44] i'll get to that as soon as i clean my ext4 partition [19:45] got to get the livecd image onto this USB stick here [19:53] broder: should i flag the backport as a security vulnerability thereby making it a higher priority, or is that not necessary? [19:53] * Resistance is writing the backport request now [19:54] i don't know that that accomplishes anything [19:54] because on the sync request i flagged it for the Sec team to review (because ZNC 0.202-2 fixes a DoS vulnerability) [19:58] is it other people's experience that youtube-dl is busted in anything older than oneiric? [19:59] * tumbleweed only uses it on sid and precise, so no idea [20:00] my inclination is to just upload srus of the version in oneiric to the older releases [20:00] sounds reasonable [20:01] broder: whats the bug number for that bug which blocks backported build-deps from being used to build packages for backports (in the archive)? Its on my Linux machine (currently broken due to unclean ext4 partition), not on this machine i have in front of me [20:02] have you tried searching lp? :) [20:02] tumbleweed: with no success, i'll try again though [20:02] search bugs.launchpad.net/launchpad [20:02] Resistance: i don't know - i'd have to go find it [20:02] found it [20:07] dpkg-architecture -qDEB_HOST_MULTIARCH doesn't work in pbuilder ? [20:07] a build that uses it in debian/rules seems to fail, while it build fine on launchpad ... [20:08] broder: Bug #914996 is the new backport request, for when you get around to it. [20:08] Launchpad bug 914996 in Oneiric Backports "Please backport ZNC 0.202-2 from Precise to Natty" [Undecided,New] https://launchpad.net/bugs/914996 [20:08] also tagged it for Oneiric backports too [20:08] dupondje: I see no reason why it wouldn't work [20:14] tumbleweed: well its strange [20:14] try building espeakup [20:14] I get: gcc-4.6.real: error: /usr/lib/libespeak.a: No such file or directory [20:14] espeakup needs fixing for the last espeak update [20:14] I have a branch on lp [20:14] I'm waiting for the change in debian before I apply it [20:15] jtaylor: the current version in ubuntu doesn't build neither [20:15] I know [20:16] it builds on debian as espeak is not yet updated there [20:16] I'm waiting until its done there and going to sync [20:16] ok :) [20:16] the fix is simple [20:16] the same as the libjack multiarch fix [20:16] tumbleweed: ugh. actually, i feel slightly questionable about this because youtube-dl does more than just youtube these days [20:16] and the other sites aren't broken [20:17] jtaylor: there is no bug for it on debian ? [20:18] its not broken in debian [20:18] well not YET I guess ? [20:18] yes [20:18] so its usefull to get it patched before it breaks :) [20:18] you can't [20:19] not cleanly at least [20:19] hehe ok :) [20:19] btw another thing [20:19] what to do with requestsync when the changelog on debian is fucked (aka 404) [20:19] write it per hand :) [20:19] (copy/paste not write) [20:19] i'm lazy :) [20:20] The lazy way is try again a few days later. [20:20] I had such an issue once, it never when away [20:20] debian changelogs are weird since a while [20:22] dupondje: that shouldn't happen any more [20:22] grab a more recent ubuntu-dev-tools [20:22] http://packages.debian.org/changelogs/pool/main/y/yacas/current/changelog [20:23] just doesn't include last changelog ... [20:23] it now gets the changelogs from launchpad [20:24] broder: youtube is still its primary reason for existance [20:25] hrm, I see debian doesn't have it in *stable, but it is currently in testing [20:25] fair enough. i'm inclined to agree, but wanted to see if someone else thought that way as well [20:25] I seem to recall it being in volatile in the past [20:27] broder: I do feel for things like this that once we've started doing it, we need to keep it up [20:28] otherwise there's no trust from the users that youtube-dl in stable releases will work. (I'm sure I keep a git checkout somewhere for when it's broken in debian) [20:32] do you know if it's possible change status to bug via lp-python api ? [20:32] ye [20:32] s [20:32] tumbleweed, I got a bug, and I can add attachment.. but now? [20:33] I saw api, after a quick look I can see the way [20:33] I'm playing with this: https://bugs.staging.launchpad.net/ubuntu/+source/forked-daapd/+bug/896668 [20:33] Ubuntu bug 896668 in forked-daapd (Ubuntu) "Please merge forked-daapd 0.19gcd-2 (universe) from Debian unstable " [Undecided,Fix released] [20:34] so, what's the problem? [20:35] I would like 'confirm' that bug and add subscription :) [20:36] and remove assignment as well [20:36] status is an attribute of the bug_task, not the bug [20:36] you should be able to work it out from the documentation: https://launchpad.net/+apidoc/1.0.html [20:38] ok, thanks :) [21:24] I have a universe package (pianobar) which is badly broken due to external changes. Can I upload a new upstream version, packaged in Precise, which fixes this bug (among other things?) [21:24] Fixing the bug in a cherrypick has proven difficult. [21:27] I would upload the fix and be explicit about what you're doing in the bug description, and let ubuntu-sru make that call when they review it [23:25] lfaraone: We're a month before feature freeze, so a new version is no problem. [23:26] ScottK: Sorry, I meant to oneiric. [23:26] If it's very badly broken that's sometimes acceptable, so as broder said. [23:26] Make sure it's in precise first.