[00:01] thats in the api definition at the moment [00:01] on +apidoc [00:01] I don't know what it looks like in wadl [00:03] lifeless: I mean, how do I derive 'getFooByName(name="bar")' from "foos['bar']" without defining that in the WADL? [00:05] wgrant: its the other way around [00:05] wgrant: you compile the wadl right? [00:06] wgrant: hell, even if its interpreted [zomg], when you create an object 'base', you could do: [00:06] for method_name in wadl-methods-for-base: if methodName.startswith(get): [00:06] collectiontype = wadl.returntypeformethod(methodName) [00:07] and so on [00:07] I think that's well within the realms of fragile evil. [00:07] wgrant: compilers do this all the time [00:07] It *will* break with the methods we have exposed now. [00:07] wgrant: I haven't looked at whether wadl is interpreted or compiled, but I'd expect compiled [00:07] wgrant: how ? [00:08] lifeless: Distribution.getSeries takes name_or_version, while others take just name. Other getters are getFooByName, rather than just getFoo. Still others use a shorter name than the corresponding collection. [00:09] Making assumptions like that seems really evil, when it's easy to do it properly. [00:09] wgrant: I have no idea how hard wadl is to change, so I can't assess difficulty there [00:51] Hey, I really want to use quilt 3.0 in karmic PPA but getting a rejection email from Launchpad. Is there any way around this? [00:54] Daviey: No. Karmic's dpkg doesn't quite fully support 3.0 (quilt). [00:56] wgrant: damn, trying to think of a sane work around [00:56] Daviey: 'do not do it' :) [00:59] Daviey: It's trivial to convert to 1.0... [00:59] (unless you have multiple orig tarballs) [01:00] what's the best/easiest way to check if I've an anonymous or non-anonymous login to the LP API? [01:00] i suppose that is our only option. :/ [01:01] geser: check what api functions you are using in code, or mv your auth file :) [01:01] geser: Check if launchpad.me returns a 401, perhaps. [01:03] wgrant: looks like this seems to be the best way [01:09] Daviey: I've written some wrapper code around the LP API for usage in ubuntu-dev-tools and now also added support for anonymous login and looking for a way to do isAnonymousLogin() which could be used for guarding code that needs non-anonymous login [01:10] ah [01:13] Hi [01:13] The launchpad OOPSes are becoming pretty annoying lately. Today's oops is OOPS-1513K110 [01:13] https://lp-oops.canonical.com/oops.py/?oopsid=1513K110 [01:14] Laibsch: What were you doing at the time? [01:14] reporting a new bug against git-buildpackage [01:14] patch included, ready for sponsorship [01:14] so I feel it's slightly more important than average ;-) [01:15] And launchpad completely forgot about all the text I entered :-( [01:16] wgrant: Is there any way to recover the text I entered without hitting the page refresh button? Going back, I lose all entries. Hitting refresh, I get another oops. [01:16] hrm [01:17] NotImplementedError [01:17] Ah, that one. [01:17] What's the URL? [01:17] http://paste.ubuntu.com/380681/ [01:17] is the full traceback [01:17] What was the request URL? [01:17] from https://launchpad.net/ubuntu/+source/git-buildpackage/+filebug [01:17] Hm. [01:18] to https://launchpad.net/ubuntu/+source/git-buildpackage/+filebug-inline-form [01:18] thanks guys, for taking a look [01:18] Well, it's probably bug #508302. [01:18] Launchpad bug 508302 in malone "NotImplementedError OOPS when reporting a bug" [High,Fix committed] https://launchpad.net/bugs/508302 [01:19] Laibsch: What happens if you try on edge.launchpad.net instead? [01:19] It's meant to be fixed there. [01:19] I will have to start from 0 in edge, right? [01:20] Yes, unfortunately. [01:23] will the sync from launchpad happen automatically? [01:23] What do you mean? [01:23] edge.launchpad.net uses the same database, just with newer code. [01:24] I'd just let the tab open and hit refresh page if all I have to do is what a couple of hours for regular LP to catch up and be updated [01:24] with the fix [01:24] Production will not be updated with the fix for nearly two weeks. [01:28] (yes, this sucks. there's a process redesign in progress that should make it a lot less slow.) [01:41] in times like these all this AJAX really sucks [01:55] hi [02:06] wgrant: you're telling me this will take two weeks before it's fixed on the main site? [02:06] incredible [02:09] Laibsch: It occurs in very few situations. [02:09] I see [02:09] that's at least some consolation [02:09] but I seem to magically attract them [02:09] I've got another one where I can't convert a bug to a question [02:10] And the problem here appears to be that it crashed while rejecting your input. So it wouldn't have worked anyway -- it just didn't display the right error message. [02:53] hi there [02:53] I tried to register the project "squeak" but it says that it is already in use [02:53] I would like to know where [02:54] any ideas? [02:54] I found squeak-vm [02:54] in ubunto [02:54] ubuntu [02:56] keithy: That normally means that there has been a squeak project created in the past, but it has been deactivated. [02:56] k [02:56] cant I nab it? [02:56] I might have been the culprit [02:56] keithy: If you ask at https://answers.launchpad.net/launchpad/+addquestion, an admin can either reactivate it or free up the name for you. [02:59] k done [02:59] now I wonder if anyone is awake [03:01] Unlikely, given that it's a weekend and both the Americas and Europe are asleep. [03:02] There ought be some folk still up in the Americas, but not likely acting as admins. [03:04] k === nhandler_ is now known as nhandler === nhandler_ is now known as nhandler [05:19] is there any issue with the ppa build system applying patches? [05:20] bjsnider: It's very probably a bug in your package. [05:20] The PPA build system just does what your package tells it to. [05:20] the patches apply in pbuilder but the ppa system ignores them [05:20] Link? [05:21] configure-arch-stamp: $(QUILT_STAMPFN) [05:21] that's the rule [05:21] We just call dpkg-buildpackage. [05:21] QUILT_PATCHES=debian/patches quilt --quiltrc /dev/null pop -a -R || test $? = 2 [05:21] No patch removed [05:21] that's it [05:21] Where is the build log? [05:21] then it goes on [05:22] http://tinyurl.com/yjkzyqw [05:24] bjsnider: That's in the clean rule. [05:24] It's removing patches there. [05:27] could it have been some problem that was momentary? [05:27] bjsnider: Do you actually call the patch target at all in debian/rules? [05:27] It does not look like it. [05:27] i didn't design the rules file [05:27] it's mplayer's rules file [05:27] i don't want to go messing with it [05:29] quilt.make is included, quilt_stampfn is called int he configure target and unpatch is called in the clean target [05:30] maybe this thing is too old to work anymore or something [05:32] bjsnider: Have you built it in a clean Karmic environment locally with both PPAs activated? [05:32] exactly so [05:32] The Launchpad build system doesn't magically go around messing with your rules file, so it is probably a bug there. [05:36] it looks from the build record like configure-arch-stamp isn't being called at all [05:36] how can it do something like that and not spit out an error [05:37] install-arch doesn't depend on it. [05:37] So it's unsurprising that it's not called. [05:39] install-indep-stamp does [05:40] bjsnider: But binary-indep is only called on one arch. [05:40] i386. [05:41] And indeed, the i386 build shows the patches being applied. [05:41] This is what is known as a bug in that horror of a rules file. [05:41] and guess what? the patches are applied in the i386 build [05:42] i just pulled this rules file out of the karmic build. [05:42] this should be a problem witht he karmic build of mplayer [05:42] unless i've been screwing with it in my sleep [05:43] It could well be. [05:44] so if i add configure-arch-stamp to install-arch, everything will be fine [05:44] Probably. [05:44] But watch for unintended side-effects. [05:44] but this raises another wuestion [05:45] why did pbuilder build this correctly on amd64? [05:45] it applied the patches [05:45] pbuilder probably builds arch-indep by default wherever it runs. [05:46] But because we build it on multiple architectures, we can only build arch-indep on one arch. [05:46] Otherwise we'd have multiple conflicting arch-indep binaries. [05:49] pbuilder does do this. [05:49] One of the nice features about sbuild is that one can use (or not use) the -A flag to test both classes of build. [05:49] (someone should add this feature to pbuilder) === hersoy is now known as ersoy [11:20] persia: it's already there "pbuilder build --binary-arch ..." [11:20] geser: Cool! Thanks for the hint. [11:23] the defaults between sbuild and pbuilder just differ: while with sbuild you have to specify that arch-indep should also be build and with pbuilder you have to specify that only arch-dep should be build [12:12] is there a plan to add ARM archictecture to launchpad builders ? [12:13] AnAnt: That relies on there being a reliable and secure ARM virtualisation technology. [12:14] I see [12:14] the reason I ask is because it seems that ARM is being used in many stuff recently: netbooks, and that new Nokia N900 that got Debian on it [12:14] It's something that a lot of people want. [12:15] It's just not technically possible yet. [12:15] which gives me the impression that ARM would be as popular as i386 & amd64 [12:15] AnAnt: Have you seen any good servers? I can't imagine a collection of N900s in the data centre :) [12:15] persia: servers ? for what ? [12:15] Building the packages? [12:15] persia: erm, I dunno what Debian guys do [12:16] They have a collection of NAS boxes, but those can't run Ubuntu (too old) [12:16] also, those can't handle virtualisation (as mentioned previously) [12:16] what's a NAS box ? [12:17] Network Attached Storage. I believe the Thecus is the model of most of the Debian buildds. [12:17] Are there any actual implementations that use ARMv7's virt extensions? [12:18] Not that I've seen, but my experience is limited to the i.MX51, and I know that other implementations are better suited for server stuff. [12:18] (i.MX51 doesn't even have a drive controller available) [12:18] Hah. === Hamaryns|weg is now known as Hamaryns [12:18] The lack of ARM hardware is disappointing. [12:19] persia: I remember that you were involved in making Ubuntu for netbooks/MIDs, right ? [12:19] Well, the devices I've seen in retail (Efika MX, Netwalker) have "4G SSD" which is really just through MTD flash. [12:19] AnAnt: For MIDs, yeah. [12:20] * persia is philosophically opposed to the concept of "netbook" [12:40] wgrant: Do you happen to know if Soyuz sbuild still has features not supported by Ubuntu sbuild? [12:41] persia: It writes info to /CurrentlyBuilding and copies ddebs into ~/public_html, but that's about it. [12:43] $log_dir is easy enough. I'll have to hunt about ddeb copying. [12:44] $log_dir? [12:44] Also, why? [12:45] Oh, /CurrentlyBuilding isn't $log_dir, right. [12:46] And because it'd be nice to have the same codebase so that I knew that if something worked in Ubuntu it ought work in Soyuz. [12:46] Right, that would make sense. [12:46] /CurrentlyBuilding has the archive purpose and component and the like. [12:46] But we have code to write that from outside sbuild now, so it's not critical that sbuild support it. [12:47] So it can be written on dispatch? [12:47] Which means that once LP supports ddebs, stock sbuild would probably just about work. [12:47] Right. [12:47] We already do it for source package builds. [12:48] lamont: Did you ever track down that old lp-buildd repository so we can find the complete Debian->Soyuz diff? [12:48] The trivial way to handle ddeb copying in the meantime would be to use schroot scripts. [12:49] Right. [12:49] It can't be any more of a hack than it is now. [12:50] It's just a few extra lines in sbuild to glob for and tar up ddebs, then copy them to ~/public_html/ddebs, where another external hack picks them up later... [12:51] How hard would it be for Soyuz to understand them natively? [12:51] I have most of the work done. [12:51] Are you likely to complete prior to lucid being deployed? [12:51] But, well, it breaks assumptions that a lot of code makes. [12:51] It's unlikely. There are non-code barriers too. [12:51] Ah :( [12:52] (librarian space, removal policies, that sort of thing) [13:13] Hi [13:13] guys I messed up a launchpad-foundations bug [13:13] Actually I was just playin with the status but I didn't know I could change it... Since I've nothing to do with this project I mean I'm not even subscribed in [13:13] Could someone check it out ? https://bugs.launchpad.net/launchpad-foundations/+bug/240067 [13:13] thx [13:13] Ubuntu bug 240067 in launchpad-foundations "Launchpad needs a wiki" [Low,Confirmed] [13:14] here it is [13:52] someone may wish to kill https://edge.launchpad.net/ubuntu/+source/ghc6/6.12.1-9/+build/1512008 [13:53] it's been going for days and I uploaded a new version of the package anyway === rmcbride__ is now known as rmcbride [14:03] Laney: You may find that running emulated builds to ensure they *can* complete is a good idea :) [14:04] persia: Actually, I made a pbuilder-armel chroot and it doesn't work :( [14:04] just ends up spinning "unsupported operand" [14:07] Laney: unsupported operand? Not unimplemented syscall? [14:08] maybe [14:08] let me do it again [14:10] There's a few syscalls (most noticeably for me 335) that aren't implemented, but builds should succeed. [14:10] unsupported syscall 335 [14:10] stderr fills with junk, but that doesn't affect the actual processing. [14:10] I didn't wait for too long [14:11] Yeah, just ignore that. [14:11] 276 comes up once in a while too. [14:11] But I've been able to run the binaries created that way on hardware, so I don't believe it matters much. [14:12] makes the build logs huge though :( [14:13] Indeed. I complained about that, but was told that it was better to have the errors than hide them. [14:13] I'd rather only report the error once per session or something. [14:13] But I'm not sufficiently knowledgeable to implement the syscalls, which was what was suggested to my continued complaint. [14:17] oh hey, it did finally finish! [14:18] Your pbuilder, or the ghc6 build on jaboticaba? [14:20] the pbuilder update [14:20] Yeah, it's just slow. My armel schroot update seems to take forever each day. [14:20] 225M log file just from doing that [14:21] That's *huge* I only get 161MB building mono. [14:21] Well, almost 162. [14:22] But that's 5 *million* "qemu: Unsupported syscall: 335" lines. [14:24] it goes up by 1-2M every 2 seconds [14:24] * Laney is `watch'ing it [14:26] RIght. Any nifty ideas as to how to trap that? Maybe we can put a filter in the output chain, since the qemu folk don't seem to want it on input? [14:27] oh, hey [14:27] Because we *know* that it's going to mostly be "Unsupported syscall: ###\n" [14:27] bug 520480 [14:27] Launchpad bug 520480 in qemu-kvm "pselect support (qemu: Unsupported syscall: 335)" [Medium,Fix released] https://launchpad.net/bugs/520480 [14:29] hm, I *do* have that version [14:29] maybe I need to rebuild the chroot? [14:29] And you're still getting that message? [14:29] I bet lool would be glad to try to fix it. [14:30] (he being the person who told me to go implement it when I complained) [14:48] persia: yeah, it's better with a new chroot [14:49] Laney: So it needs a complete new chroot, rather than just getting updated with the new version? [14:49] seems to be so [14:49] * persia suspects copying /usr/bin/qemu-arm-static might work, and tries that to see if a new chroot can be avoided === wers is now known as wers|brb [14:50] however, qemu doesn't implement a syscall that it seems ghc requires [14:50] qemu: Unsupported syscall: 257 [14:50] ghc: timer_create: Function not implemented [14:51] Hmm. Is it supported on the buildds? [14:51] must be, else the build would have died in configure [14:52] remap_file_pages [14:54] Hrm. It's at least implemented for neo1973 in qemu. === wers|brb is now known as wers [15:09] What needs to be done in order to be able to set one project as a sub project of another ? [15:13] nhandler: Create multiple projects, ask a question to have one of them be a superproject. [15:14] persia: Thanks. I wasn't sure if the question was necessary (as I noticed a new subproject box under the edit details page) [15:15] Oh, it might have changed. My information is probably a year old or more. [15:29] Laney: That particular syscall (335) has actually been implemented now [15:29] lool: yes, I saw ;) [15:29] Laney: Use the lucid up-to-date qemu-arm, and you wont get it [15:29] Laney: Ok; any other issues with your pbuilder-armel? [15:30] lool: yes, unsupported 257 [15:30] fails the build unfortunately [15:33] Laney: Ok; it might be possible to implement it in qemu-arm, but it looks complex since there's a callback mechanism in this sycall [15:33] Laney: It seems quite harder than 335 TBH [15:34] Laney: I would suggest you use qemubuilder instead [15:34] That runs a real vm, so should work [15:51] I've download a project with bzr, how do I update the project? [15:55] flower: https://help.launchpad.net/Code/QuickStart [15:58] $ bzr update [15:58] lool: will try, thanks [16:32] wgrant: yeah - I have it somewhere, should upload === qense_ is now known as qense [17:31] Hi there. How long does it usually take to be approved for the launchpad-doc team? I joined/emailed yesterday. I know I'm probably a little impatient. :) [17:41] issyl0, usually a few working days :) [17:42] It is Sunday now. :) Not many people are working. [17:48] beuno: thanks :) [17:48] qense: that's true :) [19:14] hi guys [19:16] I have a trouble... I'm trying to create a project group buy I don't know how [19:16] SiNiESTrO: you have to make a request at answers.launchpad.net/launchpad [19:16] Is it possible or I need to contact with a launchpad admin? [19:16] ok [19:16] you're fast [19:16] :P [19:17] very thanks [19:18] np :-) [20:15] How can I get this fixed? http://launchpadlibrarian.net/39487013/hiphop-php-trunk-log.txt [20:44] davidstrauss: right now you can't [20:45] davidstrauss: that is dependant on the nested trees feature in bzr which isn't done [20:45] davidstrauss: one way is to go into #bzr and complain about the lack of nested trees :) [21:25] hi [21:25] how long a package appear on ppa after upload ? [21:27] benoitc: You'll receive an email within five minutes, unless you haven't signed the package or there is something catastrophically wrong with it. [21:28] wgrant: ok [21:59] any sysops about, I asked about using the name squeak as a project name, apparently it is already taken [22:05] keithy: the existing squeak project is disabled because the license is non-free [22:06] this isnt for squeak itself [22:06] this is for code on top of squeak [22:06] that is MIT [22:06] keithy: then i don't think you should use the squeak name? [22:06] how mean is that [22:06] i think that would be fairly confusing [22:06] anyhow there are versions of squeakwithout the licence issue [22:06] and the licence is free === wgrant_ is now known as wgrant [22:07] ah, so i see, that's interesting [22:07] just defined before oss really got started [22:07] "free" by which definition? [22:07] yeah [22:08] by whatever definition you want [22:08] I think you could give squeak a break [22:08] the official license on "http://squeak.org/SqueakLicense/" doesn't look gpl compatible [22:08] there was not mit licence back in 1996 [22:08] because of the choice of law thing, if nothing else [22:08] anyhow [22:09] lets put it this way [22:09] keithy: sure there was [22:09] 96 isn't that long ago :-) [22:09] this repo is to develop stuff FOR the licence frree version [22:09] version 4.0 [22:09] you are refering to the licence for <3.x [22:10] so you allow squeak-vm [22:11] and all users of squeak use it as if it was under a free licence because the Squeak_L was a pioneering free licence [22:11] keithy: hang on, let's take a step back [22:11] no I fed up with anal approcah [22:11] all I wanted as a project area to put code for [22:11] sure [22:11] taking code out of squeak [22:12] why use the name 'squeak' if it's not sqeak? [22:12] keithy: what are you trying to do exactly? [22:12] Ok... take an example [22:12] I have a smalltalk image, called cuis [22:12] it is licence free before you ask [22:13] in order to develop with cuis [22:13] I write some code which spits out the source of the bit I want to develop [22:13] then I write some code which installs the spat out code [22:13] so I develop for cuis using a cycle [22:13] export -> scm -> checkout -> import [22:14] so I can develop in cuis [22:14] without ever needing to check in the actual cuis image [22:14] all I need to do is refer to the starting point [22:14] hi keithy [22:14] hi [22:15] so I can develop for squeak [22:15] without ever checking squeak into the squeak project [22:15] so the launchpad project is 'inactive' [22:15] no idea [22:15] I am just being told I cant use the name [22:15] I'm telling you :) [22:15] bear with me [22:15] need to check a few things off [22:16] where is the new license - got a url or something ? [22:16] its not relevant [22:16] keithy: I understand its not relevant for you. [22:16] I tick the MIT box [22:16] because the code managed in there is MIT code [22:17] however, once a project is marked 'inactive' on LP, we have a checklist. [22:17] keithy: and if you want to use launchpad - thats great - I need to go through it; you can help me with this :) [22:17] no.. sorry [22:18] if the squeak guys want to use my process to develop they can do it [22:18] keithy: uh, this isn't anything to do with the squeak upstream per se. [22:19] keithy: lets take a step up. I understand that you want to use launchpad to do some stuff right? [22:19] it is about ripping code out of the upstream to use somewhere else [22:19] keithy: what launchpad services do you want to use - code hosting? bugs? translations? [22:19] so you add stff to the upstream which defines projects , packages and slices [22:19] code hosting [22:19] ok. [22:20] to use code hosting you have two choices for open source projects: you can use the 'junk code' facility, where you put stuff in ~keithy/+junk/NAME. Or you can get a 'project' allocated where many people can put their own branches. e.g. at ~keithy/PROJECT/BRANCHNAME [22:20] I dont put any input into "squeak"any more" [22:21] we have a group smalltalkers [22:21] sounds like you want to use a project then. [22:21] with projects cuis [22:21] and pharo [22:21] and squeak [22:21] or maybe several projects. [22:21] where we have a new process for applying bzr to scm code (NEW) code [22:21] thats cool. [22:21] so, what do you need me to do for you ? [22:22] but I dont do anything to work on squeak [22:22] as the ex-release team manager [22:22] but I do want to rip off what they have done [22:23] and put the code in an accessible place for cherry picking [22:23] ok [22:23] I'm still not clear what is at issue here. What are you trying to do that isn't working. [22:24] keithy: does their code have a licence text in it? [22:24] create the project squeak [22:24] keithy: that may provide the information we need to activate the squeak project [22:24] the licence situation is that for old images [22:24] some method do exist which they have not found the original authors [22:25] so these have been rewritten and are available as a delta [22:25] sorry to waste your time [22:26] keithy: if you just want the code in an accessible place, you can put it in a +junk branch [22:26] nice name [22:26] keithy: there is history behind the name [22:26] keithy: it is a branch without a project [22:26] No its just I am not going to put any more emotional effort into fighting squeaks corner [22:26] ok [22:27] squeak is the logical name for the project [22:27] for people to use to work on MIT apache2 code on squeak platform [22:27] keithy: ok, to use the squeak name, I need to go through this checklist. [22:27] yeah but that is their problem not mine [22:28] keithy: its pretty simple, and I'm aware of the changes that have happened in the community [22:28] keithy: I'm not asking you to answer for the original 'squeak' [22:28]