[03:05] <Ubugtu> New bug: #42049 in xserver-xorg-video-i810 (main) "no direct rendering on dapper with i810 chipset (855GM)" [Medium,Needs info]  https://launchpad.net/bugs/42049
[03:00] <Ubugtu> New bug: #55948 in xserver-xorg-input-synaptics (main) "Scrolling doesn't work" [Undecided,Unconfirmed]  https://launchpad.net/bugs/55948
[03:21] <Ubugtu> New bug: #44924 in xorg-server (main) "X chooses vesa driver for an ATI Radeon X300" [Medium,Needs info]  https://launchpad.net/bugs/44924
[04:05] <Ubugtu> New bug: #38181 in xserver-xorg-video-ati (main) "Screensaver freezes on Dapper (ATI Radeon 8500 LE)" [High,Needs info]  https://launchpad.net/bugs/38181
[04:15] <Ubugtu> New bug: #56692 in xorg-server "ATI radeon: poor 3D performance" [Unknown,Confirmed]  https://launchpad.net/bugs/56692
[04:20] <Ubugtu> New bug: #43052 in xserver-xorg-video-i810 (main) "OpenGL viewport cut-off with 915gm graphics (dup-of: 23816)" [Medium,Confirmed]  https://launchpad.net/bugs/43052


[07:41] <rvba> bigjools: meanwhile, would you have time for a review (the diff looks big because there is a migration in it but the changes are pretty mechanical): https://code.launchpad.net/~rvb/maas/improve-broken-state/+merge/228132 ?
[07:43] <bigjools> rvba: I saw it don't worry, just clearing my inbox and then I'll get to it
[07:44] <rvba> bigjools: cool, thank you
[09:32] <allenap> Does anyone have a moment for a review? https://code.launchpad.net/~allenap/maas/rpc-call-get-preseed-data/+merge/228179
[09:33] <rvba> allenap: sure, I'll take it
[10:02] <rvba> allenap: at the bottom of the diff, why are you changing metadata_url to be of type `urlparse.ParseResult`?  Doesn't that parameter come from `absolute_reverse` which returns a string?
[10:05] <allenap> rvba: It actually gets passed via RPC as a tuple; see the ParsedURL type. I had previously stubbed it out using a string instead of a urlparse.ParseResult.
[10:05] <allenap> Which was a mistake.
[10:10] <rvba> allenap: oh, I see; the conversion is actually done in src/maasserver/clusterrpc/osystems.py:get_preseed_data;  that's the part I was missing.
[11:50] <bigjools> allenap: can you help me set up python's logger in pserv please?  There's currently zero feedback from the downloader service which is a little jarring :)
[11:52] <allenap> bigjools: Quick and dirty is to call logging.basicConfig(level=logging.DEBUG) in p.plugin…makeService().
[11:53] <bigjools> allenap: yesterday you said the loggingobserver needs setting up
[11:54] <bigjools> I detest logging in twisted
[11:54] <allenap> bigjools: That’s to get Twisted’s logs to go via the stdlib’s logging module.
[11:54] <allenap> So you can configure both in there.
[11:54] <allenap> bigjools: Fwiw, so do most people who use Twisted.
[11:55] <allenap> Where “configure both in there” means you can select levels and whatnot using the familiar stdlib’s logging stuff.
[11:55] <allenap> For Twisted logs.
[12:02] <bigjools> allenap: I am slightly confused by it all.  The log there now is direct from twisted, right?  If Python's log is configured will it just pick it up and show it?
[12:04] <allenap> bigjools: They’re separate at the mo. If you call twisted.python.log.err or .msg it’ll print something to can’t remember where (that’s configured in the plugin). If you use the stdlib’s logging module then it must be configured to show your messages; by default the level is set to WARN.
[12:05] <allenap> bigjools: PythonLoggingObserver can be used to bridge the Twisted logs over to logging, but that’s not in there yet.
[12:05] <allenap> not in there = not being used yet
[12:06] <bigjools> allenap: yeah I think the pserv service is started with --logfile=/dev/null
[12:06] <bigjools> stdout is redirected instead
[12:09] <allenap> bigjools: p.services.LogService gets all Twisted logs to go to the filename specified, which is defined in pserv.yaml iirc.
[12:10] <bigjools> yeah
[12:10] <bigjools> so is that going to pick up python's logging?
[12:10] <bigjools> Guess I'll try it out
[12:19] <allenap> bigjools: Nope… but you could add a call to logging.basicConfig into LogService.startService.
[12:19] <bigjools> allenap: that's what I mean, if it's configured, where will it go?
[12:20] <allenap> bigjools: basicConfig send the logs to stdout or stderr iirc.
[12:21] <bigjools> allenap: yeah I think so.  might interleave with twisted...
[12:21] <allenap> bigjools: The —logfile=… argument to twistd only affects Twisted’s logs I think. It doesn’t redirect stdio or configure the logging module.
[12:21] <allenap> bigjools: As long as you can see the logs for development that’s a start.
[12:22] <bigjools> I think we added the loggingservice to make the log location sane
[12:22] <bigjools> I am past development, thinking of production/QA now
[12:29] <allenap> bigjools: I would think about changing LogService to create a new PythonLoggingObserver to bridge Twisted logs over, and to configure the logging module using the log file defined in pserv.yaml.
[12:30] <allenap> The latter can be done in p.plugin…makeService().
[12:30] <bigjools> allenap: yeah, sounds reasonable
[12:30] <allenap> bigjools: The current functionality of LogService can be removed.
[12:30] <bigjools> right
[13:10] <rvba> allenap: I'd like to create a RegionRPCFixture similar to the CluserRPCFixture.  I'm thinking about doing something like: http://paste.ubuntu.com/7855652/ but it requires Region (from maasserver) to be import from provisioningserver which is obviously wrong… Any idea what I can do instead?
[13:11] <allenap> rvba: Yeah :) Import Region from p.rpc.region instead; that’s where it’s defined.
[13:12] <allenap> rvba: Btw, self.patch() doesn’t work on Fixture.
[13:12] <rvba> allenap: oh, right, I'll MonkeyPatcher then
[13:12] <rvba> allenap: thanks!
[13:13] <rvba> I'll use* MonkeyPatcher
[13:13] <allenap> rvba: And I’m wrong about Region().
[13:13] <rvba> allenap: yeah, that's what I just found out
[13:14] <allenap> rvba: I think you’ll have to make it easy to create stubs.
[13:16] <rvba> allenap: okay, I'll look into it… but I'd like a fixture that wires things up magically (i.e. a fixture that removes all the AMP transport and calls the 'responder' directly).
[13:16] <bigjools> easy karma for someone: https://code.launchpad.net/~julian-edwards/maas/touch-maasmeta/+merge/228301
[13:17] <bigjools> rvba, allenap: we really need a full end-to-end fixture...
[13:17] <allenap> rvba: That’s not going to be easy at all; you’ll need to get Django configured and all that jazz.
[13:19] <allenap> bigjools: I don’t think we do. I’ve cheated with ClusterRPCFixture and I’m having second thoughts. We should develop the region and cluster against each other’s RPC schema. We ought to get into the habit of writing QA tests for the whole-system side of things.
[13:20] <bigjools> allenap: but I want integration tests that talk each way
[13:20] <allenap> bigjools: You may think you want that ;)
[13:21]  * bigjools dodges allenap's meta-argument :)
[13:23] <bigjools> can someone review my simple branch please!
[13:30] <rvba> bigjools: looking at your branch now
[13:31] <bigjools> thank you rvba!
[13:42] <jseutter> bigjools: I have a workaround for that grub issue where maas couldn't install on some nodes from earlier this week.  I dropped several drives from the raid array (down to 1.1TB array size) and the maas install worked.  What is weird is that the ubuntu cd installer works with all drives in the array.
[13:49] <bigjools> jseutter: I've seen the installer fail for me when I've got raid partitions present (outside of maas)
[13:50] <jseutter> bigjools: ok, good to know :)
[16:05] <bigjools> 600-line upper decker for your Friday afternoon enjoyment. https://code.launchpad.net/~julian-edwards/maas/replace-celery-download-job-with-pserv/+merge/228168
[16:05] <bigjools> no takers?  Beuller? :)
[16:10] <bigjools> allenap: the logging is doing my head in, let's talk about it next week
[16:11] <allenap> bigjools: Yeah, let’s :)
[16:11] <allenap> bigjools: I haven’t looked at it in a long long time and it does need some attention.
[16:11] <bigjools> allenap: if we send to stdout it makes things somewhat awkward
[16:11] <bigjools> we have our own custom logging service
[16:11] <bigjools> that takes a filename
[16:11] <bigjools> not sure we need a filename, but at the same time we do need to write a log to the right place


