[00:08] <wgrant> maxb: Was that section thing in the primary archive? There's a bug filed to make it do that for PPAs, so I presume it doesn't do it in PPAs yet.
[00:10] <maxb> It was in a PPA, though presumably the same issue will bite as soon as someone wants to do an official backport in the primary archive backports pocket
[00:11] <wgrant> maxb: Huh... maybe it's because Soyuz doesn't know about the 'dev' section at all (it should be 'devel'). Normally it will reject saying that a section is not valid for that distroseries.
[00:12] <wgrant> But anyway, PPAs will soon override all unknown and mismatched sections to misc.
[01:15] <mrooney> Is anyone familiar with launchpad exports? When I do a po export I get some in the root of the tarball, some in po/ and some in <domain>/
[01:16] <mrooney> I can't really figure out why they get put in three different locations
[02:12] <blueyed> Is there a problem with (hosted) bazaar branches being published on LP?
[02:16] <beuno> blueyed, are you getting something like: bzr: ERROR: Connection error: curl connection error (GnuTLS recv error (-9): A TLS packet with unexpected length was received
[02:17] <blueyed> beuno: no. something different.. I've thought the branch from the cron server would have been pushed, but it says "These branches have diverged.". So it has not been pushed after all. Sry.
[02:22] <blueyed> I'm wondering why it says "diverged" though, since it's a cron jobs and it should get pushed only from there. If I unbind another checkout of that branch that shouldn't have any influence on this, right?
[02:22] <blueyed> (The branch gets synced with tailor.)
[02:23] <Snova> I've had that happen once or twice (I think because I interrupted it), it's because the branch on the server has a different history than the source. If you know that it's appropriate, --overwrite will do the obvious thing.
[02:24] <blueyed> well.. i've compared the history.. it's the same.. only that the last few revisions had not been pushed. I'll rather merge, then commit and pull, to be sure.
[02:25] <wgrant> Snova: That is nothing to do with Launchpad. Some part of the branches' histories has diverged.
[02:25] <wgrant> Gah.
[02:25] <wgrant> blueyed: ^^
[02:26] <wgrant> And if they haven't diverged, then it's a bzr problem.
[02:26] <Snova> Everybody seems to be doing that today. :)
[02:27] <blueyed> wgrant: yeah, I've had this happen before.. I was just wondering how that could have happened here. yes. any idea how I could compare the tip and/or IDs, just to debug this?
[02:27] <wgrant> blueyed: 'bzr log --show-ids -r-1' on the remote branch is a good start.
[02:28] <wgrant> See if that same revid is in the branch you are trying to push from.
[02:30] <wgrant> 'bzr heads' on the branch should also tell you that more directly.
[02:32] <blueyed> revision-id is different for r7063, but also the parent. both have the same timestamp in the id though.
[02:32] <blueyed> the revision id of r7062 is different, too. but their parent matches. odd.
[02:32] <wgrant> Did you upgrade the version of tailor, perhaps?
[02:33] <wgrant> I've seen the same thing when upgrading to a new bzr-svn that uses a different mapping version.
[02:33] <wgrant> Although that's generally fairly obvious.
[02:34] <blueyed> yes, maybe. but before already. I've also tried to fix there myself. but that has been before that. r7062 is from today.. and that has been days ago.
[02:34] <blueyed> no big problem. Thanks for your support.
[02:34] <wgrant> I guess you'll need to talk to the tailor people, or just push --overwrite.
[02:35] <blueyed> push --overwrite is bad for branches, not?
[02:35] <blueyed> why not merge, commit, push?
[02:36] <wgrant> That's messy. But it is the best way if anybody else is using that branch, right.
[02:46] <blueyed> really strange. merge causes a conflict.
[02:46] <blueyed> Also r7063 (the last one on LP) and r7064 should have been pushed in the same step..!
[02:46] <wgrant> Try --reprocess?
[02:47] <blueyed> --reprocess needs --force?!
[02:47] <lifeless> nor normally
[02:48] <blueyed> it says "has uncommitted changes"
[02:49] <blueyed> It's more a topic of #bzr anyway.. sry. Will come back to it tomorrow..
[02:50] <lifeless> blueyed: you probably want to revert first
[02:50] <blueyed> it's really odd that only one half has been pushed.
[02:51] <lifeless> blueyed: the one on the server is not a prefix of the one you are trying to push
[02:51] <blueyed> lifeless: I see, I've thought it would work from an already broken merge. however, also conflicts.
[02:51] <blueyed> lifeless: this is a cron server, who syncs every 10 minutes.. commits changesets from CVS and then pushes them.
[02:52] <lifeless> blueyed: sure, for bzr to be telling you that they have diverged, they must have diverged
[02:53] <lifeless> blueyed: 'bzr missing' can report on this for you
[02:53] <blueyed> lifeless: yes. but why? this looks like some bug: tailor has committed (e.g.) r4 and r5, then pushed that. LP.net only has r4 and now bzr says it's diverged.
[02:53] <lifeless> blueyed: the r4 on lp is not the r4 you have locally
[02:53] <wgrant> LP doesn't have r4, does it? It has some different one.
[02:53]  * wgrant is beaten again.
[02:54] <lifeless> blueyed: log --show-ids can show you the internals, or as I already suggested, use bzr missing
[02:57] <blueyed> yep, r4 on LP is a different one.. have seen this with --show-ids before.. bzr missing talks about two missing and 10 extra ones. But those get automatically committed from that cron server (only). The last changeset that got pushed (partly) successful had r3, r4 and r5. the last one on LP is now r4 and r3/r4 are extra/missing/different now.
[02:58] <lifeless> blueyed: push is atomic, it never partly works
[02:58] <lifeless> blueyed: whatever is going on is all to do with your scripts
[02:59] <blueyed> lifeless: the "scripts" is tailor, which does the commits and then "bzr push", which does the push.
[02:59] <lifeless> blueyed: so, as bzr push won't uncommit; it sounds like tailor is your root cause of problems
[03:00] <blueyed> unfortunately I have no stderr of bzr in the logs (and therefore did not notice that push stopped working now, due to uncommitted changes).
[03:00] <lifeless> blueyed: set +x is your friend
[03:04] <blueyed> lifeless: what do you mean?
[03:04] <lifeless> blueyed: bzr returns non-zero when commands fail
[03:04] <blueyed> I log to a specific logfile, using redirection, but until now only stdout got logged. however, I should gave gotten an cron mail with stderr.
[03:05] <blueyed> lifeless: so you mean "set -e"?
[03:05] <blueyed> it's the last line of the script anyway?
[03:29] <blueyed> lifeless: did you mean "set -e" instead? also, if "push" is atomic.. where should the 2/3 push come from? the revision-id even has the username/hostname of the cron server and the timestamp matches, too. only the last part of the id does not.
[03:30] <blueyed> Anyway, thanks for your support - as said, I will try to fix this tomorrow, but until now it looks like a bug in bzr. It _may_ be related to server hiccups I've experienced today, but should not.
[03:31] <lifeless> blueyed: the operation proceeds in phases, but if the final step isn't completed, the branch remains unaltered
[03:31] <lifeless> blueyed: its definitely not a bzr bug
[03:32] <lifeless> it may be a bug in how its being used; or tailor may be doing something odd - tailor has done that before
=== kyselejsyrecek1 is now known as kyselejsyrecek
=== Pici` is now known as Pici
[13:39] <dereine_> is it possible to make a vcs automatic import for a ~/+junk branch
=== You're now known as ubuntulog
=== deryck_ is now known as ghost
=== ghost is now known as deryck_
=== deryck_ is now known as deryck
=== matsubara is now known as matsubara-afk
[15:53] <RachedTN> hello, I wanna to chnage the name of my team from this : https://edge.launchpad.net/~ubuntu-tn-drafting to this : https://edge.launchpad.net/~ubuntu-tn-editorial
[15:54] <beuno> RachedTN, sure, what seems to be the problem?
[15:55] <RachedTN> beuno: I am the coordinator of the editorial team, and our LoCo will create another group for drafting, that's why I wanna to change the name and the url :)
[15:56] <RachedTN> it's just a problem of organisation :)
[15:56] <beuno> RachedTN, sure, it sounds fine. Are you having a problem doing that?
[15:58] <RachedTN> bueuno : I really don't know how to do this : should I first create the new team, than how could I translate the members from the old team to the new team ?
[15:58] <beuno> RachedTN, just rename the team
[15:58] <RachedTN> ok, I have done this :)
[15:59] <RachedTN> beuno: could you activate the maililng list for the : https://edge.launchpad.net/~ubuntu-tn-drafting
[15:59] <exarkun> Ooh, mailing lists
[16:00] <beuno> RachedTN, yes, approved
[16:00] <RachedTN> beuno: thanks a lot :)
[16:00] <RachedTN> exarkun: ??
[16:00] <exarkun> RachedTN: I like mailing lists.
[16:01] <RachedTN> exarkun: me too :)
[16:16] <RachedTN> beuno: renaming the team will not change the url, is there any possibility to change the URL, I chked the : https://edge.launchpad.net/~ubuntu-tn-editorial and it's not reserved
[16:20] <beuno> RachedTN, ah, if you have a mailing list, you can't rename
[16:20] <beuno> sinzui knows all about this
[16:20] <RachedTN> beuno: ok
[16:21] <sinzui> RachedTN: Names (launchpad ids) can be changes by a Launchpad admin
[16:21] <sinzui> RachedTN: Changing a name can be dangerous if the team has a PPA or a mailing list because those artifacts have permanent urls
[16:21] <RachedTN> sinzui: what should I do, write a request on https://answers.edge.launchpad.net/ubuntu  or what ?
[16:22] <RachedTN> sinzui: The mailing list was just activate few minutes later, so there is no problem with that point
[16:22] <sinzui> RachedTN: https://answers.edge.launchpad.net/launchpad/+addquestion to get the attention of an admin
[16:23] <sinzui> RachedTN: If the their is a mailing list, the rename will fail
[16:23] <sinzui> RachedTN: the list It must be destroyed
[16:24] <RachedTN> sinzui: I will descativate the mailing list ans there is no problem if it is destroyed because I will have another one with the new url :)
[16:24] <sinzui> RachedTN: I see. I think that will be fine
[16:24] <RachedTN> sinzui, beuno : thnks for your help :)
[16:29] <christoph_debian> Hi all! anyone an Idea what goes wrong @ https://bugs.launchpad.net/ubuntu/+source/afflib/+bug/230350 it gives me some 503 for some time now ...
[16:29] <ubottu> Ubuntu bug 230350 in sapphire "Missing Debian Maintainer field" [Wishlist,Fix released]
=== bdmurray_ is now known as bdmurray
=== mtaylor_ is now known as mtaylor
=== beuno_ is now known as beuno
=== matsubara-afk is now known as matsubara
[17:48] <jkakar> Is it possible to create two bug tasks for a bug, targeted to the same project?
[17:48] <jkakar> I want to put a bug in more than one milestone.
[18:00] <intellectronica> jkakar: why would you want to do that?
[18:01] <Milosz> guys
[18:01] <Milosz> the amd64 package of one of my PPA sources is now building for almost 2 hours
[18:01] <Milosz> but it usually takes around 25 minutes to build
[18:01] <Milosz> on the launchpad systems
[18:01] <Milosz> could someone check whether the machine crashed?
[18:01] <Milosz> https://launchpad.net/~internalerror/+archive/ppa/+build/947426
[18:02] <Milosz> not just for me I guess but it might be generally good
[18:02] <jkakar> intellectronica: Well, we've been talking about using milestones, instead of tags, to group related things.  For example, a whole bunch of "improve-package-ui" bugs could be assigned to a "Package UI Milestone".
[18:03] <jkakar> intellectronica: The reasons for wanting this are: milestones have dates and milestones are easier to discover because you see them in the drop-down list.
[18:03] <jkakar> intellectronica: When editing tags, there's no indication of what the current official tags are.  You have to know there's a "package-ui-improvements" tag.
[18:03] <intellectronica> jkakar: interesting. but anyway, you can't do that. i think we'll have to do this using custom lists one day
[18:04] <intellectronica> jkakar: as it happens, i am just about to submit a branch that makes it very obvious and easy to use official tags :)
[18:04] <jkakar> intellectronica: Nice. :)
[18:04] <jkakar> intellectronica: Thanks for clarifying.
[18:29] <jkakar> Is there a query string I can add to this URL to pre-fill the email address: https://edge.launchpad.net/+forgottenpassword
[18:30] <ahasenack> hey guys, do you know whom I should poke to have landscape-client crash bugs opened by apport emailed to the landscape team? The way it is now, we don't get to know about them
[18:35] <kiko> ahasenack, subscribe to the landscape-client package.
[18:37] <ahasenack> kiko: hmm, I thought I was subscribed. Sorry.
[18:40] <ahasenack> kiko: hmm, I was subscribed already indeed. I think apport does something different, because it may contain sensitive data in the crash dumps, and the bug is only visible to some special group first
[18:49] <kiko> ahasenack, you only see the bug once it has been retraced and disclosed
[18:49] <kiko> you should talk to pitti to get the skinny on it
=== sale_ is now known as sale
=== Andre_Gondim is now known as Andre_Gondim-afk
=== bureflux is now known as afflux
=== lamont` is now known as lamont
=== salgado is now known as salgado-brb