[00:28] <ScottK> kklimonda: What you have to do is upload the older version as a new upstream tarball with a higher version number, e.g. [newversion]+really[oldversion]-0ubuntu1.  Removing it and readding it won't get you around this.  See the ldb package for an example.
[00:30] <kklimonda> ScottK: thanks
[00:31] <ScottK> You're welcome.
[00:43] <mhall119> jdstrand: thank you
[00:43] <mhall119> jdstrand: the qimo-games package was updated too, it includes a few images now
[00:46] <kklimonda> ScottK: what do I have to attach to the bug report in this case? a debdiff between debian/ directory from the newer tarball and the one I'm reverting to or the full debdiff?
[00:47] <ScottK> kklimonda: Probably best to push the entire mess to REVU and link it to the bug rerport.
[00:49] <kklimonda> right, I was wondering what to do with the tarball itself
[00:49] <ScottK> REVU solves that.
[00:49] <kklimonda> *nods*
[00:55] <kklimonda> ScottK: can you take a look at it if when you have time? bug 518788
[00:55] <ScottK> Perhaps.  Not sure how soon I'll have time.
[00:56] <kklimonda> hmm.. I'll poke chrisccoulson then :)
[00:56] <chrisccoulson> moi?
[00:57] <chrisccoulson> you want somebody to sponsor work?
[00:57] <kklimonda> hmm, now that you call it like this I think I should subscribe sponsors :)
[00:57]  * kklimonda is too tired already
[01:04] <chrisccoulson> kklimonda, i will look at that in the morning if nobody else has done already
[01:04] <chrisccoulson> i'm going to get some sleep now
[01:57] <ripps> geez, a damn bug in gcc (or something) keeps getting fixed, than broken again. gmpc fails on amd64 gob files. Earlier in the Lucid cycle, it wouldn't build, then it worked, now it doesn't anymore... this is getting ridiculous
[02:54] <jdstrand> mhall119: re qimo-games> I peeked at the licensing there and it seemed fine (you did the same there as the others)-- I'd get others to comment on the rest though
[04:09] <ajmitch> ScottK: a freeze exception will be required for bug 556407 I guess? it's a mix of a security fix & new upstream features
[04:18] <ScottK> ajmitch: I saw the DSA, we want that.
[04:19] <ScottK> ajmitch: Approved.
[06:14] <fabrice_sp> Hi. What should I do with a branch that appears in the sponsorship view, but has been rejected? Delete merge proposal? It's https://code.launchpad.net/~philippe-gauthier/ubuntu/karmic/gw6c/gw6c-validation-client-v4.lp418176/+merge/14835
[08:17] <dholbach> good morning
[08:37] <iulian> Morning dholbach.
[08:41] <dholbach> hey iulian
[10:04] <jetienne> q. i need to install mysql without interaction and then setup a default password, this is for a dependancy of one of my package. where should i look ?
[10:08] <joaopinto> jetienne, you want to use DEBIAN_FRONTEND=noninteractive apt-get install mysql
[10:08] <jetienne> joaopinto: tahnks trying
[10:08] <joaopinto> but you can't set up that as regular dependency
[10:09] <geser> jetienne: you are packaging an application which needs a mysql database?
[10:09] <jetienne> i got another dependancy which cause trouble. this is a .deb which has no repository. i planned to do a wget and then dpkg. but i cant do that in the postinst. how can i handle it
[10:09] <jetienne> geser: yepm
[10:10] <joaopinto> include that .deb to the same repository you are providing your package from :P
[10:11] <jetienne> joaopinto: not that simple :) i got only the .deb of the other package and no .changes.
[10:11] <geser> jetienne: perhaps "dbconfig-common" helps here and check how similar packages do it (do shouldn't depend on the mysql-server as it can also be installed on an other host)
[10:12] <jetienne> geser: not sure what you mean here. what should i do with "dbconfig-common" ? what is it
[10:12] <geser> !info dbconfig-common
[10:14] <geser> jetienne: and for the other problem: you should try to get the source package for it and include it in your repo (or package it yourself)
[10:14] <jetienne> geser: any simpler way ?
[10:15] <jetienne> for mysql
[10:16] <jetienne> i will do a "in 1 min, try to install, and loop until you can"
[10:16] <jetienne> this is ugly and crappy but so is my job
[10:16] <joaopinto> I hope you are not doing that from a posinst
[10:16] <geser> don't know of any but I didn't have to look at such packages yet
[10:19] <joaopinto> jetienne, I am not sure what you are doing, but it looks you are doing it the wrong way :P
[10:19] <jetienne> joaopinto: with a "at" or "cron" this is possible
[10:19] <jetienne> joaopinto: and i agree with you :) this is just the easy way
[10:20] <jetienne> both, thanks for you help tho
[10:22] <joaopinto> jetienne, not an easy eay, it's a bad way, that may hurt the system
[10:22] <joaopinto> running a dpkg -i from a cron is a bad idea
[10:23] <joaopinto> I really don't see the advantage on trying to do something to work out of the box that may randomly break the system
[10:23] <jetienne> joaopinto: dont get me wrong, i DO agree with you
[10:23] <jetienne> joaopinto: it get the silly boss off my back :)
[10:23] <joaopinto> jetienne, it is bad in the sense that it may break the system, if you loop trying to dpkg -i from a cron
[10:24] <jetienne> joaopinto: you dont believe me when i tell you i agree :)
[10:24] <joaopinto> if I were your boss I would kick you :P
[10:24] <jetienne> if you were my boss, you would not advocate for crappy solutions :) i hope at least
[10:26] <jetienne> joaopinto: just last example "sql is no reliable, i want us to handle db via flat file in json"
[10:26] <jetienne> joaopinto: if you are able to say this sentence without laughing you could be my boss :)
[10:27] <jetienne> why he is asking me to install mysql now is left as an exercice to the reader :)
[10:30] <joaopinto> :P
[11:41] <sistpoty|work> ScottK: can I convince you to do source-new for the openttd related packages? (bug #556593)
[11:41] <wgrant> sistpoty|work: I actually count 5 new sources.
[11:42] <sistpoty|work> wgrant: right, looks like I counted lines
[11:43] <sistpoty|work> wgrant: btw thanks for testing :)
[11:44] <wgrant> Yep, all 6 build and work fine in Lucid.
[11:44] <wgrant> And I've just gardened that SDL bug, although it seems to not affect OpenTTD.
[12:17] <Rhonda> Someone around with the sdl mouse click issue (in e.g. wesnoth) in sdl on Debian/Ubuntu? Someone prepared a potential fix and would like to have it tested …
[12:21] <sistpoty|work> wgrant: ^^
[12:22] <wgrant> Rhonda: Yeah, I saw that on the Debian bug and was tempted to test it.
[12:22] <Laney> bah
[12:22]  * wgrant PPAifies.
[12:22] <Laney> sistpoty|work: pandoc got two NEW build-deps
[12:22] <Laney> but at least it has now been uploaded
[12:22] <Laney> and it got a versioned b-d on a newer CDBS
[12:23] <sistpoty|work> Laney: newer cdbs is very bad, I wouldn't like to get that in :(
[12:23] <Rhonda> wgrant: Would be great if you could test it - if it works it might be an good idea to push it into lucid, if that's still possible. :)
[12:23] <Laney> sistpoty|work: Yes, but we can probably get around that one
[12:23] <sistpoty|work> :)
[12:23] <wgrant> Rhonda: yeah, we probably shouldn't have a broken Wesnoth...
[12:24] <Laney> sistpoty|work: so we need haskell-texmath and haskell-xml now
[12:24] <Rhonda> wgrant: Actually I think people will complain enough that we won't have 1.8 already - which only came out last week. ;)
[12:24] <wgrant> Rhonda: Of course; they are users!
[12:25] <Rhonda> So we shouldn't give them broken mouse clicks also.
[12:25] <sistpoty|work> Laney: can you prepare a FFe?
[12:25] <Rhonda> wgrant: I was slightly amused that someone filed a bug about purging wesnoth wouldn't remove /home/$user/.wesnoth1.6 directory. ;)
[12:25] <sistpoty|work> Laney: side note: didn't come around hmake yet, and probably won't come around it until Friday :/
[12:25] <wgrant> Rhonda: Ew.
[12:26] <Rhonda> wgrant: Someone else did close it as invalid before I had the chance to lay my hands on it. :)
[12:26] <wgrant> :(
[12:28] <hyperair> cjwatson: got a moment to look at banshee-community-extensions (in NEW)?
[12:34] <cjwatson> hyperair: accepted
[12:34] <hyperair> cjwatson: thanks
[12:34] <hyperair> sebner, directhex: ^^ \o/
[12:35] <directhex> awesomes!
[12:39]  * sebner ^5 hyperair 
[12:40] <hyperair> =)
[13:18] <directhex> hyperair, isn't it binary new now rather than source new, though? :p
[13:21] <ScottK> sistpoty|work: If they are all from Debian, yes.
[13:29] <cjwatson> directhex: that's easier
[13:31] <directhex> cjwatson, do you need to be independently asked to remove the obsolete source packages from lucid for individual odds & sods which have been integrated into banshee-community-extensions, or do they appear automagically on some list somewhere?
[13:31] <cjwatson> the latter
[13:31] <cjwatson> oh, wait
[13:31] <cjwatson> source packages
[13:31] <cjwatson> please file a bug about those and subscribe ubuntu-archive
[13:39] <lfaraone> sistpoty|work: I'm confused by your response to bug 552720; I stated in the bug description that I tested squeak-vm with Scratch and Etoys, two squeak applications, and they both ran fine while I performed their respective smoketests.
[13:39] <sistpoty|work> ScottK: yes, thanks in advance!
[13:40] <sistpoty|work> lfaraone: ah, thanks. didn't see that.
[13:41] <lfaraone> sistpoty|work: okay, just checking whether I misunderstood and you meant further testing was required.
[13:42] <sistpoty|work> lfaraone: no, I simply didn't read the description thouroughly enough, sorry
[13:43] <lfaraone> sistpoty|work: no worries, I'm guilty of much of the same :)
[13:49] <Rhonda> wgrant: About that patch, please check wether the change doesn't reopen the issue why ubuntu did pull in 1.2.14 instead of 1.2.13 in the first place. :)
[13:50] <Rhonda> wgrant: There is an upstream bug mentioned in the diff for the changelog there, it should get decided which of those is the more severe issue, me thinks.
[14:01] <directhex> cjwatson, there we go, Bug #557284
[14:05] <Laney> sistpoty|work: bug 557285
[14:07] <sistpoty|work> james_w: would you volunteer to source-new haskell-xml (already passed new in debian)?
[14:08] <sistpoty|work> and eventually the haskell-texmath as well?
[14:08] <james_w> sure
[14:08] <james_w> sbeattie: do you think the super issue has anything to do with the -extension thing?
[14:08] <sistpoty|work> james_w: thanks!
[14:47] <lfaraone> james_w: I've written a script to automate the updating of a package in merge mode to a new upstream git/bzr/hg snapshot, extracting the upstream changelog from the intermedate vcs commits. Would this be useful to submit somewhere?
[14:47] <james_w> lfaraone: can I have a look?
[14:48] <lfaraone> james_w: well, right now it's very very alpha, as in "hard coded for a specific package I use, with git" but it should be generalizable. Hold on, I'll post what I have.
[14:49] <james_w> yeah, I'd just like to get a better idea of what it is doing
[14:49] <lfaraone> james_w: sure, http://sprunge.us/GfBY?py
[14:51] <james_w> lfaraone: cool
[14:51] <james_w> I guess ubuntu-dev-tools would make sense?
[14:52] <lfaraone> james_w: sure. I'll branch off it and work this into a usable state.
[15:00] <lfaraone> james_w: in the same vein as uupdate, would uupdate-vcs be an apt name?
[15:00] <james_w> yeah
[15:00] <james_w> maybe -snapshot?
[15:01] <lfaraone> good.
[15:01] <james_w> uupdate-vcs-snapshot
[15:10] <Laney> sistpoty|work: bug 557323 for you
[15:11] <Laney> I should update my ubuntu-dev-tools
[15:12] <Laney> my requestsync is subscribing motu-release
[15:13] <sistpoty|work> Laney: approved as well
[15:13] <Laney> thanks
[15:14] <Laney> washngo should get building soon too — someone cabalised it
[15:14] <Laney> then we really will have an all green graph (on some arches at least)
[15:14] <sistpoty|work> :)
[15:14] <bilalakhtar> hello MOTUs please check out this package which I publiched a week ago http://revu.ubuntuwire.com/p/gnome-media-player and the needs-packaging bug is https://bugs.launchpad.net/ubuntu/+bug/551702
[15:15] <james_w> lfaraone: how did you do the squeak-vm merge, the results are rather odd
[15:15] <james_w> oh, I see
[15:16] <lfaraone> james_w: oh? did I mess something up?
[15:16] <james_w> I don't think so
[15:16] <sistpoty|work> Laney: oh, armel build of ghc6 was restarted (on a different buildd)
[15:16] <bilalakhtar> is it still possible for packages to get into lucid repos?
[15:17] <Laney> sistpoty|work: I saw that, and lamont wants to leave it running for some reason
[15:17] <lfaraone> bilalakhtar: if you have a good reason, thourough testing, and go through REVU
[15:17] <Laney> if it's the one that has been going for nearly a month now
[15:17] <sistpoty|work> bilalakhtar: quite unlikely, unless you have a very, very good reason
[15:17] <lfaraone> james_w: would it be a good idea to have the user store the URL of the upstream repo in a "XS-Upstream-{Git, Hg, Bzr, Svn}:" field, or somewhere else?
[15:18] <bilalakhtar> sistpoty|work: The project page is here: https://launchpad.net/gnome-media-player
[15:18] <james_w> lfaraone: yeah, except that proposing that as a standard will draw some complaints
[15:18] <james_w> lfaraone: are you involved in Debian at all?
[15:18] <lfaraone> james_w: I'm a Debian Maintainer.
[15:18] <bilalakhtar> sistpoty|work: Why so? Lucid didn't release yet (not the stable atleast)
[15:19] <sistpoty|work> Laney: might be since different armel buildds use different kernels, and jaboticaba was needed for a different package
[15:19] <lfaraone> bilalakhtar: end of the month, or so.
[15:19] <sistpoty|work> *shrug*
[15:19] <james_w> lfaraone: proposing the idea to Debian would be useful then
[15:19] <persia> bilalakhtar: We're well into the freeze cycle though, and past the deadline for new packages.
[15:19] <bilalakhtar> lfaraone:
[15:19] <sistpoty|work> bilalakhtar: everyone's busy fixing bugs at the moment, or should be busy fixing bugs, not adding new features ;)
[15:19] <bilalakhtar> persia: lfaraone: So is it possible to upload for maverick?
[15:20] <persia> bilalakhtar: Absolutely, but you probably won't get someone to review until early next month.
[15:20] <lfaraone> bilalakhtar: is it a new package? probably no.
[15:20] <james_w> lfaraone: how did Debian get rid of the epoch in this package?
[15:20] <bilalakhtar> lfaraone: It is a new package
[15:20] <persia> lfaraone: Why not, for maverick?
[15:20] <lfaraone> james_w: they didn't ship it officially.
[15:20] <james_w> ah
[15:21] <lfaraone> persia: not familiar. I looked, it's an existing package, so my comments do not apply.
[15:21] <lfaraone> (I didn't know what it was)
[15:22] <bilalakhtar> lfaraone: My package is a new package. Do you mean to say the gnome-media-player package?
[15:22] <bilalakhtar> lfaraone: Yes that is my package and there's no such package in the repos
[15:22] <lfaraone> bilalakhtar: okay. expect to ship it in lucid+1.
[15:23] <bilalakhtar> lfaraone: ok then I am uploading it for maverick. I am ready to wait for a longer time
[15:24] <lfaraone> persia: oh, i'm really out of date, didn't realize lucid+1 had been named :)
[15:24] <bilalakhtar> so long, guys, have to leave now
[15:24] <persia> lfaraone: Less than a week ago, so not that out of date :)
[15:25] <sistpoty|work> we could speculate about the name of maverick+1 though :P
[15:26] <persia> nifty newt!
[15:27] <lfaraone> persia: heh. that's a good name, you should tell the sabdfl ;)
[15:28] <lfaraone> james_w: just to confirm, the bugfix release 1.5.1 of barnowl does not require a FFe, correct? http://sprunge.us/geOD
[15:28] <persia> I suspect it's already on the page of suggestions, but I've also not seen much correlation between the page of suggestions and the actual names, so don't put anything there anymore.
[15:29] <james_w> lfaraone: we already have 1.5?
[15:29] <lfaraone> james_w: correct.
[15:30] <james_w> then that looks fine to me
[15:34] <lfaraone> done, bug 557346.
[15:39] <lfaraone> james_w: re squeak, I submitted a wishlist bug upstream asking them to include the epoch, but it'll be a tough thing to convince them to add a useless epoch. (from their point of view)
[15:49] <cnd> ep
[15:54] <psusi> how do I clone the existing package branch so I can fix it and link it to the bug for a sponsor to merge?
[16:07] <geser> psusi: see https://wiki.ubuntu.com/DistributedDevelopment/Documentation
[16:12] <psusi> heh, thanks... I was actually kinda figuring it out stumbling around with bzr and lp ;)
[16:13] <psusi> already got the branch uploaded... looks like now I just need to link it to the bug and get a sponsor
[16:15] <geser> if you commit your changes with "bzr commit --fixes lp:123456" your branch gets autolinked to the bug
[16:21] <psusi> hrm.... that page says to set the reviewer to ubuntu-sponsors, but the default is ubuntu-branches... is the documentation out of date or should I really change it?
[16:25] <psusi> hrm... ok, hope that does it... now all bug #534743 needs is someone to bzr merge ; bzr commit ; dput, hoepfully in time for beta 2
[16:30] <psusi> is there anyone I should subscribe or assign this to since it is a serious regression from karmic that renders some systems unbootable?
[16:39] <arand> psusi: Reviewers team possibly, since it's udev, I think #ubuntu-devel might be the place...
[16:59] <MTecknology> Any of you in here happen to know about mailman lists?
[16:59] <MTecknology> wrong channel - sorry
[17:21] <c_korn> is there no orig tarball when using source format 3.0 (native) ?
[17:26] <hyperair> c_korn: native packages have no orig tarballs.
[17:26] <hyperair> c_korn: that's the very definition of a native package.
[17:27] <c_korn> hyperair: so I have to use 3.0 (quilt) even if I do the patching in debain/rules ?
[17:27] <slytherin> ScottK: Do you mind approving jboss binaries from new queue? Other archive admins in #ubuntu-devel seem to be busy.
[17:27] <hyperair> c_korn: er. what are you doing that involves patching in debian/rules?
[17:27] <hyperair> c_korn: why don't you use a proper patch?
[17:29] <hyperair> well actually as long as you restore your build tree to the original state in your clean rule, you're free to use anything
[17:33] <c_korn> hyperair: ok, there is no conflict using 3.0 (quilt) and using quilt in debian/rules. this was my actual question. sorry for the confusion.
[17:33] <hyperair> c_korn: get rid of quilt in debian/rules.
[17:33] <hyperair> c_korn: why are you using quilt in debian/rules?
[17:33] <slytherin> c_korn: If it is native package then you should use 3.0 (native)
[17:33] <hyperair> there is practically no point in using 3.0 (quilt) format if you're going to put quilt things in your debian/control and debian/rules[
[17:34] <hyperair> slytherin: he wants an orig tarball. that's no native package.
[17:34] <hyperair> c_korn: if you must use quilt in debian/rules and debian/control, then go back to source version 1.0
[17:37] <c_korn> I am doing some other things before the dh_quilt_patch target. so I just need to move those changes to the dh_auto_configure target
[17:38] <hyperair> i see. just use source 1.0 then
[17:38] <hyperair> or do you need 3.0 (quilt) for something else?
[17:39] <hyperair> besides patches and bz2/lzma tarballs, there isn't much to 3.0 (quilt)
[17:41] <c_korn> well, it creates a debian.tar.gz file which I find more aesthetic :)
[17:45] <hyperair> c_korn: that's not really a good reason =_=
[17:48] <c_korn> not unless you get nightmares filterdiff'ing through a diff.gz file :)
[17:54] <joaopinto> aren't the general guidelines to use 3.0 (quilt) unless there is a good reason to not do so ?
[17:59] <joaopinto> http://lintian.debian.org/tags/missing-debian-source-format.html -> If you don't have a good reason to stick with the old format, you should switch to "3.0 (quilt)" (for packages with a separate upstream tarball) or to "3.0 (native)" (for Debian native packages).
[18:08] <slytherin> One good thing about 3.0 is it standardizes patch system.
[18:25] <ari-tczew> is it possible to applicate both for MOTU and UUC?
[18:25] <ari-tczew> at the once meeting
[18:26] <cnd> I'm bisecting an older kernel, but when I build I get this at the end:
[18:26] <cnd> dpkg-deb - error: (upstream) version (`unknown') doesn't contain any digits
[18:27] <cnd> woops, wrong channel
[18:32] <geser> ari-tczew: yes, but if you get approved for MOTU you don't need to apply for UUC anymore (MOTU is a member of UUC)
[18:33] <ari-tczew> geser: I know, but my plan is following: I'm going to join MOTU -> if my application will rejected, then I'll join to UUC
[18:34] <kklimonda> hmm.. the next meeting is in 6 days - is it fine to apply right now?
[18:34] <ari-tczew> applicate to UUC isn't hard, right?
[18:35] <geser> ari-tczew: can be handled in one application
[18:35] <ari-tczew> nice
[18:35] <geser> ari-tczew: UUC has the same requirements as ubuntu-members
[18:37] <geser> kklimonda: yes, this should still give the DMB enough time to review your application and the agenda isn't full yet (/me updates the agenda since it still shows the last meeting)
[19:15] <kobrien> When packaging with debuild, how do I ensure that the package is compiled from source on the system I install to?
[19:16] <micahg> kobrien: the package gets built from source on the launchpad build farm, not on the client machines
[19:17] <kobrien> micahg: is it possible to force it to build on the client machine?
[19:18] <hyperair> go use gentoo.
[19:18] <micahg> kobrien: I don't think it's suggested for anything in the archive as that would require build dependencies on the client machines, if you want to do this outside the archive, I would suggest asking in #ubuntu-packaging
[19:18] <hyperair> you could look into dkms-styled packages
[19:18] <kklimonda> kobrien: not really - I think the only exception are kernel modules
[19:18] <micahg> hyperair: I was thinking the same thing :)
[19:18] <hyperair> =)
[19:18] <kklimonda> heh, same here
[19:19] <kobrien> ok, right, I'll pop over to #ubuntu-packaging, thanks people
[19:19]  * hyperair honestly doesn't see the point of getting everything built on the client machine
[19:21] <kobrien> my code is hpc stuff and I want it optimized for the particular processor
[19:21] <kobrien> as much as possible
[19:21] <kklimonda> kobrien: but there is still no infrastructure other than dkms (which, I think, is only for kernel modules) for building sources on the target machines. I guess you could use postinstall script to do that.. but it's really ugly and kitties cry when you thibk about it
[19:22] <kobrien> i'm coming from a FreeBSD world :)
[19:32] <mdomsch> kobrien, there is also very little that compiler optimizations for a specific CPU do these days
[20:27] <kobrien> mdomsch, this is true
[20:30] <fabrice_sp> lfaraone: please remember to use Ubuntu sponsors team and not uus
[20:33] <lfaraone> fabrice_sp: sorry, I think requestsync does that by default.
[20:33] <fabrice_sp> oh, right
[20:34] <fabrice_sp> I think a afixed version has been backported
[20:34] <fabrice_sp> As I'm not anymore member of u-u-s, can someone unsubscribe u-u-s from 557346?
[20:35] <micahg> fabrice_sp: I think it was fixed in teh last upload to lucid but not backported
[20:36] <geser> right, there was no SRU yet for changes to sponsoring
[20:36] <fabrice_sp> it annoy me only because I can't unsubscribe sponsors anymore with u-u-s ;-)
[20:37] <lfaraone> Hm. Do the changes described since .5 in http://code.google.com/p/autokey/source/browse/trunk/debian/changelog merit a request for a FFe?
[20:37] <fabrice_sp> maybe Ubuntu Sponsors team should be made member of u-u-s?
[20:39] <fabrice_sp> lfaraone: not clear (especially the 'Configmanager uses version from common.py). I would subscribe release team, just  in case
[20:40] <lfaraone> fabrice_sp: mk. I already got a FFe for the inclusion of .5, so I feel bad to have to bother the release team again about this <_<;
[20:42] <lfaraone> fabrice_sp: oh, that's just using "APP_VERSION = common.VERSION" rather hard-coding the string in the file.
[20:43] <fabrice_sp> lfaraone: just attach an upstream debdiff then, and subscribe sponsors. That's maybe just some lines
[20:43] <fabrice_sp> and what about "Slight improvement to installation"?
[20:50] <lfaraone> fabrice_sp: documentation updates, http://code.google.com/p/autokey/source/diff?spec=svn233&r=233&format=side&path=/branches/autokey-combined/INSTALL
[20:53] <fabrice_sp> add this documentation to hte bug report: that would help sponsors to decide if FFe is required or not
[20:53] <fabrice_sp> (because if it's not clear => Ffe :-) )
[20:59] <fabrice_sp> lfaraone: barnowl FTBFS here, because of dh_strip
[21:03] <lfaraone> fabrice_sp: re autokey, documented in https://bugs.edge.launchpad.net/ubuntu/+source/autokey/+bug/556453/comments/1
[21:03] <lfaraone> fabrice_sp: intersting. the build succeeded at https://edge.launchpad.net/~lfaraone/+archive/ppa/+build/1654884 and https://edge.launchpad.net/~lfaraone/+archive/ppa/+build/1654885, can you send the log?
[21:04] <fabrice_sp> sounds good re autokey. Will attach the log to the bug report
[21:08] <fabrice_sp> this is why it buils in the ppa: WARNING: not running pkgbinarymangler for this package, as requested
[21:08] <fabrice_sp> I have it installed in my chroot
[21:08] <fabrice_sp> and this is what fails
[21:08] <fabrice_sp> lfaraone:
[21:10] <fabrice_sp> so, it seems pkgbinarymangler is desactivated in ppa's. What about the archive?
[21:11] <lfaraone> hm. I'm not too sure. I'll admit I am unfamiliar with pkgbinarymangler.
[21:12] <fabrice_sp> dh_strip also is not run in ppa's. I'll check with another sync, to check my sbuild installation
[21:21] <fabrice_sp> autokey builds fine (I just ack'd it :-) ), so it's really something with barnowl
[21:22] <lfaraone> hmmm.
[21:34] <geser> what's the problem with pkgbinarymangler?
[21:35] <geser> some things like translations stripping, -dbgsym package creation it not done for PPA but only for the main archive
[21:39] <geser> ah, found the log and could reproduce it
[21:41] <fabrice_sp> ok: I'll mark the bug as incomplete,  then
[21:42] <geser> looks like a bug in pkg-create-dbgsyms
[21:42] <fabrice_sp> Last time I ahd a problem in dh_strip, it was because the package declared debug, but strip the symbols
[21:43] <fabrice_sp> it was Bug 340737
[21:43] <geser> this times it tripped over -O-X... but I've yet to look in detail at it
[21:52] <bdmurray> siretart: I added a possible apport hook to bug 538719
[22:09] <geser> fabrice_sp: a fixed pkg-create-dbgsym waits on merging and sponsoring
[22:10] <AnAnt> Hello, what has happened to guile-gnome2-* packages ?
[22:13] <geser> AnAnt: the binary debs got removed; FTBFS: https://blueprints.launchpad.net/ubuntu/+spec/foundations-lucid-supportable-binaries
[22:13] <geser> see the mail on ubuntu-devel-announce about it
[22:13] <AnAnt> oh, that was one of them ?
[22:14] <AnAnt> so, it's not about being deprecated or so
[22:15] <geser> the source package (guile-gnome-platform) is still published in lucid, just the debs are gone
[22:15] <geser> see http://people.ubuntuwire.org/~lucas/ubuntu-nbs/32/guile-gnome-platform_2.16.1-2ubuntu1_llucid32.buildlog for the FTBFS error
[22:16] <geser> if you get this FTBFS fixed they can come back
[22:21] <AnAnt> ok, thanks
[22:33] <AnAnt> geser: it built
[22:33] <AnAnt> geser: I got latest package from Debian
[22:37] <AnAnt> geser: I will upload it to my PPA
[23:10] <bjsnider> there might be a problem with lucid's vlc mozilla pugin
[23:12] <bjsnider> xulrunner 1.9.2 was sent into the archive 1 week ago. vlc is currently built against 1.9.1. there are no working patches to build vlc against 1.9.2 yet, and the differences are large enough that the build fails. that means i suppose that the plugin might not work at all.
[23:15] <micahg> bjsnider: that must have slipped under the radar
[23:16] <bjsnider> micahg, the vlc guys blame the mozilla guys
[23:17] <micahg> bjsnider: I haven't tried it, seems to work for me in 3.
[23:17] <micahg> 3.6
[23:17] <bjsnider> the build fails so thoroughly that you wouldn't think it would work
[23:17] <bjsnider> a whole bunch of symbols are affected
[23:18] <micahg> bjsnider: I'm saying it's FTBFS, but the binary seems to work
[23:25] <christoph_debian> hm has ubuntu somewhere a per-package popcon graph like the debian one web-accessible?
[23:25] <micahg> bjsnider: does the plugin from the archive work?
[23:25] <micahg> bjsnider: if yes, I'll worry about the FTBFS later
[23:37] <ScottK> christoph_debian: I think it's just text data at popcon.ubuntu.com.
[23:38] <bjsnider> micahg, i don't use it. i know about this for other reasons than that.
[23:41] <christoph_debian> ScottK: ok works just hoped there'd be some nice pictures ;)