[07:19] <NorElee> Hi i need a suggestion
[07:20] <NorElee> I want to work with one server backup utility and I am confused while choosing one. Duplicity Holland or r1soft
[07:20] <NorElee> can anyone give pros and cons related to it.


[00:06] <luv> pitti: yo! can you please give me a shout when online? It's regarding https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1063617 (I see you raised it originally)
[00:07] <luv> I already found two bugs in the compizconfig related to it. Doing more tests now. I will post a patch later this week.
[05:37] <zyga> hello
[05:38] <zyga> I have a .crash file, how can I add it to a launchpad bug report so that the various useful bots do their thing?
[05:38] <zyga> I don't have access to the original machine anymore
[05:51] <TheMuso> zyga: Perhaps unpack the crash file and upload the components as separate files manually?
[05:57] <infinity> zyga: You can pass a .crash file as an argument to ubuntu-bug(1).
[05:57] <wgrant> Or apport-collect, if the bug already exists.
[05:57] <pitti> Good morning
[05:58] <pitti> mapreri: right, that sounds urgent, will upload
[05:58] <pitti> luv: *shout* :)
[05:59] <zyga> thanks
[05:59] <zyga> It looks like Qt5 crash on some deep internals
[05:59] <zyga> hmm
[06:00] <zyga> apport-collect rejects any action as I'm not the one who filed the bug
[06:01] <zyga> TheMuso: can the .crash file be unpacked with any tool or is that a manual process?
[06:04] <TheMuso> zyga: apport-unpack
[06:06] <zyga> thanks!
[06:07] <RAOF> Oh, arse. No autopkgtest for Debian experimental, I guess.
[06:08] <zyga> so if I got that unpacked now, how can I get apport retracer to recover symbols and everything?
[06:08] <RAOF> Also, boo, argyll is orphaned.
[06:08] <zyga> though I already see symbols I'd like to see more details
[06:09] <RAOF> zyga: Install apport-retrace, and it'll download the debugging symbols for you and give you a gdb session on the core.
[06:09] <zyga> thanks
[06:11] <zyga> RAOF: hmm, it borks on the bug (1318584) not having standard description format
[06:12] <zyga> RAOF: would it help if I were to upload all the unpacked crash files to the bug report?
[06:12] <zyga> (as attachments)
[06:28] <pitti> infinity: hey Adam
[06:29] <infinity> pitti: Yes dear?
[06:29] <pitti> infinity: could you put http://people.canonical.com/~pitti/tmp/eglibc.faster-autopkgtest.debdiff into eglibc's VCS?
[06:29] <pitti> infinity: that'd be lovely, honey
[06:29]  * pitti will do the same for the kernel now, which should shave off some 30 to 45 minutes from the test
[06:29] <infinity> pitti: I can do that, sure.
[06:39] <pitti> apw: I have an updated autopkgtest for linux which makes the thing go 30 to 45 mins faster: http://people.canonical.com/~pitti/tmp/linux-autopkgtest/
[06:40] <pitti> apw: I tried a debdiff, but debclean seems to have eaten my debian/changelog entry, so this just has the updated debian/tests dir and a proposed changelog entry
[06:48] <mitya57> Mirv: When can I go ahead with qtwebkit update?
[06:54] <infinity> pitti: The changelog entry goes in debian.master/changelog, not debian/changelog.
[06:55] <infinity> pitti: Because the kernel is super special.
[06:59] <zyga> ara: hey
[07:00] <ara> zyga, good morning
[07:15] <infinity> pitti: Does @builddeps@ work for Debian too?
[07:19] <hyperair> huh this is weird
[07:19] <hyperair> raring is EOL?
[07:19] <hyperair> launchpad was rejecting my uploads to raring
[07:19] <hyperair> in a PPA
[07:19] <hyperair> but quantal went through
[07:19] <hyperair> O_o
[07:19] <hyperair> i don't recall quantal being an LTS release
[07:20] <Unit193> That's where they changed down to 9 months, Quantal just went EOL now too.
[07:20] <hyperair> oh right
[07:20] <infinity> hyperair: quantal will start rejecting soon.
[07:20] <hyperair> okay
[07:20] <infinity> hyperair: It was officially EOL on the 16th, but I haven't closed it in LP yet for reasons.
[07:21] <hyperair> i see
[07:24] <infinity> pitti: Taking your silence as a "yes" and committing. :P
[07:27] <Mirv> dbarth: mitya57 ^ asked about when he can upload qtwebkit 5.2 to utopic. can you think of a timeline at the moment when enough has migrated to oxide?
[07:27] <pitti> infinity: sorry, was OTP (meeting with the guys in Malta)
[07:28] <pitti> infinity: yes, autopkgtest has been in sync for ages, @builddeps@ works everywhere (also in ci.d.n)
[07:30] <infinity> pitti: Kay, cool.  Committed upstream, then.  We'll filter that down to Ubuntu after the next experimental upload and merge (which should be this week).
[07:30] <pitti> infinity: nice, thanks (it's not urgent)
[07:30] <pitti> the kernel seems to hit the copy timeouts way more often than eglibc
[07:31] <infinity> pitti: Yeah, I'm torn about all those tests.  I like the rebuild tests for glibc/kernel/gcc/binutils because I'm intensely paranoid about any one of those breaking the others, but they're also crappy tests to be triggered by anything BUT the toolchain.
[07:32] <infinity> pitti: We were discussing in Austin that we'd really like a test stanza called "Triggers-By" or something, where these rebuild tests could be limited to specific packages instead of all rdeps.
[07:32] <pitti> yeah; at the moment the test doesn't know why it was triggered
[07:32] <pitti> passing that will get a lot easier in the AMQP based system
[07:33] <infinity> pitti: Which also has the added bonus that this wouldn't have to work by accident (ie: there's no reason any of these packages actually are rdeps of each other, since they're all build-essential, it's just a fluke that there happen to be enough versioned deps to make it work)
[07:33] <pitti> but not with our shoestring/rsync/jenkins machine
[07:33] <pitti> infinity: yeah, I think we introduced some technically unnecessary linux-libc-dev build dep (or similar) to trigger the reverse dep check
[07:40] <infinity> pitti: Oh, erk, I see the timeout you're talking about is why the current eglibc/amd64 failed. :/
[07:40] <infinity> pitti: How likely is that to fail again if I retry?
[07:40] <pitti> infinity: I already retried an hour or so ago
[07:40] <infinity> I suppose I should just skiptest the thing(s) waiting on it, since I can read the log and see that it's fine.
[07:40] <pitti> infinity: rather unlikely
[07:40] <infinity> pitti: Oh, or you could retry. :P
[07:41] <infinity> Nothing's waiting on it but the kernel, and that build was fine, so I think I'll skiptest the kernel for now.
[07:41] <pitti> 1 hour 18 mins ago, to be precise (run #19)
[07:41] <pitti> the full run takes ~ 4 hours
[07:42] <infinity> Yeah, skipping.  I want to see the britney results before I sleep. :P
[07:42] <pitti> infinity: yes, it's indeed the copying between VM and host which occasionally kills it (there's a timeout of 1 hour, and if the boxes are busy that might take that lnog)
[07:42] <pitti> and 9p is really crappy :(
[07:42] <infinity> I guess something like NFS is out of the question?
[07:43] <pitti> infinity: I'm afraid so; it has a lot of assumptions on the VM (working and unchanged networking, daemons running) and would also need root on the host side, doesn't it?
[07:43] <pitti> not sure if one can run an NFS server as user
[07:44] <infinity> pitti: Oh, yeah, you want root on the host to make it go, I suppose.
[07:44] <pitti> -ECANTHAVEROOT
[07:44] <pitti> if I had root on the host I could use nbd
[07:45] <pitti> and just mount the qemu imae
[07:45] <pitti> image
[07:46] <pitti> infinity: so at the moment 9p is still the bit which needs almost zero assumptions on the testbed and is still reasonably fast for most things
[07:46] <pitti> i. e. I'd like to be able to run autopkgtests against someone's production VM image (all in snapshotting mode of course), or the Ubuntu live system, or what not
[07:47] <michagogo> 10:21:11 <infinity> hyperair: It was officially EOL on the 16th, but I haven't closed it in LP yet for reasons. <--- How long do you expect that to be the case? Long enough to sneak in a fix for bug #1314616 ?
[07:49] <infinity> michagogo: Is there any point?  it's EOL anyway.
[07:49] <infinity> michagogo: I assume the same bug existed in raring, and we're not fixing that either.
[07:50] <hyperair> michagogo: you can always upload to precise and have people in the intermediate releases use the precise PPA
[07:50] <michagogo> infinity: is it known (are there metrics or something) on how many users don't upgrade?
[07:51] <infinity> michagogo: If users don't upgrade, there's not much we can do for them.
[07:51] <michagogo> Actually, guessing not because I don't think I've noticed an option for it
[07:52] <michagogo> infinity: sure, but it would be interesting to know if there is actually a significant set of users running old unsupported releases
[07:53] <infinity> michagogo: There are people still running all sorts of weird old releases, yeap.
[07:53] <infinity> michagogo: I hear from time to time of people running maverick, natty, and oneiric, at least.  But, like I said, not much we can do for people who ignore EOL notices and don't seem to care.
[07:53] <michagogo> infinity: I'm sure. I was more wondering, how many?
[08:07] <apw> pitti, like the sounds of that
[08:15] <pitti> apw: is the above enough, or do you need it in a different format?
[08:17] <apw> pitti, that is sufficient indeed thanks.  your changelog woes are our layered debian thing, debian.<branch>/changelog ftw
[08:18] <zyga> anyone interested in what is apparently a Qt5 bug?
[08:18] <zyga> crash on 2nd monitor disconnect/reconnect
[08:49] <doko> infinity, before you merge eglibc the next time, please remove the systemtap b-d for ppc64el, nice surprises like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231
[08:53] <apw> pitti, ok applied, will be in the next utopic upload
[08:53] <pitti> apw: very nice, thank you!
[09:04] <zyga> cjwatson: do you know of any bugs on upstart leaking memory?
[09:04] <zyga>  3102 zyga      20   0 3129116 2,852g   1404 S  13,7 18,6 198:29.19 init
[09:04] <zyga> 3GB for upstart?
[09:04] <apw> zyga, what release is that ...
[09:04] <zyga> jodh: ^^
[09:04] <cjwatson> zyga: -> jodh
[09:04] <apw> jodh, ^
[09:04] <zyga> apw: utopic
[09:05] <zyga> one day uptime
[09:06] <cjwatson> zyga: (I haven't heard of such a thing though)
[09:06] <cjwatson> zyga: Oh, there's bug 1235649
[09:06] <cjwatson> But that should be fixed in the packages
[09:07] <zyga> seems like something new then
[09:10] <apw> zyga, its not systemic, i have a uptopic here with 7 days uptime and both system and user init are under 10M
[09:11] <zyga> oh
[09:11] <zyga> I have media-hub-server crashing all the time
[09:11] <zyga> like a few times a second
[09:11] <zyga> perhaps that's why
[09:11] <zyga> some process-exit leak?
[09:16] <zyga> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1321204 and https://bugs.launchpad.net/ubuntu/+source/media-hub/+bug/1321203
[09:22] <ogra_> cjwatson, that was graphics driver specific ... only happened on the old galaxy nexus due to the driver calling vsync several times a second
[09:22]  * ogra_ wonders if media-hub is actually supposed to be on desktop at all yet
[09:23] <ogra_> zyga, you should talk to jhodapp (he's at the sprint so should be around in i.e. #ubuntu-touch)
[09:30] <zyga> ogra_: thanks
[09:34] <dbarth> Mirv: sorry (meetings)
[09:35] <dbarth> Mirv: that's about updating qtwebkit for bugfixes? i'm not sure i have the right context
[09:51] <jodh> apw: ack - awaiting zyga's response to my questions on the bug.
[09:53] <Mirv> dbarth: yes, updating qtwebkit for other users besides phone. we did try 5.2 qtwebkit already before, and the only problem we had was OpenGL games. but it's even safer if we're satisfied with the amount of Oxide migrations done, so I'm wondering if we could give mitya57 some idea when the 5.2 could be allowed to go in.
[09:57] <pmcgowan> cjwatson, hi can you approve my reply to ubuntu-devel list
[09:59] <cjwatson> pmcgowan: done
[10:00] <pitti> mbiebl: *sniff* Bug#747662: Removed package(s) from unstable :)
[10:00] <pitti> (hal)
[10:00] <pitti> and it only took like 5 years :)
[10:07] <mlankhorst> infinity: ping?
[10:34] <luv> pitti: hi .... you saw my message?
[10:35] <pitti> 07:58:17      pitti | luv: *shout* :)
[10:35] <pitti> luv: hi :) yes, I did, ^
[10:35] <luv> haha :-)
[10:36] <luv> should get my znc settings sorted out :-)
[10:39] <luv> anyway, when I test on my other 14.04 box and I can confirm it fixes the issue (for me), I will attach patch to the issue. Or is here more to do?
[10:44] <pitti> luv: that sounds good; the compiz devs can then turn it into a merge proposal etc.
[10:45] <pitti> luv: I still get the issue occasionally, although I don't notice that much because my "start session" script has a bunch of gsettings calls to fix stuff
[10:46] <luv> cheers
[10:49] <pitti> seb128: are you aware that your e-d-s upload a week ago is stuck? friend's test started failing a week ago
[10:49] <pitti>     Soup.MemoryUse.COPY, data, len(data))
[10:49] <pitti> TypeError: set_request() takes exactly 4 arguments (5 given)
[10:49] <pitti> seb128: could be because of your e-d-s upload or perhaps a change in soup?
[10:50] <pitti> seb128: ah, https://launchpad.net/ubuntu/+source/libsoup2.4/2.46.0-2ubuntu1 landed on May 12, so probably it's that what broke friends
[10:52] <mlankhorst> can someone review the NEW queue of precise? there's a xorg-lts-trusty stack there waiting to be accepted :-)
[11:18] <michagogo> infinity: btw, which version is in quantal?
[11:18] <michagogo> (it's gone from the packages page...)
[11:18] <cjwatson> Still in +publishinghistory
[11:19] <cjwatson> Top right
[11:22] <michagogo> infinity: never mind, found it on https://launchpad.net/ubuntu/+source/bitcoin
[11:23] <seb128> pitti, no, I was not aware, some days I wish we had email notifications for such things, thanks!
[11:24] <seb128> pitti, likely libsoup yes
[11:24] <seb128> pitti, I can try to have a look in a bit
[11:24] <pitti> seb128: sorry that the pitti notificator has quite some lag
[11:25] <pitti> seb128: at least it now expects one parameter less, so just pick which one to drop :-P
[11:25] <ogra_> you need to work on that, seriously ...
[11:25] <seb128> lol
[11:25] <ogra_> also localized notifications please :)
[11:25] <pitti> ogra_: richtig!
[11:25] <pitti> seb128: le paquet "amis" est malade
[11:25] <stgraber> :)
[11:25] <seb128> heh
[11:26] <mlankhorst> o.O
[11:26] <pitti> le nouveau version de potage à le cassé
[11:26] <mlankhorst> french is still not the default language pack, pitti!
[11:26] <stgraber> I'm sure you could get google translate to give you "vos amis sont malades", that'd be slightly confusing ;)
[11:26] <seb128> pitti, version est féminin
[11:27] <pitti> seb128: ah, merci :)
[11:27] <seb128> de rien ;-)
[11:27] <pitti> mlankhorst: seb128 thinks otherwise
[11:28] <mlankhorst> yeah we patch his copy of ubuntu
[11:45] <ogra_> i'm wondering if someone has an explanation for the pm-utils/powermgmt-base dropping in http://people.canonical.com/~ogra/touch-image-stats/29.changes ... i went through all packages in that change-set, nothing dropped a dependency on these two ... there was no seed change either
[11:47] <ogra_> (and since it is touch, there are no recommends in use, i can see no reason why they would/could be dropped)
[11:48] <zyga> hmm, qtbase-opensource-src seems to FTBFS on utopic
[11:49] <zyga> I was going to file a bug on that, adding libboost-regex-dev fixed it for me (on utopic)
[11:49] <zyga> I tried to reproduce the failure in sbuild but I got a test failure instead
[11:49] <zyga> wtf?
[11:49] <zyga> can anyone more experienced than me just run a test build of qtbase-opensource-src on utopic and tell me if I'm seeing things?
[11:50] <ogra_> zyga, there was an upload a few mins ago ... you could just watch it ;)
[11:51] <brendand> zyga, what do you see?
[11:52] <zyga> brendand: I saw
[11:52] <zyga> FAIL!  : tst_qstandardpaths::testRuntimeDirectory() '!runtimeDir.isEmpty()' returned FALSE. () Loc: [tst_qstandardpaths.cpp(414)]
[11:52] <zyga> ogra_: oh, thanks
[11:52]  * zyga looks at the changelog
[11:52] <zyga> brendand: and before I was seeing a missing linkage dependency on some test tool
[13:21] <mterry> pitti, hello!  Do you know if it's possible to fake having a sim that needs to be unlocked for my mako device?
[13:25] <pitti> mterry: yes, it is
[13:25] <mterry> yay!
[13:25] <pitti> mterry: for that you need to start ofono-phonesim with a different xml
[13:25]  * pitti looks
[13:25] <pancakes9> hey guys, I'm a new contributor
[13:25] <pitti> - Modify default.xml: Set PINNAME from "READY" to "SIM PIN", set SC from 0 to 1, run phonesim with that
[13:25] <pitti> - can be unlocked with /usr/share/ofono/scripts/enter-pin pin XXXX
[13:25] <pitti> mterry: ^
[13:25] <pancakes9> Am I in the right channel for asking for help on how to get started?
[13:26] <pitti> mterry: you should talk to Wellark, I think he already set this up for some app
[13:26] <mterry> pitti, thank you so much!  I'll try it out and bug Wellark if needed  :)(
[13:27] <pitti> mterry: oh, and obviously PINVALUE (defaults to 2468, but you can change it of course)
[13:31] <ogra_> pancakes9, probably #ubuntu-motu is better
[13:31] <pancakes9> ogra_: thanks
[13:36] <lool> would someone mind giving a quick look at: http://paste.ubuntu.com/7492987/ ?  sicne it's fakeroot I'd like another pair of eyes on it; I've tested that it fixes the issue and have done a test build with it (hello-debhelper)
[13:44] <pitti> sil2100: do you know who landed unity-scopes-api? it apparently broke the unity-scopes-click test
[13:44] <pitti> sil2100: with the autolanding we don't have proper uploaders and thus the usual autopkgtest notification mails don't work
[13:44] <pitti> sil2100: i. e. unity-scopes-api is held back in -proposed due to that
[13:44] <pitti> and the new unity8 too
[13:45] <seb128> Mirv, ^
[13:45] <seb128> ogra_, ^
[13:46] <ogra_> pitti, Mirv
[13:46] <seb128> (they were just discussing unity8 in ci-eng)
[13:46] <pitti> Mirv: hello :) so please consider you notified
[13:46] <Mirv> I did not land tha tone
[13:46] <Mirv> so the scopes were landed by mhr3
[13:46] <seb128> Mirv, but you were asking about unity8 not migrating
[13:47] <Mirv> and I landed unity8 separately
[13:47] <ogra_> oh, that was sil2100 actually
[13:47] <pitti> jibel: seems I must gradually abolish my first "retry the test" reflex, except for the linux and eglibc timeouts I haven't seen an infrastructure failure since the apt-get race fix \o/
[13:47] <ogra_> (-scopes-api)
[13:47] <Mirv> seb128: yes, it seems we have the culprit then
[13:48] <pitti> sil2100, Mirv: you guys know about http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html ? (in case you wonder where your landings are stuck)
[13:48] <didrocks> pitti: you have sil2100 as the guy publishing it :)
[13:48] <Mirv> pitti: yes, I was just not first assuming it's a real error since there have been various autopkgtest problems earlier last week and so
[13:49] <didrocks> but we'll need to come to the discussion in Malta about showing off the guy clicking the package publishing or the lander :)
[13:49] <pitti> Mirv: right, my usual first assumption is "broken infrastructure" too due to long training, so I still review every single failure :)
[13:49] <Mirv> so is there an option of rejecting the scopes-api so that unity8 can pass?
[13:49] <pitti> and then play pitti-notification-bot
[13:49] <pitti> Mirv: we can remove bad packages from -proposed
[13:49] <pitti> that might lead to bzr branches getting out of sync, though
[13:49] <cjwatson> pitti: Autolandings should now have an at least somewhat useful sponsored field, FYI
[13:50] <Mirv> yes I've noticed a lot of magic happening "automatically" (by you or colin)
[13:50] <pitti> although you only really merge after it propagated, right?
[13:50] <cjwatson> So it should be possible for autopkgtest to scrape that out
[13:50] <pitti> hmm, https://launchpad.net/ubuntu/+source/unity-scopes-api/0.4.6+14.10.20140519-0ubuntu1 still only shows "buntu daily release<EMAIL_ADDRESS>[13:50] <pitti> oh, from https://launchpad.net/ubuntu/utopic/+source/unity-scopes-api/0.4.6+14.10.20140519-0ubuntu1
[13:50] <Mirv> pitti: yes the merge & clean is only done after it's in release pocket
[13:50] <pitti> Copied from ubuntu utopic in Landing PPA 011 by Łukasz Zemczak
[13:51] <sil2100> I'm back
[13:51] <sil2100> pitti: thanks for the info! uh!
[13:51] <seb128> mhr3, hey
[13:51] <pitti> Mirv: so yes, we can (and often have) remove stuff from -proposed when it introduced regressions; the version number will be "burned" then, and potentially the status needs to be updated in MPs/landings/etc.
[13:51] <seb128> pitti, do you have a link to the test errors for mhr3?
[13:51] <pitti> hey sil2100
[13:52] <pitti> it's linked from excuses
[13:52] <seb128> pitti, Mirv, sil2100: let's see if we can sort it out rather than deleting
[13:52] <pitti> https://jenkins.qa.ubuntu.com/job/utopic-adt-unity-scope-click/40/ARCH=i386,label=adt/console
[13:52] <seb128> mhr3, ^
[13:52] <seb128> pitti, danke
[13:52] <pitti> although there seems to be more than one problem there
[13:52] <cjwatson> Mirv: Well.  I try to reduce the amount of stuff running from cron.cjwatson where I can ;-)
[13:52] <pitti> Failed to get D-Bus connection (Cannot autolaunch D-Bus without X11 $DISPLAY)
[13:53] <pitti> -> missing xvfb-run?
[13:53] <pitti> the "g_signal_handlers_disconnect_matched: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
[13:53] <pitti> and several test failures
[13:54]  * sil2100 still reads the logs for the failure
[13:54] <mhr3> the click failures are hardly caused by -api
[13:54] <pitti> sil2100: that autopkgtest just builds the package, so it's FTBFS
[13:55] <sil2100> pitti: that is strange, as it built fine in the PPA
[13:55] <sil2100> Otherwise it wouldn't be publishable
[13:55] <sil2100> hmm
[13:55] <pitti> sil2100: was unity-scope-click built against the new unity-scopes-api?
[13:56] <pitti> sil2100: by the time of the upload to Ubuntu it seems the last build happened against a previous scopes-api
[13:56] <sil2100> Ah, crap, indeed, it was just scopes-api and scopes-shell
[13:56] <pitti> anyway
[13:56] <pitti> I'm really happy that this britney/adt stuff works fairly reliably now
[13:56] <sil2100> Miss-checked that one, strange stuff
[13:56] <pitti> turning "OMGwebroketheimage" into "let's take time and fix it properly without rush"
[13:56] <dobey> hmm
[13:58] <sil2100> Let me poke upstream about that one first thing
[14:02] <sil2100> pitti: thanks for letting us know about this! The unity-scope guys already got informed and know of a possible fix
[14:02] <pitti> nice!
[14:28] <mhr3> pitti, so in this case there was an issue in -click's tests, and that now prevents -api to be published, not sure if such a failure should be automatically considered something fatal
[14:29] <pitti> mhr3: we consider it fatal if a package's tests succeeded, and started failing if one of its dependencies got updated
[14:29] <pitti> then we hold back that dependency
[14:30] <pitti> there are certainly situations where it fails for a different reason, but the probability is quite high that this dependency update was the culprit
[14:30] <pitti> mhr3: so if clicks' tests now fail due to something different, the release team can override that to let -api pass
[14:30] <ScottK> pitti: seems to me the larger issue is non-devlopers having upload access to the archive via autolanding.
[14:31] <ogra_> ScottK, only after a core-dev reviewed thee packaging changes
[14:31] <ScottK> So?
[14:31] <ogra_> (and an upstream dev had to cross review the upstream changes first)
[14:31] <ogra_> thats not much different to sponsoring
[14:32] <ScottK> Except for no Ubuntu devs look at it.
[14:32] <mhr3> pitti, well, no, the system is right that the updated -api caused the -click's tests to fail, but they were doing something wrong in the first place
[14:33] <seb128> mhr3, that still points to an issue somewhere (the tests in that case), and you can't know the reason is advance, so blocking is the right thing to do
[14:33] <mhr3> pitti, it just feels that library developers are suddenly responsible for all rdeps
[14:33] <seb128> mhr3, they are to make sure they don't create any bugs in their rdeps yes
[14:33] <ogra_> ScottK, hmm ? you mean a core-dev isnt an ubuntu dev ? the landing cant go in unless a core-dev had nodded it off ... the only diifference to actual sponsoring is that the landing is done in piecemeal
[14:34] <pitti> mhr3: of course not, if the -click test is wrong then the -click author should fix it
[14:34] <pitti> but we can't just let in any uplaod which breaks a dependency, then the whole thing woudl be pointless
[14:34] <ogra_> ScottK, so the core-dev never sees the full picture ... only the packaging changes ... which can cause issues like above
[14:34] <mhr3> pitti, sure, but until that happens, others are blocked from using the new lib
[14:34] <ScottK> oct
[14:35] <pitti> mhr3: yes, intentionally (if it causes a regression or API change then it should not land yet)
[14:35] <ScottK> Oops
[14:35] <mhr3> pitti, don't get me wrong, it's good that we get notified about it, i'm just questioning the concept of auto-block
[14:35] <pitti> mhr3: NB, I'm not saying that this did cause an API change, but the failure/holding back in -proposed would look exactly like that
[14:35] <ogra_> nov :)
[14:35] <pitti> mhr3: what would be the alternative?
[14:36] <pitti> mhr3: it gets blocked, we investigate it, we might decide it's wrong and override it; or it's right and we need to fix something
[14:36] <mhr3> pitti, guess it would have to be assessed on a case-by-case basis
[14:36] <pitti> right, it is
[14:36] <mhr3> alright, so there is the ignore button somewhere? :)
[14:36] <cjwatson> mhr3: We fail safe and can assess and override case-by-case.  I don't see the problem
[14:36] <mhr3> good to know
[14:36] <pitti> mhr3: yes, as I said the release team can override it (it's a bzr commit)
[14:37] <mhr3> k, then all is fine i guess
[14:37] <cjwatson> Though generally in this kind of case I'd still prefer to see the rdep passing, to make sure that a test suite problem isn't masking something else
[14:39] <ScottK> ogra: For sponsorship, an Ubuntu dev has the whole upload. For uploads with no packaging changes, who reviews that?
[14:39] <ogra_> ScottK, upstream
[14:39] <ogra_> the owning team of the upstream branch
[14:40] <ScottK> Right. As I said, non-Ubuntu developers have upload rights.
[14:40] <ScottK> Which violates the trust model of the distro.
[14:41] <ogra_> well, with a lot more hurdles to take than dputting :) they are not actually uploading to the archive
[14:41] <ogra_> and the change goes through the landing team first (which consist of devs and non devs admittedly)
[14:43] <dobey> mhr3, pitti, cjwatson: well, it's clear why the test is failing, and the failure isn't masking an issue in the runtime click scope code. i think it's fine to "ignore" the failure in the click scope autopkgtest and push the scopes-api landing through, in this case, as long as click-scope is the only thing with broken tests
[14:43] <ogra_> after all such a landing gets a significant amount more review than a core-dev doing a dput ... i wouldnt see the trust model violated but rather improved by this
[14:48] <dobey> mhr3, pitti, cjwatson: so are we going to push scopes-api landing through despite the click-scope failure (which is a bug i can fix today), or do i need to propose a branch now and get click-scope in the same silo?
[14:48] <cjwatson> dobey: Is there a branch somewhere that fixes the bug?
[14:48] <sergiusens> cjwatson: is there an ETA for adding the click 14.10 framework?
[14:48] <cjwatson> If it's fixable today, I'd honestly be more comfortable if we did that
[14:48] <cjwatson> sergiusens: no
[14:49] <sergiusens> cjwatson: there are breaking changes in the clicks, reason why I ask
[14:49] <cjwatson> sergiusens: do you mean breaking changes in the platform?
[14:49] <sergiusens> cjwatson: yes, in the content-hub
[14:49] <cjwatson> ok, so that would be a good reason to do it
[14:49] <cjwatson> lool: ^- any objection to me adding ubuntu-sdk-14.10-dev1 et al?
[14:50] <dobey> cjwatson: nearly; i think fixing it directly in click scope trunk will result in a conflict with a branch that we landed in our devel yesterday, so i'd prefer to avoid that and merge into devel then merge devel into trunk (which has more changes than just this fix).
[14:50] <sergiusens> cjwatson: does beuno need to do anything for this?
[14:50] <cjwatson> sergiusens: I'm afraid I don't know
[14:50] <mhr3> dobey, the fix is pretty tiny, no? if it can be done in <15minutes let's just do it
[14:50] <dobey> sergiusens: yes i think the store db has to be updated with the new frameworks
[14:50] <mhr3> dobey, then even the conflict will be tiny :)
[14:50] <dobey> mhr3: yes the fix is tiny
[14:51] <cjwatson> dobey: we should get the test failure fixed before landing further changes, IMO
[14:51] <dobey> mhr3: i just switched away from my workspace where i have the code open, back to irce, and saw you discussing it with pitit here
[14:51] <dobey> mhr3: so i didn't want to waste time making an MP and all, if it was just going to get ignored for the moment :)
[14:52] <mhr3> dobey, it won't be ignored, the silo is waiting for it
[14:53] <ogra_> ... and unity8 ... and the anticipated image build ...
[14:53] <lool> cjwatson: not at all, I had it locally actually but waited for the new security permission implementation to land
[14:53] <dobey> mhr3: https://code.launchpad.net/~dobey/unity-scope-click/fix-query-tests/+merge/220280 should fix it
[14:54] <sergiusens> dobey: so there's no need to update anything in the click scope for a new framework
[14:54] <mhr3> sil2100, got the fix, can you reconf 011?
[14:54] <cjwatson> lool: ah, I don't know whether jdstrand is ready for it
[14:54] <sil2100> mhr3: on it
[14:54] <dobey> sergiusens: not in the scope itself, no. we read the frameworks from the system. the server db needs updated though, so people can actually upload clicks that use the new framework, iirc
[14:56] <lool> cjwatson: ah actually motivation for the change is to pick up an ABI breakage, so discussing this here
[14:56] <lool> ABI addition is ok, but not ABI breakage
[14:56] <sil2100> mhr3: reconfigured
[14:56] <sil2100> mhr3: you can build o/
[14:56] <mhr3> sil2100, enough to build click itself?
[14:57] <sil2100> mhr3: yes, I guess mentionin only u-s-c is what we would like
[14:57] <cjwatson> mhr3: Hm?  I already have another silo containing click itself
[14:58] <mhr3> cjwatson, sorry, i'm talking about click scope
[14:58] <cjwatson> So you mean "enough to build unity-scope-click itself"?
[14:58] <mhr3> yes
[14:58] <cjwatson> OK
[15:08] <lool> cjwatson: bottom line is that we're reverting the content-hub and corresponding browser changes to revert the ABI breakage
[15:09] <cjwatson> OK
[15:10] <cjwatson> mvo_: your click change to disable apps when their framework goes away works beautifully on my device
[15:10] <cjwatson> I'm sure you knew that, but just for the record :)
[15:13] <lool> cjwatson: mind looking at the debdiff I've put in LP #1290069 ?
[15:14] <cjwatson> lool: Maybe a bit later this afternoon
[15:14] <cjwatson> (meetings etc.)
[15:14] <lool> ok
[15:15] <lool> pitti: would you by change have a minute to look at the debdiff in LP #1290069 ?
[15:15] <beuno> sergiusens, cjwatson, yes, I need to add it to the store so we can accept apps. Just say when.
[15:15] <mvo_> cjwatson: \o/ thanks for confirming
[15:37] <tarpman> luv: did you see the recent comments on bug 1063617? even if your patch isn't fully tested yet, might be worth posting your WIP to the bug (btw thanks for working on it!)
[15:39] <luv> tarpman: cool ... I will post my findings and the patch this evening to save the guy the countless hours in gdb :-)
[15:39] <tarpman> luv: thanks!
[15:39] <luv> no probs :-)
[15:40] <luv> just got so annoyed (and it has been in for almost two years! :-( ) so I just had to fix it
[15:56] <Elv1313> Hi, can someone upload the patch for bug 1316612?
[15:56] <Elv1313> it is already confirmed and tested by 2 users, it probably affect ~40% of all sflphone-kde users, so I it would be nice if the process could be speeded up a little
[15:58] <Riddell> Elv1313: I'm about to leave but if you e-mail me I can look at it tomorrow
[15:58] <rbasak> Elv1313: you want to get that into the sponsorship queue. Attaching a debdiff suitable for applying to Utopic should do this automatically for you.
[15:59] <rbasak> I was about to say that you could try poking a patch pilot on here when one appears in the channel topic, but it sounds like Riddell will help.
[15:59] <Elv1313> Riddell: ok
[16:01] <pitti> lool: sorry, was out for errands; looks good to me (and also upstreamable)
[16:04] <lool> pitti: thanks
[16:06] <Elv1313> rbasak: Thanks, pulling "bzr branch lp:sflphone" only give me the tranlations, is there a repository where I can pull/push patches or "debian/" scrips changes?
[16:07] <rbasak> Elv1313: try "bzr branch lp:ubuntu/sflphone".
[16:07] <rbasak> Elv1313: I tend to use debdiffs directly without bzr. For that, "pull-lp-source sflphone" will give you the current Utopic unpacked source package.
[16:08] <rbasak> Elv1313: you'll want to add the patch to debian/patches, with dep3 headers so that future developers can trace the origin.
[16:09] <Elv1313> rbasak: is it possible to also add them to trusty?
[16:09] <rbasak> Elv1313: when you're done, you can submit a bzr merge proposal on Launchpad, or just attach the debdiff to the bug. For the latter, I think a bot will come along and subscribe ~ubuntu-sponsors to the bug, or you can do that directly.
[16:09] <rbasak> Elv1313: you can see the sponsorship queue at http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html...
[16:10] <rbasak> Elv1313: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure for the process for updating Trusty.
[16:10] <rbasak> Elv1313: in general Utopic needs to be fixed first, and backported fixes need to be high-impact or otherwise meet the criteria defined higher up on that page.
[16:10] <rbasak> Elv1313: HTH.
[16:16] <Elv1313> rbasak: So far errors.ubuntu.com found ~15 segfault of critical asserts for the gnome (sflphone) client and 2 deadlocks for the kde client. We have patches for ~5 of them so far, but most are stuck in unconfirmed launchpad bug reports. I think crashes are critical enough to get backported.
[16:18] <rbasak> Elv1313: that sounds reasonable. The SRU team usually makes the decision based on the bug description after upload.
[16:19] <rbasak> Elv1313: so just be sure to justify it in the bug, and you should be OK. It's mainly the trade-off between the bug impact and the regression risk that matters.
[16:19] <Elv1313> we will have a new release in time for Utopic, so there is little point to push those fixes into 14.10
[16:20] <rbasak> The risk is that it won't make Utopic, and then Utopic will regress the fixes pushed back to Trusty. I think that's the reason that it's generally required to be fixed in Utopic first.
[16:20] <rbasak> So I guess you can wait on the new release in Utopic before fixing Trusty, or fix Utopic with the patches now, or get an exception from the SRU team.
[16:22] <Elv1313> ok, thanks
[16:39] <sl33k_> I want to volunteer contributing code, triage bugs. Would I be able to help with less relevant experience?
[16:41] <Elv1313> sl33k_: helping getting bug fixed faster if the most helpful thing there is
[16:48] <rbasak> sl33k_: there are a ton of bugs with a "please provide a patch" type status. Help with these would be most welcome.
[17:00] <Elv1313> sometime, simply getting in contact with an upstream dev is enough. They may not be aware fo the issue or it might already have been fixed, but never backported
[18:54] <mapreri> pitti: thanks :) (even if I'm wondering which hours you work: I did not image you work during "office hours"...)
[19:45] <xnox> mapreri: it is office hours =) just without timezone defined ;-)
[19:51] <zyga> hmm, is python-virtualenv just broken now on utopic or did I mess up my system somehow?
[19:51] <dobey> is there anyone i can beg to accept some SRU packages to their appropriate -proposed channels?
[19:51] <zyga> http://pastebin.ubuntu.com/7494459/
[19:51] <dobey> zyga: not a useful or definite answer, but i only want to reply with "yes" :)
[19:51] <zyga> barry: ^^ ?
[19:52] <zyga> dobey: well, less strict parsing may be needed ;)
[19:52] <zyga> barry: is that wheel related by any chance?
[19:52] <dobey> zyga: why are you running python3 code in a 2.7 virtualenv?
[19:52] <zyga> dobey: I
[19:53] <zyga> dobey: I'm running what used to work: virtualenv -p python3 /some/path
[19:53] <zyga> dobey: worked from 12.04 till yesterday
[19:54] <dobey> huh
[19:54] <zyga> dobey: that's *the* way to get a useful python3 virtualenv AFAIK
[19:57] <Unit193> pitti: On initramfs-tools?  I'd think busybox as zz-busybox runs before busybox.
[19:57] <barry> zyga: not that i know of.  none of the wheels stuff has landed in debian yet (in progress).  it won't affect virtualenv anyway, just pyvenv
[19:57] <Unit193> (I put a dep from the one on the other, fixed.)
[19:58] <barry> zyga: seems to work for me
[19:58] <zyga> barry: can you check if that's broken on your (utopic) box by any chance?
[19:58] <zyga> hmmm
[19:58] <dobey> sigh. why are simple SRUs so hard to do?
[19:58] <zyga> dobey: I feel your pain
[19:58] <barry> zyga: virtualenv -p python3 /tmp/pp
[19:58] <barry> source /tmp/pp/bin/activate
[19:58] <barry> pip install nose2
[19:58] <barry> all seems happy
[19:59] <zyga> barry: it crashes for me as linked above
[19:59] <zyga> python-virtualenv changelog is old so nothing new landed lately
[20:03]  * zyga has installed python-configparser lately though, let's see if removing it helps
[20:03] <dobey> that could certainly result in what you are seeing
[20:04] <zyga> dobey: yeah
[20:04] <zyga> confirmed
[20:04] <zyga> removing python-configparser fixes it
[20:05] <dobey> is that some "let's backport the new python3 module to python2" thing?
[20:05] <zyga> barry: yeah
[20:05] <zyga> barry: can you install and check it happens on your copy too
[20:05] <zyga> oh, it's probably being imported
[20:05] <zyga> and the code doesn't fall back to 2.7 imports
[20:06] <zyga> or equivalent stuff
[20:06] <zyga> sounds plausible
[20:06] <zyga> yeah, exactly
[20:06] <zyga> damn :) I need that package and working virtualenv
[20:06] <zyga> :-)
[20:06]  * zyga wonders what to do
[20:06] <dobey> why do you need that package?
[20:07] <zyga> dobey: checkbox-support needs it to work on python2.7 which is a new requirement for us so we just have to have it :/
[20:07] <zyga> dobey: (it's 3.2+ right now)
[20:07] <zyga> dobey: well, 101 patches make it 2.7+ compatible though
[20:07] <dobey> zyga: can't you just do the appropriate try/except in checkbox directly?
[20:07] <zyga> https://code.launchpad.net/~zkrynicki/checkbox/fix-1319767/+merge/220318
[20:07] <zyga> dobey: that's a virtualenv problem though
[20:08] <zyga> dobey: oh, you mean to use the old import name
[20:08] <zyga> hmm
[20:08] <zyga> maybe
[20:08] <dobey> yes, that's what we did in u1 stuff
[20:08] <zyga> good idea, I will probably do just that
[20:09] <dobey> i generally try to avoid those "py2.7 compat versions of py3 modules" things because they tend to cause more problems than not (like the one you're having now) :)
[20:09] <zyga> still that package is broken
[20:09] <zyga> dobey: well, I tend to avoid 2.7 entirely ;)
[20:09] <zyga> they should always have different import name
[20:09] <dobey> well i guess there's a reason it's not in corelib
[20:09] <zyga> I mean, come on
[20:09] <zyga> dobey: configparser?
[20:10] <zyga> dobey: it is in python3
[20:10] <dobey> well whatever package that is, yes
[20:10] <zyga> dobey: corelib I assume that's python stdlib?
[20:10] <zyga> (or am I mistaken and you meant something else)
[20:10] <dobey> yeah i meant std lib
[20:11] <dobey> configparser is in python2.7 and ConfigParser is in python3.
[20:11] <dobey> so there shouldn't be any need to install a "python-configparser"
[20:11] <dobey> especially one that breaks things
[20:11] <zyga> ah, I understand your comment now then
[20:12] <zyga> yeah, I didn't check, I just assumed it's not in 2.7 and there's a 3 backport
[20:12] <zyga> I'll get rid of it
[20:12] <dobey> python-configparser is a package that is the result of someone trying to be clever, but actually being stupid :)
[20:13] <dobey> some of those are literally just someone ripping the code straight out of py3, adding a setup.py to install it in 2.7, and calling it a day. no tests or guarantee that it works or anything
[20:13] <barry> zyga: sorry, got stuck on the phone
[20:14] <zyga> barry: no worries, I think a debian bug is in order on python-configparser, I'll try to sort that out
[20:14] <dobey> ugh, someone packaged it in debian? even worse :)
[20:14] <barry> zyga: LP: #1156704
[20:15] <zyga> barry: it's quite old!
[20:15] <barry> zyga: yeah.  i'll see if i can spend some time on it
[20:15] <barry> it's been on my backburner for a while ;)
[20:15] <dobey> rm /pool/p/python-configparser*
[20:16] <dobey> problem solved!
[20:16] <zyga> oh yeah
[20:16] <zyga> please
[20:16] <zyga> unless the backport has some new code that has merit
[20:17] <barry> it would be for bilingual code
[20:17] <dobey> not really
[20:18] <zyga> barry: if the 3 rewrite and backport has any extra features, otherwise virtualenv, which is bi-lingual just chokes on the code
[20:19] <dobey> bilingual code would do the right thing and "try: import ConfigParser except ImportError: import configparser as ConfigParser" or similar
[20:19] <barry> actually, it looks like there are few revdeps on python-configparser, and configglue isn't one of them any more
[20:19] <zyga> yeah, there are three
[20:19] <dobey> taking the code from py3 stdlib and shoving it in py2 doesn't make code "bilingual"
[20:19] <barry> zyga: so "apt-get purge python-configparser" ? :)
[20:20] <dobey> yeah, i think i complained loudly about configglue doing that at some point
[20:20] <zyga> barry: yeah, already did that
[20:20] <barry> \o/
[22:05] <mikey85> I was banned from like every Ubuntu because of ikonia throwing false statements at me
[22:05] <mikey85> I have proof
[22:06] <mikey85> http://irclogs.ubuntu.com/2014/05/20/%23ubuntu.txt
[22:06] <sarnold> mikey85: try #ubuntu-irc or #ubuntu-ops
[22:06] <mikey85> I've been banned in both
[22:06] <sarnold> mikey85: it would be better to bring your own logs, because the irclogs don't include your hostmasks.
[22:06] <mikey85> ikonia has been wreeking havoc on me
[22:06] <Corey> mikey85: You're rapidly becoming a cross-channel problem. Please desist.
[22:06] <mikey85> no corey
[22:06] <mikey85> you guys have been accusing me falsely
[22:07] <sarnold> mikey85: note though that even though it does appear someone was impersonating you, you did not appear to take advice well.
[22:07] <Corey> mikey85: There's a process to appealing op decisions within Ubuntu; this isn't it.
[22:07] <mikey85> But still, they can atleast hear me
[22:07] <mikey85> she's going to get me banned on every Ubuntu chan and I can't let that happen
[22:08] <Corey> mikey85: You're doing it to yourself at this point. Please desist.
[22:08] <mikey85> corey leave me alone please
[22:09] <sarnold> s/did not/do not/ ... sigh. thanks Corey.
[22:15] <roasted> hello


