[00:00] <duanedesign> hey karni
[00:00] <karni> yo duanedesign
[00:01] <duanedesign> karni: who would know about tritcask? Did you say verterok wrote it?
[00:03] <karni> duanedesign: verterok is your man
[00:04] <karni> duanedesign: dude.. why would you be interested in *such* details, are you applying for a software engineer position at canonical :D ?
[00:04] <duanedesign> :)
[00:05] <duanedesign> karni: now i am trying to help a user with a traceback I have never seen before
[00:05] <duanedesign> File "/usr/lib/pymodules/python2.7/ubuntuone-client/ubuntuone/syncdaemon/tritcask.py", line 408, in iter_entries
[00:05] <duanedesign> fmap = mmap.mmap(self.fd.fileno(), 0, access=mmap.ACCESS_READ)
[00:05] <duanedesign> ValueError: mmap offset is greater than file size
[00:05] <karni> duanedesign: sounds interesting.  I will.  I'm bending the time-space-learning-curve at canonical, and still I have to give written assignments remotely related to programming itself. Who care's if the organizations structure is flat or tall, or what are the dependencies. I care that I do what I like, and I know I have my managers I report to. How complex is that :P
[00:08] <karni> Meh. I'll shut up, whining will get me nowwhere.
[00:09] <karni> *nowhere
[00:10] <duanedesign> sometimes it helps get it of your chest, so to speak :)
[00:11] <karni> Yeah
[00:36] <duanedesign> LP #657850
[00:36] <ubot4> Launchpad bug 657850 in ubuntuone-client (Ubuntu Natty) (and 5 other projects) "Ubuntu One Preferences applet doesn't display info properly (affects: 22) (dups: 5) (heat: 91)" [High,Fix released] https://launchpad.net/bugs/657850
[02:55] <adorilson> hi
[02:55] <adorilson> is possible run U1 on fedora 15 ?
[03:27] <Belxjander> Does the Ubuntu One Account Recovery service forcibly drop capital case letters in usernames ?
[03:27] <Belxjander> and if so... it will actually block my own username (first letter capital) from being completely usable with the service
[04:12] <GalahadForce> does anyone run a nvidia graphics card in here?
[04:12] <GalahadForce> after i installed mine it boots up out of range now
[04:13] <GalahadForce> any suggestions?
[04:13] <GalahadForce> on fixing it?
[04:13] <rmcbride> GalahadForce: you probably want a more general ubuntu channel. graphics cards and the Ubuntu One service aren't really related
[04:39] <dobey> GalahadForce: like rmcbride said; you might want to try plain #ubuntu
[04:39] <dobey> adorilson: i would say possible, yes; easy, no. :)
[09:00] <fagan> morning
[10:54] <adorilson> dobey, I will try
[10:55] <karni> Morning!
[10:56] <fagan> morning karni
[12:10] <duanedesign> morning all
[12:11] <fagan> morning duq
[12:11] <fagan> *duanedesign
[12:11] <fagan> :)
[12:11] <karni> hi duanedesign
[12:11] <fagan> [duq is much better as a name]
[12:11] <duanedesign> :D
[12:19]  * fagan break
[12:19] <fagan> (made a good bit of progress on what im doing just have some fiddly stuff I should ask about after break)
[12:35] <nessita> hello everyone!
[12:36] <fagan> morning nessita
[12:42] <jeroen-> rye: ping
[12:44] <rye> jeroen-, pong
[12:45] <jeroen-> oh hello rye
[12:45] <jeroen-> i was curious about the status of my files
[12:45] <rye> jeroen-, i do remember about the recovery and working with the developer to find out the proper way to recover the files
[12:46] <jeroen-> i understood the admins should be able to restore them, right?
[12:46] <rye> jeroen-, yes, the example file i gave you earlier is still allocated in the storage and databases but marked as inaccessible
[12:47] <jeroen-> rye:  well I really hope someone can fix this
[12:47] <jeroen-> rye:  if I must do something to speed uo the recovery, please let me know?
[12:48] <rye> jeroen-, i am extremely interested in this since it impacts the possibility to recover the files for everybody
[12:48] <rye> jeroen-, i have your email, should I need some more info from you I will send you a message
[12:49] <jeroen-> rye:  OK, thanks in advance for your help - I really appreciate your help
[12:50] <jeroen-> rye:  another interesting thing that it is possible that files can dissepear like this
[12:50] <rye> jeroen-, and I am very sorry for such kind of unpleasant experience with Ubuntu One, but I am doing my best to make it recoverable
[12:50] <rye> jeroen-, you might have removed metadata folders, in this case this is quite hard to say what happens
[12:51] <jeroen-> rye:  yes maybe, but still the files are gone :(
[13:07] <duanedesign> rye: good morning! Have you seen an error like this before? http://ubuntuforums.org/showthread.php?t=1775986
[13:07] <rye> duanedesign, oh
[13:08] <rye> duanedesign, no
[13:08] <rye> duanedesign, but something tells me that the file is of 0 length
[13:08] <rye> verterok, http://ubuntuforums.org/showpost.php?p=10923290&postcount=3
[13:08] <duanedesign> ahhh
[13:49] <fagan> standup in 10?
[13:50] <fagan> It seems like alecu and ralsina arent around and mandel is pretty quiet so he might not be around either
[13:54] <dobey> thems the breaks kid
[13:54] <nessita> of course stand up in 6'!
[13:54] <nessita> fagan: ralsina is off for the week
[13:54] <dobey> the cake is a lie
[13:55] <nessita> dobey: sometimes, yes.
[13:55] <fagan> nessita: oh
[13:55] <nessita> fagan: mandel should be working, and alecu is in a kindergarten meeting
[13:55] <fagan> nessita: I didnt know that I thought he was off till he got back to ar
[13:55] <fagan> nessita: ah ok
[13:56] <nessita> nopes, for the whole week, he's on holidays
[13:56] <nessita> :-)
[13:56] <fagan> so standup anyway with the like 3 or 4 of us
[13:56] <nessita> of course!
[13:59] <mandel> nessita: well I was wlaking the dog, but I have been working :)
[13:59] <fagan> very quietly
[13:59] <fagan> :)
[14:00] <fagan> moi
[14:00] <thisfred> me
[14:00] <nessita> mandel: how was the photo shooting last night?
[14:00] <nessita> me
[14:00] <dobey> me
[14:00] <fagan> mandel say me :)
[14:01] <nessita> alecu says:
[14:01] <nessita> DONE: got VS2008 compiling txnamedpipes, testrunner for it at https://code.launchpad.net/~alecu/txnamedpipes/run-tests-batch/+merge/64747 TODO: work on the tests broken on the qt+txnamedpipes branch BLOCKED: hopefully not today
[14:01] <nessita> mandel: me?
[14:01] <nessita> fagan: go
[14:01] <fagan> DONE
[14:01] <fagan> * Fixed most of the issues with my branch
[14:01] <fagan> * Did all of alecu's list I think
[14:01] <fagan> TODO
[14:01] <fagan> * Fix a failure and an error im getting. The failure I dont have a clue about but the error is an easy fix.
[14:01] <fagan> Blocked
[14:01] <fagan> * by stupidity
[14:01] <fagan> thisfred: gogo
[14:01] <mandel> me
[14:02] <thisfred> DONE: reviews | Bug #779851
[14:02] <ubot4> Launchpad bug 779851 in ubuntuone-client "Ubuntu One's Unity progress bar is uninformative when transferring a single file (affects: 2) (dups: 1) (heat: 23)" [Wishlist,Confirmed] https://launchpad.net/bugs/779851
[14:02] <thisfred> TODO same bug, whatever needs doing
[14:02] <thisfred> BLOCKED: no
[14:02] <dobey> λ DONE: bug $797870, reviews, discussions
[14:02] <dobey> λ TODO: expenses, fix more stuff
[14:02] <dobey> λ BLCK: None.
[14:02] <nessita> dobey: you in a hurry? :-)
[14:02] <dobey> mandel: go
[14:03] <nessita> DONE: bug #797411, bug #797294, bug #797860
[14:03] <nessita> TODO: finish up bug #797294, catch up with mandel re: SyncDaemonTool 4 windows, bug #798198
[14:03] <nessita> BLOCKED: nopes
[14:03] <nessita> NEXT: mandel
[14:03] <ubot4> Launchpad bug 797411 in ubuntuone-client "Extend SyncDaemonTool API (affects: 1) (heat: 389)" [High,Fix committed] https://launchpad.net/bugs/797411
[14:03] <ubot4> Launchpad bug 797294 in ubuntuone-control-panel "Implement preferences tab in the QT version (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/797294
[14:03] <ubot4> Launchpad bug 797860 in ubuntuone-dev-tools "Remove signals receivers as part of cleanup (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/797860
[14:03] <ubot4> Launchpad bug 798198 in ubuntuone-control-panel "Implement clicked callback for buttons that link to the web (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/798198
[14:03] <mandel> DONE: workd of the vm helper implementation onwidnows. All test were broken but I have  fixed them, I propose a merge but I push the wrong version will fix that so that it can be reviewd. Push the qt integration tests brach of txnamedpipes for alecu to work on.
[14:03] <mandel> TODO: finish sdtool for windows.
[14:03] <mandel> BLOCKED: no
[14:03] <thisfred> OH: I have to go to the dentist at 4, so I will be gone for an hour or so (7 hours from now)
[14:03] <nessita> dobey: my turn was after thisfred, you stole it from me! :-)
[14:03] <nessita> thisfred: ack
[14:03] <dobey> nessita: you went first!
[14:04] <nessita> dobey: no, that was alecu's standup
[14:04] <nessita> mandel: what bug # is the stdtool thingy?
[14:04] <fagan> heheh
[14:04]  * dobey bans standup-by-proxy
[14:05] <mandel> nessita: ah, I need to creat it
[14:05]  * fagan bans dobey making rules :D
[14:05] <fagan> (oh crap I cant make rules either)
[14:05] <dobey> go get me a danish
[14:05] <nessita> mandel: please do that before working on tasks. Please please please!
[14:05] <dobey> apple, with cinnamon
[14:05] <dobey> and a chai latte
[14:06] <fagan> dobey: yes sir that will take 4-7 working days
[14:06] <nessita> mandel: also, please make the bug reports for the rest of your pending tasks (and use the u1-zomg-windows tag). Thanks!
[14:06] <mandel> nessita: sure
[14:06] <mandel> nessita: when do we mumble?
[14:06] <nessita> mandel: as soon as alecu stops by
[14:07] <dobey> when you're in the pub
[14:07] <dobey> oh
[14:07] <dobey> mumble, the software
[14:07] <nessita> mandel: you need to have lunch?
[14:07] <nessita> mandel: hopefully you already had it :-) (is late there!)
[14:07] <mandel> nessita: yes, but it does not take me long, I'll put the pizza in the oven
[14:08] <nessita> mandel: I think you have at least 30 minutes, so enjoy
[14:08] <mandel> nessita: and spaniards have lunch very late, usually 2:30, 3:00 pm :)
[14:08] <mandel> nessita: I'll be paying attention to irc
[14:08] <fagan> mandel: isnt that because you are sleeping from 11-2
[14:10] <alecu> good morning, #ubuntuone!
[14:10] <fagan> morning alecu
[14:11] <mandel> fagan: I wake up at 7, so I doubt it
[14:11] <dobey> siesta is *after* lunch
[14:12] <alecu> mandel, got the branch, so I'll work on the tests right now.
[14:12] <fagan> ahhh
[14:12] <alecu> mandel, thanks!
[14:12] <nessita> alecu: hi there. We are having the windows catch up mumble after mandel has lunch
[14:12] <nessita> Chipaca: ^
[14:13] <alecu> nessita, perhaps we can start 10' before the standard thursday progress meeting. Or do it in the same meeting.
[14:13] <mandel> nessita: or we can have it now if is short (pizza in the oven)
[14:14] <nessita> alecu: I don't think we're having the standard thursday meeting, since ralsina is not around
[14:14] <nessita> alecu, mandel: now or later, as you both wish
[14:14] <nessita> I think is better now
[14:14]  * alecu is already on mumble
[14:14] <mandel> now :)
[14:15] <nessita> Chipaca: can you make it to mumble now?
[14:15] <mandel> nessita, alecu: I'm launching mumble right now
[14:16] <Chipaca> nessita: right now i have a web meeting
[14:16] <nessita> Chipaca: you prefer we waiting for you?
[14:16] <Chipaca> nessita: iwould, yes
[14:16] <nessita> Chipaca: how long is the web meeting?
[14:17] <Chipaca> nessita: dunno, martin isn't here so dunno
[14:17] <thisfred> you're gonna wait until he's back? :)
[14:17] <nessita> Chipaca: np. We 3 are in mumble, so just jump in when you're ready
[14:17] <dobey> Chipaca: you could just declare it over with :)
[14:17] <nessita> Chipaca: speak loud, since you need to beat The Cure singing in the back :-P
[14:18] <alecu> mandel, when you are done pizzaing, here's a branch that can use your review: https://code.launchpad.net/~alecu/txnamedpipes/run-tests-batch/+merge/64747
[14:18] <thisfred> nessita: I'm not gonna join, but if you guys need reviews or anything just tell me, I have work I can do, but I can easily be interrupted
[14:18] <mandel> alecu: cool, looking at it right now
[14:18] <nessita> thisfred: thanks!!!
[14:18] <dobey> thisfred: are you working on windows stuff?
[14:18] <thisfred> dobey:  not at all
[14:19] <mandel> alecu: why the double cd ..
[14:19] <alecu> mandel, because somehow cd ..\..
[14:19] <mandel> alecu: you could remember the location where you started the script and get back to it, which is nicer :)
[14:19] <alecu> did not work.
[14:19] <alecu> mandel, like pushd and popd?
[14:20] <alecu> mandel, I would do it, but I can't test it on xp to make sure it works, as I only have a seven vm
[14:20] <mandel> alecu: something like this: http://weblogs.asp.net/whaggard/archive/2005/01/28/get-directory-path-of-an-executing-batch-file.aspx
[14:20] <mandel> alecu: get the current dir of execution, store it in a var, move where ever you want, and then cd to the dir
[14:21] <mandel> alecu: but there is nothing interesting to it, you can leave it like it is :)
[14:21] <mandel> alecu: I was just asking :P
[14:21] <nessita> dobey: any news on the review for u1devtools?
[14:22] <dobey> nessita: i am looking at it right now
[14:22] <nessita> thanks
[14:22] <alecu> mandel, it seems that pushd and popd also work on seven's cmd.exe
[14:22] <mandel> alecu: wanna go down that path then?
[14:22] <alecu> mandel, but I would not worry about that, that script is a POS, and we'll probably be redoing it laters anyway when we have a jenkins running all this.
[14:23] <alecu> mandel, don't know if they work on xp
[14:23] <mandel> alecu: ok, we can forget about it, it work anyway :)
[14:23] <alecu> mandel, http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/pushd.mspx?mfr=true
[14:23] <alecu> mandel, they work on xp
[14:24] <mandel> alecu: could you take a look at the runtest script I did for SSO? there you can find the way to get the path to the pthon executable, your script will only work if the person already has it
[14:24] <alecu> mandel, sure. That's the kind of review I was expecting :-)
[14:25] <mandel> alecu: hehe
[14:25] <mandel> alecu: also reseting the python path to the previous value would be nice ;)
[14:29] <alecu> mandel, !!!!
[14:29] <alecu> mandel, in the run-tests.bat you use PYTHONPATH as the path to python, not to the libraries
[14:29] <alecu> mandel, that sounds very very troublesome.
[14:30] <alecu> mandel, I believe we should change that, or it will give us trouble later.
[14:30] <mandel> alecu: sounds reasonable, is just a s/PYTHONPATH/blahpath
[14:31] <alecu> mandel, I'll make a branch for that on -sso, don't worry.
[14:33] <mandel> alecu: thx!!
[14:34]  * mandel pizza eating
[14:35] <dobey> nessita: btw, how did you test such that add_signal_handler() created new dbus connections?
[14:35] <dobey> nessita: because i am not seeing that :-/
[14:35] <nessita> dobey: I'm not following, sorry. add_signal_handler where?
[14:36] <dobey> nessita: you were saying that we need to do this removing of signal handlers in the tearDown because it was creating new connections to the dbus daemon that weren't getting dropped on close(), no?
[14:36] <dobey> at lesat, that's what i understood from your comments yesterday
[14:37] <nessita> dobey: not exactly, what I said was: when creating a new signal  receiver, either using proxy.connect_to_signal or proxy.add_signal_handler (or similar name), that signal receiver adds a new entry in the self.bus.list_names
[14:38] <nessita> dobey: if you check the list_names content at tearDown, before flushing and closing, the signal hndler is there. It is removed when closing, but I think is more cleaner to explicitely remove it before closing
[14:39] <nessita> to avoid any possible timing issues, I'm not sure that self.bus.close() blocks until all the cleanup is fully completed
[14:39] <dobey> huh, so i am not seeing that behavior when i do self.bus.add_signal_receiver(); list_names() doesn't get bigger
[14:40] <nessita> dobey: try proxy.connect_to_signal()
[14:40] <nessita> where proxy is a dbus proxy
[14:50] <alecu> mandel, nessita, please review: https://code.launchpad.net/~alecu/ubuntu-sso-client/fix-batch-pythonpath/+merge/64834
[14:51] <nessita> ack
[14:52] <dobey> hmm
[14:56] <gord> hey guys, just wondering if there is any slowness on the network, seem to be syncing at around 3kb/s
[14:59] <fagan> alecu: I have that task list done ish and all of the commented out bits out of there
[14:59] <fagan> just have 1 failure and 1 error
[14:59] <dobey> nessita: still the list_names() is not growing for me
[14:59] <fagan> the failure I dont know how to fix though
[14:59] <alecu> fagan, nice
[15:00] <Chipaca> nessita: alecu: mumble?
[15:02] <fagan> Wow that was loud tunder
[15:02] <fagan> It was like outside my window
[15:02] <teknico> nature's trying to tell you something ;-)
[15:04] <fagan> teknico: yeah its saying im hungry feed me that dog thats barking next door
[15:05] <dobey> "nature says… stfu or gtfo"
[15:05] <fagan> hah
[15:07] <fagan> alecu: hmmm no failure anymore dont really know why that fixed itself but anyway. 2 errors that im not really sure what to do with. When you have some time could you look at i
[15:07] <fagan> *it
[15:07] <alecu> fagan, busy now, sorry.
[15:08] <fagan> alecu: yeah I know when you time no rush
[15:20] <nessita> dobey: not sure what to answer, it was for me. Even so, I'm not sure why you seem unsure to approve the branch, since removing the signal receivers is part of the expected cleanup, as far as I see.
[15:21] <dobey> nessita: why is it expected? because i didn't remove the list they get added to by some tests, to avoid breaking all those tests right off the bat?
[15:23] <nessita> dobey: by expected cleanup I mean: you create a file, is expected that tearDown will remove it. You create a listener, is expected that listener is unsubscribed. Same for signal receivers.
[15:23] <nessita> anyways, I don  have the time to argue about this
[15:23] <nessita> dobey: you can not approve, I'll see what we can do after the 24th
[15:24] <nessita> I meant: you can "not approve" it :-)
[15:32] <dobey> nessita: ok, i needinfoed it, and we can argue later :)
[15:32] <nessita> dobey: thanks
[15:33] <mandel> nessita: ping
[15:33] <nessita> mandel: pong
[15:33] <mandel> nessita: can you look at https://code.launchpad.net/~mandel/ubuntuone-client/working_windows_vm_helper/+merge/64804
[15:34] <nessita> mandel: yessir
[15:34] <mandel> when possible ofcourse
[15:34] <nessita> in about 15 minutes
[15:38] <alecu> mandel, please, review again the run-tests.bat branch, now based on your code and without hardcoding the name of the folder (it used to be build\lib.win32-2.7, but that name would surely change depending on platform and on python version)
[15:38] <alecu> mandel, https://code.launchpad.net/~alecu/txnamedpipes/run-tests-batch/+merge/64747
[15:38] <mandel> alecu, on it
[15:39] <alecu> mandel, this one too: https://code.launchpad.net/~alecu/ubuntu-sso-client/fix-batch-pythonpath/+merge/64834
[15:40] <mandel> alecu: runt-test-batch approved, shall I mark it as approved?
[15:41] <alecu> mandel, no need, just done it.
[15:41] <mandel> alecu: the other one is also ready to be approved
[15:41] <alecu> mandel, cool, thanks.
[15:41] <mandel> np
[15:42] <alecu> mandel, will tarmac merge txnamedpipes?
[15:42] <dobey> no
[15:42] <mandel> alecu: no, it has to be done manually
[15:42] <mandel> is a windows only project :(
[15:43] <dobey> but i want to fix that eventually
[15:58] <nessita> nrn
[16:03] <mterry> Heyo!  I am interested in porting ubuntuone-couch to use dh_python2 (as it came up in its MIR and the transition is a release goal).  Does anyone here know about efforts to convert the various ubuntuone packages?  I'm under the impression that they all need to be changed in lockstep?
[16:04] <fagan> hey mterry :)
[16:04] <mterry> fagan, hi!  :)
[16:04] <fagan> thisfred owns that according to lp
[16:05] <fagan> (the project not the porting thing)
[16:06] <dobey> mterry: yes, it is a somewhat difficult problem
[16:06] <thisfred> I own u1couch yes, but as to the concerted effort, I don't think so, yet. dobey?^
[16:06] <thisfred> Doesn't mean we won't though
[16:06] <thisfred> ah
[16:09] <mterry> thisfred, well, this is blocking my deja-dup MIR, so I have a vested interest.  Unfortunately, all the packages have to be done together
[16:09] <mterry> Is there any objection to me going through and working on that across the ubuntuone* packages?
[16:10] <thisfred> dobey: wherein lies the difficulty?
[16:10] <thisfred> I'd be happy to help, also
[16:10] <mterry> Note http://wiki.debian.org/Python/PythonSupportToDHPython2
[16:11] <mterry> But there was a question on #ubuntu-devel just now about how to prevent partial upgrades for a set of packages like this that is doing the transition.  I'm going to ask on the mailing list for input
[16:11] <dobey> mterry: i think if we should do it, we should do it in nightlies PPA first
[16:12] <dobey> and the hard part is ubuntuone-client, and i think there might be an issue with dh_python2 and the special .pth stuff we do
[16:12] <dobey> not sure though on that
[16:16] <mandel> nessita, alecu: I'll be away from 20 min
[16:16] <nessita> mandel: ack
[16:16] <alecu> bye mandel!
[16:16] <karni> nessita: Hi Nataly, could you please help me with this: http://paste.ubuntu.com/628024/
[16:16] <karni> nessita: I'm trying to call "authenticate" (not working from my Java source), but I can't instanticate SingleSignOnAPI
[16:16] <karni> it's complaining about BasicAuthorizer, which I took from piston-mini-client
[16:17] <nessita> karni: I never used the piston API, so I don't know what a piston SingleSignOnAPI is :-). You need to ask achuni or pindonga (they both are from ISD and in charge of that)
[16:17] <karni> nessita: ok thank you
[16:18] <nessita> welcome!
[16:19] <fagan> oh crap a plummer has come to fix my heating need to head off a bit early
[16:20] <fagan> alecu: the branch is at lp:~shanepatrickfagan/ubuntu-sso-client/nm-state-bug-fix get to it when ever you have time and send me an email. Ill get to it around 8pm UTC when im back
[16:20] <fagan> It should get to all of the things on that task list
[16:21] <fagan> be back a bit later then
[16:22] <alecu> fagan, if you are confident about it, propose it for reviewing, from the launchpad page.
[16:22] <fagan> alecu: not confident it still has errors that im not really sure on how to fix
[16:22] <fagan> Its the dbus stuff im pretty sure
[16:23] <dobey> off to get lunch, bbiab
[16:24] <fagan> the code is fine though and its working just something weird is going on. (I think I need to add a mock dbus thingy to a bit to fix it and I tried that but it didnt seem to work right so I pulled it and thats why im asking about it)
[16:24]  * fagan needs to use better english :)
[16:25] <fagan> anyway be back a bit later
[16:26] <thisfred> fagan: alecu: isn't there a proposed branch to fix that already? https://code.launchpad.net/~mterry/ubuntu-sso-client/nm0.9/+merge/63869
[16:26] <thisfred> or is this yet another nm related issue?
[16:27] <thisfred> oh nm, I think it is
[16:27] <alecu> thisfred, it seems to fix the same issue
[16:28] <alecu> thisfred, fagan started working on this branch before the london sprint
[16:28] <thisfred> I know
[16:28] <alecu> thisfred, so probably there's overlapping work
[16:28] <mterry> I made that branch without being aware of the other
[16:28] <thisfred> but continuing on this when it's already fixed seems not all that useful
[16:28] <alecu> I like mterry's solution though.
[16:28] <thisfred> me too :)
[16:29] <thisfred> So I suggest fagan abandons his, and finds a new issue to work on
[16:29] <alecu> thisfred, I think it's still useful for fagan to keep working on it even though it might not be merged, so he gets more familiar with our process.
[16:29] <thisfred> ok
[16:29] <alecu> thisfred, but if there's a better issue for him to work on... I agree.
[16:30] <thisfred> yeah, maybe finding one will take as much time as continuing down this path. I'll keep an eye out for more useful work
[16:33] <nessita> mterry: dobey made a branch for ussoc to refactor our tests in ussoc, so we can ask you to add more tests to yours without so much trouble
[16:33] <nessita> dobey: did you talk to mterry about the nm tests?
[16:35] <mterry> nessita, already in the branch
[16:35] <nessita> mterry: great! did you add the tests we were thinking on ask as well? :-D
[16:36] <mterry> nessita, I believe so (added tests for old states as well as new ones)
[16:36] <nessita> nice!
[16:36] <nessita> mterry: need a review?
[16:37] <mterry> nessita, https://code.launchpad.net/~mterry/ubuntu-sso-client/nm0.9/+merge/63869
[16:44] <mterry> thisfred, pitti just replied to my ubuntu-devel email about dh_python2 and shared a strategy for doing updates asynchronously.  So we could just update ubuntuone-couch and leave the rest.  I'm willing to do the work, but if you'd rather take it, that's fine with me
[16:45] <thisfred> mterry: It may be faster if you do it, but I'll make sure it gets reviewed quickly
[16:46]  * mterry looks at it
[16:46] <thisfred> just ping me with the proposal
[16:46] <mterry> thisfred, cool, thanks
[16:47] <mterry> thisfred, wait, what do you mean proposal?  It should just be a debian/ directory change.  Would you prefer to review that too?
[16:48] <thisfred> ehm, dunno. We have separate packaging branches for everything u1 I think
[16:49] <thisfred> which I don't know the review process for. dobey?
[16:51] <thisfred> ah, he's gone, anyway
[16:51] <thisfred> https://code.launchpad.net/~ubuntuone-control-tower/ubuntuone-couch/packaging-dailies
[16:51] <thisfred> is where the packaging branch lives for the nightlies ppa
[16:52] <thisfred> If you propose against that, we'll have a chance to test the change in the wild before proposing it for oneiric, I gues
[16:52] <thisfred> s
[16:54] <nessita> mandel: review finished, several needs fixing and needs information. PIng me back when those are fixed/answered. Thanks!
[16:54] <mandel> nessita: is that the u1-client branch?
[16:55] <nessita> mandel: yeah, the vm_helper
[16:55] <mandel> nessita: ok, let me fix those
[16:55] <nessita> I'll have lunch soon, after reviewing mterry's branch
[16:58] <Davideekejar> how do I access this from other pc's?
[17:01] <nessita> mterry: approved!
[17:01]  * nessita -> lunch
[17:01] <mterry> yay
[17:21] <dobey> nessita, mterry: i have a concern about a couple of the NM states and how we're using them
[17:22] <dobey> mterry: so my concern with only converting one thing to dh_python2 is that it will break everything else in ubuntuone, which i'd rather avoid :)
[17:22] <dobey> hrmm
[17:23] <dobey> mterry: so it should be ok in u1 stuff, theoretically; as we already do the magic .pth file stuff
[17:28] <dobey> nessita, mterry: added my concern about _SITE and _LOCAL states to the proposal
[17:30] <dobey> mandel: does working_windows_vm_helper replace provide_window_vm_helper?
[17:31]  * fagan back
[17:39] <mandel> dobey: yes, is there a problem with that?
[17:40] <mandel> dobey: tat sounds harsher that I intended :)
[17:42] <dobey> mandel: just making sure since you didn't request a review from me :)
[17:43] <dobey> and isn't hasattr() supposed to be evil and you shouldn't be doing that?
[17:43] <mandel> dobey: hmm is that the one that swallows exceptions?
[17:44] <dobey> i think so
[17:44] <dobey> and where you're using it, doesn't seem right anyway, but maybe i'm confused about share_id vs. volume_id in that use case
[17:46] <mandel> dobey: we have the same in the linux code: http://bazaar.launchpad.net/~mandel/ubuntuone-client/working_windows_vm_helper/view/head:/ubuntuone/platform/linux/vm_helper.py
[17:49] <dobey> mandel: eww
[17:50] <dobey> 80
[17:50] <dobey>     else:
[17:50] <dobey> 81
[17:50] <dobey>         share_id = share.id
[17:50] <dobey> when is that ever night the right thing to use? :)
[17:51] <nessita> dobey: when we build the share path, we use the share id to ensure path uniqueness
[17:52] <dobey> yes
[17:52] <nessita> isn't that what the code is doing?
[17:52] <dobey> but is there ever a time when share.id is not the correct thing to poke?
[17:52] <dobey> it's tryiing volume_id, then share_id, then id
[17:53] <dobey> all attribues on the share object (theoretically)
[17:53] <nessita> dobey: right, but the call is applied on different share objects
[17:53] <nessita> some are share offer, some other are shareresponse, and other is the share as a volume
[17:54] <dobey> ok, but still, hasattr() is evil, no, and we shouldn't be using it?
[17:54] <nessita> dobey: seems like it, though I keep using it as well...
[17:55] <nessita> googling now
[17:55] <dobey> why not do try:/except AttributeError:?
[17:56] <nessita> look!
[17:56] <nessita> a post from Cheepaca http://chipaca.com/post/3210673069/hasattr-17-less-harmful
[17:56] <nessita> dobey: in any case, we should not use try/except but : if getattr(instance, attr, None) is not None
[17:57] <dobey> hmm
[17:57] <nessita> I'm fine with asking changing hasattr to getattr() is not Nonw
[17:57] <nessita> None*
[17:57] <dobey> ok
[18:02] <mandel> dobey: which parameter did I have to pass to use the txnamedpipe reactor in u1dev tools?
[18:04] <dobey> mandel: --reactor=txnp iirc
[18:04] <mandel> dobey: ok, I remember it was something like that, I forgot the np :P
[18:05] <dobey> mandel: whatever the filename in ubnutone/devtools/reactors/ for the module is, is what you pass as the argument to --reactor= :)
[18:05] <dobey> for future easy lookup with ls :)
[18:05] <mandel> dobey: ok supperb, got it :)
[18:06] <mandel> nessita: I'm still looking at the exact answer for your need fixing in the u1client branch, but can you look at https://code.launchpad.net/~mandel/ubuntu-sso-client/use_txnamedpipes/+merge/61935 when ever you have time
[18:07] <mandel> nessita: needs to be merged so that we can us sso from the named pipes and not the ports
[18:07] <nessita> mandel: sure!
[18:07] <mandel> alecu: can you do the same: https://code.launchpad.net/~mandel/ubuntu-sso-client/use_txnamedpipes/+merge/61935
[18:07] <nessita> mandel: can I try it somehow?
[18:07] <nonelisted> Quick question for anyone that might know... looking for a way to change the UbuntuOne Control Panel login... there doesnt appear to be a option to do so, and I cant seem to locate the config file its drawing its information from...
[18:08] <mandel> nessita: the branch?
[18:08] <nessita> mandel: yes
[18:08] <nessita> nonelisted: what do you want to change exactly?
[18:08] <mandel> nessita: well if you were on windows you would be able to do runtest and see it running with named pipes.. but the vm is not ready :(
[18:09] <mandel> nessita: so I guess the answer in your case is no. I think alecu should be able to run the tests
[18:09] <nessita> nonelisted: there is no config file for the control panel, so I may be able to help you if you provide more details
[18:09] <nonelisted> nessita the UbuntuOne Control panel has the wrong login... need to effectively logout, and then login under the correct login, but there is no logout option in the control panel... nor can I find a config file
[18:09] <nessita> mandel: ok, then I'll wait alecu to review it
[18:09] <alecu> mandel will review it soon.
[18:09] <mandel> nessita: the namedpipes test are integration tests, that is does start a service and a client and test the full path, so they should state that it works :)
[18:10] <nessita> nonelisted: right, there is no such thing. If you logged in with the wrong username password, you should go to the devices tab and remove your current device
[18:10] <mandel> in theory (fingers crossed)
[18:10] <nessita> nonelisted: that will trigger a new request of username + password
[18:10] <nessita> mandel: "in theory"? were you able to tets it? :-D
[18:11] <nessita> nonelisted: try that and let me know how it went
[18:11] <mandel> nessita: yes, and it works, but since the tests are code, I always say in theory :)
[18:12] <mandel> nessita: god knows what can happen in the windows user land ;)
[18:12] <nessita> True
[18:12] <nonelisted> nessita: Sort of worked... basically it gets me to the "I have an account" page, but no new login dialog :-(
[18:12] <nessita> nonelisted: you should click in either "join now" to create a new account, or "I already have an account" to login with an existent account
[18:13] <candt> Hi there. I seem to have some very old files still in my u1 webstore from the early beta days. they are not showing in the web store app, but are still mentioned in my current logs.... I do not use u1 much. sync is not working properly. I favour getting admin to reset or force clean my u1 webstore, any suggestions please?
[18:13] <nonelisted> nessita: understood but upon clicking " I already have an account" the window dims slightly, and then returns to its normal active state
[18:13] <mandel> dobey: you can clearly write good email responses for stupid email threads ;)
[18:13] <nonelisted> nessita: in other words no login dialog
[18:13] <dobey> heh
[18:13] <nessita> nonelisted: seems like you're having a low level issue. Are you running our PPA nightlies?
[18:13] <dobey> mandel: i've been in the FOSS world a long time, so lots of practice ;)
[18:13] <nessita> nonelisted: if you don't know what that is, is ok :-)
[18:13] <nonelisted> nessita: nope
[18:14] <nonelisted> nessita: this machine is up to date on main branch
[18:14] <dobey> nessita: i bet he has a token in the keyring, but it's invalid auth from the server
[18:14] <nessita> dobey: nopes, he just removed the token
[18:14] <nessita> dobey: sso is not opening the GTK fialog
[18:14] <nessita> dialog*
[18:14] <dobey> nessita: check in seahorse, not the keyring :)
[18:15] <nessita> dobey: ENOPARSE
[18:15] <dobey> err, not the devices tab
[18:15] <dobey> EBRAINFART
[18:15] <dobey> s/keyring/devices tab/
[18:15] <nonelisted> nessita and dobey: you nailed it dobey.. just checked and the removal of the device did not remove it from keyring... just did and now it works
[18:15] <dobey> candt: you should open a support request on https://one.ubuntu.com/support/contact/
[18:16] <nessita> nonelisted: yey
[18:16] <nonelisted> nessita & dobey: appreciate the assistance... was killing me
[18:16] <dobey> nonelisted: no problem :)
[18:16] <nessita> that's why we're for (among other things, of course)
[18:18] <candt> @dobey thanks
[18:20] <mandel> dobey: that is what she said ;)
[18:23] <dobey> lol
[18:23] <mandel> nessita. alecu: will be at rugby beach for 1:30 min or so, will be back and will fix the u1client brach with nessita and dobey comments. Will also propose the branches for sdtool
[18:26] <nessita> mandel: ok
[18:26] <dobey> ok
[18:42] <dobey> oi
[19:30] <dobey> nessita, mterry: what are your thoughts on my last comment on https://code.launchpad.net/~mterry/ubuntu-sso-client/nm0.9/+merge/63869 ?
[19:31] <nessita> oops
[19:32] <nessita> dobey: what does it mean NM_STATE_CONNECTED_SITE?
[19:32] <mterry> dobey, I'd have to look at what local and site mean exactly in NM parlance.  If you can't reach one.ubuntu.com without GLOBAL, it makes sense to only look at that
[19:34] <mterry> or not u1 but the sso bits anyway
[19:36] <nessita> alecu: can you please do a review for me? https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/preferences/+merge/64883
[19:36] <dobey> nessita, mterry: _SITE means you have an on-site IP address (private range), and _LOCAL means you're on a .local network, and _GLOBAL means you can hit the internet, afaict
[19:36] <alecu> nessita, sure
[19:37] <nessita> dobey: then in that case your suggestion makes sense
[19:39] <dobey> of course, i have no idea how reliable that actually is :)
[19:40] <mterry> dobey, yeah, I agree.  I'll change the code.  https://secure.wikimedia.org/wikipedia/en/wiki/Site-local_address and https://secure.wikimedia.org/wikipedia/en/wiki/Link-local_address explain a bit
[19:44] <dobey> ok
[19:47] <mterry> dobey, nessita: branch updated
[19:50] <dobey> +1
[20:02] <alecu> mandel, ping me when you are back
[20:03]  * alecu has just seen all the _sso tests go green on windows
[20:03] <alecu> good job, mandel!
[20:06] <nessita> alecu: w00t?
[20:06] <nessita> :-)
[20:06] <nessita> alecu: any signs of the UI?
[20:07] <alecu> nessita, http://bit.ly/jlpvPU
[20:08] <nessita> alecu: not sure I understood what you mean
[20:08] <nessita> would you please rephrase?
[20:08] <alecu> "sign"
[20:08] <nessita> ah
[20:09]  * nessita realizes how that is supposed to be funny, and she laughs à la Sheldon
[20:09]  * alecu will stop making bad jokes. For 15 minutes.
[20:10] <nessita> :-)
[20:13] <thisfred> non-urgent review ( so: great if you can do it, don't do it if you are working on urgent stuff): https://code.launchpad.net/~thisfred/ubuntuone-client/better-progress-bar/+merge/64887
[20:13] <thisfred> there, I fixed it
[20:13] <dobey> rm -rf ?
[20:13] <thisfred> nope
[20:14] <thisfred> but there is some red in the diff :)
[20:15] <thisfred> It at least feels like it simplified things a bit
[20:15] <thisfred> but that may be because I just made it do what *I* wanted ;)
[20:16] <dobey> ugh, pep8 doesn't say anything about floats :(
[20:16] <thisfred> It's 100% TDD and glutenfree!
[20:17] <thisfred> do you prefer 0.5 to .5?
[20:17] <dobey> yes
[20:17] <thisfred> I'll gladly fix that,  I don't care about it
[20:17] <thisfred> doing
[20:17] <dobey> + def __init__(self, clock): # pylint: disable=W0613
[20:18] <dobey> why did you add that comment? because of your emacs thing?
[20:20] <dobey> + return float(done * in_progress) / (total * total_files)
[20:21] <dobey> is that float supposed to be () the whole thing, and not just the left half?
[20:21] <thisfred> dobey: 1. there is an unused variable there, which I suspect pylint *should* complain about
[20:21] <thisfred> 2. no
[20:22] <thisfred> one of the operands of the division needs to be a float
[20:22] <thisfred> if I cast the whole division to float it'll be 0.0 always
[20:22] <thisfred> assuming it comes out to less than 1
[20:22] <dobey> oh, or 1.0, i guess
[20:23] <thisfred> right
[20:23] <thisfred> I could cast both operands to float
[20:23] <thisfred> but it's not necessary
[20:23] <dobey> well it would round right, so 0.5 would be 1.0?
[20:23] <dobey> but anyway
[20:23] <thisfred> In python 3, everyone will have jet packs
[20:23] <dobey> it looks weird only casting the left part
[20:24] <thisfred> no it does not round, it just throws away the modulo
[20:24] <dobey> oh, weak
[20:25] <dobey> so the pylint W0613 i'm a bit concerned about
[20:26] <thisfred> well, there's cases to be made for either, this makes  / and % work nicely together. As I said, it's fixed in python3
[20:26] <thisfred> Ok, I can take it out if you want
[20:26] <thisfred> I  don't think we check it, but I think we should
[20:26] <dobey> we don't use pylint on u1client, no
[20:26] <thisfred> oh right
[20:26] <dobey> for various reasons
[20:26] <thisfred> all very good ones, I'm sure
[20:27] <thisfred> ok, it's out
[20:27] <dobey> well, actually, i'm thinking we should just switch everything to pyflakes, and burn pylint in a drum by the river
[20:27] <thisfred> fine by me
[20:28] <thisfred> though I think this is something that maybe should be added to pyflakes then
[20:28] <dobey> so i'd rather avoid adding more ugly pylint comments with arbitrary spacing
[20:28] <dobey> maybe, what are the actual warning messages?
[20:28] <thisfred> Won't happen again, squire
[20:29] <thisfred> WARNING W0613 pylint:Unused argument 'clock'
[20:29] <dobey> a nod's as good as a wink to a blind bat
[20:29] <dobey> oh
[20:29] <dobey> yeah, unused arguments suck
[20:29] <dobey> does it go away if you set it as a default arg?
[20:30] <dobey> self.clock = PatchedClock()
[20:30] <dobey> weak
[20:30] <dobey> i think that should be clock=PatchedClock, and self.clock = clock() perhaps
[20:31] <dobey> or something like that, or just remove the arg, since it's in a fake object
[20:31] <thisfred> well, it might be instantiated by code that expects the original signature
[20:31] <thisfred> since we're patching it in
[20:31] <thisfred> anyway, it's test code, I can live with it
[20:31] <dobey> ok
[20:32] <dobey> the other's not in test though
[20:32] <dobey> 401+ def _timeout(self, result): # pylint: disable=W0613
[20:32] <thisfred> also removing
[20:32] <thisfred> but yeah, it's again understandable: we don't control the signature of the callback I guess
[20:33] <thisfred> r1007 has them gone
[20:33] <dobey> right
[20:33] <dobey> cool
[20:34] <thisfred> This branch was total TDD win: It greatly helped me make incremental changes with confidence that I would have broken everything with if I'd done them all at once
[20:35] <dobey> but at some point you just have to stick the needle in someone's arm, and see what happens
[20:37] <alecu> thisfred, looks like a lovely branch. I can't review it right now, though :P
[20:37] <thisfred> np, as long as it gets in before final freeze ;)
[20:38] <dobey> thisfred: +1 and requested another review, since i think it's a 2-review branch
[20:38] <thisfred> yep
[20:38] <thisfred> I agree
[20:41] <dobey> am so tired
[20:47] <dobey> stupid clouds
[20:57] <nessita> alecu: ping
[20:57] <alecu> nessita, pong
[20:57] <nessita> alecu: I'm about to do changes to the devices widget, but then I realized I may generate a lots of conflicts for your branch On Hold
[20:58] <alecu> right
[20:58] <nessita> alecu: since we already have the twisted web client in trunk, shall we land your branch the same?
[20:58] <alecu> nessita, perhaps. It needs reviews though.
[20:58] <nessita> alecu: I can review it
[20:59] <alecu> nessita, https://code.launchpad.net/~alecu/ubuntuone-control-panel/more-devices-tab/+merge/63292
[20:59] <thisfred> gotta go to dentist
[20:59] <thisfred> bbiab
[20:59] <nessita> let's land this baby!
[20:59] <nessita> thisfred: good luck!
[21:00] <alecu> thisfred, have fun :P
[21:00]  * alecu pictures a scary saddist junkie dentist from thisfred neighborhood.
[21:01] <nessita> alecu: where is your branch taking the device list info from?
[21:03] <alecu> nessita, get_devices_info. "TODO: [...] this should be changed when have a working dbus replacement on win32"
[21:03] <alecu> so, it currently uses a SAMPLE_DEVICES_INFO dict that we need to get rid of.
[21:04] <nessita> ah... but... what do we need dbus for in devices tab?
[21:04] <nessita> isn't all that rest+web?
[21:05] <nessita> alecu: I mean, I think we should separate at backend level a call that only queries the device list, which is what we show in this UI\
[21:05] <nessita> meaning, provide separate device_info calls (different names, of course) so we use the dedicated on in QT. Anyways, we can land this as is and I can take over
[21:06] <nessita> in a subsequent branch
[21:09] <alecu> nessita, backend.devices_info gets the bandwidth and notification settings from sd thru dbus, and adds that info to the "local device" in the returned dict.
[21:10] <nessita> alecu: right, that is what I said we should have 2 separated calls
[21:10] <alecu> nessita, that was why I decided to skip that call when building the qt ui.
[21:10] <nessita> "I think we should separate at backend level a call that only queries the device list" "Anyways, we can land this as is and I can take over"
[21:11] <alecu> nessita, perhaps. But if we have two calls we'll be breaking our current dbus interface
[21:11] <alecu> nessita, when we designed this we toyed with the idea of changing bw settings for remote devices.
[21:11] <nessita> alecu: why? I m not saying chaging devices_info, but building a new one devices_only_info (withe a better name)
[21:12] <nessita> and use that from QT, and leave the rest as is
[21:12] <alecu> nessita, we can do that with no problems. And yes, we can do it in a different branch :-)
[21:12] <nessita> we can change the implementation of devices_info internally to use devices_only_info, for example
[21:12] <nessita> yes
[21:13] <dobey> nessita: should i make a release of ubuntu-sso-client for oni, or do you want to?
[21:13] <nessita> dobey: if you have the time, you're welcome to :-)
[21:14] <dobey> ok, i will
[21:14] <nessita> alecu: so, I don't like the ControlPanel widget triggering the self.get_devices_info call and having the child updating. I think each widget should query the info it needs and it should be independent from the parent, that way we can reuse the widget outside a COntrolPanel parent
[21:15] <dobey> though i am unnaturally tired right now, so in a bit i will
[21:15] <nessita> alecu: I usually will mark this as Needs Fixing, though I don't want to block the branch since I need it.
[21:15] <nessita> suggestions?
[21:15] <alecu> nessita, suggestions: opening a bug to refactor that?
[21:16] <dobey> please don't have any emergencies that require me to do more than maybe rm -rf something tomorrow :)
[21:17] <nessita> alecu: fair enough
[21:17] <alecu> nessita, we'll need to do that perhaps for the installer. Or perhaps later if the installer does not use it.
[21:21] <nessita> alecu: done, and approved. Any luck with my preferences branch?
[21:23] <alecu> nessita, sorry, I have not gotten to it yet. I want to finish the tests for the branch mandel passed me this morning.
[21:26] <nessita> alecu: woudl you have any ETA on that?
[21:26] <nessita> would*
[21:30] <alecu> nessita, I'm fixing the last of five broken tests, after that I'll make sure no more tests are needed. I look forward to proposing the merge tomorrow morning.
[21:31] <nessita> ok, I'll seek more reviewers then, I would like to have this landed before I start working tomorrow
[21:39] <nessita> mterry: simple needs fixing for https://code.launchpad.net/~mterry/ubuntuone-client/nm0.9/+merge/63861
[21:40]  * mterry looking
[21:41] <mterry> nessita, oh yeah, forgot about that branch
[21:41] <nessita> mterry: ;-)
[21:41] <nessita> dobey: if you didn't eod'd yet, would you please also review mterry's u1client branch?
[21:42] <dobey> tests? :)
[21:42] <dobey> does that code currently have tests?
[21:42] <dobey> also, i'm not sure site/local should be treated the same here
[21:43] <dobey> especially if we're going to implement lan sync; but also not sure if we should treat them as offline until we do, or what
[21:44] <mterry> dobey, makes sense to treat them as offline until that functionality exists
[21:45] <mterry> dobey, I didn't see similar comprehensive tests like in ubuntu-sso
[21:46] <nessita> dobey: I agree with mterry, those are offline until we do
[21:46] <nessita> mandel: you back?
[21:47] <mterry> nessita, dobey: branch updated to handle them like disconnected
[21:49] <nessita> mterry: I'll approve after I run it IRL
[21:51] <dobey> ok
[21:53] <dobey> +1 from me
[21:53] <dobey> and i am off. see you all on monday :)
[22:00] <alecu> mandel, ping
[22:04] <alecu> nessita, did you get to discuss with mandel regarding the many uses of: "type(data) == type(False)" in the following branch??? https://code.launchpad.net/~mandel/txnamedpipes/add_qt_integration/+merge/61923
[22:04] <alecu> nessita, it looks awful and unneeded.
[22:04] <nessita> alecu: I did, and I request to change to, at least, type(data) == bool
[22:05]  * thisfred back
[22:05] <nessita> alecu: he insisted we need to check that data was a bool
[22:05] <nessita> not only that data represented a true value
[22:06] <alecu> nessita, but it's "if data is not None or type(data) == bool"
[22:06] <alecu> nessita, so the "or type...." is unneeded. All of the time!
[22:06] <nessita> crap, is that so? I recall an and
[22:07] <nessita> alecu: having an or there surely makes no sense
[22:07] <nessita> if there was an and, that would be other story
[22:07] <nessita> alecu: checking for not None is enough?
[22:10] <alecu> nessita, I think that checking for None should be enough.... so none of that "type(xxx) == type(False)" makes sense.
[22:10] <alecu> but I'd like to check that with mandel, and see why he is doing things this way.
[22:10] <nessita> ok
[22:10] <nessita> makes sense
[22:10] <nessita> well, I'm off
[22:10] <nessita> see ya guys tomorrow
[22:11] <alecu> I'm off too.
[22:30] <thisfred> EOD, unless someone needs a review
[22:30] <thisfred> and that will be in an hour then
[22:31] <thisfred> after I walk the dog
[22:31] <thisfred> later  all
[22:47] <mterry> thisfred, I did propose a packaging branch for ubuntuone-couch dailies, btw
[22:47] <mterry> thisfred, https://code.launchpad.net/~mterry/ubuntuone-couch/packaging-dailies-dh-python2/+merge/64870
[23:29] <thisfred> mterry thanks! I'll review that