[09:15] <ikikiki> JOIN
[12:18] <sunil_> sunilsivan
[12:19] <sunil_> data card connecting problem
[13:45] <Sreekumar> Hi
[13:46] <Sreekumar> How can I install HP Scanner N9120?
[13:46] <svij> Sreekumar: hey! If you want support, please join #ubuntu, there might be more peopl………………
[13:46] <svij> however.
[13:47] <Sreekumar> Anybody can help me?
[13:47] <svij> Sreekumar: hey! If you want support, please join #ubuntu, there might be more people to help you and that's the best channel
[13:47] <Sreekumar> ok thanks


[03:18] -queuebot:#ubuntu-release- New binary: python-jenkinsapi [amd64] (focal-proposed/universe) [0.3.11-1ubuntu1] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: drmaa [amd64] (focal-proposed/universe) [0.7.9-1] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: swig [i386] (focal-proposed/universe) [4.0.1-2] (i386-whitelist)
[05:20] -queuebot:#ubuntu-release- New binary: swig [ppc64el] (focal-proposed/universe) [4.0.1-2] (i386-whitelist)
[05:21] -queuebot:#ubuntu-release- New binary: swig [amd64] (focal-proposed/universe) [4.0.1-2] (i386-whitelist)
[05:22] -queuebot:#ubuntu-release- New binary: swig [arm64] (focal-proposed/universe) [4.0.1-2] (i386-whitelist)
[05:22] -queuebot:#ubuntu-release- New binary: swig [s390x] (focal-proposed/universe) [4.0.1-2] (i386-whitelist)
[05:22] -queuebot:#ubuntu-release- New binary: swig [armhf] (focal-proposed/universe) [4.0.1-2] (i386-whitelist)
[05:25] -queuebot:#ubuntu-release- New binary: nipy [amd64] (focal-proposed/universe) [0.4.2-3] (no packageset)
[05:25] -queuebot:#ubuntu-release- New binary: nipy [s390x] (focal-proposed/universe) [0.4.2-3] (no packageset)
[05:25] -queuebot:#ubuntu-release- New binary: nipy [ppc64el] (focal-proposed/universe) [0.4.2-3] (no packageset)
[05:36] -queuebot:#ubuntu-release- Unapproved: alsa-lib (bionic-proposed/main) [1.1.3-5ubuntu0.3 => 1.1.3-5ubuntu0.4] (core)
[05:37] -queuebot:#ubuntu-release- Unapproved: alsa-lib (eoan-proposed/main) [1.1.9-0ubuntu1.1 => 1.1.9-0ubuntu1.2] (core)
[05:40] -queuebot:#ubuntu-release- New binary: nipy [armhf] (focal-proposed/universe) [0.4.2-3] (no packageset)
[05:41] -queuebot:#ubuntu-release- New binary: nipy [arm64] (focal-proposed/universe) [0.4.2-3] (no packageset)
[08:55] -queuebot:#ubuntu-release- New: accepted drmaa [amd64] (focal-proposed) [0.7.9-1]
[08:55] -queuebot:#ubuntu-release- New: accepted nipy [arm64] (focal-proposed) [0.4.2-3]
[08:55] -queuebot:#ubuntu-release- New: accepted nipy [ppc64el] (focal-proposed) [0.4.2-3]
[08:55] -queuebot:#ubuntu-release- New: accepted php-guzzlehttp-promises [amd64] (focal-proposed) [1.3.1-2ubuntu1]
[08:55] -queuebot:#ubuntu-release- New: accepted swig [amd64] (focal-proposed) [4.0.1-2]
[08:55] -queuebot:#ubuntu-release- New: accepted swig [armhf] (focal-proposed) [4.0.1-2]
[08:55] -queuebot:#ubuntu-release- New: accepted swig [ppc64el] (focal-proposed) [4.0.1-2]
[08:55] -queuebot:#ubuntu-release- New: accepted nipy [amd64] (focal-proposed) [0.4.2-3]
[08:55] -queuebot:#ubuntu-release- New: accepted nipy [s390x] (focal-proposed) [0.4.2-3]
[08:55] -queuebot:#ubuntu-release- New: accepted swig [arm64] (focal-proposed) [4.0.1-2]
[08:55] -queuebot:#ubuntu-release- New: accepted swig [s390x] (focal-proposed) [4.0.1-2]
[08:55] -queuebot:#ubuntu-release- New: accepted nipy [armhf] (focal-proposed) [0.4.2-3]
[08:55] -queuebot:#ubuntu-release- New: accepted swig [i386] (focal-proposed) [4.0.1-2]
[08:55] -queuebot:#ubuntu-release- New: accepted python-jenkinsapi [amd64] (focal-proposed) [0.3.11-1ubuntu1]
[10:07] <xnox> sil2100:  please RM source-highlight 3.1.9-1build1 from focal-proposed, it ftbfs in both debian & ubuntu, and the 3.1.8 that we have in focal-release is better. Then i will do no change rebuild of 3.1.8 and it will help with icu transition.
[10:07] <xnox> reason "ftbfs"
[10:10] <sil2100> One moment o/
[10:14] <sil2100> xnox: ok, on it now
[10:16] <sil2100> xnox: done
[11:43] <handsome_feng> Hi, Could someone help to deal with the removal: #1863109? Thanks!
[11:43] <handsome_feng> LP: #1863109
[12:08] <Kamilion> teward: on contemplating the nginx ipv6 issue in #1743592 I think I came up with useful defaults for all. Please have a look before committing to reverting "tomorrow". Thanks!
[12:11] -queuebot:#ubuntu-release- New binary: octavia [amd64] (focal-proposed/universe) [6.0.0~b2~git2020020614.005cd1e6-0ubuntu2] (no packageset)
[12:29] <mfo> sil2100, hi Lukasz!  If you have a chance, could you please review mod-wsgi in the upload queue for bionic/xenial?  Thanks in advance!
[12:29] -queuebot:#ubuntu-release- New: accepted octavia [amd64] (focal-proposed) [6.0.0~b2~git2020020614.005cd1e6-0ubuntu2]
[12:50] <sil2100> mfo: on it o/
[12:50] <sil2100> handsome_feng: I'll try to look into it shortly
[12:51]  * sil2100 just needs to finish up some stuff
[12:52] <mfo> sil2100, thanks!
[12:52] <handsome_feng> sil2100, thanks! +1 :)
[13:16] -queuebot:#ubuntu-release- Unapproved: accepted mod-wsgi [source] (bionic-proposed) [4.5.17-1ubuntu1]
[13:16] -queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1040.45] (no packageset)
[13:23] -queuebot:#ubuntu-release- New: accepted linux-signed-azure-5.3 [amd64] (bionic-proposed) [5.3.0-1014.15~18.04.1]
[13:23] -queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1040.45]
[13:24] <sil2100> mfo, handsome_feng: both done o/
[13:24] -queuebot:#ubuntu-release- Unapproved: accepted mod-wsgi [source] (xenial-proposed) [4.3.0-1.1ubuntu1]
[13:25] <mfo> sil2100, ack, thanks for the prompt review, Lukasz!
[13:25] <handsome_feng> sil2100, thank you! \o/
[15:20] -queuebot:#ubuntu-release- New binary: linux-signed-gcp-5.3 [amd64] (bionic-proposed/main) [5.3.0-1013.14~18.04.1] (no packageset)
[15:21] -queuebot:#ubuntu-release- New binary: linux-signed-gke-5.3 [amd64] (bionic-proposed/universe) [5.3.0-1013.14~18.04.1] (no packageset)
[15:23] -queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1053.56] (no packageset)
[16:14] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp-5.3 [amd64] (bionic-proposed) [5.3.0-1013.14~18.04.1]
[16:14] -queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.3 [amd64] (bionic-proposed) [5.3.0-1013.14~18.04.1]
[16:14] -queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1053.56]
[16:38] <teward> Kamilion: better place to have that discussion than 'here'.
[16:38] <teward> needs also Server Team input
[16:50] -queuebot:#ubuntu-release- Unapproved: procps (xenial-proposed/main) [2:3.3.10-4ubuntu2.4 => 2:3.3.10-4ubuntu2.5] (core)
[17:24] -queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/main) [2.38~14.04 => 2.43.3~14.04] (no packageset)
[17:37] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1072.77] (kernel)
[17:40] <vorlon> python3.7 (3.7.6-1ubuntu3) focal; urgency=medium
[17:40] <vorlon>   * No-change rebuild to drop python3.7.
[17:40] <vorlon> huh why didn't that work
[17:40] <vorlon> doko: and I guess you wouldn't like me to zero out my TIL merges by merging ruby-defaults right now ;)
[17:43] <xnox> vorlon:  server team is doing the ruby transition, so you should consider your TIL stolen on it.
[17:43] <xnox> vorlon:  or like check with powersj
[17:45] <doko> yeah, I missed that upload. sorry
[17:45] <doko> vorlon: just go ahead
[17:45] -queuebot:#ubuntu-release- Unapproved: landscape-client (eoan-proposed/main) [18.01-0ubuntu9.1 => 18.01-0ubuntu9.2] (ubuntu-server)
[17:45] <doko> stage1 rebuilds are finished in Debian, and stage2 rebuilds are running
[17:46] <doko> kanashiro: ^^^
[17:46] -queuebot:#ubuntu-release- Unapproved: landscape-client (bionic-proposed/main) [18.01-0ubuntu3.4 => 18.01-0ubuntu3.5] (ubuntu-server)
[18:01] <ahasenack> hi, I need some help/guidance with these mysql8 tests on arm64:  http://autopkgtest.ubuntu.com/packages/m/mysql-8.0/focal/arm64
[18:01] <ahasenack> looks like they just take too long, and get killed
[18:01] <ahasenack> the closest I got to the finish line was 97%
[18:02] <ahasenack> I do see some green ones that took longer and passed, though, so I'm not 100% sure it's just a timeout
[18:03] <ahasenack> maybe there is an inactivity check?
[18:23] -queuebot:#ubuntu-release- Unapproved: util-linux (eoan-proposed/main) [2.34-0.1ubuntu2.2 => 2.34-0.1ubuntu2.3] (core)
[18:27] <ahasenack> I filed https://code.launchpad.net/~ahasenack/britney/hint-mysql8-arm64/+merge/379582
[18:36] <kanashiro> re ruby 2.7 transition: I have a ruby-defaults package in my ppa with only ruby2.7 enabled, I am working to fix stuff on the Debian side and we are planning to upload the new ruby-defaults on Monday. Is that ok?
[18:37] <kanashiro> btw I am applying and uploading the delta vorlon added to ruby-defaults to Debian, so it can become a sync again
[19:38] <blackboxsw> rbalint: are we expecting a apt Allowed Origins fix for trusty uploaded too?  Regarding: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1857051
[19:39] <blackboxsw> I've completed SRU verification for xenial, bionic, eoan on this, but it's missing the trusty series upload
[19:40] <blackboxsw> and that's not a good time to try to get ahold of him :/ sending email
[19:43] <vorlon> kanashiro: sounds good to me, thanks
[20:56] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1056.60] (kernel)
[21:08] <wxl> lubuntu's daily failed and it seems to be an issue with qtermwidget-l10n but it's unclear exactly what. any ideas on how i can get more info? https://launchpadlibrarian.net/465846401/buildlog_ubuntu_focal_amd64_lubuntu_BUILDING.txt.gz
[21:10] <sarnold> wow you're not kidding :) that's pretty cryptic
[21:10] <wxl> i'm glad i'm not alone in that interpretation
[21:10] <wxl> perhaps i should just try a rebuild and see what happens
[21:12] <TJ-> wxl: it seems pretty obvious: " trying to overwrite '/usr/share/qtermwidget5/translations/qtermwidget_ca.qm', which is also in package qtermwidget5-data 0.14.1-2"
[21:13] <wxl> ah didn't see that up there
[21:14] <wxl> thanks for pointing out the literally obvious TJ- :)
[21:14] <sarnold> hah
[21:21] -queuebot:#ubuntu-release- Unapproved: sosreport (bionic-proposed/main) [3.6-1ubuntu<IP_ADDRESS> => 3.9-1ubuntu<IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[21:22] -queuebot:#ubuntu-release- Unapproved: sosreport (eoan-proposed/main) [3.6-1ubuntu3.1 => 3.9-1ubuntu<IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[21:28] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1072.77]
[21:28] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1056.60]
[22:45] <xnox> ocaml transition in progress
[23:20] <vorlon> doko: I tried to fix gringo's hard-coding of python3.7, and then it ftbfs in basically the same way as gcc-python-plugin, with an error about PyTypeObject.  Do you have a reference to what's changed in PyTypeObject between 3.7 and 3.8?  Because the compiler error messages are rather opaque about which of the 800 elements of the struct are triggering this
[23:24] -queuebot:#ubuntu-release- New binary: rust-sval-derive [amd64] (focal-proposed/universe) [0.5.0-1] (no packageset)
[23:25] -queuebot:#ubuntu-release- New binary: rust-sval-derive [s390x] (focal-proposed/universe) [0.5.0-1] (no packageset)
[23:26] -queuebot:#ubuntu-release- New binary: rust-sval-derive [arm64] (focal-proposed/universe) [0.5.0-1] (no packageset)
[23:26] -queuebot:#ubuntu-release- New binary: rust-sval-derive [armhf] (focal-proposed/universe) [0.5.0-1] (no packageset)
[23:26] -queuebot:#ubuntu-release- New binary: rust-sval-derive [ppc64el] (focal-proposed/universe) [0.5.0-1] (no packageset)
[23:38] -queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1031.32] (kernel)
[23:52] <tumbleweed> vorlon: the relevant change looks like https://www.python.org/dev/peps/pep-0590/