[06:45] <dscassel> BobJonkman: Oh no! I'll be in Toronto for an Eclipse Demo Camp on the 16th.
[12:18] <BluesKaj> Hiyas all
[15:15] <dscassel> FYI, the LoCo council session discussing splitting Canada into province teams (ie, renaming to Ubuntu Ontario) is on now in #ubuntu-uds-bonaire4
[15:15] <dscassel> Listen in here: http://icecast.ubuntu.com:8000/bonaire4.ogg.m3u
[15:16] <dscassel> They're talking about language teams now.
[16:06] <dscassel> Nothing good will come of it, but I'm seriously debating a rant on the planet.
[16:06] <BluesKaj> dscassel:  http://icecast.ubuntu.com:8000/bonaire4.ogg.m3u , crashes firefox when i try ro run it.
[16:07] <dscassel> BluesKaj: Yeah, genii-around was saying the same thing.
[16:07] <dscassel> It's over now anyway.
[16:07] <BluesKaj> ok
[16:07] <dscassel> They weren't paying any attention ot the irc channel. :/
[16:08] <dscassel> Just a bunch of people who aren't affected by the decision agreeing amongst themselves that it was a good idea.
[16:08] <BluesKaj> dscassel:  which chat ?
[16:09] <dscassel> THe LoCo council meeting about whether to split Canada (and Australia) into province teams.
[16:10] <dscassel> They care way more about hypothical CD distribution than I do.
[16:11] <dscassel> Hypothetical because if it goes ahead, there won't be any more teams.  Ubuntu Canada becomes Ubuntu Ontario, and that's it.
[16:12] <genii-around> We don't get to autonomously decide what's best for ourselves?
[16:16] <BluesKaj> heh, I contact some linux guys in sudbury and they were all redhat/fedora types , so I just let it go
[16:16] <BluesKaj> contacted
[16:17] <BluesKaj> there ewere only about 10-11 ppl in their "club"
[16:18] <BluesKaj> BBL..
[16:29] <FiReSTaRT> hey guys.. just a brief announcement (been busy as hell).. finally installed oneiric and went with KDE since i don't own a tablet :P
[16:40] <BluesKaj> FiReSTaRT, lots of former gnome ppl are switching , but KDE has a few probs still altho nothing like the drastic changes on "ubuntu"
[16:59] <dscassel> Sorry, back from lunch.
[16:59] <dscassel> FiReSTaRT: I don't own a tablet either, but I'm a fan of unity.
[17:00] <dscassel> Reason: Keyboard shortcuts rock.  Tablets don't have keyboards.
[17:00] <dscassel> Anyway.
[17:00] <dscassel> genii-around: Apparently not.
[17:00] <dscassel> We'll see how it goes.
[17:01] <dscassel> BluesKaj: Nothing wrong with Red Hat/Fedora people.
[17:01] <dscassel> Although one of htem apparently took over the Mississauga Ubuntu Meet-up and essentially killed it.
[17:03] <BluesKaj> dscassel, I didn't say there was anything wrong with them , but they could have told me and they did call themselves Linux when they really should have called it Redhat -Linux
[17:05] <dscassel> BluesKaj: That's why I like calling things "Ubuntu."  It all sounds like muttering to me
[17:07] <dscassel> genii-around: Nobody gets close enough to the mic.
[17:07] <dscassel> There was one joker who leaned into the mic at the end of a session and said "Boo!"
[17:07] <dscassel> Practically blew out my eardrums. :P
[17:07] <genii-around> Heh, bastard
[17:08] <genii-around> I tried to listen to the one in bonaire5 on kubuntu accessibility ... mutter-mutter-mutter LOUD CROWD LAUGHING mutter-mutter .... etc
[17:09] <dscassel> I've had to turn everything up way high and keep a finger near the volume controls...
[17:11] <genii-around> bonaire3 looks intriguing
[17:11] <dscassel> Everybody's on lunch now, right?
[17:12] <dscassel> I'm kinda annoyed with the whole thing at this point. Plus, I've got work to do. :P
[17:13]  * genii-around pretends not to hear the phone on his desk ringing
[17:13] <dscassel> heh. :)


