[02:27] <Logan_> james_w: Are you around?
[02:27] <james_w> Logan_, yeah
[02:28] <Logan_> james_w: could you please requeue_package.py --full hivex ?
[02:28] <Logan_> There's currently an import failure for it that should be resolved with that command.
[02:29] <james_w> Logan_, done
[02:29] <Logan_> Thanks. :)
[02:29] <james_w> with --priority for good measure :-)
[02:30] <Logan_> Awesome. :P
[04:07] <mortrca> Whenever a member of my team commits changes, the file <RepositoryLocation>/.bzr/repository/pack-names is changed so that it is no longer owned by the group, but by the user that has committed the changes. This makes it impossible for anyone to commit changes until the ownership is changed back. How can I fix this?
[04:09] <fullermd> The file gets replaced, I'm pretty sure, so it shouldn't matter.  They just need to be able to write the dir.
[04:11] <bob2> you need to fix their umasks
[04:11] <bob2> and then make .bzr g+s, recursively
[04:11] <mortrca> fullermd: Even with permission to write to the directory the file becomes unavailable.
[04:12] <fullermd> umask shouldn't matter; bzr will inherit the dir mode.
[04:12] <fullermd> The g+s is probably it.  I keep forgetting about the problems of inferior FS semantics  ;p
[04:14] <mortrca> I will give that a try, thank you.
[04:14] <bob2> umask is need to make it group writable
[04:14] <fullermd> No, bzr will do that itself if the dir is group writable.
[04:15] <fullermd> ('m pretty sure it'll even make it world writable if the dir is...)
[07:54] <mgrandi> so apparently you can make bzr run out of memory by having a big commit >.>
[07:56] <mgrandi> but strangely you can still commit it
[09:21] <venefyxatu> mgrandi: there are several ways to make it run out of memory :-)   https://bugs.launchpad.net/bzr/+bug/367545 and https://bugs.launchpad.net/bzr-svn/+bug/191731
[09:21] <venefyxatu> ooh, fun
[09:21]  * venefyxatu pokes ubot5
[09:23] <mgrandi> probably involves the branch one
[09:24] <mgrandi> but also happens during merge / pull
[14:22] <askhl> Hi.  I'm trying to share a repostiory on one computer with multiple people using ssh.  But after a push by USER, the file .bzr/repositories/pack-names will be owned by USER.USER, which prevents other users from pushing until I fix the group permissions.  How should I solve this?  The examples I find on the net do not seem to have to deal with this problem.
[15:24] <askhl> Let me rephrase my previous question: "How do I properly grant commit rights to someone?"
[16:03] <pef_> hi! I have installed bzr on a cluster and I'm getting
[16:03] <pef_> Value "/etc/ssl/certs/ca-certificates.crt" is not valid for "ssl.ca_certs"
[16:03] <pef_> No valid trusted SSL CA certificates file set. See 'bzr help ssl.ca_certs' for more information on setting trusted CAs.
[16:03] <pef_> See `bzr help ssl.ca_certs` for how to specify trusted CAcertificates.
[16:03] <pef_> Pass -Ossl.cert_reqs=none to disable certificate verification entirely.
[16:04] <pef_> however, I don't want to have to pass that argument each time when I call bazaar
[16:04] <pef_> how do I turn it off in my ~/.bazaar?
[16:04] <pef_> I've tried
[16:04] <pef_> ssl.cert_reqs=none
[16:04] <pef_> ssl.ca_certs=none
[16:04] <pef_> but it doesn't change anything
[19:15] <jelmer> pef_: that should do it
[19:15] <jelmer> pef_: what section did you set it in?
[19:15] <pef_> I didn't know I had to put it in a section
[19:15] <pef_> those two lines are the only contents of the file
[19:15] <pef_> what should [go above]?
[19:15] <jelmer> e.g. [DEFAULT]
[19:16] <jelmer> though I think if you don't have a section, it means it's in that one too
[19:17] <pef_> nope, adding [DEFAULT] hasn't made a difference
[19:18] <pef_> any other ideas?