[00:00] <igc> morning
[00:01] <beuno> goooooooood morning igc
[00:01] <Pilky> igc: you in australia or something?
[00:03] <igc> Pilky: yes, Brisbane
[00:04] <igc> morning beuno!
[00:04] <thumper> jelmer: ping
[00:08] <jelmer> thumper, pong
[00:09] <thumper> jelmer: lp:~jelmer/python/trunk is this still wanted?
[00:09] <thumper> jelmer: it is having problems scanning
[00:26] <LaserJock> jelmer: around?
[00:28] <jelmer> thumper: no, should be ok to remove
[00:28] <jelmer> LaserJock, hi
[00:28] <LaserJock> jelmer: it's me again :-)
[00:28] <LaserJock> jelmer: I'm trying to get bzr-svn going on Fedora 9
[00:28] <thumper> jelmer: do you want to delete it or shall I?
[00:30] <LaserJock> jelmer: when I try to use bzr-svn it gives me "Installed Subversion version does not have updated Python bindings."
[00:30] <jelmer> thumper: I don't think I can, can I?
[00:30] <thumper> jelmer: you should be able to
[00:31] <LaserJock> I looked in the bzr-svn README about the issue, but I'd like to avoid having to build my own Subversion 1.5 if I can
[00:32] <LaserJock> jelmer: I wondered if you'd had other people wondering about bzr-svn on Fedora. Surely somebody must use it
[00:33] <jelmer> LaserJock: you do really need to have subversion 1.5 or 1.4 with the patch, there's no way around that
[00:33] <jelmer> afaik everybody who has used bzr-svn on fedora has done the patching
[00:34] <LaserJock> jelmer: ok, do you know where the patch is?
[00:34] <jelmer> LaserJock, yes, it's linked from the bzr-svn wiki page
[00:34] <LaserJock> doh
[00:36] <jelmer> thumper: hmm, it's mirrorred so it'll just be recreated next time I run my register branches command :-/
[00:37] <jelmer> thumper: I'll see if I can create a new branch from python svn and upload that
[00:37] <thumper> jelmer: ok
[00:39] <thumper> jelmer: lp:~jelmer/bzr-gtk/AUTHORS??
[00:39] <jelmer> thumper: yeah, error in my script that did the registration :-/
[00:39] <thumper> jelmer: are you going to clean up those branches?
[00:40] <thumper> jelmer: https://code.edge.launchpad.net/~jelmer/ shows lots of mirror failures
[00:50] <jelmer> thumper: are the failures a problem? The web ui doesn't make deleting them very easy
[00:51] <thumper> jelmer: no not really a problem, it just looks messy :)
[01:23] <Verterok> moin
[01:27] <mrbrocoli> how do i remove a stale bzr lock?
[01:28] <spiv> "bzr break-lock URL"
[01:28] <mrbrocoli> awesome, thanks!
[01:28] <beuno> spiv, maybe we should add that to the message that says the repo is locked?
[01:29] <spiv> beuno: yeah.  I think there's even a bug about that :/
[01:29]  * beuno goes look
[01:36] <beuno> found it, bug #139202
[01:39]  * beuno diggs into the code
[01:40] <mwhudson> heh, i thought from the summary that that was probably an mpt bug
[01:41] <Pilky> does it take a while for launchpad to recognise a push to it on the site?
[01:41] <mwhudson> Pilky: it can take a minute or two
[01:41] <Pilky> ah there we go
[01:50] <LaserJock> jelmer: woot! I finally built new Fedora 9 subversion rpms and bzr-svn now loads
[01:51] <jelmer> LaserJock, nice
[01:51] <jelmer> would you perhaps be interested in putting them up somewhere and linking to them from the wiki?
[01:51] <LaserJock> I was just thinking of that
[01:51] <LaserJock> it'd be a shame for me to horde them all to myself ;-)
[02:14] <LaserJock> jelmer: alright, all done, have a look at http://bazaar-vcs.org/BzrForeignBranches/Subversion#fedora-9-i386 and see if it looks ok
[02:17] <poolie> jam, did you work out what was wrong with your ssh keys?
[02:17] <LaserJock> unfortunately right now I can only make i386 rpms
[02:56] <tolstoy> Hi Folks. I have a repo (via init-repo) with no files in it, and I'd like to create a new repo style branch (NOT in init-repo) that also has no files in it.
[02:56] <tolstoy> Sort of like I had "branched" from the original, then "pushed" elsewhere. Possible?
[02:57] <tolstoy> I don't see a --no-tree option on a lot of these things.
[02:58] <mwhudson> yeah, i think that must be possible but not necessarily from the command line
[02:58] <tolstoy> Ah.
[02:58] <tolstoy> Hm.
[02:58] <mwhudson> probably easy-ish to do it in a plugin
[02:58] <mwhudson> how badly do you want it? :)
[02:59] <tolstoy> I just have a bash script. Running it against the output of a cvsps conversion to arrange the repo how I want it.
[02:59] <tolstoy> So it's not really worth it.
[02:59] <tolstoy> I can just "branch" to a staging area, then from there, "push" it to the "source-of-truth" area.
[03:00] <tolstoy> Hm. Can I do a push from a repo with just a .bzr in it and end up in the same place?
[03:01] <tolstoy> I think that works, actually.
[03:01] <tolstoy> Yep!
[03:03] <mwhudson> yes
[03:03] <tolstoy> Faster, too.
[03:03] <mwhudson> you can also do a regular branch, then 'bzr remove-tree' i think it is
[03:04] <mwhudson> though this is obviously a bit of a waste of effort :)
[03:04] <tolstoy> Yes. I'm glad I didn't see that earlier.
[03:05] <tolstoy> My experiment here is to see if we can organize project repos by releases.
[03:05] <tolstoy> Sort of ruins the shared-branch repo thing, but ah well.
[03:16] <bob2> another way: mkdir foo ; bzr init foo ; bzr reconfigure --branch foo ; bzr push ~/repo/blah foo
[03:18] <tolstoy> Cool.
[03:19] <tolstoy> The push method (just have bash cd in and push) worked, but, alas, the branches are not consistently named.  Still, it mostly worked and was slow only on the project with 8000 revisions.
[03:55]  * igc lunch
[04:23] <poolie> spiv, i'm reading your patch
[05:00] <beuno> poolie, lifeless, are you guys coming to DebConf after all?
[05:09] <poolie> beuno: i am not, i think robert may be
[05:11] <beuno> poolie, ah, ok. Because I just saw you guys didn't send a talk for bzr
[05:11] <mwhudson> man, using bzr on launchpad on an old-ish os x/ppc laptop hurts a bit
[05:42]  * igc pick up kids
[06:48] <lifeless> beuno: poolie: I'm not as far as I know; we had discussed my going to talk but that was all
[06:49] <beuno> lifeless, well, you can still organize one or two BoFs
[06:50] <beuno> are you registered?
[06:51] <lifeless> no
[06:53] <beuno> au, I suppose you don't need to get sponsored anyway
[06:54] <beuno> well, if you do decide to come, let me know and I'll do as much as I can to help out
[06:55] <lifeless> unless canonical actively wants me to go, I doubt I will at this point
[06:57] <beuno> well, poolie, ball's in your court now  :)
[07:00] <keithy> any loggerhead users?
[07:00] <mwhudson_> i am a loggerhead developer, for my sins
[07:01] <keithy> can I serve non-public branches?
[07:01] <mwhudson_> i think i need more context
[07:01] <mwhudson_> before i can answer that question
[07:02] <keithy> my first problem is noone can see whats in my repo
[07:03] <keithy> secondly I have two private clients
[07:03] <mwhudson_> i don't understand the first problem at all
[07:03] <mwhudson_> 'see'?
[07:04] <mwhudson_> for the second, i'd run loggerhead behind apache and do authorization type stuff in apache
[07:04] <keithy> so they need to see what in my repo, but not what is in eachothers reps
[07:05] <keithy> iam thinking tubogers is too much hassle
[07:05] <mwhudson_> i love my isp!
[07:06] <mwhudson_> keithy: it's getting late here, so if you mail the bazaar list i can try to help there
[07:06] <mwhudson_> or you can try to get life out of someone else here :)
[07:06] <beuno> keithy, I'll give it a try
[07:07] <beuno> you want to setup loggerhead, which gives access to different branches depending on the user?
[07:09] <keithy> beuno: yes thats about it
[07:09] <keithy> last time I tried I gave up at turbogears
[07:10] <beuno> keithy, I can't think of a straight forward way of doing that, unless you run multiple loggerhead instances in different ports, and do some magic from apache
[07:10] <keithy> man
[07:11] <keithy> why are bzr branches so invisible
[07:11] <beuno> keithy, invisible in what sense?
[07:11] <keithy> well on mac os x all you see is an empty directory
[07:12] <beuno> keithy, that's because it's a hidden directory
[07:12] <beuno> .bzr
[07:12] <keithy> right...
[07:12] <beuno> ls -a should show it to you
[07:12] <keithy> so how is anyone able to know what branches you have to push to?
[07:12] <beuno> keithy, either where you branched from, or you specify it once, and bzr remembers it
[07:18] <keithy> arg I dont want to have to install XCode on my server
[07:18] <lifeless> keithy: I would run three loggerhead instances:
[07:18] <keithy> so how do I install turbogears?
[07:19] <lifeless> keithy: 1) with your branches that are public, 2) with client A's branches, 3) with client B's branches
[07:21] <keithy> why cant I install turbogears without having to put 2Gb worth of XCode on my server
[07:23] <TheSheep> is there a simple way to find all revisions that change a particular file from python, or do I have to look through all revisions and filter them?
[07:33] <beuno> that's it for me
[07:33] <beuno> g'night all
[07:38] <keithy> arg even fink wants xcode
[07:40] <poolie> igc, thanks for the reviews!
[07:45] <igc> poolie: np
[08:03] <gour> igc: see https://bugs.launchpad.net/bzr-fastimport/+bug/232177
[08:03] <liw> lifeless, so... the bzr process is still running on add universe, RSS is 6.7 GiB, and strace tells me it does brk occasionally, but nothing much else
[08:03] <poolie> liw, hi
[08:04] <liw> poolie, greetings and salutations!
[08:05] <igc> gour: thanks for putting that issue in and collecting your progress
[08:05]  * igc dinner
[08:05] <poolie> liw, if you're wanting to see where it's spending its time try pressing C-\ but be aware there is some chance this may make it crash
[08:05] <liw> poolie, I'm going to wait for lifeless to come and do that :)
[08:05] <poolie> :)
[08:06] <liw> although I may have to find \ for him on this keyboard
[08:24] <vila> mneptok: ping, can you have a look at bug #229076 and enlighten us ?
[08:38] <mneptok> vila: enlighten you in what regard?
[08:39] <vila> what is the setup of www.gnome.org, what is the server that close the connection when the header is 'User-agent' instead of 'User-Agent' ?
[08:42] <mneptok> AFAIK, "User-agent" is non-RFC for HTTP1.1
[08:42] <mneptok> http://www.faqs.org/rfcs/rfc1945.html
[08:42] <mneptok> http://www.faqs.org/rfcs/rfc2068.html
[08:43] <mneptok> i agree it's a bit strict, but is is understandable, IMO
[08:43] <vila> https://bugs.edge.launchpad.net/bzr/+bug/229076/comments/13
[08:43] <vila> it's a bit clear that header names are case-insensitive :)
[08:44] <vila> taken straight from rfc2616
[08:44] <vila> anyway, the bug has been fixed, what I'd like to know is what is the server that triggered it since that the first time we encounter such strictness
[08:44] <vila> well "strictness"
[08:46] <liw> the reply from www.gnome.org, port 80, includes: Server: Apache/2.2.3 (Red Hat)
[08:47] <liw> lifeless, update: bzr is now continuing past the place it was stuck, I didn't do anything except kill the interactive python process I had open (the one on which you counted files/tips/whatever it was)
[08:47] <vila> liw: yes, but apache2 itself has always been perfectly happy with that
[08:47] <liw> vila, indeed
[08:48] <liw> vila, could be a (transparent) proxy somewhere, perhaps
[08:50] <vila> liw: hence the question :) My 8-ball doesn't reveal that transparent one :) Which by the way could at least politely answer  with 400 or any 5xx :)
[08:50] <vila> that's why I'd like to contact it to report the problem even if we fixed it on our side
[08:51] <liw> yeah
[08:52] <mneptok> vila: it looks like the case sensitivity is a deliberate change to the GNOME infrastructure
[08:52] <mneptok> vila: it was put in place after DDoS attacks
[08:52] <mneptok> it's not an optimal fix, but it works.
[08:53] <lifeless> mneptok: rfc2616 - any captilisation is valid for field names
[08:54] <lifeless> liw: interesting
[08:54] <mneptok> lifeless: OK I'LL READ THAT AFTER I HAVE SOME COFFEE. THANKS FOR POINTING ME AT IT.
[08:54] <mneptok> >:)
[08:54] <liw> lifeless, now doing pool/universe/p/portsentry
[08:54] <lifeless> Ok i SeE iF i CaN hElP yOu
[08:54] <mneptok> :)
[08:54] <liw> lifeless, I guess bzr was stuck into swapping mode for a while, but eventually got past that
[08:55] <liw> lifeless, typical bzr processes are right now in the 20-30 megabyte range (for RSS)
[08:55]  * vila find the coffee idea too tempting to resist
[08:55] <lifeless> liw: how long is it taking for each package?
[08:55] <lifeless> liw: and what is the repo size up to ?
[08:55] <liw> lifeless, a couple of seconds for most small packaes
[08:55] <lifeless> poolie: got a few?
[08:56] <lifeless> liw: (just du -sH .bzr/repository/packs)
[08:56] <liw> lifeless, 17 GiB total in the directory, with 16 GiB in one big pack file
[08:57] <lifeless> liw: I think it was paused doing a full pack :P
[08:57] <jml> that's absolutely no history, right?
[08:57] <lifeless> yeah
[08:57] <lifeless> can you time doing a branch from one of those packages to a standalone branch ?
[08:57] <lifeless> liw: ^
[08:59] <liw> lifeless, sure
[08:59] <liw> aalib: real    0m2.370s
[08:59] <liw> user    0m1.332s
[08:59] <liw> sys     0m0.128s
[09:00] <liw> (now I'm busy for a while)
[09:02] <lifeless> liw: awesome
[09:02] <vila> lifeless: the liw experiment is for all universe packages in hardy ? Sources ?
[09:02] <lifeless> vila: unpacked sources, yes
[09:04] <vila> awesome, 17GiB is cheap for that IMHO, is that an hint that one of my dream will come true ? Having all sources available in sync with my install ?
[09:04] <liw> vila, it's still running
[09:05] <vila> liw: ok, you will report here isn't it ?
[09:05] <liw> vila, yup
[09:05] <vila> great
[09:07] <vila> lifeless: bzr-email is failing tests, I have a patch, should I send it to you or push to lp ?
[09:10] <lifeless> send to the list  with Merge/bzr-email
[09:12] <james_w> bzr-email/MERGE isn't it?
[09:20] <lifeless> sounds plausible
[09:24] <vila> james_w, lifeless: grr, so not only did I forget the /bzr-email and re-send it, but now I read that ;-/
[09:25] <lifeless> :
[09:26] <jml> what's the difference between Branch.pull & Branch.clone? I'm guessing that the latter preserves format and the former doesn't?
[09:26] <jml> also, clone needs a bzrdir it seems -- is this right?
[09:27] <lifeless> pull mirrores between existing branches
[09:27] <lifeless> clone makes a new branch
[09:27] <lifeless> vila: what is should_send returning ?!1
[09:28] <jml> lifeless: I guess I meant in the case where a branch has just been created.
[09:28] <vila> the email itself
[09:28] <jml> eg.g bzr init; bzr pull <url>
[09:28] <lifeless> vila: then i don't think the fix is appropriate; for starts the method is wrongly named
[09:29] <vila> lifeless: hey man, I fix the tests as they are because I'm tired of adding --no-plugins to selftest :)
[09:30] <lifeless> vila: well, this is what review is for no? To identify slippery-slope events  :)
[09:30] <vila> LOL
[09:31] <vila> lifeless: ok, you won. My daughters also found my weak point when I'm angry about them: make me laugh.
[09:31] <lifeless> :)
[09:32] <lifeless> seriously though, it sounds like something has creeped here, and that the method has come to have a different purpose - thats fine, but it should be trivial to give it a better name and then the test and code won't be confusing
[09:33] <vila>     def should_send(self):
[09:33] <vila>         return self.to() and self.from_address()
[09:35] <lifeless> so it can return None or to()
[09:35] <vila> +        return bool(self.to() and self.from_address())
[09:35] <lifeless> 'return self.to() is not None and self.from_address() is not None' would be wrong, because '' is wrong for an email address
[09:35] <lifeless> yes, thats good
[09:35] <lifeless> that would avoid changing the tests
[09:36] <vila> and about the name ? should_send seems to capture "check that we have enough info before sending"
[09:36] <lifeless> I think the name is ok given the details we've just looke at
[09:36] <lifeless> if it had been returning the email body as I thought you meant it would have been an issue
[09:37] <jml> lifeless: Is there a way to pull stacked branches such that I only pull the stacked bit, and not the whole thing.
[09:37] <lifeless> jml: I think you want init --stacked=url && pull in command line terms
[09:37] <lifeless> jml: in library terms, doing branch.bzrdir.clone(target) should DTRT I think
[09:38] <jml> lifeless: and pull as well? or just clone the bzrdir?
[09:38] <lifeless> just clone
[09:39] <lifeless> subsequent pulls will preserve the stacking bit and add data not accessible as one would expect
[10:02] <gour> if one uses 'restricted' subscription policy on launchpad, what is restricted to other lp members?
[10:03] <gour> /to/for
[10:07] <poolie> gour: is this a restricted team?
[10:08] <lifeless> poolie: ping
[10:08] <poolie> pong
[10:08] <gour> poolie: i'm reading lp feature high. document, team managament section --> subscription policies
[10:09] <lifeless> gour: restricted means that you hasve to invite people
[10:09] <gour> poolie: and i'm interested if i create a project, how it can be managed...in the beginning we want a smaller number of devs to discuss and commit
[10:10] <gour> lifeless: that's clear. but what will be seen by non-invited people? code, bugs, blueprints?...
[10:10] <lifeless> gour: it des not affect visibility of the team, just how to get into it
[10:11] <gour> lifeless: hmm, so everything is visible except commit rights?
[10:12] <lifeless> gour: everything is visible, full stop.
[10:13] <gour> lifeless: everyone can commit his stuff in main trunk? strange...
[10:13] <lifeless> gour: no
[10:14] <lifeless> gour: *membership* and *visibility* are differewnt
[10:14] <lifeless> gour: membership grants commit rights
[10:14] <lifeless> gour: everything is visible
[10:14] <gour> lifeless: ahh, ok. that makes sense
[10:17] <keithy> I am trying to setup loggerhead
[10:17] <keithy> its complainging about no module sqllite
[10:17] <keithy> no mention of anything in the eadme's etc
[10:17] <keithy> readmes*
[10:17] <keithy> It hought squeak was bad at dependencies
[10:18] <keithy> I am beginning to feel there is some python initiation ritual I havent been through
[10:18] <keithy> or are you guys just used to things not working?
[10:21] <lifeless> turbogears is rather painful; I believe the loggerhead devs such as mwhudson would like to use a different toolchain to ease the pain
[10:21] <keithy> seaside?
[10:21] <lifeless> in this case I can help; there are sql alchemy optional modules or something under the hood there
[10:22] <keithy> so I need sql lite?
[10:22] <keithy> no mention of this in the docs
[10:24] <keithy> so not what do I do?
[10:24] <keithy> so now what do I do?
[10:25] <bob2> install pysqlite2
[10:25] <keithy> how?
[10:26] <bob2> how do you normally install libraries on your OS?
[10:26] <keithy> download dmg and double click on an installer!
[10:26] <keithy> how else
[10:26] <keithy> so far I have needed c compilers
[10:26] <keithy> and all sorts
[10:27] <bob2> fink, darwinports?  I don't use os x, sorru.
[10:27] <keithy> and they require xcode and xcode is 1G install
[10:30] <lifeless> keithy: by a different toolchain I mean cleaner and more self containined python libraries
[10:31] <lifeless> keithy: I suggest that you file a bug on loggerhead; I too have had trouble installing it
[10:31] <bob2> is python2.5's included 'sqlite3' module the same as 'sqlite'?
[10:31] <keithy> like seaside! ;p;
[10:31] <keithy> lol
[10:31] <bob2> it looks pretty dbapi2-y
[10:31] <TheSheep> bob2: it's sqlite
[10:31] <keithy> ah so it is loaded!
[10:32] <keithy> I winder where it si
[10:32] <keithy> I wonder where it is
[10:37] <siretart> would someone please to upload bzr-svn 0.4.10 to the bzr ppa?
[10:38] <liw> lifeless, 39619 seconds total run time (real time), 21 G total pack directory size, 16 G for the biggest pack file, then 1.7, 1.6, 1.2, 0.39, and then pretty smal ones
[10:38] <keithy> so do I need to install sqllite3 separately?
[10:41] <keithy> so fink doesnt work
[10:43] <lifeless> keithy: I'm sorry I can't be more help right now, I'm in a week long sprint of meetings
[10:43] <keithy> np
[10:43] <lifeless> keithy: if you can put a bug/question against loggerhead in launchpad I think its likely you can attract mwhudon's attention in his workday which is GMT+12 or so
[10:44] <keithy> the dependency on sqllite is already in the bugs list
[10:47] <lifeless> well I am talking about docs on how to get it going largely
[10:47] <lifeless> -> going for a while
[10:47] <keithy> k cya
[10:47] <jml> lifeless: is there a way to use the test machinery to create a branch with a specific branch format?
[10:50] <lifeless> format=
[10:50] <jml> lifeless: it's unclear whether that's a bzrdir format, a repo format or a branch format.
[10:51] <jml> lifeless: I'm guessing there's something about the interrelation between formats that I don't get.
[10:53] <keithy> sqlite3 is included in pythin, why does loggerhead want sqlite
[10:55] <lifeless> jml: format='dirstate'
[10:55] <lifeless> bah, I have been sucked back into IRC. let me outta here!
[10:58] <jml> lifeless: feel free to talk to me IRL.
[11:03] <liw> lifeless, http://files.liw.fi/temp/output.log -- I forgot to capture theoutput of the universe run, but that's the one for the main run
[11:13] <keithy> after all that! loggerhead renders my hierarchical branches structure as flat!
[11:19] <keithy> I am dissappointed
[11:21] <awilkins> Do you just add stuff to the top of NEWS when pathcing?
[11:22] <awilkins> And does a small extra option for a command count as a feature or an improvement :-)
[11:41] <visik7> hi
[11:41] <visik7> "This transport does not update the working tree"  means that there is another transport that support it ?
[11:42] <bob2> only file://
[11:42] <bob2> or ssh if you have the update-after-push plugin installed (which just does 'ssh remotehost bzr co /path'
[11:46] <jml> lifeless: ping
[12:00] <matkor> vila:I have noticed yours recent commit to bzr-gtk. Could you please merge https://code.launchpad.net/~matkor/bzr-gtk/trunk-matkor ?
[12:01] <matkor> One-line chages but close two bugs (I think). TIA, regards
[12:04] <vila> matkor: better ping<EMAIL_ADDRESS>it looks like I didn't really respect the process by pushing that way
[12:05] <gour> if someone wants to migrate repos from darcs, no matter whether darcs-1 or darcs-2 format, and no matter how old are they, tailor is the only player which does the job atm - pull latest tailor and latest darcs. both darcs-to-git and darcs2git fails with either darcs-2 repo format or older date-format in darcs
[12:05] <vila> matkor: wow, looks like your patch doesn't even appear on http://bundlebuggy.vernstok.nl/bzr-gtk/
[12:06] <vila> matkor: what you should do is send it to<EMAIL_ADDRESS>with [MERGE] in the subject or nobody will be informed of its existence, I'm not a core bzr-gtk dev, just an occasional contributor
[12:07] <gour> ...or new tailor-0.9.33
[12:07] <matkor> vila: should I subscribe or can I just send e-mail out of ist ?
[12:09] <vila> matkor: I don't know for sure, look at https://lists.canonical.com/mailman/listinfo/bzr-gtk
[12:11] <matkor> ok tnx
[12:19] <gour> igc: i updated 'darcs support' bug with latest info...
[12:29] <matkor> Is it OK to send bundle intendent to merge having  target_branch: file:///home/users/matkor/src/bzr-gtk/trunk/ ? Which is checkout of http://bazaar.launchpad.net/%7Ebzr-gtk/bzr-gtk/trunk/ ?
[12:35] <vila> matkor: taget_branch yes, that's how bzr calculated it, bonus points if public_branch is set though, look at bzr help send
[12:42] <matkor> vila: I got confused with:  bzr send ./ http://bazaar.launchpad.net/%7Ebzr-gtk/bzr-gtk/trunk/ -r -3..    giving me: bzr: ERROR: No mail-to address specified.
[12:43] <vila> matkor: add --mail-to<EMAIL_ADDRESS>[12:44] <vila> matkor: or use -o my.patch
[12:45] <vila> matkor: but your public_branch is wrong, you should use *your* branch here, it's where the bundle can be merged from
[12:46] <vila> errr, wait
[12:47] <visik7> bob2: any possiblity to get it on bzr:// transport  ?
[12:48] <vila> bzr send <where you want your patch to be applied> <where your patch have actually been applied>
[12:48] <vila> matkor: ^
[12:49] <bob2> visik7: not supported as yet, as far as I know
[12:50] <vila> visik7: the idea is that you have working tree where you can.. work. So you need at least a shell access there, and then you can just do bzr co or bzr update
[12:52] <visik7> yes I'm in the process of misusing bzr as a deploy tool :)
[12:53] <visik7> 'couse I work with some pigs&dogs that puts their hands on the server so I need to track them
[12:53] <bob2> ghetto workarounds include push-after-update and bzr co from cron
[12:55] <TheSheep> ok, I have finished writing a storage plugin for my wiki that uses bzr repository to keep the pages and history. Would anyone want to take a look at it and maybe suggest doing some things differently?
[12:55] <visik7> TheSheep: based on some web framework ?
[12:56] <TheSheep> visik7: no, just wsgi
[12:56] <TheSheep> the code for the plugin is here (sorry that it's Mercurial) http://sheep.art.pl/devel/dandelion/file/tip/dandelion/plugin/bzrstore.py
[12:56] <visik7> :)
[12:56] <visik7> ahahah
[12:56] <visik7> funny
[12:58] <TheSheep> I had trouble for example with getting the list of all files that were changed in a revision
[12:58] <visik7> TheSheep: from the bzrlib or from the command line tool ?
[12:59] <TheSheep> visik7: from bzrlib
[12:59] <visik7> maybe whatching in the command line tool you got how it does
[12:59] <visik7> no ?
[12:59] <TheSheep> in the end I did [entry.name for path, entry in entries if
[13:00] <TheSheep> entry.revision == rev_id]
[13:00] <TheSheep> :)
[13:00] <luks> repository.get_revision_delta or something like that
[13:00] <matkor> bzr: ERROR: Please specify smtp_server.  No server at default localhost - how can I do it ?
[13:00] <matkor> bzr send does not mention any option for that ...
[13:00] <luks> TheSheep: working_tree.commit(message="imported existing pages", author="wiki")
[13:00] <luks> er, maybe you meant committer there?
[13:00] <luks> and unicode(revision.message, "utf-8")
[13:01] <luks> the decoding there is wrong, it's already unicode
[13:01] <TheSheep> luks: ah, I thought it stores bytes, cool
[13:01] <luks> no, most things in bzrlib are unicode
[13:01] <bob2> matkor: -o foo.patch, then send it using your mail client
[13:01] <TheSheep> luks: isn't delta just another tree?
[13:02] <luks> TheSheep: delta is the list of files that changed in a revision
[13:02] <TheSheep> great
[13:03] <TheSheep> I'm sure some parts of this code can cause nightmares for anyone familiar with bzrlib :)
[13:03] <luks> not bzrlib relased, but you have some locking problems in try/finally there
[13:04] <luks> it should be lock(); try: ... finally: unlock()
[13:04] <luks> you have try: lock(); ... finally: unlock(), which might call unlock even if lock failed
[13:04] <TheSheep> ah, right, so that it doesn't try to unlock when the lock fails
[13:04] <TheSheep> thanks
[13:04] <matkor> bob2: Thats last option, seems  $HOME/.bazaar is place where I should specify smtp server ...
[13:05] <bob2> matkor: yes, ~/.bazaar/bazaar.conf - it presumably defaults to localhost
[13:07] <matkor> ok .. it went ... I doubt it gets through to<EMAIL_ADDRESS>with strange from adress ...
[13:08] <luks> usually you want 'bzr send' to just launch an external mail client
[13:08] <matkor> How often http://bundlebuggy.vernstok.nl/bzr-gtk/  is updated ?
[13:09] <vila> matkor: you need to set mail_client in bazaar.conf for that, smtp_server is adifferent beast
[13:10] <vila> matkor: presumably http://bundlebuggy.vernstok.nl/bzr-gtk/ get the mails from bzr-gtk list so if you don't see your mail here neither does it
[13:11] <matkor> vila: I do not see even my subscribe confirmation mail .. but I am postgreyed so might have delays ..
[13:12] <vila> matkor: just be patient then, may be an admin need to validate your subscription,
[13:27] <gour> i'm new with bzr, but somehow feel strange that bzr status reports nothing when there is no change. what do you think about something like darcs' "No changes!" ?
[13:30] <Odd_Bloke> gour: I dunno, I think you'll find you just adjust to the lack of output.
[13:31] <gour> Odd_Bloke: i consider that providing some output is nice HIG
[13:31] <Odd_Bloke> It does provide output, a newline followed by a prompt.
[13:32] <gour> well, i'm serious
[13:32] <Odd_Bloke> Me too, I don't want our UI cluttered up for no reason.
[13:33] <pickscrape> Just create a file and never add it. Then you'll always have output :)
[13:34] <Odd_Bloke> Regardless, if you think something about bzr should be different, submitting a patch to the ML is a much better way of getting it discussed than IRC (especially as most of the core devs are probably in bed ATM). :)
[13:34] <gour> pickscrape: i'm not interested for *any* output, but info that nothing changed
[13:35] <gour> will do
[13:42] <nekohayo> hmm. let's say I cherry pick r3..6 from some branch, and later I just "bzr merge" from it, what would happen?
[13:43] <nekohayo> and if that branch has a change I don't want to incorporate ever, that means I need to always cherry-pick?
[13:44] <luks> or you can merge it and revert the particular change
[13:44] <nekohayo> oh, you can do that? how can you revert a past committed change?
[13:44] <luks> if that change in a single commit?
[13:44] <luks> is
[13:45] <nekohayo> yeah, but for example 10 revisions earlier
[13:45] <luks> yeah, so merge, commit the merge, and then `bzr merge -r X..before:X .` and commit the reverted change
[13:46] <nekohayo> bzr merge -r150..22 ?
[13:47] <nekohayo> oh -r 150..149
[13:47] <nekohayo> that uncommits revision 150?
[13:47] <luks> -r 150..149
[13:47] <luks> or -r 150..before:150
[13:48] <luks> that will revert the change from revision 150
[13:48] <nekohayo> ok, thanks :)
[14:04] <lelit> hi all
[14:05] <lelit> I'm playing with bzr and tailor lately: it was able to migrate the whole darcs history to bzr without a glitch! :-)
[14:05] <jelmer> hi lelit
[14:05] <lelit> now I'm trying the other way around, and notice that bzr is *very* slow in collecting the "missing" changesets
[14:05] <lelit> hi jelmer
[14:05] <lelit> how's going?
[14:06] <jelmer> pretty well, thanks :-)
[14:06] <jelmer> lelit: Collecting missing changesets in what regard, "bzr missing" ?
[14:07] <lelit> I have a local bzr.dev clone, and when I do (tailor backend does, that is) "cd /tmp/p; bzr init; bzr missing SomeSourceRepo"
[14:09] <lelit> see http://progetti.arstecnica.it/tailor/browser/vcpx/repository/bzr.py#L168
[14:10] <lelit> that missing_revisions() takes something more than 1h here, with 100% cpu
[14:11] <jelmer> there was talk about reimplementing it using a somewhat smarter algorithm earlier
[14:11] <jelmer> jam, ping
[14:11] <lelit> after than, in another couple of hours the migration completes
[14:11] <lelit> jelmer: ah, ok, it's a known problem then, not something wrong with that code
[14:12] <jelmer> lelit: I think bzr itself only uses that particular function for the "bzr missing" command, not for anything else
[14:14] <lelit> do you think there's a better way of knowing the list of csets that a "bzr pull" would fetch?
[14:14] <lifeless> bzr.dev makes missing much faster
[14:15] <lelit> lifeless: ?
[14:17] <lifeless> john landed a patch to improve missing yesterday
[14:18]  * lelit goes to update
[14:22]  * lelit restarts the test
[14:22] <lelit> thank you
[14:26] <gour> lelit: good luck ;)
[14:43] <cjean_> Hi, I'm looking for a complete tutorial explaining how to manage a decentralized workflow with gatekeeper
[14:43] <jam> jelmer: pong
[14:43] <cjean_> there is no much details on the current documentation
[14:44] <jam> jelmer, lelit: I did land a patch yesterday that made missing better, and another that made the function missing used even better
[14:44] <jelmer> jam: sorry, was wondering about your missing improvements but lifeless already replied
[14:46] <lelit> jam: thankyou, I'll write here the result. It's still using 100% cpu, since 25 mins ago now...
[14:47] <jam> lelit: using the latest bzr.dev?
[14:47] <jam> I would really like to understand your circumstance
[14:47] <jam> here, things run on bzr.dev in <10s
[14:48] <lelit> tailor is doing (look at the trac URL for the function) a missing() from an empty new repo, pulling from a local bzr.dev clone
[14:49] <lelit> I just want the *list* of patches, "darcs pull --dry-run" in darcs parlance
[14:50] <lelit> I *must* be doing it wrongly...
[14:50] <lelit> jam, and yes, updated and reinstalled current bzr.dev
[14:50] <lifeless> lelit: is it possible that the repository is not locked ?
[14:51] <jam> lelit: are you writing your own plugin for it?
[14:51] <jam> lifeless: 'find_unmerged' would be locking the branches
[14:51] <jam> I'm not sure what function he is using
[14:51] <lelit> jam, see http://progetti.arstecnica.it/tailor/browser/vcpx/repository/bzr.py#L168
[14:51] <lelit> it's just my tailor business :)
[14:52] <jam> a Branch.missing_revisions
[14:52] <jam> I don't know if that is ever used
[14:52] <jam> it certainly doesn't scale well
[14:52] <jam> andprobably doesn't take a lock
[14:52] <lelit> what you'd suggest?
[14:53] <jam> lelit: ATM, bzrlib.missing.find_unmerged(this_branch, other_branch, 'local'/'remote'/'all')
[14:53] <lelit> ok, thanks alot, I'll try that way
[14:54] <jam> The only place that uses Branch.missing_revisions() is one function in the test suite
[14:55] <jam> lifeless: what do you think, should I just nuke the function, or should I move the 'find_unmerged' functionality over into it?
[14:55] <jam> I think it *used* to be used as part of pull/push/etc to figure out if branches had diverged
[14:55] <jam> Now, I think we use get_graph.().heads()
[14:56] <lelit> later, ciao
[14:56] <jelmer> jam: bzr-svn uses it
[14:56] <lelit> so, that's *three* places :)
[14:56] <jam> jelmer: well, it's a Bad(tm) function
[14:57] <fullermd> Our *three* users are...   wait, I'll come in again.
[14:57] <jam> we could improve it
[14:57] <jam> just not sure if it is worthwhile
[14:57] <jam> jelmer: what do you use it for?
[14:58] <jelmer> jam: actually, never mind me
[14:58] <jelmer> jam: I added a custom implementation for bzr-svn later on
[14:58] <Lo-lan-do> Hi all
[14:59] <jelmer> jam: it's being used from Branch.pull()
[14:59] <jam> jelmer: you mean SVNBranch.pull(), right?
[14:59] <jelmer> jam: yep
[15:00] <Lo-lan-do> jelmer: I am under the impression that bzr-svn is slower and slower as time passes, and possibly that it's doind more and more connections to the SVN repo
[15:00] <jelmer> Lo-lan-do, what version are you using?
[15:00] <Lo-lan-do> Is that known and/or addressed?
[15:00] <jam> jelmer: well, there is example code in Branch.update_revisions() which shows you how to do it with a Graph instead of missing_revisions
[15:00] <jam> though we could arguably do something similar in missing_revisions
[15:01] <Lo-lan-do> 0.4.10 + bzr 1.5, I guess
[15:01] <jelmer> Lo-lan-do: in that case, it's not a known issue
[15:01] <jelmer> jam: thanks, I'll see if I can steal that
[15:01] <Lo-lan-do> I just did a bzr commit on a svn-bound branch for gforge, and it took 4 minutes and 40 seconds, and 276 sockets opened to the repo
[15:02] <gumpa> Howdy, I've hosed my gui bazaar stuff.  Started after creating ~/.bazaar/plugins, and branching lp:bzr-gtk  and qbzr there
[15:02] <jam> jelmer: any chance you could be around for a skype call tomorrow around 1900 UTC time ?
[15:02] <jam> we are thinking about talking about bzr-svn in my next "This Week in Bazaar" post
[15:02] <jam> and it would be nice to have your input
[15:03] <jelmer> jam: yep, sounds good
[15:03] <jam> jelmer: great
[15:03] <jelmer> Lo-lan-do, ouch, that's wrong - please file a bug
[15:03] <gumpa> now olive crashes
[15:04] <jam> gumpa: did you branch "lp:bzr-gtk ~/.bazaar/plugins/gtk" ?
[15:04] <jam> just to make sure it was named correctly
[15:04] <gumpa> I've removed and installed bzr-gtk, removed the plugins dir, still ng
[15:06] <jam> lifeless: how is UDS going, btw
[15:08] <gumpa> I had changed bzr-gtk to bzr_gtk, just changed bzr_gtk to ~/.bazaar/plugins/gtk still crashes
[15:09] <jelmer> gumpa: what's the error you're getting?
[15:09] <jelmer> jam/lifeless: Somewhat related to Branch.missing_revisions(), any chance you can reply to https://lists.ubuntu.com/archives/bazaar/2008q2/041834.html ?
[15:10] <gumpa> just did apt-get remove bzr-gtk --purge, now 'bzr qdiff' says 'Not running bzrlib.plugins.gtk, things may break'
[15:11] <gumpa> and lots of 'Two plugins defined the same command:'
[15:12] <jelmer> gumpa, qdiff is not part of bzr-gtk
[15:12] <jelmer> bzr gdiff is
[15:12] <gumpa> typo s/gdiff/qdiff
[15:13] <gumpa> same messages with gstatus
[15:15] <gumpa> Previously this command was registered from <module 'bzrlib.plugins.bzr_gtk' from '/home/ktenney/.bazaar/plugins/bzr_gtk/__init__.pyc'>
[15:15] <gumpa> after Two plugins defined the same command: ...
[15:16] <jelmer> gumpa: remove the bzr_gtk directory in ~/.bazaar/plugins
[15:17] <gumpa> Fixed. You make it look so easy.  thanks
[15:18] <lifeless> jam: good
[15:18] <gumpa> can I apt-get install bzr-gtk to get Olive now?
[15:23] <jelmer> gumpa, Olive is part of bzr-gtk
[15:24] <gumpa> how do I start it?
[15:24] <jelmer> gumpa, So you should already have it if you installed bzr-gtk into ~/.bazaar/plugins/gtk
[15:24] <jelmer> start the olive-gtk binary from that directory
[15:24] <xif> Hi. I have a file that I need to use in two code tree (two separate projects). How would I share that file among the two projects, if they're both managed with bzr?
[15:25] <gumpa> jelmer great, thanks, see you
[15:31] <matkor> xif: Those separate project are not self-branches  ?
[15:32] <xif> matkor: nope, they're completely separate projects.
[15:33] <xif> to further explain: these projects are web applications.
[15:33] <xif> the file they're sharing is a Javascript library.
[15:34] <LeoNerd> Hrm... Any reason why bzr doesn't ignore directories called "CVS" by default?
[15:36] <NfNitLoop> LeoNerd: Heh, I've wondered that myself.
[15:36] <fullermd> LeoNerd: Because the speed of add varies inversely (and significantly) with the number of ignore rules.
[15:36] <LeoNerd> fullermd: Ahh... OK.
[15:36] <NfNitLoop> bzr init; bzr add . ; bzr commit;   What!?  CVS/?
[15:36] <fullermd> So the default set is pared down as much as possible.
[15:36] <LeoNerd> Besides... bzr ignore CVS    isn't exactly difficult
[15:36] <LeoNerd> It's just something I hadn't thought about and just presumed would work
[15:37] <jam> LeoNerd: at one point we ignored lots of things by default
[15:37] <jam> but it turned out to slow things down
[15:37] <jam> when you had to check every file against 100+ possible ignores
[15:37] <LeoNerd> Right
[15:37] <jam> so we turned it down a bit
[15:37] <NfNitLoop> Wouldn't the better solution be to fix the performance of ignore?  ;)
[15:38] <jam> NfNitLoop: It isn't ignore
[15:38] <jam> it is stuff like 'add' having to compare against a large list
[15:38] <jam> we already use tricks to make it faster
[15:38] <jam> but if you are adding 20,000 files
[15:38] <jam> the overhead of each one makes a difference
[15:38] <NfNitLoop> aaah.  Yeah.
[15:38] <xif> OK, nobody has an answer?
[15:39] <xif> doesn't BZR have something like svn:externals?
[15:40] <NfNitLoop> Not that I know of, but I'm not a bzr developer. :)
[15:40] <NfNitLoop> IIRC, you can check out a project within the directory of another.
[15:40] <xif> OK, that might be a solution...
[15:40] <NfNitLoop> but there's nothing to tie revision X of baseProject to revision Y of innerProject.
[15:45] <xif> hm, this kind of sucks :/
[15:49] <lifeless> jam: do you remember if we fixed the problem where commit did not notify the dirstate of the sha1 of files read in during commit ?
[15:49] <lifeless> jam: sabdfl is still seeing status on large trees as 70-80% slower than hg's.
[15:53] <jam> lifeless: afaik we never fixed that
[15:54] <xif> OK, looks like this has been thought of before: http://bazaar-vcs.org/NestedTreeSupport
[15:55] <beuno> xif, LarstiQ is working on that, but it might take a while to land
[15:55] <xif> a Nested Tree "by reference" is basically svn:externals.
[15:55] <vila> jam: what's that "This Week in Bazaar" post thing ? 8-)
[15:55] <jam> vila: jam-bazaar.blogspot.com
[15:55] <xif> beuno: good to know, that's a useful feature :)
[15:55] <jam> http://jam-bazaar.blogspot.com
[15:55] <jam> vila: I'm just doing a weekly blog post with statik
[15:56] <jam> if you have ideas of something to talk about let me know
[15:56] <jam> it is a "spend 45 minutes every week to get some publicity"
[15:56] <vila> ok, reading it.
[15:56] <jam> so, quick topics, nothing terribly fancy
[15:56] <jam> just that we do a lot of work that doesn't get noticed because we forget to communicate ti
[15:56] <jam> it
[15:57] <vila> ooh, the 'my' plugin I wanted to code for ages exists and is called 'bookmarks' :)
[15:58] <vila> ooooh 'removable' !
[16:00] <htd> hi, i am totally new to bzr - if i merge my changes, can i control if the full history of my changes gets merged or just the most recent revision?
[16:02] <Pilky> jam: might have something for you next week
[16:02] <matkor> htd: you can control what changes are marged
[16:03] <jam> Pilky: what is that?
[16:03] <Pilky> first release of a OS X GUI client for Bazaar
[16:04] <htd> matkor: sounds great, thanks for the info
[16:04] <jam> sounds interesting
[16:05] <Pilky> gonna be pretty basic to begin with (add, init, init-repo, commit, status) but should still be pretty helpful
[16:05] <pickscrape> beuno: what happened to your plugin_management plugin? I just did a pull and upstream has vanished.
[16:13] <gumpa> I am getting a traceback and hang on "Please wait, loading ancestral graph" when I click  the 'Log' button in Olive, current lp:bzr-gtk
[16:13] <jam> Pilky: have you tried QBzr on Mac?
[16:13] <jam> just wondering if your time might be better spent expanding something that already works there
[16:14] <gumpa> pastebin?
[16:14] <Pilky> jam, possibly, I just don't think that there's going to be a huge adoption of a GUI client on the Mac if it's not native
[16:15] <jam> Pilky: perhaps, though there won't be huge adoption if it is underdeveloped, either :)
[16:15] <pickscrape> One of my colleagues spotted BazaarX the other day
[16:15] <pickscrape> Which is apparently a bzr client for cocoa.
[16:15] <jam> jelmer: I responded
[16:16] <Pilky> heh, but an application is only underdeveloped for a certain amount of time ;)
[16:16] <Pilky> pickscrape: that would be the app I'm working on
[16:16] <pickscrape> Ah
[16:16] <jelmer> jam: earlier you mean, or just now?
[16:16] <jam> jelmer: just now
[16:16] <jelmer> jam: Thanks :-)
[16:16] <Pilky> We only started coding it yesterday but we've got pretty far
[16:16] <pickscrape> Yes, it caused a small flurry of excitement amongst the Crayon Monkeys who aren't too keen on the idea of using the command line :)
[16:17] <pickscrape> Unfortunately I have no idea how to compile it, so I can't advise them :(
[16:17] <Pilky> compile BazaarX?
[16:19] <Pilky> at the moment there's not much to compile, just some unit tests for the bit that talks to bzr, but we'll be providing disk images with the app on for each release
[16:19] <pickscrape> Cool. Yeah, I realise it's young. I just get frustrated by the whole apple thing. At least with windows I can easily run it under vistualbox.
[16:20] <pickscrape> virtualbox.
[16:20] <awilkins> I'd rather people diverted all their attention to Olive, frankly, and shamelessly stole as many ideas from TortoiseSVN as possible.
[16:21] <awilkins> Is vistualbox a euphemism for "The OS before Windows 7" ?
[16:21] <awilkins> ;-)
[16:22] <pickscrape> That would be Windows ME II ;)
[16:22] <jam> jelmer: do you use the 'stop_revision' parameter of missing_revisions?
[16:22] <jam> I'm just trying to understand it
[16:22] <jam> I *think* it is a revno
[16:22] <jam> I was going to clean up the function
[16:23] <jelmer> jam: in my implementation it is a revid
[16:23] <pickscrape> Pilky: either way, my colleagues are very much looking forward to your work on that, and it is appreciated.
[16:23] <jam> but now I'm thinking about just deprecating it because it is crufty
[16:23] <jam> jelmer: well I see:
[16:23] <jam> if stop_revision > other_len:
[16:23] <jam> jelmer: so I'm pretty sure it *has* to be a revno
[16:23] <jelmer> jam: It may've changed since I created my implementation though
[16:23] <jam> at least for the base implementation
[16:23] <Pilky> pickscrape: nice to know that others are interested as well :)
[16:23] <jelmer> jam: Mine is called lhs_missing_revisions() these days
[16:23] <jam> jelmer: update_revisions() takes a revision id
[16:23] <jam> I think missing_revisions is just badly broken
[16:24] <jam> and nobody noticed
[16:25] <jelmer> jam: looks like it
[16:27] <jam> jelmer: ok, deprecation and future nuking it is
[16:34] <steelpotato> can somebody help me an error message?
[16:34] <steelpotato> I'm trying to use bzr switch, and it says:
[16:34] <steelpotato> bzr: ERROR: Cannot switch a branch, only a checkout.
[16:35] <Pilky> steelpotato: did you use bzr checkout to get the files?
[16:35] <steelpotato> I guess not :) No, I think I used branch.. so that makes sense, but I still want to switch it
[16:35] <steelpotato> the url I'm switching to is a branch of the url I originally branched from
[16:36] <Pilky> so you're wanting to change the default URL to merge/push/pull?
[16:36] <Lo-lan-do> Then first bind to your initial URL, and switch after that
[16:37] <steelpotato> Pilky: well, yes, but mostly I want to change to the new files, since they contain some changes
[16:37] <radix> steelpotato: then maybe you just want to pull or merge
[16:37] <jam> steelpotato: bzr pull http://new_url ?
[16:37] <jam> or maybe
[16:37] <Pilky> steelpotato: try bzr pull URL
[16:37] <jam> bzr pull --remember --overwrite http://new_url
[16:37] <steelpotato> that would change the files
[16:37] <Pilky> and add --remember to that if you want to set that as the default
[16:37] <steelpotato> but what if I wanted to switch back?
[16:37] <Pilky> to the previous files?
[16:38] <steelpotato> yeah
[16:38] <radix> steelpotato: or... maybe you just want to branch again? :)
[16:38] <steelpotato> this is an experimental change i'd like to review
[16:38] <Pilky> just bzr revert -1
[16:38] <beuno> pickscrape, I moved it: https://code.edge.launchpad.net/~beuno/bzr/automatic_plugins
[16:38] <beuno> it has almost-working-install now  :)
[16:38] <jam> steelpotato: alternatively "bzr merge http://new_url"
[16:38] <radix> steelpotato: ok, so someone made a branch and you want to review the changes it has?
[16:38] <jam> if you just want to review it
[16:38] <steelpotato> Let me explain my background a little bit...  :) I'm used to using git, where I could branch all over the place
[16:38] <steelpotato> and switch between them at wil
[16:38] <steelpotato> I'm trying to duplicate that without needing to create new checkouts
[16:39] <steelpotato> because the folders are flex projects and the IDE doesn't like duplicate projects
[16:39] <radix> Yeah, I suggest merging it and then viewing the diff.
[16:39] <radix> And you can branch as much as you want. branch branch branch.
[16:39] <bob2> steelpotato: create a repository, branch things into it, checkout from it and then switch that checkout amongst the branches
[16:39] <steelpotato> bob2: right, that's what I am trying to do, but since I used bzr branch instead of bzr checkkout originally, switch isn't working
[16:40] <steelpotato> I could just check it out again
[16:40] <Pilky> steelpotato: just wondering why you don't just branch from the repository with the new files?
[16:40] <steelpotato> Pilky: I'm not sure I understand
[16:41] <bob2> steelpotato: right, so 'bzr init-repo ~/somewhere', 'bzr branch . ~/somewhere/trunk', 'bzr bind ~/somewhere/trunk', 'bzr reconfigure --checkout'
[16:41] <steelpotato> Pilky: you mean get a new folder with the branch?
[16:41] <Pilky> yeah
[16:41] <Pilky> I'm assuming the files you want are in some central location
[16:41] <steelpotato> Pilky: they are, but I can't create multiple copies locally
[16:41] <Pilky> why not?
[16:42] <steelpotato> Pilky: because the IDE gets mad at me for having two projects claiming to be the same one
[16:42] <Pilky> odd, which IDE?
[16:42] <steelpotato> Flex Builder
[16:42] <steelpotato> Eclipse
[16:42] <Pilky> ah
[16:42] <steelpotato> I just use it for compiling and linking :)
[16:42] <Pilky> I can see how that would be an issue
[16:43] <radix> steelpotato: IMO merge is the easiest thing you could do right now.
[16:43] <steelpotato> bob2: I totally don't understand those commands, but I could give them a shot... Why would I need to use the bind command to get that to work?
[16:43] <radix> steelpotato: If you merge it, it'll change your working copy but not the branch; you can view the differences and then revert them.
[16:43] <steelpotato> radix: would my local commit history be any different than the branch's?
[16:44] <steelpotato> radix: would it show a new commit or something, or would that match the branch I'm merging from ont he server?
[16:44] <radix> steelpotato: No. merging doesn't affect your branch (i.e., it doesn't add any revisions). You have to commit the merge if you want to save it.
[16:44] <pickscrape> beuno: thanks. And bzr pull --remember Just Worked too :)
[16:44] <steelpotato> bob2: or is it the reconfigure --checkout thing
[16:44] <radix> steelpotato: and if you don't want to save it, you can "bzr revert" and the merge goes away.
[16:44] <beuno> pickscrape, sorry about moving it  :)
[16:44] <bob2> steelpotato: well, the idea is that a checkout doesn't actually include a branch, it just points at one. those commands put the branch elsewhere, then attach the existing branch dir to that other place.  you're right, the reconfigure is redundant.
[16:44] <pickscrape> Not a problem
[16:45] <steelpotato> bob2: alright... i'm going to try to switch my working copy to be a "checkout" instead of a "branch"
[16:46] <bob2> steelpotato: or, like someone else said, you can just bind to the remote branches directly
[16:47] <steelpotato> bob2: ? Is that what they said? :D
[16:48] <steelpotato> well, I don't like the merging idea (it would work, but I want something more flexible)
[16:49] <steelpotato> you mean bzr bind the_new_branch?
[16:49] <steelpotato> that makes it send all commits to the server, right?
[16:49] <bob2> bzr bind sftp://whatever
[16:49] <bob2> yes
[16:49] <steelpotato> would the bind command get me those new files?
[16:49] <steelpotato> then I could unbind, or somethign?
[16:50] <steelpotato> Because I don't want my commits sent to the server automatically
[16:50] <radix> steelpotato: fyi, a "checkout" is a bound branch, and means that commits automatically get sent to whatever branch you "checked out"
[16:50] <steelpotato> ohhh
[16:50] <radix> steelpotato: then you don't want to reconfigure to a checkout.
[16:50] <steelpotato> radix: but I DO want to do the switch
[16:50] <steelpotato> so I could bind, switch, then unbind, right?
[16:50] <steelpotato> I think I'm totally missing the point here
[16:51] <lifeless> indeed
[16:51] <lifeless> switch assumes you have your work stored elsewhere
[16:51] <radix> oh, or you could bind to a branch on your own machine? I guess that's what beuno's suggesting
[16:51] <steelpotato> Maybe I should read more about the design decisions of bzr
[16:51] <lifeless> if you just want a new basis, just pull --oveerwrite
[16:51] <radix> merging sounds like a much simpler way to review changes than all of this stuff :)
[16:51] <steelpotato> lifeless: yeah, that would work like I'm expecting switch do, right?  Would it changed my "stored location"
[16:52] <steelpotato> radix: yeah, but I might want to work on it, then switch back to something else, etc
[16:52] <Pilky> steelpotato: have you read through the user guide? might be worth identifying what workflow best fits your situation and reading the relevant section
[16:52] <steelpotato> radix: I'm looking for something that willl support the workflow I'm used to
[16:52] <steelpotato> Pilky: thanks
[16:53] <bob2> steelpotato: what I would do: create repository, branch everyone else's stuff there, make your 'trunk' or 'reviewed' or whatever branch, co it, then use switch to move between all the others
[16:53] <Pilky> bzr is incredibly flexible to various workflows. I'm using it for solo stuff, distributed stuff that's centralised on launchpad and the friend that is working on the launchpad project is hoping to switch over from subversion while using it similar to subversion
[16:54] <steelpotato> bob2: so, basically what I'm doing now, except I'm bound to the branch I'm working on?
[16:54] <steelpotato> bob2: we have a repo on the server, it has some branches there
[16:55] <steelpotato> bob2: somebody branched locally, then pushed their changes up to a new folder up there
[16:55] <steelpotato> bob2: we're planning on distributing lots of experimental changes there until it is reveiwed, when it will be merged into the trunk
[16:55] <steelpotato> I'm thinking this will work ..
[16:56] <steelpotato> Pilky: yeah, I like it so far...
[16:56] <steelpotato> thanks everybody
[16:56] <steelpotato> I'll fool around with it more
[16:56] <sabdfl> steelpotato: the user guide is still very cool to gain an understanding of all the different workflows that are easy with bzr, because you can then compose a customer wokflow that right for you
[16:59] <Psy|ecimTech> Hi there, someone can guide me a bit on a problem trying to install bzr-eclipse?
[17:00] <beuno> Psy|ecimTech, I can try, and, if not, I'll try and drag the developer in here
[17:00] <Psy|ecimTech> Thanks
[17:00] <Psy|ecimTech> I'm on XP SP3, I have the bazaar executable intalled and the xml plugin on the plugin directory
[17:01] <Psy|ecimTech> I'm now configuring bazaar's plugin on eclipse, but the preference dialog keep telling me that there is no bzr-xmloutput plugin
[17:01] <Psy|ecimTech> on bazaar plugins path I have
[17:02] <Psy|ecimTech> bazaar\plugins & bazaar\plugins\bzr-smloutput
[17:02] <beuno> Psy|ecimTech, could you fire up a console in windows, and run:  bzr plugins
[17:02] <Psy|ecimTech> oh I see
[17:03] <Psy|ecimTech> seems that there is a problem with the folder name
[17:03] <Psy|ecimTech> bazaar recomends rename it to bzr_xmluoutput
[17:03] <Psy|ecimTech> lets see..
[17:04] <Psy|ecimTech> Solved!
[17:05] <Psy|ecimTech> thanks very much
[17:05] <beuno> Psy|ecimTech,  :)
[17:16] <Jc2k> jelmer: i'm looking at bug #232196 and wondered if you could spare 5 to see if i'm hot or cold..
[17:22] <Jc2k> jelmer: i actually just realised i'm coooold :-(.. *goes back to digging*
[17:27] <matkor> Is it posible to mark bug as duplicate of another ?
[17:27] <matkor> https://bugs.launchpad.net/bzr-gtk/+bug/232551
[17:30] <beuno> matkor, sure, on the left hand side, you have "Mark as duplicate"
[17:30] <matkor> ahh
[17:31] <matkor> thanks bueno
[17:32] <beuno> matkor, np
[17:49] <jelmer> Jc2k, hi
[17:59] <Jc2k> jelmer: lo
[18:00] <Jc2k> i thought the branch commit history was weird, but it looks similar to branches that do work
[18:01] <Jc2k> so im no closer to finding out whay these branches are screwy/different to normal
[18:01] <jelmer> it's probably just a corner case bug
[18:01]  * jelmer tries to branch the eog url
[18:14] <grahal> is there something similar to git-send-email in bzr?
[18:14] <grahal> bzr send doesn't seem to be the answer
[18:15] <fullermd> It's the usual one.  What's it lack?
[18:15] <Jc2k> jelmer: changing trains. be back in a bit..
[18:17] <grahal> I was expecting the ability to break commits into several emails
[18:17] <grahal> not a single email with all the merge
[18:17] <grahal> 1/3, 2/3, 3/3 kind of thing
[18:23] <fullermd> grahal: You may want to see the thread at <https://lists.ubuntu.com/archives/bazaar/2008q2/thread.html#41611>
[18:24] <fullermd> The topic seems to come up every few months; that's the last time through it (it generally quickly goes a bit meta)
[18:24] <lifeless> grahal: you could also do send -r -4..-3; send -r -3..-2; send -r -2..-1
[18:25] <grahal> I see, thanks for the info
[18:25] <grahal> will have a look
[18:32] <jelmer> Jc2k, it's svn revnum 3335 that is the culprit
[19:05] <lifeless> tchau
[19:28] <jelmer> Jc2k, ping
[19:31] <Jc2k> jelmer: pong
[19:46] <jelmer> Jc2k, I think I have a fix
[19:49] <Jc2k> jelmer: awesome :D
[19:50] <keithy> I am attempting to setup loggerhead still
[19:50] <keithy> the directions for ProxPass in apache dont setup the static files
[19:53] <lelit> jelmer, lifeless: for whatever reason, bzr.dev took even longer in that .missing()
[20:06] <Jc2k> jelmer: got a diff so i can take it for a spin?
[20:31] <keithy> I am struggling to get the static content served by appache
[20:31] <keithy> for loggerhead
[20:31] <keithy> has anyone got some conf I could look at
[20:32] <sabdfl> keithy: expert is mwhudson_
[20:33] <keithy>
[20:35] <jelmer> Jc2k: yeah, I'll commit to bzr-svn's 0.4 branch in a few minutes
[20:35] <jelmer> I was trying to add a test case to reproduce this
[20:35] <jelmer> but I haven't been able to do so yet
[20:37] <Jc2k> cool
[20:39] <Lo-lan-do> jelmer: Sorry about the duplicate bugs, by the way
[20:39] <keithy> mwhudson_ hello: :
[20:40] <jelmer> Jc2k, pushed
[20:40] <Jc2k> awesome
[20:49] <Jc2k> *patches and kicks off some imports*
[20:52] <Jc2k> jelmer: happily your patch is what i was thinking, but i just couldn't figure out a test case to go with it
[20:52] <jelmer> Jc2k: Yeah, me neither :-(
[20:52] <Jc2k> SVN seems to stop you creating that kind of a state these days?
[20:53] <jelmer> well, I must admit I haven't reproduced the full state, just the bits I thought mattered
[20:53] <Jc2k> well, same here
[20:54] <Jc2k> *shrugs*
[21:09] <NemesisD> hi all, ive found the documentation on using the ssh+bzr:// protocol a little spotty, is there a way you can specify the username and password so that several dirs can be pushed with a shell script
[21:10] <Lo-lan-do> NemesisD: You can do the username with ~/.ssh/config, and use keys to avoid the password problem
[21:13] <NemesisD> hmm
[21:22] <NemesisD> Lo-lan-do, ok im following the guide on bazaar's site but its a bit confusing, i did an ssh keygen
[21:22] <NemesisD> and its telling me to copy the contents to my local authorized_keys file, do i just copy the big huge key or am i copying the DEK-Info part and th Proc-Type part?
[21:25] <Lo-lan-do> Actually, you need to copy it to the remote authorized_keys file.
[21:25] <Lo-lan-do> The ssh-copy-id command does it for you.
[21:27] <NemesisD> hmm,  i just did cp id_bzr.pub authorized_keys on the remote system then i scp'ed the authorized_keys to my local .ssh directory
[21:27] <beuno> NemesisD, and make sure the permissions for that file are set to 600
[21:28] <NemesisD> i entered a passphrase when it asked when i did the keygen, should i not have done that?
[21:29] <beuno> NemesisD, then, you will be asked for a passphrase every time
[21:29] <beuno> if you don't want to use a passphrase, re-generate it without one
[21:30] <Lo-lan-do> Or use ssh-agent, which will cache it in memory.
[21:31] <NemesisD> hmm, im a bit confused, i think i would like to be prompted for a password when i ssh in manually to do stuff but i want my script that uses bzr+ssh:// to not be prompted, but i suppose that doesn't make much sense
[21:37] <NemesisD> i tried resetting the password to blank and its still prompting
[21:45] <NemesisD> crap, ive somehow done the process in reverse, now the remote can ssh into me with no pass but not vice versa
[21:46] <beuno> BB is down, The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
[21:46] <beuno> abentley, ^
[21:48] <NemesisD> fix'd
[21:49] <abentley> beuno: Should be up in a minute.
[21:50] <beuno> abentley, cool, thanks. Didn't know if you where aware  :)
[21:50] <abentley> No, I wasn't.  Thanks.
[21:51] <abentley> Every now and then it hangs badly enough a kill -9 is needed, and the auto-restart doesn't do that.
[21:52] <beuno> abentley, always sqlite's fault?
[21:52] <beuno> (loggerhead seems to do the same, so it makes me wonder)
[21:53] <abentley> No, an interaction between sqlite's and turbogears.
[21:54] <NemesisD> ugh, ok so rather than doing a bzr push with ssh, would it be equivalent to, on the local machine, do bzr checkout foo/ temp/, scp temp/ to the remote machine then delete the local copy of temp?
[21:54] <beuno> abentley, I haven't looked into it, but, would adding a postgre backend be too complicated?  I think you already use alchemy, right?
[21:55] <abentley> No, adding the backend isn't complicated.  I just don't see an easy way of migrating the data.
[21:57] <beuno> abentley, well, I want to use BB for a few projects, so, if you're willing to point me in the right direction now and then, I can try and add postgre/mysql support, and a migration script
[21:57] <beuno> (and, of course, to improve BB's uptime for bzr :p)
[21:57] <abentley> I'd love it if you did that.
[21:58] <beuno> cool, I've just finished work, so I'll plunge into the code now and start snooping
[21:58] <beuno> is there anyway I can get my hands on the current bzr sqlite DB to run tests?  I don't know if there's any sensitive data on it like passwords and such
[21:59] <keithy> have we a loggerhead expert in the house?
[21:59] <keithy> I have a heirarchical arrangement of brances
[21:59] <abentley> There are passwords.  I can get you a copy, but I'll have to scrub the passwords first.
[21:59] <keithy> and some duplicate names
[22:00] <keithy> loggerhead flattens them
[22:00] <beuno> abentley, no hurry, but if you could, it would probably speed things up for me  :)
[22:00] <keithy> and the duplicates are pointint to the same repo
[22:01] <beuno> keithy, mwhudson_ seems to be still away. He's in New Zeland, so don't expect him to be up for a couple more hours
[22:02] <abentley> beuno: Actually, he's awake and active on the private irc server.
[22:03] <beuno> ah, well, he must be busy then (I assumed because he has the _ in the nick)
[22:07] <keithy> mwhudson_: hello
[22:07] <keithy> do any of the other web frontends support a heirarchy of repos?
[22:09] <keithy> I cant see the "download tarball" option
[22:09] <beuno> keithy, loggerhead currently doesn't have that option
[22:10] <beuno> some work might be done on loggerhead in the following months, so expect improvements  :)
[22:10] <keithy> sigh
[22:10] <keithy> so nothing works
[22:11] <beuno> that may be a bit over the top, but feel free/encouraged to file bugs toward loggerhead as feature requests
[22:11] <keithy> http://bzr.warwick.st/
[22:12] <keithy> the published urls for the repositories are wrong
[22:12] <keithy> thats on the front page!
[22:13] <beuno> keithy, please file bugs with as much detail as you can so it can get fixed
[22:17] <mwhudson_> keithy: what's wrong with the urls?
[22:18] <keithy> I access my repo via
[22:18] <keithy> bzr push ssh://bzr.warwick.st/squeak/3.10/LPF/pr_tools
[22:19] <keithy> the url listed for pr_tools is
[22:19] <keithy> bzr push ssh://bzr.warwick.st/squeak/pr_tools
[22:19] <keithy> there are two LPF branches
[22:19] <keithy> bzr push ssh://bzr.warwick.st/squeak/3.10/LPF
[22:19] <keithy> bzr push ssh://bzr.warwick.st/squeak/3.9.1/LPF
[22:19] <keithy> they show up as the same repo
[22:20] <keithy> again with the wrong url
[22:21] <keithy> I spent 6 hours or more trying to get the apache config to work
[22:22] <keithy> I set up a virtual host instead
[22:22] <keithy> so that working now
[22:22] <mwhudson_> loggerhead displays the public_location url for each branch i think
[22:22] <keithy> sorry I dont know what that means
[22:23] <keithy> a branch should not know where it is in the hierarchy
[22:23] <mwhudson_> keithy: well, i don't really understand your description of your problem
[22:23] <mwhudson_> keithy: so i guess we're about even
[22:23] <keithy> I have a heirarchical repo
[22:23] <keithy> bzr push ssh://bzr.warwick.st/squeak/3.7
[22:24] <keithy> bzr push ssh://bzr.warwick.st/squeak/3.8
[22:24] <keithy> bzr push ssh://bzr.warwick.st/squeak/3.8
[22:24] <keithy> bzr push ssh://bzr.warwick.st/squeak/3.9
[22:24] <keithy> bzr push ssh://bzr.warwick.st/squeak/3.10
[22:24] <keithy> etc
[22:24] <mwhudson_> ok
[22:24] <keithy> bzr push ssh://bzr.warwick.st/squeak/3.10/LPF
[22:24] <keithy> bzr push ssh://bzr.warwick.st/squeak/3.9/LPF
[22:24] <mwhudson_> oh, i think i see
[22:24] <keithy> bzr push ssh://bzr.warwick.st/squeak/3.9/LPF/pr_tools
[22:24] <keithy> each level is a specialization of the one above
[22:25] <keithy> http://bzr.warwick.st  ignores the hierarchy
[22:25] <mwhudson_> so i guess one thing to say is that the urls loggerhead is using in the web browser and the paths you push to using ssh don't inherently have anything to do with each other
[22:26] <mwhudson_> keithy: can you pastebin your loggerhead.conf file?
[22:26] <keithy> url?
[22:27] <mwhudson_> http://pastebin.ubuntu.com/
[22:27] <keithy> http://pastebin.ubuntu.com/13727/
[22:28] <keithy> the repo heirarchy is fairly invisible since .bzr is a hidden directory, so my public users have no idea what is in the repo
[22:28] <keithy> so something should tell them what bzr command to use to access the repo
[22:30] <beuno> abentley, meeting all dependencies for BB in hardy is turning out to be quite a challenge
[22:30] <mwhudson> ah dammit i don
[22:30] <mwhudson> 't have the loggerhead source on this machine yet
[22:31] <mwhudson> (my hd in my other laptop died yesterday)
[22:31] <keithy> ouch
[22:32] <abentley> beuno: What's the problem?
[22:33] <beuno> abentley, BB asks for a newer (or older) version of almost all the dependencies
[22:33] <beuno> pkg_resources.VersionConflict: (PasteScript 1.6.2 (/usr/lib/python2.5/site-packages/PasteScript-1.6.2-py2.5.egg), Requirement.parse('PasteScript>=0.9.7,<1.6'))
[22:33] <beuno> finding newer egg's for the other ones was fairly easy, finding *older* versions is turning out to be much harder
[22:34] <abentley> I find you have to hand-hack the URLs for PyPI.
[22:34] <beuno> RuleDispatch above revision 3201 was a tough one too
[22:34] <abentley> But I honestly was unaware of any issue.  That PasteScript is not a dependency I deliberately put there.
[22:34] <abentley> Neither the RuleDispatch.
[22:35] <beuno> pkg_resources.VersionConflict: (RuleDispatch 0.5a0.dev-r2115 (/usr/lib/python2.5/site-packages/RuleDispatch-0.5a0.dev_r2115-py2.5-linux-i686.egg), Requirement.parse('RuleDispatch>=0.5a0.dev-r2303'))
[22:35] <abentley> This is all sounding suspiciously like *TurboGears* requirements, not BB's.
[22:35] <beuno> hrm
[22:36] <abentley> Have you installed Hardy's TG?
[22:36] <beuno> they are...
[22:36] <beuno> yes
[22:37] <mwhudson> keithy: so basically the problem is that loggerhead only really seems to expect branches to be directly in the repo
[22:37] <mwhudson> repo/
[22:37] <mwhudson> repo/branch1
[22:37] <keithy> something like that
[22:37] <mwhudson> repo/branch2
[22:37] <mwhudson> keithy: you can sort of fudge around this by not using auto_publish_folder i expect
[22:38] <keithy> and it finds branches at a deeper level, but "moves" them to the top level
[22:38] <mwhudson> or by using it for each part of your repo or something
[22:39] <keithy> k
[22:39] <beuno> abentley, I've got /usr/lib/python2.5/site-packages/TurboGears-<IP_ADDRESS>-py2.5.egg/turbogears/
[22:39] <mwhudson> i think you could say that the auto_publish_folders feature wasn't amazingly well thought out
[22:39] <abentley> So what are you doing that's triggering the demand for PasteScript.
[22:40] <beuno> abentley, starting BB. Although, traceback *is* from TurboGears
[22:40] <abentley> You don't have an old TG install do you?
[22:40] <abentley> in addition to the Hardy one?
[22:41] <beuno> abentley, let me check, but the traceback is coming from the path above
[22:41] <abentley> beuno: Please pastebin the traceback.
[22:42] <beuno> abentley, http://paste.ubuntu.com/13732/
[22:42] <abentley> beuno: It doesn't look like you're starting BB.
[22:43] <beuno> abentley, I was running setup for BB there, but it's the same error
[22:43] <beuno> in fact, I get the same error while importing turbogears in ipython
[22:44] <beuno> so it's definetly not a BB problem...  :/
[22:45] <mwhudson> i think i'd look for out of date crap on $PYTHONPATH
[22:45] <abentley> beuno: Yeah, I've just double-checked and BB only specifies versions of TG, Elixir, SQLAlchemy and bzr.
[22:46] <beuno> mwhudson, I'm starting to suspect it has something to do with when I installed loggerhead  :)
[22:46] <beuno> :p
[22:46] <mwhudson> eh, i wouldn't recommend actually _installing_ loggerhead
[22:46] <beuno> cleaning things up, installing them all over again
[22:47] <kwah> hi everyone
[22:47] <beuno> mwhudson, setup.py outdated?
[22:47] <kwah> are there features in bzr helping out in tracking refactoring ?
[22:48] <mwhudson> beuno: i haven't looked at setup.py once since i started maintaining loggerhead
[22:48] <beuno> mwhudson, aaah, good to know
[22:49] <beuno> (makes a lot of sense now)
[22:49] <mwhudson> beuno: perhaps i should have made it more obviously broken
[22:49] <mwhudson> oh actually i have looked at it
[22:49] <mwhudson> but only to get sdist to work
[22:50] <beuno> ok, yes, it was the loggerhead which b0rked everything
[22:50] <mwhudson> which reminds me, i should see if bzr 1.5 breaks loggerhead like i expected it to
[22:50] <beuno> oddly enough, for python2.5, if I run BB with python2.4, it works fine
[22:51] <beuno> mwhudson, I
[22:52] <beuno> I'd recommend breaking setup.py in a very obvious way  :)
[22:52] <beuno> if things go well, I might end up packaging, so I guess I'll have to fix it eventually, but, for now...
[22:55] <mwhudson> and wa-hey, no python 2.4 on this machine yet eithr
[22:55] <mwhudson> oh er, or tg
[22:57] <johan> is there a command similar to git log -p in bzr. which shows me a log but includes the diffs?
[23:04] <beuno> abentley, ok, cleaning up everything and doing clean installs worked.  Thanks, and sorry for the noise
[23:10] <pickscrape> johan: that's a request already in launchpad
[23:10] <johan> pickscrape: okay, that's good enough for me
[23:15] <abentley> beuno: No problem.
[23:34] <beuno> abentley, is there a specific problem you see in going from sqlite to postgre?   I'm running a few quick tests now against MySQL, and I don't see many problems in the horizon
[23:35] <abentley> No, I don't know of any specific problems.
[23:35] <abentley> I just have all this data and no simple way to convert it.
[23:35] <beuno> abentley, that's good news, I thought I was missing something
[23:36] <beuno> I'll try and hack together a script that does it, and, when you send me the data, I'll run tests against it
[23:36] <abentley> I guess you should try exercising all the hardcoded queries, since that's most likely to differ.
[23:37] <beuno> once I get all the data over, I'll look into testing those
[23:46] <abentley> beuno: The other thing to try would be getting the test suite running under PG.
[23:48] <beuno> abentley, sure, sounds sane. I'm going to start with mysql, because it's what I know best, and will spend the less amount of time with trivial problems, but jumping to pg after that should be very easy