[19:10] <u0_a390> does anyone know a port thats works with my device ( Samsung Tab S8 ) i dont want to accidentally break my device if there is already a port for


[16:20] <vish> coz_: https://launchpad.net/~ubuntugnometeam
[16:20] <vish>  <coz_> anyone remember the gnome3 project for ubuntu mentioned here about a week ago?
[16:22] <coz_> vish,  yeah that was one but there was another fellow who is creating a revision that is not from ppa  but an ubuntu with gnome3 preinstalled
[16:22] <vish> oh.. maybe i missed it.. :)
[16:24] <coz_> vish,  its no biggie.. i tried fedora 15  with gnome3  and it was nice and just found compiz can run fine on the fallback mode


[09:58]  * kaxing hello, I've noticed 12.04.3 image is not yet on http://old-releases.ubuntu.com/
[10:43] <cjwatson> kaxing: It's possible I forgot to push that change, let me try
[10:44] <cjwatson> (Even if this works it'll take ages though)
[10:54] <kaxing> cjwatson, thanks!
[17:32] <doko> please could somebody accept gccgo-4.9?
[20:49] <med_> stokachu, thanks for http://astokes.org/customizing-fastpath-curtin-installations/
[21:09] <stokachu> med_: np man :D
[23:38] <rbasak> https://launchpad.net/ubuntu/+source/nginx/1.4.1-3ubuntu1.2/+build/5587112
[23:38] <rbasak> "INFO Rejection during accept. Aborting partial accept."
[23:39] <rbasak> Do I just need to hit the rebuild button for that?
[23:39]  * rbasak hasn't seen that before
[23:41] <infinity> rbasak: Yeah, that's LP pooping itself slightly, just retry.


[11:32] <lord4163> Helluw :)
[11:33] <lord4163> Does anyone know where I can edit the "home lens"?
[11:33] <lord4163> So it will look good again in Ubuntu 12.04
[11:39] <lord4163> anyone?
[14:53] <nik90> hyperair, ping
[14:54] <hyperair> pong
[14:54] <hyperair> nik90: pong
[14:55] <hyperair> hang on, i think my network's gonna go
[14:55] <nik90> hyperair, can you set the bug priority to high...its a potential precise blocker.. https://bugs.launchpad.net/unity/+bug/982343
[14:56] <hyperair> i don't think it's a precise blocker though..
[14:56] <hyperair> i think it would be better if you ask one of the unity devs
[14:57] <nik90> oh, i thought you were one
[14:57] <hyperair> and for the record, nothing's (to my knowledge) blocked ubuntu's release since 6.06
[14:57] <hyperair> a bug like this is really minor to be called a "precise blocker"
[14:57] <nik90> well it can be confusing to new users to see the icon still in the launcher
[14:58] <hyperair> but that's about it. it's not a complete showstopper. not everyone installs apps from there either
[14:58] <nik90> what installing apps from the usc? I thinnk a lot of users do
[14:58] <nik90> but yeah it is not a blocker..
[14:58] <hyperair> hang on, usc or unity?
[14:59] <nik90> well this bug occurs when you install apps from the usc
[14:59] <nik90> if you cancel the installation, the app icon is still present in the launcher
[14:59] <hyperair> on the unity launcher?
[14:59] <nik90> yes
[14:59] <nik90> on the unity launcher
[14:59] <hyperair> wait, i didn't know they even ended up in the launcher to begin with..
[14:59] <nik90> oh..well it was added with unity 5.8 onwards
[15:00] <hyperair> i thought you had to explicitly add it to the unity luancher?
[15:00] <nik90> every app that you install from the usc, is automatically (by default) added to the unity launcher
[15:00] <nik90> you have the option to disable this option in the usc though
[15:00] <hyperair> O_o that must get cluttered pretty fast..
[15:00] <nik90> but by DEFAULT, it goes into the launcher
[15:00] <hyperair> you're talking about the launcher, right? the bar on the left?
[15:00] <hyperair> not the dash?
[15:00] <nik90> yes yes the bar on the left (unity launcher)
[15:00] <nik90> :)
[15:00] <nik90> you can try for yourself
[15:00] <hyperair> lemme try...
[15:02] <hyperair> oho so it does.
[15:02] <nik90> yup
[15:02] <nik90> so you think the bug deserves a high priority?
[15:05]  * hyperair shrugs
[15:05] <hyperair> let the unity developers handle it
[15:05] <hyperair> i see it as a minor inconvenience
[15:05] <hyperair> a mostly cosmetic thing.
[15:06] <nik90> ok
[19:13] <AlanBell> probably a davmor2 question
[19:17] <malin> my lense won't start atuomatically.
[21:28] <mhall119> malin: using the wikipedia tutorial?
[21:29] <mhall119> you need to run "quickly run" after you "sudo quickly install"
[21:29] <malin> mhall119: ah, so that's the command. Nope. I am working on my own lense :)
[21:30] <malin> the lense autostart, but the scope dosen't
[21:30] <mhall119> malin: using Singlet and Quickly?
[21:34] <malin> nope
[21:34] <malin> this is my project: http://bazaar.launchpad.net/~malinkb/unity-buss/unity-buss-experimental/files/head:/
[21:35] <malin> and I have installed the .lens file to /usr/share/unity/lenses/<name on my lense>/
[21:35] <malin> .service to /usr/share/dbus-1/services/
[21:35] <malin> and the file called buss to /usr/lib/unity-lense-<name of lense>/
[21:40] <malin> mhall119: the only thing I can not do is to make the entire lens to start automatically :)
[22:16] <davidcalle> malin, what does your .service file look like?
[22:18] <davidcalle> malin, maybe it's because your daemon file is not an executable. Right click on it, in properties -> permissions -> check "Allow executing file as a program"
[22:18] <malin> davidcalle: that might be it. I will check it. I did an ls -lha | grep name of deameon and it looked equal the other files, but I will take another look
[22:19] <davidcalle> malin, you can also make it executable via a terminal "sudo chmod +x /usr/lib/unity-lens-buss/buss"
[22:20] <malin> davidcalle: davidcalle it's not set as allow executing file as program, but so ain't the other unity-lense service files
[22:21] <malin> ah that program
[22:21] <malin> belived you thinked about the sericefile
[22:21] <malin> I can do it to the buss :)
[22:21] <malin> I wonder about one thing
[22:21] <davidcalle> malin, yeah, the .service file is just the way the system finds about your program and knows what to start.
[22:21] <malin> what do I need to make launchpad make a deb-file for me?
[22:21] <malin> I have made a ppa
[22:21] <malin> yeah
[22:23] <davidcalle> You need a few other files. http://bazaar.launchpad.net/~davidc3/onehundredscopes/piratebay-precise/files
[22:23] <malin> I looked in the video-lense-sourceode and figured out you made the video-lense in ubuntu :)
[22:23] <davidcalle> Here is an example.
[22:23] <davidcalle> malin, indeed :)
[22:23] <malin> :) that is so cool
[22:24] <davidcalle> First, look at setup.py and MANIFEST.in : the manifest file lists all the files that need to be installed on the system. The setup.py file says where they need to be installed.
[22:24] <malin> okey, so I have to make all those folders and that setup.py ? I think I will work on that during this week now and then.
[22:24] <davidcalle> malin, thanks
[22:24] <malin> :)
[22:25] <malin> I haven't used it very much, the video-lense, but maybe I should, it could make me find things faster
[22:25] <davidcalle> malin, those two files are the first bits. Then, the big part is the debian folder. It's what will allow Launchpad to create a .deb.
[22:25] <malin> okey, so the setup.py and manfiest.in is the the files I have to make myself
[22:26] <malin> ah, okey
[22:27] <malin> it's bit of work, but I should try to make it myself
[22:27] <malin> too
[22:28] <malin> don't know what depneds I need for the lense
[22:28] <malin> but I think I have to get some sleep.
[22:28] <davidcalle> malin, once you have done those two, I'll give you a hand with the debian folder if you need one. But basically, you have to look at each file and change things that are irrelevant to your lens
[22:28] <malin> And again. thank you so much for help :)
[22:28] <malin> okey :) I will
[22:28] <malin> good night :)
[22:28] <davidcalle> malin, no problem, good night :)


 The way you asked made me think you might know something that wasnt yet announced