[01:15] <mhall119> software upgradable hardware?  What kind of hardware do you have?
[02:37] <MrChrisDruif> Haha
[02:37] <MrChrisDruif> Is not what I meant =')
[02:38] <MrChrisDruif> I meant that hardware already can get firmware upgrades
[03:01] <MrChrisDruif> mhall119; ^
[03:23] <mhall119> oh, and here I was trying to apt-get install more-ram
[16:48] <willcooke> http://smart-home-blog.com/2011/12/02/new-lenovo-ideacentre-q180-htpc/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+smart-home-blog+%28Smart+Home+Blog%29
[16:49] <willcooke> interesting, Lenovo getting in on the HTPC thing
[16:53] <mhall119> holy hell, who came up with that remote control design?
[16:56] <mhall119> I can't imagine anybody would feel comfortable using that
[16:57] <tgm4883> mhall119, I've seen one, they aren't that bad
[16:57] <tgm4883> that image makes it look uncomfortable though
[16:58] <willcooke> :)
[16:59] <willcooke> BTW guys, I realise I've been conspicuous by my absence over the last couple of weeks.  I'm putting plans in place to address that asap....
[17:00] <willcooke> just need to get a few other things put away first.
[17:01] <mhall119> willcooke: when you and repete have time, perhaps we can hold a scheduled discussion time to try and get everybody here at the same time?
[17:02] <willcooke> mhall119, certainly - that sounds like a great idea.
[17:03] <willcooke> I'll push to get that set up early next week, and I'll make an announcement or something on the mailing list
[17:03] <MrChrisDruif> Also add it to the Fridge
[17:03] <willcooke> I'd guess that around this sort of time would be best for most people
[17:04] <MrChrisDruif> I posted something earlier about weekly meetings, but no-one gave any response whatsoever
[17:04] <willcooke> MrChrisDruif, good idea.  Who's got access to the fridge door?
[17:04] <MrChrisDruif> willcooke; I know how to add stuff on that
[17:05]  * MrChrisDruif should be warming-up dinner, so he goes on doing that
[17:05] <willcooke> MrChrisDruif, I didn't see your message I'm afriad, I think it might have got lost in the heated debate that was going on :)
[17:06] <MrChrisDruif> willcooke; https://lists.launchpad.net/ubuntu-tv/msg00016.html
[17:07] <willcooke> Thx MrChrisDruif - well, I'll aim for that slot next week.
[17:07] <willcooke> I'll come back with a confirmation one way or the other asap
[17:10] <MrChrisDruif> Alright, just let me know
[17:10] <MrChrisDruif> Tonight I'll be of for orchestra rehearsal
[17:15] <willcooke> MrChrisDruif, cool - have fun!
[17:15] <MrChrisDruif> Thanks willcooke =)
[17:19] <AlanBell> o/ willcooke
[17:20] <willcooke> howdy AlanBell
[18:41] <tgm4883> comedic, but IMO relevant to the 3D discussion   http://theoatmeal.com/blog/3d_movies
[18:57] <mhall119> ah theoatmeal, so crude and yet so right
[19:01] <willcooke> ha!
[19:03] <dmj726> Well, I think 3D has its place, but I'm not sure it should be an immediate priority for us
[19:04] <willcooke> agreed - I don't think 3D is out of the gimmick phase quite yet
[19:06] <dmj726> I've seen a couple films enhanced by 3D, and one to which 3D was essential
[19:10] <dmj726> That said, we're still somewhat in the gimmick phase, though most films are less gimmicky about it than 3D films of prior decades
[19:21] <willcooke> It's interesting, things like "Jaws 3D" were piss poor certainly, but I get the impression some modern day 3D films were made in 3D only because they could charge a few extra bucks to see them, rather than being designed to benefit from 3d directly.
[19:21] <willcooke> That said, I've never actually seen a modern 3D movie
[19:21] <willcooke> :)
[19:21] <willcooke> I refuse to be taken in by the shameless money grabbing
[19:21] <willcooke> I'm sticking it to the man!
[19:22] <dmj726> hehe
[19:23] <dmj726> willcooke: the shameless postconversion is rather questionable
[19:23] <willcooke> definitely
[19:24] <dmj726> A few directors actually do a good job using it as an enhancement to already quality work, like Martin Scorsesee's Hugo.
[19:24] <AlanBell> I have no idea how they do that
[19:25] <AlanBell> http://en.wikipedia.org/wiki/2D_to_3D_Conversion
[19:25] <AlanBell> now I do :)
[19:25] <willcooke> and so do I
[19:25] <dmj726> Cave of Forgotten Dreams isn't the same film in 2D as in 3D, but that's because it's documenting these ancient cave paintings and in 3D it feels like you're actually in the cave with the paintings.
[19:26] <dmj726> of course the last one won't be breaking box office records
[19:32] <willcooke> :D
[20:14] <tgm4883> dmj726, I'll have to take a look at that. I don't think I understand why if you are looking at cave paintings (paintings on a wall) that it would look different in 3d rather than 2d
[20:15] <dmj726> tgm4883: The cave walls are highly curved
[20:15] <tgm4883> also, I'm not 100% sure how that would extend to other genres in a meaningful way
[20:15] <dmj726> and the curves are important to the way the people painted on them
[20:15] <tgm4883> I'll have to see it
[20:16] <dmj726> tgm4883: I'm not saying it would apply to other genres
[20:16] <tgm4883> It's like IMAX, it only applies to some very specific films
[20:16] <dmj726> just that it is possible to have 3D be an important artistic tool for a film
[20:17] <dmj726> Personally, I think most 3D films are just doing it for the money, but I don't doubt that there will be some films for which it is clearly better
[20:17] <dmj726> it also could be useful for certain kinds of software
[20:18] <dmj726> I'm not suggesting we devote much effort to 3D support right now though
[20:18] <dmj726> just not writing it off
[20:18] <dmj726> especially given that it has been used much more artistically recently than in the past
[20:19] <dmj726> (Alfred Hitchcock excepted of course)


