[00:13] flacoste_afk: hey - are u here? [00:31] elmo: Effectively taking the PPA service down for two weeks after each Ubuntu release isn't too good - even one extra i386 buildd would make a big difference. [00:37] flacoste_afk: it works!!! :) [00:49] The following sources cannot be copied: dvb-ttpci-firmware fe2624-ppa2~bpo40+1 in intrepid (version older than the dvb-ttpci-firmware fe2624-ppa2 in jaunty published in jaunty), [00:50] why can't I do that ? [00:50] mirak: The message seems clear, but what exactly were you trying to do? [00:50] what is not clear is that it's a backport [00:51] wgrant: I mean I try to backport a package [00:51] mirak: Where are you trying to copy it to and from? [00:51] Which distroseries? Which archive? [00:51] it's logical that fe2624-ppa2~bpo40+1 in intrepid < fe2624-ppa2 in jaunty isn't it ? [00:52] wgrant: I copy from my ppa to my ppa team [00:52] the archive is my own package [00:52] mirak: In which distroseries? [00:52] what is it ? [00:52] Jaunty/Intrepid/blah [00:52] hem [00:53] I though it would be able to put them right [00:53] I choosed any [00:53] probably I need to move from same distro to same distro [00:53] You probably tried to copy from Intrepid to Jaunty. [00:53] I choosed "the same serie" option [00:54] Which are the source and destination PPA? [00:54] I selected intrepid and jaunty packages to move maybe [00:56] it's ok [00:56] it's just that when you chosse "same serie" option, you can't mix jaunty and intrepid packages [00:56] it doesn't manage to put the package at the same place they wehere on the source ppa [01:06] mirak: That sounds like a bug, but it worked for me. [01:47] Hmm... it appears that you can't enumerate secondary PPAs of a person via the web service API [02:02] I'm trying to write a script that calls archive.syncSource, but I'm getting a 500 Internal Server Error [02:03] X-Lazr-Oopsid: OOPS-1218EC8 [02:04] maxb: The named PPA issue is being fixed for 2.2.5. [02:05] maxb: How are you calling syncSource [02:05] +? [02:05] hmm. I'm actually trying to sync into a secondary PPA [02:06] You crafted the resource URL? [02:06] and launchpad.load()-ed it [02:06] Right. [02:07] post /beta/~mercurial-stable-snapshots/+archive/staging source_name=%22mercurial%22&from_archive=%22https%3A%2F%2Fapi.edge.launchpad.net%2Fbeta%2F%7Emercurial-stable-snapshots%2F%2Barchive%2Fppa%22&version=%221.2.1%2Bhg20090430-7889-ea82a23cf887-0ppa1%22&ws.op=syncSource&to_pocket=%22Release%22&include_binaries=true [02:07] is what I get in httplib2 debug output [02:07] So, you could file a bug with that bug, hunt down a Canonical employee to look at the traceback of that OOPS, or work out what was wrong with the request using trial and error. [02:10] maxb: That request looks fine to me, though, so you'll have to find somebody with access to the traceback. [02:12] * wgrant tries on staging. [02:15] maxb: It's the binary copying that's causing the problem, which makes it rather useless for your purposes... [02:15] hmm [02:16] The entire point of this exercise being to ensure all the binaries are built before they get published to the publicly advertised PPA, yes :-/ [02:19] Hmm,. [02:19] I can't copy anything with binaries, it seems. [02:19] But I did just find another bug. [02:20] I just copied with binaries using the webpage [02:20] You can copy to non-release pockets using IArchive.syncSource, and they won't show up anywhere except the apt-gettable archive, and they can't be removed. [02:21] heh [02:21] Oh, wait, they do show up. [02:21] It was just replication lag. [02:21] Erm. [02:21] And it *did* include the binaries, when I told it not to. [02:22] Ah, it's because that source was initially built in that archive, copied elsewhere, then deleted in the origin. So it wasn't a good test at all. [02:24] * maxb thinks all PPAs should have the option to publish initially to an "incoming" pocket, and automatically copy to the release pocket once all build records for the source publication reach "successfully built" [02:24] I still can't copy things with binaries. [02:25] maxb: That would be nice, although you can always do that easily with multiple PPAs as long as they haven't broken it. [02:25] * wgrant files a couple of bugs. [02:27] Bug #370635 [02:27] Launchpad bug 370635 in soyuz "Archive.syncSource with binaries OOPSes" [Undecided,New] https://launchpad.net/bugs/370635 [02:29] And bug #370636 [02:29] Launchpad bug 370636 in soyuz "Can copy to non-RELEASE PPA pockets using Archive.syncSource" [Undecided,New] https://launchpad.net/bugs/370636 [03:09] is it just me or is the build process on LP a little slow at the moment? https://launchpad.net/~vk7hse/+archive/scott-vk7hse-jaunty?field.name_filter=&field.status_filter=published&field.series_filter=any I uploaded this over an hour ago... [03:13] VK7HSE: The build queues (https://launchpad.net/builders) are currently fairly long, because lots of the build machines are currently serving the huge load on releases.ubuntu.com. [03:13] Apparently those machines will be builders again some time early next week. [03:13] wgrant: Oh ok that's fine then! [03:50] Hey guys, [03:51] Question: Is there an index of packages available in all the PPAs on launchpad? or does one have to use google? [03:51] doctormo: You can search at https://launchpad.net/ubuntu/+ppas - searching for a package name will get you PPAs containing that package. [03:52] wgrant: great [03:52] wgrant: Just tried to use the api/python, decided against it. [04:29] Is OOPS-1218B233 or OOPS-1218ED21 when looking at merges a known/common/being worked on issue? See bug #370658 [04:29] Launchpad bug 370658 in launchpad "OOPS-1218ED21 when looking at proposed merge" [Undecided,New] https://launchpad.net/bugs/370658 [04:29] https://devpad.canonical.com/~jamesh/oops.cgi/1218B233 [04:31] I wonder if lazr.oops will be release, I saw some other lazr code was recently and I kinda liked playing with that code. [04:43] random "why dont you just use procmail" question: anyone know how to tag mail from launchpad lists in gmail? [04:43] pwnguin: Use Sieve or procmail! [04:44] pwnguin: Or see http://blog.launchpad.net/bug-tracking/gmail-filters-for-launchpad-bug-email [04:46] actually, it looks like the mail im basing this on was a "contact this team" [04:46] not quite bugmail [04:46] or a generic listserv [04:46] The same ideas probably apply. [04:47] doctormo: I presume lazr.oops will be released along with the rest of LP on July 21st. [04:47] s/the rest/some other less interesting parts of/ [04:48] wgrant: That's good, do you know if that means parts of the code Ubunet will use (i.e. oops) will flow that way to, or will that be a fork? [04:48] doctormo: I don't think we're meant to know that Ubunet exists. [04:48] wgrant: You aint? it's in internal Beta and I worked on it, you can take this private if you'd like. [04:49] doctormo: I know you worked on it. But I'm just another Launchpad user, and it hasn't been announced publicly yet. [04:49] wgrant: Ah, well, it's good to know launchpad will have more bits released July 21st [04:49] your knowlege of lp caught me off guard there ;-) [04:51] doctormo: July 21st is the date that LP itself will be released. They like to say it's all of it, but some of the more interesting bits (Codehosting and Soyuz) are being kept non-free for the time being. [04:51] I never got to see either of those bits myself, what do they do? [04:51] soyuz? [04:52] that's the builder, no? [04:52] doctormo: Soyuz manages the Ubuntu archives and PPAs. Codehosting hosts bzr branches. [04:52] pwnguin: And the archive management stuff, yes. [04:52] its hardly worthwhile unless you're canonical or debian [04:52] pwnguin: Using != fixing [04:53] wgrant: hmm, so I agree it may not be apparently useful in a purely 1 dimentional kind of way. But er, there is more to FOSS than that, as Sugar Labs keeps on pointing out, one of the important aspects is the ability to learn from the code. [04:53] its a distributed system. not exactly a blast fixing those when timing issues arise [04:53] anyways [04:53] doctormo: Right. Most people seem to agree. [04:54] Ah my default is always to FOSS, but then I have alt-funding installed. [04:54] after the 21st, perhaps someone will rewrite soyuz using hadoop [04:54] or bashReduce ;) [04:55] pwnguin: bashReduce? I don't like the sounds of that! [04:55] its as awesome as it sounds [04:57] i wonder how long it takes to topological sort the build dependency tree [04:57] pwnguin: It doesn't do anything as fancy as that. [04:58] It just throws stuff at the buildds. [04:58] well, bash reduce could ;) [04:58] If a dep is missing, it takes the first missing one and doesn't retry it until it sees that appear in the archive. [05:05] Is there any way to filter the ppa search further? [05:05] doctormo: What exactly do you want to filter on? [05:06] wgrant: arch and distribution would be good [05:06] doctormo: Ah, no. [05:07] Maybe there should be a method somewhere to search source publishings across all archives. === Andre_Gondim is now known as Andre_Gondim-afk [05:12] Hmm, this PPA search isn't as useful if it pulls up results from any arch/series [05:13] Series would be useful; arch, not so much. [06:04] When is Launchpad going to reallocate some servers from mirroring back to PPA building? These 12 hour wait times are killing me [06:05] ripps: Somebody said many hours ago that it'll be some time early this next week. [06:05] wgrant: okay, thanks for the heads up [06:07] ripps: Although you'd think they could sacrifice just one mirror server to help clear the i386 backlog, wouldn't you? [09:33] hey hey [09:33] Can't open my languages - i get a "Ooops" - Something wrong in launchpad? [09:38] Demophobie: That's LaunchPad's fault, not yours.... I am seeing some OOPSes also tonight... the LP devs will get to it when they can, I'm sure. [09:39] jmarsden: Ah okay - i was worried if it my fault. I made come changes.. [09:39] some* ^^ [09:39] As far as I know, OOPSes are always a problem in LP of some sort. [09:40] A page with a title of 'Oops!' is always Launchpad's fault. [09:41] It will have been logged, and QA people will probably look at it on Monday. [09:41] ok [09:41] :) [10:02] o/ does anybody know when will Karmik be available in the PPA in Launchpad ? thanks [10:05] cemc: It has been for a week now. [10:05] Nearly. [10:05] humm [10:06] You won't see it in the dropdown on your archive page until you upload something to it. [10:06] But the list of PPA-supported architectures and distroseries is at https://launchpad.net/ubuntu/+ppas [10:07] so that's why I didn't see it. makes sense. thanks for the info [10:07] np [10:10] things i marked as "Deleted" in the translation Import queue will de removed after while, right? [10:11] i have a lot of files (i tried a lot) in the import queue and some seem to block others to be updated === Philip6 is now known as Philip5 === thunderstruck is now known as gnomefreak [11:09] build of package is too slow [11:09] why can't we upload binaries at least for amd64 and i386 ? [11:10] if they are build in pbuilder it should be ok right ? [11:11] mirak: Builds are normally quick, and will be again in a couple of days. [11:12] You can't upload binaries, because then there's no way to verify the content of a binary. [11:12] wgrant: yes but I doubt anyone will ever verify the soures [11:12] sources [11:13] mirak: I always try to verify the diff. [11:13] before someone gets hurts I mean [11:13] mirak: the whole point is that the binaries must be built from the sources. [11:13] of what you download ? or all the ppa ? ^^ [11:13] Binary uploads are a bad idea, and I strongly doubt that Launchpad's policy on them will ever change. [11:14] I understand but what I mean is that in reality, if someone gets hurts, it will be from a binary, [11:14] It's normally just as quick for Launchpad to build them, except when the sysadmins steal most of the buildds for weeks, which has happened for the first time just now. [11:14] Right, but I can verify that a binary is fine by looking at the source. [11:14] and the feact the sources are altered doesn't change this [11:14] Unless an untrusted entity built the binary, which you are. [11:15] What benefit does uploading binaries give, assuming the usual < 1 minute dispatch time? [11:15] wgrant: yes, but my sources can't be trusted either. and most people will just download the binary. But I understand, it's just I think in 99,0% of the cases, if someone wants to do something nasty he will have no problems doing it [11:16] 99,9% [11:16] mirak: I can and will verify your sources. Others will too. [11:17] wgrant: in theory yes but in reality it won't happen. Are you reviewinf each ppa ?? [11:17] mirak: Each PPA that I add to my systems, yes. [11:17] Unless it is from somebody that I know and trust well. [11:18] wgrant: if you don't trust me you still can build from the sources you reviewed ^^ [11:18] mirak: But I don't need to, if Launchpad did it for me. [11:18] mirak: Not being able to upload binaries gives you (as the uploader) no disadvantage, unless you are malicious. [11:19] but well this question wouldn't matter when launchpad will be faster [11:19] Right. [11:19] wgrant: yes it is, it's slower to make available my packages, but if it's just temporary it's ok [11:20] mirak: Right, I think everybody is very disappointed with the current state of the build queues. [11:20] is the /var/cache/pbuilder/build mounted on a tmpfs for the builds ? [11:21] mirak: The buildds use a mutant sbuild, not pbuilder. [11:21] I tried this, this makes things really faster, however it needs at least 4 or 6 gigs of ram [11:21] wgrant: is it worth to try sbuild for my personnal usage ? [11:22] mirak: It's a lot more efficient, but it requires LVM. If you're already using LVM, sure. [11:22] wgrant: you mean sbuild needs lvm ?? [11:22] mirak: In most of its modes, yes. [11:23] I used it at some point, but dropped because I never resized anything, or just bought new harddrive instead of exetending the volumes. [11:23] and the problem with having a /boot partitions was anoying [11:39] BjornT: any success on figuring out why I didn't get the NEW bug mail when filing bugs with requestsync (and LP API)? I just filed a bug through the web interface and got the NEW bug mail so it's not my mail setup [13:06] ooh, Tags field on the bug filing page [13:07] yup, they implemented that feature request pretty quickly :-) [13:07] * maxb wonders if there are any graphs of build queue sizes [13:08] You also get other fields if you are the bug supervisor. [13:57] hi, when i try to translate temlpates of my project, i get OOPS-1218B866 since a couple of days. any ideas? [13:57] https://devpad.canonical.com/~jamesh/oops.cgi/1218B866 === asac_ is now known as asac === hypera1r is now known as hyperair