[21:42] <jrmy> well did you hear the price range, earliest release date, size and gpu?
[21:43] <maxsilver> ive only heard the gpu
[21:43] <jrmy> yeah amd r700
[21:44] <jrmy> full hd on a nintendo console should be cool
[21:44] <jrmy> i dont care for the 3d but whatever
[21:44] <jrmy> but the price was set as $350-$400
[21:44] <maxsilver> that seems reasonable
[21:45] <jrmy> earliest launch is somewhere between mid october and november
[21:46] <jrmy> and the design is to be about the size of the xbox/xbox 360 whichever both are about the same size
[21:46] <jrmy> and to look like a modern snes
[21:47] <jrmy> but yeah thats about it for now
[21:47] <jrmy> if youre subscribed to game informer as well as their mailing list you'd know this.. unless you didnt care to read the whole email
[21:48] <maxsilver> i dont subscribe, but im interested to see their new stuff
[21:48] <jrmy> but "miyamoto confirms a new console" caught my eye
[21:48] <jrmy> as in game informer's or nintendo?
[21:49] <jrmy> http://www.gameinformer.com/b/news/archive/2011/04/21/miyamoto-confirms-new-nintendo-console-pricing-and-release-rumors-surface.aspx
[21:49] <jrmy> thats the page though
[21:49] <jrmy> so i guess 3 day old news
[21:49] <jrmy> lol
[21:50] <jrmy> anyone know if subway is still doing the buy a 6" breakfast sub get one free?
[21:51] <jrmy> 7am-9am
[21:51] <jrmy> or is it just me and you maxsilver?
[22:07] <jrmy> lost connection
[22:27] <jrmy> maybe no one is talking because its easter
[22:54] <snap-l> And now for round two...
[22:54] <snap-l> swear this is worse than Christmas.
[23:41] <jjesse> no one is talkign because we are in a food coma


