[01:54] Does LP accept orig.tar.bz2's yet? === ursula_ is now known as Ursinha [02:37] NCommander: for what? [02:37] thumper, uploads of orig.tar.bz2 [02:37] NCommander: ah, sorry not sure [02:45] NCommander: I don't think so. === henninge-zzz is now known as henninge [07:53] hi, [07:54] is it possible to create a new user on staging.lp.net? [07:55] or won't this work because the registration email will not be sent [08:01] thekorn: It won't work, for that reason. [08:03] wgrant, hmm that's what I suspected, how unfortunate [08:04] Indeed. [08:04] thekorn: Why do you need it?\ [08:06] wgrant, I'm about to add a function to py-lp-bugs to add/accept/decline bug nominations, [08:06] and I need to test the case of accepting a nomination, [08:07] as on all projects where I'm allowed to accept a nomination, my nomination is auto-accepted [08:08] so my idea was to create another user on staging [08:09] thekorn: Want me to nominate some stuff on staging for you, in that case? [08:11] wgrant, sounds like a good plan, but I'm not there yet, [08:12] * wgrant wasn't aware that nominations were exposed through the API yet. [08:12] thanks, will come back to you (or others) when I have some usable code, [08:13] no not the api, good old python-launchpad-bugs ;) [08:13] Ah, the lovely screenscraping backend? [08:13] I had hoped that could be killed soon. [08:15] * thekorn too [08:15] thekorn: Is the API still much slower? [08:16] wgrant, no the API is great, and fast [08:16] but lacking some (important) functionallity [08:16] Hmm, I remember originally it was substantially slower. [08:16] especially regarding bugs [08:16] yes, but this is fixed in many cases [08:17] Ah, excellent. [08:25] thekorn: what functionality is on top of your priority list? [08:25] today i'm landing CVE management APIs, b.t.w [08:26] intellectronica: Yay, finally! You rock. [08:30] intellectronica, hi, managing bug nominations and searching users buglists [08:30] this are two things I know of why people are still using py-lp-bugs [08:31] thekorn: cool. i think nominations should be ready this cycle. hopefully user task lists searches too [08:32] great, super === salgado-afk is now known as salgado === verterok_ is now known as verterok === matsubara-afk is now known as matsubara === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell === beuno_ is now known as beuno === salgado is now known as salgado-lunch === bureflux is now known as afflux === jcastro_ is now known as jcastro === matsubara is now known as matsubara-lunch === kiko is now known as kiko-fud === thekorn_ is now known as thekorn === matsubara-lunch is now known as matsubara === salgado-lunch is now known as salgado === ahasenack is now known as pandora === kiko-fud is now known as kiko [17:01] leonardr, hi, I've got one question about authorize-token, what does the access level "read non-private data" mean? [17:01] and especially, [17:02] let's say I'm hiding the time_zone/map in the web UI, [17:02] will this also mean that I cannot access me.time_zone with launchpadlib [17:05] thekorn: in general you will only be able to see information you can see when logged in [17:05] er, when _not_ logged in [17:05] so if it's hidden, me.time_zone will probably show up as redacted [17:05] there's a tag: value for redacted which you can check [17:06] ok, that's what I expected, [17:06] but me.time_zone shows "europe/Berlin" when using "read non-private data" [17:06] and it's hidden on my profile [17:07] in that case the code to hide that data is probably in the view and not in the data model [17:08] would you file a bug for that? (in launchpad-foundations) [17:08] leonardr, yes will do [17:25] flacoste, hey [17:25] I am wondering, how could this bug be filed in 2002: https://bugs.edge.launchpad.net/mailman/+bug/265736 [17:25] Launchpad bug 265736 in mailman "QRUNNER is fucking the machine perform.." [Low,New] [17:26] MagicFab: bug import [17:27] altough the bug number seems kind of high for a bug import [17:27] barry: any ideas ^^^ [17:27] and yes I was curious what bug reports would "offensive" :) [17:27] that was likely imported from SF [17:27] barry: with such a high bug number? [17:28] barry: you ran the import a while ago, no? [17:28] o [17:28] 265 isn't that high [17:28] gmb did the import before epic [17:28] ah ok [17:28] it's recent then [17:28] yep, and see the sf608524 tag. that points to the original SF bug number [18:29] barry: ~30 minutes until your session! [18:50] jcastro: oh! i almost forgot [18:51] barry: no worries, that's what I'm here for. [18:51] * barry wishes he was actually prepared ;) === salgado is now known as salgado-afk [20:15] Hello [20:15] someone here? :S [20:16] I have a problems with requesting cd of ubuntu on my account :S [20:16] can someone help me? [20:17] kattollikisd, what's the problem? [20:20] I resqueting cd for ubuntu ... and now I see this [20:20] ups sorry [20:20] I gonna poste it in a paste bin [20:21] kattollikisd, on shipit.ubuntu.com? === kiko is now known as kiko-afk [20:21] http://paste.ubuntu.com/68973/ [20:22] kiko, yes [20:23] do you know how to erase all that list so then I start in 0 to resquest cd over agiang [20:23] ? [20:27] kattollikisd, I don't understand the problem. [20:27] kattollikisd, is the problem that your requests are being denied? [20:29] yes kiko-afk, that the problem, sorry for my english... I don' t know to much about the lenguage :S [20:34] kiko-afk, that' s the problem :S [20:46] kiko-afk ? [20:51] Is there a way to list all {supported,current,development} distroseries using the LP API? [21:06] kattollikisd, what's your launchpad ID? [21:11] kiko-afk, Kattollikisd [21:14] kattollikisd, I'll check with somebody why your CDs are being rejected. how many are you requesting? [21:16] I haven' t request CD for the 8.10, but I request like 5 o 6 cd of the 8.04 ( of then... I had just 2 ) [21:16] I requested 5 or 6 cd but not as a special request. [21:17] kattollikisd, I wonder why your request was declined then. odd. [21:17] the last special request that I did was at the time of the 7.10 [21:17] :( [21:17] let's figure this out [21:17] ok :S [21:19] kattollikisd, make a new request. [21:19] on shipit.ubuntu.com [21:20] hmm [21:20] Laney: it doesn't look like you can. :( [21:20] actually, I found it [21:20] quit [21:20] Urr. [21:20] bac: That was my conclusion too [21:20] kattollikisd, I'll look into this on monday when there's somebody back in the office ok? [21:20] anyone: What project do I file bugs against for the LP API? [21:20] Laney, launchpad [21:21] got it [21:21] Laney: yes, please open a bug. that'll get the ball rolling. [21:24] can Launchpad host shared repos? [21:25] bac: Bug #295338 [21:25] Launchpad bug 295338 in launchpad "Export API functions to get current distroseries for a distribution" [Undecided,New] https://launchpad.net/bugs/295338 [21:26] kiko-afk, ok... so monday I have to be here right? [21:31] kattollikisd, I'll sort it out, you don't have to be around [21:34] ohhh... thanks kiko-afk, a lot of thanks you [21:34] no worries [21:34] ok byebye [21:34] ohh wait :P [21:34] sorry I.. I just have another question [21:36] If I create anocher account for Kubuntu.. If I put the same address that I have in the ID kattollikisd [21:36] Their cd will arrive ? [21:38] at the same address? === matsubara is now known as matsubara-afk [21:46] LaserJock, set up a branch to which multiple people can write. Instruct users to use it as a bound branch (or is that not what you meant?) [21:56] persia: no, I meant, I have a shared repo, can I push that to LP or not? [21:58] Oh. That's not a question for wihch I know a workaround :) [21:58] I've built some branches for packaging [21:58] and they're in a shared repo so I'm trying to figure out what I want to end up pushing [21:58] If I create anocher account for Kubuntu.. If I put the same address that I have in another Id of the Launchpad, those Cd that I request will arrive? ( The other ID launchpad is mine, is for Ubuntu ) [21:59] kattollikisd, Best practice is to have only one launchpad account per person. [22:01] persia, oh thanks [22:26] Error ID: OOPS-1042EB133 [22:27] Error ID: OOPS-1042EC97 [22:27] * Hobbsee sighs. [22:27] This was working. You haven't rolled out since the ubuntu release. Why is it broken again now? [22:29] OOPS-1042G3321 is the corresponding production oops. [22:29] https://devpad.canonical.com/~jamesh/oops.cgi/1042G3321 [22:31] Error ID: OOPS-1042H3298 [22:31] https://devpad.canonical.com/~jamesh/oops.cgi/1042H3298 [22:43] Hobbsee: it's weekend, isn't that enough for LP to break? [22:43] geser: I can't answer that one, without getting yelled at by kiko-afk and such, i'm afraid. [22:45] LaserJock: You don't push repos. You push branches. [22:46] wgrant: right, but is there a way to create repo structure on LP? [22:46] LaserJock: If pushing each branch completely is too slow, you might want to upgrade to bzr 1.6 and use stacking. [22:46] No, that doesn't make sense. [22:46] hmm [22:47] so I've got some branches for a project [22:47] but I didn't feel like pushing everything [22:49] Then don't push all of them. [22:50] heh [22:50] I meant, I'm sort of trying to figure out if I can/should push the whole lot or not [22:51] Hmm, what do shared repositories have to do with that? [22:51] I assumed it would be easier to push if it were to a shared repo [22:51] Actually, I think there is a plugin that will let you push all branches in a repo. [22:51] But you can't push the repo itself. [22:52] plus it organizes everything nicely [22:52] And it'll be slow unless you're next to the DC or use stacked branches. [22:52] How does it organise things nicely? ~mantha/someproject/* isn't nice enough? [22:52] no [22:53] because I want to split them further [22:53] Oh. [22:53] and have debian and ubuntu repos [22:53] Shouldn't you just have debian and ubuntu branches? [22:53] no, I also have upstream branches for each [22:54] Why do you need separate upstream branches? [22:54] so I have debian, debian-upstream, ubuntu, ubuntu-upstream [22:54] Wouldn't just upstream, debian, ubuntu work? [22:54] because it's not the same [22:54] debian and Ubuntu don't always share upstreams [22:54] Not the same upstream, or not the same revision? [22:54] umm, it's the same upstream, but different "revisions" [22:55] where revision is a basically a tarball import [22:55] Right, so just have the debian and ubuntu branches branch from different revisions. [22:55] In mplayer we have upstream, ubuntu and ubuntu-upstream. [22:55] wgrant, Why? [22:55] There's no right way to do this, because the way it's done now is wrong. [22:55] * persia thought that was what vcs-imports was supposed to do. [22:55] ie. the whole idea is wrong. [22:56] persia: vcs-imports manages the upstream branch. [22:56] IIRC [22:56] I'm not doing anything with a vcs-import [22:56] But we're not derived from the upstream branch; we're derived from the tarball. [22:56] Which is why bzr packaging currently sucks. [22:56] RIght, and then one merges the upstream into the packaging branch every once in a while, right? [22:56] Isn't that just a matter of making sure the tarball matches a given revision? [22:57] The "process" (It has only been done a couple of times) is grab a new tarball, strip the code out of ubuntu-upstream, put the new code in, and merge the change into ubuntu. [22:57] It would be lovely to be able to do that from the upstream branch itself, but I think mplayer might do Bad Things. [22:58] Ugh. That's the worst mix of VCS packaging and traditional packaging I've ever heard described. [22:58] Yep. [22:58] I wasn't entirely pleased when I discovered it... but it was apparently one of the earlier bzr packaging attempts. [22:58] so if I were to do a vcs import I'd then have 5 branches :/ [22:59] Having *-upstream or upstream-* branches is probably a bug. [22:59] perhaps it's better to just ditch it all and create an ubuntu branch that's debian/ only [23:00] I think it's better to wait until james_w fixes the world. [23:00] well, I don't exactly have that time very well [23:00] I'm trying to get some collaborative packaging going [23:01] and I'm not waiting for another release to get that going [23:01] LaserJock, The only VCS packaging system I've seen I liked was to have a vcs-imports branch for upstream, from which were derived distro branches based on a given revision. [23:01] persia: umm, what if there is not upstream VCS? [23:01] persia: That's how it should be. [23:01] *no [23:01] LaserJock: Then upstream needs to be shot! [23:01] Doing debian/ only in VCS is a somewhat limiting compromise, but also works. [23:01] Anything else is painful. [23:02] Who broke the team pages? [23:02] the problem is that I want to work with Debian [23:02] and if I can upstream [23:02] but there's really no good way to do it via vcs [23:02] If there *really* isn't an upstream VCS, you can fake one by unrolling tarballs, but do it sequentially, and pretend it's a pristine upstream VCS. [23:03] for one of the projects there is no VCS at all [23:03] persia: Does https://launchpad.net/~xorg-edgers have a black menu of death? [23:03] LaserJock: Uhm, wow... that's not good. [23:03] wgrant: heh, and it's a Main package but I won't go there too much since I put it in [23:03] "black menu of death"? No, it has a menu on the left. [23:04] persia: OK, how odd. [23:04] I thought team pages had a black menu last release. [23:04] But it seems that only the PPA does. [23:04] How very confusing. [23:04] LaserJock: Eww. [23:04] persia: you have a menu on the left? I have one on the right [23:05] The UI seems to be undergoing a transition that exposes how much of the modularity is encapsulated on a per-display basis. [23:05] * persia has apparently enabled the "mirror" function in the text above [23:05] persia: But this has been going on since before 2.0 was released :( [23:05] And I hear it's all going for another revamp for 3.0. Yay. [23:06] Completely redesign LP's UI every year for three years. Good policy. [23:06] wgrant, Yes. There are a lot of display views. I'd like a consistent UI, but I'm not sure that having one is related to version numbers. I'm looking forward to the mockups beuno is likely to bring to UDS. [23:06] From what I understand, consistency and sensible modularity are key items of the plan. [23:06] That would be good. [23:07] persia: do you have any good ideas if I were to have a vcs-import and then want to import the Debian packages? [23:07] But it's getting a bit silly, having each UI transition only partially completed before remaining bits are rejected because of the next UI redesign. [23:07] LaserJock: You might want to discuss this with james_w, I think. [23:07] wgrant: that's how I got where I am ;-) [23:07] Oh dear. [23:08] he gave me code to import everything and now I don't know how to do anything with the branches I got [23:08] I've got a few hundred MBs of bzr branches here that I don't know what to do with [23:08] LaserJock, Well, what I did last time I did that was to collect a set of debdiffs for the last several versions in Debian, and construct a derived branch with a bit of history. If Debian already has stuff in a VCS, you could create a vcs-importer for Debian as well. [23:09] none of the projects have vcs in Debian [23:09] so that's the hard part [23:09] Then create a stub branch of the last few uploads, and do the right thing in the future. [23:09] I don't have any clue of where Debian is derived from [23:09] If you want this to be not so labour-intensive, wait for james_w to VCS the world. [23:09] That would be my suggestion too. [23:10] It's not going to be an easy transition, but it will be so much better when it's all done. [23:10] Especially if Debian adopts bzr, but that's never going to happen. [23:10] well, I guess until then I can just put ubuntu into VCS [23:10] wgrant, Why won't it be an easy transition? The last several years of upload revision diffs are available to construct stub branches, and with automation, it ought be mostly invisible. [23:10] so we do a vcs-import where possible and branch off ubuntu branches [23:11] persia: I guess I'm just a bit pessimistic because of my previous experiences with bzr packaging. [23:11] LaserJock, For Ubuntu-local, that would be the right model. [23:11] I can then just manually update the ubuntu branch when Debian uploads something new [23:12] For upstream->Debian->Ubuntu, we'd want a Debian branch, which might be vcs-import, and might be constructed, depending on the Debian maintenance. Ideally, this can be determined from debian/control. [23:12] When Debian updates, apply the Debian changes to the Debian branch, and then merge those changes into the Ubuntu branch. [23:12] sure, if only things worked that way ;-) [23:14] I'd guess maybe 5 of the ~20 packages I'm trying to do use vcs's in Debian [23:14] wgrant, I was incredibly pessimistic until I saw what cjwatson was doing with the d-i stuff. Now I'm of a mixed mind : I still don't like bzr much, but with well organised branches and some automation, it's not that bad (although I avoid bzr bd : I've never had it do the right thing). [23:15] LaserJock, So? MoM generates debdiffs for each Debian upload. Just apply the debdiiff in the branch, and commit. [23:15] If Debian pulls a new upstream, merge against the new upstream first, and only apply the diff of the packaging changes. [23:15] (and commit inbetween). [23:15] persia: Why don't you like bzr? [23:15] Mind you, I think your life would be easier if you just did it the traditional way until there is better infrastructure. [23:16] persia: how would I know what upstream to merge against. In fact I'm not sure I can do that [23:16] wgrant, From what I understand, mostly because I'm not running a new enough version to include the latest speed improvements, and because I don't understand how to use shelve very well. [23:16] some upstreams don't have a revision that corresponds exactly to the tarball [23:16] shelve is awesome [23:16] LaserJock: Exactly the problem that I've found. [23:17] The constant upgrades are somewhat troublesome, too. [23:17] like a lot of upstreams I know run autogen.sh between the VCS and tarball [23:17] Indeed. The concept behind shelve is why I still work by flipping around patches, and patchutils is my core set of tools. [23:17] It's particularly surprising giving that they are coming from the same company that enforces Ubuntu release structures. [23:18] wgrant, Hrm? bzr releases on a schedule doesn't it? while things get deprecated, little seems to break. It adds to the list of reasons I don't like bzr, but I'm not sure how it's dissimilar to how Ubuntu is released. [23:19] It's not too dissimilar from how Ubuntu is released. [23:19] It's just completely incompatible with it. [23:19] You're told you should always be running $LATEST_BZR_VERSION to fix $CRIPPLING_SPEED_ISSUE. [23:19] Well, unless you're in London. [23:20] well, I'm pretty sure I'd use for packaging svn if LP supported it :-) [23:20] svn now has merge tracking, so it's not such an awful choice. [23:20] svn is just so much simpler [23:20] Except you probably can't do cross-repo merging. [23:21] LaserJock, is svn better than bzr? Previously, I'd claim that bzr merge made it superior. Now, I'll claim that bzr shelve makes it superior (even though I still don't understand shelve as well as I'd like) [23:21] I fail to see how svn is simpler. [23:21] you don't have to think about formats, repos, merges, blah blah [23:21] Yes you do, they just change less frequently. [23:21] I couldn't care less about merges, etc. [23:21] I just want revision control that's simple [23:22] bzr is nothing but trouble for me, for what I do [23:22] I can see how it's awesome for some things [23:22] You want to do VCS packaging, and you couldn't care less about merges? That's the *reason* to do VCS packaging. Otherwise, just VCS debian/ and ignore the rest. [23:22] exactly [23:22] I just want debian/ versioned [23:22] Then you only need one branch. The "ubuntu" branch. [23:22] yep [23:22] it contains debian/ [23:23] Throw away the rest of it. [23:23] like I said, if LP supported svn I'd do just that [23:23] but since it doesn't I end up getting peer-pressured into all the merge stuff, etc. ;-) [23:23] I don't see how svn is simpler than bzr for svn-like workflows. [23:23] Mind you, this gives you almost none of the advantages of VCS packaging, and nearly all the disadvantages. Only worth it if you expect to have many people touching the package, and have some reason to delay between uploads. [23:24] wgrant: because people laugh at you when you do svn-like workflows [23:24] Given that there's no unstable->testing delay in Ubuntu, seems fairly pointless to me. [23:24] Anyway, shouldn't we be having this conversation in -motu ? [23:24] Lots of people use bzr just like svn. [23:24] Probably. [23:25] Or even -devel. [23:25] -devel probably makes more sense. [23:25] well, my original questions were about LP [23:25] but yeah, we've floated more into packaging [23:25] Indeed :) [23:26] Hello people. Why "Registry Administrators" (~registry) is member of the "Ubuntu Tunisian Team" (ubuntu-tn-user) ? That's making sabdfl member of the tunisian team and it's making some noise ^^ [23:27] ~ubuntu-tn-users, sorry [23:36] be back tomorrow, gn