[00:43] <nacc> slangasek: doko: php-rrd failure is an obvious thinko in debian ... bug filed
[00:43] <nacc> Pharaoh_Atem: can you look at the php7.0 failures on armhf and s390x? (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html)
[01:10] <nacc> slangasek: doko: i think i can fix imagick, it looks to be another relatively obvious issue with debian's package, will work on it tmrw
[01:10] <nacc> but i think most of the php7.0 excuses are now covered
[06:09] <cpaelzer> good morning
[06:56] <pitti> Good morning
[07:51] <dholbach> good morning
[08:28] <LocutusOfBorg> good morning!
[08:34] <pitti> stgraber: oh, looking forward to learn what the replacement of lxc-clone/ephemeral will be :)
[08:56] <darkxst> dholbach, did it occur to you that its beta1 release eve, how was I going to pilot! anyway I moved it to next week ;)
[08:59] <dholbach> darkxst, I'm just putting together a rough schedule as a reminder
[08:59] <dholbach> if I took into account all local holidays, freeze dates and everything else, it'd take me weeks to put together :-)
[08:59] <dholbach> thanks for moving to another day
[09:00] <darkxst> dholbach, ha, yeh, didnt think of it like that ;)
[09:00] <darkxst> anyway no problem
[09:00] <darkxst> its been a bumpy beta1 ;(
[09:02] <dholbach> luckily there's still some time to fix bugs
[09:02] <darkxst> yes
[09:03]  * darkxst waiting on upload to migrate so I can re-spin images and hopefully fix 4 or so bugs
[09:09] <pitti> slangasek, infinity, doko, Laney: please be aware of http://bazaar.launchpad.net/~ubuntu-release/britney/britney2-ubuntu/revision/579
[09:09] <pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html is updated for that now
[09:09] <pitti> slangasek, infinity, doko, Laney: TL/DR: hinted regressions are now shown in yellow as "Ignored failure", so all red "Regressions" are "real"
[09:09] <Laney> pitti: nice
[09:10] <pitti> makes the output much easier to read, no more searching for the "ignored failure foo" 20 lines below
[09:10] <pitti> and makes retry-autopkgtest-regressions more useful
[09:10] <pitti> as it won't retry the known-failing ones
[09:14] <pitti> and e. g. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-numpy is much easier to read now
[09:29] <infinity> pitti: Nice.
[10:13] <StevenK>  /wii pitti
[10:13] <StevenK> Ah
[10:16] <doko> LocutusOfBorg, ping on llvm3.8 rc3?
[10:17] <LocutusOfBorg> ping sylvestre, I never packaged a new upstream release
[10:17] <LocutusOfBorg> I already pinged him about llvm-3.7
[10:27] <FourDollars> cyphermox: cjwatson: pitti: dholbach: mdeslaur: I would like to apply to become a MOTU. Could you help to endorse me on https://wiki.ubuntu.com/ShihYuanLee/MOTUApplication? Thx.
[10:28] <dholbach> FourDollars, sure, adding it to my TODO list :)
[10:28] <FourDollars> dholbach: Thx a lot.
[10:29] <LocutusOfBorg> https://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=email&sponsoree=fourdollars%40gmail.com&sponsoree_search=email
[10:29] <LocutusOfBorg> https://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=Shih-Yuan+Lee&sponsoree_search=name
[10:29] <LocutusOfBorg> FourDollars, ^^^ maybe you want to add them to the wiki page
[10:30] <LocutusOfBorg> so your sponsor knows what they sponsored to you :)
[10:30] <FourDollars> LocutusOfBorg: I leave http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=Shih-Yuan+Lee*&sponsoree_search=name on the wiki.
[10:31] <FourDollars> LocutusOfBorg: Please also check Ubuntu Sponsorship Miner <-
[10:31] <FourDollars> LocutusOfBorg: Maybe I should raise it up. Thx.
[10:32] <LocutusOfBorg> oh... I found it
[10:32] <LocutusOfBorg> sorry then :)
[10:33] <FourDollars> LocutusOfBorg: np. I should put it in the first line so people can easily find it.
[10:34] <LocutusOfBorg> I didn't change the link in my MOTU application
[10:34] <LocutusOfBorg> https://wiki.ubuntu.com/GianfrancoCostamagna/MOTUApplication
[10:34] <LocutusOfBorg> so it was "searchable" with find tool
[10:34] <LocutusOfBorg> :)
[10:36] <FourDollars> I see.
[10:37] <FourDollars> Let me refine my wiki page.
[11:42] <jamespage> infinity, changed my mind on using the dpdk binary by default as it also requires hugepages to be configured otherwise it borks
[11:48] <jamespage> cpaelzer, hey - are you working on the underlinking issue in dpdk?
[11:50] <cpaelzer> jamespage: yes
[11:51] <cpaelzer> jamespage: I have this one fixed along with a few others, there are some itches left
[11:51] <jamespage> cpaelzer, awesome! I've uploaded ovs with dpdk enabled and requested that ovs-dpdk be removed from the archive
[11:51] <cpaelzer> jamespage: if things go well I'll prepare an upload for review today - if not I hope tomorrow
[11:52] <cpaelzer> jamespage: I've seen the bug updates seeing dpdk pulled into main by that - huge thanks for that
[11:52]  * cpaelzer hugs jamespage
[11:52] <jamespage> cpaelzer, no problem - thanks for the dpdk work
[11:52] <jamespage> cpaelzer, I decided not to enable by default based on cpu features...
[11:52] <cpaelzer> jamespage: the underlinking itself will be fixed for sure, it is just not certain yet how much more I can fix in this one upload
[11:53] <cpaelzer> jamespage: so is it !default in general (because we are afraid of regressions) or is it "default = sse3 ? openvswitch-dpdk : openvswitch"
[11:54] <jamespage> cpaelzer, no - you just install openvswitch-switch and then switch between versions using alternatives
[11:54] <jamespage> so no extra package
[11:54] <jamespage> cpaelzer, its really ssse3 + hugepages configured correctly
[11:54] <jamespage> I guess we could do that but I'd rather make it a little more explicit for now
[11:55] <cpaelzer> jamespage: I clearly prefer not being the default as long as it needs to mature so much IMHO
[11:58] <jamespage> cpaelzer, agreed
[12:01] <jamespage> cpaelzer, https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/openvswitch
[12:02] <jamespage> I've updated the Vcs fields in the repo - they will go with the next upload
[12:04] <cpaelzer> jamespage: cool, I did the same for DPDK already which will be in the next upload as well (VCS)
[12:05] <cpaelzer> jamespage: btw the underlinking and other changes should (tm) not change anything for you or did you address the "static" linking in openvswitch-dpdk already?
[12:05] <jamespage> cpaelzer, I did for xenstore and pcap - but I hit a dl one when backporting atm
[12:05] <jamespage> (that's on 14.04 only)
[12:06] <cpaelzer> jamespage: ok we can try that with the new version then as soon as I'm done with it
[12:06] <jamespage> cpaelzer, ok
[12:10] <rbasak> doko: I'm going to drop the symbols file delta you added to libecap so it's just a sync. You hadn't sent that to Debian, and based on https://launchpad.net/ubuntu/+source/libecap/0.2.0-1ubuntu5 it looks like we're just ignoring any disappearing symbols anyway. Any objection?
[12:11] <rbasak> Also libecap is only used by squid. It's barely a shared library.
[12:11] <doko> rbasak, don't do that
[12:11] <rbasak> doko: OK, well can you merge libecap then please?
[12:11] <doko> rbasak, symbols files are a requirement for MIRs
[12:11] <rbasak> A symbols file that is useful, or a symbols file that is present only to meet the wording of a MIR and actually serves no purpose?
[12:11] <doko> rbasak, it belongs to the server team, so it's your task
[12:12] <doko> rbasak, why?
[12:12] <rbasak> It's only used by squid, so is barely a shared library at all. It might as well be static.
[12:13] <rbasak> And, when symbols disappeared, all we did was ignore them. The symbols file caught it, it FTBFS, and we update the symbols file to match.
[12:13] <rbasak> So what's the point?
[12:13] <hrw> hello
[12:13] <doko> and you mean just because you update squid every two years, it's not necessary?
[12:13] <hrw> can someone remove linux-chromebook from archive for me?
[12:14] <hrw> I am still listed as maintainer when no one is using this package and I do not even have hardware for it.
[12:14] <cjwatson> hrw: Could you file a bug against it with an explanation, and subscribe ubuntu-archive?
[12:14] <rbasak> I mean that the symbols file appears to be to be providing no benefit or protection, so is busywork for the sake of it and is pointless to do.
[12:14] <cjwatson> Gives us an audit trail
[12:14] <hrw> cjwatson: thanks, will do
[12:14] <rbasak> doko: if you disagree, then please explain how the symbols file could be useful in this case.
[12:15] <cjwatson> apw: ^- do you agree with hrw's request above, since you uploaded it yesterday?
[12:15] <doko> rbasak, it will remind you when a soname bump is needed, or a package rename is needed if upstream dops symbols without changing the soname
[12:16] <doko> and I probably didn't forward the patch to debian, because it was outdated
[12:16] <doko> debian had the new version for a long time
[12:16] <rbasak> doko: except that upstream dropped symbols without changing the soname, and we just updated the symbols file to match. See https://launchpad.net/ubuntu/+source/libecap/0.2.0-1ubuntu5. I know I did it in that case, but since that was the outcome, the symbols file didn't help us there.
[12:16] <apw> cjwatson, linux-chromebook, if you want it gone that makes my life easier -- i was simply trying to fix the module-init-tools deps i do not care about the package
[12:17] <hrw> cjwatson: https://bugs.launchpad.net/ubuntu/+source/linux-chromebook/+bug/1549782
[12:17] <doko> rbasak, so the savings is just for you, because you don't care to rename the package for these cases?
[12:17] <rbasak> doko: as I said, it is only squid that uses it.
[12:17] <hrw> apw: as the only maintainer of it I would love to see it gone ;d
[12:17] <rbasak> doko: and we don't know what the formal ABI is, anyway.
[12:17] <apw> hrw, works for me, it is anchient
[12:18] <doko> sorry, I don't get it why we have this discussion. no, you can't know if external software uses it
[12:18] <hrw> apw: it was when got added but at that time it was acceptable solution
[12:18] <rbasak> Which is fine, but what am I supposed to do when the symbols file flags an ABI difference?
[12:18] <rbasak> Everyone else seems to just change the symbols file.
[12:20] <rbasak> doko: because you don't care> and you didn't care to send the change to Debian, so what's the difference?
[12:20] <rbasak> doko: I'm just going to sync this, as I want to make progress and I don't see the downside. I'll take input from others if anyone else wants to chime in.
[12:21] <doko> rbasak, you're wrong. I couldn't send anything to debian, because the versions didn't match
[12:21] <rbasak> doko: unless you want to take the merge?
[12:21] <cjwatson> hrw: subscribe, not assign :)  (fixing)
[12:21] <hrw> cjwatson: long time since I used launchpad ;D
[12:21] <doko> rbasak, that's blackmailing
[12:22] <rbasak> doko: and you're just creating work for me with no justification.
[12:22] <rbasak> (I would really like someone else to chime in here, please)
[12:22] <rbasak> I'm happy to accept it if I'm wrong, but I would like someone to actually consider what I'm saying. I don't feel that you are.
[12:22] <rbasak> Look at the history of libecap uploads in Ubuntu.
[12:23] <rbasak> I have a symbols file here ready to go if needed, but given the previous history, I expect it to immediately FTBFS on other architectures and create more work to fix it.
[12:23] <cjwatson> hrw: done
[12:24] <hrw> cjwatson: thanks a lot
[12:24] <hrw> apw: thanks for reminding me (by upload) that this package still exists
[12:25] <apw> hrw, heh you are very welcome :)
[12:29] <pitti> doko, rbasak: IMHO, that changing of symbols files is merely the symptom -- the real cause is upstream not maintaining a stable ABI or properly maintaining their soname
[12:29] <pitti> doko, rbasak: so the only two sane options that I see are to either beat some sense into upstream for proper versioning, or drop the shlib and provide a -dev package with a static lib only
[12:29] <hrw> bye
[12:29] <rbasak> pitti: sure, I understand that. I think I'm saying that "maintaining" a symbols file in an Ubuntu delta is pointless.
[12:30] <pitti> if it's just one consumer, then there's little point to even pretend that it woudl be a generally usable library
[12:30] <pitti> rbasak: it's not
[12:30] <pitti> rbasak: if you build a shared library, you make a commitment and a promise
[12:30] <pitti> and if you don't want to keep that, don't build a shared library
[12:30] <rbasak> pitti: sure. Sorry, I mean in this specific case, not the general case.
[12:31] <rbasak> pitti: I mean "maintaining", not maintaining. We're just paying lip service if in reality we just update the symbols file every time symbols change.
[12:31] <pitti> rbasak: exactly my point :)
[12:31] <rbasak> That's what I'm saying is pointless. Given that we're doing this, why maintain the symbols file at all?
[12:31] <rbasak> I'll accept that not shipping a shared library the right answer, but unfortunately we're just downstream of Debian here.
[12:31] <pitti> it's not pointless, it's pointing you towards the real error: your library broke ABI
[12:32] <pitti> well, then file an RC bug against Debian and let it get auto-removed, or something
[12:32] <rbasak> I think the answer is: 1) stop creating extra work for ourselves, since that makes less time available to fix it properly; and 2) explain upstream and ask them nicely to fix it properly.
[12:32] <pitti> changing ABI without soname bump for sure is an RC bug, as it will cause squid to crash on partial updates, unless they manually craft their dependencies
[12:32] <doko> rbasak, pitti: In the of a static lib, you have to communicate to the security team, that thy need to update squid together with libecap. static libs come for a price as well. maybe you save some work, but you increase the work for others
[12:32] <pitti> but that's what a static library is for then
[12:33] <pitti> doko: *nod*
[12:33] <rbasak> pitti: incidentally the ABI change was historical and in libecap2. They've had a soname bump now.
[12:33] <rbasak> So I can't really file an RC bump now, seeing as they have bumped the soname.
[12:33] <rbasak> An RC bug that is.
[12:33] <pitti> rbasak: ah, if they did, what's the problem then?
[12:34] <pitti> on a soname bump it's totally legitimate to update the symbols files
[12:34] <rbasak> pitti: I feel that I'm recreating the symbols file again for no real reason.
[12:34] <rbasak> pitti: given the history of symbols files being arbitrarily changed.
[12:34] <pitti> well, changing symbols files without soname bump -> don't do that
[12:34] <pitti> changign symbosl files with a soname bump -> normal operation
[12:35] <rbasak> pitti: in fact I'd go a bit further and say that in general having a symbols file in an Ubuntu delta to meet MIR requirements is a bit pointless too for this reason. A stable ABI is for upstreams to maintain; we can't maintain that in an Ubuntu delta.
[12:35] <pitti> well, I disagree
[12:35] <rbasak> (like you said, it'a a symptom)
[12:35] <rbasak> If there is no symbols file, then that suggests that there isn't a stable ABI, and _that_ is the problem, not the lack of the symbols file.
[12:35] <pitti> if we have a package in main and want that to work properly, then things like symbols files are a great help to avoid breaking stuff
[12:36] <pitti> and an FTBFS due to symbols mismatch is infinitely better than having to scrape off apport crash reports after the fact
[12:36] <doko> rbasak, symbols files are part of the packaging, not about upstream
[12:36] <doko> some upstreams have symbol versioning
[12:36] <pitti> and if it's FTBFS due to a symbols mismatch, the consequence is *not* to just adjust the symbols file :)
[12:37] <doko> introducing tens of diffs dropping php swig support, and discussing a symbols file for 20min ...
[12:37] <rbasak> The problem with that is that without knowing the actual public ABI (as opposed to a list of symbols), we don't know whether the public ABI inadvertently changed or not.
[12:38] <doko> rbasak, sure, we should just drop all symbols files for that reason
[12:38] <pitti> well, *shrug*, you asked for another opinion, I gave it, not going to repeat it as that would just annoy you more :)
[12:39] <rbasak> pitti: I appreciate your opinion, thanks. Based on that I'll just add the symbols file and adjust for other archs if needed I guess.
[12:39] <rbasak> And I'll bring this up again if/when we get an FTBFS similar to the libecap2 ones.
[12:39] <pitti> rbasak: just to avoid doubt, that was for a soname bump, right?
[12:39] <rbasak> pitti: yes, libecap2->3
[12:39] <pitti> rbasak: and it's totally useful to send that to debian
[12:40] <rbasak> doko mentioned that he couldn't before due to some mismatch. How would I check for this?
[12:40] <pitti> arch specific symbols files are very rare for C; they are unfortunately the norm for C++, if it uses that
[12:40] <pitti> if you send the delta right after mering, that should by definition be current
[12:40] <pitti> merging, even
[12:40] <doko> rbasak, wrong. I said that we had an older libecap in the archive
[12:41] <rbasak> Ah, OK, thanks.
[12:41] <rbasak> http://paste.ubuntu.com/15196806/ is what I have right now.
[12:41] <pitti> ah, C++
[12:41] <rbasak> I used 1.0.1-2~ since -1 was prior to the gcc 5 transition
[12:41] <rbasak> So presumably the symbols were different then.
[12:42] <pitti> it often (but not always) works to demangle them, then one can often avoid the per-arch symbols files; but I don'thave too much experience with those
[12:42] <rbasak> Does that make sense for Debian? Or would that be wrong for them since they published libecap3 before the GCC transition also?
[12:43] <pitti> rbasak: Debian might need to adjust it then, but Debian has current g++ 5 now, so either way they need the current version of teh symbols
[12:43] <pitti> (they might need to rename it libcap3v5 then if the new g++ changed the ABI)
[12:43] <rbasak> OK, thanks.
[12:44] <pitti> (syncing that should be a no-op for us mostly, so we can do that if we want)
[12:44] <doko> rbasak, on a first look I don't see anything arch specific. it could be that some symbols are missing on ppc64el due to -O3.
[12:44] <pitti> these can be marked as (optional) then
[12:45] <pitti> particularly stuff which is not part of the real ABI, but just leaking from standard libraries
[12:45] <pitti> yay C++
[12:45] <doko> rbasak, this might help you, if there are too many architecture differences: http://pkg-kde.alioth.debian.org/symbolfiles.html
[12:46] <rbasak> doko: you mean I should use those tools? They're not KDE specific? I was looking at sed 's/ \(_.*\) \(.*\)/ (c++)"\1" \2/' libfoo.symbols | c++filt from https://wiki.debian.org/UsingSymbolsFiles
[12:46] <pitti> c++filt is nice indeed, makes these actually readable and less platform specific
[12:47] <pitti> :w
[12:48] <doko> rbasak, it's not KDE specific. you create a symbols file using pkgkde-symbolshelper create, then upload, download all the build logs and update using pkgkde-symbolshelper batchpatch
[12:48] <rbasak> OK, thanks.
[12:49] <doko> but the symbolshelper is not aware of the unmangled notation, afaik
[12:50] <rbasak> I'm finding this quite confusing. Lots of information from different sources rather than a single set of steps to follow. If I just use c++filt for now, will that be OK?
[12:50] <rbasak> Well apparently not, that just FTBFS.
[12:54] <doko> sure
[12:54] <doko> how does it fail?
[12:56] <rbasak> http://paste.ubuntu.com/15196904/ - I assume I'm doing something quite essential wrong.
[12:57] <doko> you're using c++ with the mangled names, not the unmangled ones
[12:58] <doko> at least for the first symbol
[13:00] <rbasak> The symbols file has unmangled names
[13:06] <doko> the missing symbol is unmangled
[13:06] <doko> I mean, mangled
[13:07] <rbasak> Ah
[13:07] <rbasak> Yes, that line does exist in my symbols file. Most of the lines are unmangled.
[13:07] <rbasak> Some seem to remain mangled.
[13:07] <rbasak> http://paste.ubuntu.com/15196979/
[13:08] <rbasak> Line 85
[13:09] <rbasak> That's the only one I see, so perhaps I could just leave that one mangled.
[13:09] <Laney> run it through c++filt and put that in its place
[13:10] <rbasak> c++filt seems to leave it unchanged
[13:10]  * Laney plays the x-files theme
[13:10] <Laney> so it does
[13:10] <doko> looks like a bug
[13:10] <doko> in the demangler
[13:11] <doko> or mangler
[13:13] <rbasak> I left that line undemangled, and the build succeeds.
[13:13] <rbasak> I guess that's OK to upload then? I'll clean up the merge first. Thank you for your help.
[13:14] <doko> sure
[13:16] <doko> rbasak, might be https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
[13:20] <rbasak> Thanks. I guess it's safe to just work around for now by not demangling that symbol?
[13:24] <pitti> infinity, Laney: I taught britney about force-badtest hints for a specific arch but all versions now: http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/1444
[13:25] <pitti> infinity, Laney: with that we enforce tests on the non-broken arches again, and don't have to constantly bump the versions for those
[13:25] <pitti> so please use that new syntax from now on
[13:32] <rbasak> Looks like i386 and powerpc failed. https://launchpadlibrarian.net/242789112/buildlog_ubuntu-xenial-i386.libecap_1.0.1-3ubuntu1_BUILDING.txt.gz
[13:33] <rbasak> Some extra symbols, some missing symbols.
[13:33] <rbasak> Should I just mark the missing ones as optional, and forget about the extra ones?
[13:34] <rbasak> doko: ^
[13:44] <doko> ahh, 32/64bit differences
[13:45] <doko> rbasak, is it intended that you build without optimization?
[13:46] <rbasak> doko: I haven't touched Debian's packaging in this area.
[13:47] <rbasak> Looks like the packaging just uses trivial CDBS.
[13:47] <doko> rbasak, I'll have a look, because it's likely that the symbols will change again with optimization
[14:19] <doko> mvo, does snappy build on powerpc?
[14:20] <doko> ohh, neither on s390x
[14:20] <mvo> doko: its fixed on s390x, I will upload the right today
[14:20] <mvo> doko: powerpc is a gccgo issue, I am not sure I can fix that myself
[14:39] <pitti> tseliot: hey Alberto, how are you?
[14:40] <pitti> tseliot: I have two other tiny bits for udev/trusty -- I suppose you want  bug 1536438 SRUed?
[14:40] <pitti> tseliot: would make sense to bundle those three
[14:42] <tjaalton> doko: do you know of a llvm bug where it doesn't detect avx support on skylake properly? mesa fails llvmpipe tests if built on skylake
[14:42] <tjaalton> with 3.8
[14:43] <tjaalton> apparently it has issues detecting what kind of avx support it has
[14:44] <doko> tjaalton, sorry, no.
[14:44] <tjaalton> alright
[14:54] <ahasenack> doko: hi, could you please take a look at https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1549819 ? It has a 6 line reproducer script
[14:54] <ahasenack> or point us at the current maintainer?
[14:56] <ahasenack> doko: a landscape-client unit test started core dumping like that in xenial
[14:56]  * doko stares at mvo ...
[14:59] <doko> ahasenack, could you check if a python-apt rebuild helps? we recently upgraded apt. juliank might want to comment too
[15:00] <doko> hmm,not rebuilt in Debian
[15:02] <ahasenack> doko: I'll try that
[15:02] <ahasenack> doko: also, do you know where I can find the core dump?
[15:02] <ahasenack> ubuntu@landscape-client-xenial:~$ ./foo.py
[15:02] <ahasenack> Segmentation fault (core dumped)
[15:02] <ahasenack> it's nowhere, not in /var/crash or $PWD
[15:02] <ahasenack> ulimit -c says unlimited
[15:03] <mvo> ahasenack: what doko said, a rebuild would be nice first, if that does not help I can have a look later
[15:04] <ahasenack> installing build deps...
[15:04] <mterry> mvo, looking at the ubuntu-snappy MIR, those golang packages don't have the right naming schemes.  Which means when Debian adds packages for them, we won't be in sync at all
[15:05] <mvo> mterry: uh, could you please comment in the bug so that I can sort it out?
[15:06] <tjaalton> doko: it's a mesa bug after all, was fine with 11.1 but 11.2rc breaks
[15:10] <ahasenack> mvo: it still core dumps after I rebuild and reinstall python-apt
[15:10] <ahasenack> mvo: it's inside a xenial lxd, if that matters
[15:11] <juliank> There's a bug somewhere in APT's cache generation
[15:11] <mvo> ahasenack: interessing, I get http://paste.ubuntu.com/15197818/ when I run your script
[15:11] <mvo> juliank: can you redproduce the segfault?
[15:11] <ahasenack> mvo: on a real xenial host, or vm?
[15:12] <mvo> ahasenack: real systemm
[15:12] <mvo> system
[15:12] <juliank> mvo: Have not tried it, but there's still some seg fault in the cache generation not fixed yet, so I'd love to get a complete backtrace
[15:12] <ahasenack> juliank: I can't find the core dump file
[15:12] <juliank> We probably missed a stringview that needs to be moved when the cache is moved
[15:12] <ahasenack> ulimit -c is unlimited, nothing in /var/crash or $PWD
[15:13] <juliank> Any service for core dumps installed? For example, I use systemd-coredump which stores them into /var/lib/systemd/coredump
[15:13] <juliank> there can be other handlers
[15:13] <ahasenack> let me check
[15:14] <ahasenack> that directory is empty here
[15:14] <ahasenack> I can remove apport
[15:14] <juliank> You could also run it in gdb if you have the debugging symbols available.
[15:15] <ahasenack> it's a python script
[15:15] <juliank> and how is that problematic?
[15:15] <ahasenack> still no core dump even with apport removed
[15:16] <juliank> Anyway, apt-cache gencaches should crash as well if you pass it a config file with -c that contains APT::Architecture "";
[15:17] <juliank> For mvo, it works correctly.
[15:18] <juliank> FTR, this is likely http://bugs.debian.org/812251
[15:19] <juliank> Try this reproducer: http://paste.ubuntu.com/15197886/
[15:19] <juliank> Of course, setting Architecture to an empty string won't work, but it should at least build a cache
[15:20] <ahasenack> juliank: that crashed here
[15:20] <juliank> Great
[15:20] <ahasenack> juliank: I'm trying to find all the dbg packages I need
[15:21] <juliank> Only interested in libapt-pkg5.0 ddeb
[15:21] <ahasenack> the bt isn't that great yet
[15:21] <ahasenack> http://pastebin.ubuntu.com/15197906/
[15:22] <juliank> I'm not sure where the dbgsym are in the archive, but this one should be it: https://launchpad.net/ubuntu/xenial/amd64/libapt-pkg5.0-dbgsym/1.2.3
[15:24] <juliank> But that seems like a bad place to crash in
[15:24] <tseliot> pitti: hi. Yes, I'd like that SRU. Where do I find the other changes?
[15:25] <ahasenack> juliank: ok, now I have something more
[15:25] <juliank> Do bt full
[15:25] <pitti> tseliot: it's bug 1473800 and bug 1535255
[15:25] <pitti> tseliot: but if you want I can upload the SRU for all three, your's is quite simple too
[15:26] <ahasenack> juliank: http://pastebin.ubuntu.com/15197953/ still a few "optimized out" bits
[15:26] <tseliot> pitti: yes, please
[15:26] <pitti> tseliot: ack, will do
[15:26] <tseliot> pitti: thanks
[15:28] <stgraber> pitti: lxc-copy
[15:28] <pitti> stgraber: ah, thanks; I didn't see an announcement yet on the homepage
[15:28] <juliank> ahasenack: I see. But it just crashes because you specified an invalid empty architecture there, AFAICT.
[15:29] <ahasenack> well, yes
[15:29] <juliank> But that's not really problematic.
[15:29] <pitti> stgraber: OOI, will lxc-clone remain in xenial? I wonder if I need to teach autopkgtest's lxc runner to get along with both, or whether it can just continue to call lxc-clone
[15:29] <juliank> Who specifies "" as an architecture in real life?
[15:29] <juliank> You told APT that your system has no architectures.
[15:30] <stgraber> pitti: we will keep lxc-clone and lxc-start-ephemeral around in Xenial, yes. Removing them now would cause too much breakage I think.
[15:30] <ahasenack> juliank: it's something that < xenial was ok with we had it as a unit test, and it started failing
[15:30] <stgraber> pitti: we'll likely get rid of them immediately after y opens though
[15:30] <juliank> ahasenack: This has to fail. But it should not crash
[15:30] <pitti> stgraber: thanks for the heads-up
[15:30] <ahasenack> right
[15:31] <juliank> It also does not fail on multi-arch systems
[15:32] <ahasenack> juliank: it seems to crash only on a container, though
[15:32] <juliank> because they'll have the secondary architectures set from APT::Architectures
[15:32] <ahasenack> juliank: that tells me something else is going on
[15:32] <juliank> Read what I wrote
[15:32] <ahasenack> irc lag, I'm sure you are used to it
[15:33] <mterry> bdmurray, can you add ~snappy-dev to your package-subscribers list?
[15:34] <juliank> ahasenack: Should be fixed in a few mins
[15:41] <juliank> Writing a test case now
[15:42] <ahasenack> juliank: thx a lot
[15:42] <ahasenack> I attached your reproducer and the bt full to the bug
[15:46] <bdmurray> mterry: yep
[15:47] <seb128> davmor2, cyphermox, those upgrade issues with fontconfig look like the binary is updated before the lib and the cache update fails on missing symbol, updating the libfontconfig shlibs would likely do the trick
[15:47] <mterry> cheers
[15:48] <juliank> ahasenack: Fixed in https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=9de2fd4
[15:49] <juliank> There will be a 1.2.4 release shortly
[15:49] <ahasenack> juliank: \o/
[15:49] <ahasenack> thx a lot
[15:50] <davmor2> seb128: nice, thanks
[15:50] <seb128> davmor2, yw
[15:54] <juliank> I'm still hoping I can reproduce (1) the other APT crash when building the cache and (2) the messed up index files sometime (part of last line is repeated)
[15:54] <juliank> Well, (2) might be fixed these days
[15:55] <juliank> (1) will be easy once there's a backtrace
[16:00] <cyphermox> seb128: ack
[16:13] <pitti> xnox: the cloud images are achingly fat, so it's quite a bit of a purge fest to minimize them
[16:13] <pitti> xnox: the images.linuxcontainers.org are much nicer, only 1/8th the size, faster, and minimal
[16:13] <pitti> xnox: right now I'm using the lxc "ubuntu" template which is similarly small
[16:13] <pitti> xnox: but anyway, I do have the purge list, I mostly just didn't get around to setting this up with lxd yet
[16:15] <xnox> pitti, horum. if they are "fat" we can trim them. I understood they have cloud-init + nested lxd, and that's it.
[16:15] <pitti> xnox: this morning I accidentally had cloud-init in a container, which completely breaks them :)
[16:15] <pitti> (although with lxc plain, maybe lxd has some provision for them)
[16:16] <nacc_> slangasek: so twig is unlikely to build (test) for a bit, as i think it triggers an actual bug in php7.0, which is then going to gate symfony and php-doctrine-bundle. Any recommendations? I've filed the PHP bug, but not sure how quickly it'll get looked at
[16:17] <pitti> xnox: ah, maybe the s390 ones are smaller? x86 cloud images have apt-xapian-index, cryptsetup, ureadahead, lxc, lxd, lvm2, mdadm, ppp, w3m, vim, and loads of other stuff that doesn't belong into a container
[16:20] <nacc_> Pharaoh_Atem: ping
[16:21] <rbasak> smoser: ^
[16:21] <rbasak> Also kirkland ^
[16:21] <rbasak> About "fat" cloud images.
[16:21] <rbasak> This comes up every so often. Either we want them to be slim or we want them to be "comfortable". We cannot have both.
[16:21] <Odd_Bloke> Doesn't belong in a container, but does belong in an Ubuntu-server-that-works-on-a-cloud image.
[16:22] <Odd_Bloke> Well, not all of those things, perhaps.
[16:22] <rbasak> There's also a goal to make the Ubuntu experience the same regardless of whether you're using a VM or a container.
[16:22] <Odd_Bloke> (Looking at you, ppp)
[16:22] <rbasak> This comes at the cost of having some stuff that doesn't make sense in a particular environment, but the win is that users don't get surprises switching from mode to another.
[16:23] <smoser> Odd_Bloke, ppp is gone i think
[16:23] <Odd_Bloke> Oh, cool.
[16:23] <smoser> yeah, i dropped hat a while ago.
[16:25] <smoser> cloud-image and server are now basically the same.
[16:25] <smoser> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.xenial/revision/2413
[16:25] <smoser> we also dropped wireless-tools wpasupplicant and memtest86+.
[16:25] <smoser> xenial cloud imags smaller than wily
[16:26] <smoser> thats the first reduction in quite some time.
[16:26] <pitti> rbasak: well, most container workloads shouldn't/don't have a "human experience"
[16:26] <smoser> i am absolutely not goign to say there is no fat. but i believe that just about everything in the seed is justifiable.
[16:26] <pitti> they should be managed completely automatically, and be as dense/efficient as possible
[16:27] <pitti> indeed, the x86 ones got trimmed recently, thanks for that; some 380 MB to 290 MB
[16:27] <pitti> but, container images are 65 MB
[16:27] <rbasak> pitti: I think there are a bunch of different desires that work against each other here. No single answer will suit everyone. A container you describe is certainly useful, but so is a fat one.
[16:27] <Odd_Bloke> pitti: Definitely; but that isn't what the cloud images are designed to be. :)
[16:27] <pitti> rbasak: sure, hence the need to have either two images, or a simple way to install the "comfy" bits
[16:27] <rbasak> pitti: ultimately kirkland has to balance whose things.
[16:28] <pitti> with a cloud-init option, or "apt-get install ubuntu-server-standard" or so
[16:28] <rbasak> those things
[16:28] <rbasak> AIUI, we don't ship the minimal thing you want right now, and I'm not aware of any plans to do so, apart from "core" as it used to be called.
[16:28] <pitti> with "one size fits it all" you either provide a really bad "interactive"  experience, or you penalize every container/juju workload by shipping tons of unnecessary stuff
[16:29] <pitti> rbasak: actually we do, I'm quite happy with teh images.linuxcontainers.org images
[16:29] <rbasak> Is it really a "penalize" though?
[16:29] <pitti> sure
[16:29] <Odd_Bloke> The argument for favouring the "comfy" use case is probably that anyone doing serious container stuff will be customising the images anyway.
[16:29] <pitti> it's 5x the download, HD size, unpack, upgrade size, plus the longer boot time etc.
[16:29] <rbasak> How expensive is it really?
[16:30] <rbasak> Right, but how expensive is _that_ really? :)
[16:30] <pitti> well, how expensive is "5x expensive" -- I'd say "5 times"? :-)
[16:30] <Odd_Bloke> rbasak: A major selling point for containers is density, so it does make a substantial impact in those terms.
[16:30] <pitti> (storage space)
[16:30] <pitti> it's less well defined for dist-upgrade and boot time of course
[16:30] <smoser> wasted processor use and memory are one thing, and we can and should make packages disabler themselves if they're not in an environment where they'd be used.
[16:30] <rbasak> It's mostly disk space. That isn't the bottleneck for container density, AIUI.
[16:31] <pitti> but it's much easier to install a metapackage to an "interactive" cloud workload where/when you actually need it (which should not be the common case)
[16:31] <rbasak> "5 times" more expensive is nothing if it's $0.00000001 to $0.00000005.
[16:31] <pitti> than maintaining an ever-growing list of packages to purge, as that's really error prone
[16:32] <pitti> well, here's the thing:
[16:32] <rbasak> "maintaining an ever-growing list of packages to purge" is just because your use case isn't currently supported, and what you're doing is a workaround.
[16:32] <pitti> if you say that 5x the download size isn't a noticeable penalty, what's wrong with enabling the apt-get install of a "comfy" metapackage when you enable it
[16:32] <pitti> as that'll download the same things, but much less often
[16:32] <rbasak> The time is a penalty when doing interactive work.
[16:32] <rbasak> It doesn't matter so much for non-interactive work.
[16:32] <rbasak> Developer time is what is most expensive.
[16:33] <pitti> well, as I said, I'm quite happy with the images.linuxcontainers.org images
[16:33] <pitti> rbasak: developer time> exactly
[16:33] <pitti> cf. "maintaining an ever-growing purge list"
[16:34] <pitti> I know how brittle and maintenance-intense it is because I'm doing it
[16:34] <pitti> I have to do it for x86/ppc64el images anyway, but I don't need to for the arches where I'm currently using LXC/LXD because these already have small images
[16:35] <pitti> anyway, this just started out as an explanation to xnox why I prefer the lxc images
[16:35]  * hallyn points rbasak to the cost of bandwidth over satelite :)
[16:35] <pitti> no doubt the classic "ubuntu server" experience shouldl have vim and stuff installed, as these are more geared towards humans
[16:35] <Odd_Bloke> hallyn: Ah, yes, the classic cloud use case. ;)
[16:36] <pitti> but "noninteractive container/VM" and "interactive server" are quite different use cases, and unifying them will always make people unhappy
[16:36] <Odd_Bloke> I guess it does potentially go through literal clouds...
[16:36] <hallyn> Odd_Bloke: i rest my case
[16:36] <rbasak> hallyn: if you're using satellite, you are presumably already caching the images. The one-off hit is still presumably insignificant.
[16:37] <rbasak> Anyway, I defer to kirkland. I understand there are use cases where "comfortable" is a pain.
[16:37] <rbasak> pitti: I don't think we're unifying them. We're just not doing the slim one right now.
[16:37] <pitti> the one package which is the most contentious one is probably cloud-init
[16:37] <xnox> Odd_Bloke, pitti - it's just lxd images are used as "full cloud images" in e.g. openstack-lxd. And they are also used as minimal bootstrap chroots in like "juju" case or the stuff you do.
[16:38] <xnox> imho there is room for more minimalistic lxd image.
[16:38] <hallyn> rbasak: i think the cost is wroth it, i just object to your over-trivialization of the cost :)
[16:39] <pitti> xnox: lxd images are fairly minimal, mostly debootstrap really
[16:39] <xnox> pitti, when i say lxd images -> i mean the lxd image we publish at cloud-images.ubuntu.com. not the stgraber image =)
[16:40] <sergiusens> barry, hey, is a fix for this coming soon http://paste.ubuntu.com/15198707/
[16:40] <pitti> xnox: ah, let's call them "cloud images" to avoid confusion
[16:41] <xnox> ack.
[16:42] <sergiusens> barry, there are many other conflicts that follow the same pattern
[17:01] <pitti> tseliot: I uploaded systemd to trusty-proposed with all three patches; can you still add an SRU test case to bug 1536438 please?
[17:02] <pitti> tseliot: I meant, uploaded to the SRU review queue, of course (~ubuntu-sru still needs to review/process)
[17:03] <barry> pip 8.0.2-8 should fix those
[17:05] <rbasak> doko: thank you for the libecap fixes.
[17:06] <doko> rbasak, I'll forward these once they are visible in the release pocket
[17:06] <rbasak> doko: appreciated
[17:12] <tseliot> pitti: sure, I'll do it tomorrow. Thanks
[17:50] <seb128> bdmurray, arges, sru_team: is there anything blocking the wily libreoffice update to be accepted? it was supposed to be a 0 day SRU at the beginning but seems it's stucked there forever now
[18:00] <bdmurray> seb128: I don't know but will have a look.
[18:04] <seb128> bdmurray, thanks
[18:08] <bdmurray> seb128: it looks like wily had a security update recently :-(
[18:09] <marlinc> My GRUB broke since the latest updates, not sure why. Getting 'error: sparse file not allowed' while booting. It then jumps into the UEFI menu
[18:09] <marlinc> The only way get it to boot is to press esc so it goes into the actual GRUB screen instead of trying to boot immediately
[18:11] <bdmurray> seb128: also fonts-stix is in universe in wily but was added to main for xenial. would that need to change?
[18:11] <seb128> bdmurray, oh, right, going to need to rebase ... or discard at this point, I'm unsure it's still worth it but I'm just wondering for the record what went wrong and why it's ignored by the SRU team since octobre
[18:11] <seb128> I guess it would
[18:13] <jdstrand> bdmurray: hey-- I wouldn't normally mention this since it has only been a couple of days, but the trusty squashfs-tools sru is important for snappy
[18:13] <jdstrand> and seb128 scared me :)
[18:15] <bdmurray> jdstrand: are the two in the queue the same?
[18:15]  * jdstrand looks
[18:16] <jdstrand> I uploaded one, then deleted it cause I wanted to tweak the changelog
[18:16] <jdstrand> and uploaded another
[18:17] <bdmurray> jdstrand: I still see 2 in the queue
[18:17] <jdstrand> bdmurray: ok, somehow the first didn't get deleted.
[18:17] <jdstrand> bdmurray: I did just now. if you refresh, you should see only one
[18:18] <bdmurray> jdstrand: okay
[18:28] <gpiccoli> cyphermox: ping
[18:28] <cyphermox> gpiccoli: hey
[18:28] <gpiccoli> hello! May I pm you?
[18:28] <cyphermox> sure
[18:29] <gpiccoli> thanks!
[18:50] <nacc_> lol, fun to finally figure out that imagemagick in debian/ubuntu backported a fix that was then reverted upstream
[18:50] <nacc_> slangasek: --^ that will resolve our php-imagick failures, i think
[18:54] <barry> pitti: still around?
[19:31] <nacc_> doko: for clearing out the excuses queue, do you want me to subscribe you to the bugs that fix those packages up? or should i just let it go through the normal channels?
[19:32] <doko> nacc_, both works
[19:41] <Son_Goku> nacc_: pong?
[19:43] <nacc_> Son_Goku: hey, two things
[19:43] <Son_Goku> yes?
[19:43] <nacc_> Son_Goku: i pinged yesterday if you could look at those failures on non-x86 archs for php7.0?
[19:43] <nacc_> Son_Goku: and also, if you could help provide a twig testcase for php upstream?
[19:43] <Son_Goku> nacc_: I don’t have access to any non x86 hw
[19:43] <nacc_> Son_Goku: i'm pretty bogged down with just getting packages turned over
[19:43] <nacc_> Son_Goku: sure, but can you look at the logs and see if it's something obvious?
[19:43] <Son_Goku> ah, sure
[19:43] <nacc_> thanks
[19:44] <Son_Goku> I’m unusually bogged down today, though
[19:44] <Son_Goku> I’m closing on my house
[19:44] <nacc_> Son_Goku: oh congrats -- it's fine, i just needed to delegate some of that, as i want to make more progress on the other packages
[19:45] <Son_Goku> yeah, I’ll take a look at them
[19:46] <nacc_> Son_Goku: thanks
[20:00] <nacc_> Son_Goku: the non-x86 arch issue may not be a big deal, as it appears to have always failed there
[20:00] <Son_Goku> ah
[20:00] <Son_Goku> well, so it’s a “no change” situation
[22:34] <nacc_> doko: ok, subscribed you to the bugs that should unblock all but php-imagick (and php7.0, but not sure if the latter will go away automatically once the others do -- the two failures are "always failed" currently)
[23:29] <carldani> Can anyone in here help me with a Feature Freeze Exception request? I have just created my first one and hope I didn't screw up. Any criticism or RTFM pointers are highly appreciated. https://bugs.launchpad.net/ubuntu/+source/flashrom/+bug/1547144
[23:38] <tumbleweed> carldani: looks reasonable. A full debdiff is always good to include
[23:40] <sarnold> perhaps a mention of testing of any dependant packages, if any -- if none, a mention of that too
[23:40] <tumbleweed> and if it's seeded on any release media
[23:40] <tumbleweed> this has neither, so it's it's a pretty easy FFe candidate
[23:43] <carldani> tumbleweed: how do I determine whether a package is on release media?
[23:43] <tumbleweed> carldani: seeded-in-ubuntu (in ubuntu-dev-tools)
[23:43] <carldani> oooh nice
[23:43] <tumbleweed> and reverse-depends for reverse-depnedencies :)
[23:45] <tumbleweed> I'm quite happy to dust off my release-team hat and approve that :)
[23:45] <carldani> thank you!
[23:46] <carldani> there's one catch, though
[23:46] <carldani> I'd rather mention it upfront
[23:46] <sarnold> it's not done yet? :)
[23:46] <carldani> flashrom doesn't build on s390, and AFAICS Ubuntu 16.04 will have s390
[23:47] <tumbleweed> that's not a regression, though
[23:47] <tumbleweed> https://launchpad.net/ubuntu/+source/flashrom/0.9.7+r1852-1.1
[23:47] <tumbleweed> if it builds on at least those architectures, you're fine
[23:48] <carldani> We (flashrom developers) do have S390 support in upstream svn since a few hours, and plan to release 0.9.9 final soon which will have s390 support.
[23:48] <tumbleweed> all the more reason to do it
[23:49] <tumbleweed> carldani: oh, if you're looking for things to talk about in FFes. Test coverage is useful, gives us an idea of risk levels
[23:50] <carldani> arm64 and ppc64el (broken in the old 0.9.7+r1852-1.1) are compiling just fine in the package mentioned in the ffe
[23:52] <carldani> tumbleweed: thank you! that was quick. wow.
[23:53] <tumbleweed> you happened to find a not-very-active release team member, with spare cycles, staring at IRC :)
[23:54] <stefanct> with a very descriptive nick too ;)
[23:56] <carldani> sarnold: ah yes, and flashrom will probably never be finished... people find flash chips in so many weird locations, flashrom even has a driver for reflashing monitor firmware over i2c over vga
[23:56] <sarnold> carldani: that's simultaneously cool and scary :)
[23:57] <carldani> sarnold: indeed.