[09:37] <Ingvix> how do I see my clipboard content in terminal?
[09:37] <Ingvix> whops, wrong channel
[09:38] <hateball> Ingvix: xclipboard
[10:15] <NessaDevil> HI Guys. I have a problem with my lubuntu installation. Please have a look at the screenshot attached. http://bit.ly/276Wars
[10:23] <inski> I installed 16.04 on an Advent laptop, runs fine on ac, on battery shows splash screen and occasionally login but normally goes straight to suspend, unfortunately there is then no gui only a terminal ctrl alt F1 any ideas
[10:44] <Ingvix> My acer aspire one netbook suspends always at booting screen and in the login screen after that, continuesly if I don't login between the sleeps. If the process of suspeding has started before I login it may suspends even a moment after login. This behaviour also happens continuesly logged in if I have selected to suspend when closing the lid. Obviously I don't have that enabled but anyway. It's not earth shattering case but are there any known fixes? I
[10:44] <Ingvix> only found this some what similar case: http://ubuntuforums.org/showthread.php?t=2276661 and no solution is offered in the thread
[14:18] <TheSilentLink> hello whats the best terminal program for lubuntu?
[17:19] <Ingvix> how do change the font color of the clock in the task bar
[17:20] <Ingvix> and can I change add an tray icon for an app that doesn't have on but is in the tray
[18:52] <Ingvix> lubuntu doesn't seem to have too active community
[18:58] <teward> moreso a lack of support because it's the middle of the day on monday?
[18:58] <teward> :
[18:58] <teward> pp
[18:58] <teward> nobody's on a 'dedicated support staff' role ;)
[19:12] <Ingvix> maybe
[19:23] <lynorian> Ingvix, right click on the panel click panel prefrences and click on appearance and then change the color with a custom font color
[19:24] <Ingvix> ah, yes, thanks lynorian
[19:25] <Ingvix> I didn't realise that that determines the color of the clock too and I don't have any other text visible on the panel
[20:54] <n-iCe> hi
[21:49] <lynorian> are there any cursor themes that are not white or black my mom really wants to know and is giving me trouble over this
[21:50] <lynorian> I personally don't mind because I can see the cursor well enough
[21:56] <n-iCe> hi
[21:56] <n-iCe> lynorian: http://askubuntu.com/questions/533245/changing-the-mouse-cursor-shape-on-lubuntu
[22:20] <lynorian> thanks n-ice


