[00:00] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_plasma-workspace build #146: STILL FAILING in 49 min: http://kci.pangea.pub/job/yakkety_unstable_plasma-workspace/146/
[00:00] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kdepim-runtime build #84: STILL FAILING in 37 min: http://kci.pangea.pub/job/xenial_unstable_kdepim-runtime/84/
[00:00] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:00] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kdepim-addons build #159: FIXED in 37 min: http://kci.pangea.pub/job/xenial_unstable_kdepim-addons/159/
[00:00] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:00] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_libkleo build #63: FIXED in 17 min: http://kci.pangea.pub/job/zesty_unstable_libkleo/63/
[00:00] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_ktp-common-internals build #176: STILL FAILING in 17 min: http://kci.pangea.pub/job/yakkety_unstable_ktp-common-internals/176/
[00:01] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kproperty build #16: STILL FAILING in 18 min: http://kci.pangea.pub/job/yakkety_unstable_kproperty/16/
[00:01] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_pimcommon build #58: STILL FAILING in 18 min: http://kci.pangea.pub/job/yakkety_unstable_pimcommon/58/
[00:01] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_libkleo build #111: STILL FAILING in 19 min: http://kci.pangea.pub/job/yakkety_unstable_libkleo/111/
[00:01] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:01] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_pimcommon build #45: FIXED in 17 min: http://kci.pangea.pub/job/zesty_unstable_pimcommon/45/
[00:01] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kdb build #24: STILL FAILING in 19 min: http://kci.pangea.pub/job/yakkety_unstable_kdb/24/
[00:01] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:01] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_dolphin build #183: FIXED in 17 min: http://kci.pangea.pub/job/yakkety_unstable_dolphin/183/
[00:10] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:10] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_libgravatar build #80: FIXED in 8 min 46 sec: http://kci.pangea.pub/job/yakkety_unstable_libgravatar/80/
[00:10] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_marble build #126: STILL FAILING in 59 min: http://kci.pangea.pub/job/yakkety_unstable_marble/126/
[00:17] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:17] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kdepim-apps-libs build #38: FIXED in 15 min: http://kci.pangea.pub/job/yakkety_unstable_kdepim-apps-libs/38/
[00:17] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kdepim-runtime build #71: STILL FAILING in 25 min: http://kci.pangea.pub/job/yakkety_unstable_kdepim-runtime/71/
[00:17] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:17] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kleopatra build #66: FIXED in 15 min: http://kci.pangea.pub/job/yakkety_unstable_kleopatra/66/
[00:17] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_khtml build #165: STILL FAILING in 20 min: http://kci.pangea.pub/job/yakkety_unstable_khtml/165/
[00:17] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:17] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:17] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_libksieve build #90: FIXED in 16 min: http://kci.pangea.pub/job/xenial_unstable_libksieve/90/
[00:17] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_incidenceeditor build #99: FIXED in 16 min: http://kci.pangea.pub/job/xenial_unstable_incidenceeditor/99/
[00:21] <KurousagiMK2> valorie: this it? https://launchpad.net/ubuntu/xenial/+package/libmarblewidget-qt5-23
[00:23] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kdepim-runtime build #85: STILL FAILING in 17 min: http://kci.pangea.pub/job/xenial_unstable_kdepim-runtime/85/
[00:24] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:24] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_messagelib build #103: FIXED in 23 min: http://kci.pangea.pub/job/xenial_unstable_messagelib/103/
[00:24] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:24] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_mailcommon build #70: FIXED in 23 min: http://kci.pangea.pub/job/zesty_unstable_mailcommon/70/
[00:24] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:24] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_libksieve build #89: FIXED in 23 min: http://kci.pangea.pub/job/yakkety_unstable_libksieve/89/
[00:25] <valorie> KurousagiMK2: yes
[00:25] <valorie> see the post on kubuntu-devel though -- I don't know how to answer the question
[00:30] <clivejo> need more info
[00:30] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_plasma-workspace build #147: STILL FAILING in 25 min: http://kci.pangea.pub/job/yakkety_unstable_plasma-workspace/147/
[00:30] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_ktp-common-internals build #177: STILL FAILING in 24 min: http://kci.pangea.pub/job/yakkety_unstable_ktp-common-internals/177/
[00:30] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:30] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_eventviews build #40: FIXED in 13 min: http://kci.pangea.pub/job/xenial_unstable_eventviews/40/
[00:30] <clivejo> what package is he trying to install
[00:31] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_incidenceeditor build #38: STILL FAILING in 13 min: http://kci.pangea.pub/job/yakkety_unstable_incidenceeditor/38/
[00:35] <acheronuk> he doesn't say
[00:35] <clivejo> kinda need to know that :P
[00:37] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kdepim-runtime build #72: STILL FAILING in 14 min: http://kci.pangea.pub/job/yakkety_unstable_kdepim-runtime/72/
[00:37] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:37] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_mailcommon build #53: FIXED in 13 min: http://kci.pangea.pub/job/xenial_unstable_mailcommon/53/
[00:44] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_messagelib build #139: STILL FAILING in 27 min: http://kci.pangea.pub/job/yakkety_unstable_messagelib/139/
[00:45] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:45] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_calendarsupport build #53: FIXED in 14 min: http://kci.pangea.pub/job/xenial_unstable_calendarsupport/53/
[00:50] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_marble build #127: STILL FAILING in 35 min: http://kci.pangea.pub/job/yakkety_unstable_marble/127/
[00:50] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_incidenceeditor build #39: STILL FAILING in 14 min: http://kci.pangea.pub/job/yakkety_unstable_incidenceeditor/39/
[00:57] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:57] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kmbox build #240: FIXED in 12 min: http://kci.pangea.pub/job/xenial_unstable_kmbox/240/
[00:57] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:57] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_akonadi-contacts build #115: FIXED in 12 min: http://kci.pangea.pub/job/xenial_unstable_akonadi-contacts/115/
[00:57] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:57] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_akonadi-search build #77: FIXED in 12 min: http://kci.pangea.pub/job/xenial_unstable_akonadi-search/77/
[01:02] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kwin build #128: STILL FAILING in 31 min: http://kci.pangea.pub/job/yakkety_unstable_kwin/128/
[01:03] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kreport build #35: STILL FAILING in 12 min: http://kci.pangea.pub/job/yakkety_unstable_kreport/35/
[01:03] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:03] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kcalutils build #107: FIXED in 12 min: http://kci.pangea.pub/job/yakkety_unstable_kcalutils/107/
[01:12] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:12] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_akonadi-mime build #126: FIXED in 14 min: http://kci.pangea.pub/job/xenial_unstable_akonadi-mime/126/
[01:12] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:12] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kldap build #262: FIXED in 15 min: http://kci.pangea.pub/job/xenial_unstable_kldap/262/
[01:12] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_messagelib build #140: STILL FAILING in 23 min: http://kci.pangea.pub/job/yakkety_unstable_messagelib/140/
[01:19] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kreport build #36: STILL FAILING in 10 min: http://kci.pangea.pub/job/yakkety_unstable_kreport/36/
[01:20] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:20] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_eventviews build #54: FIXED in 16 min: http://kci.pangea.pub/job/yakkety_unstable_eventviews/54/
[01:29] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:29] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:29] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_knotes build #60: FIXED in 16 min: http://kci.pangea.pub/job/yakkety_unstable_knotes/60/
[01:29] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_akonadi-import-wizard build #36: FIXED in 16 min: http://kci.pangea.pub/job/yakkety_unstable_akonadi-import-wizard/36/
[01:29] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:29] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:29] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_mbox-importer build #52: FIXED in 16 min: http://kci.pangea.pub/job/yakkety_unstable_mbox-importer/52/
[01:29] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_pim-storage-service-manager build #53: FIXED in 16 min: http://kci.pangea.pub/job/yakkety_unstable_pim-storage-service-manager/53/
[01:29] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:29] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:29] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_pim-data-exporter build #57: FIXED in 16 min: http://kci.pangea.pub/job/yakkety_unstable_pim-data-exporter/57/
[01:29] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:29] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_pim-sieve-editor build #49: FIXED in 16 min: http://kci.pangea.pub/job/yakkety_unstable_pim-sieve-editor/49/
[01:29] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:29] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:29] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_akonadiconsole build #35: FIXED in 16 min: http://kci.pangea.pub/job/yakkety_unstable_akonadiconsole/35/
[01:29] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_akonadi-calendar-tools build #49: FIXED in 16 min: http://kci.pangea.pub/job/yakkety_unstable_akonadi-calendar-tools/49/
[01:29] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kalarm build #63: FIXED in 16 min: http://kci.pangea.pub/job/yakkety_unstable_kalarm/63/
[01:29] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:29] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:29] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:29] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_blogilo build #63: FIXED in 16 min: http://kci.pangea.pub/job/yakkety_unstable_blogilo/63/
[01:29] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_grantlee-editor build #62: FIXED in 16 min: http://kci.pangea.pub/job/yakkety_unstable_grantlee-editor/62/
[01:29] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:29] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_akonadi-calendar build #75: FIXED in 16 min: http://kci.pangea.pub/job/xenial_unstable_akonadi-calendar/75/
[01:29] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kmail-account-wizard build #41: FIXED in 16 min: http://kci.pangea.pub/job/yakkety_unstable_kmail-account-wizard/41/
[01:35] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:35] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kontact build #55: FIXED in 15 min: http://kci.pangea.pub/job/yakkety_unstable_kontact/55/
[01:35] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:35] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kaddressbook build #52: FIXED in 15 min: http://kci.pangea.pub/job/yakkety_unstable_kaddressbook/52/
[01:36] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:36] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_akregator build #63: FIXED in 23 min: http://kci.pangea.pub/job/yakkety_unstable_akregator/63/
[01:36] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_korganizer build #47: NOW UNSTABLE in 16 min: http://kci.pangea.pub/job/yakkety_unstable_korganizer/47/
[01:38] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kwin build #129: STILL FAILING in 31 min: http://kci.pangea.pub/job/yakkety_unstable_kwin/129/
[01:41] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:41] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kmail build #71: FIXED in 20 min: http://kci.pangea.pub/job/yakkety_unstable_kmail/71/
[01:54] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:54] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kdepim-addons build #94: FIXED in 33 min: http://kci.pangea.pub/job/yakkety_unstable_kdepim-addons/94/
[02:03] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[02:03] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_calendarsupport build #65: FIXED in 9 min 13 sec: http://kci.pangea.pub/job/yakkety_unstable_calendarsupport/65/
[02:12] <valorie> clivejo, acheronuk: asked
[02:12] <valorie> also, acheronuk, did you notice you got some patches for 5.7.1+dfsg-3 ?
[02:13] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_akonadi-calendar build #62: STILL FAILING in 10 min: http://kci.pangea.pub/job/yakkety_unstable_akonadi-calendar/62/
[02:13] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_mailcommon build #71: STILL FAILING in 19 min: http://kci.pangea.pub/job/yakkety_unstable_mailcommon/71/
[02:29] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_akonadi-calendar build #63: STILL FAILING in 10 min: http://kci.pangea.pub/job/yakkety_unstable_akonadi-calendar/63/
[02:33] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_mailcommon build #72: STILL FAILING in 14 min: http://kci.pangea.pub/job/yakkety_unstable_mailcommon/72/
[02:42] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kpimtextedit build #166: STILL FAILING in 9 min 10 sec: http://kci.pangea.pub/job/yakkety_unstable_kpimtextedit/166/
[02:42] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[02:42] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kimap build #192: FIXED in 9 min 11 sec: http://kci.pangea.pub/job/yakkety_unstable_kimap/192/
[02:46] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[02:46] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_libkdepim build #62: FIXED in 13 min: http://kci.pangea.pub/job/yakkety_unstable_libkdepim/62/
[02:55] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kpimtextedit build #167: STILL FAILING in 7 min 37 sec: http://kci.pangea.pub/job/yakkety_unstable_kpimtextedit/167/
[02:55] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[02:55] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kmbox build #202: FIXED in 8 min 11 sec: http://kci.pangea.pub/job/yakkety_unstable_kmbox/202/
[02:55] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[02:55] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_krunner build #165: FIXED in 8 min 40 sec: http://kci.pangea.pub/job/yakkety_unstable_krunner/165/
[03:07] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[03:07] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kldap build #171: FIXED in 12 min: http://kci.pangea.pub/job/yakkety_unstable_kldap/171/
[03:07] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_libkleo build #112: STILL FAILING in 12 min: http://kci.pangea.pub/job/yakkety_unstable_libkleo/112/
[03:14] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_akonadi build #284: STILL FAILING in 27 min: http://kci.pangea.pub/job/yakkety_unstable_akonadi/284/
[03:28] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_libkleo build #113: STILL FAILING in 15 min: http://kci.pangea.pub/job/yakkety_unstable_libkleo/113/
[03:41] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_akonadi build #285: STILL FAILING in 22 min: http://kci.pangea.pub/job/yakkety_unstable_akonadi/285/
[03:56] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kwallet build #207: STILL FAILING in 14 min: http://kci.pangea.pub/job/yakkety_unstable_kwallet/207/
[04:17] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kwallet build #208: STILL FAILING in 15 min: http://kci.pangea.pub/job/yakkety_unstable_kwallet/208/
[04:38] <DarinMiller> I suspect nobody is here, but I thought I would try anyways....
[04:38] <DarinMiller> Looking into the calligra warnings on KCI: Noticed it's version 2.9 same as debian based on qt4.  v3.0 is qt5 and is in debian experimental.  Can we pull from debian experimental.
[04:38] <DarinMiller> ?
[04:41] <DarinMiller> Also, the calligra KCI console reports missing optional packages not found ( https://paste.ubuntu.com/23802348/ ) . How are deps handled for optional packages?
[06:17] <himcesjf> Hi, I am running Kubuntu 16.10 and I followed the channel topic link - http://qa.kubuntu.co.uk/ -> Kubuntu Smoke Tests -> Touchpad Management ->testing forms
[06:17] <himcesjf> There is minor mistake in instructions in the form
[06:18] <himcesjf> Change the behaviour of the "One Finger" setting to Middle Button, hit Apply, then tap with a single finger on the "Click Me" button on the right -- this is fine but
[06:18] <himcesjf> Change the behaviour of the "Two Fingers" setting to Middle Button, hit Apply, then tap with a single finger on the "Click Me" button on the right -- should be read as "tap with two fingers"
[06:18] <himcesjf> Change the behaviour of the "Three Fingers" setting to Middle Button, hit Apply, then tap with a single finger on the "Click Me" button on the right -- should be read as "tap with three fingers"
[06:19] <himcesjf> It says tap with single finger for all
[06:37] <valorie> ah, I wonder if I have the permissions to fix that
[06:40] <valorie> oh, that's in Google Docs
[06:40] <himcesjf> GoogleForms, yes
[06:41] <valorie> sitter: did you make those forms?
[06:41] <valorie> if so, can you share them with me?
[06:41] <valorie> oh, look at the hour, I'll email him
[06:46] <valorie> thank you for that, himcesjf
[06:46] <himcesjf> Sure thing
[06:50] <valorie> are you interested in helping us out, himcesjf?
[06:50] <himcesjf> Yep, went through Trello boards and QA link but Package Docs link - https://is.gd/zco9ne - asks for username and pw which I don't have
[06:52] <valorie> that's your KDE Identity
[06:52] <himcesjf> I would like to know about packaging and would like to see if I can help with packaging
[06:52] <valorie> Trello has it's own accounts -- we hope to move onto Free infra
[06:52] <himcesjf> So that link was the only way I suppose
[06:52] <valorie> do you have a KDE Identity?
[06:52] <himcesjf> No
[06:53] <valorie> really
[06:53] <valorie> gosh, everything but bko is tied to your KDE identity
[06:53] <valorie> https://identity.kde.org
[06:54] <valorie> use your real name
[06:54] <himcesjf> Oh, I think I did register there in past
[06:54] <himcesjf> Right, I have it. I forgot
[06:54] <valorie> great
[06:54] <himcesjf> Use my real name as username?
[06:55] <valorie> that won't work on bugs.kde.org, but it works everywhere else
[06:55] <valorie> yes please
[06:56] <himcesjf> Sure, let me see what I had set in past
[08:47] <acheronuk> valorie: patches where? for which Qt package?
[09:21] <Mirv> it's happening!
[09:27] <acheronuk> Mirv: it is????? :)
[09:29] <acheronuk> oooooh!
[09:34] <lordievader> Good morning
[09:34] <acheronuk> just got a email saying my previous bug on gold linker is 'fixed' so LP has picked up that transition :)
[09:34] <acheronuk> lordievader: indeed it is :)
[09:36] <lordievader> Hey acheronuk, doing good, I think?
[09:37] <acheronuk> yep. or at least a good start to a Sunday anyway.
[09:37]  * acheronuk wonders if it goes downhill from here
[09:37] <lordievader> :)
[10:33] <acheronuk> soee: morning
[11:35] <mparillo> Good morning. When LTS users experience problems, we generally ask them to try the backports PPA. Yesterday, my son wanted his super key to work, so I installed backports over 16.04. Just as was the case when I tested it a while ago, the Application Launcher shortcuts were lost, so I could not shut down that way. I could not even start the konsole that way. I had to use krunner to launch a konsole and sudo poweroff.
[11:35] <mparillo> Is there an easier way? A more systemd way?
[11:41] <acheronuk> https://www.freedesktop.org/software/systemd/man/systemctl.html
[11:41] <acheronuk> systemctl reboot ?
[11:42] <acheronuk> never tried it....
[11:53] <mparillo> Thanks. But if it is normal for major Plasma upgrades to lose some App Launcher shortcuts, do we need to add that in our standard Backports announcements?
[11:56] <acheronuk> mparillo: Not lost any in the upgrades I've tried
[12:10] <mparillo> OK, thanks
[13:07] <BluesKaj> Hiyas all\
[14:03] <clivejo> acheronuk: you about?
 @clivejo, Later maybe
