[06:52] <vila> hi all
[06:59] <maxb> jelmer: You reviewed https://code.launchpad.net/~maxb/bzr/fix-meliae-feature-use/+merge/72353 as "Needs Fixing" without an explanation?
[07:43] <vila> maxb: on natty, with the bzr ppa in sources.list, bzr-2.4.0 is not proposed. If I try to force its installation, I'm told bzrtools and qbzr should be removed
[07:44] <vila> maxb: is it because we need new versions for bzrtools and qbzr in the ppa ?
[08:37] <jam> hi all
[08:38] <nyuszika7h> Hi
[08:47] <vila> jam: hey
[09:02] <maxb> vila: err... I can't reproduce that
[09:03]  * vila blinks
[09:03] <vila> maxb: any idea on how I could debug it ?
[09:04] <maxb> try 'apt-cache policy bzr bzrtools qbzr', and see if anything seems unexpected
[09:05] <vila> yup, was going down that route and: http://paste.ubuntu.com/674389/
[09:06] <vila> maybe I should just force the installation of bzr and bzrtools and be done
[09:06] <maxb> ah, you have apt pins you've forgotten about :-)
[09:06] <maxb> See /etc/apt/preferences
[09:08] <vila> oooh, -updates preferred over ppa ?
[09:09] <maxb> evidently
[09:09] <vila> ok :)
[09:10] <vila> So, what are the possibilities here ? Add a pin-priority for ppa ? Move apt/preferences out of the way during the upate ? Just force bzr install ?
[09:10] <maxb> Well, why do you have an /etc/apt/preferences at all?
[09:11] <vila> hehe, right, I was there indeed, I used to need it to be able to test -proposed but I don't need it anymore
[09:19] <vila> maxb: solved, thanks
[09:33] <poolie> hi jam, maxb, vila
[09:40] <vila> poolie: hey
[09:41] <poolie> hi there
[09:44] <jelmer> hi jam, maxb, poolie, vila
[09:44] <vila> jelmer: hey
[09:46] <maxb> morning all :-)
[09:46] <maxb> jelmer: Could you clarify your "Needs Fixing" on https://code.launchpad.net/~maxb/bzr/fix-meliae-feature-use/+merge/72353 ?
[09:48] <jelmer> maxb: That was in response to jam's comments, I hadn't seen you had updated the code already
[09:48] <jelmer> maxb: now approved
[09:48] <maxb> I thought it most likely was - thanks
[09:56] <poolie> no jam yet?
[09:57] <jelmer> he was here earlier this morning
[09:58] <vila> he's often lunching around  this time of day
[09:58] <poolie> i always forget you guys are a bit closer than i expect, at least at this time of year
[10:01] <vila> poolie: funnily enough, I feel the same with you :) I often think: "Damn, still awake ???" before checking your tZ ;)
[10:01] <poolie> i should stop soon
[10:01] <poolie> it's 8 here
[10:17] <deni> hi all
[10:17] <deni> anyone have any idea how to change the default permissions bzr uses when someone does a push to a local repo
[10:18] <deni> *local=remote
[10:22] <Riddell> deni: the files just get written by the receiving sever (ssh or apache or bzr smart server etc) so it just depends on who that server is running as
[10:27] <deni> Riddell: i use bzr+ssh
[10:27] <deni> to push to a remote repo
[10:27] <poolie> hi deni, riddell
[10:27] <deni> but the permissions are not set accoiring to the defualt umask
[10:27] <deni> *according
[10:28] <deni> i have a shared repo .... that need to be g+w
[10:28] <deni> so i set the default umask to 007....
[10:28] <deni> so all the files and folders are created with the g+w permission
[10:28] <deni> bzr seems to disregard that
[10:29] <deni> cause when i push a newly created local repo on to the remote host it creates the folder with g-w permissions
[10:29] <jelmer> deni: bzr doesn't track modes, just the exectutable bit
[10:29] <deni> i've searched a little bit on the net and this seems to be a bzr bug
[10:29] <deni> jelmer: what do you mean by doesn't track modes?
[10:30] <jelmer> deni: sorry, I was misunderstanding your question.
[10:30] <poolie> yes there is a bug for this
[10:32] <deni> poolie: do you know what the status is for this?
[10:32] <deni> or if there are any workarounds
[10:34] <poolie> so first off, are you sure the umask is actually set when the remote bzr shell starts?
[10:34] <poolie> eg if you do 'ssh myhost mkdir foo'
[10:34] <poolie> does foo end up with the intended permissions?
[10:35] <deni> poolie: yes i've tested creating files and folders over ssh and it respects the default umask
[10:36] <poolie> deni, and doesn't it at least inherit the permissions from the repository directory?
[10:40] <deni> poolie: here's the scenario
[10:41] <deni> i create a local repo....do some work....and i decide i want to push this repo onto a remote host so that others can access it and so i can have a backup if my hard drive fails
[10:41] <deni> i do a push
[10:41] <deni> the repo is created with the screwed up permissions...
[10:41] <deni> i have to go ssh onto the remote host
[10:41] <deni> do a chmod -R
[10:41] <deni> and after that everything works fine
[10:42] <deni> but i don't wan't to have to do this every time we create a new project
[10:42] <poolie> yeah i can understand that
[10:42] <poolie> it's https://bugs.launchpad.net/bzr/+bug/394559
[10:43] <deni> i assume i could ssh first and create the folder manually and then do a push and that the permissions would be perserved but that's not the best solution either
[10:43] <deni> actually that's no different from having to do a chmod
[10:44] <deni> poolie: i think it has more to with this one https://bugs.launchpad.net/bzr/+bug/50568
[10:45] <deni> it's from 2006 and still not solved???
[10:46] <poolie> that's sftp specific
[10:47] <poolie> but it has a workaround
[10:48] <deni> poolie: you mean ACLs?
[10:49] <deni> seems kind of an overkill for something like this
[10:49] <poolie> or i believe bzr+ssh will not reset the setgid bit
[10:50] <deni> still
[10:50] <deni> that's no different than doing a chmod
[10:50] <deni> hmm
[10:50] <deni> no wait
[10:51] <deni> i'll test that right now
[10:59] <deni> poolie: it doesn't seem to work
[10:59] <deni> bzr+ssh screws things up again
[10:59] <deni> regardless
[11:01] <poolie> deni, isn't it inheriting them from the containing directory?
[11:04] <deni> poolie: it appears not
[11:06] <poolie> hm
[11:06] <poolie> that's really pretty strange
[11:09] <deni> i'd say so
[11:12] <deni> the sitcy bit doesn't do anything other than make it so that the files created in that directory belong to the same group regardless of who creates it
[11:13] <deni> that doesn't help me much cause bzr users already all belong to the same group
[11:13] <deni> bzr doesn't change the group or anything like that
[11:13] <deni> it just doesn't preserve the write permissions that the parrent directory does have
[11:14] <deni> i don't see how the sitcky bit would help in this situation at all
[11:14] <poolie> where did the sticky bit even come in to this?
[11:15] <deni> sorry my bad....i was talking about setdit
[11:15] <deni> *setgid
[11:16] <deni> it kinda goes along with the sticky bit so i was thinking about one and talking about the other
[11:16] <deni> anyway..i tried setting g+s but like i said all that does is make it so that all the files created in my /bzr folder have the same group as the bzr folder
[11:17] <deni> that does not help at all since the bzr users are already in the same group
[11:17] <deni> setgid does not preserve the g+w option
[11:35] <vila> deni: what does 'ssh myhost umask' says ?
[11:36] <dpi_> hi
[11:37] <dpi_> can any1 here help me with a bzr problem on Win7 64 ?
[11:37] <dpi_> plz ?
[11:37] <vila> deni: just checking, I've been confused in the past about profile files executed or not depending on the way you connect and what command you run, bzr+ssh doesn't start a shell by default so very little is set (unlike when you start a remote shell)
[11:38] <vila> in other news the babune windows salve reports 105 new failures since revno 6076..6082
[11:38] <vila> slave
[11:39] <poolie> ok good night all
[11:39] <vila> http://babune.ladeuil.net:24842/view/%20High/job/selftest-windows/503/
[11:39] <vila> poolie: g'night !
[11:40] <nigelb> gosh, I need to stop hilighting my last name, I end up getting pinged for babune :)
[11:40] <vila> nigelb: soory about that ;)
[11:40] <nigelb> heh
[11:41] <jelmer> g'night poolie
[11:41] <jelmer> Riddell: reviewed i18n-install
[11:43] <Riddell> a hat trick of approvals, that should keep PQM busy for the next day
[11:49] <deni> vila: tnx for the info....so bzr+ssh ignores the /etc/profile file
[11:49] <deni> is there any way around that?
[11:49] <vila> well, *ssh* does
[11:51] <deni> so how do you explain the fact that it ignores the umask settings?
[11:51] <deni> i'm getting all kinds of mixed information
[11:51] <dpi_> so far, I tracked the problem to pageant and bazaar ... any1 can help me please ?
[11:51] <vila> so roughly you need to execute the right command which can be achieved either setting bzr_remote_path or tweak your authorized_keys file to execute a wrapper
[11:52] <jelmer> Riddell: btw, would now be a good time to ask for translations on the mailing list, or do you want to wait with that?
[11:52] <Riddell> jelmer: it needs to wait at least until launchpad has done the import
[11:52] <Riddell> but I'd also like to look at topic help and other translations first
[11:52] <Riddell> we need to consider adding string freezes to our release schedule
[11:52] <jelmer> Riddell: ah, fair enough
[11:53] <jelmer> Riddell: perhaps around the same time we do the API freeze ?
[11:53] <vila> deni: AIUI, *sftp* tweak the group bits, ssh now, it depends on what you ask it to execute (which is often hard to get right)
[11:53] <Riddell> jelmer: when is that done?
[11:54] <dpi_> okay, so either I'm mute or no one even cares to say "no, sorry, cannot help"...
[11:54] <vila> last beta for a series freezes the API
[11:54] <jelmer> dpi_: Hi
[11:54] <jelmer> dpi_: Sorry, I don't really have much experience with Bazaar on Windows.
[11:54] <dpi_> hi Jelmer, thanks I was starting to wonder if I was muted
[11:54] <dpi_> ;)
[11:54] <deni> vila: the bottom line is that neither sftp now ssh work the way they should
[11:54] <dpi_> no problem, thanks for answering
[11:55] <deni> i think that the best thing i can do is wait for the bug to get fixed....
[11:55] <deni> or try and look into it myself
[11:55] <deni> i don't want to fiddle aroung with workarounds that complicate things and confuse everything even more
[11:57] <vila> deni: well, AIUI, the most used setup is a server with a *single* user and an authorized_keys file so the issue you're encountering doesn't impact enough people to gather the energy to fix it :-}
[11:57] <deni> vila: ???? i think you got it very wrong....or you a making a joke
[11:57] <vila> deni: I've heard people using chmod and they seem to be happy with it, I guess it depends on how often you need to do it
[11:58] <deni> how do you think people colaborate if not via a shared server?
[11:58] <dpi_> ok, bye people
[11:58] <vila> deni: I'm just stating what I've heard here and from the bugs
[11:58] <vila> deni: no, I'm saying you can setup the server with a single user that everybody connect to
[11:58] <deni> this issues impacts every user of bazaar
[11:58] <deni> like every single one of them
[11:58] <vila> deni: like, not at all
[11:58] <deni> if they are working in some kind of team
[11:59] <vila> deni: launchpad uses bzr+ssh and there is no need for the sticky group bit
[11:59] <deni> vila: oh, ok...sorry i missed that in you statement somehow
[11:59] <deni> but the fact to use a single user for working with bazaar is apsurd
[12:00] <deni> what's the purpose a multiuser system then
[12:00] <vila> deni: the only known issue is indeed the group sticky bit, but AFAIK from the bzr code base, the umask is obeyed
[12:00] <deni> launchapd is a different story alltogether
[12:01] <deni> vila: nope....it's not just the issue with the group bit....that was just a workaroung
[12:01] <vila> deni: most people prefer to maintain a *single* authorized_keys file than a bunch of users
[12:01] <deni> the fact is that the umask is NOT obeyed
[12:01] <deni> that's the whole problem
[12:01] <vila> deni: well, bzr internally uses the python chmod which, AFAIK, obeys umask
[12:02] <deni> that makes absolutely no sense to me..... i have a machine on which there are many users.... all are in the same group...say development....
[12:02] <vila> deni: I understand the setup, I'm just saying it's not the most used
[12:02] <deni> i disagree
[12:03] <deni> i think we are gonna have to agree to disagree on this one
[12:08] <jelmer> Riddell: I think it's 4 weeks before the final release
[12:13] <vila> deni: right, looks like I started on the wrong foot, let's restart, what does 'ssh myhost umask' says in your case ?
[12:14] <Lo-lan-do> Hi all :-)
[12:14] <vila> Riddell: yup, as jelmer says, 4 weeks before final release (i.e. last beta which also freezes the API so plugin authors can do their releases for the series)
[12:15] <jelmer> hi Lo-lan-do
[12:15] <Lo-lan-do> jelmer: I think I've hit a bug in bzr-svn.  Before I report it formally, is there any more info needed beyond what's at http://pastebin.com/bS2yBghd ?
[12:15] <vila> Riddell: by the way, will it be possible to add more translations for minor releases (or is it not the way it works) ?
[12:15] <jelmer> Lo-lan-do: looks like bug 826946
[12:15] <jelmer> Lo-lan-do: what version of bzr-svn are you using?
[12:16] <Lo-lan-do> jelmer: 1.1.0~bzr3767-1
[12:17] <Lo-lan-do> jelmer: Not quite 826946: I get a traceback, and the commit fails, and I'm on svn+ssh://
[12:18] <Lo-lan-do> (But I've encountered something very like 826946 on an svn+https:// repo too, some time ago)
[12:18] <jelmer> Lo-lan-do: does that particular file exist if you look with "svn log -v" ?
[12:21] <Lo-lan-do> Not at the revision mentioned.  It's been renamed to fusionforge.pot about 3000 revisions ago.
[12:22] <Lo-lan-do> (a bit before the Branch_5_1 was forked from the trunk)
[12:22] <jelmer> Lo-lan-do: please file a bug
[12:23] <jelmer> I'm about to fix bug 826946 and then release 1.1.0; hopefully the fix for that one can make it into 1.1.1
[12:23] <Lo-lan-do> Okay.
[12:23] <Lo-lan-do> Thanks :-)
[13:25] <deni> vila: sorry i went away for a while... anyway....umask is set to 007
[13:25] <deni> i've made some progress btw
[13:25] <deni> u can make sftp use specific umask by setting so in the sshd_config....
[13:26] <deni> that affects only sftp though.....if i want to cover sftp, scp and ssh you have to use pam
[13:26] <deni> so i've set up 007 umask for ssh as well
[13:27] <deni> vila: now it works fine with bzr because like you said bzr+ssh doesn't execute bash and therefore does not read the settings in /etc/profile
[13:27] <deni> but setting this up in pam fixed the problem
[13:27] <vila> deni: \o/
[13:27] <deni> sort of anyway....now i'm stuck with all users having the default umask 007 which is not that great...
[13:28] <deni> to have new files in your home directory created with those permissions
[13:28] <deni> the good part is that the users ~/.profile or .bashrc file can override these settings
[13:28] <deni> if needed
[13:28] <vila> right, so the issue (AIUI) with *sftp* is that the bits we send are dropped by the server
[13:29] <vila> for ssh, it's still unclear to me where exactly the problem appears
[13:29] <deni> ssh did the same thing as well
[13:29] <deni> dropped the bits
[13:29] <vila> one trick would be to set bzr_remote_path to a wrapper that set the umask as you see fit *before* calling 'bzr serve'
[13:29] <deni> yep...
[13:30] <deni> several work arounds come to mind
[13:30] <deni> i've learned quite a few things about umask, sftp, ssh and pam so far :)
[13:30] <deni> that i dind't know before
[13:30] <deni> the whole setup seems a little messy but hey :)
[13:30] <vila> great, if you could add this pieces of wisdom to the bug report, that would be awesome :)
[13:31] <deni> sure thing
[13:31] <vila> thanks !
[13:32] <vila> deni: just to make sure I understood: you're saying that the group bits are dropped by the sftp server and that the profile is not taken into account when executing 'bzr serve' remotely ?
[13:33] <jelmer> the latter seems reasonable, isn't profile just for login shells?
[13:34] <vila> yup, just making sure I understand what tricked the unsuspecting users
[13:48] <Lo-lan-do> Is there a way to tell bzr to use some specific options for ssh?
[13:49] <Lo-lan-do> (I'm looking for options not in ~/.ssh_config, because I want to have them only for when bzr invokes ssh and not in the general case)
[13:50] <deni> vila: yeah i know, we established that already :)
[13:50] <vila> Lo-lan-do: from memory, because we support different ssh implementations, there is no way to specify options
[13:51] <deni> vila: ups....wrong channel sorry for the highlight
[13:51] <Lo-lan-do> Ah, I guess BZR_SSH would be it.
[13:51] <vila> Lo-lan-do: not even -vvv which will make connection issues debugging so much easier :-/
[13:51] <deni> vila: i've posted the info on the bug btw
[13:51] <vila> deni: thanks !
[13:53] <vila> Lo-lan-do: BZR_SSH only specify the shh client, but may be you can use a wrapper and inject options ?
[13:53] <deni> if i find out more i'll be sure to post.... although i don't think i'll come up with something better....atleast not without looking at the bzr code
[13:53] <vila> deni: where you'll find that we use chmod(0755) by default hence the bug about making it configurable
[13:54] <deni> vila:  :)
[13:55] <Lo-lan-do> Actually, it seems the option I wanted to pass is already used by bzr so I don't really need it :-)
[13:55] <Lo-lan-do> (I was looking for ControlMaster=no or some equivalent)
[14:19] <smoser> is it trivial for someone to kick the importer for http://package-import.ubuntu.com/status/qemu-kvm.html#2011-05-16%2017:12:45.463425 ?
[14:20] <smoser> is it ever trivial to kick the importer to get a package branch fixed?
[14:21] <jelmer> occasionally
[14:21] <jelmer> vila, maxb: ^ Does either of you know what's up with that one?
[14:22] <vila> not without digging but shooting in the dark:
[14:22] <vila> we've fixed some inconsistent delta bugs for 2.4
[14:23] <vila> so I'd rather update jubany to 2.4 ?
[14:30] <vila> jelmer: regarding bug #833097, does http://paste.ubuntu.com/674549/ looks like the kind of fallout from the API change ?
[14:30] <vila> others may be needed, I just want a quick go/no-go
[14:30] <vila> not a review ;)
[14:30] <vila> (yet)
[14:31] <jelmer> vila: yeah, looks like it
[14:31] <vila> k, thanks
[14:33]  * jelmer backports bzr 2.4 to python2.5
[14:36] <vila> jelmer: err, jubany has python 2.6 already, what do I miss ?
[14:36] <jelmer> some buildds are still on hardy :(
[14:36] <vila> :(
[14:38] <jelmer> doesn't seem too bad
[14:46] <vila> about pqm being slow, I tried various tricks with TMP on 5400 RPM disks, comparing with /tmp mounted as tmpfs, nothing comparable with pqm
[14:46] <jelmer> vila: do you know what might cause the doc strings to not be preserved on 2.5?
[14:46] <vila> -O ?
[14:47] <jelmer> nope
[14:47] <vila> I thought we preserver the needed ones by naming them __doc__
[14:47] <vila> preserved
[14:49] <vila> even disabling fdatasync doesn't makes such a difference on the whole test suite... I'm inclined to rule that out as a possible cause...
[15:04] <Merwin> Hey, I forgot to specify --fixes in my commit. How can I amend it ?
[15:04] <Merwin> (The problem is that I pushed my change to LP :D)
[15:04] <jelmer> Merwin: easiest is probably a new commit which does have --fixes
[15:04] <Merwin> ok ;)
[15:05] <Merwin> But i need t oedit something to commit :p
[15:06] <Merwin> (Ah, just discovered --unchanged)
[15:30] <vila> jam: I don't understand your comment on bug #832061, what do you mean with 'similarly' ? Except for the first option which I migrated myself, none of the others are configurable as in 'associated with a config option'
[16:03] <AdamdV> Hello, I'm trying to develop a bit of a web-interface for bzr (amongst other things), and I'm wondering problems I'll have keeping accurate commit history bc of bzr whoami. Because all the bzr commits will only be coming from one *system* user, (php) how can I keep an accurate commit history? Is there some parameter I can pass to commit to have it spoof the whoami, or do I have to unset and set it before each action?
[16:05] <smoser> is there a way to explicitly push tags ?
[16:05] <smoser> ie, i do something, commit, push
[16:05] <smoser> then tag
[16:05] <smoser> and if i push, i think it does nothing as i have no new versions
[16:06] <jelmer> smoser: bzr push (confusingly) only reports the new revisions it has pushed, while it does in fact update both tags and revisions.
[16:06] <jelmer> AdamdV: hi
[16:06] <jelmer> AdamdV: I would set "bzr whoami" to e.g. "mywebapp@`hostname`" and then specify --author to commit.
[16:09] <smoser> ah.
[16:11] <jelmer> smoser: there is a bug open about it, perhaps we should increase its priority
[16:11] <jelmer> bug 164450
[16:12] <jelmer> I'll set it to high, you don't seem to be the only one who is hitting it
[16:12] <jelmer> bug 164450
[16:15] <AdamdV> jelmer: Okay, that sounds like it will work. Thanks.
[16:21] <smoser> jelmer, well, clearly any bugs that affect me should be marked critical
[16:41] <jelmer> smoser: I think an awesome april fools joke for Launchpad would be to show all the bugs the currently logged-in user has reported as Critical
[17:48] <vila> jelmer, smoser: and assigned to him ;)
[17:48] <smoser> yeah.
[17:52] <fullermd> Or just reject bug 1 as an intended feature   :p
[18:04] <jam> vila: look at the code that I mentioned, all of them have config options.
[18:16] <vila> jam: great then ! That means less options to migrate/add
[18:18] <vila> jam: regarding locks, how about those pesky problems we had on windows where we still haven't manage to get useful feedback about pausing/retry (that should stay off by default) for example
[18:20] <vila> jam: the point is that even if it has always worked, being *able* to ask a random user to do a simple test will help, whereas asking him to write code have failed in the past
[18:21] <vila> jam: I fail to understand why you seem to be against such a goal :-(
[18:22]  * vila bbl, dinner time
[23:45] <AdamdV> What bzr * command can I use to get the current branch revision number?
[23:46] <jelmer> AdamdV: "bzr revno"
[23:46] <AdamdV> Great thanks