[00:26] <JZA> hi anyone know why launchpad is so slow
[00:26] <JZA> I am doing a checkout of a project
[00:26] <JZA> and is taking hours
[00:27] <JZA> I get.. Fetching revisions:Inserting stream:Estimate 589932/600665
[00:27] <JZA> and only 43kbp/s transfer rate
[00:30] <wgrant> JZA: Which project?
[00:30] <wgrant> And how good is your ISP's connection to London?
[00:30] <JZA> they were supposed to be just scripts
[00:30] <JZA> but is a bit more than that
[00:31] <JZA> https://code.launchpad.net/~openerp-dev/openobject-addons/
[00:31] <JZA> anyhow, still should take around 20 min, it's been downloading for hours now
[00:31] <JZA> I can downlaod a 1gb movie in 20min
[00:31] <JZA> usually less
[00:33] <wgrant> There's a bit of a difference between downloading a single large file from local peers, and downloading a complex VCS tree from another continent, I'm afraid.
[00:34] <wgrant> Lots of ISPs have pretty terrible connections to Europe.
[00:34] <wgrant> However
[00:34] <wgrant> Are you downloading over HTTP or SSH?
[01:30] <JZA> wgrant: I am downloading from bzr, I guess it would use ssh
[01:30] <JZA> wgrant: who says I am in europe?
[01:30] <wgrant> JZA: Launchpad is in Europe
[01:30] <JZA> wgrant: my bandwith is around 10mbps
[01:30] <wgrant> And that branch is more than just scripts; it's about 700MB
[01:31] <wgrant> JZA: bzr will use SSH if you've used 'bzr lp-login', HTTP otherwise.
[01:31] <JZA> oh
[01:32] <wgrant> I'm not quite sure what's in there
[01:32] <wgrant> But whatever it is, it's pretty huge...
[01:32] <JZA> wgrant: sucks...
[01:32] <JZA> I wonder why launchad cant zip the whole tree as a tarball
[01:35] <wgrant> Normally projects release tarballs/zips themselves, but Launchpad can generate them directly from a branch. http://bazaar.launchpad.net/+branch/openobject-addons/tarball might work, but I don't know how well it scales to several hundred megabytes...
[01:36] <JZA> welll it's definely going faster
[01:37] <JZA> would it only tar the main branch?
[01:38] <wgrant> JZA: That's for a single branch, yes.
[01:40] <JZA> I see
[01:49] <dobey> which branch are you downloading?
[01:50] <dobey> and why are there so many branches, sheesh
[01:51] <JZA> dobey: not sure, this was supposed to be only some scripts
[01:51] <JZA> but I guess this have to be compliat for each addon
[01:51] <dobey> what was? what bzr command did you use?
[01:51] <JZA> so they include the addons
[01:52] <JZA> bzr branch lp:openupgrade-addons
[01:53] <dobey> uhm
[01:53] <dobey> that is not openobject-addons
[01:54] <dobey> also, that is one heck of a lot of directories in a bzr branch
[01:54] <JZA> umm... ur right
[01:54] <JZA> too similar names
[01:56] <dobey> anyway, it looks like there also plenty of binary files in the tree
[01:56] <dobey> binary files make the size of the history to be quite large, if they are changed often
[01:56] <JZA> :S
[02:00] <lifeless> dobey: actually binary isn't a problem per se; it's files where when they change the majority of the file changes thats an issue - and many binary files have this characteristic (but many don't)
[02:00] <lifeless> for instance, running sqlite db's in bzr would be fine
[02:03] <dobey> well, i don't guess this branch is in that category of not having the problem
[02:05] <dobey> because i'm pulling that branch right now, and getting upwards of 7MB/s download at times, mostly it's around 3 MB/s. and it is taking quite a long while to pull it
[02:05] <dobey> it's been going > 10 minutes already
[02:07] <dobey> ah, just finished
[02:07] <dobey> and yeah, it's 898M
[02:13] <dobey> heh
[02:13] <dobey> oh well, it's late
[19:50] <smoser> cjwatson, above, how do i do that ?
[19:51] <smoser> how does that stuff normally get crated ?
[19:53] <dobey> smoser: precise-proposed bzr branch of package in precise?
[19:54] <dobey> smoser: dput the proposed package to precise-proposed and it should get imported
[19:55] <smoser> dobey, well, well,
[19:55] <smoser> a.) i hope that works. i have very little success with the importer
[19:55] <smoser> b.) that looses interim commits that i wanted to preserve
[19:55] <smoser> s/well, well,/well.../
[19:56] <smoser> oh.
[19:56] <smoser> c.) when does that occur ? on acceptance into -proposed ? (i've always been confused on that)
[19:57] <dobey> yes
[19:57] <dobey> it should occur when the package is accepted into proposed
[19:59] <dobey> though i'm not entirely sure what the expected interaction of imports is for Vcs-Bzr branches. that's always been a bit confusing
[22:42] <philsf> how can I automatically close LP bugs from commits? bzr --fixes lp:number only links the branch, doesn't set "fix commited" neither "fix released"
[22:44] <dobey> commits to what?
[22:44] <dobey> anyone can bzr commit --fixes lp:number in any branch; doesn't mean it fixes it in the thing it was reported in
[22:46] <philsf> dobey, how can I close the bug then? I mean, appart from going to the bug itself and manually setting it to fixed.
[22:48] <dobey> philsf: are you using merge proposals as a way of getting changes into your trunk?
[22:51] <philsf> dobey, nope, just merging locally. is that what it's required?
[22:53] <dobey> it is required to use tarmac, which handles merging of branches, and has a plug-in to close bugs as fixed once the code is merged to trunk
[22:59] <dobey> maybe you should just write a script to close the bugs from the command line, using the launchpad api
[23:07] <philsf> https://launchpad.net/bzr-tarmacland ?
[23:07] <philsf> I can't find a package, with apt-cache search
[23:10] <philsf> my google-fu is failing me: I also can't find documentation on how to use it
[23:30] <dobey> lp:tarmac is tarmac
[23:30] <dobey> it's not packaged in ubuntu yet
[23:30] <dobey> i don't know what bzr-tarmacland is
[23:31] <dobey> it seems to be a plug-in useful for developers of launchpad itself
[23:32] <dobey> not generally useful to other people
[23:44] <philsf> oh, ok
[23:46] <philsf> dobey, what about "fix commited" -> "fix released"? I often see automatic LP comments in ubuntu bug reports, that a bug was fixed in a given release. How can I do that?
[23:47] <dobey> that is only in the packages in ubuntu
[23:47] <philsf> dobey, is it sufficient to include a "Closes: LP:number" in the pacakge changelog?
[23:47] <dobey> you need to do it manually for upstream releases
[23:48] <philsf> oh, that's a pitty. thanks for the info, anyway


[07:36] <praisethemoon> good day folks!
[08:29] <praisethemoon> pavlushka, o/
[08:30] <pavlushka> o/ praisethemoon :)(
[08:30] <pavlushka> :)
[08:30] <praisethemoon> how is it going?
[08:32] <elacheche> Hello!
[08:32] <elacheche> Wassup folks
[08:55] <praisethemoon> elacheche, hello o/
[09:01] <elacheche> :)
[09:08] <pavlushka> 0/ elacheche :)
[09:24] <elacheche> Oh! Too much net splits
[09:25] <praisethemoon> elacheche, what happened?
[09:27] <elacheche> The freenode stuff are maintaining the EU servers.. Apparently both of us are not using the EU servers x)
[09:28] <elacheche> Yes we use the same US server x)
[09:30] <praisethemoon> oh wow xDDDD
[09:30] <praisethemoon> how did you know? :3
[09:32] <elacheche> So.. late yesterday, I decided that I'll use python to create a script that I need for work instead of shell, I know that I probably will be able to finish it in an hour or less using bash, but I'll try this adventure and see how many hours I'll need to it in python :/ x)
[09:32] <praisethemoon> elacheche, what kind of script?
[09:33] <elacheche> praisethemoon: use the /whois elacheche command the output of that command will be in the "freenode" tab/window, you'll find the maintainince annoucement there as well
[09:33] <praisethemoon> i'm sure you can do the lua version in far less time :P
[09:33] <praisethemoon> true ..
[09:33] <praisethemoon> how do you activate AFK notice?
[09:33] <elacheche> praisethemoon: Nah! I'm not a lua ninja yet, but when I finish converting all my dummy shell scipts to py3 I'll start converting them to lua and learn things..
[09:34] <praisethemoon> elacheche, good plan :)
[09:34] <praisethemoon> do you code in C?
[09:35] <elacheche> I have an old inhouse DNS server based on AD (winbugs).. I activated an other DNS server integrated with my GW, I'll try to convert all records to dnsmasq and pfsense format to inject them to the config file without adding each one from the webui
[09:36] <elacheche> Use /away <msg> to enable/disable the away flagn the notice is what you right in the msg field
[09:36] <elacheche> I'm a C n00b as well
[09:36] <elacheche> :)
[09:39] <praisethemoon> how do I disable it? XD
[09:40] <elacheche> just use it without <msg>
[09:44] <praisethemoon> i did, it says /BACK
[09:44] <praisethemoon> GUESS WHOS BACK
[09:44] <praisethemoon> :3
[09:50] <elacheche> Emm, it depends on your client then
[09:55] <praisethemoon> oh okay
[09:55] <praisethemoon> i use hexchat now :3
[09:55] <praisethemoon> wbu?
[09:56] <elacheche> hexchat is good :)
[13:25] <praisethemoon> hello!
[13:26] <elacheche> Hey!
[13:26] <elacheche> Guess what!
[13:27] <elacheche> I finished the AD to DNSMASQ script (with 1 little bug x) ) in only 20 lines of py codes
[13:27] <elacheche> Now it's time to tr to convert that dnsmasq to pfsense format (I hope that I don't break my pfsense box x) )
[13:32] <praisethemoon> elacheche, i have no idea about what you are doing
[13:32] <praisethemoon> i'm such a n00b
[13:32]  * praisethemoon cries ..
[13:39] <elacheche> x)
[13:40] <elacheche> It's just converting a file text from format to an other
[13:54] <praisethemoon> oh
[13:54] <praisethemoon> from user friendly format to hacker friendly format :D
[14:57] <praisethemoon> pavlushka, o/
[14:57] <pavlushka> o/ praisethemoon :)
[14:57] <praisethemoon> sup man
[14:58] <pavlushka> doing open (means free) work for family business :)
[15:01] <pavlushka> sending email to a news paper, scanning veterinary prescription for our ducks and fowls and pigeons and sheep :(
[15:01] <pavlushka> but I am happy for them coz its good for them :)
[15:02] <pavlushka> need to go to some other district with sample soil for soil testing.
[15:05] <praisethemoon> pavlushka, oh that's good :)
[15:05] <praisethemoon> my father owns a small shop, i always though of writing a software to manage products etc but he doesnot have a computer on the shop yet
[15:06] <praisethemoon> elacheche, what is ELCE 2016?
[16:33] <elacheche> praisethemoon: Embedded Linux Conference Europe
[16:34] <praisethemoon> oh yeah i figured :3 had to google
[16:34] <praisethemoon> i'm also interested in IoT
[16:34] <elacheche> :D
[16:34] <praisethemoon> dammit i have to finish berserk
[16:34] <praisethemoon> gotta write awesome stuff with it
[16:34] <praisethemoon> >.<
[16:35] <elacheche> :)
[16:40] <Chikore> Hi people =)
[16:46] <praisethemoon> Chikore, hello
[16:46] <praisethemoon> how is it going?
[16:52] <Chikore> Good
[17:42] <Chikore> who tried 16.10?
[18:08] <praisethemoon> o/


