[00:00] shane4ubuntu: you can do that in ubuntu preferences. right? [00:00] ok, then you're safe [00:00] karni: I have all my files backed up, because u1 was eating my files randomly anyway. [00:00] you can remove your files from webUI or from a computer (or move them), that is still connected [00:00] and let it sync up the meta (so they'll get removed from the cloud) [00:01] shane4ubuntu: you will find scripts to remove your couchDB data from the cloud in the link from the topic [00:01] karni: I still have to un-subscribe my folders on the laptop, so I don't want to touch the WebUI for a few days, I will clean that up later. [00:01] shane4ubuntu: it's always good to make a backup, though, if you keep your contacts synced with couchDB or something. you know, so that you're safe [00:02] shane4ubuntu: when you disconnect all the machines, you can clean up under webUI, plus to remove logs [00:02] ok, but basically I can sudo apt-get -purge remove ubuntuone [00:02] shane4ubuntu: you'll find them under ~/.local/share/ubuntuone and desktop-couch [00:02] karni: ok, thanks! [00:02] shane4ubuntu: I think you could do that, yes [00:02] shane4ubuntu: mind you, I'm giving those instructions for the first time [00:02] shane4ubuntu: so the last thing I need is you loosing some data becase of me ;) [00:03] karni: lol, I do have my files backed up, so not to worry too much. [00:03] ok shane [00:03] shane4ubuntu: I hope you'll get back to U1 one day, when it's more rock solid and suits your needs [00:04] karni: I will be back, I'm just pretty disappointed in some stuff, I filed bugs, and everyone is too busy with other Ubuntu stuff to be dedicated to u1 [00:05] shane4ubuntu: it might be becase majority of the team was away for the last week, but I understand you. [00:05] shane4ubuntu: I hope you're bugs will get fixed soon, anyway :) thanks for your support and input [00:05] karni: I tried to help troubleshoot, but bug has been unattended for a while now, and I don't have time to mess with it if their isn't the interest in fixing it. [00:05] shane4ubuntu: that's appreciated [00:05] shane4ubuntu: i hope that'll change soon :) [00:06] karni: I appreciate the help that you have given, and I know others have helped as well, and it was appreciated, just don't seem to be making headway. [00:06] hello, is there a UbuntuOne music streaming app for iphone? [00:07] sircram: I'm pretty sure there is, but I might be wrong [00:07] duanedesign: ↑ [00:07] beuno: ↑ [00:08] I didn't see one in the appstore, so I was worried === nessita1 is now known as nessita === rodrigo__ is now known as rodrigo_ [09:05] hi [09:07] is something wrong with the u1 servers? [11:31] toros: hello [11:31] toros: still having an issue? [11:48] duanedesign: I will check it [11:50] kk [11:53] "WARNING - Connection lost: Connection to the other side was lost in a non-clean fashion." :( [11:53] I'll try to restart the u1sdtool [11:55] it is still rather slow... [11:59] the connection has been closed again :( [12:00] by the way, I had the same issue at home yesterday evening [12:00] with a different u1 account [12:10] hi [12:10] toros: hi there. Yesteday we were updating our servers, so the connections were dropped [12:11] toros: today, can you check in your log file if you have something like this? "ubuntuone.SyncDaemon.ActionQueue - INFO - The request 'protocol_version' failed with the error: [('SSL routines', 'SSL23_READ', 'ssl handshake failure')] and was handled with the event: SYS_UNKNOWN_ERROR" [12:11] toros: log file is located at ~/.cache/ubuntuone/log/syncdaemon.log [12:15] 2010-11-24 13:13:41,183 - ubuntuone.SyncDaemon.ActionQueue - INFO - The request 'protocol_version' finished OK. [12:16] any ideas with bug 558712/ [12:16] Launchpad bug 558712 in ubuntuone-servers "N900 fails to PhoneSync with error 401 (affects: 6) (heat: 18)" [Wishlist,Triaged] https://launchpad.net/bugs/558712 [12:17] beuno: would you have a pointer for hrw? [12:17] nessita: the syncdaemon starts syncing but after a while it drops the connection [12:18] it uploaded 3 files (out of 12) in 25 minutes [12:18] hrw, hi :) [12:18] the N900 isn't supported [12:18] (614 KB) [12:19] beuno: is there something other then gnomebuntu/androind/windows supported then? [12:20] toros: yes, we're currently debugging what is going on, we're getting similar disconnection ourselfves [12:20] beuno: saying 'n900 is not supported' is cheap. looking why it got http 401 is hard? [12:20] ourselves* [12:22] ohh, ok. thank you! [12:22] toros: thank you! [12:23] mandel or vds: would you be available for a review? [12:23] hrw, right, so, phone sync is provided by a third party application (funambol) [12:23] nessita: sure [12:23] hrw, we know it fails with N900's [12:23] it is a problem in the client implementation of syncml [12:24] beuno: scheduleworld also uses funambol but it syncs with n900 [12:24] with same app [12:24] hrw, right, we have escalated it to Funambol many times [12:24] hrw, the problem is outside of our code [12:24] vds: Thanks!!! https://code.launchpad.net/~nataliabidart/ubuntu-sso-client/split-gui/+merge/41369 [12:25] hrw, and our main focus is android and iphone, so no work on our part is going to go into other OSes [12:26] ok [12:30] FYI: A server-side issue has been discovered that causes the clients to disconnect after some period of time. We are working on diagnosing and fixing this issue at the moment. [12:31] rye: can I share this information on identica/twitter? [12:32] other people might be affected too... :) [12:35] toros, sending that message to !ubuntuone group @ identi.ca atm === teknico is now known as teknico_away [12:36] rye: thank you! [12:38] btw - how to get to ubuntuone filesystem from shell app? [12:40] sorry - found [12:41] u1sdtool ? [12:49] toros: rye: could you try to connect now and tell me how it goes? [12:53] I restarted the syncdaemon... let's see how it works [12:55] Hi all, honk, need help. I have a U1 installation which is messed up in that it hangs upon initialisation. we looked at that in the past together, but could not figure out what's going wrong. i'm about to leave for a longer trip and need u1 to work and do not have time for debugging. could i please have my account reset and start from scratch? [12:55] Chipaca, 'checking client version', [12:55] diverse_izzue, hangs upon initialization - during connection or when syncdaemon starts up? [12:55] diverse_izzue, if the first one - we are now looking into this since that affects all the users [12:56] rye, it's not a very recent problem, we looked at that a month ago or so but then i gave up on it and left it disabled since [12:57] rye, if i remember correctly it failed to crawl some of the folders, just started the daemon, will see what happens [12:58] rye, where are the logs again? [12:58] diverse_izzue, ~/.cache/ubuntuone/log/syncdaemon.log [12:58] 2010-11-24 13:57:45,182 - ubuntuone.SyncDaemon.ActionQueue - WARNING - Connection lost: Connection to the other side was lost in a non-clean fashion. [12:58] 2010-11-24 13:57:45,177 - ubuntuone.SyncDaemon.StorageClient - INFO - Connection lost, reason: [Failure instance: Traceback (failure with no frames): : Connection to the other side was lost in a non-clean fashion. [13:05] btw - U1 music store is available only by banshee or are there other methods? [13:10] rye, so far it doesn't fail in the way it did earlier on, but disconnects very often, is that the issue you say you are investigating? [13:10] diverse_izzue, exactly [13:10] hrw: Also from within Rythmbox [13:10] ok, so not for me - kubuntu [13:10] * JamesTait throws another 'h' in there. [13:13] rye, so basically this seems to be a bad point in time to try and figure out my other issue... [13:17] hi all [13:19] hi al [13:19] hi alecu* [13:19] alecu: so, how can I help you? [13:19] (btw, you forgot to do the review yesterday?) [13:20] nessita, oh, I forgot, yeah. [13:20] alecu: no problem I chased someone else [13:20] nessita, sorry. [13:20] :-) [13:20] nessita, is it already done? [13:20] yes, thanks [13:20] ok, great. [13:20] so, zeitgeist [13:21] I been looking at syncdaemon, and I'm trying to understand what would be the best place to log the events into zg [13:21] nessita, ^ [13:21] aja [13:22] nessita, so, it can be either at the time that SD events are sent to the event queue, or by subscribing to those events [13:22] nessita, also, I'm trying to think of a good layering to have SD not depend much on zeitgeist [13:23] alecu: what about: [13:23] nessita, but my first idea would mean having one function per logged event, and that does not scale. [13:23] so... [13:23] shall we mumble? [13:23] alecu: having a new module (even installable in another package?) that defines the handle_EVENT_NAME? [13:24] right [13:24] Chipaca, no, disconnecting as usual [13:24] alecu: we can certainly use some python power to avoid programming several handle_bla [13:25] nessita, what is the SD queue that was recently disabled because of performance issues? [13:25] http://marcin.juszkiewicz.com.pl/2010/11/24/ubuntu-one-good-or-bad/ [13:25] rye: right, we need to roll back to the previous version while we debug this. We're leaking memory all over the place for some strange reason. [13:25] alecu: hum, I'm not aware of any queue being disabled [13:26] alecu: I know content queue has an exponential growth in trunk syncdaemon [13:26] nessita, hmmm... what about some events (perhaps dbus events) that were disabled? [13:26] but is not disabled, afaik [13:26] twice today I have had "Temporary maintenance" page come up when i go to one.ubuntu.com/files - refreshing the page "fixes" it [13:26] oh, I heard some of that recently. perhaps verterok or facundobatista can shed some light? [13:26] alecu: I don't know about that either :-) shall we ping them? [13:27] alecu: maybe when they woke up? :-P [13:28] nessita, right. they must still be in Disney Time. [13:28] lucky them [13:28] nessita, so, a new module that listens for all (event/action?) queue events, and handle_SOMETHING them? [13:29] alecu: the listen setup is only one, no need to list events of interest [13:29] nessita, I assume that those events have the live syncdaemon objects passed into them, so we can fill up all zg fields. [13:30] alecu: and yes, handle_FOO. No syncdaemon object attached, just a few parameters [13:30] alecu: each event may have a particular set of parameters, you can find that listing in event.py [13:30] popey: Hi! We're having a spot of bother at the moment, see https://wiki.ubuntu.com/UbuntuOne/Status#Files [13:30] alecu: ubunutone/syncdaemon/events.py [13:30] lookin [13:30] ah, ok [13:31] alecu: sorry, event_queue.py [13:31] * nessita realizes that module should be named events.py :-P [13:31] for instance: 'AQ_FILE_NEW_OK': ('volume_id', 'marker', 'new_id', 'new_generation') [13:31] popey: We are working hard to rectify it, although I don't currently have an ETA. [13:33] alecu: yes [13:34] nessita, let's say I'm handling that event, and sending a zg "File was created on the server, syncdaemon creating locally" event. [13:34] nessita, zg needs the local path, and the current HD partition uuid. [13:34] nessita, is there a way to get at that info? [13:35] alecu: that we need to consult with chicharra team. But I wonder: can't we store custom info? [13:36] alecu: I mean, why would we need the HD partition uuid? [13:36] nessita, we can store custom info in zg events, but it would make no sense for the programs reading it. [13:36] alecu: can be leave some fields empty? [13:36] nessita, (the programs == "gnome-activity-journal") [13:37] nessita, and the aggregation program thisfred will be working on. [13:38] nessita, I wouldn't worry about the partition. I can get the partition if I can get at the local file uri. [13:38] alecu: can we leave fields empty? since in the case of U1, every single file/folder would be located under home [13:38] nessita, and that's a piece of info I think we *must* store. [13:39] nessita, then I can query the partition at the start of syncdaemon and cache it for the rest of the sd life. Don't worry about the partition. [13:39] nessita, let's worry about the filename [13:39] alecu: the path can be retrieved, yes, by accessing filesystem_manager [13:40] example is located at: (looking) [13:42] alecu: still looking :-) [13:43] alecu: can't find the code right now but you can query volume_manager [13:43] alecu: that module tracks the metadata for every node [13:44] nessita, alecu: hi [13:44] what are you looking for? [13:44] verterok: we would need the path of file/folder when handling events [13:44] nessita: which events? [13:44] verterok: and right now, the events pass the volume_id and node_id [13:44] verterok: can we access the path somehow? I'm thinking that volume_manager has that info [13:45] verterok: any event that involves a file/folder/share/etc [13:45] nessita: volume_manager only knows about volumes [13:45] nessita: what events? [13:45] verterok: any event that involves a file/folder/share/etc [13:45] bye [13:46] nessita: event is a bit fuzzy, a FS_FILE_CLOSE_WRITE, SV_FILE_DELETED, dbus signal? [13:47] verterok: we would track events for creation/deletion of files/folders both happening locally and remotly [13:47] verterok: so, we'll use SV_ and AQ_ levels, I think [13:47] nessita: ok, but those are two different things === teknico_away is now known as teknico [13:48] nessita: we now get deltas for the changes on the server, a fire the SV_FILE|DIR events internally (sync.py) [13:48] nessita: what are the AQ events? [13:48] *levels [13:48] verterok: we have no prior list right now [13:49] alecu: or do we? [13:49] verterok, would you mind taking a look at the index on this spec? https://wiki.ubuntu.com/UbuntuOne/Specs/ZeitgeistIntegration/EventsSpec [13:49] nessita, prior list? a list of prior events? [13:49] alecu: I mean, a list of events from event_queue that we will be using [13:49] nessita, not at all. [13:50] right [13:51] verterok: after a quick review, we would be interested in AQ_ and SV_ events [13:51] nessita: ok(?) [13:51] verterok: I didn't understand what you've said about generations and fire [13:51] nessita: mn [13:51] *nm [13:51] verterok: ideally, we would be defining new handle_BLA for the events we care about [13:51] nessita: a new subscriber with handle_EVENT_NAME [13:52] verterok: that stable-1-4 branch is just having the same build issue as trunk was, on narwhal. [13:52] dobey: k, thanks [13:52] verterok: and why did you resubmit the trunk branch; it was not necessary to do so [13:52] dobey: it was complaining about needing another review :/ [13:52] tarmac ^ [13:52] dobey: FYI, verterok reported bug #680719 and I assigned to you [13:52] Launchpad bug 680719 in ubuntuone-client "landing branches for stable-1-4 is broken! (affects: 1) (heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/680719 [13:53] nessita: please please, don't mix this thingy into a EQ existing subscriber :) [13:53] verterok: what? [13:53] verterok: we would be building a new module, that subscribes a new listener [13:53] verterok, you mean creating a separate subscriber, right? [13:53] yes [13:53] verterok: yes because you set it to approved before launchpad rescanned, so it tried to merge the old revision [13:53] I'ld like to be able to completely turn it off, with a config option [13:54] dobey: ahh, ok [13:54] verterok: ideally, we won't be editing existing code [13:54] verterok, yes. And we would shut that off it zg is not installed or if you have turned it off with an option. [13:54] alecu: :) [13:54] nessita: *ideally* [13:54] :) [13:55] ok, brb; must install a pci sound card [13:55] dobey: we have stand up in 5 [13:55] verterok, so, I heard about some events that were recently disabled for performance reasons. [13:55] (just FYI) [13:55] verterok, were those just dbus events? [13:55] nessita: standup or mumble? [13:55] dobey: I didn't get any invite [13:56] alecu: no, dbus_interface doesn't send events, it handle events and send signals :) [13:56] verterok, oh, right. [13:56] which makes me remember that Chipaca said he would be re-setting the weekly call [13:56] alecu: just to make it clear, let's name dbus stuff signals ;) [13:56] nessita: i thought we agreed last week to do the mumble meeting today this week, and thursday from now on [13:56] alecu: and the internal events: just events [13:56] dobey: we didn't set a time for today [13:56] verterok, so, I heard about some *signals* that were recently disabled for performance reasons. [13:56] nessita: but if it's not mumble then i will wait to fix my sound [13:56] irc i can do [13:56] dobey: let's have the standup in 4 minutes and schedule the weekly call [13:56] alecu: I'm not aware of such thing [13:56] dobey: thanks [13:57] alecu: we disabled sending a dbus signal for each internal event a long time ago [13:57] alecu: me neither. You heard from who? [13:57] alecu: because it's really slow [13:57] verterok, oh, it must be that. [13:58] * dobey tries to figure out what all he did yesterday [13:58] verterok, but it's only on the dbus level that was disabled, right? [13:58] alecu: dbus_interface.py line 520 [13:58] alecu: yes [14:01] grrrrrrrrrr [14:03] me [14:03] alecu, CardinalFang, thisfred, mandel, dobey, Chipaca: stand up? [14:03] vds: ? [14:03] me [14:03] me [14:03] nessita, didn't see your "me" [14:03] me [14:03] me [14:03] oh, just did. [14:03] me [14:04] alecu: there isn't an event for conflicts [14:04] nessita: please do not circumvent tarmac like that again. [14:04] dobey: I didn't, I ran tarmac locally [14:04] yes, you did [14:05] DONE: branches for bug #627496 and bug #677518, destopcouch reviews [14:05] TODO: build new package of ussoc, try to land natty package for u1cp, help alecu with zg [14:05] BLOCKED: nopes [14:05] NEXT: mandel [14:05] NOTES: tomorrow and Friday I'm not coming [14:05] you ran it locally because the one configured to land branches did not go exactly according to your desire. [14:05] Launchpad bug 627496 in ubuntu-sso-client (Ubuntu) (and 1 other project) "Registration screen looks cramped when big fonts selected (affects: 2) (dups: 1) (heat: 51)" [High,Triaged] https://launchpad.net/bugs/627496 [14:05] Launchpad bug 677518 in ubuntu-sso-client (Ubuntu) (and 1 other project) "Split gui code to allow other implentations (affects: 1) (heat: 817)" [High,Triaged] https://launchpad.net/bugs/677518 [14:05] regardless of how you did it, you did it. [14:05] DONE: add kwalet support, worked on windows code fr desktopcouch [14:06] TODO: file bugs regarding the above mentioned code (sorry) [14:06] BLOCKED no [14:06] * mandel looks at vds [14:06] meh [14:06] DONE: fixed the patch of python-couchdb to port the oauth session from DC to python-couchdb, code review, installing natty [14:06] TODO: land the branch for #675551, do some more porting to python-couchdb [14:06] BLOCKED: not at all [14:06] alecu: please [14:06] DONE: discussed on #zeitgeist bug #676090. Started working on bug #674252, a branch for review: https://code.launchpad.net/~alecu/ubuntuone-client/add-simple-zeitgeist/+merge/41667 [14:06] TODO: more discussion on the above two bugs, on #ubuntuone and on #zeitgeist [14:06] BLOCKED: no [14:06] Cardinalfang: the last to jump gets to code in C++... Geronimooooo!!!! [14:06] DONE: Bug #680929. Poked at zeitgeist to see how hard it would be to add to d-c [14:06] now; decided against for now. Got python-couchdb packaged and pushed to PPA; n [14:06] ot built yet. [14:06] TODO: Merges. Half day. Remainder this weekend, packaging. [14:06] BLOCKED: No [14:06] Launchpad bug 676090 in ubuntuone-client (Ubuntu) (and 1 other project) "Define the U1 Zeigeist ontology types for all events (affects: 1) (heat: 8)" [Undecided,In progress] https://launchpad.net/bugs/676090 [14:06] Launchpad bug 674252 in ubuntuone-client (Ubuntu) (and 1 other project) "Syncdaemon needs to store events into zeitgeist (affects: 1) (heat: 8)" [High,In progress] https://launchpad.net/bugs/674252 [14:06] Launchpad bug 680929 in desktopcouch "some tests run against personal couchdb (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/680929 [14:06] DONE: Stage #2 of bug 510159 TODO: wrap that up and start on the debian package split, and fix last small issues BLOCKED: no [14:06] Launchpad bug 510159 in desktopcouch (Ubuntu) (and 1 other project) "Split desktopcouch in two: a records library that can be used on the server and a desktop application/library (affects: 1) (heat: 8)" [Medium,In progress] https://launchpad.net/bugs/510159 [14:07] 1 sec brb [14:07] λ DONE: banshee backports (lucid), fixed 680501, 680593, 680553 [14:07] λ TODO: nightlies, banshee store tests, more releases [14:07] λ BLCK: None. [14:07] re [14:07] we need to set a time for the weekly call that would take place today [14:08] is one hour from now ok with everyone? [14:08] nessita, kind of bad for me [14:08] nessita, I need to have lunch [14:08] mandel: oh gosh, you may be starving [14:09] mandel: how long would you need? [14:09] at least spamassassin recognizes all google meeting invites as spam [14:09] nessita, not too much, 4:30 would be nicer :) [14:09] he's spanish, so he needs like 4 hours for lunch, you know [14:10] mandel, that's 1:20h from now, right? [14:10] mandel: 4:30 UTC? [14:10] nessita, yes [14:10] Chipaca: is that time good for you? ^ [14:10] what about the rest of the crowd? [14:10] mandel, that's not 1:20h from now! [14:11] nessita, if not, I can wait, no worries, dobey the spanish things is to have lunch late [14:11] ok, no big deal, we can have it in an hour [14:11] mandel: yes, and siesta after :) [14:11] it's 14:11 gmt now, right? [14:11] mandel: 1:30 from now you meant? or 4:30 UTC? :-) [14:11] ya me liado! [14:11] dobey, hahaha [14:12] ok, we do it when you said, I do not care about lunch or anything [14:12] when the planets are aligned in full eclipse [14:12] is a good time for me [14:12] mandel: 2 hours from now? [14:12] and that's my final offer :-P [14:13] nessita, cuando quieras [14:13] actually, 1:45 from now [14:13] I'll adapt [14:13] ok [14:13] that being 4pm UTC [14:13] nessita, so 5 CET [14:13] or something like that [14:13] alecu, CardinalFang, dobey, thisfred, vds, Chipaca: weekly call at 4pm UTC? [14:14] nessita, +1 [14:14] nessita: sure [14:14] +1 [14:14] okay. [14:16] nessita: +1, that's in 1h~45m right? [14:17] Chipaca: is there someone else having access to the "official" tarmac? we need someone else being able to access it if dobey is not around [14:18] what the hell does that mean? [14:18] it's a cron job [14:19] dobey: today tarmac wasn't landing a branch becasue it wasn't happy with the approvers (not sure why). I'm asking who else can debug this issue (or issues like this) when you're not around [14:19] alecu: question re your branch: with ubuntuone/syncdaemon/zeitgeist_log.py is a module inside syncdaemon? [14:20] you didn't ask ANYONE to debug the issue; and didrocks is not a member of ubuntuone-hackers, so launchpad sees his review as one from community. [14:20] alecu: shouldn't that be outside syncdaemon, at the same (project) level? [14:21] dobey: as far as I know you're the only one with access to tarmac, and I knew it was way too early for you. Could anyone else helped me? [14:21] nessita, yes, it makes more sense for it to go outside syncdaemon. fixin it [14:21] alecu: thanks [14:22] nessita: #tarmac perhaps. or you could have waited the hour or so for me to come on-line. [14:23] nessita, you are proposing to move it as ubuntuone.zeitgeist_log.py, right? [14:23] dobey: my point exactly. I think we need more than person being able to access tarmac. [14:23] nessita: and i don't even have "access" to all of the things being handled by tarmac [14:23] than one* person [14:24] nessita: the stuff in the DC is not directly accessible by me [14:24] it requires an admin [14:24] alecu: I was thinking on a separated module [14:24] alecu: like ubuntuone/zeitgeist/ [14:24] nessita: really, nobody should need to access tarmac. there is nothing with either of those two ussoc branches that having access to the machine running tarmac would have helped you to answer [14:25] dobey: so, for example, when we need to tweak a requirement like not every approver must be a u1hackers or similar, how do you usually fix that? [14:25] but circumventing the policies we're trying to enforce with tarmac, by simply running it yourself without the configuration, is not the correct course of action for any problem [14:26] dobey: can you please answer my question? [14:26] nessita: that requirement is not specifiyable in the tarmac config [14:26] dobey: where is specifiable? [14:26] you can not say "oh this one person is ok to review" [14:26] dobey: where is specifiable? [14:27] nessita: the isPersonValidReviewer() call on the Launchpad API's branch object for the target branch, is what determines if the review is valid for counting [14:27] dobey: why didrocks wasn't a valid person reviewer? [14:27] nessita: because he is not a member of the review team or branch owner (or team). [14:28] dobey: how can we solve this in the future? [14:28] (well, I reviewed more the functionnality than the integration in the code as I'll need it in the future) [14:28] nessita: you will need to more specifically describe the exact issue. [14:29] nessita: you could have gotten another u1-hackers person to review and approve it [14:29] dobey: I could, yes. I didn't see the point or gain on that [14:30] nessita: well it is our team's policy [14:30] dobey: it is? I wasn't aware of that [14:30] two reviews from team members, yes [14:30] the point is to cross-polinate knowledge of different parts of our code, across our whole team [14:31] dobey: ok then. I have another question: the other day you said "I'll disable this new plugin so your branch can land". How do you accomplish that? [14:33] nessita: the plug-in in question is only used if a certain option is available, and i disabled that option. but i was trying to get that plug-in working for us at the time, because it is a valuable plug-in to have, and i was actively working on making it work. that is a different plug-in, and we have been using the review count policy for quite some time now [14:33] dobey: where can the option be disabled? is a config file? where that config file is located at? [14:33] I just want to understand the picture [14:34] yes it's a config file. and obvioiusly it is located on the machine where tarmac is running [14:34] granted, we actually have two separate instances of tarmac running currently. [14:34] one in DC, and one I'm maintaining due to the interdependent nature of some of our projects. [14:35] nessita, so verterok tells me that files and directory events are not mapped easily from SD to ZG [14:36] verterok, let's try to focus on one event, so we can understand the rest. [14:36] alecu: I may be outdated... why not? I see we have AQ_FILE_NEW_OK, AQ_DIR_NEW_OK\ [14:37] alecu: not mapped to dbus [14:37] nessita, verterok says we can easily look at dbus_interface for shares and UDFs... and not so easily for the rest. [14:38] verterok, so, let's focus on "File was created locally, syncdaemon creating on the server" [14:38] alecu: right, so. AQ_[FILE|DIR]_NEW_OK [14:38] alecu: that means the file/dir was created on the server [14:38] verterok, ok, it means it was succesfully created on the server. cool. [14:38] ok, must get sound working again. brb [14:39] alecu: I think that maybe you're mixing DBus events with raw SD events [14:39] nessita, no, I'm not. [14:40] alecu: ok, so at bus level we have no notif of files and folders events, but at SD level we do have [14:40]