[00:54] <rlaager> Okay, so I rebuilt my backport of libgadu against libgnutls26. Now, I definitely get "Unable to locate package libmessaging-menu-dev" on Trusty: https://launchpadlibrarian.net/194579012/buildlog_ubuntu-precise-amd64.pidgin_1%3A2.10.11-1ubuntu0%2Bpidgin4.12.04_MANUALDEPWAIT.txt.gz
[00:55] <rlaager> err, that's precise, nevermind
[01:00] <rlaager> Okay, so now trusty says, "libgadu-dev : Depends: libgnutls26-dev but it is not installable".
[06:14] <pitti> Good morning
[06:15] <pitti> hallyn: cgmanager startup behaviour> ah great, then all is well AFAICS?
[06:15] <darkxst> morning pitti
[06:15] <pitti> hey darkxst
[06:16] <darkxst> pitti, is there some way to override make check in cdbs (for xvfb-run)?
[06:16] <pitti> darkxst: yes, there is; /me needs to look, it's been a few years
[06:17] <pitti> there's DEB_MAKE_CHECK_TARGET, but that's not sufficient
[06:18] <darkxst> nope, best I could find was DEB_MAKE_INVOKE, but that runs the entire build through xvfb
[06:20] <pitti> darkxst: perhaps just don't define DEB_MAKE_CHECK_TARGET and run the checks in common-post-build-arch::?
[06:20] <darkxst> I did try something like that, but tests (for gjs) still seem to run
[06:21] <darkxst> I suppose I could make the DEB_MAKE_CHECK_TARGET non fatal though, then it would work
[06:22] <darkxst> or just completely ignore build tests, since we have autopkgtests also?
[06:24] <darkxst> does that seem reasonable? pretty sure its exactly the same test suite
[06:27] <pitti> jamespage: thanks for starting the init migration on nova! FTR, it's stuck in -proposed as nova-objectstore doesn't seem to start automatically (https://jenkins.qa.ubuntu.com/job/vivid-adt-nova/47/ARCH=amd64,label=adt/console)
[06:27] <pitti> darkxst: setting DEB_MAKE_CHECK_TARGET to "check || true" would run everything twice
[06:29] <pitti> darkxst: build tests are still nice as they run on all the arches
[06:30] <pitti> darkxst: I still don't understand -- AFAICS cdbs does not run "make check" automatically
[06:30] <pitti> darkxst: are you sure you don't have anything in your rules which invokes the tests automatically? perhaps it even happens through normal "make" in the upstream build system?
[06:33] <darkxst> pitti, when I removed DEB_MAKE_CHECK_TARGET I still had two sets of tests running, one for the override
[06:34] <darkxst> though gjs doesnt seem to run make check atleast in jhbuild
[07:31] <dholbach> good morning
[07:49] <pitti> didrocks: argh, floodlight holding up sysvinit again :/
[07:50] <pitti> Laney, infinity: could either of you please force-badtest floodlight?
[07:50] <didrocks> pitti: it's a different test failing than last time?
[07:50] <pitti> didrocks: no, exactly the same
[07:50] <pitti> (three)
[07:51] <didrocks> ah :(
[07:52] <didrocks> pitti: so, systemd hackfest this week it seems? I planned to do some dev story stuff, but will see if I can join
[07:52] <pitti> didrocks: yes; we should wait for slangasek's definitive answer, but I think Thu/Fri
[07:53] <slangasek> yes Thu-Fri
[07:53] <didrocks> ok, let's see if I can join (I did some transitions last week)
[07:55] <pitti> oh, hey slangasek -- unsual hour :)
[07:56] <pitti> slangasek: so, I updated https://wiki.ubuntu.com/SystemdForUpstartUsers, will create a pad for coordination with links and lists of packages to convert grouped by openstack/desktop/juju/etc.
[07:56] <pitti> slangasek, didrocks: as for IRC, I think just #u-devel should be fine, WDYT?
[07:56] <slangasek> yes, that's my preference
[07:57] <didrocks> pitti: yeah, sounds good to me
[07:57] <pitti> and then we can have hangouts as necessary, but having it on all the time is too distracting IMHO
[07:57] <didrocks> agreed
[07:57]  * pitti yays https://launchpad.net/ubuntu/+source/keystone/1:2015.1~b1-0ubuntu2 and smells another MIR coming for didrocks  :)
[07:58] <slangasek> ok; I'd like to at least have a daily hangout at the start of the overlap between US and EU
[07:58] <pitti> that sounds good
[07:59] <didrocks> pitti: it's MIR-day anyway, 11 packages now (fctix, second edition) :p
[07:59] <didrocks> pitti: I'm a little bit afraid about that autogenerated systemd units btw
[07:59]  * pitti creates http://pad.ubuntu.com/systemd-porting-sprint
[07:59] <pitti> didrocks: I haven't looked at it at all yet TBH
[07:59] <didrocks> seems like it will just "have everything started on runlevel 5 equivalent"
[07:59] <didrocks> instead of seeing relations between services
[07:59] <pitti> didrocks: the current upstart jobs aren't really much different either AFAIR
[07:59] <didrocks> right
[07:59] <didrocks> it was just the opportunity to get it right :)
[08:00] <didrocks> but having a tool doing that genericness… meh
[08:00] <jamespage> pitti, will look this morning
[08:03] <pitti> didrocks, jamespage: yeah, .init.in also sounds a lot like it should just use /lib/init/init-d-script
[08:04] <didrocks> yeah, as I did for whoopsie IIRC
[08:05] <jamespage> pitti, hmm - maybe - currently the openstack-pkg-tools helper produces one that has some systemd specific actions as well
[08:05] <jamespage> pitti, I think we'll run with that for this cycle at least as it brings us a bit closer to Debian as well
[08:06] <pitti> jamespage: sounds good; merging/getting closer with Debian makes stuff easier in its own right, too
[08:16] <jamespage> pitti, oops - missed the init.in for objectstore - fixing now
[08:17] <pitti> jamespage: thanks! (and yay tests!)
[08:34] <pitti> slangasek: I prepared http://pad.ubuntu.com/systemd-porting-sprint
[08:34] <pitti> I think jamespage could already grab some of the OpenStack ones which he already started
[08:35] <didrocks> pitti: I'm unsure how often the file system update on the server, but some are already transitionned from Friday
[08:35] <pitti> didrocks: yeah, it's lagging several days behind for some reason
[08:35] <pitti> didrocks: I also transitioned two (apport-noui and mythtv)
[08:35] <pitti> didrocks: but so far it has always updated eventually
[08:36] <didrocks> yeah, it will just need some refresh then or should I remove those already done?
[08:37] <pitti> didrocks: just remove them from the pad, please
[08:38] <didrocks> doing
[08:39] <jamespage> pitti, canonical server team will deal with the openstack ones
[08:39] <jamespage> pitti, I have a few to review from coreycb last week
[08:40] <didrocks> jamespage: will you handle the server ones as well?
[08:40] <jamespage> didrocks, sure
[08:40] <pitti> jamespage: ack; I kept them separate in the categorization as I figured converting those might be a bit special (upstream coordination, and they are all relatively similar, etc.)
[08:40] <jamespage> didrocks, rbasak will help out there as well
[08:40] <didrocks> great ;)
[08:41] <pitti> jamespage: (no need to add "TODO" -- perhaps instead say "jamespage"
[08:44] <pitti> jamespage: I updated the status of keystone
[08:44] <jamespage> pitti, ah - right - yes - indeed - its stuck in proposed
[08:46] <pitti> slangasek: should I send the u-d-a@ announcement now, or is there something further to be done?
[08:46] <pitti> slangasek: ah, I have an XX:XX for the hangout time, but we can update the pad later
[09:09] <jamespage> pitti, when's the planned switch to systemd happening? I'll poke the juju dev team to deal with the autogenerated upstart jobs
[09:09] <pitti> jamespage: "we release when it's ready" by and large, but we do aim for 15.04, i. e. vivid
[09:09] <pitti> we shouldn't drag it for too long
[09:09] <pitti> jamespage: https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration has the remaining work aside from porting the jobs
[09:10] <jamespage> pitti, oh I agree - but do we have a target for the swithover?
[09:10] <pitti> jamespage: I figure by feature freeze?
[09:10] <pitti> (no particular date)
[09:10] <jamespage> pitti, sounds reasonable
[09:10] <jamespage> pitti, I know that the juju team will prioritize the work accordingly - all of our vivid openstack testing will break on switchover unless we have the new juju bits
[09:11] <pitti> jamespage: so end of January would be nice, so that we still have enough time to fix the rough edges
[09:11] <jamespage> +1 ack
[09:11] <pitti> jamespage: cool, thanks for coordinating that!
[09:14] <jamespage> pitti, I've raised a bug for juju-core, linked it to the blueprint and pinged the ta and engineering manager for juju-core
[09:15] <jamespage> hopefully that should get some attention post haste
[09:15] <pitti> thanks; tagged and subscribed
[09:16] <pitti> jamespage: and replaced the textual WI with the bug
[09:16] <jamespage> pitti, ack
[09:16] <jamespage> rbasak, ^^ fyi - I know you are point on juju-core crossteam activities
[09:26] <cjwatson> rlaager: There's no such package libgnutls26-dev in trusty; it was called libgnutls-dev
[09:26] <cjwatson> rlaager: Generally I'd advise using chdist from devscripts to reproduce this kind of thing; that way you can have an isolated apt-get environment (that can't actually install packages, but it can tell you whether it would be able to resolve dependencies) that only considers trusty plus the PPA in question
[09:27] <rlaager> cjwatson: Thanks. I wasn't aware of that tool.
[09:46] <pitti> stgraber: oh, I see -- /lib/udev/bridge-network-interface is one of the udev-y things which would bring up bridges refering to a recently up'ed physical interface
[09:46] <pitti> (40-bridge-network-interface.rules)
[10:11] <pitti> didrocks: erk -- check /usr/sbin/invoke-rc.d line 577
[10:11] <pitti> didrocks: I just got an error message "op: not found" due to the extra line break
[10:12] <pitti> from http://launchpadlibrarian.net/194237210/sysvinit_2.88dsf-53.2ubuntu3_2.88dsf-53.2ubuntu4.diff.gz
[10:12] <pitti> didrocks: want to upload a fix, or want me to if you don't have time?
[10:13] <cjwatson> that was already fixed
[10:13] <cjwatson> http://launchpadlibrarian.net/194242250/sysvinit_2.88dsf-53.2ubuntu4_2.88dsf-53.2ubuntu5.diff.gz
[10:14] <pitti> cjwatson: no, it wasn't -- the error above is the line immediately below that
[10:14] <cjwatson> oh yeah, good point
[10:14] <pitti> i. e. the printerror
[10:14] <cjwatson> misread, sorry
[10:14] <pitti> well, *shrug*, I'll just upload it
[10:16] <pitti> cjwatson, didrocks: ^ uploaded (2.88dsf-53.2ubuntu6)
[10:17] <pitti> jamespage: nova test succeeds again, cheers!
[10:17] <jamespage> pitti, np
[10:17] <cjwatson> there was already an ubuntu6 ...
[10:18] <cjwatson> pitti: you'll need to rebase on https://launchpad.net/ubuntu/+source/sysvinit/2.88dsf-53.2ubuntu6
[10:18] <pitti> argh, sorry about that
[10:18]  * pitti says "Use pull-lp-source, Luke!" a hundred times
[10:19] <pitti> ubuntu7 is the charm! uploaded
[10:22] <highvoltage> heh :)
[11:33] <didrocks> pitti: sorry, was out for some exercise
[11:35] <pitti> didrocks: no worries
[11:36] <didrocks> pitti: I really wonder what I did with my vim snippet in that upload to get the 2 breaks…
[11:36] <pitti> tseliot: I updated bug 1312255 with some info and a question, but by and large translating this into a unit looks reasonably straightforward; let me know if you have questions
[11:36] <pitti> didrocks: forgot to hit the pastetoggle key? :-)
[11:36] <didrocks> pitti: probably :p
[11:37] <tseliot> pitti: I'll have a look at it, thanks
[11:44]  * xnox has an evil plan for upstart-local-bridge
[11:44] <didrocks> xnox: based on generators, from what I see :)
[11:45] <xnox> didrocks: yeah, but with full compat for system-systemd, session-systemd, session-upstart without system-upstart.
[11:45]  * xnox should post an email about it.
[11:46] <didrocks> nice ;) yeah, please do
[12:10] <LocutusOfBorg1> pitti, thanks for the answers, I don't know the best solution, feel free to do what you think is best
[12:10] <LocutusOfBorg1> ;)
[12:41] <pitti> LocutusOfBorg1: I don't know what is best, I don't know why that line got removed
[12:41] <pitti> LocutusOfBorg1: is there some upstream commit that this refers to which might have some more info?
[12:44] <pitti> stgraber: systemd with the recent user lxc fixes is now in vivid
[12:52] <LocutusOfBorg1> pitti, found it https://www.virtualbox.org/changeset/48422/vbox/trunk/src/VBox/Additions/linux/drm/vboxvideo_drm.c
[12:53] <LocutusOfBorg1> " Additions/linux/drm: removed .fasync as drm_fasync is an unneeded no-op to be removed in Linux 3.12."
  Just buttload it.