[12:30] <benji> BradCrittenden: you can't seem to settle on a name here lately
[12:30] <benji> I have a small review up that could use your attention: https://code.launchpad.net/~benji/charmworld/migration-018-delete-bundles/+merge/181807
[12:30] <BradCrittenden> benji: yeah, i got the dropouts.
[12:31] <benji> ooh, I hear that can be fatal
[12:31] <BradCrittenden> the nick retention period is much longer than the time it takes me to reconnect so it won't let me have 'bac'
[12:32]  * InigoMontoya prepare to die
[12:38] <benji> InigoMontoya: you can /release the nick by talking to NickServ and he'll let you have it back
[12:40] <InigoMontoya> benji: no, it isn't a problem, i can usually get it back quickly.  but i have to notice the problem after my client reconnects
[12:41] <benji> why does your client choose the wrong nick?
[12:41] <InigoMontoya> benji: b/c when it reconnects freenode has not yet released 'bac' and i guess i have the longer one as my alternate.
[12:42] <benji> ah; I have some purge-all-past-incarnations commands that my client runs when I connect.  That helps a bit with that.
[12:42] <InigoMontoya> benji: moving on to other topics:  i'm about ready to break out 'rev' as a separate field in the mongo doc.  it seems crazy to go to all of the trouble i'm having just for this issue.
[12:43] <InigoMontoya> benji: it can still be part of the _id as needed
[12:43] <InigoMontoya> benji: reality-based objections?
[12:43] <benji> makes sense; will you also have the search_id as part of the document, so you can search on it?
[12:44] <benji> no, but Falcor isn't a fan of the idea
[12:44] <benji> ah, who am I kidding, Falcor loves everyone
[12:44] <InigoMontoya> unsure about search_id
[12:46] <benji> I figured that since you want to search on everything but the revision, the search ID would be the way to go (since that's what it is)
[13:02]  * sinzui sets charmworld to benji's 264
[13:02] <sinzui> 364 I mean
[13:02] <jcsackett> rick_h: if you can look at https://codereview.appspot.com/12935046/ again i updated it yesterday.
[13:04] <rick_h> jcsackett: cool looking
[13:04] <rick_h> jcsackett: ah, I saw jeff gave you a lgtm so I didn't go back to it
[13:04] <jcsackett> rick_h: it's LGTM with your proposed changes; figured i would make sure you were happy with those changes.
[13:05] <jcsackett> if you want to hand wave it i'm happy to go ahead and land it. :-P
[13:05] <rick_h> ok, looking now
[13:07] <sinzui> benji, I see from the log the migration was run. I still see the wiki bundle. This might be a timing issue because ingest starts *before* the website is brought back up
[13:08] <rick_h> jcsackett: replied.
[13:08] <jcsackett> rick_h: dig, thanks.
[13:10] <jcsackett> jujugui: i need two reviews on https://codereview.appspot.com/12741050 and someone with IE to QA. it's an easy one--just a bunch of deletions.
[13:11] <benji> sinzui: I would suspect timing.  The migration is simple and its tests seem to be representative.  If the bad bundle doesn't cause any errors, I would suspect re-ingestion.
[13:12] <sinzui> benji, The ES data is different. The search that worked yesterday doesn't work. I think all is well.
[13:12] <benji> cool!
[13:12] <sinzui> benji, are bundles ingested first?
[13:12] <benji> thanks for working on it
[13:12] <benji> I don't know the order off the top of my head.
[13:12]  * benji looks
[13:13] <sinzui> I think they are, meaning the first bundles will always be place before the website restarts
[13:13] <benji> sinzui: it depends on the hash order of a dictionary, so it should be consistent, but is unspecified
[13:27] <sinzui> benji, bac: do either of you have time to review  https://code.launchpad.net/~sinzui/charmworld/provide-type-from-api-search
[13:27] <frankban> bac, benji: when you have time, could you please review https://codereview.appspot.com/12802045 ?
[13:27] <benji> sinzui: sure
[13:27] <benji> frankban: sure
[13:27] <InigoMontoya> frankban: sure
[13:28] <frankban> thank you both
[14:03] <rick_h> kind of short notice http://www.yuiblog.com/blog/2013/08/23/save-the-date-yuiconf-nov-6-7
[14:03] <rick_h> hatch:  ^
[14:04] <rick_h> hatch: Makyo updated the branch from yesterday with the bi-directional go constraint conversersion, refactoring, added the sandbox tests/adjustments. https://codereview.appspot.com/13084045
[14:05] <rick_h> hatch: Makyo appreciate a second look though I know I got LGTM yesterday. Feel like a lot's changed, but part of that is in my head
[14:13] <Makyo> rick_h, on it
[14:15] <jcsackett> jujugui: can i get two reviews on https://codereview.appspot.com/12741050, please?
[14:15] <rick_h> jcsackett: will look in a sec
[14:15] <jcsackett> rick_h: thanks.
[14:16] <Makyo> jcsackett, on it.
[14:16] <jcsackett> Makyo: thanks!
[14:20] <sinzui> jcsackett, admin thinks you are on holiday today. Did you forget?
[14:23] <jcsackett> sinzui: it's a half day, PM.
[14:23] <jcsackett> leaving at noon.
[14:23] <sinzui> jcsackett, sorry, I thought you had extended it to the whole day.
[14:24] <sinzui> I think I am the only member of Orange working on Monday.
[14:28] <sinzui> benji, about the access to _representation. I too was hoping that we would have solved this by now for bundles and charms. maybe both classes should have a property that returns dict(self._representation)
[14:31] <benji> sinzui: that would be fine with me; I do worry a little about non-canonical key/values sneaking in, plus it would be nice to have the properies get a chance to return things.  How about returning dict((key, getattr(self, key)) for key in self._COMMON_REPRESENTATION)
[14:34] <rick_h> Makyo: did you do the IE QA on jcsackett's branch?
[14:35] <sinzui> benji, yes, that is better. Maybe we want a guard in the class that ensures unwanted keys are always rejected. __init__ looks flawed. if it was ensured a sane dict, calling @representation or dict(Bundle(data)) could be trusted
[14:36] <benji> sinzui: yep, I like putting the gate earlier too (dict(Bundle(data)) can actually be trusted now because it does its own filtering, but I get your point)
[14:37] <sinzui> benji, okay. I will report a bug for this because I think we want to fix this bad pattern for charms and bundles.
[14:37] <benji> sounds good
[14:40] <Makyo> rick_h, ah, will do that now.
[14:40] <rick_h> Makyo: that's ok, was wondering. My lbox submit finished so I can pull it into my colo now
[14:40] <rick_h> I'll poke at it
[14:41] <Makyo> rick_h, oh, alright.
[14:42] <adeuring> bac, sinzui: could you trying the branch: lp:~adeuring/charmworld/1206659-spurious-errors ? it should fix a number of spurious failures, even some in tests that were not disabled in r362, but I'd like some independent test runs before I claim that everything is fixed...
[14:42] <bac> adeuring: sure!
[14:42] <sinzui> thank you adeuring
[14:45] <bac> adeuring: how long does 'make test' take to run on your slow and fast machines?
[14:45] <Makyo> luca, ping
[14:45] <luca> Makyo: heya
[14:47] <Makyo> luca, the upgrade service ux appears in two different places in the mockup.  I like the second one better - after all of the unit management stuff - because this is by service, not by units, and having it mixed in confused even me for a bit.  Can I go with that one?
[14:47] <Makyo> luca, on https://www.dropbox.com/s/d6sc200adk2dszs/juju-gui-2-inspector-09.jpg
[14:48] <luca> Makyo: they are the same but different :D
[14:48] <luca> Makyo: There is 2 use cases going on here
[14:48] <luca> Makyo: #1 I need to upgrade my servicer
[14:48] <luca> Makyo: #2 I need to revert my service
[14:49] <Makyo> luca, Why is it mixed in with units?
[14:49] <luca> Makyo: When there is a new upgrade that the user hasn't seen yet, the "A new upgrade is available" populates near the top
[14:49] <luca> Makyo: there isn't really a "mixed in with units" thing, they are just notifications, it's all about hierarchy
[14:50] <Makyo> luca, I keep getting wireframes with no explanation and being told to implement.  I'd appreciate a call.
[14:50] <Makyo> jujugui call in 10 kanban now.
[14:50] <luca> Makyo: Ah, thats fine. We actually worked with gary on this and most of this way his idea, I would of thought he would of briefed you guys on it before delegating it out.
[14:51] <Makyo> luca, nope.
[14:51] <luca> Makyo: right, when are you available?
[14:51] <Makyo> luca, now for 9 minutes, and in an hour and nine minutes for several hours.
[14:51] <adeuring> bac: the slow one needs ca 100 seconds (...and I just noticed another test failure...)
[14:51] <bac> adeuring: i'm running the tests but they are taking forever to run
[14:51] <adeuring> ..and the fast machine now show a ton of errors even for trunk...
[14:52] <bac> adeuring: in past 'make test' took about 74 seconds for me.  this one is taking minutes
[14:53] <adeuring> bac: interesting. I changed a status check when a temporary index is created for a test. Could be related.
[14:55] <bac> adeuring: still on the first line of dots of test output
[14:55] <adeuring> bac: Then just abort it...
[14:55] <bac> adeuring: even if all tests pass, this is too painful
[14:55] <adeuring> right
[14:59] <Makyo> jujugui call in 1
[15:06] <bac> adeuring: try scripts/reset-db?
[15:06] <bac> adeuring: in a bind, i've rm /var/lib/elasticsearch too
[15:07] <adeuring> bac:  yes
[15:07] <adeuring> i tried both, but i did not restart mongodb, as suggested by sinzui
[15:19] <Makyo> rick_h, constraints are passed from pyjuju in the get_service call, and are hooked up, at least in the inspector.
[15:19] <Makyo> rick_h, will check go too.
[15:19] <rick_h> Makyo: k, cool. Yea I figure pyjuju worked and maybe we never got around to checking/working on -core?
[15:20] <Makyo> rick_h, yeah, will do that now.
[15:25] <bac> sinzui: you said "it is not in saucy".  were you referring to pyjuju or core?  that is, what is in saucy?
[15:26] <sinzui> pyjuju is not in saucy
[15:27] <rick_h> sinzui: ah, that makes sense
[15:27] <rick_h> sinzui: I heard it the other way as well
[15:27] <sinzui> sorry for speaking in curtisese
[15:32] <hatch> rick_h: I'm going to revert the inspector and then I can help you out
[15:33] <rick_h> hatch: k, all good.
[15:34] <Makyo> Bleh, debug-log no longer uses newlines, nearly impossible o read.
[15:34] <rick_h> joy
[15:35] <hatch> matt I crested a card in urgent and put our heads on it for the IE10 QA
[15:36] <Makyo> hatch, Cool, thanks/
[15:37] <hatch> crested a card
[15:37] <hatch> hmm
[15:37] <hatch> lol
[15:39] <Makyo> rick_h, I am getting constraints from core, too, but they're showing up strangely.  It looks like core responds only in MB, but GUI expects GB for memory, so it says I created a machine with 2048GB of memory.  I hope that's not the case :)
[15:39] <rick_h> Makyo: hah, ok. Good to know. Maybe that follow up card isn't much work then.
[15:39] <rick_h> Makyo: curious to trace how it was getting the data format and fitting it to the UX
[15:40] <hatch> 2048GB of ram....that must be rick_h's new desktop
[15:40] <rick_h> hah, I'm about 2012 short
[15:40] <hatch> lol
[15:41] <rick_h> err, 2016 that is. /me can't do match on fridays
[15:41] <Makyo> rick_h, It looks like it's just populated in the service model's attrs and bound in the inspector from there.
[15:41] <rick_h> Makyo: cool
[15:41] <rick_h> Makyo: yea, I saw some stuff in the utils that generates titles and such for the UX so maybe it's doing it there.
[15:42] <Makyo> luca, ping; I'm free if you've got some time before your end of day.
[15:43] <luca> Makyo: ok, I'm in a meeting with Mark S at the moment but I'll join guichat when I'm out.
[15:43] <Makyo> luca, alright, thanks.
[15:48] <benji> frankban: I finally finished looking at your branch, it looks good
[15:50] <frankban> benji: great, thanks
[16:06] <luca> Makyo: I'm on GUI chat
[16:06] <Makyo> bcsaller, in guichat if you want to join
[16:18] <rick_h> Makyo: after your call, was that -core constraint working done via the gui? e.g. you deployed and set a constraint from the gui and then when you opened it back up it was loaded ok, just off as far as units?
[16:19] <Makyo> rick_h, deployed from command line in a real env.  `juju deploy --constraints mem=2G cs:precise/mysql`
[16:19] <rick_h> Makyo: ok, I'd be curious then if settnig via the gui does work since that's where I was looking for us to translate the names of the constraints to the Go format.
[16:24] <rick_h> hatch: running out to grab some food. Looks like my last branch had the wrong 'structure' for constraints and so needing to clean that back up. Latest work is in lp:~rharding/juju-gui/ghost-constraints-1125352 if you want to poke and if you wanted to pair on it in a bit.
[16:24] <hatch> rick_h: ok sure - I have a few emails to write then I'll be on it
[16:25] <rick_h> hatch: np, biab
[16:45] <hatch> hmm
[16:45] <hatch> fresh trunk test failures....
[16:52] <hatch> I'm always confused how this happens
[16:56] <hatch> oh it did fail in CI too
[16:56] <hatch> it was just masked by the selenium failures
[16:56] <rick_h> hatch: details on what I broke?
[16:56] <bac> frankban: review done
[16:57] <hatch> rick_h: I think it was a bad merge
[16:57] <rick_h> hatch: hmm, yea that sucks. I mean it has to merge/pass tests to land so confused
[16:57] <hatch> rick_h:  https://gist.github.com/hatched/13dd112c33c1263476f4
[16:57] <frankban> bac: thanks!
[16:57] <hatch> oh woops
[16:57] <hatch> heh
[16:57] <hatch> the 'expected' is the Constraints object
[16:58] <hatch> ^ rick_h
[16:58] <rick_h> hatch: yea, looking
[16:58] <rick_h> hmm, those are tests I changed and such but not seeing the /actual/expected
[16:59] <rick_h> hatch: but I can pull down trunk again and see if I can replicate it locally. Sec
[17:01] <hatch> thanks
[17:01] <rick_h> hatch: ok, I have the same error here. Will hack a branch to see what's up/fix it.
[17:02]  * rick_h wonders how the $@#$@# it landed then.
[17:02] <hatch> yeah right!?!?
[17:02] <hatch> maybe you had an old test server running :D
[17:02] <hatch> that caught bcsaller once hehe
[17:02] <rick_h> oh, and the lbox hit that vs its own?
[17:02] <hatch> yup
[17:03] <rick_h> hmm, guess that's possible. I was running tests.
[17:07] <rick_h> hatch: cool, easy fixes. Must have done that I guess. Sorry about that :/
[17:07] <hatch> yeah....you'll pay for this....
[17:08] <hatch> with your cpu.....mohohahahahahaha
[17:08] <hatch> I figure that would be from Futurama
[17:08] <rick_h> haven't I already suffered enough on this card? plus more lboxing...the punishment!
[17:08] <hatch> pssht lboxing for you is what....20s? :P
[17:08] <rick_h> no, stupid bzr/launchpad/branching :/
[17:09] <hatch> ahhh right right
[17:12] <hatch> rick_h: gave you an lgtm
[17:12] <rick_h> hatch: cool thanks.
[17:17] <rick_h> hatch: ok, fix heading down for that.
[17:17] <hatch> great - once it lands I can then revert the flag branch
[17:17] <rick_h> it's in trunk at least. bzr pull will have it and you can start
[17:18] <hatch> cool proposing
[17:21] <hatch> jujugui fyi I'm putting bugs which will block the release in maintenance/urgent
[17:21] <rick_h> hatch: k
[17:23] <hatch> jujugui review for reverting the inspector as the default https://codereview.appspot.com/12739049/
[17:25] <hatch> Makyo: I can't find any IE10 specific bugs \o/ lemme know what your result is whenever you get a chance
[17:26] <rick_h> hatch:  looking
[17:27] <hatch> landing thanks for the reviews Makyo rick_h
[17:38] <Makyo> My IE is so small :S  I should see if I can get VB to pretend like I have a bigger monitor.  The unit details view goes off the edge of the screen.
[17:42] <Makyo> Happens in all browsers, ditto with fullscreen.  I think I  just have it smaller than our minimum size is all
[17:44] <Makyo> hatch, maybe worth a card, but I don't think I'd consider it a blocker.  Looks fine once I get above something like 1024x768 :P
[17:46] <hatch> haha that's pretty small
[17:49] <Makyo> hatch, yeah. vbox just picked up a small default.
[17:50] <Makyo> hatch, also, relation labels are too high.  Also small.  Probably defaulting to a baseline at the bottom rather than the middle.
[17:50] <Makyo> hatch, no blockers, though.  Everything looks/works fine otherwise.
[17:59] <hatch> awesome! :D
[17:59] <hatch> thanks for that
[18:00] <rick_h> man, almost have my own charmworld/juju-gui running in lxc containers but can't configure the juju-gui to set the charmworld url away from manage.jujucharms.com
[18:01] <hatch> rick_h: sounds like a bug to me :)
[18:03] <rick_h> hatch: trying to set via cli and see if it works
[18:04] <rick_h> hatch: yea, worked via cli. hmmm, need a release to check if it works via the inspecgtor
[18:08] <rick_h> http://uploads.mitechie.com/lp/lxc-jujugui.png so that's all in lxc containers. Charmworld hadn't finished ingesting and such. However cool to run it all locally.
[18:08] <rick_h> pretty quick overall
[18:08] <rick_h> so thanks for the charm-school jcastro ^
[18:10] <hatch> that is awesome :) I need to do that at some point
[18:11] <rick_h> 20GB of ram left, time to try to run 100 juju-guis
[18:11] <hatch> very odd issue with the CI failures this time
[18:11] <hatch> I guess I'll retrigger it and see what happens
[18:11] <hatch> rick_h: so where are we with the ghost constraints stuff? Anything i can help with?
[18:12] <rick_h> hatch: sorry, took a break to watch the charm school on lxc stuff to test things coming up.
[18:12] <rick_h> hatch: so we're doing ok. Fixing the constraints object conversion to work
[18:12] <rick_h> python works, go api fails.
[18:13] <hatch> who needs Go anyways
[18:14] <rick_h> heh, my branch is going to leave the api set to go in the config-debug per our discussion today
[18:15] <hatch> I think I missed that discussion
[18:15] <hatch> guichat to bring me up to speed?
[18:15] <rick_h> sure
[18:32] <hatch> awesome HTC is going to fix the mrs phone - now I can go get a new phone haha
[18:42] <hatch> canceled CI trying again...
[18:43] <rick_h> hatch: ok, might need a chat after all. Data seems to go in, won't come back out
[18:45] <hatch> rick_h: ok in a few minutes just eating a sandwitch :)
[18:45] <rick_h> hatch: rgr
[18:51] <hatch> arg I don't know what's up with this CI
[18:56] <hatch> rick_h: ok sandwitch done ....guichat?
[18:57] <rick_h> hatch: rg
[18:57] <rick_h> rg
[18:57] <rick_h> damn rgr
[19:41] <bac> benji, sinzui: in our google doc, we agreed the api endpoint should be plural "bundles" but it is still "bundle".  any objections to me fixing it?
[19:41] <benji> bac: are we going to change "charm" to "charms"?
[19:42] <benji> wait, there already is a "charms"
[19:42] <benji> bac: we changed it the other way, API2 had "charms" but API3 has "charm"
[19:42] <sinzui> bac, charms/ is a searchable collection, charm/ is an individual charm
[19:43] <sinzui> bac /search is a collection of all bundles and charms and it replaces charms/
[19:43] <bac> sinzui, benji: looky here: https://docs.google.com/a/canonical.com/document/d/17bgbReU6JJMoUHSJeo8egG5zoSM0fpPIs7U8F1-Piyk/edit#heading=h.u3246vho9aig
[19:43] <sinzui> bundle/ would provide a single bundle I think
[19:43] <bac> fourth bullet point
[19:43] <bac> http://staging.jujucharms.com/api/3/bundles/~abentley/wiki-bundle/1/wiki
[19:44] <sinzui> bac, I know.bundles/ is fine because we moved charms/ to search/
[19:44] <benji> bac: I don't really care much one way or the other, just making the current state known
[19:45] <sinzui> bac, benji. I don't have an opinion about the plural of bundle(s)/, but I want it to be consistent with charm/ which is what we have now
[19:46] <benji> +1
[19:46] <sinzui> we can rename charm to charms/ in api3
[19:46] <bac> sinzui: well it is easier to fix the google doc than the code
[19:46]  * sinzui is dizzy from seeing all his work not come to fruition today
[19:47] <bac> actually, no because we have:
[19:47] <bac> http://manage.jujucharms.com/~sinzui/bundles/mysql/5/tiny/json
[19:47] <bac> http://manage.jujucharms.com/bundles/mysql/tiny/json
[19:48] <bac> so, in the branch i'm about to propose they are all going to be 'bundles'
[19:48] <bac> if we want to change them to 'bundle' we can do that, after updating the doc
[19:48] <bac> i gotta land this thing!
[19:49] <sinzui> bac, sure. We will revisit all the URLs in SEO soon anyway
[20:00] <sinzui> bac, I can review your branch if you want https://code.launchpad.net/~bac/charmworld/official-bundle-json/+merge/181909
[20:00]  * sinzui needs a break from failing to show interesting bundles
[20:00] <bac> sinzui: it has conflicts.  i'll let you know when it is fixed -- thanks!
[20:26] <bac> sinzui: conflicts fixed
[20:26] <bac> sinzui: sorry the diff is so long
[20:28] <sinzui> bac: np
[20:28] <sinzui> bac, can you review https://code.launchpad.net/~sinzui/charmworld/api3-interesting/+merge/181910 ? It is very short because I got lost
[20:28] <bac> sure
[21:17] <sinzui> bac, I replied with 2 questions
[21:20] <bac> sinzui: ok
[21:28] <bac> sinzui: thanks for the mongo sort reminder.  i'd tried that yesterday, before i made basket_revision a field.  i'll make that change now.
[21:29] <bac> sinzui: as to the other, yes basket_with_revision is a better name
[21:29] <sinzui> bac okay. I was only asking questions. Make changes as you like; r=me
[21:56] <bac> sinzui: would you update https://docs.google.com/a/canonical.com/document/d/17bgbReU6JJMoUHSJeo8egG5zoSM0fpPIs7U8F1-Piyk/edit# with check marks?
[21:56] <sinzui> bac, The 3 interesting parts aren't done-done
[21:57] <sinzui> I did verify routing with versions is good
[21:57] <bac> sinzui: 4b and 4c aren't done?
[21:58] <sinzui> bac, api supports them, but until we change ingest and views to collect the data, no one will see which is new or popular
[21:59] <sinzui> well...considering how new bundles are, we might not ever see popular bundles
[22:01] <bac> good point sinzui.
[22:01]  * bac dog walk
[22:17] <sinzui> bac, I deployed your changes to staging. They work for the most part, but I think there is something amiss with the basket-name: http://staging.jujucharms.com/~abentley/bundles/wiki-bundle/1/wiki/json is not found  and a search for abentley finds a bundle without a basket.
[22:21] <sinzui> bac, I need to make dinner so will sign off. I think we need to update ingest or the model to handle the / in the basket. I see this in the DB: { "_id" : "~abentley/wiki-bundle/1/wiki", "owner" : "abentley", "basket" : "wiki-bundle/1"}
[22:22] <sinzui> well, before I go I will delete the bundle from staging so that we can check with a fresh ingest.
[22:23] <hatch> man there has to be something wrong with canonistack
[22:25] <sinzui> hatch, how do you mean
[22:25] <hatch> the ci just hangs after loading in the selenium deps
[22:25] <hatch> and I can't find anything wrong with it
[22:26] <hatch> it's like it can't create a new instance or something
[22:27] <sinzui> hatch, are the deps enormous?
[22:27] <hatch> I don't think so it always gets to "FInished processing dependencies for selenium==2.33.0"
[22:27] <hatch> then sits there for 45mins until it times out
[22:33] <sinzui> hatch, I wonder if there is a network issue. I thought this might be an issue with the charm payload. which is bug 1156649
[22:33] <_mup_> Bug #1156649: pyJu fails to deploy/upgrade charm with 32MB payload <juju:New> <https://launchpad.net/bugs/1156649>
[22:34] <hatch> hmm nope it's not even getting that far
[22:34] <hatch> I think I'll bench this and make a card
[22:34] <hatch> start on it again on monday
[22:34] <sinzui> hatch, I think you are getting much farther since you have an instance doing an install
[22:34] <sinzui> have a nice weekend
[22:35] <hatch> you too!
[22:38] <sinzui> bac: I have good news and bad news. Since I did not go away as I claimed I was, I was here fir the reingest of the bundle. It works! this means we need a migration to purge all bundles before your changes are activated. Oh, but since I happen to know benji landed just such a migration 9 hours ago, we can just pretend you have. I am confident that no bundles will be in the db when we restart production.
[22:39] <sinzui> bac have a nice weekend.
[22:41]  * benji is glad to be part of the good news for once.
[22:51]  * bac missed the bad news
[22:52] <bac> it sounded like good news & good news