[14:23] <clivejo> ok
[14:23]  * clivejo watches digikam build
[14:53] <clivejo> yipppeeee
[14:53] <clivejo> digikam built on arm64 :)
 Nice
[15:57] <clivejo> and released!
[15:57] <clivejo> !info digikam zesty
[16:08] <clivejo> hi DarinMiller
 @clivejo, :)
[16:10] <clivejo> stupid bot!
 is it?
[16:11] <clivejo> yeah, takes ages to update :P
 oh, yes
 @DarinMiller, KCI unstable branch for calligra says <IP_ADDRESS> here
[16:13] <clivejo> @acheronuk would you have time today to go through apps
 go through in what sense? noting which sources are PIM and which are not?
 @DarinMiller, KCI unstable branch for calligra says <IP_ADDRESS> here
[16:19] <clivejo> splitting out PIM and ones that won't build
[16:20] <clivejo> doing an upload of the ones that look good
[16:21] <clivejo> PIM will have to be uploaded by an MOTU anyways due to all the NEW packages from the splits
 I expect this evening, yes
[16:21] <clivejo> Id like to split them into three groups, GOOD, PIM and WIP
 ok
[16:24] <clivejo> any idea on when you be free?
 My main PC running zesty upgraded to Qt 5.7.1 without hitch :)
 @clivejo, ummm... 7pm onwards seems likely
[16:24] <clivejo> too much wine?!?
 give or take a margin if error
 @clivejo, I wish
[16:26] <DarinMiller> G'morning/afternoon.  I missed whoever mentioned me prior to Rik's 9:16 comment (laptop locked up when unplugged).
[16:27] <ejat> The following packages will be REMOVED:
[16:27] <ejat>   kde-style-qtcurve-qt5
[16:27]  * DarinMiller wishes Nvidia would fix their video drivers for hybrid laptops.  GPU's should not fall off the bus when power is unplugged.
[16:28] <clivejo> Nvidia should do a lot more for Open Source, but dont
 @DarinMiller, No prob. I was just replying to your comment last night, as clivejo saying hello to you presumably meant you were about now
[16:28] <DarinMiller> Agreed!
[16:30] <clivejo> DarinMiller: what were you looking at will calligra?
[16:30] <clivejo> with
 @ejat, that package depends on the Qt ABI it was compiled on, so any upgrade of Qt version needs that rebuilt. so I guess you are hitting that issue somewhere.
 Fwd from DarinMiller: <DarinMiller> Looking into the calligra warnings on KCI: Noticed it's version 2.9 same as debian based on qt4.  v3.0 is qt5 and is in debian experimental.  Can we pull from debian experimental.
[16:32] <clivejo> I read that, but don't understand
[16:32] <ejat> @acheronuk so i should wait for all compiled ?
 @ejat, what Qt are you upgrading from where?
[16:33] <clivejo> it should be <IP_ADDRESS> in KCI
[16:33] <Mirv> acheronuk: nice that everything seems pretty smooth!
[16:33] <DarinMiller> KCI flagged calligra with build warnings so I started investigating.
[16:34] <Mirv> ejat: acheronuk: qtcurve has been recompiled (otherwise the release pocket migration would not have happened), it should not be removed though either. maybe some PPAs in use?
[16:34] <ejat> acheronuk: http://paste.ubuntu.com/23805249/
[16:36] <ejat> Mirv: i dont use any kubuntu currently
[16:36] <clivejo> ejat: what dist version are you using?
[16:37] <ejat> clivejo: zesty
 @Mirv, yep, kde-style-qtcurve-q5 upgraded fine with Qt 5.7.1 and works great here. I use that mostly for my UI, so really pay attention to that one
[16:38] <clivejo> ejat: with or without poroposed?
[16:38] <ejat> without proposed
[16:39] <Mirv> double-checked, https://launchpad.net/ubuntu/zesty/amd64/kde-style-qtcurve-qt5/1.8.18+git20160320-3d8622c-3build1~4 has qtbase-abi-5-7-1
 @ejat, maybe you had a version with a higher version from a ppa somewhere, so it removed rather than upgraded when the ABI broke?
[16:39]  * DarinMiller notes that qt 5.7.1 is working spendidly on his zesty box also.
[16:40] <Mirv> this is a problem that's really hard to debug without being at the computer :)
[16:40] <Mirv> DarinMiller: nice!
[16:40] <Mirv> ejat: pastebin apt-cache policy libqt5core5a ?
 ejat: 'sudo apt-get install kde-style-qtcurve-q5=1.8.18+git20160320-3d8622c-3build1~4'
[16:40] <KurousagiMK2>  kde-style-qtcurve-qt5 depend libqtcurve-utils2, out there do not have one http://paste.ubuntu.com/23805249/
[16:41] <ejat> Mirv: http://paste.ubuntu.com/23805296/
[16:41] <Mirv> just in case, to check that no suggestions come from any PPA and one of them (to be upgraded to) is the newest 5.7.1+dfsg-2ubuntu1~8
[16:41] <Mirv> ejat: right, looks correct
[16:42] <ejat> acheronuk: E: Unable to locate package kde-style-qtcurve-q5
[16:42] <Mirv> acheronuk: qt5, not q5
[16:42] <Mirv> sorry, I meant ejat ^
 ejat Mirv: I had to bump qtxureve version for backports etc. coudl be I chose a migher version schem than you did for the qt 5.7.1 rebuilt one
[16:43] <ejat> http://paste.ubuntu.com/23805312/
 ejat: I may have mistyped that package name on telegram
[16:43] <Mirv> ejat: ah, right, that means you have the qtcurve from some PPA with higher number, ok, problem solved
[16:43] <ejat> acheronuk: http://paste.ubuntu.com/23805312/
[16:44] <ejat> Mirv: i just proceed ?
[16:44] <ejat> downgrade the qt?
[16:44] <Mirv> ejat: nothing is removed, lots is upgraded, yes that's usually a good thing. maybe try dist-upgrading then after that still to be sure.
[16:45] <Mirv> ejat: downgrade one package, which actually is an upgrade but just to a version number that happens to be lower :)
 yes, and disable the ppa the higher version came from if it is still active
[16:45] <ejat> ok ..
[16:45] <Mirv> right, if dist-upgrade says something about removing again, don't proceed
[16:45] <Mirv> but try to find some offending PPA to disable
 Mirv: we should probably comminate on such version bumps in the future, but there are so many things to think about I did not consider mentioning it
 even if they are only bumped in ppas
[16:47] <Mirv> acheronuk: yes, there are many things to think about with Qt always :) too many..
 indeed!
