=== asac_ is now known as asac === asac_ is now known as asac [04:48] is the branch scanner stuck? [04:48] or just busy [04:49] jamesh: stuck :/ === ^Gonzo^ is now known as [PUPPETS]Gonzo [07:55] SteveA, kiko_ : I think that there is a problem with auto mail alias (ubuntu.com) activation. I'm in ubuntumembers launchpad team and alias is not active. Sebner was wait 14 day and dont work too. Some idea? [07:55] stub: and you? :) [07:57] sabdfl: er, how does one access a backport ppa. Last i knew, that didn't exist. [07:57] every ppa is a backport ppa ;-) [07:58] emgent: that's something elmo handles [07:59] sabdfl: okay, so "The Official Backports" as a ppa... [08:01] oh ok thanks sabdfl [08:01] Hobbsee: why not? [08:02] sabdfl: no, this is not a question of why. this is a question of 'where is it, and how is it accessed from ppa'? [08:03] Hobbsee: i don't know how they set it up. it was done before they had ppa's so it's probably not configured as a ppa [08:03] sabdfl: i'ts a component of the regular archive. [08:03] sabdfl: so i'm somewhat confused as to your response about how to build against -backports [08:04] (is there a way that most people don't know about? As far as i know, the answer to building against backports is that it's not possible, without rebuilding all the packages that you want from -backports in your ppa) [08:05] offs [08:05] there is a standard way to specify dependencies [08:05] you should ask the soyuz team to make it possible to specify backports [08:05] nicely [08:07] * Hobbsee did not intend to piss you off - only to ask for a clarification on your answer [08:10] sabdfl: i asked about the case now, to check that the generally given answer was correct, seeing as your answer had been contrary to it. i did not make suggestions about how it should be fixed in future. I'm unsure why you should be annoyed with me as a result. [08:12] morning cprov [08:12] Hobbsee: good morning. [08:28] emgent: I think you need to email rt@admin.canonical.com still to get that looked at. [08:40] cprov: Hobbsee had a question i could not answer, about specifying backports as a dependency for a PPA [08:41] stub: did you see that db patch? [08:43] sabdfl: I see [08:44] Hobbsee: how do you see it working ? [08:46] Hobbsee: please correct me if I'm wrong, but ubuntu itself never build packages using -backports, unless they are in -backports, right ? [08:46] cprov: correct. [08:47] Hobbsee: so, if we allow you to say, this PPA should use -backports to build packages it surely compromise the ordinary packages you normally build [08:47] cprov: i presume that for ppa, you'd want to allow an option for people to build against !release pockets - which you should be doing anyway. [08:47] cprov: w.r.t packages that get put in -updates [08:48] Hobbsee: it already use -updates + -security (as you can see in the build logs) [08:48] oh, so it does. [08:49] cprov: add an option that says "build against backports" or something, and add that line into the sbuild repositories, update, and build the package? [08:49] Hobbsee: yes, the infrastructure would support it fine, but PPA-wide [08:50] cprov: you can't specify per ppa? [08:50] cprov: have a backports-enabled tarball, and a non-backports-enabled tarball, perhaps. [08:50] Hobbsee: are you sure people would like to build every package using backported build-deps ? [08:50] this is a good question. [08:51] Hobbsee: yes, I am afraid it's a per-package, not a per-PPA decision. [08:51] i'd think for the most part, yes they would. if they specifically didn't, then they could just not enable backports in their ppa, and rebuild packages that are in backports that they wanted to use [08:52] Hobbsee: yes, as they can do for other archive-dependencies, currently. [08:52] yes, of course. [08:52] hmm [08:52] Hobbsee: that's my plan for the future, make PRIMARY archive dependencies explicit [08:53] * Hobbsee desoyuzifies [08:53] er, what? [08:54] you want to make the standard ubuntu archive dependancies explicit....how is that different from what you do now? [08:54] Hobbsee: so a PPA-owner would be able to specify something else then 'user PRIMARY release + updates + security' [08:54] Hobbsee: well, now there is not choice, PPA packages always depend on those pockets (and only those) [08:55] s/is not/is no/ [08:55] right, yes, i see. [08:55] which then presumably generalises to building for debian... [08:55] Hobbsee: wow, hold on ;) that's a looooong path. [08:56] well, yes, i know. [08:56] Hobbsee: but yes, debian PPAs are in our plans. Have you followed the conversations in UDS ? [08:56] but as in, the infrastructure will therefore be there that you can build for any debian or debian-based distro [08:57] cprov: no, how could i have? [08:57] Hobbsee: irc, I presume [08:57] * Hobbsee was not aware of any icecasts. [08:57] oh, i didn't see a launchpad specific one. [08:57] anyway, there will be news in this area soon. [08:58] nice [08:58] so, in the case of the future plan, that's also per-ppa, not per-package? [08:58] oh. [08:58] duh. [08:58] cprov: why not change the upload target field, depending on whether they want to allow backports or not, per package? [08:59] Hobbsee: so, summing up, do you think there will be valid use-cases for using generalised PRIMARY archive dependencies, right ? [08:59] that already ahppens for different ubuntu releasese. [08:59] Hobbsee: well, that's pretty much like 'enabling pockets in PPAs' [08:59] * Hobbsee desoyuzifies again. [08:59] well, yeah. [08:59] er, yes, i think there would be valid use cases for it [09:03] Hobbsee: nice, probably there is use cases for both. Let's see what we can do post-2.0. Can you file a bug, please ? [09:04] Hobbsee: There were icecasts from every room at UDS. [09:04] the use cases for depending on backports seem to be the same use cases for depending on other PPAs [09:04] (unless I'm missing something) [09:04] Hobbsee: Actually, both icecast and VoIP. [09:04] soren: i wasn't aware that included launchpad rooms. do you know where the launchpad ones were publicised? i didn't see them on scott's uds schedule [09:05] jamesh: yeah, i think so [09:05] Hobbsee: Oh.. I'm not sure about those. [09:05] Hobbsee: I thought you weren't aware of the general availability of icecast/voip streams. [09:06] most of the LP hacking at the sprint was in the lounge area [09:06] rather than explicit sessions [09:06] soren: nah :) [09:07] soren: i was on some of the icecasts, and the voip wasn't behaving for me. besides, i hate talking on those things anyway, due to the high pitched voice (in comparison) [09:07] (some of us were involved in relevant UDS sessions though) [09:07] Hobbsee: Yeah. Phones suck. [09:07] Hobbsee: clearly we need vocoder support integrated into Ubuntu's VoIP software [09:08] jamesh: :D [09:20] to compile for multiple series on the PPA, can i specify a comma separated list of ubuntu releases in the debian/changelog? [09:22] jaromil: nope. [09:22] you'll need to submit multiple builds [09:23] (preferably with version numbers that'll trigger an upgrade when upgrading OS versions) [09:33] jamesh: is it recommendable that i use the same version number or different version numbers for different series? [09:34] or something like 0.10-hardy 0.10-feisty and so on [09:34] jaromil: for the releases in my PPA, I've used the Ubuntu version number as part of the release [09:34] see https://edge.launchpad.net/~jamesh/+archive [09:35] I used the numeric version number rather than code name [09:35] i see. the ~ is sexy :) [09:35] thanks for the suggestion [09:36] while they have been lexically sorted since breezy, it probably won't always be [09:36] (what happens after Z?) [09:37] so then the debian/changelog will have multiple entries for multiple series, where i must update the latest between every build [09:38] or can i change the entry directly somewhere outside the debian/build of source package? [09:39] i guess it will be a slow process to compile the same package on more series... but ok then, seems worth :) [10:04] jaromil: I'm not sure of what the best practice is. I just changed the version number + release codename in the changelog and generated a second upload [10:42] jamesh: i just found out that the best way to have the same source packaged for different series seems to be copying packages in your PPA [10:44] jaromil: you mean, same sources and binaries, right ? because you can't rebuild sources within the same archive. [10:44] jaromil: as mentioned above, that is problematic when doing distro upgrades [10:45] jaromil: e.g. your package might depend on different shared library versions when built against gutsy and hardy [10:45] jaromil: if you publish binaries with the same version number for each release and the user upgrades from gutsy to hardy, then the user won't be prompted to upgrade your package [10:45] cprov: ack. i wanted to rebuild already uploaded sources in my PPA for multiple series [10:45] since they already have the latest version [10:45] i see [10:46] yea, i just noticed for instance gutsy hasn't libfftw3 while hardy has [10:47] can i handle such dependencies making them "recommended" other than required - so that the build doesn't stops? i contemplate the case fftw3 is not present in the configure script, should be no problem [10:47] jaromil: you only need to rebuild a source in another suite when it depends on new features, in this case the solution is indeed to upload a new source and ideally with a higher version, so upgrades will work as expected. [10:48] ok. so i'll keep on doing that [10:48] jaromil: when you depend on constant features across different suites it's okay to copy source & binaries built in the oldest suite. [10:49] when in doubt, it is probably better to do separate packages [10:49] jamesh: agreed. [10:50] * jaromil getting a clearer picture [10:50] any comment about "recommending" dependencies? something i'm missing in the control file? [10:51] debian policy manual lists only build-depend(-indep) [10:52] * jaromil feels like an olive in a plate of 'spaghetti a la debian' [11:27] good morning [11:27] is there an easy way to reassign all the bugs of a certain person to another person? === Ng_ is now known as Ng === stgraber1 is now known as stgraber [12:53] Hello [12:54] I've noticed that launchpad hasn't been sending out commit emails and updating the code pages with the latest revisions [12:54] I assume that the issue is already known, but I wanted to make sure [13:28] hey guys [13:28] when do you think lp's behavior will be back to normal? [13:29] jprieur, what specifically? [13:30] beuno, all the web visualization stuff for branches are out of sync. [13:31] code browsing is OK but the listing of branches and the online log per branches is out of sync. [13:31] jprieur, ah, right. Well, I don't know any specifics, just that it's stuck in a "very big branch", and it should unblock soon [13:31] jml, any ideas con specific? [13:32] beuno, it's like that since yesterday [13:32] more than a day, I'd say [13:32] jprieur, my last branch was scanned ~13 hours ago [13:32] and LP admins already know about it, so it shouldn't be long [13:33] https://code.launchpad.net/~people-project/people-project/people-trunk shows revision 266 and the branch is actually at revision 285 [13:33] well, ok, thanks for the answer :) [13:34] sorry I couldn't do better :) [13:34] I'd expect it to be fixed in the following hours, but it's just a hunch === fdd-0 is now known as fdd === kiko_ is now known as kiko [15:06] hi [15:11] morning [15:12] LP currently sorts the releases of my project in a wrong order: Releases: 0.7.2, 0.7.2.1, 0.7.1, 0.6, 0.7, 0.5, 0.3, 0.2, 0.1 [15:12] esp. note that 0.7.2.1 is not the latest [15:12] should I open a bugreport for that? [15:17] afflux, there should be a bug open for that already [15:17] beuno: can you point me to it? [15:18] afflux, #73094 [15:19] thanks [15:19] np [15:19] Hi.Im a newcomer to launchpad and tried to get started by contributing to the translation of miro-guide. Im looking for a hint for a work flow. To me it seems the only way translation is done in launchpad is the Web. Am I right ? [15:19] KleinerPinguin, well, you can also translate offline and upload the translation files. [15:20] kiko, yes. i thought there would be a better way [15:20] i closed a lp bug using bzr commit, but when i pushed my branch, the state of the bug wasn't changed... is that normal? [15:22] philn, hmmm, not really -- abentley do you know how the branch scanner checks metadata there? [15:22] no clue, but i know it worked at least once [15:22] kiko, i thought it would be possible to just open a branch from miroguide and would be ready to go. but no luck there [15:23] KleinerPinguin, yeah, not yet! we'll be working on this after july :) [15:23] kiko: The branch scanner is currently tied up dealing with these large branches. [15:24] So whatever it normally does won't be happening. [15:24] and, afaik, you can only close bugs with changelogs, not commits [15:25] beuno: bzr --fixes lp:1234 [15:25] +ci [15:26] where is the syntax to close bugs from changelog explained? [15:26] hrm, I wonder what that does... [15:26] philn, I don't know, but it's only for uploading packaged to main or universe [15:26] s/packaged/packages [15:27] kiko, after all its just one file with 120 strings....maybe im im just procastinating :- ) [15:27] i see... well i want an automatized way to track bugfixes and eventually revisions... and it seems to be lacking in LP [15:27] philn, as far as I know we do handle commits -- but as abentley said the branch scanner seems tied up [15:28] for a given bug i want to know when and by whom it was fixed, e.g: a link between the bug and the commit [15:28] ok... [15:29] philn: The changelog bug handling is only done for package uploads, not for branches. [15:29] is it planned to fix that? it's quite annoying IMO :( [15:30] abentley, hang on -- we do support --fixes, though, right? [15:30] abentley, I mean, we don't scan changelogs, but we do scan metadata [15:30] kiko: That's my understanding. [15:30] so what philn is doing should worn [15:30] work too :) [15:30] will work, too, once his branch is scanned. [15:30] well i remember it worked at least once for me [15:31] philn, as abentley and I said before, it will work -- it's just that the scanner process is a bit busy right now. [15:31] kiko, sorry to bug you again. Do you have a pointer where to track that spefic feature. I assume its somewhere in blueprints but i cant think of a search query right now [15:31] ok so it's just a question of time [15:31] good then [15:31] (and will need to be optimized, it appears! guess we don't have enough big branches to try it yet :) [15:31] KleinerPinguin, best person to ask is jt1, who runs the translations project [15:32] philn: No, we don't have a plan to support scanning changelogs for branches. It's a wishlist bug at the moment. [15:32] abentley, did philn mention changelogs anywhere? [15:32] ah [15:32] close bugs from changelogs [15:32] philn, that feature is for package upload changelogs :) [15:33] i understood that [15:33] but i used to like that feature in Trac [15:33] philn, why not use --fixes, which is much more explicit? [15:33] trac uses the commit messages. I wasn't aware it also used changelogs. [15:34] i find --fixes easy to forget.. i guess i need to get used to it [15:34] abentley: oops, yes you're right [15:36] so i do bzr uncommit and commit again when i forget --fixes... anyway, nevermind [15:39] Hi, I'm trying to put my software into my PPA. Is there a delay in this process or did I do something wrong? [15:52] cperrin88, if you did something wrong in packaging, you'll get emailed, as long as you signed the package right [15:52] cperrin88, there is a delay in building, but upload processing is pretty quick [15:52] Thakns [15:53] about 10 seconds before your answeer i got an e-mail :D [15:54] does this include intrepid now? [15:58] who did you ask? [15:58] kiko [16:01] uhm [16:01] Hobbsee, not sure if the chroots are set up -- right people to ask would be infinity or elmo [16:01] why launchpad PPA dont show building status? [16:02] emgent: it does. Which page are you viewing ? [16:03] pmb [16:06] doesn't the server delete file when the build didn't work? [16:07] *the files [16:07] no [16:07] can I delete them? [16:08] sure [16:08] how? [16:11] cperrin88: https://edge.launchpad.net/~user/+archive/+delete-packages [16:11] there's a delete packages link on your PPA page [16:11] This PPA does not contain any source packages published. [16:14] cperrin88: you have never uploaded any sources to https://edge.launchpad.net/~cperrin88/+archive, that's why. Or do you mean another PPA ? [16:15] i did uplaod sources but they were rejected [16:15] cperrin88, so there was no build either [16:15] right [16:16] but dput tells me that the file is already there [16:16] cperrin88, if you do succeed in uploading and the build fails, you'll be able to delete packages (sometimes -- read the help text :) [16:16] cperrin88, that's not possible -- we don't reuse ftp directories [16:16] cperrin88: use dput -f [16:16] ah [16:16] okay [16:16] kiko: it's whinging about the fact that it's already been uploaded somewhere, from that system. [16:17] kiko: it's a local error. [16:17] interesting -- yeah, dput has no way of knowing if it failed! [16:17] cperrin88: or remove the .upload file [16:17] okay :) [16:17] thanks [16:18] in which file do I have to set the distribution before using debuild .... just in th changelog file? [16:19] yes [16:25] cprov: news about building status? [16:27] emgent: no, you haven't pointed me to the page that makes you think that there is no build-status, have you ? ;) [16:28] emgent: if you're looking for a global build queue for ppa, there isn't one. [16:31] where can i find the right values for section in the control file [16:33] hello there [16:33] hi [16:34] what should i do to request the import of our project's svn? [16:34] simply ask the question in the question tracker? [16:57] the i386 builder seems to be quite busy ^^ 3 hours ... that's some time ^^ [16:58] cperrin88: heh, Ubuntu has almost 1200 builds queued for all builders :/ [16:58] yeah [16:59] amd64 and lpia are on idle .... the problem is .. I don't have such a platform :D [16:59] looks like the autosync was turned on [17:02] looks like someone is building languagepacks, they need some time, so be patient [17:02] I have time [17:05] a lot of intrepid builds [17:08] what is the build score? [17:12] is anyone else having problems with Launchpad not updating for new bzr revisions? [17:12] bobbo, yeah, the branch scanner is tied up apparently - some massive branches are in [17:13] kiko: heh, thanks :) [17:13] cperrin88: what's the location of your ppa, and which package? [17:16] http://ppa.launchpad.net/cperrin88/ubuntu/ , package bcv4 - 0.5.0-0ubuntu1~ppa1 [17:44] I thought the service would build for all architectures ... but atm it's just qeued for i368 and is already built for amd64 and lpia ... === kiko is now known as kiko-fud [17:45] PPA build only for i386, amd64 and lpia as only those arch are supported by Xen [17:45] right -- it's a security issue, mainly, cperrin88 [17:45] ahh .. okay :) [17:46] I need i368 so ... i have to wait ^^ [17:47] But there are builders for the other architectures but they are not virtualized? [17:47] yes, but only for the "official" uploads to the Ubuntu archive [17:48] are there plans to virtualize them somhow, too? [17:48] the i386 buildd is also responsible for building arch:all packages, so it has more to do then the other buildds [17:49] I can wait :) [17:49] I have to wait ^^ === matsubara is now known as matsubara-lunch [18:22] the open suse build service was definately faster .... [18:25] open suse build service? [18:25] Yeah [18:25] It can build even Ubunut packages [18:25] *Ubuntu [18:26] wow. thanks for the tip. never knew about that. [18:26] even doe, launchpad works OK. [18:26] Yeah [18:26] i just finished automating all my scripts to upload new versions and such [18:26] but well. i need more :) [18:26] Well [18:26] sorry, gotta go, bbl() [18:26] bye === matsubara-lunch is now known as matsubara === kiko-fud is now known as kiko [19:06] is buidl score my current place in the qeue? [19:06] the PPA's are very very slow... [19:06] downloading from them that is [19:19] cperrin88, no, it's a score calculated on attributes of your package itself. it's used to calculate the position you should be in the queue, though there is an ETA you should be able to rely on for the build [19:21] * bobbo wishes there was a dedicated PPA builder [19:21] bobbo, there are dedicated PPA builders. what do you mean? [19:22] kiko: so how are the auto-sync'd ubuntu packages slowing down the PPA builds? [19:23] bobbo, they aren't. [19:23] everything's running a bit slow today, though, it seems. [19:23] kiko: ah ok, i though it was the Ubuntu packages slowing the PPA builds === fta_ is now known as fta [19:24] thanks for clearing that up :) [19:24] sure thing :) [19:25] A list for the PPA builds would be great [19:26] it's being worked on (by al-maisan, btw) [19:26] that's good :) [20:03] wooohoo .. my package is building ^^ [20:04] cperrin88: mine just built :D properly happy [20:08] mine is done, too :) [20:11] hi all [20:11] hi [20:11] seems like LP branch scanning is completely broken these days [20:11] is that a known issue ? [20:11] yeah, it's currently blocked on some gigantic branches apparently [20:12] abentley might know more [20:12] :/ [20:13] I see [20:13] thanks [20:14] it seems like LP needs more servers .... [20:15] kiko, asabil_: AFAIK the last thing that happened was a recommendation to increase the timeout. [20:16] hmm ? [20:16] timeout for what ? [20:22] asabil_: timeout for the script that scans the branches for new revisions. [20:24] oh ok [20:29] <\sh> now I know why you launchpadders don't opensource launchpad...you are not allowed to talk about it...because it's da "Phyt" club... as seen yesterday during a fair in karlsruhe ;) http://www.sourcecode.de/content/phyton-world ;) [20:31] heh === kiko is now known as kiko-afk [21:10] does launchpad have something like bugzilla's "saved searches"? [21:11] <\sh> ahasenack, browser bookmarks [21:11] ok, thanks === mwhudson is now known as mwh === mwhudson_ is now known as mwhudson