[13:16]  * pitti did ages ago
[13:17] <Bluefoxicy> Like, that disk cache thing, the buffers?  They go down.
[13:17] <Bluefoxicy> 16GB RAM, 7GB used, 9GB disk cache?  Turns into 15GB used, 1GB ... then 0.5GB... then 100MB
[13:17] <Bluefoxicy> know what happens?
[13:17] <Bluefoxicy> Your computer starts thrashing the hard disk, and just locks up.  If you wait long enough, the OOM killer eventually kicks in (if the process keeps consuming more RAM), kills something, and you can use your PC again.
[13:18] <Bluefoxicy> Because you wind up re-reading the same library files again and again several times per second when you run low on disk cache.
[13:18] <Bluefoxicy> So
[13:18] <Bluefoxicy> really
[13:18] <pitti> LocutusOfBorg1: uploaded, thanks! I update the bug
[13:18] <Bluefoxicy> Why isn't there a tunable to tell the kernel to kick in OOM kill early?
[13:18] <LocutusOfBorg1> thanks for caring pitti ;)
[13:19] <Bluefoxicy> e.g when reclaimable RAM (including disk cache, buffers, etc.) drops below a certain threshold
[13:19] <Bluefoxicy> just to say "your PC really won't be usable if you have less than this much RAM for disk cache and buffers, so falling below this is an OOM situation"
[13:21]  * Bluefoxicy sets kernel.sysrq to 240 so he can throw an OOM kill manually when this happens.
[13:37] <highvoltage> /win 11
[13:37] <pitti> highvoltage: /lose 5
[13:37] <pitti> highvoltage: hey Jonathan, how are you?
[13:40] <highvoltage> pitti: hey! doing good thanks and you?
[13:40] <pitti> highvoltage: quite fine, thanks!
[13:40] <pitti> highvoltage: the ZA summer a few weeks ago was nice :)
[13:41] <highvoltage> pitti: are you visiting again next month?
[13:41] <pitti> highvoltage: no, I won't; I'll go to FOSDEM (Brussels)
[13:42] <xnox> pitti: see you there ;-) i've booked everything for myself.
[13:42] <pitti> xnox: I don't have much to book except for the train
[13:43] <pitti> xnox: beer time after the hackfest and on Sat evening then, I figure? :-)
[13:43] <highvoltage> ah, still nice :)
[13:46] <xnox> pitti: yeap.
[13:55] <hallyn> pitti: i'm a bit lost at this point.  You mean all is well if we just do nothing?
[13:56] <pitti> hallyn: well, we still need to start cgmanager by default
[14:20] <pitti> hallyn: but I meant aside from that it seems there's nothing else blocking that?
[14:22] <pitti> jamespage: ironic's new dep on the nonexisting python-pysendfile -- is that just a typo and should be python-sendfile, or is that a PPA package of some sort?
[14:22] <jamespage> pitti, argh that's me being a dumbass
[14:22] <jamespage> pitti, at least I think so
[14:22]  * jamespage looks
[14:23] <didrocks> pitti: didn't you tell there was an issue about ressource management? like both settings process in the same cgroup resources?
[14:23] <pitti> jamespage: debian/pydist-overrides removes "pysendfile", that apparently led to that
[14:23] <hallyn> pitti: with no other changes?
[14:23] <jamespage> pitti, hmm - apparently so although I thought the dh-python was clever enough to figure out where that comes from based on installed packages
[14:23] <pitti> didrocks: obviously everything has to decide whether it talks to systemd or cgmanager for shuffling stuff around, but the use cases should be fairly non-overlapping
[14:24] <pitti> hallyn: the "disallow fumbling with the systemd controller" was discussed and isn't possible, and you already wrote that cgmanager doesn't change the setup at startup
[14:24] <hallyn> yup
[14:24] <pitti> hallyn: so I see nothing else ATM -- do you still?
[14:25] <pitti> jamespage: ah, that was bug 1391960 -- so apparently it either needs to become a build dep or a manual binary dep?
[14:25] <didrocks> tedg: so nothing to do for you as well in UAL then? ^
[14:25] <jamespage> pitti, it is a build dep
[14:26] <pitti> jamespage: oh ok, so dh_python isn't as clever as it should be then?
[14:26] <pitti> didrocks: yep
[14:26] <pitti> didrocks: talked to tedg a few days ago
[14:27] <xnox> pitti: hallyn: is that cgroups/systemd discussion somewhere on a bug report mailing list, or just irc?
[14:27] <tedg> didrocks, It depends on Upstart, if it's still using CGManager to create the cgroups, we need to talk to cgmanager to access them. Which I think is the plan. So there's no UAL items (in theory).
[14:27] <pitti> xnox: summary is on bug 1400394, and I hope followups go there from now on
[14:27] <jamespage> pitti, that may indicate something broken in sendfile - looking now
[14:27] <xnox> jamespage: pitti: one can provide hints / overrides for dh_python there was a text file where to hint what dh_python should do when it sees "foo" requires.
[14:28] <hallyn> pitti: hm, so was that only done in debian/rule?
[14:28] <pitti> jamespage: ok; sorry for nagging, just reviewing what's stuck in -proposed
[14:28] <hallyn> pitti: just remove the --no-enable?
[14:28] <jamespage> xnox, yeah - I know but I'm pretty sure it should be able to figure out the binary package from the install bits
[14:28] <pitti> hallyn: "that"?
[14:28] <hallyn> yeah, having it not run by default
[14:28] <pitti> hallyn: oh -- yes, that should suffice, hang on
[14:28] <hallyn> yeah i thought ther emight e something in the actual systemd unit file too, but i see nothing
[14:29] <hallyn> stgraber: ^ is there anything else beside the 3 last patches to help lxcfs which you'd want in a new cgmanager releases?
[14:29] <pitti> hallyn: yep, that should do
[14:29] <hallyn> (any features i haven't implemented yet)
[14:35] <hallyn> jamespage: had any thoughts of merging ipxe from debian? :)
[14:36] <hallyn> (if not i'll do it, don't want to step on toes)
[14:36] <jamespage> hallyn, happy for you todo that :-)
[14:37] <pitti> cyphermox: looking at urfkill -- what was the reason to drop d-bus activation in favor of an upstart job? isn't starting on demand appropriate somehow? (and how doesn't that affect debian then?)
[14:40] <rbasak> Logan_: any objection if I sync haproxy 1.5.10-1 from Debian experimental? Looks like a straightforward upstream bugfix release.
[14:43] <hallyn> jamespage: on it
[14:47] <stgraber> hallyn: nope, I think we're good with current git trunk
[14:47] <stgraber> pitti: cool, thanks!
[14:49] <hallyn> pitti: are you by chance DD ?
[14:49] <pitti> stgraber: bonjour !
[14:49] <pitti> hallyn: yes
[14:49] <hallyn> pitti: cool, i'll hit you up for sponsoring? :)
[14:49] <pitti> hallyn: "by chance" .. it's what brought me into this Ubuntu business in the first place :)
[14:49] <hallyn> pitti: i really need ot pursue dm
[14:49] <pitti> hallyn: sure!
[14:50] <hallyn> pitti: i had a feeling  :)  but i've been wrong about that before
[14:51] <pitti> hallyn: so, toss me a .dsc or a debdiff or a git link, and I can upload it
[14:53] <pitti> hallyn, stgraber: btw, any immediate idea what breaks overlayfs (for lxc-start-ephemeral) on current 3.18 kernel? I filed bug 1409425
[14:53] <pitti> I tried to look into the upstream git, and there's a commit that sounded related
[14:53] <pitti> but we already have that
[14:54] <pitti> hallyn, stgraber: i. e. my question is -- is current git head working for you? if so, then I'll just wait for the new release :0
[14:55] <stgraber> pitti: nope, no clear idea as to what's going on here. I'd have to try the daily PPA on a 3.18 system to see what's going on. (Currently running on a 3.13 kernel here as I've been having other problems with 3.16 and 3.18)
[14:55] <Saviq> tvoss, hey, could we have your opinion on https://bugs.launchpad.net/ubuntu/+source/trust-store/+bug/1384950/comments/7 ?
[14:57] <tvoss> Saviq, sure, on my list
[15:08] <hallyn> pitti: i'm on 3.18.0-8-generic #9 with ppa lxc.  overlay clones are working for me
[15:08] <pitti> hallyn: great! I like retroactive bug fixing :)
[15:08] <pitti> stgraber: ^ FYI
[15:09] <cyphermox> pitti: as I recall there was a conflict between the dbus activation and the upstart job; but really xnox and awe knew about the details of this more than I did
[15:09] <hallyn> pitti: i would've thought the mount fix for overlay was in the archive...  but maybe not
[15:09] <pitti> hallyn: it is, that's the thing
[15:09] <hallyn> hm
[15:09] <pitti> hallyn: maybe it needed something else or there was a followup fix which I missed; I didn't really look very hard
[15:09] <hallyn> pitti: could you 'lxc-start -n <container> -l trace -o outout' and pastebinit outout?
[15:09] <cyphermox> pitti: the only thing I could think of right now is that we'd want urfkill to be started as early as possible on touch, earlier even than NM would start it or whatever, since it has to do some device enablement early on
[15:10] <pitti> hallyn: lxc-start is fine, it's -ephemeral which is broken (overlayfs)
[15:10] <pitti> hallyn: and l-s-e doesn't seem to have any debug options?
[15:10] <xnox> cyphermox: yo, sup? use busname in systemd units, don't mix dbus activation and upstart jobs. E.g. look at ofono, $ sudo stop ofono => yet org.ofono remains on the bus.
[15:10] <xnox> (spawned as a new process if there were any org.ofono clients e.g. d-feet)
[15:11] <pitti> xnox: I was looking at our urfkill delta, and we install an upstart job instead of using dbus activation, and I was wondering why
[15:11] <xnox> pitti: let me tell you why.
[15:11] <pitti> xnox: cyphermox's "early device setup" certainly makes sense, if we need that
[15:11] <pitti> Debian might not have that use case
[15:11] <hallyn> pitti: oh, but try 'lxc-clone -s -o container1 -n container2' and then lcx-start -n container2
[15:12] <pitti> hallyn: how does that use overlayfs?
[15:12] <cyphermox> pitti: I'm not sure that's a good enough reason not to properly fix urfkill to be started properly by systemd ;)
[15:12] <hallyn> yes
[15:12] <pitti> hallyn: cloning and starting works fine
[15:12] <pitti> oh, -s?
[15:12] <hallyn> d'oh
[15:12] <hallyn> pitti: don't bother
[15:12] <hallyn> stgraber: i was thinking lcx-start-ephemeral used the api more tha nit does.
[15:13] <hallyn> stgraber: lcx-start-ephemeral needs to be updated the same way the api did, for the new overlayfs options
[15:13] <xnox> pitti: did urfkilld restore state of things? and thus we wanted it to start earlier. Anyway, it should be systemd unit with busname and WantedBy=multi-user.target or some-such, to stay equivalent.
[15:14] <xnox> pitti: and my grep of all upstart jobs and initscripts does not reviel any reverse dependencies (e.g. start on started urfkill) or anything like that.
[15:14] <xnox> cyphermox: pitti: oh I remember why i dropped dbus activation and added upstart job.
[15:15] <stgraber> hallyn: ah, right
[15:15] <xnox> cyphermox: pitti: we were at a sprint in malta and the phone testing would not work, because urfkill would start even when not needed during testing.
[15:16] <cyphermox> not needed during testing?
[15:16] <xnox> cyphermox: pitti: dropping dbus activation allowed to reliably control execution -> not needed with proper systemd unit / dbus-activation.
[15:16] <xnox> cyphermox: as in testing would mock urfkill, and the real one should not be present at the time.
[15:17] <xnox> cyphermox: there was this other guy from phonedations that came to me with a bug about it.
[15:17] <cyphermox> ah, makes sense
[15:17] <cyphermox> yeah, Tony
[15:17] <xnox> old, tall, skinny, scruffy. probably tony.
[15:17] <hallyn> xnox: hi, any updates on the netcf upload for debian?
[15:17] <xnox> pitti: is there a way to suspend dbus activation?
[15:18] <hallyn> (don't know what tz you'r ein and don't want to miss you :)
[15:18] <xnox> hallyn: bah, did not upload. Can you please drop me an email to xnox @ debian . org, such that I do it when I'm back home?
[15:18] <xnox> hallyn: mostly +0 UTC ~=
[15:18] <pitti> xnox: yeah, don't install a .service file
[15:18] <hallyn> xnox: thanks
[15:18] <pitti> xnox: so, why would a test not just stop the system urfkill and/or replace its bus name?
[15:19] <xnox> pitti: well that's what we did.... I mean suspend on temporary basis.
[15:19] <pitti> xnox: anyway, it's not a problem to port the upstart job, I was just curious why
[15:19] <xnox> pitti: good point. i mean have .service file, but disable it via /run or some such.
[15:20] <xnox> pitti: with .service file and systemd-dbus activation one can do $ systemctl disable urfkill and that will suspend that job, even if dbus activation of it is attempted (as far as i can tell)
[15:20] <xnox> pitti: talk to tony, he might remember where/how "urfkill was getting spuriously activated, when not desired"
[15:20] <pitti> xnox: right
[15:21] <xnox> pitti: i have just little bits and pieces to extend in the local-bridge and then our session-upstart-init will be fully decoupled from upstart-pid1 and we can port phone to systemd, atleast for pid1.
[15:21] <xnox> well, phonedations people can.
[15:22] <pitti> yay!
[15:25] <Riddell> didrocks: what's the status of bluez5 in utopic?
[15:26] <Riddell> didrocks: _Groo_ is packaging bluedevil
[15:30] <didrocks> Riddell: waiting on some unity-system-settings change
[15:30] <didrocks> Riddell: then, we'll be good to go, but we need rsalveti and the kernel team to work on the Touch side
[15:39] <Riddell> didrocks: this new bluedevil only supports bluez5, is there a ppa we should put it in until bluez5 gets in the archive?
[15:40] <didrocks> Riddell: yes! please use https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/transitions
[15:40] <didrocks> Riddell: core-devs should have access to it
[15:40] <didrocks> Riddell: building on all archs
[15:41] <Riddell> all arches? ppas can do that?
[15:42] <slangasek> pitti: hi, why did you remove the juju-related systemd workitem from the blueprint?
[15:43] <pitti> slangasek: it was replaced with a bug link
[15:43] <slangasek> ok
[15:43] <didrocks> Riddell: some are devirtualized, yeah
[15:43] <didrocks> Riddell: it's using the distro builders
[15:44] <slangasek> pitti: regarding mailing u-d-a, I'm not sure this needs u-d-a as opposed to just u-d
[15:44] <pitti> slangasek: u-d@ WFM too, but I thought such kinds of announcements would be on-topic
[15:45] <xnox> slangasek: are phonedations people going to be on the sprint?
[15:45] <xnox> doko: why do you statically link libpython2.7 into the python interpreter?
[15:45] <pitti> slangasek: anyway, I think except for a hangout time (which we can put into the pad later) we should be set?
[15:47] <hallyn> pitti: http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.35-1.dsc
[15:50] <pitti> hallyn: any reason why you didn't just write LP: #1400394 in the changelog to actually close the bug?
[15:51] <pitti> hallyn: can I do that on upload, or will that disrupt some git?
[15:54] <slangasek> pitti: is this pad the draft for the announcement you're sending?  if so I guess we should set the hangout time first :)
[15:54] <hallyn> pitti: no git involved.  i just didn't do it bc debian <shrug>
[15:54] <hallyn> pitti: please go ahead
[15:54] <pitti> slangasek: no, that's the actual working scratchpad; for the annoucement we shouldn't replicate that IMHO, just saying when and wher it happens
[15:54] <slangasek> pitti: ok
[15:54] <slangasek> let me give the pad a quick read this morning (currently otp)
[15:56] <xnox> pitti: can i haz url plz =)
[15:56] <pitti> xnox: http://pad.ubuntu.com/systemd-porting-sprint
[15:58] <mitya57> sil2100, hi, when will you be able to look at appmenu-qt5?
[15:58] <mitya57> I got submenus working yesterday, that needed some patching on qt side
[15:59] <mitya57> also I tested it with more real-world applications, worked fine
[16:01] <pitti> hallyn: uploaded
[16:02] <sil2100> mitya57: hey! Sorry about that, I was supposed to do that before EOY but I think I got distracted due to the last-year touch image milestone, I promise looking at parts of it today and finalizing it tomorrow
[16:03] <mitya57> Thank you, no problem, we all were on holidays
[16:05] <hallyn> pitti: thanks!
[16:08] <jamespage> pitti, ironic should be sorted now - pysendfile was missing egg-info
[16:09] <flexiondotorg> I've submitted some merge proposal for livecd-rootfs and ubuntu-cdimage that add support for Ubuntu MATE.
[16:09] <pitti> jamespage: ah, dh_python looks at that to map the "import" to the python:Depends? I see
[16:09] <jamespage> pitti, indeed it does
[16:09] <flexiondotorg> How do I go about "integrating" (for want of a better expression) the Ubuntu MATE seeds?
[16:09] <flexiondotorg> Is there a package I should create a merge proposal against?
[16:11] <flexiondotorg> The Ubuntu MATE seeds are here - https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-seeds/ubuntu-mate.vivid
[16:27] <hallyn> jamespage: the kvm-ipxe package was there for p->t transitions, so we can drop it now right?
[16:27] <hallyn> yeah i think so.  anyway i'll try some upgrades to make sure
[16:42] <cjwatson> flexiondotorg: Mm, that stuff is not handled very well, needs an archive admin to mirror them on http://people.canonical.com/~ubuntu-archive/seeds/ and point a few things at them.  Will sort that out for you.
[16:42] <flexiondotorg> cjwatson, Many thanks for helping.
[16:45] <cjwatson> flexiondotorg: That part is done, should be visible soon.  There are various bits of lp:ubuntu-cdimage that need to be edited to point to the appropriate places.  Grepping for something like ubuntu-gnome is probably a good way to find them.
[16:46] <xnox> cjwatson: has kylin been fixed in those places?
[16:46] <cjwatson> I think so
[16:46] <xnox> cool.
[16:52] <flexiondotorg> cjwatson, Thanks. I think I've identified all the place ubuntu-mate need to be added. Prepairing a new proposal now.
[17:01] <flexiondotorg> cjwatson, When I try to resubmit the merge proposal launchpad tells me: This branch is not mergeable into lp:~ubuntu-cdimage/debian-cd/ubuntu.
[17:04] <cjwatson> flexiondotorg: That's because your branch is in the ubuntu-cdimage project, not in the debian-cd project.
[17:04] <cjwatson> flexiondotorg: You can move it on https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-cdimage/ubuntu-mate/+edit
[17:04] <pitti> slangasek: off for the night; if/when you are happy with the pad, perhaps you can send the announcement over your day, otherwise I'll send it tomorrow morning?
[17:05] <flexiondotorg> cjwatson, Understood.
[17:12] <flexiondotorg> cjwatson, Thanks for your help. I've resubmitted and it looks sane.
[17:45] <hallyn> jamespage: pushing a test build of ipxe to ppa:serge-hallyn/virt.  will push to vivid in a few hours
[18:59] <hallyn> stgraber: did you want me to take a stab at that lxc-start-ephemeral update, or are you doing it?
[19:01] <stgraber> hallyn: feel free to do it. I'm currently busy getting the lxcfs packaging ready for the archive. Though I'm happy to take care of it once I'm done.
[19:59] <hallyn> stgraber: ok, doesn't look too bad;  and i see Miklos made the overlay filesystem type 'overlay', so you can check for a 'overlay' (in additoin to or instead of 'overlayfs') entry in /proc/filesystems.
[20:00] <stgraber> hallyn: right
[20:26] <hallyn> stgraber: feh, just lost some time bc i was re-using a test container in a bad state
[20:27] <hallyn> k got something working
[22:06] <ahoneybun> balloons, I have a machine I can play around with now, how best do I help with testing?
[22:08] <Unit193> ahoneybun: I'd think the best place to ask would be channel 27, #ubuntu-quality.
[22:09] <ahoneybun> k thanks Unit193
[22:10] <staylor_> Curious about the recommended way of handling device trees with custom kernel packaging.  We have a custom package for support various embedded boards for a number of customers, right now we have one package per customer but the kernels themselves are effectively all the same and custom device tree files is the main difference.
[22:12] <staylor_> So I'm thinking of just removing the *.dtb from the kernel-image-custom package and instead have a number of device-tree-customerA/device-tree-customerB packages.


[13:06] <mup> Issue operator#778 opened: Harness.update_relation_data should complain if you pass anything but Dict[str, str] <Created by PietroPasotti> <https://github.com/canonical/operator/issues/778>
[19:59] <mup> Issue operator#779 opened: Not v4 UUID in `_TestingModelBackend` <Created by Abuelodelanada> <https://github.com/canonical/operator/issues/779>
[21:36] <mup> Issue operator#780 opened: Make it possible for storage to be attached prior to charm instance construction <Created by sed-i> <https://github.com/canonical/operator/issues/780>