[16:48] <Mirv> having an automated versioning scheme that's logical helps. I've used the ~2 etc for archive rebuilds, but for xenial-overlay PPA I use ~~xenial1 for example which is always lower than any with one ~
 Mirv: I think I also grabbed a new qtcurve git snapshot from debian for the backports, which I assumed/hoped would get synced from debaoin to zesty, and maybe it has not yet, so you rebuild was on the old version?
 will have to check later
[16:55] <Mirv> acheronuk: Debian has an old version from last May too, but the same is in Ubuntu
[16:55] <Mirv> no Ubuntu changes -> automatic syncing
[16:55] <Mirv> (and I use the "buildN~2" syntax for my rebuilds which preserves the automatic syncing)
 umm. maybe not then :/
[17:04] <clivejo> Sput: In quassel 0.12.4 why do certain users private messages disappear until they reply?
[17:30] <clivejo> !jenkins
[17:33] <clivejo> DarinMiller: can you see what is wrong with discover on KCI?
[17:45] <DarinMiller> clivejo:  checking on Discover shortly.....
[17:47] <clivejo> no prob, g2g for a bit myself
[18:37] <acheronuk> clivejo: if I run kdesrcbuild, these are the PIM repos it wants to clone and build http://paste.ubuntu.com/23805994/
[19:10] <clivejo> is prison not a framework?
[19:15] <acheronuk> It is. I pulled the latest metadata and kdesrcbuild output "Building prison from kde-pim (6/56)"
[19:15] <acheronuk> so that is a bit out of date
[19:15] <acheronuk> with anything like that, you need to sanity check the list
[19:16] <acheronuk> that paste was just 'kdesrc-build kde-pim --pretend | grep Building | awk '{print $2}' | pastebinit'
[19:17] <acheronuk> so raw output filters a bit to show packagenames
[19:18] <DarinMiller> qq: reviewing the disover console output: dh_install: plasma-discover-common missing files: usr/share/plasmadiscover/*
[19:18] <DarinMiller> but usr/share/plasmadiscover/* is in the .install file.
[19:19] <acheronuk> DarinMiller: it is, yes
[19:20] <DarinMiller> next error: /usr/share/pkg-kde-tools/qt-kde-team/3/dhmk.mk:112: recipe for target 'debian/dhmk_install' failed
[19:20] <DarinMiller> so need to add usr/share/pkg-kde-tools/qt-kde-team/3/ directory?
[19:20] <clivejo> DarinMiller: see above that, you have a list of all the files being built
[19:21] <DarinMiller> looking...
[19:21] <acheronuk> dh_install installs the files built by the build according to the .install files
[19:21] <clivejo>  dh_install: plasma-discover-common missing files: usr/share/plasmadiscover/*
[19:22] <clivejo> so dh_install is processing that package plasma-discover-common
[19:22] <clivejo> and the install file is plasma-discover-common.install
[19:22] <acheronuk> so it's telling you that the install files expect to find files with that path to install, but they are "missing" in what was built
[19:22] <clivejo> its trying to find a match with usr/share/plasmadiscover/*
[19:22] <clivejo> but not finding anything
[19:23]  * acheronuk zips it so not to confuse
[19:25]  * DarinMiller 's middle name is "Confusion"
[19:26] <clivejo> it is very confusing, as there are two types of missing files
[19:27] <clivejo> basically you have list-missing which is a built file, but no install file tells it where to be installed
[19:27] <DarinMiller> reviewing console output and attempting to digest...
[19:28] <clivejo> and this one where the install file references it, but the compiled/built files dont exist
[19:28] <DarinMiller> but usr/share/plasmadiscover/* is in plasma-discover-common.install
[19:28] <clivejo> yes
[19:28] <DarinMiller> OK, let keep looking....
[19:28] <clivejo> but if you look at the list of files the source is creating
[19:28] <acheronuk> look at the list of files that were actually built
[19:29] <clivejo> there are none actually matching that pattern
[19:29] <acheronuk> and their paths
[19:43] <clivejo> DarinMiller: do you understand?
[19:44] <clivejo> The solution is to remove the line which is trying to install files which are not being built any more
[19:47] <DarinMiller> So the error/warning is not telling us it's unable to install, it's saying it has nothing to install in the specified directory (usr/share/plasmadiscover/*)?
[19:48] <DarinMiller> so remove usr/share/plasmadiscover/*?
[19:49] <clivejo> there used to be files in there
[19:49] <clivejo> but due to recent change, those files arent there any more
[19:52] <DarinMiller> Makes sense. I was attempting to rectifiy an existance (need to park files somewhere but can't) issue as opposed to an "absense" issue (clean up after yourself).
[19:52] <clivejo> This is the package in the last build - http://paste.ubuntu.com/23806409/
[19:53] <clivejo> The used to be a file called usr/share/plasmadiscover/featured.json
[19:53] <DarinMiller> So why does the build process not create the needed install dir's dynamically?
[19:53] <clivejo> which that line was installing into plasma-discover-common
[19:53] <DarinMiller> one lonely featured.json file is no longer used....
[19:53] <clivejo> upstream developers have decided to do away with that file
[19:54] <clivejo> I would assume they made it dynamic
[19:54] <clivejo> and gets updated from the interwebs
[19:56] <acheronuk> DarinMiller: as packagers often have good reason to pick and choose what files to install, what package to put them in, and even where to install them
[19:56] <DarinMiller> why does debian packaging have .install files that are not auto generated by the build process.  That would take care of this issue.  I can understand if you wanted to overrided the default install location, then use a .install for override.
[19:57] <clivejo> Debian is very strict on what goes where
[19:58] <clivejo> we have -dev, -common, -data packages to organise where to put things
[19:58] <DarinMiller> Problem understood.  Fixing now...
[19:58] <acheronuk> some very simple packages don't have .install files so everything just goes to the default place in the one resultant .deb
[19:59] <acheronuk> but most need things separating out
[19:59] <clivejo> and some very complex ones have loads of packages all generated from the single source!
[20:00] <acheronuk> old PIM!
[20:00] <acheronuk> calligra
[20:00] <clivejo> and its a real headache trying to work out what goe where
[20:00] <DarinMiller> oh, ok so what i was saying is possible, but the deb packages we inherit add some "excitement" to our lives.
[20:01] <clivejo> not just some
[20:01] <clivejo> shed loads
[20:01] <acheronuk> big sheds at that
[20:01] <acheronuk> almost small warehouses
[20:05] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_umbrello build #155: STILL UNSTABLE in 18 min: http://kci.pangea.pub/job/yakkety_unstable_umbrello/155/
[20:05] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_umbrello build #81: STILL UNSTABLE in 19 min: http://kci.pangea.pub/job/zesty_unstable_umbrello/81/
[20:08]  * DarinMiller looking forward to small warehouses of excitement
[20:10] <clivejo> take one warehouse at a time!
[20:11] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_umbrello build #184: STILL UNSTABLE in 24 min: http://kci.pangea.pub/job/xenial_unstable_umbrello/184/
[20:13] <clivejo> ahoneybun: https://www.youtube.com/watch?v=sUhvKTq6c40
[20:15] <DarinMiller> submittin mp... what is the "Target reference path" .... kubuntu-unstable?
[20:16] <DarinMiller> ^g
[20:16] <clivejo> yup#
[20:16] <clivejo> remember a changelog entry
[20:21] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_umbrello build #82: STILL UNSTABLE in 15 min: http://kci.pangea.pub/job/zesty_unstable_umbrello/82/
[20:21] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_umbrello build #156: STILL UNSTABLE in 15 min: http://kci.pangea.pub/job/yakkety_unstable_umbrello/156/
[20:22] <DarinMiller> MP complete: dch comment added and as well as git commit -m "pertinent comment here".  Let me know if I missed something.
[20:24] <acheronuk> into ~kubuntu-packagers/kubuntu-packaging/+git/akonadi-calendar-tools
[20:24] <acheronuk> eek! ^^^
[20:26] <acheronuk> target set wrongly I guess
[20:27] <DarinMiller> weird.... attempting to fix...
[20:29] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_umbrello build #185: STILL UNSTABLE in 17 min: http://kci.pangea.pub/job/xenial_unstable_umbrello/185/
[20:32] <DarinMiller> Fixed: https://code.launchpad.net/~darinsmiller/kubuntu-packaging/+git/discover/+ref/kubuntu_unstable
[20:33] <DarinMiller> not sure how the akonadi-calendar-tools link ended up there...
[20:50] <valorie> wow, busy Sunday! y'all have been productive
[21:04] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[21:04] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_discover build #106: FIXED in 15 min: http://kci.pangea.pub/job/zesty_unstable_discover/106/
[21:05] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[21:05] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_discover build #116: FIXED in 15 min: http://kci.pangea.pub/job/xenial_unstable_discover/116/
[21:05] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[21:05] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_discover build #104: FIXED in 15 min: http://kci.pangea.pub/job/yakkety_unstable_discover/104/
[21:37] <clivejo> having connection problems DarinMiller?
[21:38] <DarinMiller> Moved my laptop back to the computer room. GPU fell of the bus again when laptop lost power.
[21:40] <valorie> :(
[21:44] <jokwvgf> hello
[21:45] <clivejo> hi jokwvgf
[21:45] <jokwvgf> anyone here?
[21:45] <jokwvgf> does kubuntu have uefi on the 32bit image?
[21:46] <jokwvgf> hey clivejo
[21:46] <jokwvgf> how's max?
[21:46] <mparillo> I do not think the 32-bit image supports UEFI.
[21:46] <jokwvgf> i have a table with windows 8
[21:47] <jokwvgf> an dit only has 32bit cpu
[21:47] <jokwvgf> i need to get rid pf windows
[21:48] <jokwvgf> clivejo have ypu finished the tuica?
[21:49] <clivejo> He's fine
[21:49] <clivejo> the what?
[21:49] <jokwvgf> dont tell them who i am
[21:49] <clivejo> I dunno who you are!
[21:49] <jokwvgf> oh...
[21:54] <jokwvgf> any ideas on how i v
[21:54] <jokwvgf> i can boot kubuntu on this thing?
[21:56] <DarinMiller> jokwvgf: Did  you try disabling UEFI in the BIOS?
[21:56] <jokwvgf> DarinMiller: that doesnt make sense
[21:57] <jokwvgf> you mean secure boot, right?
[21:58] <jokwvgf> clivejo, i just have 32bit with uefi
[21:58] <jokwvgf> on the cpu support
[21:58] <DarinMiller> jokwvgf: yes
[21:58] <jokwvgf> the problem isnt booting, its.... booting.... err... after...
 Get out you troll
[22:00] <jokwvgf> fine... bye
[22:00] <valorie> that was very strange
 What?
[22:01] <clivejo> Ovi, why so rude?
 He was annoying
[22:02] <clivejo> I agree, but no need to say it!
 Well he knows he can't boot 32 bit uefi
[22:02] <clivejo> trolls are people too
[22:04] <clivejo> and a fellow Aridian judging from its IP
 I hate that guy
 Aridian?
[22:04] <clivejo> Aradian
[22:04] <clivejo> someone from Arad
 Ah...
 Yeah I know
[22:05]  * clivejo nods knowingly
 He's in my house now
[22:05] <clivejo> kick him out in the cold
 Doing it now
 Out in the snow with him
[22:06] <clivejo> and file an abuse report with his ISP
[22:08] <valorie> playing games with yourself, ovidiuflorin?
 clivejo is in kahoots with him
[22:09]  * sintre is now really confused
[22:09] <clivejo> me?
 Yes
[22:09] <clivejo> I only met him once, in Berlin
[22:09] <clivejo> hes crazy I tell ya
 I know
 That's why I kicked him out
[22:10] <clivejo> he shouldnt be allowed our of Romania
[22:10] <clivejo> out
[22:11] <clivejo> or anywhere near a Steak House
 That reminds me
 I'm hungry
[22:12] <clivejo> its 11:12pm !!
 Not here
 Here it's later
[22:13] <clivejo> 0:13am?
[22:14] <clivejo> or is that 12:13am
[22:14]  * clivejo gets confused
 0
 (Photo, 1280x720) https://irc-attachments.kde.org/0aiGPWhz/file_1756.jpg
[22:15] <valorie> I thought it was Makita stores he has to be kept away from?
[22:15] <valorie> oh dear
[22:15] <clivejo> ovidiuflorin: why did you miss the devel chat yesterday?
[22:15] <valorie> that looks too much like the final product
 What devel chat?
[22:16] <clivejo> not gonna say what that looks like
[22:16] <clivejo> yup
[22:16] <clivejo> https://lists.ubuntu.com/archives/kubuntu-devel/2017-January/011080.html
 I'm very behind with my emails
 I'm afraid to open it
[22:20] <clivejo> does anyone know how to check if you have hidden a conversation in quassel
[22:21] <clivejo> for some reason I keep Darin's conversation open
[22:21] <clivejo> I cant keep
[22:21] <clivejo> once I go out of his conversation he disappears
 What happened yesterday?
[22:22] <clivejo> We started a fork
[22:22] <clivejo> KDEUbuntu
 Wtf?
[22:23] <clivejo> LOL
[22:23] <clivejo> nah, just chatted about Qt and road blockers, how to proceed etc
[22:24] <clivejo> acheronuk has done some tests and apparently we might not need gpgme for FW5.30
 We do for pim
[22:25] <clivejo> valorie: the Community ML seems to be quite positive now, how would we go about requesting Phab project?
 Pinged the sysadmins for that I
[22:26] <clivejo> yes, I think we'll have to do a partial upload of apps (ie minus PIM)
 Is that possible?
[22:26] <clivejo> should be
[22:26] <clivejo> Phil talked about it in the past
[22:26] <clivejo> Id like to get the other apps in ASAP
[22:27] <clivejo> kdenlive, games, etc
[22:29] <clivejo> BTW who is our nominated tester master person?
[22:29] <clivejo> was it wxl?
[22:34] <clivejo> valorie: do you know?
[22:36] <valorie> I never heard of a post called "tester master person"
[22:37] <valorie> clivejo: putting in a sysadmin request for the phab board is on my today's todo
[22:37] <clivejo> to opt in to the alpha 2
[22:37] <valorie> nobody did that yet, correct?
[22:37] <valorie> clivejo: I'll ping the KC again to give wxl the nod as the release manager
[22:37] <clivejo> there was a conversation about putting a name forward
[22:38] <valorie> right, but it got about two or three +1
[22:38] <valorie> and then died out
[22:38] <valorie> and the active packagers Kubuntu Developers didn't chime in as I recall
[22:38]  * clivejo looks around
[22:39] <valorie> Max ain't gonna post for you, dude
[22:40] <clivejo> is wxl willing to co-ordinate it?
[22:41] <clivejo> is he not the Lubuntu nomination as well?
[22:41] <valorie> he offered, yes
[22:42] <valorie> he also does Lubuntu, although was planning to hand it to Simon
[22:42] <clivejo> well get the paperwork done :P
[22:42] <valorie> not sure what that plan is now
[22:42] <valorie> I'll ask if he's still willing
[22:45]  * clivejo pushes wxl into the spotlight
[22:56] <valorie> sysadmin request filed
 where does quassel store its config?
 @CliffordTheBigRedDoggie right click on any chat
 Select show all
 Make sure the chat you want is enabled
 Fully!
[23:07] <clivejo> it doesnt appear in the chat list
[23:26] <clivejo> can I get some people on xenial and yakkety to test digiKam 5.4 - launchpad.net/~clivejo/+archive/ubuntu/digikam/
[23:27] <valorie> ah, I should get my xenial box working again
[23:28] <valorie> right after I write the email re: RM wxl


[05:37] <infinity> cjwatson: Don't worry about the d-i ABI bump upload, I'm going to do some ARM generic mangling tomorrow and kill a few birds with one stone.
[07:27] <cjwatson> infinity: ok
[07:28] <cjwatson> infinity: dannf posted a couple of MPs for generic stuff (base-installer and debian-installer)
[07:30] <infinity> Yeah.  I wasn't going to bother doing omap/generic across the board everywhere this close to release, but if we start in one spot, we may as well just clean it all up and be done with it.
[13:03]  * xnox leaves infinity to merge&upload the three s/highbank/generic/ patches from the sponsorship queue.
[14:49] <bdmurray> cjwatson: could you have a look at the patch in bug 1166595?
[14:49] <ubot2> Launchpad bug 1166595 in libdebian-installer (Ubuntu) "should use generic flavor on highbank" [Undecided,New] https://launchpad.net/bugs/1166595
[14:53] <cjwatson> bdmurray: infinity was going to look at that stack of patches
[14:53] <bdmurray> cjwatson: okay, thanks
[17:52] <infinity> bdmurray: Yeah, I'm looking at those and reworking some.


[12:43] <stgraber> Sorry to disturb but I still have this really annoying regression on Feisty : bug #88400
[12:44] <stgraber> anyone has something I should try that I didn't do already ?
[12:44] <stgraber> I really hate the idea to have sound on Edgy and then nomore on Feisty
[01:18] <zul> Im pretty sure its being worked on
[01:20] <stgraber> I hope so (I'm currently retrieving the latest kernel from git to check what really does this patch and maybe find the key)
[02:45] <crimsun> stgraber: it's probably the toshiba model addition
[02:45] <crimsun> stgraber: have you verified that you're running the latest bios on your hardware?
[02:47] <mjg59> crimsun: Did you see my followup about the Macbook audio?
[02:47] <crimsun> mjg59: yes, I was just about to reply in -devel
[02:47] <crimsun> (I've got about 6000 backlogged emails from travel)
[02:47] <mjg59> Heh
[02:48] <mjg59> Anyway, it seems to work for me (which is arguably an improvement over the current situation)
[02:49] <crimsun> great, I'll look at that as soon as I get this email conundrum into reasonable shape
[02:49] <crimsun> I've also got elmo's sound regression on radar
[02:49] <mjg59> Cool
[10:18] <stgraber> crimsun: I'll check but I updated it something like two months ago
[10:29] <stgraber> crimsun: They released a new bios 3 weeks ago, I'm flashing it now
[10:29] <stgraber> (If I can find a non-Windows version of it :))
[12:22] <stgraber> crimsun: ok, I've flashed my bios but still no sound ...
[05:40] <bdmurray> What do kernel error messages about usb like "not accepting address xy, error -71" mean?
[05:40] <kylem> oh, pftt, error -71! isn't that obvious!
[05:40] <kylem> ;P
[05:41] <kylem> (i haven't the foggiest, got a bug url?)
[05:51] <bdmurray> kylem: https://launchpad.net/ubuntu/+bug/88746
[05:51] <bdmurray> see the dmesg attachment
[05:51] <kylem> thanks.
[05:51] <kylem> i'll queue it after my current AT
[05:53] <bdmurray> I'm not specifically curious about this bug but rather about that set of messages in general
[09:56] <stgraber> crimsun: I've flashed my bios with the latest version from toshiba and guess what, no change ...
[09:57] <crimsun> stgraber: yes, I read backscroll. I'll give you a patch to try backing out.
[09:57] <stgraber> thank you
[09:57] <crimsun> ETA is a few hours, right now I'm a bit busy


[00:14] <wgrant> kyrofa: I think we'll need to extend the way snap builds work now that branches are widely supported. Can you file a bug detailing your specific use case?
[00:14] <nacc> kyrofa: if you do file a bug, i'd be really interested as well
[16:36] <johnl> hi, I can't get my launchpad recipe to use the specified git branches. It defaults to a branch literally named "HEAD" instead. Is this a launchpad bug maybe? https://answers.launchpad.net/launchpad/+question/654438
[17:22] <kyrofa> wgrant, nacc sure thing. Against launchpad-buildd?
[17:42] <kyrofa> wgrant, nacc here is my tome of a bug report: https://bugs.launchpad.net/launchpad-buildd/+bug/1709416
[17:50] <nacc> kyrofa: well written, I'll be curious to see what wgrant thinks
[17:51] <kyrofa> Thanks nacc :)
[21:29] <geekgonecrazy> Anyone aware of amd64 snap build workers being locked up?  Keeps saying 1 hour to build even after several hours.  armhf seems to be processing like usual
[21:39] <dobey> https://launchpad.net/builders
[21:39] <dobey> lots of private jobs building, and probably taking too much time for some reason
[21:40] <geekgonecrazy> ah! Thanks for the link.  Some point in past probably saw that but forgot about it :D
[21:40] <geekgonecrazy> yeah looks like very high compared to arm which is pretty empty
[21:41] <dobey> x86 is likely to be a bit slower in any case, given all the PPAs/recipes on launchpad, and most probably not building on arm
[21:41] <geekgonecrazy> i'm guessing build.snapcraft.io probably comes over as private job
[21:41] <dobey> no idea
[21:43] <geekgonecrazy> dobey: thanks for think.  I guess at least I have a reason as to the slowness :D I guess if I get impatient enough i'll have to go the local lxd route to get this release out
[21:43] <geekgonecrazy> link*
[21:44] <kyrofa> Hey dobey, good to see you :)


[01:07] <dcordes> These instructions can be used to work around the locked panel: https://help.ubuntu.com/community/UbuntuNetbookEdition/ConvertGnomeSession
[01:08] <dcordes> It will add une-efl to the gnome session
[01:15] <ogra_ac> dcordes, totally wrong for maverick though
[01:19] <ogra_ac> (and breaks the gnome session)
[01:20] <dcordes> ogra_ac: ok what is right for maverick ?
[02:07] <dcordes> I think it is difficult to close windows with the maximus concept
[06:49] <ajay> hi all, i have connected usb to serial connector ,i need to connect cross null modem female to female cable so i chave connected female to male cross null modem cable
[06:50] <ajay> to which i connected straight female to female null modem cable
[06:50] <ajay> to this i connected DB9 to IDC 10 cable
[06:50] <ajay> does cable length affects for minicom
[06:51] <ajay> due this connection cable length got incresde
[06:51] <ajay> increased
[06:54] <rsalveti> ajay: hey, don't know if you saw what lool wrote about serial and igepv2
[06:54] <rsalveti> seems to be a common issue
  rsalveti: Plenty of people get this issue with IGEP
  There is a hardware grounding issue I'm sure
  one workaround is using a differnt USB serial adapter, or a real PC serial port; another workaround is plugging a mini-USB cable to the IGEP to help grounding
[06:55] <rsalveti> ajay: ^
[06:57] <ajay> rsalveti, thanks but i have tested with different serial adapter getting same issue and other is mini USB ,can you please tell how to solve grounding problem
[06:58] <rsalveti> ajay: if you have a mini-usb cable, you could connect it at igepv2 and your pc
[06:58] <rsalveti> that should help fixing the grounding issue
[06:59] <ajay> rsalveti, i need to get a mini USB cable for this
[07:00] <ajay> mini USB need to connect to pc USB port correct?
[07:00] <ajay> i mean mini USB port to igep and other port to PC USB port
[07:00] <rsalveti> ajay: yep
[07:04] <ajay> rsalveti,if i connect hdmi  cable to board then i am getting just blank screen it means board is somewhat booting till uboot
[07:04] <ajay> am i right?
[07:08] <rsalveti> not sure
[07:10] <ajay> rsalveti, if i change omapfb parameter for boot.ini file then different behaviour shows that is some time signal is not proper
[07:12] <rsalveti> hm, ok, so it seems your kernel is booting
[07:13] <ajay> rsalveti, yes but i am not getting any display on monitor so thought to chech in minicom but there also i am not getting message
[07:13] <ajay> may be as you told grounding issue
[07:14] <ajay> rsalveti, is there any way to debug using ethernet port?
[07:14] <ajay> i mean using PC to PC cable
[07:15] <rsalveti> you first need a working kernel
[07:17] <ajay> rsalveti, that i have downloaded from their website
[07:17] <ajay> a binary image
[09:02] <ajay> rsalveti, i am followed steps for ubuntu 10.10 as mentioned http://labs.igep.es/index.php/How_to_get_the_Ubuntu_distribution
[09:03] <ajay> using wget downloaded image and then created boot.ini and removed MLO,uboot.bin boot.scr from /booot
[09:03] <ajay> and connected minicom and then did power on but with this also i am not getting any message over minicom
[09:04] <ajay> surely something is wrong in my board or setup
[09:05] <ajay> minicom i have setup as per wiki mentioned for minicom8N1 115200
[10:23] <ajay>  rsalveti i  got a mini A USB cable but as you suggested i connected mini A port to igep board where do i need to connect other port of Mini A USB cable
[10:24] <ajay> rsalveti, for solving grounding issue
[16:03] <dcordes> go home button messes up onboard: it hides onboard itself along with the floating 'show onboard button' that should be always on top


[18:21] <bkerensa> bdmurray: do you have a list of bug squad contributors for this cycle?
[18:25] <bdmurray> bkerensa: not right at hand but it should be easy to generate
[18:25] <bkerensa> bdmurray: I shall PM you the release notes staging link


[00:02] <lifeless> pickscrape: I'm not aware of any BB maintainers, no.
[00:20] <kfogel> lifeless: can I pick your brains for a sec about bzr+ssh and hooks?  about 5 min
[00:20] <lifeless> kfogel: no.
[00:20] <lifeless> kfogel: you can read my reply to beuc, then come and pick my brains after that.
[00:20] <kfogel> lifeless: I did.
[00:20] <lifeless> ok cool
[00:20] <kfogel> lifeless: oh, wait -- you mean in the last half hour or so?
[00:20] <lifeless> 120 seconds ago
[00:20] <kfogel> lifeless: I was writing a reply, then wanted to confirm something... heh
[00:20] <kfogel> lifeless: cool
[00:21] <kfogel> lifeless: you may have made my whole reply unnecessary.  I'll go read now.
[00:25] <lifeless> kfogel: bzr-hookless-email is totally different, btw.
[00:26] <kfogel> lifeless: I know (I'm well-acquainted with it, and have a patch in it actually).  I think it is what Stefan is using for commit emails, but am not positive.
[00:26] <kfogel> I'm pretty sure we're *not* using bzr-email.
[00:26] <lifeless> well, you can't, until bzr-ssh is enabled.
[00:26] <lifeless> at which point you probably should :P
[00:27] <kfogel> lifeless: actually, I like Stefan's solution much better, because then mods to our commit email system do not have to block on savannah admins!
[00:27] <lifeless> kfogel: I don't see the connection, but I don't care either.
[00:27] <lifeless> whatever you like is what you should get
[00:28] <kfogel> (my description of how bzr-hookless-email works to Sylvain is a bit too shorthand; unfortunately savannah tracker doesn't allow comment editing either :-(  )
[00:28] <lifeless> neither does lp.
[00:29] <lifeless> wikis they are not
[00:56] <igc> morning
[02:10] <a7p> hi everyone - is there a way to generate a revisionnumber into a file? I want it to get printed out each time the program is started.
[02:10] <a7p> so the user can see which revision he is running.
[02:11] <bob2> bzr version-info
[02:11] <dOxxx_afk> http://bazaar-vcs.org/KeywordExpansion
[02:13] <a7p> dOxxx: exactly what I'm looking for, thx
[02:32] <phoenixz> I did a bzr tag --force.. ever since, every push and pull I get "conflicting tags: blah"... how can I fix this?
[02:32] <spiv> push --overwrite
[02:32] <spiv> Or pull --overwrite
[02:32] <spiv> Depending on which tags you want to keep and which you want to overwrite :)
[02:56] <jamesh> lifeless: the patch on the "disable pymalloc" bug does have a configure switch to enable it.  The issue about the tuple cache is certainly something that would be a useful extension, but the patch is useful on its own
[02:57] <lifeless> jamesh: cool. I'm chatting to gutworth about it
[03:00] <gutworth> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
[03:00] <gutworth> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[03:00] <gutworth> ?
[03:00] <gutworth> ah, launchpad is down
[03:01] <lifeless> yes :(
[03:01] <lifeless> we're doing a db schema change amongst other things
[03:01] <lifeless> and zope is blowing up
[03:01] <lifeless> I'm told we're rolling back and it will be back very soon
[03:02]  * gutworth is so glad he's not in charge of administering large websites
[03:03] <lifeless> somehow encodings.utf_8.codecs became None
[03:03] <lifeless> not during vm shutdown either
[03:03] <gutworth> that happens in our tests all the time, too
[03:03] <lifeless> does it? thats very interesting
[03:03] <lifeless> does anyone have any idea /how/ ?
[03:04] <gutworth> you should ask __ap__ when he's up
[03:04] <gutworth> I think he fixed it
[03:04] <a7p> mmm ... ~/.bazaar/rules is written, but $Date$ does not get replaced upon a commit - do I miss something concerning keywords?
[03:04] <lifeless>  shall
[03:04] <a7p> selftest ran fine.
[03:05] <gutworth> we're very proud of __ap__. This is his handywork http://python.org/dev/buildbot/stable/
[03:09] <gutworth> lifeless: http://bugs.python.org/issue6551
[03:10] <lifeless> thanks!
[03:15] <a7p> is there any way to check if the rules file is applied?
[03:16] <spiv> a7p: it should be if your working tree is in a new enough format, IIRC.
[03:17] <a7p> *sigh*
[03:17] <spiv> a7p: (2a, the default format in 2.0.0, is new enough)
[03:18] <lifeless> a7p: what bzr version do you have?
[03:18] <lifeless> a7p: what does 'bzr info' report for you?
[03:18] <spiv> a7p: I don't think there's a command to find out what filters are active or applied to a particular file, although maybe there should be.
[03:18] <a7p> pack-0.92 - I'm running 1.18
[03:19] <spiv> 'bzr upgrade --1.14' would work for you I think.
[03:19] <gutworth> yep you need a later version
[03:20] <spiv> (Although I'd recommend upgrading to bzr 2.0.0 and using the current format when you can, as it is faster and smaller.)
[03:20] <a7p> thx, - thanks I'll try that ... just have 1.18 installed since it's the default in macports
[03:26] <poolie> mwhudson: the bugs attached to lp:ubiquity seem to imply we need to think a bit more about the user model too
[03:27] <a7p> *sigh* - still does not work.
[03:28] <poolie> a7p: what specifically is not working?
[03:28] <poolie> you're not seeing the file being filtered?
[03:28] <poolie> there were several bugs in 1.18 with filters not been applied enough
[03:28] <poolie> sorry, but that's how it was
[03:28] <poolie> several are fixed in 2.0.x
[03:29] <a7p> poolie: i've just upgraded to 2.0.2
[03:29] <a7p> http://paste.ubuntu.com/333592/
[03:30] <a7p> rules is configured to [name *] keywords = on
[03:30] <poolie> % bzr plugins
[03:30] <a7p> to my understanding $Date$ should get the current date added upon commit
[03:31] <a7p> git, hg, keywords, launchpad, net_credential_store, svn, xmloutput
[03:31] <spiv> a7p: I think you can also do 'rm foo; bzr revert foo' to regenerate a file with the current filters.
[03:31] <poolie> yes it'd be good to see if that  works
[03:31] <a7p> ah, I should run the selftest with 2.0.2
[03:31] <poolie> selftest is quite an internally-facing test
[03:32] <poolie> it probably won't find anything related to bad installation
[03:32] <a7p> okay - theres' something messed up - was fine with 1.18
[03:32] <a7p> I'll remove the other plugins
[03:32] <spiv> selftest is mainly a tool for developers rather than users
[03:32] <poolie> james_w: i guess you're asleep?
[03:33] <james_w> hi poolie
[03:33] <james_w> guess again :-)
[03:33] <poolie> hi
[03:33] <poolie> blame canada? :)
[03:33] <poolie> anyhow
[03:33] <poolie> regarding the udd stuff
[03:33]  * a7p is confused - just removed most plugins from ~/.bazaar/plugins, but they still appear upon bzr plugins
[03:34] <poolie> james_w: i realize there is more to do than the two items i raised and the ones vincent added
[03:34] <a7p> ah, sry, my wrong
[03:34] <spiv> a7p: 'bzr plugins -v'
[03:34] <poolie> i should have made it more clear that i'm just trying to work out what specifically to do in the medium term
[03:34] <spiv> (that shows you where they seem to be installed)
[03:34] <poolie> to get from a longish set of stories to what we do this week and next week
[03:36] <james_w> poolie: yeah, I think I may have phrased my mail badly
[03:36] <poolie> it happens :)
[03:36] <a7p> ahhh ... *g*
[03:37] <james_w> I felt I was missing a step, I saw "here's a bunch of things we could work on," then "here's what we are going to work on," and didn't feel I knew how the two were joined
[03:37] <poolie> oh
[03:37] <james_w> I appreciate I wasn't at the sprint
[03:37] <a7p> $Date: (evaluation error) $  - it's a big step forward ;)
[03:37] <poolie> well, it was kind of a straw man for you to object to
[03:37] <poolie> if you were to file say 3 high priority bugs tagged udd we'd probably just do them
[03:38] <poolie> i don't know if you feel ready or able to do that
[03:38] <spiv> a7p: heh
[03:38] <poolie> but we do need to cross that somehow
[03:38] <james_w> poolie: I'm currently writing my second spec, which should distill out some of the other things that we would like
[03:38] <james_w> I think it would be good to see how that tallies with the list that you had, and see what changed at UDS
[03:39] <james_w> I'm concious of time passing, but the spec will be done tonight, and I'll fire off a mail to udd before bed
[03:39] <james_w> https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-lucid-distributed-development is one
[03:39] <poolie> that's ok
[03:39] <poolie> we have useful stuff to do
[03:39] <poolie> i'm writing a mail about this at the moment
[03:39] <james_w> see "Migration" for one set of things that I'm not entirely sure about
[03:39] <poolie> i just feel a bit like the bzr team is doing business as usual on bzr
[03:40] <james_w> yeah
[03:40] <poolie> when we should be reorienting a bit more towards udd
[03:40] <mwhudson> poolie: yeah
[03:48] <a7p> grrr, I'm giving up for now - got to write some code for money.
[03:48] <a7p> thanks for your help
[04:07] <a7p> puh, just switched from bzr+ssh to sftp to avoid having to upgrade the servers bzr.
[04:22] <james_w> poolie: do you think one mail with all the issues I want to discuss to udd is the best thing
[04:22] <james_w> or start a thread per-issue?
[04:22]  * Kamping_Kaiser shakes his head at bzr. 3 step upgrade is a bit silly
[04:24] <james_w> ooh, thanks mwhudson
[04:24] <mwhudson> james_w: i hope you're not in bristol
[04:25] <james_w> nope :-)
[04:25] <maxb> Is there any UI for "make this repository as small as possible", or must I manually rm the contents of obsolete_packs to achieve this?
[04:26] <mwhudson> james_w: good
[04:26] <mwhudson> james_w: and you're talking about the AttributeError thing?
[04:26] <james_w> yeah
[04:26] <james_w> though I like the cleanups anyway :-)
[04:26] <mwhudson> james_w: ah, np :)
[04:26] <bob2> maxb: it'll clear it out on the next pull or commit
[04:26] <mwhudson> i was impressed there wasn't more flakes
[04:26] <james_w> I use vim-pyflakes now
[04:27] <poolie> maxb: there's a bug for an option to pack to rm them
[04:27] <poolie> um
[04:27] <lifeless> maxb: not really, why?
[04:27] <poolie> james_w: whatever you think best
[04:28] <Peng> bob2: No, it'll clear out on the next pack.
[04:28] <Peng> (including auto-packs)
[04:28] <bob2> oh
[04:28] <maxb> It just feels like a UI wart
[04:28] <maxb> and rm-ing things inside .bzr is scary-ish
[04:29] <Peng> maxb: But...why would you want to?
[04:30] <bob2> Peng: it can take up significant amounts of space
[04:30] <lifeless> only if you run 'bzr pack' :)
[04:30] <bob2> (I thought the next operation that altered the repo data cleared obsolete_packs)
[04:30] <lifeless> generally it will be ~ 1% of the repo
[04:30] <lifeless> bob2: the next that /deletes/ from the repo
[04:30] <lifeless> packing involves deleting pack files
[04:34] <maxb> james_w: I would like to do something about the copy-pasted code from "bzr import" (bzrtools) to "bzr import-dsc" (bzr-builddeb). I see two options: A) Push the changes into bzrtools, and depend on a *really* new bzrtools, or B) Separate out the code into a .py file which is deliberately maintained to be as close as possible to the bzrtools version, but sever the actual dependency. What do you think?
[04:35] <james_w> maxb: I'd like to push the changes to bzrtools, so at least we could depend on it after a dwell period
[04:35] <james_w> and because it's the right thing to do :-)
[04:36] <james_w> I just haven't previously had time to separate out the changes and propose them back, sorry
[04:38] <maxb> james_w: Do you think option B might make sense in the interim, to make it easier to see what we still need to push back?
[04:38] <james_w> maxb: I would have no problem with doing that
[04:38] <maxb> I'll do a MP
[04:55] <dOxxx> good night all
[05:02] <mwhudson> james_w: have you seen https://code.edge.launchpad.net/~mwhudson/pyflakes/support-lazy-imports ?
[05:03] <james_w> I've heard about it
[05:03] <james_w> haven't ever felt the need to use it though
[05:03] <mwhudson> hm, i should merge trunk into it again it seems
[05:03] <mwhudson> instead i'm going to go and see spamalot though :)
[05:04] <james_w> enjoy
[05:14] <poolie> spiv, hi?
[05:14] <poolie> quick call?
[05:21] <spiv> poolie: sure
[06:17] <james_w> good night
[07:20] <vila> hi all
[07:20] <vila> james_w: wow, where are you ? Or should I say when ?
[07:21] <RAOF> There's currently no way to embed a branch within a branch, is there (ie: foo/ being a branch, and branching bar into foo/bar)?
[07:30] <Peng> RAOF: Well, bzr won't mind if you put "bar" in "foo", but they won't be linked together in any way like svn:external.
[08:39]  * igc dinner
[09:41] <bialix> hello
[09:45]  * fullermd waves at bialix.
[09:46]  * bialix warmly waves back
[09:46]  * bialix hopes he learn this "waves" phrases correctly
[09:48] <fullermd> Well, except for the 'warmly' part.  This time of year, I don't believe anything around you is warm   :p
[09:50] <bialix> even if you in the building?
[09:59] <vila> bialix: hey !
[09:59] <bialix> heya vila!!!
[09:59] <vila> fullermd: ha ha ! You didn't escape quickly enough today !
[09:59] <bialix> got my mail?
[10:00] <bialix> fullermd: vila: LOL
[10:00] <vila> which one ? :) I just replied to the selftest related one
[10:00] <bialix> about extra libs
[10:00] <vila> not yet
[10:00] <fullermd> Eep!  I mean, I'm not fullermd.  I just broke into his house, and am using his keyboard.  Yeah.  That's it.
[10:00] <bialix> wanna chat?
[10:01] <vila> I filed a bug about it this morning, let me find that back, but yes, a quick chat will be welcome, we can always update the bug with a summary of it
[10:01] <bialix> link to a bug please?
[10:02] <vila> fullermd: right, so get out of that house, quick ! You don't know what the guy will do if he finds you!!!!
[10:02] <vila> fullermd: he's known to be a freaking lunatic, member of the NRA and very active there !
[10:03] <vila> fullermd: and that's without mentioning his remotely controlled webcam, man, you're so already dead....
[10:04] <fullermd> Webcam?!  Ack!
[10:04]  * fullermd puts on pants real quick.
[10:04] <vila> bialix: bug #491797
[10:06] <bialix> vila: just this morning I've thought about standard location for extra libs
[10:07] <bialix> maybe bzr needs to use something like PythonXY/site-packages
[10:07] <vila> bialix: aaah, execellent, I was afraid some technical reason was escaping me making it impossible !
[10:07] <bialix> inside C:\Program Files\Bazaar
[10:07] <vila> yup, exactly my thoughts
[10:08] <vila> may be I expressed it too poorly in the bug report ?
[10:08] <bialix> there will be several difficulties IMO, but nothing really critical
[10:08] <vila> It's kind of related to that BZR_PLUGIN_PATH discussion we had some weeks ago
[10:08] <bialix> sorry, I don't remember
[10:08] <bialix> last 2 months I was overloaded on my job
[10:09] <vila> plugins can be searched into 'core', 'user', 'site', I seem to remember 'site' didn't make sense for you in the bzr.exe context
[10:14] <bialix> vila: perhaps
[10:14] <bialix> what is user there?
[10:15] <bialix> core means inside bzrlib/plugins/ ?
[10:15] <bialix> I don't remember what is site
[10:15] <bialix> silly me, forget everything :-(
[10:16] <vila> 'core' is bzrlib/plugins, 'user' is ~/.bazaar/plugins and 'site' is ... well site-dependent obviously but that's the place where plugins are installed when you want all users to be able to access them
[10:17] <vila> bialix: I think you forget it because you have no use for it yourself :)
[10:17] <bialix> yep, I'm happy with BZR_PLUGIN_PATH
[10:18] <bialix> for bzr.exe there is no use for core then
[10:18] <bialix> because bzrlib/plugins resides inside library.zip
[10:18] <bialix> I've explicilty extracted launchpad plugin from there
[10:19] <bialix> so now 'site' for bzr.exe is C:\PF\Bazaar\plugins
[10:19] <bialix> PF == Program Files (too much to type)
[10:19] <bialix> and user in APPDATA\bazaar\2.0\plugins
[10:19] <vila> hmm, great, so can you add c:\PF\Bazaar\lib to sys.path ?
[10:19] <bialix> never really likes this 2.0
[10:20] <bialix> it was not very good from jam side
[10:20] <vila> and similarly APPDATA\bazaar\2.0\lib ?
[10:20] <bialix> PF\Bazaar\lib should not be added
[10:20] <vila> why ?
[10:20] <bialix> because there all our standard c-extension lives
[10:21] <bialix> wait a sec
[10:21] <vila> so you mean it's already there and doesn't need to be added ?
[10:23] <bialix> vila: here is PF\Bazaar
[10:23] <bialix> http://pastebin.com/d6d2dc13c
[10:23] <vila> what's in lib ?
[10:24] <bialix> here is lib: http://pastebin.com/d2d2ef24d
[10:24] <bialix> scary
[10:24] <bialix> yes, lib is used for bundled libs for bzr.exe
[10:25] <bialix> there is lib\library.zip where all python-only libs stored
[10:25] <bialix> and too much of other c-extensions and dlls
[10:25] <vila> excellent ! That's exactly where we *could* add more libs, except it will be far cleaner to have another one in sys.path
[10:25] <bialix> I've explicitly move those libs from PF\Bazaar to PF\Bazaar\lib
[10:25] <bialix> vila: we should not use lib
[10:26] <bialix> it's for standard things
[10:26] <vila> Yeah, so what ?  :-) Kidding, that's why I say we should add one more
[10:27] <vila> So APPDATA\bazaar\2.0\lib sounds perfect no ?
[10:27] <vila> Ha no, that's 'user', where would be 'site' then ?
[10:28] <vila> bialix: anyway, we are indeed back to that discussion, the needed concepts are 'core', 'user' and 'site' otherwise we're running into cycles
[10:29] <vila> 'core' is protected (that's your arguments about putting nothing more there), so you have to provide 'site'
[10:29] <vila> That could be PF\Bazaar\site-lib
[10:30] <vila> or PF\Bazaar\site\{lib,plugins}
[10:30] <vila> bialix: still there ?
[10:31] <bialix> vila: bbiab
[10:32] <vila> bialix: ok, no worries
[10:56] <vila> fullermd: how can I use tmfs on freeBSD (i.e. in memory file system for /tmp) ?
[10:58] <vila> fullermd: looks like I need to add that to the kernel ?
[11:00] <vila> fullermd: I hardly believe it's not there by default >-/
[11:00] <fullermd> Or load it as a module, I guess.  I've never actually used it myself.
[11:00] <fullermd> I just use a md-backed regular FS for mine.
[11:01] <vila> that's what I want: /tmp in memory, whatever the mean !
[11:01] <vila> fullermd: how do you do that ?
[11:02] <fullermd> See the tmpmfs flag (and probably tmpsize) for rc.conf.
[11:02] <fullermd> (the default size is 20 megs, so that's probably a little tighter than you usually want in practice...
[11:07] <vila> fullermd: so in defaults/rc.conf the doc for tmpmfs says: Set to YES to always create an mfs /tmp, NO to never
[11:07] <vila> fullermd: and the default is AUTO.... color me confused :)
[11:07] <vila> what does that mean exactly ?
[11:08] <vila> df /tmp says 1M 512-blocks, so 512M, but that looks like real disk to me (as real as a VM can go that is...)
[11:14] <vila> fullermd: anwyay, using tmpmfs="YES", tmpsize="256m" and rebooting, I now have a /dev/md0
[11:15] <vila> fullermd: so last question: when doing df I now have:
[11:15] <vila> /dev/ad0s1e              1015260     5848   928192     1%    /tmp
[11:15] <vila> /dev/md0                  507356      300   466468     0%    /tmp
[11:16] <vila> fullermd: could that be a problem ? Is the later mounted on top of the former ? Do the former act as an extension area for the former (ha ha, dream !) ?
[11:16] <vila> OR should I just comment out the line in fstab for the former?
[11:32] <fullermd> Yeah...   having two things mounted on the same point is usually not what you really want  :p
[11:35] <vila> fullermd: ok, commented out for next reboot, df /tmp points to /dev/md0 for now, so I'm good :)
[12:23] <poseidm> can I use bazaar also as a backup system for directories with binary files?
[12:28] <spiv> poseidm: yes
[12:34] <poseidm> do you use it for backup? or some other tool?
[14:05] <bialix> vila: ping, I'm back
[14:06] <vila> bialix: wow, that was a big biffy ;-)
[14:06] <bialix> biffy?
[14:06] <vila> bialix: what is the last message you read in the conversation this morning ?
[14:06] <bialix> what means biffy?
[14:07] <vila> bialix: bbiab means be back in a biffy, biffy being a very short time AIUI
[14:07] <beuno> vila, spiffy?
[14:07] <beuno> (hi!)
[14:08] <vila> http://www.internetslang.com/BBIAB.asp says bit not biffy...
[14:08] <bialix> bbiab means be back in a bit?
[14:08] <vila> where did I get that then....
[14:08] <bialix> yes, vila, my in a bit was a bit longer than biffy
[14:09] <vila> anyway, glad you're back :)
[14:09] <vila> bialix: what is the last message you read in the conversation this morning ?
[14:09] <bialix> [2009-12-03 12:30:39] <vila> bialix: still there ?
[14:09] <bialix> :-D
[14:09] <bialix> I have log
[14:10] <vila> hehe, so, how about PF\Bazaar\site\{lib,plugins} ? That seems to clearly defines the 'site' needed directories no ?
[14:10] <bialix> vila: So APPDATA\bazaar\2.0\lib sounds perfect no ? -- no, it seems wrong
[14:10] <bialix> esp on Vista where it could be roaming
[14:10] <vila> yeah, yeah, keep reading :)
[14:10] <bialix> ok
[14:10] <bialix> so
[14:11] <bialix> that's why I said at start of our chat that good name is needed
[14:11] <bialix> maybe PF\Bazaar\python25-libs
[14:11] <bialix> maybe
[14:11] <bialix> any other variant is good, but having python version specified may help to avoid confusion
[14:11] <bialix> if people start installing package for 2.6
[14:12] <bialix> PF\Bazaar\lib -- is our core
[14:12] <bialix> PF\Bazaar\plugins is our site
[14:12] <bialix> I mean for bzr.exe
[14:12] <vila> so, if you want to take that into account, the blessed names are:
[14:13] <bialix> core is inside r/o blackbox, let me say that
 PF\Bazaar\lib -- is our core
 PF\Bazaar\plugins is our site
[14:13] <bialix> beuno: what is spiffy?
[14:13] <vila> meh, don't mix up core and site there, one is for libraries, the other for plugins, so both should be 'core'
[14:15] <bialix> if you insist that bzrlib/plugins/* is core then I can say that PF\Bazaar\lib\library.zip -> bzrlib/plugins/* is the core
[14:15] <vila> then you can have site\lib and site\plugins for 'site' and if needed lib\py25 lib\py26 but that would mean that bzr.exe exists for both 2.5 and 2.6, is that the case ?
[14:15] <bialix> and hi beuno
[14:15] <bialix> vila: no, bzr.exe bundled only one interpreter
[14:15] <vila> bialix: I don''t understand the meaning of -> here
[14:15] <beuno> bialix, http://www.urbandictionary.com/define.php?term=spiffy
[14:16] <bialix> beuno, ah thx, it was spiffy
[14:16] <vila> beuno: In fact I think I meant be back in a jiffy
[14:16] <bialix> pfffffffffffffffffffffff
[14:16] <beuno> vila, that's it! jiffy!  :)
[14:16] <beuno> bialix, http://www.urbandictionary.com/define.php?term=jiffy
[14:16] <beuno> :)
[14:16] <bialix> vila: I've used -> to indicate it's inside zip archive
[14:17] <vila> bialix: ha ! ok ! FUll agreement ! core is r/o blackbox-cant-be-modified
[14:18]  * bialix shakes vila's hand, cool
[14:18] <vila> but BZR_PLUGIN_PATH allows the user to put 'site'/'user' *before* 'core' if needed
[14:19]  * vila re-reading plugin.py
[14:20] <vila> bialix: can you look at plugin.py get_core_plugin_path() and get_site_plugin_path() too ?
[14:21] <vila> I think we are pretty close so let's make these last steps
[14:21] <bialix> vila: I'm not quite understand your remark about BZR_PLUGIN_PATH
[14:21] <bialix> vila: bb in 15 minutes
[14:22] <vila> bialix: forget it for a minute, just think that the default path is: ''user' 'core' 'site' and read the comment in get_standard_plugins_path()
[14:22] <bialix> ok, will do, after short lunch
[14:23] <vila> bialix: bon appetit !
[14:24] <fullermd> Hm, lunch.  That's sounding like a goodish idea...
[14:24] <rubbs> Morning
[14:37] <bialix> fullermd: lunch for whimps?
[14:38]  * bialix reading plugin.py
[14:49] <bialix> vila: ok
[14:50] <bialix> vila: get_core_plugin_path insist core on bzr.exe is PF\Bazaar\plugins
[14:50] <bialix> that's fine
[14:50] <vila> right
[14:50] <bialix> user is APPDATA\bazaar\2.0\plugins
[14:51] <bialix> no problem here
[14:51] <vila> right
[14:51] <bialix> site is still puzzling for me
[14:51] <vila> let's leave aside for a minute
[14:52] <bialix> ok
[14:52] <bialix> so where we now? again
[14:52] <vila> do you agree that bzr.exe can look at APPDATA\bazaar\2.0\lib for additional libraries ?
[14:52] <bialix> it can but I think it's bad idea
[14:52] <vila> why ?
[14:52] <bialix> because it can be roaming
[14:53] <vila> hmm, but in that case the plugins can be wrong too right ?
[14:53] <vila> So it's the user responsability to be coherent between the plugins he install and the bzr.exe he install on his various hosts, right ?
[14:54] <bialix> well
[14:54] <bialix> honestly to say
[14:54] <bialix> I'm hate APPDATA\bazaar\2.0 location
[14:55] <vila> ok, for the sake of the discussion, let's call it USER\plugins then :)
[14:55] <vila> Don't you feel better ?
[14:56] <vila> do you agree that bzr.exe can look into USER\lib for additional libraries ?
[14:57] <bialix> on my machine this is C:\Documents and Settings\myname\Application Data\bazaar\2.0\
[14:57] <bialix> it's so boring to cd to this directory even via decent file mamanger
[14:57] <bialix> so I'm keep all my plugins in C:\work\Bazaar\plugins and has specified BZR_PLUGIN_PATH
[14:58] <bialix> how's your proposal will lokk given in mind my habit of BZR_PLUGIN_PATH?
[14:58] <bialix> vila: ^
[14:58] <bialix> what
[14:59] <bialix> what's USER\lib
[14:59] <bialix> ?
 I'm hate APPDATA\bazaar\2.0 location
 ok, for the sake of the discussion, let's call it USER\plugins then :)
[14:59] <vila> USER == APPDATA\bazaar\2.0
[14:59] <bialix> why every user should have separate copy of third-party libs?
[14:59] <bialix> why not PF\Bazaar\extra ?
[15:00] <bialix> why not PF\Bazaar\extra-libs ?
[15:00] <vila> because bzr.exe don't have a concept for 'site' which is where additional plugins and libraries can be installed in order to be shared between several users and several versions of bzr.exe
[15:00] <vila> That's the whole point of the damn concept !
[15:00] <bialix> another problem with APPDATA -- this folder is usually hidden
[15:01] <bialix> so you can't get there on vanilla windows machine
[15:01] <vila> Can we focus on solutions to already identified problems before raising new ones ?
[15:01] <bialix> until you enable option to show hidden files in Explorer, or put the full path to address line
[15:01] <bialix> let's try to invent site for bzr.exe then
[15:02] <bialix> PF\Bazaar\site
[15:02] <bialix> ok?
 or PF\Bazaar\site\{lib,plugins}
[15:03] <bialix> that's fine, though PF\Bazaar\site\plugins is useless
[15:03] <vila> right, that was my last proposal this morning and that's what plugin.get_site_plugin_path() can return
[15:03] <bialix> there is PF\Bazaar\plugins tight here
[15:03] <bialix> s/tight/right/
[15:04] <bialix> if you wish -- why not? but it seems useless
[15:04] <vila> :-(
[15:04] <bialix> we started from the question: where we would like to put extra 3rd party libs
[15:05] <vila>  PF\Bazaar\plugins exists and is not empty ?
[15:05] <vila> what's in there ?
[15:05] <bialix> all plugins provided by installer
[15:06] <bialix> lp, netrc, bzrtools, qbzr, svn, upload, xmloutput
[15:06] <bialix> and explorer
[15:06] <vila> right, so that's core
[15:06] <bialix> yes
[15:06] <vila> and you said you want to keep that read-only, ok, so we can't put anything there, ok ?
[15:07] <bialix> vila: no I said this about PF\Bazaar\lib
[15:07] <bialix> precisely about PF\B\lib\library.zip
[15:07] <bialix> PF\B\plugins is user editable
[15:08] <vila> Can't you see that's precisely why we can't add more libraries ?
[15:08] <bialix> there is another std location on windows for all users if you wish site
[15:08] <bialix> C:\Documents and Settings\All users\...
[15:09] <bialix> there is also Application Data, etc
[15:09] <bialix> [17:08]	<vila>	Can't you see that's precisely why we can't add more libraries ?  <--- I don't understand this question
[15:10] <vila> We want to be able to add plugins that aren't known by bzr.exe and these plugins requires some libraries
[15:10] <vila> they should go into XXX\plugins and the libraries into XXX\lib
[15:11] <vila> Since you don't want to add libraries into PF\B\lib, we can't add plugins into PF\B\plugins
[15:11] <bialix> your term "plugins that aren't known" makes me uncomfortable
[15:11] <bialix> does that implied bzr.exe knows about some plugins? it's not true
 all plugins provided by installer
 lp, netrc, bzrtools, qbzr, svn, upload, xmloutput
[15:12] <bialix> this is known by installer
[15:12] <vila> are you making a disctinction between bzr.exe and the installer ??
[15:12] <bialix> yes
[15:12] <vila> I didn't
[15:12] <bialix> it's up to you
[15:12] <vila> s/bzr.exe/installre
[15:13] <bialix> ok
[15:13] <bialix> if you wish to install plugins to "plugins" and libraries to "lib" (or "libs"?) that's makes sense
[15:14] <bialix> where I should install libraries if I'm using BZR_PLUGIN_PATH
[15:14] <bialix> ?
[15:14] <vila> I want names to be coherent between 'core', 'site' and 'user' so lib and plugins for each of them, do you agree ?
[15:14] <bialix> vila: I don't understand why you want tie them together
[15:15] <vila> For consistency, because I dislike:
 precisely about PF\B\lib\library.zip
 PF\B\plugins is user editable
[15:16] <vila> I want to be able to install a plugin and its libs that will override the one provided by the installer
[15:16] <bialix> you're late for 3 years
[15:16] <vila> ok, too bad, bye
[15:16] <bialix> we may talk about where to put extra libs
[15:16] <bialix> regardless of plugins
[15:17] <bialix> this is 2 loosely related things
[15:17] <bialix> install things in PF\B\lib may be wrong idea because there is already too much things
[15:18] <bialix> you need clean location to ensure user won't delete some important file
[15:18] <bialix> I guess so
[15:18] <bialix> ok, too bad, bye -- sorry for this
[15:23] <bialix> vila: I'm really sorry
[15:31] <kfogel> jelmer: no sign of bzr 2.0.2 at http://packages.debian.org/lenny-backports/bzr yet... Any ideas?
[15:32] <jelmer> kfogel: Not sure why it's not listed there, but the archive appears to have it:
[15:32] <jelmer> http://www.backports.org/debian/pool/main/b/bzr/
[15:34] <kfogel> jelmer: thank you.
[15:35] <kfogel> jelmer: you might know off the top of your head: savannah.gnu.org is currently running 1.16.1, and has been having some severe loggerhead crashing problems lately.  Is loggerhead with 2.0.2 stable?  That will be an additional motivation to upgrade, if so.
[15:36] <jelmer> kfogel: I wouldn't know, sorry
[15:36] <kfogel> jelmer: np
[15:42] <kfogel> Does anyone here know if loggerhead is stable with Bazaar 2.0.2?  Latest release is "loggerhead-1.17" from August 2009... Does one have to run trunk code to work with bzrlib 2.0.2?
[15:59] <P4C0> Hello, is it possible to revert the changes done in a branch? or should I just rm the branch and create it again?
[15:59] <Pilky> P4C0: bzr revert
[15:59] <rubbs> P4C0: bzr revert
[16:00] <rubbs> Pilky: beat me
[16:00] <Pilky> rubbs: w00t, what do I win?
[16:00] <P4C0> Pilky, rubbs thanks, and if I don't want a branch anymore, can I just rm it?
[16:01] <Pilky> P4C0: yep
[16:01] <P4C0> Pilky: thanks
[16:01] <rubbs> Pilky: brownie points. you get 5. If you get 1000, I'll send you some brownies ;)
[16:02] <Pilky> P4CO: not sure what happens to any revisions just in that branch that are stored in the repo, you'd have to ask one of the bzr devs
[16:02] <P4C0> ok, thanks
[16:02] <rubbs> Pilky: P4C0: The revisions stay there
[16:03] <rubbs> Pilky: P4C0: They just don't have any children
[16:03] <rubbs> at least thats what it looks like when I did it.
[16:03] <rubbs> I could be wrong
[16:03] <Pilky> rubbs: yeah that's what I thought, I was just wondering if bzr did anything to clean them up
[16:11] <rubbs> Pilky: I'm not 100% sure, I'm gonna do a quick test and check.
[16:12] <Pilky> rubbs: if any command was to do it I'd have a guess at pack
[16:12] <rubbs> Pilky: that would be my guess as well
[16:13] <fullermd> It doesn't.
[16:14] <fullermd> gc is discussed from time to time.  It hadn't topped anybody's todo yet.
[16:17] <rubbs> Ah, that's what I thought, I just couldn't remember for sure
[16:22] <hazmat> so i'm trying to push a branch upstream back to launchpad, but i get an odd error bzr: ERROR: RemoteRepository is not compatible with CHKInventoryRepository different rich-root support.. any ideas on how to resolve?
[16:30] <fullermd> hazmat: That means your local repo is in the 2a format, while the LP is in an earlier format without RR support.
[16:30] <fullermd> Basically, the options boil down to 'upgrade the LP branch' or 'redo local changes in a poor-root branch'.  RR revs can't be moved into a non-RR repo.
[16:34] <hazmat> fullermd,  thanks for the info.. upgrading the lp branch isn't an option for me.. re redoing the local changes.. to get my local branch, i branched a co of a launchpad repo in a shared repo dir, what would i have to do differently to get the same repo format as launchpad.. also is there a way i can downgrade my existing repo to something compatible?
[16:35] <fullermd> Well, to answer the last first, no; the poor-root -> rich-root transition is a trap door.  We've supported both back to 1.0 (and even further, sorta), and it was just time (or well past time) to pull the default switch.
[16:36] <fullermd> When you branch into an existing repo, it will use that existing format.  So that's how you ended up in the situation; you had an existing 2a repo, so the 'branch' process upgraded the data as it came in.
[16:36] <fullermd> So to get the same, you'd either (a) branch to a standalone location with no existing repo (which would preserve the source format), or (b) lookup the format manually first and make sure your repo can talk back to it.
[17:01] <P4C0> is there a command to remove all the local files that are not under the repo control?
[17:03] <Pilky> P4C0: bzr clean-tree I think
[17:03] <Pilky> or something along those lines
[17:04] <jelmer> bzr clean-tree- --unknown
[17:04] <P4C0> thanks
[17:04] <jelmer> --ignored for ignored files
[17:07] <bialix> hello jam
[17:09] <P4C0> hmm I just compile the code on my local branch but bzr clean-tree says there's nothing to clean
[17:09] <Pilky> P4C0: are the compiled files ignored?
[17:09] <P4C0> --ingored did it ;)
[17:10] <P4C0> Pilky: seems so... bzr status doesn't say anything
[17:11] <Pilky> yeah, by default it doesn't list the ignored files
[17:31] <kfogel> Does anyone here know if loggerhead is stable with Bazaar 2.0.2?  Latest release is "loggerhead-1.17" from August 2009... Does one have to run trunk code to work with bzrlib 2.0.2?
[17:34] <kfogel> rockstar: ^^
[17:34] <rockstar> kfogel, I'm pretty sure it is.  I think our loggerhead instance might be running on 2.0.1 or 2.0.2 now.
[17:35] <rockstar> kfogel, I can't imagine that part of the API has changed much.
[17:35] <kfogel> rockstar: thanks.  The question is, are we running the last release of loggerhead, or trunk code?
[17:35] <rockstar> kfogel, we're running a variant of trunk, but, like I said, I can't imagine there were that many changes.
[17:35] <beuno> kfogel, latest release of LH, AFAIK
[17:36] <beuno> and the latest LH works fine with the latest bzr
[17:37] <kfogel> beuno, rockstar: thanks
[17:40] <beuno> kfogel, I'd be happy to help out getting LH working in the emacs world
[17:41] <beuno> (or adapt some things if needed, within reason)
[17:43] <kfogel> beuno: they don't make it easy for knowledgeable volunteers to assist, but I keep offering our help; maybe they'll take us up on it.
[18:19] <quicksilver> it seems that sometimes cd into a very old branch and bzr pull --overwrite is slow
[18:19] <quicksilver> slower than rm -rf branch; pull fresh branch
[18:19] <quicksilver> that seems counterintuitive?
[18:25] <mwhudson> quicksilver: is there a format conversion going on?
[18:25] <quicksilver> yes, I think so.
[18:26] <quicksilver> actually pulling a fresh branch is slower than I remembered.
[18:26] <quicksilver> 7 minutes so far and counting.
[20:21] <lifeless> james_w: hi
[20:22] <james_w> morning lifeless
[20:22] <lifeless> james_w: can you explain where the concern about 'good bug reports' comes from, I think it may be impeding communication/'getting things done'.
[20:22] <lifeless> james_w: also, how are you :)
[20:22] <james_w> good thanks, how are you?
[20:22] <lifeless> Good - back down to 91kg yesterday morning
[20:23] <lifeless> the 90kg barrier is my nemesis
[20:23] <james_w> you mean the udd thread "Bugs for daily build packages"
[20:23] <james_w> ?
[20:24] <lifeless> Not precisely ;). its turned up a few times; you mentioned in a bug I filed on -builder, I think, and then again in the thread about what stuff bzr folk are doing
[20:24] <lifeless> I'd like to understand more about it, about what you mean, and so forth
[20:26] <james_w> oh
[20:26] <james_w> got it now
[20:29] <james_w> so, my worry is that some things are too imprecise currently
[20:29] <james_w> "<thing> could be better" type reports
[20:29] <james_w> I could report that, and then use the bug report to discuss ways to tackle it
[20:29] <james_w> but that probably isn't the best forum
[20:30] <james_w> there's also a question of when the bug can be considered fixed
[20:30] <james_w> with something like that, what does "better" mean
[20:37] <james_w> I'm trying to find a bug I'm sure I remember where you were discussing whether having a bug "bzr <operation> is too slow" open was worthwhile, as my recollection is that you touched on similar issues there
[20:37] <lifeless> yes
[20:37] <lifeless> and those are good, valid concerns
[20:38] <lifeless> OTOH bug reports are essentially just conversations; I agree that the list is ~ the best the forum to be discussing 'what should be done'
[20:38] <lifeless> and I don't want you to tear through the specs and turn everything into bugs - I don't think thats efficient either.
[20:39] <jam> morning lifeless
[20:39] <jam> hi james_w
[20:39] <lifeless> but I'd like to encourage you to file a bug for anything that is adding friction, or causing issues
[20:39] <jam> what are you still doing up?
[20:39] <lifeless> hi jam
[20:39] <james_w> hi jam
[20:40] <lifeless> even if its a big amorphous, its still data to the bzr devs
[20:40] <jam> james_w: so one of the good things about filing separate bugs is that it allows you to split the discussion by thread, and have a way to make progress on part of it without all of it
[20:40] <james_w> lifeless: I will file bugs in future where appropriate
[20:40] <lifeless> in the performance case we knew it all :P
[20:40] <jam> it also gives a checklist of "these are things to work on"
[20:41] <jam> which can be done in mailing list threads, but it is a lot harder to get a summary and overview
[20:42] <rubbs> so in this case what is the difference between a bug report and a blueprint? (sorry to just jump in here)
[20:44] <james_w> rubbs: you could probably use either. Historically bzr hasn't used blueprints
[20:45] <rubbs> james_w: ok, cool. I was just curious
[20:46] <jam> rubbs: blueprints are very underdeveloped as a launchpad feature
[20:46] <jam> they are meant to capture the concept of "feature development" separate from a "bugfix"
[20:48] <yojimbo-san> I have a beginners question -- I've used lots of centralised VCS (e.g. svn) but not a DVCS; As a sysadmin, I have /etc under VCS on multiple servers, but I'd like to have one central place where I can (check out/see) all the machines configs with a single tool, such as Trac. I'm probably using the wrong terminology, but can I "join" multiple repositories together into one other one? (it can be read-only if that's easier) ... so from my Trac machine, I see one
[20:48] <rubbs> jam: that makes sense thank you
[20:52] <rubbs> yojimbo-san: I think I understand your question but let me make sure: You wish to be able to keep multiple different configurations together in one central location so you can view them all. Is that correct?
[20:53] <yojimbo-san> yes; just for viewing purposes. Each machine should be otherwise stand-alone (local repository) and independant
[20:53] <yojimbo-san> But I'd like to see the version history for each file from the central place
[20:54] <rubbs> I'm not an expert here, but maybe this would help. Instead of trying to pull from many to one, you could push from one to many. Here's what I mean:
[20:55] <NfNitLoop> it's basically a centralized configuration, with a different repo for each machine.
[20:55] <NfNitLoop> all with copies hosted on the 'trac' server.
[20:55] <NfNitLoop> they can have a standalone branch/local-copy for faster/disconnected operation.
[20:55] <rubbs> you could make a central location (shared repository) that has a main file. Then branch off a new branch for each configuration and then push them to the servers.
[20:57] <yojimbo-san> So, if the central location sees a file as "/machine1/etc/hosts", how would machine1 see this as "/etc/hosts"? (Or should I cheat by symlinking /etc? :-) )
[20:57] <yojimbo-san> Or is that not a relevant question with bzr?
[20:58] <NfNitLoop> with bzr...
[20:58] <NfNitLoop> you can put your branches anywhere.
[20:58] <NfNitLoop> so on each host, I woulddo:
[20:58] <NfNitLoop> cd /etc; bzr init .; bzr add files you want to track; bzr commit -m "Initial Checkin"
[20:59] <NfNitLoop> then you can either do a 'bzr push' up to your server...
[20:59] <NfNitLoop> or from your server do a "bzr pull"
[20:59] <rubbs> so for example, say you have server1 and server2.
[20:59] <NfNitLoop> actually, the advantage of doing a bzr pull from the server is that it'll update your working copy.
[20:59] <NfNitLoop> so I'd recommend that.
[21:00] <rubbs> you can make a change on server1 and then push it to server2
[21:01] <rubbs> A better example might be that you have a central repository on server1 at /var/configfiles
[21:01] <rubbs> then you can have branches on server2 and server3 at /etc
[21:02] <rubbs> Then if you want to update server2 from server1's repo, you can do this from server2: cd /etc; bzr pull sftp://server1/var/configfiles;
[21:02] <yojimbo-san> Ok, that gives me something to try ...
[21:03] <rubbs> DVCS took me a while. The best way to learn is to just fool around with it until you get it.
[21:03] <yojimbo-san> :-)
[21:03] <rubbs> that and keep asking questions
[21:03] <rubbs> ;)
[21:03] <yojimbo-san> Are things like file owners/permissions tracked well?
[21:04] <bob2> no
[21:04] <rubbs> no
[21:04] <yojimbo-san> so that makes pulling files dangerous ...
[21:04] <bob2> use etckeeper
[21:04]  * rubbs slaps head
[21:04] <rubbs> I should have remembered that
[21:05] <rubbs> etckeeper was designed for pretty much exactly what you are asking about
[21:05] <yojimbo-san> bob2: does etckeeper track permissions? I thought it was just a handy wrapper around having VCS in the first place ...
[21:05] <bob2> yes, no
[21:05] <yojimbo-san> Mmm, I must go do some more reading then :-)
[21:06] <yojimbo-san> So if I use etckeeper to create local bzr repositories, I then want some way of hooking them all back to my central Trac ...
[21:07] <rubbs> there, I can not help, but I'm guessing it's possible
[21:08] <yojimbo-san> probably, especially if I create the branch for each machine's etckeeper repository on the central place, push it out (empty) to the target machine, then initialise etckeeper to use it ... then push it back centrally ...
[21:09] <yojimbo-san> Sounds like a bit of a juggling act, but I'll go figure something out. Thanks for your time, rubbs, bob2 NfNitLoop.
[21:09] <rubbs> np
[21:11] <NfNitLoop> yojimbo-san: It's only about 1 command more than working with centralized svn.
[21:12] <NfNitLoop> if you're going to store them all on a central server anyway, you could get away with using svn.
[21:12] <NfNitLoop> bzr just buys you the nice features of DSCM (and bzr itself)
[21:24] <yojimbo-san> NfNitLoop: Well, as a non-coder, finding a decent opportunity to learn about bzr in a way that's different from simple svn isn't always easy :-) So having a target problem motivates me to actually learn stuff ...
[21:35] <lifeless> james_w: actually, we used blueprints for a bit; they didn't fit all that well
[21:51]  * igc breakfast
[22:10] <poolie> james_w: I agree with you that "X could be better" or "something should be done" bugs are poor
[22:10] <poolie> also that blueprints don't help much in our system
[22:11] <poolie> perhaps they match UDS well
[22:12] <lifeless> poolie: I prefer 'x could be better' to silence though, which is my point
[22:12] <lifeless> one can iterate to improve the resolution
[23:19] <mtaylor> lifeless: I just got another complaint from someone about error messages when branch formats don't match
[23:32] <lifeless> mtaylor: yes
[23:33] <mtaylor> lifeless: just thought I'd continue to be annoying about it :)
[23:34] <lifeless> mtaylor: if they upgrade... :P
[23:35] <mtaylor> lifeless: if they upgrade the error messages get better? :)
[23:35] <mtaylor> lifeless: that's exciting!
[23:39] <mvo> bazaar.launchpad.net give me connection refused errors, is that just me or is this a general problem?
[23:39] <mvo> (on port 22)
[23:39] <spiv> mvo: I think Launchpad is down for a code update atm?
[23:40] <spiv> That's what /topic in #launchpad claims, at leastd.
[23:41] <lifeless> mtaylor: if they upgrade, they have 2a and don't have trouble :P
[23:42] <mtaylor> lifeless: :P
[23:42] <mtaylor> lifeless: do you want me to actually file another bug about it though? or can I assume everyone is well aware...
[23:42] <lifeless> mtaylor: its in the 'wishlist' pile at the moment; its something we'd take a patch to make better
[23:42] <lifeless> (and there are bugs)
[23:42] <lifeless> but its not something we're devoting time to
[23:43] <mtaylor> lifeless: k. as long as it's in a pile somewhere. just didn't want to assume it was and be wrong
[23:43] <lifeless> the pile grows... :P
[23:43] <lifeless> mysql could file a ticket on it, if its plaguing you guys
[23:45] <mtaylor> lifeless: oh, I don't know if it's plaguing mysql
[23:52] <mvo> spiv: aha, ok, thanks! its time for bed for me anyway :)
[23:52]  * mvo waves
[23:55] <blueyed> I'm getting content conflicts, and I don't know how to resolve them: http://pastebin.com/m726a3dee
[23:55] <blueyed> (answers.lp.net is down)