[00:29] -queuebot:#ubuntu-release- New binary: rust-shadow-rs [riscv64] (lunar-proposed/universe) [0.20.0-1] (no packageset)
[00:33] -queuebot:#ubuntu-release- New binary: libdfu-ahp [riscv64] (lunar-proposed/universe) [1.0~git20221215.dd2df39-1] (no packageset)
[01:02] -queuebot:#ubuntu-release- Unapproved: autopkgtest (kinetic-proposed/main) [5.25ubuntu1 => 5.25ubuntu1.1] (core)
[01:08] -queuebot:#ubuntu-release- Unapproved: rejected autopkgtest [source] (kinetic-proposed) [5.25ubuntu1.1]
[06:48] -queuebot:#ubuntu-release- Packageset: 30 entries have been added or removed
[07:42] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [sync] (jammy-proposed) [2.06-2ubuntu14]
[09:18] -queuebot:#ubuntu-release- Unapproved: libreoffice (kinetic-proposed/main) [1:7.4.3-0ubuntu<IP_ADDRESS> => 1:7.4.4-0ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[09:46] -queuebot:#ubuntu-release- Unapproved: libinput (jammy-proposed/main) [1.20.0-1ubuntu0.1 => 1.20.0-1ubuntu0.2] (desktop-core, i386-whitelist)
[09:46] -queuebot:#ubuntu-release- Unapproved: libinput (kinetic-proposed/main) [1.21.0-1 => 1.21.0-1ubuntu1] (desktop-core, i386-whitelist)
[10:53] <tjaalton> sil2100: llvm has built, time to recover mesa backport from the jammy rejected list :)
[11:21] -queuebot:#ubuntu-release- New binary: php-maxminddb [amd64] (lunar-proposed/none) [1.11.0-4] (no packageset)
[11:21] -queuebot:#ubuntu-release- New binary: php-mcrypt [s390x] (lunar-proposed/none) [3:1.0.5-4] (no packageset)
[11:21] -queuebot:#ubuntu-release- New binary: rust-clap-derive-3 [ppc64el] (lunar-proposed/none) [3.2.18-2] (no packageset)
[11:21] -queuebot:#ubuntu-release- New binary: php-mcrypt [amd64] (lunar-proposed/none) [3:1.0.5-4] (no packageset)
[11:21] -queuebot:#ubuntu-release- New binary: rust-clap-derive-3 [amd64] (lunar-proposed/none) [3.2.18-2] (no packageset)
[11:22] -queuebot:#ubuntu-release- New binary: php-maxminddb [s390x] (lunar-proposed/none) [1.11.0-4] (no packageset)
[11:22] -queuebot:#ubuntu-release- New binary: rust-clap-derive-3 [s390x] (lunar-proposed/none) [3.2.18-2] (no packageset)
[11:22] -queuebot:#ubuntu-release- New binary: php-mcrypt [ppc64el] (lunar-proposed/none) [3:1.0.5-4] (no packageset)
[11:23] -queuebot:#ubuntu-release- New binary: php-maxminddb [ppc64el] (lunar-proposed/none) [1.11.0-4] (no packageset)
[11:23] -queuebot:#ubuntu-release- New binary: rust-clap-derive-3 [armhf] (lunar-proposed/none) [3.2.18-2] (no packageset)
[11:23] -queuebot:#ubuntu-release- New binary: php-mcrypt [armhf] (lunar-proposed/none) [3:1.0.5-4] (no packageset)
[11:24] -queuebot:#ubuntu-release- New binary: php-maxminddb [arm64] (lunar-proposed/none) [1.11.0-4] (no packageset)
[11:28] -queuebot:#ubuntu-release- New: accepted libdfu-ahp [amd64] (lunar-proposed) [1.0~git20221215.dd2df39-1]
[11:28] -queuebot:#ubuntu-release- New: accepted libdfu-ahp [armhf] (lunar-proposed) [1.0~git20221215.dd2df39-1]
[11:28] -queuebot:#ubuntu-release- New: accepted libdfu-ahp [riscv64] (lunar-proposed) [1.0~git20221215.dd2df39-1]
[11:28] -queuebot:#ubuntu-release- New: accepted numba [amd64] (lunar-proposed) [0.56.4+dfsg-1]
[11:28] -queuebot:#ubuntu-release- New: accepted numba [armhf] (lunar-proposed) [0.56.4+dfsg-1]
[11:28] -queuebot:#ubuntu-release- New: accepted numba [s390x] (lunar-proposed) [0.56.4+dfsg-1]
[11:28] -queuebot:#ubuntu-release- New: accepted php-maxminddb [arm64] (lunar-proposed) [1.11.0-4]
[11:28] -queuebot:#ubuntu-release- New: accepted php-maxminddb [s390x] (lunar-proposed) [1.11.0-4]
[11:28] -queuebot:#ubuntu-release- New: accepted php-mcrypt [armhf] (lunar-proposed) [3:1.0.5-4]
[11:28] -queuebot:#ubuntu-release- New: accepted php-mcrypt [s390x] (lunar-proposed) [3:1.0.5-4]
[11:28] -queuebot:#ubuntu-release- New: accepted libdfu-ahp [arm64] (lunar-proposed) [1.0~git20221215.dd2df39-1]
[11:28] -queuebot:#ubuntu-release- New: accepted libdfu-ahp [s390x] (lunar-proposed) [1.0~git20221215.dd2df39-1]
[11:28] -queuebot:#ubuntu-release- New: accepted numba [ppc64el] (lunar-proposed) [0.56.4+dfsg-1]
[11:28] -queuebot:#ubuntu-release- New: accepted php-maxminddb [ppc64el] (lunar-proposed) [1.11.0-4]
[11:28] -queuebot:#ubuntu-release- New: accepted php-mcrypt [ppc64el] (lunar-proposed) [3:1.0.5-4]
[11:28] -queuebot:#ubuntu-release- New: accepted rust-clap-derive-3 [armhf] (lunar-proposed) [3.2.18-2]
[11:28] -queuebot:#ubuntu-release- New: accepted rust-clap-derive-3 [s390x] (lunar-proposed) [3.2.18-2]
[11:28] -queuebot:#ubuntu-release- New: accepted rust-shadow-rs [arm64] (lunar-proposed) [0.20.0-1]
[11:28] -queuebot:#ubuntu-release- New: accepted rust-shadow-rs [ppc64el] (lunar-proposed) [0.20.0-1]
[11:28] -queuebot:#ubuntu-release- New: accepted rust-shadow-rs [s390x] (lunar-proposed) [0.20.0-1]
[11:29] -queuebot:#ubuntu-release- New: accepted libdfu-ahp [ppc64el] (lunar-proposed) [1.0~git20221215.dd2df39-1]
[11:29] -queuebot:#ubuntu-release- New: accepted php-maxminddb [amd64] (lunar-proposed) [1.11.0-4]
[11:29] -queuebot:#ubuntu-release- New: accepted rust-clap-derive-3 [amd64] (lunar-proposed) [3.2.18-2]
[11:29] -queuebot:#ubuntu-release- New: accepted rust-shadow-rs [amd64] (lunar-proposed) [0.20.0-1]
[11:29] -queuebot:#ubuntu-release- New: accepted rust-shadow-rs [riscv64] (lunar-proposed) [0.20.0-1]
[11:29] -queuebot:#ubuntu-release- New: accepted numba [arm64] (lunar-proposed) [0.56.4+dfsg-1]
[11:29] -queuebot:#ubuntu-release- New: accepted rust-clap-derive-3 [ppc64el] (lunar-proposed) [3.2.18-2]
[11:29] -queuebot:#ubuntu-release- New: accepted php-mcrypt [amd64] (lunar-proposed) [3:1.0.5-4]
[11:29] -queuebot:#ubuntu-release- New: accepted rust-shadow-rs [armhf] (lunar-proposed) [0.20.0-1]
[11:32] -queuebot:#ubuntu-release- New binary: rust-clap-derive-3 [arm64] (lunar-proposed/none) [3.2.18-2] (no packageset)
[11:34] -queuebot:#ubuntu-release- New binary: php-maxminddb [armhf] (lunar-proposed/none) [1.11.0-4] (no packageset)
[11:34] -queuebot:#ubuntu-release- New binary: php-mcrypt [arm64] (lunar-proposed/none) [3:1.0.5-4] (no packageset)
[11:38] <schopin> athos: sorry, my week has been unusually meeting-intensive so far, I haven't been pulling my +1 weight. I'm currently looking into nipype (needs a patch for new numpy) and will then move onto matplotlib.
[12:13] <ricotz> sil2100, hello :), it would great if you have time to look at this libreoffice SRU for kinetic - https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/2001911
[12:13] -ubottu:#ubuntu-release- Launchpad bug 2001911 in libreoffice (Ubuntu Kinetic) "[SRU] libreoffice 7.4.4 for kinetic" [High, In Progress]
[12:44] <sil2100> ricotz: o/
[12:48] <ricotz> sil2100, o/
[12:48] <sil2100> ricotz: while we're at it, I see the previous libreoffice SRU in -propsoed had some discussion re: the s390x test regressions. Will this upload suffer  from the same problems?
[12:48] <ricotz> this is basically superseding https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1997333
[12:48] -ubottu:#ubuntu-release- Launchpad bug 1997333 in libreoffice (Ubuntu Kinetic) "[SRU] libreoffice 7.4.3 for kinetic" [High, Fix Committed]
[12:49] <ricotz> sil2100, I have added a patch to skip those on s390x, and the test-run of autopkgtest on s390x succeeded
[12:50] <sil2100> Excellent
[12:50] <sil2100> ricotz: by skipping you mean the single tests that were failing, not the whole suite, right?
[12:51] <ricotz> sil2100, https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/commit/?h=wip/kinetic-7.4&id=2fc53a0c2d178b7193d2f069ea140d1c3fb8e088
[12:51] -ubottu:#ubuntu-release- Commit 2fc53a0 in ~libreoffice/ubuntu/+source/libreoffice "autopkgtests: Skip two failing tests on s390x"
[13:01] <sil2100> Awesome
[13:03] -queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (kinetic-proposed) [1:7.4.4-0ubuntu<IP_ADDRESS>]
[13:06] <ricotz> thank you \o/
[13:42] <athos> schopin: nice. some packages failed w/ a weird error (seems to be a autopkgtest infra error). I retriggered some of those and am looking for the netx package to work on
[14:00] <tjaalton> sil2100: dunno if the bot spam scrolled my comment out of sight, but jammy-proposed is now clear for mesa, it's on the rejected list if it can be resurrected from there, or I'll upload again
[14:00] <sil2100> \o/
[14:00] <sil2100> Looking
[14:00] <sil2100> tjaalton: is that both kinetic and jammy, or just jammy?
[14:01] <tjaalton> just jammy, kinetic has it already
[14:02] <sil2100> tjaalton: 22.0.5-0ubuntu0.4, correct?
[14:03] <tjaalton> no 22.2.x
[14:05] <tjaalton> 22.2.5-0ubuntu0.1~22.04.1
[14:31] <tjaalton> sil2100: did you find it?-)
[14:32] <athos> schopin: I will handle foolscap now and will move to dovecot then :)
[14:32] <schopin> Great, thanks!
[14:52] <tjaalton> sil2100: btw, there's this bug for linux-firmware which concerns the point-release as well: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1999406
[14:52] -ubottu:#ubuntu-release- Launchpad bug 1999406 in linux-firmware (Ubuntu Lunar) "Update firmware for hwe/oem kernel migrations" [High, In Progress]
[14:53] <sil2100> tjaalton: hmm, I'm confused by this here: https://launchpad.net/ubuntu/jammy/+queue?queue_state=4&queue_text=mesa
[14:53] <tjaalton> we discussed this a bit in Prague, and this approach is the middle-ground for updating the firmware that we know are needed for the newer kernels. the other option was to just backport it all as-is
[14:53] <tjaalton> sil2100: yes, there were bogus uploads, forget about 0.4.. we decided to remove directx-headers instead of patching mesa
[14:53] <sil2100> tjaalton: so I should take the ~22.04.1, right? Why were there 3 other uploads rejected afterwards? ANd the ~22.04.1 has a rejection message of "Rejected in favor of 22.0.5-0ubuntu0.3"
[14:53] <tjaalton> to fix the build
[14:54] <sil2100> Ah, ok!
[14:54] <tjaalton> yeah that was because the review tooling was confused aiui
[14:55] <tjaalton> it only saw the oldest upload or something
[14:55] <sil2100> Reviewing now o/
[14:55] <tjaalton> excellent
[17:22] -queuebot:#ubuntu-release- New binary: python-epimodels [amd64] (lunar-proposed/universe) [0.4.0-1] (no packageset)
[17:25] <ricotz> vorlon, hi, I will upload the next libreoffice 7.5 upstream release candidate for lunar this week, I noted the amd64 autopkgtest failures for now, but I won't try to fix them with that upload yet
[17:26] <vorlon> ricotz: if you're not fixing the autopkgtest failures, what possible point is there to uploading?
[17:26] <vorlon> it's just going to waste a bunch of resources and then get stuck in -proposed
[17:27] <ricotz> vorlon, as I said this is the next release candidate including a lot of changes
[17:27] <vorlon> ricotz: but why should it be in the archive instead of in a ppa?
[17:28] <ricotz> vorlon, and yes, I don't want to waste resources even with PPA build
[17:28] <vorlon> fyi folks, per discussion w/ ginggs and bdmurray we've dumped everything in the s390x 'huge' autopkgtest queue and are requeuing based on the versions that proposed-migration is *currently* waiting for.  This e.g. gets rid of tests that were triggered for the /previous/ version of perl whose results we no longer care about
[17:29] <vorlon> the requeuing is not the speediest, however :)
[17:29] <ricotz> great :)
[17:30] <vorlon> (at present: 4700 of 10k tests re-queued)
[17:31] -queuebot:#ubuntu-release- New: accepted php-maxminddb [armhf] (lunar-proposed) [1.11.0-4]
[17:31] -queuebot:#ubuntu-release- New: accepted python-epimodels [amd64] (lunar-proposed) [0.4.0-1]
[17:31] -queuebot:#ubuntu-release- New: accepted php-mcrypt [arm64] (lunar-proposed) [3:1.0.5-4]
[17:31] -queuebot:#ubuntu-release- New: accepted rust-clap-derive-3 [arm64] (lunar-proposed) [3.2.18-2]
[17:34] <ricotz> vorlon, do you know if the "pkgstripfiles dead-lock" has got some investigation in the past? I am seeing this currently with libreoffice/riscv64 https://launchpad.net/ubuntu/+source/libreoffice/1:7.5.0~rc1-0ubuntu2/+build/25425185
[17:35] <vorlon> ricotz: why do you think it's a deadlock?
[17:36] <vorlon> I don't remember why pkgstripfiles can't be run in parallel across different binary packages, but given that it takes a while to run it for even *one* package, it's probably sensible regardless.  I've never seen it deadlock, it's just slow on large packages
[17:36] <ricotz> vorlon, I had a small talk with cj_watson some time ago, bascially it can finished after some days, but usually the build just dies before that
[17:36] <vorlon> ok, I don't know anything about that
[17:37] <ricotz> this is independent from the arch, I saw this happening on amd64 too
[17:38] <ricotz> (without leaving a build log)
[17:38] <vorlon> pkgstripfiles timing out on riscv64 for libreoffice seems plausible to me without being a deadlock
[17:39] <ricotz> I see, is it possible to skip this for specific packages/archs?
[17:39] <vorlon> yes
[17:39] <vorlon> the consequence will be not having dbgsym packages for that package/arch
[17:40] <vorlon> let me check the syntax for skipping it
[17:41] <ricotz> hmm, oh, isn't that archive build specific
[17:42] <ricotz> sorry, I assumed this is the "pkgmangler" which strips translations and optimizes image files
[17:43] <vorlon> oh, actually I don't even see in the code that this is the bit that handles dbgsym files
[17:43] <vorlon> anyway, are there a lot of .png files in the libreoffice tree?  that's usually the expensive bit
[17:43] <vorlon> which NO_PNG_PKG_MANGLE=1 will avoid
[17:44] <ricotz> yes, the help files contain a lot of images, and a lot of svg files
[17:44] <vorlon> this is all in the pkgbinarymangler package in the archive if you want to have a look around
[17:44] <ricotz> thanks for the gint
[17:44] <ricotz> *hint
[17:44] <vorlon> right - optimizing the png files is expensive
[17:50] <vorlon> ok, s390x huge queue refilled.  https://autopkgtest.ubuntu.com/running will take a bit yet to catch up
[18:14] <cjwatson> vorlon,ricotz: I have to say, https://paste.ubuntu.com/p/ZpxxZBZdn7/ looks a bit like a deadlock to me
[18:16] <ricotz> cjwatson, any chance to investigate it with that build?
[18:16] <ricotz> I assume skipping the png optimization only would not help then
[18:16] <cjwatson> I'm happy for people to suggest things I might check
[18:17] <cjwatson> Because I do see suspicious things like this on the build farm from time to time, and cleaning them up manually is tedious
[18:21] <cjwatson> https://paste.ubuntu.com/p/HZHspvVw35/ - current lock file contents
[18:27] <ricotz> cjwatson, looks like a similar case https://launchpad.net/ubuntu/+source/libreoffice/1:7.4.4-0ubuntu<IP_ADDRESS>/+build/25478191
[18:27] <ricotz> but probably still alive
[18:31] <cjwatson> Possible clue, further back in the build log I see "gzip: stdin: unexpected end of file" and "tar: Unexpected EOF in archive" and then dpkg-deb exiting non-zero
[18:32] <cjwatson> I wonder if it's bad error handling in pkgbinarymangler, so if it hits ENOSPC or something then it never recovers and spins forever
[18:32] <cjwatson> The "waiting for lock" stuff starts right after those errors
[18:33] <cjwatson> I don't have the same tools available to me to poke about inside ppc64el builds
[18:33] <cjwatson> (Ideally I wouldn't even for riscv64 builds, but with the way things are set up right now, I do)
[18:36] <vorlon> cjwatson: thanks for the added context.  ENOSPC, what are the chances of that happening intermittently due to parallel builds?  Also, pkgstripfiles itself doesn't look like it should be disk-intensive...
[18:38] <cjwatson> https://paste.ubuntu.com/p/9yJ28Q4xyN/
[18:39] <cjwatson> intermittent ENOSPC is certainly a possibility.  Right now this particular builder has 47G free, but that might not mean much if there are a lot of temporaries
[18:39] <cjwatson> It's not unambiguously ENOSPC, that just seems like a good guess for this particular kind of failure
[18:40] <cjwatson> I think pkgstriptranslations is the thing that's actually failing, and that might use non-trivial space maybe?
[18:40] <cjwatson> But maybe somebody can sit down and think hard about the locking arrangements here given that context
[18:41] <cjwatson> Or actually maybe it's dpkg-deb --build that's failing
[18:41] <vorlon> pkgstriptranslations also just moves .po or .mo files around, doesn't it?  would surprise me if that used a lot of disk either
[18:41] <cjwatson> That's kind of what the log suggests
[18:41] <vorlon> ah
[18:41] <vorlon> *that* would use more disk :)
[18:49] <cjwatson> https://paste.ubuntu.com/p/F6G4TQJnxv/ is perhaps also relevant information since that indicates which dpkg-deb runs actually succeeded
[18:53] <cjwatson> aaaaalso I think there might be a fundamental logical incompatibility between pkgbinarymangler's locking strategy and debhelper's parallelism, although I haven't completely thought it through
[18:54] <cjwatson> debhelper's dh_builddeb calls on_items_in_parallel, which divides up the list of packages to operate on into batches and calls a provided sub with each batch
[18:54] <cjwatson> The provided sub walks through the batch in order and calls dpkg-deb --build on each item
[18:55] <cjwatson> Meanwhile, pkgbinarymangler's dh_builddeb diversion writes out the list of packages to a file
[18:55] <cjwatson> (the lock file)
[18:55] <cjwatson> pkgstripfiles then only processes a package once it finds it on the first line of the lock file, and deletes it from the lock file once it's done
[18:57] <cjwatson> As I say I haven't completely thought this through, but that strategy feels pretty fragile.  If there's any disagreement at all between the order that debhelper works in and the order that pkgstripfiles works in, it seems as though it will deadlock, since there's no completely obvious guarantee that a package that's actually having dpkg-deb --build called on it - and is not e.g. waiting for an
[18:57] <cjwatson> earlier package in the batch to finish - will ever reach the top of the lock file
[18:58] <cjwatson> That said, the enforcing of ordering is probably deliberate due to https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/893826
[18:58] -ubottu:#ubuntu-release- Launchpad bug 893826 in qt4-x11 (Ubuntu Precise) "symlinked docs are different between architectures, depending on dpkg-deb package order" [High, Fix Released]
[18:58] <cjwatson> So maybe it does make sense, but it hurts my brain
[19:04] <cjwatson> I can't see how pkgbinarymangler's dh_builddeb would have got as far as calling dpkg-deb --build on the main libreoffice package without first calling pkgstripfiles on it; but there's an error message for dpkg-deb --build on that package, and it's still in the pkgstripfiles lock file
[19:05] <cjwatson> Same goes for several other binary packages there
[19:06] <cjwatson> Can anyone see anything I'm missing there?  I probably need to eat
[19:16] <Eickmeyer> ubuntu-archive: Does anybody have a spare cycle to review edubuntu-installer in NEW? It's not a system installer, it's more akin to ubuntustudio-installer in that it's a metapackage installer.
[19:36] <vorlon> hopefully not too much like ubuntustudio-installer which afaik has been out of compliance with TB guidance around third-party repositories for years.
[19:36] <Eickmeyer> vorlon: No third-party repo stuff.
[19:37] <vorlon> ok, I'll try to get to it later this afternoon (but dotnet7 has been awaiting bootstrapping so takes priority)
[19:38] <Eickmeyer> vorlon: Understandable. :)
[19:41] <vorlon> xypron, xnox: linux-allwinner-5.17 and linux-starfive-5.17 FTBFS in lunar and appear to be superseded by the non-5.17 kernel flavors, should these be removed from lunar?
[19:58] <arraybolt3> vorlon: (re: out of compliacne with TB guidance around third-party repositories) Partially out of curiosity, and partially to further my own knowledge, is the TB guidance you mention documented anywhere public, and if so, could I have a link to it? (If you're too busy now, no problem, I'll try and find it.)
[20:02] <vorlon> arraybolt3: well it was in TB minutes at least, so "public but difficult to discover" probably
[20:16] <vorlon> cpaelzer_: I'm still unhappy about the tabular output formatting, but it's good for dopamine hits from being able to remove packages without having to think deepyl
[20:16] <vorlon> *deeply
[20:33] <xypron> @vorlon: The generic kernel does not support the Nezha D1, Lichee RV, VisionFive. esmil: has rebasing the -allwinner and -starfive flavors on his agenda.
[20:38] <vorlon> xypron: there are 5.19-based linux-allwinner and linux-starfive source packages in lunar that don't fail to build
[20:38] <vorlon> so isn't 5.17 obsolete for lunar?
[20:39] <xypron> vorlon: then 5.17 should be obsolete.
[20:57] -queuebot:#ubuntu-release- Unapproved: autopkgtest (kinetic-proposed/main) [5.25ubuntu1 => 5.25ubuntu1.1] (core)
[21:50] <bdmurray> The amd64 queue experienced a processing hiccup but should be better now
[23:21] -queuebot:#ubuntu-release- New binary: tideways [amd64] (lunar-proposed/universe) [5.0.4-15] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: libahp-gt [amd64] (lunar-proposed/none) [1.6.0-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: tideways [ppc64el] (lunar-proposed/universe) [5.0.4-15] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: libahp-gt [ppc64el] (lunar-proposed/none) [1.6.0-1] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: libahp-gt [arm64] (lunar-proposed/none) [1.6.0-1] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: libahp-gt [armhf] (lunar-proposed/none) [1.6.0-1] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: tideways [armhf] (lunar-proposed/universe) [5.0.4-15] (no packageset)
[23:25] -queuebot:#ubuntu-release- New binary: tideways [arm64] (lunar-proposed/universe) [5.0.4-15] (no packageset)
[23:31] -queuebot:#ubuntu-release- New binary: libahp-gt [s390x] (lunar-proposed/universe) [1.6.0-1] (no packageset)
[23:34] -queuebot:#ubuntu-release- New binary: tideways [s390x] (lunar-proposed/universe) [5.0.4-15] (no packageset)
[23:54] -queuebot:#ubuntu-release- New: accepted libahp-gt [armhf] (lunar-proposed) [1.6.0-1]
[23:54] -queuebot:#ubuntu-release- New: accepted tideways [arm64] (lunar-proposed) [5.0.4-15]
[23:54] -queuebot:#ubuntu-release- New: accepted tideways [s390x] (lunar-proposed) [5.0.4-15]
[23:54] -queuebot:#ubuntu-release- New: accepted libahp-gt [s390x] (lunar-proposed) [1.6.0-1]
[23:54] -queuebot:#ubuntu-release- New: accepted tideways [armhf] (lunar-proposed) [5.0.4-15]
[23:55] -queuebot:#ubuntu-release- New: accepted libahp-gt [amd64] (lunar-proposed) [1.6.0-1]
[23:55] -queuebot:#ubuntu-release- New: accepted libahp-gt [ppc64el] (lunar-proposed) [1.6.0-1]
[23:55] -queuebot:#ubuntu-release- New: accepted tideways [ppc64el] (lunar-proposed) [5.0.4-15]
[23:55] -queuebot:#ubuntu-release- New: accepted libahp-gt [arm64] (lunar-proposed) [1.6.0-1]
[23:55] -queuebot:#ubuntu-release- New: accepted tideways [amd64] (lunar-proposed) [5.0.4-15]
[23:58] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [sync] (kinetic-proposed) [2.06-2ubuntu14]