[02:10] <holstein> lol
[02:10] <holstein> durrell: whats the issue?
[03:52] <durrell> holstein: Dunno, some bug with the free Radeon driver I guess
[03:52] <durrell> I just switched to Gnome 3 since I like it better anyway and it works fine
[03:56] <durrell> I guess I should probably setup ssh now
[03:56] <durrell> lol
[04:19] <holstein> durrell: interesting.. should be very similar with 3d
[04:21] <holstein> im about to try gnome3 for an extended period
[04:21] <holstein> i know i like and can use XFCE.. and LXDE is great for what it is
[04:21] <holstein> i usually just use openbox.. but im looking for that thing i can install on most any hardware for any user
[04:22] <holstein> unity is not the answer there for me.. it doesnt do well on older hardware, and i dont run it so im no good at setting it up
[15:48] <durrell> holstein: Openbox is my favorite lightweight WM
[15:48] <durrell> I really like Gnome3, though
[15:48] <durrell> Even with the funky
[15:48] <durrell> "Activities"
[15:49] <durrell> It works well for me
[15:49] <durrell> And it's a lot nicer looking


[00:48]  * t3rnary slaps t3rnary around a bit with a large trout
[01:11] <bjh33> hi
[01:16] <Muwanguzi7> Hi
[04:02]  * Peethu slaps Peethu around a bit with a large trout
[04:02] <cprofitt> Peethu: was it raw or cooked?
[04:02] <Peethu> just checkin in
[04:03] <Peethu> hate 13.10v.. installing 12.1 again
[04:04] <Peethu> cprofit: u thr
[04:05] <cprofitt> I am
[04:06] <cprofitt> Peethu: I am rather fond of 13.10
[04:06] <cprofitt> though I will be migrating my testing box to 14.04 soon
[04:07] <Peethu> i starter in case of ubuntu dev
[04:07] <Peethu> cprofit:
[04:07] <Peethu> did you tried in phone
[04:07] <Peethu> cprofit:
[04:09] <Peethu> seems like u r busy.. back later
[15:01] <balloons> howdy everyone
[15:01] <balloons> https://plus.google.com/hangouts/_/72cpi5ial81gk1qbofl262k96o?authuser=0&hl=en for anyone who wants to join the hangout
[15:03] <pleia2> balloons: I think you meant that for #ubuntu-uds-community-2
[15:03] <balloons> haha, ty pleia2
[16:04] <lool> mhall119: Heya, we'd need a followup session for the "System framework for apps" discussion (that just happened in Core 1), what's the best way to do this?
[16:04] <mhall119> lool: go to summit.ubuntu.com, propose a meeting using the link on the right
[16:05] <mhall119> if you have room in the Core rooms, put it in the Core track and ask one of those leads to schedule it
[16:05] <mhall119> otherwise put it on the hallway track and ask msm to schedule it
[16:57] <lool> mhall119: filed http://summit.ubuntu.com/uds-1311/meeting/22125/followup-session-for-system-framework-for-apps/ in the appdev track (where it originally was, but it was scheduled in core 1 due to lack of slots I guess); it doesn't really matter if this ends up in the hallway track though
[17:03] <lool> mhall119: (would you mind scheduling it?)
[17:28] <mhall119> lool: do you have a time you'd prefer?
[17:32] <mhall119> lool: or day?
[18:05] <lool> mhall119: no
[18:07] <lool> well, I'd like the lowest number of conflicts  :-)
[18:08] <mhall119> lool: 16:00 UTC tomorrow then
[18:08] <lool> thanks
[18:08] <mhall119> np
[18:09] <lool> ah crap, it's the time of the push notifications followup
[18:09] <lool> well I guess I'll divide my time
[18:19] <lool> (actually I was confused, it's all good)
[18:26] <lool> the apparmor parser also takes time
[18:26] <lool> content hub?  or HUD?
[18:28] <lool> QUESTION: do we need separate chroots for native builds and cross-builds due to multiarch deps still?
[18:29] <lool> I mean if I'm on trusty/amd64 and I want to a) cross-build to saucy/armhf and b) build for saucy/amd64, can I use a single chroot?
[18:30] <lool> ups ECHAN
[22:56] <Pieter-Wageninge> Hi


[11:47] <tertitten> Hi, I have a couple of questions, I'm trying to de-brand the new live installer, I found the slides and have de-branded those, but the first part of the installer, where you go through the options, how do I de-brand that?


[08:54] <duanedesign> morning all
[09:06] <mandel_afk> ivanka: ping
[09:06] <mandel_afk> duanedesign: morning :)
[09:10] <ivanka> mandel: hi
[09:16] <mandel> ivanka: hello, here too, I dont want to  seem rude :)
[09:19] <ivanka> mandel: :-)
[10:02] <JamesTait> Bore da!
[12:24] <ralsina> good morning everyone!
[12:43] <duanedesign> morning ralsina
[12:43] <ralsina> morning duanedesign!
[13:46] <alecu> tomboy seems to be broken in my natty... hmpf
[13:53] <nessita> alecu: fix it! :-D
[13:53]  * nessita runs
[13:53] <alecu> nessita, no... I mean, the tomboy executable keeps crashing!
[13:54] <nessita> oh
[13:56] <ralsina> alecu dobey nessita thisfred standup in 4'
[13:56] <thisfred> yipyip
[14:00] <nessita> me
[14:01] <ralsina> me
[14:01] <thisfred> me
[14:01] <ralsina> alecu, standup ping!
[14:01] <alecu> me
[14:01] <nessita> dobey, mandel!
[14:02] <ralsina> mandel left for the doctor, I
[14:02] <dobey> me
[14:02] <ralsina>  I have his status and report
[14:02] <dobey> λ DONE: bug 714894 x5, bug 715993, moved u1sync to separate project,
[14:02] <dobey> λ TODO: shotwell plug-in research, finish bug 673012, evaluate SRUs for maverick
[14:02] <dobey> λ BLCK: None.
[14:02] <dobey> oh
[14:02] <ubot4> Launchpad bug 714894 in ubuntuone-storage-protocol (and 5 other projects) "We're packaging it wrong (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/714894
[14:02] <ubot4> Launchpad bug 715993 in ubuntuone-client "package python-ubuntuone-client 1.5.3 r848~natty1 failed to install/upgrade: trying to overwrite '/usr/share/pyshared/ubuntuone/__init__.py', which is also in package python-ubuntuone-storageprotocol 1.5.0-0ubuntu2 (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/715993
[14:02] <nessita> dobey: ?
[14:02] <ubot4> Launchpad bug 673012 in desktopcouch (Ubuntu) (and 1 other project) "Async monitoring of _changes (affects: 1) (heat: 43)" [Undecided,Confirmed] https://launchpad.net/bugs/673012
[14:02] <ralsina> dobey: you are NOT late today :-D
[14:02] <dobey> sorry, habit
[14:03] <ralsina> nessita?
[14:03] <nessita> DONE: Proposed branch for bug #715776. Had a very long conversation with jdo re shares. Made several reviews.
[14:03] <nessita> TODO: weekly call. Convince jdo to try to make shares a 0.1 better. Work on bug #716431.
[14:03] <nessita> BLOCKED: nopes, but I'm behind schedule.
[14:03] <nessita> NEXT: ralsina
[14:03] <ubot4> Launchpad bug 715776 in ubuntuone-client (Ubuntu) (and 1 other project) "Shares dir name may not be unique (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/715776
[14:03] <ubot4> Launchpad bug 716431 in ubuntuone-control-panel "Shares to me path looks aweful (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/716431
[14:03] <ralsina> DONE: reviews, canonicaladmin, doctor :-(
[14:03] <ralsina> TODO: reviews, management stuff, sprint planning, triage another 8 tons of bugs, some coding (my days are all alike)
[14:03] <ralsina> BLOCKED: no
[14:03] <ralsina> thisfred!
[14:03] <thisfred> DONE: u1couch API discussion with aquarius, and thinking about design of same
[14:03] <thisfred> TODO: Bug #702183, Bug #702116, u1couch API, make UDF notifications aggregate
[14:03] <thisfred> BLOCKED: nada
[14:03] <ubot4> Launchpad bug 702183 in ubuntuone-client (Ubuntu) (and 1 other project) "Syncdaemon needs to open the control panel in the background and change the launcher icon to urgent when the user exceeds their quota (affects: 1) (heat: 120)" [Medium,Triaged] https://launchpad.net/bugs/702183
[14:03] <ubot4> Launchpad bug 702116 in ubuntuone-client (Ubuntu) (and 1 other project) "Syncdaemon needs to show and update a progressbar in the Ubuntu One launcher for pending operations (affects: 1) (heat: 120)" [Medium,Triaged] https://launchpad.net/bugs/702116
[14:03] <thisfred> alecu!
[14:03] <alecu> DONE: a branch to update the progressbar (bug #702116), depends on latest thisfred branch. Talked with aquarius re: API work on android. Reading on DroidCouch.
[14:03] <alecu> TODO: setup android dev env. Find a way to make DroidCouch talk to U1 couch servers.
[14:03] <alecu> BLOCKED: no
[14:03] <alecu> HATE: the internet
[14:03] <alecu> pre-EOM comments time!
[14:03] <ralsina> mandel has implemented file status on windows, some branches need more reviews
[14:04] <ralsina> But they are windows reviews, so they are mine
[14:04] <ralsina> file status notifications, that is
[14:04] <thisfred> alecu: oh you're doing the progressbar? Awesome, let me know when you need reviews
[14:04] <ralsina> He's at the doctor now.
[14:04] <alecu> thisfred, my branch only implements all the backend logic for the progressbar; I was hoping you would tackle the libunity stuff :-)
[14:04] <thisfred> alecu: sure, np
[14:05] <thisfred> that's the fun part. Well, sometimes :)
[14:06] <ralsina> Please talk to stuart about the API work, since he will manage you on that, but  let me know if you are too busy with non-API work so we can manage your time correctly ok?
[14:06] <nessita> ralsina: any news on the sprint?
[14:06] <ralsina> nessita: still waiting official approval
[14:07] <ralsina> remember our weekly team call
[14:07] <ralsina> And I have nothing else
[14:07] <dobey> oh man, that call thing is today isn't it
[14:08] <ralsina> dobey: yup
[14:08] <dobey> i wonder when my mic will start working again
[14:08] <ralsina> dobey: hopefully soon? It has not worked once since I have been in the company ;-)
[14:08] <nessita> dobey: have you tried buying another mic?
[14:09] <ralsina> eom?
[14:09] <dobey> nessita: the hardware is fine
[14:10] <dobey> ralsina: it worked a couple months ago :)
[14:10] <ralsina> dobey: I have been here 2.15 months :-)
[14:10] <nessita> dobey: maybe is broken now
[14:10] <nessita> ralsina: eom here
[14:10] <ralsina> eom its is!
[14:11] <dobey> nessita: nope. it just stopped working after an update a couple months ago
[14:12] <nessita> dobey: when you speak it sounds like a busted mic, but... your call
[14:12] <nessita> anyways, dobey, can you please let me know how to test https://code.launchpad.net/~dobey/ubuntuone-client/pth-mathic/+merge/49124
[14:12] <nessita> dobey: make distcheck is failing with
[14:12] <ralsina> dobey, there is a branch from manuel that is not landing
[14:12] <nessita> make[1]: Entering directory `/home/nessita/canonical/u1/client/review_pth-mathic/libsyncdaemon'
[14:12] <nessita>   VALAC  libsyncdaemon_1_0_la_vala.stamp
[14:12] <nessita> /bin/bash: -C: command not found
[14:12] <ralsina> nessita: you don't have valac installed?
[14:12] <nessita> maybe?
[14:13] <nessita> when did we added a new dep? and why we didn't send an email to ubunet-discuss? :-)
[14:13] <ralsina> nessita: it's for the shotwell plugin
[14:13] <ralsina> nessita: but yes, it was... under-announced?
[14:13] <nessita> ralsina: right, can we let the whole team know in the mailing list?
[14:14] <ralsina> nessita: sure. Dobey, mail it? ;-)
[14:25] <alecu> thisfred, I set your branch to "approved" an hour or so ago, but it has not been merged yet
[14:25] <alecu> https://code.launchpad.net/~thisfred/ubuntuone-client/lp-702055/+merge/48987
[14:25] <alecu> dobey, do you have any idea why? ^^
[14:25] <thisfred> alecu, yeah I saw. Maybe mandel's branch is holding stuff up? dobey?
[14:25] <nessita> alecu: talk to dobey, tarmac is weord these days
[14:25] <thisfred> or commit message
[14:25] <nessita> weird*
[14:25] <thisfred> let me look
[14:26] <nessita> commit message is set
[14:26] <alecu> right
[14:26] <thisfred> right, I thought I did that
[14:27] <thisfred> btw, nessita: Not a single remark? That's unusual :P
[14:27] <nessita> thisfred: it was later last night ;-)
[14:27] <nessita> late*
[14:27] <nessita> thisfred: and you branch was really good, I must say
[14:27] <nessita> particularly on styling issues
[14:27] <nessita> thisfred: congrats!
[14:28] <dobey> rodrigo_: ping
[14:35]  * karni reports in
[14:37] <dobey> karni: dobry :)
[14:37] <karni> dobey: hahaha :D
[14:37] <karni> dobey: you what, polish or something ;)
[14:38] <karni> dobey: dobry!
[14:39] <alecu> btw: congrats to mandel on his award :-)
[14:39] <alecu> and to rye too!
[14:40] <dobey> karni: no, not polish
[14:40] <karni> dobey: was kidding ;) but it was funny to see that greeting hehe
[14:40] <dobey> karni: but maybe i confused the polish and the czech :P
[14:40] <karni> dobey: no, it was perfect :D
[14:40] <dobey> hehe ok :)
[14:41] <nessita> alecu: ping
[14:46] <alecu> nessita, pong
[14:47] <nessita> alecu: so, I had my syncdaemon disconnected, and the bubbles still read '3 files uploading'. Do you think we can improve that somehow? (happy to fill in a report when you have an opinion)
[14:48] <nessita> alecu: i didn't know SD was disconnected, so when I saw the bubble I was happy that my files were uploading. But they weren't!
[14:49] <alecu> nessita, I have a branch waiting for eric's latest branch to land that adds connection/disconnection bubbles.
[14:49] <nessita> alecu: YOU ROCK
[14:50] <alecu> nessita, but I think I'm not pausing the "3 files uploading" bubble.... so your case will fail exactly like that...
[14:50] <alecu> nessita, so I'd really like a bug report on that, if you may :-)
[14:50] <nessita> alecu: sure!
[14:52] <rodrigo_> dobey, pong
[14:52] <nessita> bug #716457
[14:52] <ubot4> Launchpad bug 716457 in ubuntuone-client "'N files are uploading' is missleading when syncdaemon is disconnected (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/716457
[14:52] <nessita> alecu: ^
[14:53] <alecu> thanks!
[15:05] <joshuahoover> ralsina, alecu: just saw this post by jcastro about libunity and the progress indicator: http://castrojo.tumblr.com/post/3202209062/progress-meters-quicklists-and-number-count-for-the has some links in it that might be useful...sorry if this is all old news to you guys :)
[15:05] <ralsina> joshuahoover: not to me!
[15:06] <alecu> joshuahoover, Chipaca told us about it yesterday, but thanks a lot :-)
[15:06] <joshuahoover> alecu: cool
[15:06] <jcastro> any gotchas or things you run into that could help the next set of app authors would be useful if you want to add to https://wiki.ubuntu.com/Unity/LauncherAPI
[15:07] <alecu> jcastro, will do, thanks!
[15:14] <dobey> jcastro: is there a design page on what some types of apps should do with their launchers, similar to the pages for notifications/etc?
[15:14] <jcastro> not afaict
[15:16] <dobey> yeah i'm not seeing anything on the unity page either
[15:19] <ralsina> sorry guys we are a bit delayed with the team meeting
[15:19] <ralsina> Let's postpone it for now+10 minutes
[15:20] <dobey> heh
[15:20] <dobey> stop arguing about the email vs. visible name thing :)
[15:20] <ralsina> dobey: it's a bit deeper than that, really
[15:22] <thisfred> hmmm python-ubuntuone-client is failing to install
[15:22] <thisfred> on maverick
[15:22] <thisfred> from nightlies
[15:22] <dobey> thisfred: yes, we know
[15:22] <thisfred> oh ok
[15:22] <joshuahoover> jcastro: i love your updates on unity...great posts!
[15:22]  * thisfred learns to stop worrying and love the bomb
[15:22] <jcastro> <3
[15:24] <dobey> thisfred: it will be fixed shortly
[15:25] <thisfred> awesome
[15:25]  * dobey fixes the other nightlies too
[15:26] <karni> looks like I managed to untwist the AQC
[15:28] <beuno> karni, \o/
[15:29] <karni> beuno: I'll keep you posted! :)
[15:52] <joshuahoover> ralsina: forgot to ask about nightlies...are they still broken? will they be fixed soon?
[15:52] <dobey> joshuahoover: they should be installable now
[15:53] <dobey> joshuahoover: but working might be a bit bold to say, with the big change to pth files that's landing right now :)
[15:53] <dobey> but once all the pth support stuff lands, it should be working again too
[15:54] <dobey> joshuahoover: but i am working on it, yes :)
[15:54] <joshuahoover> dobey: cool
[15:56] <ralsina> ok, I'm going to have a pathetic lunch break
[15:56] <ralsina> See everyone in a while
[16:14] <karni> facundobatista / Chipaca : why is query_volumes the only method, that doesn't use the ActionCommandQueue.go() scheme, and calls the client method directly?
[16:15] <karni> I can only imagine it's because it's of high importance and, thus, executed instantly instead of being queued.
[16:19] <kklimonda> great, so apparently U1 has managed to send over 400MB of data using my phone..
[16:19] <kklimonda> my bill is not happy ;)
[16:20] <karni> kklimonda: what do you mean U1 and using your phone
[16:20] <karni> kklimonda: you used mobile connection and your laptop, was it a mobile app, or something else?
[16:20] <kklimonda> yeah, I've used mobile connection and my laptop
[16:21] <karni> kklimonda: U1 is smart, but not _that_ smart. u should have u1sdtool -d or something :<
[16:21] <kklimonda> I did have
[16:22] <kklimonda> but it doesn't stay disabled after reboot
[16:22] <karni> O_o
[16:22] <kklimonda> also, there was really nothing there to sync
[16:22] <karni> right
[16:22] <karni> so where teh 400 megs from?
[16:22] <kklimonda> well, it obviously decided it knew better
[16:22] <kklimonda> it started resyncing my music
[16:27] <kklimonda> also, it is a good indicator that we need.. well, an indicator to indicate that U1 is doing something..
[16:27] <karni> kklimonda: alecu is already working on it with promising results
[16:28] <karni> kklimonda: aggregated notifications, that is.
[16:28] <kklimonda> brr, I've had to pay over $80 because of that small incident..
[16:28] <kklimonda> well, $80 just for the data sent
[16:28] <kklimonda> some more for the bill itself..
[16:29] <karni> kklimonda: you know you can't really blame U1 for it.. u1sdtool -d disconnects it only for the current session. Ubuntu doesn't diffrenciate what connection you're using.
[16:30] <karni> kklimonda: however, that perhaps might be a good idea to file a bug report or something to make the disconnect option permanent
[16:30] <kklimonda> karni: I can blame it for syncing files that were already synced.
[16:30] <karni> kklimonda: that sounds more resonable, right
[16:30] <kklimonda> I wonder why it did that.. I'll have to dig into that deeper when I'm back home.
[16:31] <karni> kklimonda: you might wanna look at the logs (that's probably what you meant)
[16:32] <kklimonda> anyone interested in helping me figure it out tomorrow I can provide you with logs ;)
[16:35] <kklimonda> one weird thing I see in logs is "2011-02-06 16:09:23,199 - ubuntuone.SyncDaemon.local_rescan - DEBUG - Deleting metadata, because of node_id=None, of '/home/kklimonda/Music/Tom Waits'"
[16:35] <mandel> ralsina_lunch, ivanka: i;m back earlier than expected, let me know when you wanna do the mumble
[16:35] <kklimonda> and one such line for each and every folder in ~/Music/
[16:36] <mandel> rye: ping
[16:36] <kklimonda> ok, I'll be back in few hours.
[16:39] <rye> mandel, kind-of-pong
[16:39] <mandel> rye: kind-of-congrats then ;)
[16:40] <rye> mandel, ah, thanks! Congrats to you too!
[16:41] <mandel> rye: thx! i think is our turn to buy a round next time we all meet :)
[16:42] <rye> mandel, wow, yes, definitely!
[16:43] <mandel> dobey: ping
[16:46] <dobey> mandel: yo
[16:47] <mandel> dobey: hello, can you give be a hand to understand an error when trying to land a branch?
[16:47] <dobey> sure
[16:48] <mandel> dobey: this is the merge: https://code.launchpad.net/~mandel/ubuntuone-client/implement_windows_os_helper/+merge/46630
[16:48] <dobey> mandel: lint failed
[16:49] <dobey> undefined name 'WindowsError'
[16:50] <dobey> i guess maybe we need to add some magical ignore stuff for u1lint also
[16:50] <mandel> dobey: where abouts is that? my brain most be blocking it...
[16:51] <mandel> oh, got it, ctrl+F i the browser hehe
[16:51] <dobey> mandel: the actual errors tend to be in the sort-of middle of the output, because stderr and stdout are joined with \n, and not merged into a single output :-/
[16:51] <dobey> mandel: so sometimes it can be hard to read :(
[16:52] <dobey> i'll see if i can fix tarmac to handle that better
[16:52] <mandel> dobey: he, i was looking at the bottom wondering wtf :)
[16:52] <dobey> mandel: yeah, the bottom tells you what failed sort of, but you have to search up to find the actual error
[16:53] <mandel> dobey: ok, now that i know… i'll think a way to go around the windowserror, 'cause the diable comment does not work with pyflakes, right?
[16:53] <mandel> ralsina: ping
[16:53] <dobey> mandel: right
[16:53] <ralsina> mandel: pong
[16:54] <mandel> ralsina: which room?
[16:54] <mandel> ralsina: the mumble
[16:54] <ralsina> yes.... online services desktop+?
[16:54] <mandel> ralsina: ok
[16:54] <dobey> mandel: you can do try: import blah blah; except ImportError: class WindowsError: blah blah, or just add it to the ignore list in pylintrc for now
[16:55] <mandel> dobey: I'll do the import blah blah, at least is not a general thing, just in case
[16:55] <ralsina> that's because that import fails on Linux, right?
[16:55] <dobey> ralsina: presumably yes
[16:56] <ralsina> so, we need to add "run lint on Linux before approving" :-(
[16:56] <ralsina> to our windows review checklist
[16:56] <mandel> ralsina: well, there should be a windows review and alinux one
[16:56] <mandel> ralsina: you did windows which is ok, the other should pick this things...
[16:57] <ralsina> mandel: yeah
[16:57] <mandel> I really do not know why the uses WindowsError and not OSError...
[16:57] <ralsina> So no reviews that just read the code, either
[16:57] <dobey> well
[16:57] <ralsina> mandel: it's a known quirk
[16:57] <dobey> this is what bots are for
[16:57] <dobey> and the bot caught it :)
[16:57] <ralsina> You can even get DOSError in some specific cases
[16:57] <mandel> puag...
[16:58] <ralsina> puag indeed
[16:58] <ralsina> WindowsError is raised whenever there is a windows-specific error that can't happen on any other platform
[16:59] <ivanka> mandel: hi! I'm ready
[16:59] <mandel> ralsina: well, at least the recognize Windows as not being an OS hehe
[16:59] <mandel> ivanka: desktop+ room?
[16:59] <ralsina> mandel: WindowsError subclasses OSError anyway so you could catch OSError still
[16:59] <mandel> ivanka: and hello
[16:59] <mandel> ralsina: hmm, really?
[17:00] <ralsina> mandel: the doc says so :-)
[17:00] <ralsina> http://docs.python.org/library/exceptions.html
[17:08]  * ralsina considers throwing random VMSErrors occasinally
[17:09] <mandel> ralsina: http://bazaar.launchpad.net/~ubuntuone-hackers/ubuntuone-windows-installer/trunk/view/head:/install/UbuntuOne7.wxs
[17:10] <thisfred> dobey any idea why my branch is not landing? has commit message and was approved 3h ago https://code.launchpad.net/~thisfred/ubuntuone-client/lp-702055/+merge/48987
[17:11] <dobey> thisfred: yes, i had disabled client stuff from landing for a bit while fixing up the nightlies for the pth changes
[17:11] <dobey> thisfred: it should land in the next run in a few minutes
[17:11] <thisfred> dobey: ah ok, thx
[17:12] <ralsina> mandel: that file is agonizingly long and xml-y
[17:12] <ralsina> xml-y sounds like smelly, FYI
[17:13] <mandel> ralsina: yes, and is casesensitive, look at the bottom, where it says UI
[17:18] <dobey> lunch time :)
[17:24] <ralsina> My mumble died!!!!
[17:25] <ralsina> Oh, everyone's died :-)
[17:25] <mandel>  mine too hehe
[17:25] <mandel> server went down...
[17:59] <Fury1> Hi I have problems accessing my account. When I click on "Konto verwalten" ("Manage accounts"). Firefox opens a blank website https://login.ubuntu.com/+openid. The statusbar says "Fertig" (Ready").
[17:59] <Fury1> I'm using a german version of ubuntu. I hope my the guessed english original messages in () are understandable.
[18:03] <dobey> Fury1: hrmm, are you using a proxy?
[18:03] <Fury1> no
[18:04] <dobey> Fury1: that page shouldn't be blank, so maybe something is wrong with firefox. not sure. but the link opens https://one.ubuntu.com/account/ which redirects through the openid log-in process to make sure you're logged in
[18:04] <dobey> Fury1: does opening that link work?
[18:07] <Fury1> after a while waiting for login.ubuntu.com it just returns to https://login.ubuntu.com/+openid
[18:08] <dobey> Fury1: ok, try clearing your cookies for one.ubuntu.com and login.ubuntu.com, and clearing your cache
[18:09] <dobey> kenvandine: ping
[18:13] <Fury1> I cleared my cache and cookies and tried again to login clicking on "Manage accounts" Ubuntu Single Sign in asked for my password. Now I'm stucked at another blank website https://one.ubuntu.com/auth/complet/?next=%Faccount......
[18:14] <dobey> Fury1: i think there is maybe something wrong with either your firefox or your ISP then. it works fine here :(
[18:15] <Fury1> :-( I'll try a different browser. If that doesn't work I'll try at work tomorrow.
[18:17] <alecu> thisfred, here's the progressbar backend branch (depends on your last branch) https://code.launchpad.net/~alecu/ubuntuone-client/status-progressbar/+merge/49266
[18:18] <thisfred> alecu: thanks! I'll review and then see if I can start hooking it up!
[18:20] <kenvandine> dobey, pong
[18:21] <dobey> kenvandine: hey. just wondering if it doesn't make sense to have the "close" menu item in the unity menubar for u1 control panel
[18:22] <kenvandine> why?
[18:22] <kenvandine> i hate those stubs
[18:22] <kenvandine> why have a menu at all?
[18:22] <dobey> i don't know. i guess the idea of unity without the menubar seems weird :)
[18:23] <kenvandine> we try to hide them whenever they aren't useful
[18:23] <kenvandine> i think they automatically hide for GtkDialog
[18:23] <kenvandine> which makes sense
[18:24] <kenvandine> but if you don't provide any functionality in the menu, what's the difference?
[18:24] <kenvandine> that's my opinion :)
[18:24] <dobey> don't know :P
[18:24] <dobey> encompass won't have any menus normally
[18:26] <thisfred> alecu: approved, so you have 2 +1s, and I think my branch has been merged
[18:29] <alecu> yes, it finally merged! thanks dobey :-)
[18:29] <dobey> sure
[18:32] <alecu> thisfred, so, the place to update the UI would be the _timeout method in ProgressBar. I've calculated the number as a percentage, but it seems the library uses 0.0 - 1.0
[18:32] <thisfred> ok, that's easy enough to change or convert
[18:33] <alecu> thisfred, also, I didn't see the active or "pulsating" state mentioned in jcastro's post. We should look in the library to see if that's still planned.
[18:34] <thisfred> I did see that Ken has numbers working for xchat-gnome, so hopefully emblems work as well.
[18:35] <alecu> cool
[19:15] <ralsina> nessita:  +1 on uniq-share-dir
[19:16] <nessita> yey
[19:24] <ralsina> nessita +1 on share-subs
[19:24] <ralsina> nessita: I must confess I fieldtested it and didn't run the test
[19:24]  * ralsina forgot
[19:25] <nessita> ralsina: well, tarmac will run them
[19:25] <nessita> but do not get used to that :-P
[19:25] <ralsina> yeah, and I trust you ran them, but yes, I'll be a good boy from now on
[19:28] <dobey> bah
[19:29] <dobey> reviewers shouldn't be running unit tests.
[19:34] <karni> nessita: hey :) what is the 'marker' used in the syncdaemon - is it a unique string?
[19:35] <nessita> karni: ah... markers are a very complicated thing. I know facundobatista made then better, so you should ask him the latest state of the art
[19:35] <kklimonda> hey nessita, what does "DEBUG - comp yield: dir '/home/kklimonda/Music/Celtic Woman' will be scaned later because it's in NONE!" mean?
[19:35] <kklimonda> :)
[19:35] <karni> nessita: I know how they work. I'm only wondering about the type ;D But thanks!
[19:36] <ralsina> nessita: on the improve-share-name branch
[19:36] <nessita> karni: ah! I think they can be an object()
[19:36] <karni> nessita: aha :) thanks, I'll check that!
[19:36] <ralsina> nessita: any chance of improving ".ubuntuone/Purchased from Ubuntu One"?
[19:37] <nessita> kklimonda: that means that the local hash that syncdaemon has for that dir matches the latest known server hash
[19:37] <nessita> kklimonda: so, that file will be scanned later, when the server info is udpated
[19:37] <nessita> facundobatista: am I lying properly? ^
[19:38] <facundobatista> nessita, almost
[19:38] <nessita> ralsina: I have no info from syncdaemon about that. I can squeeze a hack if you give me any idea (but it will be another branch following a bug report from you :-))
[19:38] <ralsina> nessita: it's not THAT ugly ;-)
[19:38] <nessita> ralsina: that folder is being symlinked from somwhere else, no idea from where
[19:38] <ralsina> nessita: how can I find out?
[19:38] <nessita> maybe we can replace the string
[19:39] <facundobatista> nessita, kklimonda, being in NONE means that the local hash that syncdaemon has for that dir matches the latest known server hash, yes, so the directory is ok to be scanned later (you should find the scan for that directory below in the log)
[19:39] <nessita> ralsina: that's related to music store, so we should ask some music store guru
[19:39] <ralsina> nessita: really, music store? I'd never have guessed it.
[19:39] <kklimonda> facundobatista: any idea what to look for to find the reason for syncdaemon deciding to sync all the files anyway?
[19:39] <kklimonda> facundobatista: they haven't been touched for weeks
[19:40] <nessita> ralsina: yes, I think (just guessing) that is symlinked from ~/Music somewhere
[19:40] <ralsina> nessita: yes, it has my song bought from Music Store indeed
[19:40] <kklimonda> facundobatista: and they are all on the server already
[19:40] <ralsina> We could just remove the ".ubuntu"
[19:41] <facundobatista> kklimonda, first, you should see if the "activity agains the server" is produced because of indications of LocalRescan or ServerRescan
[19:41] <ralsina> But the branch does what it promised so, I'll read the code a bit and probably +1 it
[19:41] <kklimonda> facundobatista: I got "DEBUG - Deleting metadata, because of node_id=None, of '/home/kklimonda/Music/Pink Floyd/The Dark Side of the Moon'" below
[19:41] <nessita> ralsina: we could, you're right
[19:42] <facundobatista> kklimonda, if it has node_id in None means that it never was created in the server properly (or at least that the client didn't get the response, or that it got the response but didn't save it)
[19:42] <kklimonda> facundobatista: ok, so the reason for that could be a flaky connection to the server?
[19:43] <facundobatista> kklimonda, yes
[19:43] <ralsina> nessita: it's not symlinked from anywhere though
[19:43] <nessita> guh
[19:44] <kklimonda> facundobatista: but during the original transfer connection was good, it was only during last few days that I've been connected via my phone. Is it possible that the client couldn't receive all the metadata from the server and decided to resend all files that it was unsure of?
[19:46] <facundobatista> kklimonda, no
[19:46] <facundobatista> kklimonda, if it got the node_id and saved it, it will not lose it
[19:47] <ralsina> nessita: +1 in improve-share-name
[19:47] <kklimonda> facundobatista: something did make it happen lose it few days ago. Any idea if my logs will help you figure it out?
[19:47] <kklimonda> to lose it*
[19:47] <ralsina> nessita: I also accidentally approved uniq-share-dir once again ;-)
[19:48] <facundobatista> kklimonda, yes, if you find where that node was created to the server, we can track it since then
[19:48] <kklimonda> facundobatista: where? what to look for in the syncdaemon.log ?
[19:49] <facundobatista> kklimonda, a FS_FILE_CREATE for that path
[19:49] <nessita> ralsina: thanks!
[19:49] <facundobatista> kklimonda, if you have that, we can track it!
[19:51] <kklimonda> facundobatista: something like this: http://pastebin.com/gbeUEng3 ?
[19:54] <facundobatista> kklimonda, right, you should then find a MakeFile for that path
[19:56] <kklimonda> facundobatista: http://pastebin.com/85Ch9B56
[19:57] <facundobatista> kklimonda, exactly... that MakeFile has a life cycle in the queue, so you need to find *all* the log lines for it (you can grep with 703cd7c7-1a55-4975-99a4-0cff38f9c5b3)
[19:57] <kklimonda> http://paste.ubuntu.com/565535/
[19:57] <facundobatista> kklimonda, in that line it indicates that is "path locked", most probably because there's another command for the parent directory (most probably, a MakeDir)
[19:59] <kklimonda> most likely, there is a MakeDir for every folder in Music/ :)
[19:59] <facundobatista> kklimonda, see:
[19:59] <facundobatista> syncdaemon.log.2011-02-07_07-48-21:2011-02-06 16:10:43,632 - ubuntuone.SyncDaemon.fsm - DEBUG - set_node_id: path='/home/kklimonda/Music/Pink Floyd/The Dark Side of the Moon/03 Time.mp3' mdid='703cd7c7-1a55-4975-99a4-0cff38f9c5b3' share_id='51badade-6063-4b9c-bbb1-921f64aa87f5' node_id='e4e2e46b-5ce5-4cd4-b102-394387a6cf8b'
[20:00] <facundobatista> that indicates that the node_id was effectively saved for that node
[20:00] <facundobatista> kklimonda, so, if in a later run you find that that LR path says that node_id=None for that path, we may be in one of two situations
[20:00] <kklimonda> facundobatista: yes, but that was today.. well, 3 days ago. But syncdaemon has been running for weeks (the original upload of this file has been on 20th of january 2011) and and that didn't happen.
[20:01] <facundobatista> kklimonda, ah, ok!
[20:01] <kklimonda> facundobatista: one thing is that for some time I couldn't run u1sdtool --waiting-c
[20:01] <facundobatista> kklimonda, why?
[20:01] <kklimonda> facundobatista: it quit with dbus message about unicode errors
[20:01] <facundobatista> oh
[20:01] <facundobatista> we had a bug about that, yes
[20:02] <kklimonda> but the file still has been uploaded to the server before (and I see it there) so that's not it - still the only weird thing aside the whole reuploading everything :)
[20:47] <ralsina> dobey: I will have to add API to libsyncdaemon so... tomorrow morning.
[20:48] <ralsina> And I am personally going to give the evil eye to the next person that commits a C file without comments on what functions do :-)
[20:49] <lalejand> Hi everybody, I just updated U1 stuff (nighlty) and now, when I do "u1sdtool -s" it crashes :/
[20:50] <ralsina> Oh, wait, no new API. Neat!
[20:50] <lalejand> it says that : http://pastebin.com/1q2rZq8c
[20:51] <dobey> ok
[20:51] <lalejand> even if I try a u1sdtool -q. It crashes also
[20:51] <dobey> lalejand: you upgraded everything, or you upgraded only ubuntuone-client?
[20:52] <lalejand> dobey : everything
[20:52] <dobey> lalejand: do you have a /usr/share/pyshared/ubuntuone directory?
[20:53] <lalejand> dobey : oh wait, it looks like every 5 minutes something new appears to be updates
[20:53] <lalejand> "updated"
[20:54] <dobey> lalejand: we just updated the way python bits are installed, to work better; but it breaks compatibility with the older method, so if you still have some older things lying around, something might fail :-/
[20:56] <lalejand> dobey : /usr/share/pyshared/ubuntuone I don't have this directory, I have instead unbuntuone-client, ubuntuone-control-panel, ubuntuone-storage-protocol
[20:57] <dobey> ok, everything should work now then. do you still get that error?
[20:58] <lalejand> yes
[20:58] <lalejand> dobey : yes
[20:58] <lalejand> dober : Am I supposed to restart a session ?
[20:59] <dobey> no. hmm
[20:59] <dobey> lalejand: what does this say when you run it: python -c "import ubuntuone; print ubuntuone.__file__"
[21:00] <lalejand> dobey : http://pastebin.com/h8mqqjPd
[21:01] <dobey> hmm
[21:02] <dobey> lalejand: what about: python -c "import ubuntuone.platform as plat; print plat.__file__"
[21:04] <lalejand> dobey : http://pastebin.com/x9bD6VwA
[21:05] <dobey> lalejand: what veresion of python-ubuntuone-client do you have?
[21:05] <lalejand> dobey : 1.5.3+r857~maverick1
[21:07] <dobey> hmm
[21:08] <ralsina> I am EODing. Have a nice evening everyone!
[21:08] <nessita> bye ralsina!
[21:08] <dobey> i wonder if python2.6 has a problem with the pth files :(
[21:09] <nessita> alecu: I'm assigning bug #715887 to you, so you can squeeze a branch when you have a 10 minutes slot?
[21:09] <ubot4> Launchpad bug 715887 in ubuntuone-client (and 1 other project) "Notify-OSD messages say "your cloud" (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/715887
[21:10] <dobey> no, it works fine on my lucid
[21:10] <dobey> lalejand: do you have a /usr/lib/python2.6/dist-packages/ubuntuone directory?
[21:15] <alecu> nessita, ack.
[21:16] <alecu> anybody knows how to enable desktopcouch synchronizing in natty?
[21:17] <lalejand> dobey : do you have a /usr/lib/python2.6/dist-packages/ubuntuone directory? >>> no
[21:17] <thisfred> I can't get unity to work. Which makes developing for it ever so slightly harder
[21:17] <dobey> lalejand: have you ever installed ubuntuone from source?
[21:18] <dobey> alecu: start desktopcouch, connect to ubuntuone.
[21:19] <lalejand> dobey : from source ? No, only packages
[21:19] <dobey> lalejand: do you have "ubuntuone-music" installed?
[21:19] <lalejand> via update-manager
[21:20] <dobey> alecu: are you still on maverick somewhere?
[21:20] <lalejand> dobey : no I don't find any package named ubuntu-music. I have rythmox-ubuntuone-music-store
[21:21] <alecu> dobey, yes, on my desktop, but I'm not at the office right now.
[21:21] <dobey> alecu: doh ok
[21:21] <lalejand> dobey : I install my U1 stuff from : http://ppa.launchpad.net/ubuntuone/nightlies/ubuntu
[21:22] <dobey> lalejand: can you do: find /usr/lib/py* -name "ubuntuone" -type d
[21:23] <lalejand> dobey : http://pastebin.com/s1wHBmy0
[21:25] <dobey> lalejand: if you apt-get remove --purge python-ubuntuone, does it work then?
[21:26] <nessita> ok, I'm gone
[21:26] <nessita> bye all!
[21:28] <karni> bye nessita
[21:28] <lalejand> dobey : it works now
[21:29] <dobey> lalejand: ok, thanks
[21:30] <lalejand> dobey : so I will have to never reinstal this package ?
[21:31] <dobey> lalejand: well there is a bug in the new python installation stuff. so not never
[21:32] <lalejand> dobey : ah ok thx
[21:33] <dobey> lalejand: should be fixed sometime tomorrow
[21:39] <thisfred> alecu: so two problems stand in the way of progress bar progress: 1. there are no python bindings for libunity yet, it seems, and 2. The nvidia drivers in natty are broken, so I can not use unity at all :(
[21:39] <alecu> thisfred, awful.
[21:40] <dobey> lalejand: if you install python-ubuntuone again, does it then work?
[21:40] <dobey> thisfred: isn't there a .gir for libunity?
[21:40] <thisfred> yeah. we can work around 1. by calling dbus directly I guess, but without any way to test that it's not gonna be easu
[21:40] <thisfred> easy
[21:40] <thisfred> dobey: where would I find that?
[21:41] <dobey> gir1.2-unity-3.0 - GObject introspection data for the Unity library
[21:41] <dobey> install that and "from gi.repository import Unity" i suspect
[21:42] <thisfred> kthx
[21:42] <dobey> and libunity-dev should have the Unity-3.0.gir file that is xml, so you can look at it for API reference if you need and there is no other documentation to look at :)
[21:43] <thisfred> Yeah. There's https://wiki.ubuntu.com/Unity/LauncherAPI but that's pretty minimal still
[21:47] <lalejand> dobey : crash again after resintalling python-ubuntuone
[21:47] <dobey> weird
[21:49] <dobey> thisfred: are you on maverick or narwhal?
[21:49] <lalejand> dobey : but u1 seems tu run still because I can see information in the notifications messages
[21:49] <thisfred> hmm: from gi.repository import Unit; dir(Unity)
[21:49] <thisfred> gets RepositoryError
[21:49] <thisfred> dobey: both
[21:49] <alecu> thisfred, I get that same error
[21:50] <thisfred> apparently it doesn'
[21:50] <dobey> thisfred: ah, maybe it's not called Unity then
[21:50] <alecu> gi.RepositoryError: Typelib file /usr/lib/girepository-1.0/Dbusmenu-Glib-0.4.typelib for namespace 'Dbusmenu-Glib' contains namespace 'Dbusmenu' which doesn't match the file name
[21:50] <thisfred> t like introspection, ironically
[21:50] <dobey> oh
[21:50] <thisfred> dobey: the import goes fine
[21:50] <dobey> because dbusmenu is broken
[21:50] <dobey> yell at tedg
[21:50] <dobey> because it's clearly his fault
[21:50] <alecu> :-)
[21:50] <dobey> thisfred: do you have maverick readily available with nightlies installed?
[21:51] <thisfred> dobey: yep
[21:51] <thisfred> that's what I'm typing from
[21:51] <dobey> thisfred: cool. do you have python-ubuntuone installed?
[21:52] <thisfred> dobey: I do
[21:52] <dobey> thisfred: does "python -c import ubuntuone.platform as pt; print pt.__file__" explode for you?
[21:52] <dobey> uhm, move that first quote
[21:53] <thisfred> got it
[21:53] <thisfred> dobey: no asplosions
[21:53] <thisfred> seems to work
[21:53] <dobey> what did it print?
[21:54] <thisfred> /usr/local/lib/python2.6/dist-packages/ubuntuone/platform/linux/__init__.py
[21:54] <dobey> wtf do you have stuff in /usr/local/lib for?
[21:54] <thisfred> (after I ran it *outside* a source directory ;)
[21:54] <thisfred> dobey: I have no idea
[21:54] <dobey> someone did a make install from ubuntuone-client
[21:54] <dobey> bad monkey!
[21:55] <thisfred> maybe I did at one point, I don't remember though
[21:55] <dobey> well do a make uninstall :)
[21:55] <thisfred> but it explains some things
[21:55] <thisfred> hehe
[21:56] <dobey> and let me know if it still works after that :)
[21:56] <alecu> this is my EOD. bye all!
[21:57] <thisfred> dobey: removed it, still works:
[21:57] <thisfred> /usr/lib/pymodules/python2.6/ubuntuone-client/ubuntuone/platform/linux/__init__.pyc
[21:59] <dobey> ok
[21:59] <dobey> lalejand: i think maybe something else is wrong with your system somehow. it works ok for myself and thisfred it seems :(
[22:00] <lalejand> dobey : ahm
[22:01] <lalejand> dobey : what can I do ? Try to reinstall U1 stuff ?
[22:01] <dobey> lalejand: i'm not sure. need to find out exactly why it's failing
[22:03] <dobey> lalejand: you don't have anything installed relating to ubuntuone, from somewhere other than the nightlies ppa?
[22:04] <lalejand> I never installed from source
[22:05] <dobey> do you have anything from another PPA?
[22:05] <lalejand> dobey : once I had huge problems with U1, I had to uninstall everything and reinstall all, maybe I forgot things, I don't know
[22:05] <lalejand> dobey : do you have anything from another PPA? >>> related to U1 ?
[22:06] <dobey> yes, related to u1
[22:06] <lalejand> dobey  : well, no, I didn't know there are others U1 ppas
[22:07] <lalejand> dobey : ubuntuone-client-tools is no longer needed ?
[22:07] <dobey> it wasn't ever "needed" no
[22:08] <dobey> it should have got uninstalled on upgrade
[22:08] <lalejand> dobey : ok
[22:08] <dobey> it doesn't exist any more; that code was moved out of ubuntuone-client
[22:08] <lalejand> dobey : yes it did
[22:09] <dobey> you can try uninstalling and re-installing i suppose, but i doubt it will solve the problem
[22:15] <lalejand> dobey : gir1.0-ubuntuone-1.0 is not needed neither ?
[22:16] <dobey> no, not unless you're installing another application that uses it. and i don't think anyone does yet
[22:16] <lalejand> dobey : this looks okay ? http://ubuntuone.com/p/ceL/
[22:19] <lalejand> dobey : and this ? http://ubuntuone.com/p/ceN/
[22:22] <dobey> looks ok, yeah
[22:33] <lalejand> dobey : I uninstalled, purged, and reinstalled, and still crash
[22:35] <lalejand> dobey : this can help ? http://pastebin.com/LsbE7s4V
[22:36] <dobey> lalejand: that is a separate issue. if you apt-get remove --purge zeitgeist-core that should go away
[22:36] <dobey> i think there is alreayd a bug filed for that
[22:36] <dobey> re: the python import error, if it's still happening, there is something else wrong with your system, but i don't know what, or how to figure out exactly :(
[22:36] <dobey> but right now, i have to go
[22:38] <lalejand> dobey : ok, thanks for your help anyway
[22:39] <dobey> sure. sorry we couldn't figure it out
[22:39] <dobey> cheers all
[22:56] <lalejand> Hi again, in the U1 web interface, in the contacts page, I have that : http://ubuntuone.com/p/cee/ strange no ?


[19:43] <Atamira> morning
[20:10] <ibeardslee> morning
[20:36] <ajmitch_> morning
[22:50] <mwhudson> mmm, lovely weather today