[01:07] <davef> Another RMC mailbag.. still no Psion.
[01:25] <ball> Did you send him one to review?
[01:25] <davef> Not me, daftykins .. I think
[01:26] <ball> Ah.
[01:30] <daftykins> yeah that was me, i've been pondering chasing it because that's months now with no response
[01:30] <ball> Was it a Psion II?
[01:33] <davef> I just looked at my ISPs moving form (I'm moving early June) and it still has the 'rona-19 questions that were being asked in the beginning.
[01:34] <davef> But then this is an opportunity to go with FTTH
[01:35] <davef> Which means signing up to .. *shivers* dare I say it? ... *cringe* .. Bell.
[01:35] <ball> Yeahno.
[01:36] <ball> Though I suppose technically Illinois Bell provide my local loop.
[01:36] <ball> ...but I pay Earthlink for the service.
[01:36] <davef> I'm talking Bell Canada
[01:36] <ball> Sure he was a Scotsman anyway ;-)
[01:37] <davef> But they are the only provider that can deliver GbE for the same price that I'm paying for 400/50 cable.
[01:37] <ball> Gigabit just plain isn't available here.
[01:37] <davef> The highest I can go is 3Gbps
[01:37] <ball> I think the most we can get is 45 Mbit/S
[01:38] <daftykins> Psion 3c
[01:38] <ball> I remember those
[01:38] <ball> brb
[01:39] <davef> I had some HP thing around the Psion era.
[01:39] <davef> Later on I had the OG Sharp Zarus linux PDA. I wish I still had that.
[01:39] <daftykins> hmm not familiar
[01:40] <daftykins> i've been meaning to email him and ask just wtf it is
[01:40] <davef> https://i.redd.it/f8vu13p7yxzz.jpg
[01:42] <davef> It has both compact flash and SD card slots
[01:43] <davef> I used a CF wifi adapter
[01:43] <daftykins> oh wow that's your pic?
[01:43] <davef> I wish
[01:43] <daftykins> oh yeah i already forgot you said you wish you held onto it
[01:44] <daftykins> alcohol may have been involved
[01:44] <davef> I don't remember what happened to it
[01:44] <daftykins> almost looks like Windows CE
[01:44] <davef> It ran some kind of QT based UI
[01:44] <daftykins> o0
[01:44] <davef> But it was Linux
[01:44] <penguin42> dont think I ever actually saw one
[01:45] <davef> they were rare
[01:45] <davef> I think I got mine from Argos
[01:46] <davef> And they didn't sell them for long
[01:46] <penguin42> talking of old stuff; I just stumbled across https://stak.com/Clearance/Bargain?limit=100
[01:47] <penguin42> it looks like a small PC dealers which has a box of prehistoric crap
[01:47] <penguin42> I mean, zip, jazz, dds, travan catridges, BNC T's, SCSI cabling
[01:47] <daftykins> lol wow this is like some old dinosaur listed their collection
[01:54] <penguin42> yeh I mean I've got shelves like that but...
[01:55] <daftykins> i've got this client that i implemented a separate backup strategy for, to a pair of USB HDDs on the 1st and 15th of the month
[01:56] <daftykins> the other day she responds to the 1st of the month having failed - and refers to them as tapes xD
[01:56] <daftykins> i visited and found they don't even plug them in flat inside the network cabinet D:
[01:57] <ball> Does that mean I should get rid of my SCSI cable collection?
[01:58] <daftykins> depends if you want to strike it rich on ebay :)
[01:58] <penguin42> ball: Is it worse than mine?
[01:58] <ball> penguin42: Possibly.
[01:59] <ball> daftykins: I've never sold anything on eBay
[02:00] <daftykins> ooh
[02:00] <daftykins> have some cat pics i had forgotten about: https://imgur.com/a/8D9kOsc
[02:01] <ball> That arm's the perfect width for the cat.
[02:01] <daftykins> :D
[02:01] <daftykins> she's gonna turn 18 soon
[02:01] <daftykins> i suppose then i'll have to fight the boys off
[02:03] <ball> Wow.
[02:04] <daftykins> omw i just spotted ultraviolet reactive rounded floppy cables on that page
[02:04] <ball> :-)
[02:04] <daftykins> hang on i've got penguin42's address, i'm buying the whole stock and shipping it to him ;)
[02:06] <ball> At least it's going to a good home. :-)
[02:06] <penguin42> hmm
[02:10] <daftykins> xD
[02:11]  * penguin42 doesn't have a Jazz drive though
[02:17]  * ball <- more interested in Ditto and PocketZip than Jazz.
[02:21] <daftykins> he can't leave us like that!
[02:21] <ball> H's off to dig through his RS-232 cable bin to make sure no SCSI cables have crept in there.
[02:23] <daftykins> :D
[03:43]  * ball wanders off
[22:04] <daftykins> it's nearly Monday :O
[22:05] <zxmpi> engage silent mode... ::screws in red light bulb after unscrewing white light bulb::
[22:06]  * daftykins unplugs the phones
[22:06]  * zxmpi sets jaffa cakes to manual
[22:33] <ball> I once worked at a university where the student discussion board (running on OpenVMS) included a popular debate on "Jaffa Cakes: Cake or Biscuit?"
[22:36] <daftykins> heh
[22:36] <ball> I think the eventual conclusion was that they were cakes because they went hard if left over time (sacrelidge) whereas biscuits go soft.
[22:38]  * ball goes back to deduping the family photo archive
[22:41] <daftykins> hmm feel like i saw a tech call in show where someone asked if there was software to do that, not sure the answers they gave
[22:42] <ball> I think I started out with about 33,000 files.  Just 18,476 left to go...
[22:43] <ball> Plus probably 1,600 on my wife's phone.
[22:46] <ball> Those will need backing up, scaling, deleting and the low-res versions uploading to iPhoto
[22:49] <ball> 18,345...
[22:50] <daftykins> uploading? iPhoto was an old macOS viewer and library prog to my mind
[22:51] <daftykins> how come something isn't in place to back 'em up directly?
[22:51] <ball> iPhoto on MacOS seems to be a client for the photos part of iCloud.
[22:52] <ball> ...so I use it to pull out a handfull of photos for processing, delete them and upload the low-res versions.
[22:52] <ball> Her phone is supposed to automatically back up photos to iCloud but she has something like 8 GB of photos because she forgets to turn off "live images".
[22:52] <ball> brb
[22:53] <daftykins> it's barely a dollar a month or something for the 50GB tier with crApple, had to bump a client up to the next one of ~200GB the other day due to having too many pics
[23:10] <ball> I think that's what she's on now.  Thought it was more expensive than that.
[23:10] <ball> I like having a local copy anyway.
[23:16] <ball> I should put them on a read-only share so that she can see them from her MacBook Air
[23:16] <ball> (for ordering prints, sharing online etc.)
[23:17] <daftykins> they renamed iPhoto long ago, must be an old model machine stuck on an EOL OS?
[23:17] <daftykins> run Nextcloud at home and set it up for auto photo upload :D
[23:17] <ball> No, I probably just didn't notice the name change.
[23:20] <ball> I would have looked at it but I moved across the room so that I could try Ubuntu in a VM on my own computer.
[23:20] <ball> ...and my computer doesn't run MacOS
[23:22] <ball> brb
[23:23] <daftykins> i keep up with the enemy xD
[23:38] <ball> Heh.


[04:40] <gkad> i'm new to tuxtrans. In that I would like to install tamil.ttf fonts. I could not copy the ttf in /usr/share/fonts/truetype, will you pls help me
[19:03] <Marius_> Hi
[19:03] <Marius_> Good afternoon all
[19:04] <Marius_> need a bit of help with autologin