[10:23] <head_victim> Just some market research for you in case you get questions on the topic, it would appear Edubuntu runs reasonable enough on P4s (around 3.0 ghz) without needing to change the window manager. Surprised me to be honest.
[10:40] <alkisg> It runs on 1 Ghz P4s too, with 768MB RAM.


[06:00] -queuebot:#ubuntu-release- Unapproved: udisks2 (mantic-proposed/main) [2.10.1-1ubuntu1 => 2.10.1-1ubuntu1.1] (core, i386-whitelist)
[08:07] -queuebot:#ubuntu-release- Unapproved: python-gssapi (mantic-proposed/universe) [1.8.2-1build1 => 1.8.2-1ubuntu<IP_ADDRESS>] (no packageset)
[08:08] -queuebot:#ubuntu-release- Unapproved: python-gssapi (lunar-proposed/universe) [1.8.2-1build1 => 1.8.2-1ubuntu<IP_ADDRESS>] (no packageset)
[08:12] -queuebot:#ubuntu-release- Unapproved: python-gssapi (jammy-proposed/universe) [1.6.12-1build2 => 1.6.12-1ubuntu2.1] (no packageset)
[09:49] -queuebot:#ubuntu-release- Unapproved: accepted python-gssapi [source] (mantic-proposed) [1.8.2-1ubuntu<IP_ADDRESS>]
[10:19] -queuebot:#ubuntu-release- Unapproved: accepted python-gssapi [source] (lunar-proposed) [1.8.2-1ubuntu<IP_ADDRESS>]
[10:59] -queuebot:#ubuntu-release- Unapproved: rejected udisks2 [source] (mantic-proposed) [2.10.1-1ubuntu1.1]
[11:25] -queuebot:#ubuntu-release- Unapproved: python-gssapi (jammy-proposed/universe) [1.6.12-1build2 => 1.6.12-1ubuntu0.1] (no packageset)
[11:39] -queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (mantic-proposed) [45.2-0ubuntu1]
[11:39] -queuebot:#ubuntu-release- Unapproved: rejected python-gssapi [source] (jammy-proposed) [1.6.12-1ubuntu2.1]
[11:40] -queuebot:#ubuntu-release- Unapproved: accepted python-gssapi [source] (jammy-proposed) [1.6.12-1ubuntu0.1]
[11:43] <RikMills> ubuntu-release: please see: https://answers.launchpad.net/launchpad/+question/708661
[11:43] <RikMills> just for your FYI
[11:46] <ricotz> RikMills, hi :), I was about to ask about that ;)
[11:47] <RikMills> ricotz: if it help you, kconfig in proposed can be deleted
[11:47] <ricotz> it is about https://launchpad.net/ubuntu/+source/libreoffice/4:7.6.4-0ubuntu1/+build/27060284 , so it might help
[11:48] <RikMills> yes, that dependency issue would go away at least
[11:49] <RikMills> and I don't think libreoffice KDE code invokes the broken kdeconfig_compiler_kf5 in its code
[11:49] <RikMills> you previous libreoffice upload would have failed if it did
[11:49] <ricotz> so +1 for that mitigation
[11:49] <ricotz> ack
[11:50] <RikMills> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4979/+build/27045185
[11:50] <RikMills> that was started before the dep issue, and looks to be completing
[11:50] <RikMills> slowly....
[11:51] -queuebot:#ubuntu-release- Unapproved: accepted osinfo-db [source] (mantic-proposed) [0.20231027-0ubuntu<IP_ADDRESS>]
[11:52] <RikMills> ubuntu-archive: please remove kconfig from noble proposed, for the above reasons. thanks
[11:53] -queuebot:#ubuntu-release- Unapproved: accepted osinfo-db [source] (jammy-proposed) [0.20231027-0ubuntu<IP_ADDRESS>]
[12:00] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (mantic-proposed) [23.4-0ubuntu1~23.10.1]
[12:07] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (lunar-proposed) [23.4-0ubuntu1~23.04.1]
[12:10] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (jammy-proposed) [23.4-0ubuntu1~22.04.1]
[12:16] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (focal-proposed) [23.4-0ubuntu1~20.04.1]
[12:35] -queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (mantic-proposed) [0.58ubuntu0.2]
[12:37] -queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (lunar-proposed) [0.57ubuntu0.3]
[12:40] -queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (jammy-proposed) [0.52ubuntu0.6]
[12:41] -queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (focal-proposed) [0.43ubuntu1.15]
[12:43] -queuebot:#ubuntu-release- Unapproved: accepted distro-info [source] (mantic-proposed) [1.5ubuntu<IP_ADDRESS>]
[12:44] -queuebot:#ubuntu-release- Unapproved: accepted distro-info [source] (lunar-proposed) [1.5ubuntu<IP_ADDRESS>]
[12:45] -queuebot:#ubuntu-release- Unapproved: accepted distro-info [source] (jammy-proposed) [1.1ubuntu0.2]
[12:51] -queuebot:#ubuntu-release- Unapproved: accepted fonts-noto-color-emoji [source] (mantic-proposed) [2.042-0ubuntu<IP_ADDRESS>]
[12:52] -queuebot:#ubuntu-release- Unapproved: accepted fonts-noto-color-emoji [source] (jammy-proposed) [2.042-0ubuntu<IP_ADDRESS>]
[12:54] -queuebot:#ubuntu-release- Unapproved: accepted gnome-characters [source] (mantic-proposed) [45.0-1ubuntu1]
[13:01] -queuebot:#ubuntu-release- Unapproved: rejected open-vm-tools [source] (jammy-proposed) [2:12.3.0-1~ubuntu<IP_ADDRESS>]
[13:02] -queuebot:#ubuntu-release- Unapproved: rejected open-vm-tools [source] (lunar-proposed) [2:12.3.0-1~ubuntu<IP_ADDRESS>]
[13:10] -queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (lunar-proposed) [9.0.0-2ubuntu1.3]
[13:11] -queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (jammy-proposed) [8.0.0-1ubuntu7.8]
[13:15] -queuebot:#ubuntu-release- Unapproved: accepted libgcrypt20 [source] (jammy-proposed) [1.9.4-3ubuntu3.1]
[13:37] -queuebot:#ubuntu-release- Unapproved: udisks2 (mantic-proposed/main) [2.10.1-1ubuntu1 => 2.10.1-1ubuntu1.1] (core, i386-whitelist)
[13:49] -queuebot:#ubuntu-release- Unapproved: rejected dnsmasq [source] (jammy-proposed) [2.86-1.1ubuntu0.4]
[13:51] -queuebot:#ubuntu-release- Unapproved: accepted udisks2 [source] (mantic-proposed) [2.10.1-1ubuntu1.1]
[13:59] -queuebot:#ubuntu-release- Unapproved: libreoffice (mantic-proposed/main) [4:7.6.2-0ubuntu1 => 4:7.6.4-0ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[14:18] -queuebot:#ubuntu-release- Unapproved: firmware-sof (mantic-proposed/main) [2.2.6-1ubuntu1.2 => 2.2.6-1ubuntu1.3] (no packageset)
[14:25] -queuebot:#ubuntu-release- Unapproved: firmware-sof (jammy-proposed/restricted) [2.0-1ubuntu4.4 => 2.0-1ubuntu4.5] (no packageset)
[14:43] -queuebot:#ubuntu-release- Unapproved: accepted getmail6 [source] (jammy-proposed) [6.18.4-2ubuntu1]
[14:56] -queuebot:#ubuntu-release- Unapproved: accepted haproxy [source] (jammy-proposed) [2.4.24-0ubuntu<IP_ADDRESS>]
[15:01] -queuebot:#ubuntu-release- Unapproved: accepted haproxy [source] (focal-proposed) [2.0.33-0ubuntu0.1]
[15:07] -queuebot:#ubuntu-release- Unapproved: accepted openafs [source] (jammy-proposed) [1.8.10-1ubuntu2~22.04.1]
[15:09] <ricotz> mfo, hello :), did you get a second opinion and could you follow up on https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/2044019 ?
[15:09] -ubottu:#ubuntu-release- Launchpad bug 2044019 in libreoffice (Ubuntu Mantic) "[SRU] libreoffice 7.6.4 for mantic" [Medium, Incomplete]
[15:18] -queuebot:#ubuntu-release- Unapproved: accepted octavia [source] (focal-proposed) [6.2.2-0ubuntu1.1]
[15:49] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (focal-proposed) [1.11+20.04ubuntu1.1]
[15:51] -queuebot:#ubuntu-release- Unapproved: rejected libreoffice [source] (mantic-proposed) [4:7.6.3-0ubuntu<IP_ADDRESS>]
[15:52] <mfo> hi ricotz o/ i'm out today/monday. but yes, i asked someone for a second opinion right after posting the comment yesterday, and other members of the sru team can also check it during their sru vanguard shifts. thanks again for your promptness on it!
[15:53] <ricotz> mfo, I see, could you please ask someone to take a look or even take over this review?
[15:54] -queuebot:#ubuntu-release- Unapproved: update-manager (jammy-proposed/main) [1:22.04.17 => 1:22.04.18] (core)
[15:54] <ricotz> mfo, thank you for the detailed review, I have simplified the diff for easier understanding
[15:56] <mfo> ricotz, this is not assigned to me exclusively, it just happened i took it for review the last couple of weeks; please feel free to ping the sru vanguard of the day, by all means :)
[15:56] <mfo> (gotta reboot for some updates)
[15:59] <ricotz> tjaalton, hi :), I see you were already quite busy with SRU handling, would you still have time to take a look at libreoffice for lunar and mantic?
[16:11] <ricotz> mfo, thanks, I have done so
[16:11] <mfo> ricotz, you're welcome! o/
[16:18] <tjaalton> ricotz: yeah I'm getting done with my day
[16:19] <tjaalton> and really need to head out now
[16:30] <tjaalton> I'll have a look on Monday
[16:31] <ricotz> tjaalton, thank you
[16:52] <doko> https://tracker.debian.org/pkg/zope.interface  why is "autopkgtest for zope.component/5.1.0-1: ppc64el: Regression" still shown when 6.1-0.1 already succeeds?
[16:59] <doko> bdmurray: is there an update about the arm64 autopkg tests against unknown versions?
[16:59] <vorlon> doko: why are you asking here about the contents of tracker.debian.org?
[17:00] <juliank> you want #debci in oftc I suppose
[17:00] <juliank> or debian-release
[17:00] <doko> vorlon: oops, mismatch
[17:03] <bdmurray> doko: I'm testing a fix now
[17:05] <bdmurray> doko: but look the armhf queues are doing well!
[17:07] <doko> well, I don't see the point that all the stable queues are emptying faster than the development/noble queue.
[17:09] <bdmurray> glass half empty I guess
[17:13] <doko> Net gschimpft isch globt gnug
[18:15] <ricotz> vorlon, hi :), Rik_Mills requested the removal of kconfig in noble-proposed earlier
[18:15] <ricotz> which will unblock https://launchpad.net/ubuntu/+source/libreoffice/4:7.6.4-0ubuntu1/+build/27060284
[18:16] <ricotz> https://launchpad.net/ubuntu/+source/kconfig/5.112.0-0ubuntu2
[18:16] <tsimonq2> ricotz: This will likely block SRUs you do as well.
[18:17] <ricotz> tsimonq2, libreoffice builds on the new riscv64 builders
[18:23] <RikMills> tsimonq2:
[18:24] <RikMills> ricotz: yes, libreoffice doesn't seem to use that binary form kconfig in the build
[18:24] <RikMills> not all package that build depend on kconfig do
[18:52] <vorlon> ricotz, RikMills: kconfig removed from noble-proposed
[19:21] <vorlon> tsimonq2: um we're talking about risc-v here. A "porter box" is your own personal qemu.
[19:22] <vorlon> (we do need documentation about what version Launchpad is running and what commandline it's invoked with)
[19:22] <tsimonq2> vorlon: The RISC-V builds are done on QEMU, not Real Hardware? That slightly makes it easier.
[19:23] <tsimonq2> vorlon: I've set up launchpad-buildd before and I'm familiar; those extra docs would be perfect.
[19:23] <tsimonq2> (I think I've been told a few years ago they were all virtualized, but thought maybe that would have changed over the years, or something.)
[19:24] <vorlon> yeah, riscv64 hardware exists but we don't have any yet that's adequately server-grade and performant enough to run launchpad on
[19:24] <vorlon> there's a plan, but AIUI the hardware delivery has been pushed back
[19:24] <tsimonq2> Okay, that makes sense. Is it emulated on amd64?
[19:24] <vorlon> yes
[19:24] <vorlon> (though in principle the host architecture should be irrelevant)
[19:26] <tsimonq2> Got it. I'll try this tomorrow to see if I get anywhere, thanks!
[19:26] <vorlon> anyway, it was qemu before the move to bos03 and it's qemu afterwards, so figuring out what changed in the qemu in the process is very relevant!
[19:27] <vorlon> one difference AIUI is that the builders are now deployed via openstack instead of manually
[19:27] <tsimonq2> I suspect the Launchpad team documented that (and if they didn't before, they probably will now ;) )
[19:27] <tsimonq2> vorlon: What kind of difference does that make?
[19:28] <vorlon> tsimonq2: it means figuring out the actual commandline being used might have to involve getting an IS admin with access to the compute notes to empirically check what the commandline is
[19:28] <vorlon> (launchpad team are not admins on the cloud, they're tenants)
[19:29] <tsimonq2> Ah, right, I remember learning that (tenant vs admin) recently.
[19:30] <tsimonq2> Thanks again for your help - and if we do get that information, let me know, I'd like to give it a try too. :)
[19:32] <tsimonq2> Side note, generally for ubuntu-archive: I did https://launchpad.net/ubuntu/+source/language-pack-kde-en/1:19.10.0ubuntu2 and friends yesterday, and moved the Section from translations to localization per Debian Policy. I know when I've set up my local Launchpad instance with Soyuz that archive admins can override the section manually; my question is, is there some Automagic there or is that a
[19:32] <tsimonq2> manual move?
[19:33] <vorlon> sections are initially set from the control field in the package on initial publication; after that the sections can be managed by an AA with `change-override -x`, which pokes overrides into the launchpad db that are used for subsequent index generation
[19:34] <tsimonq2> Sounds good, I'll file a bug with the details and an AA can follow up there. Thanks again!
[19:37] <vorlon> tsimonq2: you are welcome to file a bug, but why do you care about the section at all?
[19:38] <tsimonq2> I don't, just figured I'd DTRT. :)
[19:39] <tsimonq2> (All of those are ancient debhelper 8 packages, so there is likely bigger fish to fry.)
[19:51] <vorlon> tsimonq2: nothing in Ubuntu cares about section, except for "metapackages".  There are likely to be a large number of discrepancies nowadays between the source packages and the archive.  And even if we reconciled them now, they'd drift again over time, given the way launchpad overrides currently work.  I don't think it's worth spending time playing whack-a-mole here
[19:51] <tsimonq2> vorlon: Sounds good, thanks for the info!
[20:20] -queuebot:#ubuntu-release- New binary: edubuntu-meta [amd64] (noble-proposed/universe) [24.04.3] (no packageset)
[20:20] -queuebot:#ubuntu-release- New binary: edubuntu-meta [arm64] (noble-proposed/universe) [24.04.3] (no packageset)
[20:20] -queuebot:#ubuntu-release- New binary: edubuntu-meta [armhf] (noble-proposed/universe) [24.04.3] (no packageset)
[20:20] -queuebot:#ubuntu-release- New binary: edubuntu-meta [ppc64el] (noble-proposed/universe) [24.04.3] (no packageset)
[20:20] -queuebot:#ubuntu-release- New binary: edubuntu-meta [s390x] (noble-proposed/universe) [24.04.3] (no packageset)
[20:21] <Eickmeyer> vorlon: ^ Working on a minimal install for edubuntu, this one actually has contents. Just needs an ack if you don't mind. :)
[20:22] <Eickmeyer> (I'll need to do another upload for the dependencies of the non-minimal seed to depend on the minimal)
[20:25] -queuebot:#ubuntu-release- New: accepted edubuntu-meta [amd64] (noble-proposed) [24.04.3]
[20:25] -queuebot:#ubuntu-release- New: accepted edubuntu-meta [arm64] (noble-proposed) [24.04.3]
[20:25] -queuebot:#ubuntu-release- New: accepted edubuntu-meta [armhf] (noble-proposed) [24.04.3]
[20:25] -queuebot:#ubuntu-release- New: accepted edubuntu-meta [ppc64el] (noble-proposed) [24.04.3]
[20:25] -queuebot:#ubuntu-release- New: accepted edubuntu-meta [s390x] (noble-proposed) [24.04.3]
[20:25] <Eickmeyer> ta
[20:27] -queuebot:#ubuntu-release- New: accepted python-pyasyncore [source] (noble-proposed) [1.0.2-0ubuntu1]
[20:29] -queuebot:#ubuntu-release- New binary: python-pyasyncore [amd64] (noble-proposed/none) [1.0.2-0ubuntu1] (no packageset)
[20:32] -queuebot:#ubuntu-release- New: accepted python-pyasyncore [amd64] (noble-proposed) [1.0.2-0ubuntu1]
[22:23] <ricotz> vorlon, hi, please could you reject the libreoffice SRU uploads in the lunar and mantic queues?
[22:45] <vorlon> ricotz: done
[22:46] -queuebot:#ubuntu-release- Unapproved: rejected libreoffice [source] (lunar-proposed) [4:7.5.9-0ubuntu<IP_ADDRESS>]
[22:46] <ricotz> vorlon, thanks!
[22:46] -queuebot:#ubuntu-release- Unapproved: rejected libreoffice [source] (mantic-proposed) [4:7.6.4-0ubuntu<IP_ADDRESS>]
[22:52] <vorlon> Eickmeyer: well we have yet to build an Ubuntu Studio image using livecd-rootfs >= 24.04.8, we might want that to happen and have someone test that it works before moving on to switching edubuntu
[22:53] <Eickmeyer> vorlon: Fair, but the MR is there anyhow. I probably should've started with Edubuntu since it's closer to Ubuntu Desktop than Studio is, although Studio will be a nice canary to see how a KDE Plasma desktop will respond.
[22:54] <vorlon> also, my understanding is that the ubuntu-desktop-installer snap is supposed to be extended so that flavors will provide it config rather than shipping a separate snap.  Are edubuntu-desktop-installer and ubuntustudio-system-installer intended to be temporary?
[22:55] <Eickmeyer> vorlon: No, that's simply not true. ubuntu-flavor-installer exists for that purpose. https://github.com/canonical/ubuntu-flavor-installer
[22:55] <vorlon> and how about I do PROPOSED=1 build of Ubuntu Studio so we get some results without waiting for migration
[22:55] <Eickmeyer> vorlon: Sounds good.
[22:56] <vorlon> Eickmeyer: so that directly contradicts what I was told, and making flavors build and maintain their own snaps for something that SHOULD be a simple matter of configuration is flaming garbage.  I'll follow up on this internally
[22:57] <vorlon> (but it's December, I'm actually already EOY, so this may not happen until January)
[22:58] <vorlon> tsimonq2: lubuntu-update-notifier SRU ping
[22:58] <Eickmeyer> vorlon: Sounds good. Yeah, I was taken aback too, but the structure of Github is nice in that dependabot keeps the internals of ubuntu-desktop-installer up-to-date automatically, Launchpad syncs it, and then it automatically builds a snap which is then uploaded to the edge part of the snap in the store, so it's not as bad as it *could* have been.
[23:03] <vorlon> Eickmeyer: here we go, something for debugging https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/noble/ubuntustudio/+build/544166
[23:04] <Eickmeyer> vorlon: That's an odd one. What would've caused that?
[23:05] <vorlon> Eickmeyer: something somewhere is causing things to be done prior to the ubuntustudio-dvd case block starting on line 866
[23:06] <vorlon> it's not immediately obvious to me what/where
[23:06] <vorlon> ah
[23:06] <vorlon>                 case $PROJECT in
[23:06] <vorlon>                         ubuntu-server|ubuntu-wsl|ubuntu-oem|ubuntu|\
[23:06] <vorlon>                         ubuntu-budgie|ubuntustudio)
[23:06] <vorlon> needs to be ubuntustudio-dvd
[23:08] <vorlon> livecd-rootfs 24.04.10 uploaded
[23:17] -queuebot:#ubuntu-release- New binary: golang-github-ghjm-cmdline [amd64] (noble-proposed/none) [0.1.2-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: haproxy-cmd [amd64] (noble-proposed/none) [0.0.2] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: golang-github-inetaf-tcpproxy [amd64] (noble-proposed/none) [0.0~git20231102.2862066-1] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: golang-sourcehut-rockorager-go-jmap [amd64] (noble-proposed/none) [0.4.4-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: jruby-mavengem [amd64] (noble-proposed/none) [2.0.1-1] (no packageset)
[23:20] -queuebot:#ubuntu-release- New: accepted golang-github-ghjm-cmdline [amd64] (noble-proposed) [0.1.2-1]
[23:20] -queuebot:#ubuntu-release- New: accepted golang-sourcehut-rockorager-go-jmap [amd64] (noble-proposed) [0.4.4-1]
[23:20] -queuebot:#ubuntu-release- New: accepted jruby-mavengem [amd64] (noble-proposed) [2.0.1-1]
[23:20] -queuebot:#ubuntu-release- New: accepted golang-github-inetaf-tcpproxy [amd64] (noble-proposed) [0.0~git20231102.2862066-1]
[23:20] -queuebot:#ubuntu-release- New: accepted haproxy-cmd [amd64] (noble-proposed) [0.0.2]
[23:46] -queuebot:#ubuntu-release- Unapproved: accepted firmware-sof [source] (mantic-proposed) [2.2.6-1ubuntu1.3]
[23:55] <deathcollege_> list
[23:56] <deathcollege_> not the right command sry