[00:53] <aj00200> I am trying to merge two nearly identical launchpad branches with the command "bzr merge --remember lp:~bbot+core+developers/bbottheircbot/BBot_Githubt --force" but I get a no common ancestor error. Is there a way to force it without the common ancestor (and hopefully make it a common ancestor)
[01:58] <wgrant> aj00200: That's going to be difficult if you're maintaining and separately committing to both bzr and git trunks.
[01:58] <wgrant> aj00200: #bzr may be able to offer advice on how to achieve what you desire.
[01:59] <wgrant> Forcing a one-off merge now won't help the future.
[04:06] <poolie> i'm getting a gpg error from apt trying to update from a private ppa
[04:06] <poolie> is this known at all?
[04:07] <wgrant> poolie: No.
[04:07] <wgrant> poolie: Which?
[04:07] <wgrant> And what's the error?/
[04:07] <poolie> canonical-ux
[04:07] <poolie> "The following signatures were invalid: BADSIG 6D8F9D432E7"
[04:07] <wgrant> BADSIG?
[04:07] <wgrant> Ew.
[04:07] <wgrant> walled-garden?
[04:07] <poolie> yes
[04:07] <wgrant> natty?
[04:07] <wgrant> Or oneiric?
[04:08] <poolie> strangely enough if i download the Release and .gpg file through chrome they do verify ok
[04:08] <poolie> oneiric
[04:08] <wgrant> That's what I was just checking.
[04:08] <wgrant> Sounds like your local apt cache may be broken?
[04:08] <wgrant> It uses If-Modified-Since.
[04:09] <wgrant> sudo rm /var/lib/apt/lists/*walled-garden*, perhaps.
[04:09] <poolie> yes it does sound  like that
[05:05] <poolie> wgrant: well, https://bugs.launchpad.net/launchpad/+bug/836419
[05:05] <poolie> not going to do anything new with it now
[05:05] <poolie> s/new/
[05:07] <wgrant> Ew.
[05:07] <wgrant> We write Release files directly into dists/
[05:07] <wgrant> WTF
[05:07] <wgrant> Who needs atomicity.
[05:08] <poolie> so it could be race between apache and the writer?
[05:08] <poolie> that would account for it
[05:08] <wgrant> Right, it could just be very, very bad timing.
[05:08] <poolie> this is a bit worse than the other one because it doesn't get unstuck unless you manually delete the local cache file
[05:08] <wgrant> Since the file contents are precalculated.
[05:08] <wgrant> Yeah.
[05:09] <poolie> ok, that seems like the likely explanation then
[05:09] <wgrant> maverick's final ISOs ended up with a similar sort of situation with extras.ubuntu.com, required some future-touching of its indices to stop apt errors.
[05:09] <wgrant> It would be nice if apt detected the conflict and considered that the files might not be valid.
[05:09] <poolie> mm
[05:10] <poolie> arguably if the signature's invalid it shouldn't cache the file etc
[05:10] <wgrant> Right.
[05:10] <wgrant> Eventually everything will use InRelease and that won't be so much of a problem, hopefully.
[05:10] <wgrant> We'll just have terrible vulnerabilities instead...
[05:14] <poolie> is that just a release file with an inline signature?
[05:16] <wgrant> Yes.
[05:16] <wgrant> So there's no inconsistency, and it can more easily invalidate all involved files if the sig is bad.
[05:18] <poolie> right
[05:18] <poolie> but why terrible vulnerabilities then?
[05:21] <wgrant> Well, inline OpenPGP signatures have a habit of not being correctly implemented. I think I've reported all the obvious holes in apt's implementation, but you never know.
[05:22] <wgrant> I generally consider them a bad idea, because correct implementations are rare.
[05:22] <wgrant> And difficult.
[05:23] <poolie> oh, because gpg tends to default to saying "yes, something in here was signed", as you aluded to?
[05:23] <poolie> i agree
[05:24] <poolie> i just wasn't sure if you meant the specific combination with nonatomic writes was a probelm
[05:25] <wgrant> No, no, unrelated. Just saying that neither approach has a history of being well-implemented, so we probably can't win.
[05:25] <poolie> probably not :)
[08:35] <pmjdebruijn> hi all
[08:35] <pmjdebruijn> https://launchpadlibrarian.net/78452640/upload_2841727_log.txt
[08:35] <pmjdebruijn> any clue what went wrong there?
[08:36] <pmjdebruijn> I don't see any epoch defined in my package?
[08:36] <pmjdebruijn> nor the previous package
[08:37] <wgrant> pmjdebruijn: The old kvm binary package must have an epoch in its version.
[08:37] <wgrant> Which PPA is this?
[08:37] <pmjdebruijn> it this have this: dh_gencontrol -pkvm -- -v1:$(DEB_VERSION)
[08:37] <pmjdebruijn> wgrant: https://launchpad.net/~unnet-pkg-master/+archive/kvm-spice-release/+packages
[08:42] <wgrant> pmjdebruijn: https://launchpad.net/~unnet-pkg-master/+archive/kvm-spice-release/+build/2746647
[08:42] <wgrant> kvm-1:84+dfsg-0ubuntu16+0.14.1+noroms+0ubuntu2unnet1~lucid
[08:42] <pmjdebruijn> right
[08:42] <pmjdebruijn> though the new package should generate kvm-1:84+dfsg-0ubuntu16+0.15.0+noroms+0ubuntu2unnet1~lucid
[08:42] <pmjdebruijn> but it seems it doesn't
[08:43] <wgrant> That would be a bug in your package.
[08:45] <pmjdebruijn> it's just a debian backport :D
[08:45] <pmjdebruijn> hmmmm
[08:45] <wgrant> I'm not sure that Debian's packaging is compatible with Ubuntu's.
[08:45] <wgrant> Our virt stacks differ significantly in parts.
[08:46] <pmjdebruijn> I backported 0.14.1 previous without issues
[08:46] <pmjdebruijn> oh wait
[08:46] <pmjdebruijn> erhm
[08:46] <pmjdebruijn> crap
[08:46] <pmjdebruijn> I got the other from ubuntu onoiric
[08:46]  * pmjdebruijn hits himself in the head
[08:47] <pmjdebruijn> neverind
[08:47] <pmjdebruijn> and thanks for being my rubberduck :)
[08:51] <pmjdebruijn> sorry for wasting your time
[09:17] <pmjdebruijn> ah
[09:17] <pmjdebruijn> wgrant: dh_gencontrol -pkvm -- -v1:$(DEB_VERSION)
[09:17] <pmjdebruijn> vs
[09:17] <pmjdebruijn> wgrant: dh_gencontrol -pkvm -- -v1:84+dfsg-0ubuntu16+$(debsrc_ver)+$(debian_rev)
[09:17] <pmjdebruijn> that bit me
[09:31] <wgrant> pmjdebruijn: Right. I guess Ubuntu long ago used the upstream KVM version.
[09:52] <pmjdebruijn> indeed
[12:05] <henninge> adeuring: Hi! ;-)
[12:08] <adeuring> hi henninge, I'll change the tpopic
[12:08] <henninge> adeuring: thanks ;)
[14:56] <daker> hi
[14:57] <deryck> hi daker
[14:57] <deryck> adeuring, I'll take IRC now.
[14:57] <adeuring> deryck: thanks!
[14:58] <deryck> adeuring, np.  I really should be taking it an hour earlier than now, but forget sometimes. So I don't mind a ping from you about it. :)
[15:02] <daker> deryck, i need some help
[15:02] <deryck> daker, what sort of help?
[15:02] <daker> the recipie is failing on the lp builders, but not locally in a pbuild chroot
[15:03] <daker> https://code.launchpad.net/~daker/+archive/slumber/+build/2750501
[15:03] <daker> deryck, https://code.launchpad.net/~daker/+recipe/slumber-daily
[15:03] <TheEvilPhoenix> there's a reason it gives you the build logs you know... just sayin
[15:04] <TheEvilPhoenix> its a python issue
[15:04] <TheEvilPhoenix> when its building it cant find a specified module
[15:04] <TheEvilPhoenix> so it fails and errors out
[15:04] <daker> the lp build is not pulling in a needed build-dep (python-setuptools)
[15:06] <daker> TheEvilPhoenix, deryck python-setuptools is in build-deps but the lp build doesn't pull it
[15:07] <TheEvilPhoenix> wasnt there an issue with the builders not taking into account PPA dependencies too, deryck?
[15:07] <TheEvilPhoenix> coulda sworn several people were here complaining about that a few weeks ago
[15:07] <deryck> I'm not sure actually.
[15:07] <deryck> bigjools or abentley, can one of you help here?  I'm dumb about recipes.
[15:07] <TheEvilPhoenix> (me included)
[15:08] <TheEvilPhoenix> deryck:  i dont think the issue is the recipe
[15:08] <TheEvilPhoenix> i think the issue is the builders
[15:08] <TheEvilPhoenix> i.e. its not reading dependencies for building
[15:08] <TheEvilPhoenix> or if it is
[15:08] <TheEvilPhoenix> its not grabbing them
[15:08]  * bigjools looks at build log
[15:09] <bigjools> ummm
[15:09] <bigjools> Build-Depends: debhelper (>= 7.0.50~), cdbs (>= 0.4.49)
[15:09] <bigjools> buggy package/recipe
[15:09] <TheEvilPhoenix> LOL
[15:09] <TheEvilPhoenix> daker:  failed build-deps line in control
[15:10] <daker> TheEvilPhoenix, can you explain ?
[15:10] <TheEvilPhoenix> daker:  read bigjools's line
[15:10] <TheEvilPhoenix> <(ID+)bigjools> Build-Depends: debhelper (>= 7.0.50~), cdbs (>= 0.4.49
[15:10] <TheEvilPhoenix> that's whats in the control file
[15:10] <TheEvilPhoenix> so...
[15:10] <TheEvilPhoenix> that explains why its not installing the build dep
[15:10] <TheEvilPhoenix> unless you can provide other proof stating that the control file *has* the package you need
 buggy package/recipe  <--- that's basically what i just said
[15:11] <abentley> deryck: I had a look, but istm that bigjools has it in hand.
[15:11] <deryck> abentley, yes, thanks anyway abentley.
[15:11] <deryck> and thanks bigjools! :)
[15:11] <daker> TheEvilPhoenix, bigjools my control doesn't actualy look like this
[15:11] <daker> control file*
[15:12] <bigjools> the package is from a recipe, right?
[15:12] <bigjools> so is it grabbing the packaging branch you expect?
[15:13] <daker> it's grabbing the packaging from another branch
[15:13] <daker> look at "Recipe contents" https://code.launchpad.net/~daker/+recipe/slumber-daily
[15:13] <TheEvilPhoenix> and whats the control file in that branch say
[15:13] <bigjools> I can see the control file in the packaging branch has got the right build-depends
[15:14] <TheEvilPhoenix> ninja'd :P
[15:15] <daker> bigjools, so my control file is correct ?
[15:15] <bigjools> the one in the packaging branch has the dependency you talked about
[15:16] <bigjools> oh
[15:16] <bigjools> ha
[15:16] <bigjools> the recipe build failed
[15:16] <bigjools> ImportError: No module named setuptools
[15:16] <bigjools> yet the build is reported as successful
[15:16] <bigjools> abentley: see https://code.launchpad.net/~daker/+archive/slumber/+recipebuild/76990
[15:17] <bigjools> [python-module-clean/slumber] Error 1 (ignored)
[15:17] <abentley> bigjools: looking
[15:17] <bigjools> not sure it should be ignoring that!
[15:18]  * daker is rolling his eyes
[15:18] <bigjools> abentley: the build is OK but the log says otherwise.  It's ignored the error though, and the package ends up with an incorrect control file it seems.
[15:19] <bigjools> I don't know which component decided to ignore it, my recipe knowledge is limited
[15:19] <abentley> bigjools: yes, I see that.  I'm trying to see how that could happen.  I don't think our code is ignoring the error.
[15:19] <bigjools> so I shall hand back to deryck / abentley
[15:19] <bigjools> abentley: yeah it might be one of the build tools
[15:20] <abentley> bigjools: would this be /usr/lib/pbuilder/pbuilder-satisfydepends ?
[15:20] <bigjools> no idea
[15:20] <bigjools> something didn't install setuptools
[15:21] <abentley> bigjools: it looks like dpkg-buildpackage is emitting 0 even though it failed.
[15:21] <bigjools> abentley: yes see the "[python-module-clean/slumber] Error 1 (ignored)"
[15:23] <idnar> what is a "subteam"?
[15:24] <abentley> bigjools: I don't know enough to know whether this invocation is sane:  "/usr/bin/dpkg-buildpackage -i -I -us -uc -S".  If it is, then it's a problem we can't fix.
[15:25] <bigjools> abentley: unfortunately I don't know either
[15:25] <abentley> bigjools: okay, who do we have who knows packaging?
[15:26] <abentley> bigjools: btw, the relevant file is lib/canonical/buildd/buildrecipe
[15:26] <bigjools> jelmer might know
[15:28] <jelmer> at a first glance, it looks like a missing build dep on python-setuptools
[15:29] <abentley> jelmer: right.  We're trying to figure out how to make that a recipe build failure, because right now, the error is ignored.
[15:31] <daker> jelmer, abentley this line Build-Depends: debhelper (>= 7.0.50~), cdbs (>= 0.4.49) is from an old rev of the packaging branch
[15:32] <daker> so the lp builder is not pulling the last rev
[15:32] <jelmer> abentley, bigjools: cdbs adds a "-" at the front of the "setup.py clean" line
[15:33] <jelmer> abentley, bigjools: causing make to ignore non-zero exit codes
[15:33] <jelmer> see /usr/share/cdbs/1/class/python-distutils.mk:135
[15:34] <jelmer> this is an issue in the package, not the recipe builder
[15:35] <abentley> jelmer: thanks.
[15:35] <daker> jelmer, what should i do to fix it ?
[15:36] <jelmer> daker: add a build dependency on python-setuptools
[15:36] <jelmer> there is a bug open in debian about cdbs ignoring errors from commands run in the clean target
[15:36] <jelmer> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441020
[15:37] <daker> jelmer, don't make crasy
[15:37] <daker> jelmer, look http://bazaar.launchpad.net/~daker/slumber/deb-packaging/view/head:/debian/control
[15:37] <daker> and as i said :
 jelmer, abentley this line Build-Depends: debhelper (>= 7.0.50~), cdbs (>= 0.4.49) is from an old rev of the packaging branch
 so the lp builder is not pulling the last rev
[15:38] <jelmer> daker: your debian version hasn't changed, so it won't do a new build
[15:39] <jelmer> daker: you probably want to update it to include the packaging branch revno
[15:44] <daker> jelmer, how can i do that? any wiki page ?
[15:46] <jelmer> add something like ~ppa{revno:packaging} to the end of the version string
[15:50] <bigjools> thanks for helping jelmer
[15:52] <abentley> daker: The wiki is here: https://help.launchpad.net/Packaging/SourceBuilds/GettingStarted#The%20anatomy%20of%20a%20recipe
[16:48] <huangkan> I downloaded codes of project docky through bzr. The question is how to reconstruct a project from these codes in ide like eclispe, so that I could read, run and debug? Is there any tutorial on it?
[16:50] <jelmer> huangkan: that really depends on the project, it's out of scope for #launchpad
[16:51] <jelmer> huangkan: the docky help/developer channels are probably a better place to ask
[16:51] <huangkan> jelmer:thx
[17:31] <eLBati> ciao
[17:32] <eLBati> is it possible to understand where a branch has been branched from ? :-)
[17:33] <deryck> eLBati, you mean locally or in the web UI?  bzr info locally should tell you something about the branch.  but I'm guessing you mean web UI?
[17:34] <eLBati> deryck, in the web UI
[17:35] <eLBati> moreover , bzr info doesn't tell me it, since I originally branched using another pc
[17:35] <deryck> eLBati, yeah, I don't think we have anything like that in the web ui.
[17:35] <deryck> eLBati, what's the branch url on lp?  Can I see it?
[17:35] <eLBati> deryck, https://code.launchpad.net/~openobject-italia-core-devs/openobject-italia/l10n_it_fix_partially_deductible_vat
[17:36] <eLBati> deryck, how can I know what branch should I propose the merge to?
[17:37] <eLBati> I have 2 options :-)
[17:37] <deryck> eLBati, well, it's stacked on lp:openobject-italia so I'd guess that as a starting point.
[17:37] <eLBati> uhm no
[17:38] <eLBati> deryck, the options are this https://code.launchpad.net/~openerp/openobject-addons/trunk or this https://code.launchpad.net/~openerp/openobject-addons/6.0
[17:38] <deryck> eLBati, there's probably a bzr command to see common branch starting points, but my bzr foo is not that strong.  maybe abentley can help us?
[17:39] <deryck> abentley, see eLBati above.  he doesn't know what branch he branched from and wants to figure that out.
[17:46] <Lekensteyn> Hi, can I make a mailinglist for a team open while keeping the PPA uploading privileges away?
[18:05] <lamalex> hey everyone, i'm trying to get started with bzr colo, so I ran bzr colo-init lp:unity but it errors out with bzr: ERROR: File exists: '/srv/bazaar.launchpad.net/mirrors/00/05/66/af/.bzr'
[18:05] <lamalex> am I doing it wrong?
[18:07] <lamalex> yes..i a
[18:07] <lamalex> am
[18:25] <abentley> eLBati, deryck: bzr doesn't track branch points, but you can look back at old revisions and see what their branch nick was using "bzr log --long".
[18:25] <abentley> eLBati, deryck:   Or you can compare your branch with the candidates using "bzr missing . https://code.launchpad.net/~openerp/openobject-addons/trunk".
[18:26] <abentley> eLBati, deryck:   Or you can compare your branch with the candidates using "bzr missing . https://code.launchpad.net/~openerp/openobject-addons/trunk"
[18:27] <abentley> eLBati, deryck: or you can see what changes would be merged by doing "bzr diff -r ancestor:https://bazaar.launchpad.net/~openerp/openobject-addons/trunk"
[18:40] <eLBati> many thanks abentley deryck
[18:40] <abentley> eLBati: np
[18:54] <deryck> abentley, I'll hand over IRC to you now.
[18:54] <abentley> deryck: okay
[19:59] <ovnicraft> hello, its possible branch a project on LP w/o LP account ?
[20:00] <maxb> yes
[21:32] <GTRsdk2> abentley?
[21:32] <GTRsdk2> can you delete a project page for me?
[22:08] <maxb> GTRsdk2: projects are never deleted, only deactivated. Please file a question to request that