[04:29] <jac_cplane> does anyone have a juju 2.x work around for centos not supporting python3
[04:30] <jac_cplane> it seems some of the juju libs require python3.  which part of the repos for centos7
[07:04] <kjackal> Good morning Juju World!
[07:47] <Mmike> Hello! Is there a way to configure the size of the 'logs' database? Currently it is 4GB, but I'd like to shrink that, if possible?
[09:47] <anrah_> Is there a way to include non-PyPi packages on wheelhouse.txt
[09:47] <anrah_> I mean that I created python package and I would like to include that on a charm, but not (yet) publish it on PyPi
[10:57] <SimonKLB> anrah_: the wheelhouse.txt is very similar to requirements.txt, you can add your own local paths or paths to a git repo
[10:58] <anrah_> Thanks, Noticed also that :)
[10:58] <SimonKLB> anrah_: for example, i have this in a charm's wheelhouse.txt "-e git://github.com/simonklb/aiosmtpd.git@merged#egg=aiosmtpd"
[10:58] <SimonKLB> great :)
[11:55] <lazyPower> icey: ping
[11:55] <icey> morning lazyPower
[11:55] <lazyPower> hey there, can you refresh my memory on the ceph-osd osd-devices config string?
[11:55] <lazyPower> does that *have* to point to a /dev device or can it just be a filepath?
[11:57] <icey> lazyPower: it can be a directory, although there are some practical caveats
[12:02] <icey> basically around using the same disk for multiple purposes, so the directory use case better serves for development, but can be used for example with bcache devices
[12:05] <lazyPower> yep
[12:05] <lazyPower> we're working on some demoware and i forgot how osd-devices config string worked, that unblocked me :) thanks
[12:05] <icey> glad to help lazyPower
[16:16] <bdx> hello all, can I apply constraints to juju deployed lxd instances via `--constraints`` ?
[16:17] <bdx> I'm trying it out a few different ways and not seeing the lxd profile modified to any degree
[16:18] <bdx> for example `juju deploy ubuntu --to lxd:0 --constraints "mem=1G"`
[16:18] <bdx> I thought ^ was a thing
[16:18] <bdx> possibly I'm using incorrectly
[16:40] <rick_h> bdx: so it was something getting worked on. lxd now supports enforcing those and kvm was updated to respect them
[16:40] <rick_h> bdx: I don't think the lxd side was landed
[16:40] <rick_h> bdx: the 2.2 release notes call out kvm supporting them but no mention of lxd so looks like it didn't get in there
[16:54] <vlad_> Hey guys quick question. I'm deploying a bundle of cephmon and ceph node charms from the store. On there CIDR network definitions do they need me to provide the actual static IPs or are they capable of DHCP?
[17:46] <rick_h> 14min juju show warning: https://www.youtube.com/watch?v=7Tqg3Hnkq2U
[17:47] <rick_h> lazyPower: marcoceppi bdx kwmonroe jrwren and more ^
[17:50] <vlad_> rick_h: Hey you got a second to chat?
[17:50] <rick_h> vlad_: a sec, doing a live stream in 10
[17:51] <vlad_> rick_h: Is that the youtube link? If so I'd be down to watch
[17:51] <rick_h> vlad_: I'm not sure on the CIDR/DHCP bit on the cephmon/node charms. Maybe cholcombe has the details there.
[17:51] <rick_h> vlad_: yes, that link should go live once we hit go on the stream
[17:52] <cholcombe> vlad_: we don't do anything different than this: http://docs.ceph.com/docs/hammer/rados/configuration/network-config-ref/.  We just pass the settings along
[17:53] <cholcombe> vlad_: take a look at the ceph networks section
[17:53] <vlad_> cholocombe: Thank you
[17:54] <vlad_> rick_h: Thanks to you as well! Good luck on the stream I'll watch
[17:54] <rick_h> https://hangouts.google.com/hangouts/_/y5xturh7gffpzedw7ob6hzpijme for those joining in (lazyPower bdx kwmonroe jrwren etc)
[17:54] <rick_h> marcoceppi: you around for it today?
[17:55] <lazyPower> rick_h: skipping this week, will catch you on the next one
[17:55] <marcoceppi> sure, i think I can join
[17:55] <rick_h> lazyPower: k
[17:55] <rick_h> lazyPower: you get to be the start next one?
[17:58] <vlad_> cholocombe: Hey ok cool that document totally cleared it up. If I'm deploying a set of them in a bundle I need to provide an array of addresses then correct?
[18:13] <cholcombe> vlad_: are you deploying to metal?
[18:15] <lazyPower> rick_h: uhhh
[18:18] <vlad_> cholocombe: Yeah I'm deploying to metal. I don't think the array idea I had makes any sense
[18:18] <vlad_> cholocombe: I've got all my networks setup on MaaS. When the deploy kicks of it spits out errors trying to get addresses for my services immediately, but keeps deploying. It gets IPs for all the physical machines and ends up failing around the ceph area
[18:24] <rick_h> marcoceppi: https://hangouts.google.com/hangouts/_/hjkwxg4fvjb3rhvfwoqswejggue
[18:25] <rick_h> for folks watching heading to https://www.youtube.com/watch?v=Ii1Ax4HgAP0
[18:25] <rick_h> I'll have to see if I can download/stitch them together later
[18:30] <cholcombe> vlad_: you can have ceph-mon/osd gather their ip info from the juju network spaces if you want
[18:30] <cholcombe> it's in the docs: https://jujucharms.com/ceph-mon/ under network support
[18:33] <vlad_> cholocombe: Is there any way to define spaces in a bundle?
[18:38] <cholcombe> vlad_: i don't think so.  i think you define them on maas?
[18:38] <cholcombe> i'm not entirely sure
[18:39] <vlad_> cholocombe: Yeah at first I didn't even try and use spaces outside of MaaS, and I just realized that juju has picked up my space from MaaS, and I guess I've architected this a bit wrong from that standpoint
[18:39] <vlad_> Is there anyway to remove a space once it has been added? I saw no mention of this in the docs
[18:40] <rick_h> cholcombe: vlad_ yes, the spaces must exist in the underlying provider first
[18:40] <rick_h> cholcombe: vlad_ and then you tell the bundle to leverage them and request that the right unit is on the right machine with access to the right spaces
[18:40] <cholcombe> rick_h: thanks
[18:46] <vlad_> rick_h: Is there a delete space command for when I've created a space in juju that doesn't exist ont he provider?
[18:47] <rick_h> vlad_: hmm, checking "juju help commands" there's a reload-spaces but not seeing a remove-space :(
[20:40] <Budgie^Smore> are we having fun yet?
[20:48] <lazyPower> Budgie^Smore: with 2.2 on the horizon this week according to rick, you bet :)
[20:49] <Budgie^Smore> lazyPower so he is being particular bossy this week then? ;-)
[20:49] <lazyPower> not even close  (not to me anyway)
[20:49] <lazyPower> he gave me leeway
[20:49] <Budgie^Smore> hehehe nice :)
[20:51] <Budgie^Smore> so just went will it hit jaas is the real question ;-)
[20:52] <rick_h> Should hit really tight on release
[20:53] <Budgie^Smore> coolio :)
[20:56] <Budgie^Smore> Finally started building a preseed file for my "cluster in a box" idea


[03:48] <brlin> I would like to ask if it's policy-wise possible to embed an external snapcraft recipe(e.g. from another repository, etc) to a source repo and trigger snap build from it.
[05:04] <wgrant> brlin: Can you explain in more detail what you're trying to do?
[05:09] <brlin> @wgrant Currently LP only supports building snaps which source repository contains the Snapcraft recipe, this is not applicable for the software which snapcraft recipe is store in another repository (either not upstreamed or stored separately upon upstream request).  It would be great if we can, for example, set up a code import on LP and set up snap build based on a recipe that is in another repository.
[05:10] <brlin> (Mostly for the benefit of automated snap building upon upstream code changes)
[05:11] <wgrant> brlin: snapcraft.yaml specifies where the source comes from. It's common to have it be the same tree as the one that contains snapcraft.yaml, but it's by no means required
[05:16] <brlin> @wgrant The problem is it's not an easy task to set up automated build if the recipe is separated from the target's source tree.  If external recipe is supported we can reuse the existing code import functionality to set up automated build on new code import.
[05:17] <wgrant> brlin: So your specific problem is that Launchpad won't automatically trigger builds based on changes in other repositories?
[05:18] <brlin> @wgrant Yes.
[05:18] <wgrant> It's best to make a problem statement rather than specifying a solution, because it's much more likely we'd solve the problem by having LP trigger builds based on other repositories perhaps extracted from snapcraft.yaml
[05:18] <brlin> Got it, thanks.
[05:23] <wgrant> brlin: A similar feature was prototyped in build.snapcraft.io, but it's not something that exists in Launchpad itself today. Let me see if we have an existing bug about it.
[05:24] <wgrant> I can't see one.
[05:25] <wgrant> brlin: Please file it at https://bugs.launchpad.net/launchpad/+filebug. Remember to state your use case, not just one potential solution.
[05:25] <brlin> Will do.
[06:24] <brlin> Here's the bug: https://bugs.launchpad.net/launchpad/+bug/1822721
[06:24] <ubot5`> Ubuntu bug 1822721 in Launchpad itself "No way to set up automated snap build on changes in another repository" [Undecided,New]
[10:53] <brlin> I would like to ask if it's difficult to set up an launchpad-buildd instance in a local environment?
[15:16] <hggdh> apt update is taking quite a long time to run now (at least for Disco); mine is downloading at 20kB/s (down from 7MB/s).Is there something going on?
[15:17] <hggdh> (this is for the main archive)
[15:18] <rbasak> hggdh: yes - discussed in #canonical-sysadmin
[15:20] <hggdh> rbasak: thank you sir. Did not think of #c-sysadmin (yeah, rather dumb)
[22:56] <Wimpress> wgrant: Is it possible to setup a PPA that has a real armhf builder, rather than arm64 with cross building?
[22:57] <wgrant> Wimpress: Launchpad doens't cross-build.
[22:57] <wgrant> Wimpress: Our arm64 hardware and arm64 kernels run armhf natively.
[22:57] <Wimpress> OK.
[22:57] <Wimpress> So there are not real armhf builders?
[22:58] <wgrant> No.
[22:58] <Wimpress> Bum.
[22:58] <wgrant> Wimpress: Why?
[22:58] <wgrant> There is never a requirement for them.
[22:58] <Wimpress> Super niche.
[22:58] <wgrant> No, wrong :)
[22:58] <Wimpress> I am building Chromium specifically optimised for the Raspberry Pi.
[22:59] <wgrant> Sure
[22:59] <wgrant> That'll work fine on our arm64 kernels.
[22:59] <Wimpress> Something of the host is leaking because a few components keep trying to link to 64 bit libs and those symbols are not available for libraspberrypi0.
[22:59] <wgrant> The build system is looking at things it shouldn't.
[23:00] <wgrant> We hack uname etc. so it looks like armhf.
[23:00] <Wimpress> I've been able to avoid this issue by disabling ARM Thumb but I've bumped into the same issue elsewhere in the code.
[23:00] <Wimpress> Wondered if I could avoid yet more build system hacking but building on real 32-bit arm host.
[23:01] <wgrant> No, it's best to track down the build system bug.
[23:01] <Wimpress> With 11 hours between build attempts, iteration is slow ;-)
[23:02] <Wimpress> If I build locally is it possible to upload all the assets to a PPA?
[23:02] <wgrant> You can always reproduce it locally with an armhf chroot on an arm64 kernel, with the compat_uts_name kernel commandline hack we use
[23:02] <wgrant> You can't upload binaries to a PPA, no.
[23:02] <wgrant> You should fix the build system bug.
[23:02] <Wimpress> Didn't think so.
[23:02] <Wimpress> Yeah, I am working on the build system. As you can imagine, lots of places to look/check for Chromium.
[23:03] <Wimpress> Wishful think there might be a cheat available :-)
[23:03] <wgrant> The entire Ubuntu archive is built on these, including Chromium, so we're not going to make exceptions for buggy build systems.
[23:05] <Wimpress> Yeah, this is due to patching Chromium to use libraspberrypi0. You can build Chromium just fine when the weirdness of those blobs is not a concern.
[23:06] <wgrant> Ah
[23:06] <wgrant> Wimpress: So hopefully it's easy enough to find the code that runs only in the scenario.
[23:07]  * wgrant just runs arm64 on all his Raspberry Pis
[23:07] <Wimpress> No if you want MMAL exposed you don't ;-)
[23:08] <wgrant> :(
[23:37] <Wimpress> wgrant: I was tryijng to clean up some git imports for Ubuntu MATE earlier. I was unable to delete any git repos in LP. Known issue?
[23:39] <Wimpress> Timeout Error
[23:39] <Wimpress> (Error ID: OOPS-ec138266e390c39a952394eb5c2f10ce)
[23:39] <ubot5`> https://oops.canonical.com/?oopsid=OOPS-ec138266e390c39a952394eb5c2f10ce
[23:40] <wgrant> Wimpress: https://bugs.launchpad.net/launchpad/+bug/1793266
[23:40] <ubot5`> Ubuntu bug 1793266 in Launchpad itself "Unable to delete repository" [Critical,In progress]
[23:40] <wgrant> A fix for the timeout is in progress
[23:40] <Wimpress> Ah OK. Cheers.


[00:00] -queuebot:#ubuntu-release- New binary: emerald [arm64] (disco-proposed/universe) [0.8.16-1] (no packageset)
[00:00] -queuebot:#ubuntu-release- New binary: emerald [armhf] (disco-proposed/universe) [0.8.16-1] (no packageset)
[00:02] -queuebot:#ubuntu-release- New binary: golang-1.12 [i386] (disco-proposed/universe) [1.12~beta1-1] (no packageset)
[00:03] -queuebot:#ubuntu-release- New binary: ghostwriter [arm64] (disco-proposed/universe) [1.7.3-1] (no packageset)
[00:03] -queuebot:#ubuntu-release- New binary: grim [arm64] (disco-proposed/universe) [1.0+ds-1] (no packageset)
[00:04] -queuebot:#ubuntu-release- New binary: grim [armhf] (disco-proposed/universe) [1.0+ds-1] (no packageset)
[00:05] -queuebot:#ubuntu-release- New binary: ghostwriter [armhf] (disco-proposed/universe) [1.7.3-1] (no packageset)
[00:07] -queuebot:#ubuntu-release- New binary: libnss-unknown [arm64] (disco-proposed/universe) [0.0.1+0git.3faffd5f-1] (no packageset)
[00:07] -queuebot:#ubuntu-release- New binary: libnss-unknown [armhf] (disco-proposed/universe) [0.0.1+0git.3faffd5f-1] (no packageset)
[00:08] -queuebot:#ubuntu-release- New binary: lablgtk3 [armhf] (disco-proposed/universe) [3.0~beta3-1] (no packageset)
[00:09] -queuebot:#ubuntu-release- New binary: mle [arm64] (disco-proposed/universe) [1.3-1] (no packageset)
[00:10] -queuebot:#ubuntu-release- New binary: rust-ena [arm64] (disco-proposed/universe) [0.11.0-1] (no packageset)
[00:10] -queuebot:#ubuntu-release- New binary: rust-ena [armhf] (disco-proposed/universe) [0.11.0-1] (no packageset)
[00:11] -queuebot:#ubuntu-release- New binary: lablgtk3 [arm64] (disco-proposed/universe) [3.0~beta3-1] (no packageset)
[00:11] -queuebot:#ubuntu-release- New binary: python-tornado4 [armhf] (disco-proposed/universe) [4.5.3-2] (no packageset)
[00:12] -queuebot:#ubuntu-release- New binary: python-tornado4 [arm64] (disco-proposed/universe) [4.5.3-2] (no packageset)
[00:12] -queuebot:#ubuntu-release- New binary: slurp [arm64] (disco-proposed/universe) [1.0-1] (no packageset)
[00:13] -queuebot:#ubuntu-release- New binary: slurp [armhf] (disco-proposed/universe) [1.0-1] (no packageset)
[00:14] -queuebot:#ubuntu-release- New binary: bitlbee-mastodon [arm64] (disco-proposed/universe) [1.4.0-1] (no packageset)
[00:14] -queuebot:#ubuntu-release- New binary: rust-hyphenation [armhf] (disco-proposed/universe) [0.7.1-1] (no packageset)
[00:14] -queuebot:#ubuntu-release- New binary: rust-hyphenation [arm64] (disco-proposed/universe) [0.7.1-1] (no packageset)
[00:14] -queuebot:#ubuntu-release- New binary: bitlbee-mastodon [armhf] (disco-proposed/universe) [1.4.0-1] (no packageset)
[00:14] -queuebot:#ubuntu-release- New binary: oakleaf [armhf] (disco-proposed/universe) [0.0.0-1] (no packageset)
[00:14] -queuebot:#ubuntu-release- New binary: oakleaf [arm64] (disco-proposed/universe) [0.0.0-1] (no packageset)
[00:26] -queuebot:#ubuntu-release- New binary: golang-1.12 [arm64] (disco-proposed/universe) [1.12~beta1-1] (no packageset)
[00:26] -queuebot:#ubuntu-release- New binary: golang-1.12 [armhf] (disco-proposed/universe) [1.12~beta1-1] (no packageset)
[00:29] -queuebot:#ubuntu-release- New binary: xemacs21 [arm64] (disco-proposed/universe) [21.4.24-7] (no packageset)
[00:32] -queuebot:#ubuntu-release- New binary: xemacs21 [armhf] (disco-proposed/universe) [21.4.24-7] (no packageset)
[01:57] -queuebot:#ubuntu-release- New: accepted bitlbee-mastodon [arm64] (disco-proposed) [1.4.0-1]
[01:57] -queuebot:#ubuntu-release- New: accepted golang-1.12 [arm64] (disco-proposed) [1.12~beta1-1]
[01:57] -queuebot:#ubuntu-release- New: accepted oakleaf [arm64] (disco-proposed) [0.0.0-1]
[01:57] -queuebot:#ubuntu-release- New: accepted rust-hyphenation [armhf] (disco-proposed) [0.7.1-1]
[01:57] -queuebot:#ubuntu-release- New: accepted xemacs21 [armhf] (disco-proposed) [21.4.24-7]
[01:57] -queuebot:#ubuntu-release- New binary: emerald [i386] (disco-proposed/universe) [0.8.16-1] (no packageset)
[01:57] -queuebot:#ubuntu-release- New binary: rust-hyphenation [ppc64el] (disco-proposed/universe) [0.7.1-1] (no packageset)
[01:57] -queuebot:#ubuntu-release- New: accepted bitlbee-mastodon [armhf] (disco-proposed) [1.4.0-1]
[01:57] -queuebot:#ubuntu-release- New: accepted oakleaf [armhf] (disco-proposed) [0.0.0-1]
[01:57] -queuebot:#ubuntu-release- New binary: dav4tbsync [amd64] (disco-proposed/universe) [0.10-1] (no packageset)
[01:57] -queuebot:#ubuntu-release- New: accepted golang-1.12 [armhf] (disco-proposed) [1.12~beta1-1]
[01:57] -queuebot:#ubuntu-release- New binary: oakleaf [s390x] (disco-proposed/universe) [0.0.0-1] (no packageset)
[01:57] -queuebot:#ubuntu-release- New: accepted xemacs21 [arm64] (disco-proposed) [21.4.24-7]
[01:57] -queuebot:#ubuntu-release- New: accepted lablgtk3 [arm64] (disco-proposed) [3.0~beta3-1]
[01:57] -queuebot:#ubuntu-release- New: accepted libnss-unknown [armhf] (disco-proposed) [0.0.1+0git.3faffd5f-1]
[01:57] -queuebot:#ubuntu-release- New: accepted python-tornado4 [arm64] (disco-proposed) [4.5.3-2]
[01:57] -queuebot:#ubuntu-release- New: accepted rust-ena [arm64] (disco-proposed) [0.11.0-1]
[01:57] -queuebot:#ubuntu-release- New: accepted rust-hyphenation [arm64] (disco-proposed) [0.7.1-1]
[01:57] -queuebot:#ubuntu-release- New: accepted slurp [armhf] (disco-proposed) [1.0-1]
[01:57] -queuebot:#ubuntu-release- New binary: python-tornado4 [s390x] (disco-proposed/universe) [4.5.3-2] (no packageset)
[01:57] -queuebot:#ubuntu-release- New binary: rust-ena [s390x] (disco-proposed/universe) [0.11.0-1] (no packageset)
[01:58] -queuebot:#ubuntu-release- New: accepted lablgtk3 [armhf] (disco-proposed) [3.0~beta3-1]
[01:58] -queuebot:#ubuntu-release- New: accepted python-tornado4 [armhf] (disco-proposed) [4.5.3-2]
[01:58] -queuebot:#ubuntu-release- New: accepted slurp [arm64] (disco-proposed) [1.0-1]
[01:58] -queuebot:#ubuntu-release- New binary: rust-ena [ppc64el] (disco-proposed/universe) [0.11.0-1] (no packageset)
[01:58] -queuebot:#ubuntu-release- New: accepted mle [arm64] (disco-proposed) [1.3-1]
[01:58] -queuebot:#ubuntu-release- New binary: libctl [i386] (disco-proposed/universe) [4.1.4-3] (no packageset)
[01:58] -queuebot:#ubuntu-release- New: accepted rust-ena [armhf] (disco-proposed) [0.11.0-1]
[01:58] -queuebot:#ubuntu-release- New binary: slurp [s390x] (disco-proposed/universe) [1.0-1] (no packageset)
[01:58] -queuebot:#ubuntu-release- New: accepted emerald [arm64] (disco-proposed) [0.8.16-1]
[01:58] -queuebot:#ubuntu-release- New: accepted ghostwriter [arm64] (disco-proposed) [1.7.3-1]
[01:58] -queuebot:#ubuntu-release- New: accepted golang-1.12 [i386] (disco-proposed) [1.12~beta1-1]
[01:58] -queuebot:#ubuntu-release- New: accepted grim [armhf] (disco-proposed) [1.0+ds-1]
[01:58] -queuebot:#ubuntu-release- New: accepted libctl [armhf] (disco-proposed) [4.1.4-3]
[01:58] -queuebot:#ubuntu-release- New binary: ghostwriter [s390x] (disco-proposed/universe) [1.7.3-1] (no packageset)
[01:58] -queuebot:#ubuntu-release- New binary: grim [s390x] (disco-proposed/universe) [1.0+ds-1] (no packageset)
[01:58] -queuebot:#ubuntu-release- New binary: mle [ppc64el] (disco-proposed/universe) [1.3-1] (no packageset)
[01:58] -queuebot:#ubuntu-release- New: accepted emerald [armhf] (disco-proposed) [0.8.16-1]
[01:58] -queuebot:#ubuntu-release- New: accepted grim [arm64] (disco-proposed) [1.0+ds-1]
[01:58] -queuebot:#ubuntu-release- New: accepted libnss-unknown [arm64] (disco-proposed) [0.0.1+0git.3faffd5f-1]
[01:58] -queuebot:#ubuntu-release- New binary: libnss-unknown [ppc64el] (disco-proposed/universe) [0.0.1+0git.3faffd5f-1] (no packageset)
[01:58] -queuebot:#ubuntu-release- New: accepted ghostwriter [armhf] (disco-proposed) [1.7.3-1]
[01:58] -queuebot:#ubuntu-release- New binary: grim [ppc64el] (disco-proposed/universe) [1.0+ds-1] (no packageset)
[01:58] -queuebot:#ubuntu-release- New: accepted libctl [arm64] (disco-proposed) [4.1.4-3]
[01:58] -queuebot:#ubuntu-release- New: accepted golang-1.12 [ppc64el] (disco-proposed) [1.12~beta1-1]
[01:58] -queuebot:#ubuntu-release- New: accepted python-tornado4 [amd64] (disco-proposed) [4.5.3-2]
[01:58] -queuebot:#ubuntu-release- New: accepted rust-hyphenation [i386] (disco-proposed) [0.7.1-1]
[01:58] -queuebot:#ubuntu-release- New: accepted xemacs21 [i386] (disco-proposed) [21.4.24-7]
[01:58] -queuebot:#ubuntu-release- New source: egl-wayland (disco-proposed/primary) [1.1.1-0ubuntu1]
[01:58] -queuebot:#ubuntu-release- New binary: libctl [ppc64el] (disco-proposed/universe) [4.1.4-3] (no packageset)
[01:58] -queuebot:#ubuntu-release- New: accepted oakleaf [amd64] (disco-proposed) [0.0.0-1]
[01:59] -queuebot:#ubuntu-release- New: accepted xemacs21 [amd64] (disco-proposed) [21.4.24-7]
[01:59] -queuebot:#ubuntu-release- New source: eglexternalplatform (disco-proposed/primary) [1.0+git20181101-0ubuntu1]
[01:59] -queuebot:#ubuntu-release- New: accepted rust-hyphenation [amd64] (disco-proposed) [0.7.1-1]
[01:59] -queuebot:#ubuntu-release- New binary: martian [amd64] (disco-proposed/universe) [1.2-0ubuntu1] (no packageset)
[01:59] -queuebot:#ubuntu-release- New: accepted xemacs21 [ppc64el] (disco-proposed) [21.4.24-7]
[01:59] -queuebot:#ubuntu-release- New: accepted bitlbee-mastodon [i386] (disco-proposed) [1.4.0-1]
[01:59] -queuebot:#ubuntu-release- New: accepted libcloudflare-client-perl [amd64] (disco-proposed) [0.55.4-1]
[01:59] -queuebot:#ubuntu-release- New: accepted libjs-jquery-center [amd64] (disco-proposed) [1.1.0+dfsg1-1]
[01:59] -queuebot:#ubuntu-release- New: accepted python-netdisco [amd64] (disco-proposed) [2.2.0-1]
[01:59] -queuebot:#ubuntu-release- New: accepted lablgtk3 [amd64] (disco-proposed) [3.0~beta3-1]
[01:59] -queuebot:#ubuntu-release- New: accepted oakleaf [i386] (disco-proposed) [0.0.0-1]
[01:59] -queuebot:#ubuntu-release- New: accepted libconfig-model-backend-yaml-perl [amd64] (disco-proposed) [2.132-1]
[01:59] -queuebot:#ubuntu-release- New: accepted slurp [amd64] (disco-proposed) [1.0-1]
[01:59] -queuebot:#ubuntu-release- New: accepted bitlbee-mastodon [amd64] (disco-proposed) [1.4.0-1]
[01:59] -queuebot:#ubuntu-release- New: accepted golang-1.12 [s390x] (disco-proposed) [1.12~beta1-1]
[01:59] -queuebot:#ubuntu-release- New: accepted libmoox-locale-passthrough-perl [amd64] (disco-proposed) [0.001-1]
[01:59] -queuebot:#ubuntu-release- New: accepted python-tornado4 [i386] (disco-proposed) [4.5.3-2]
[01:59] -queuebot:#ubuntu-release- New: accepted slurp [i386] (disco-proposed) [1.0-1]
[01:59] -queuebot:#ubuntu-release- New: accepted ghostwriter [i386] (disco-proposed) [1.7.3-1]
[01:59] -queuebot:#ubuntu-release- New: accepted libparse-binary-perl [amd64] (disco-proposed) [0.11-1]
[02:00] -queuebot:#ubuntu-release- New: accepted voluptuous-serialize [amd64] (disco-proposed) [2.0.0-1]
[02:00] -queuebot:#ubuntu-release- New: accepted libjs-jquery-markitup [amd64] (disco-proposed) [1.1.15-1]
[02:00] -queuebot:#ubuntu-release- New: accepted rust-ena [amd64] (disco-proposed) [0.11.0-1]
[02:00] -queuebot:#ubuntu-release- New: accepted emerald [amd64] (disco-proposed) [0.8.16-1]
[02:00] -queuebot:#ubuntu-release- New: accepted libnss-unknown [i386] (disco-proposed) [0.0.1+0git.3faffd5f-1]
[02:00] -queuebot:#ubuntu-release- New: accepted python-envs [amd64] (disco-proposed) [1.2.6-1]
[02:00] -queuebot:#ubuntu-release- New: accepted python-ifaddr [amd64] (disco-proposed) [0.1.6-1]
[02:00] -queuebot:#ubuntu-release- New: accepted xemacs21 [s390x] (disco-proposed) [21.4.24-7]
[02:00] -queuebot:#ubuntu-release- New: accepted libnewlib-nano [amd64] (disco-proposed) [2.10.0-1]
[02:00] -queuebot:#ubuntu-release- New: accepted python-flask-cors [amd64] (disco-proposed) [3.0.7-1]
[02:00] -queuebot:#ubuntu-release- New: accepted openrazer [amd64] (disco-proposed) [2.4.0+dfsg-1]
[02:00] -queuebot:#ubuntu-release- New: accepted rust-ena [i386] (disco-proposed) [0.11.0-1]
[02:00] -queuebot:#ubuntu-release- New: accepted emerald-themes [amd64] (disco-proposed) [0.8.16-1]
[02:00] -queuebot:#ubuntu-release- New: accepted golang-github-justinas-alice [amd64] (disco-proposed) [0.0~git20171023.03f45bd-1]
[02:00] -queuebot:#ubuntu-release- New: accepted grim [amd64] (disco-proposed) [1.0+ds-1]
[02:00] -queuebot:#ubuntu-release- New: accepted lablgtk3 [i386] (disco-proposed) [3.0~beta3-1]
[02:00] -queuebot:#ubuntu-release- New: accepted mle [amd64] (disco-proposed) [1.3-1]
[02:01] -queuebot:#ubuntu-release- New: accepted ghostwriter [amd64] (disco-proposed) [1.7.3-1]
[02:01] -queuebot:#ubuntu-release- New: accepted grim [i386] (disco-proposed) [1.0+ds-1]
[02:01] -queuebot:#ubuntu-release- New: accepted golang-github-namsral-flag [amd64] (disco-proposed) [1.7.4~alpha+git20170814.67f268f-1]
[02:01] -queuebot:#ubuntu-release- New: accepted libnss-unknown [amd64] (disco-proposed) [0.0.1+0git.3faffd5f-1]
[02:01] -queuebot:#ubuntu-release- New: accepted oakleaf [ppc64el] (disco-proposed) [0.0.0-1]
[17:14] -queuebot:#ubuntu-release- New binary: golang-github-datadog-zstd [amd64] (disco-proposed/universe) [1.3.4+ds-2] (no packageset)
[17:15] -queuebot:#ubuntu-release- New binary: test-kitchen [amd64] (disco-proposed/universe) [1.23.2-1] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: displaycal [s390x] (disco-proposed/universe) [<IP_ADDRESS>-3] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: displaycal [amd64] (disco-proposed/universe) [<IP_ADDRESS>-3] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: displaycal [ppc64el] (disco-proposed/universe) [<IP_ADDRESS>-3] (no packageset)
[17:23] -queuebot:#ubuntu-release- New binary: displaycal [arm64] (disco-proposed/universe) [<IP_ADDRESS>-3] (no packageset)
[17:24] -queuebot:#ubuntu-release- New binary: displaycal [i386] (disco-proposed/universe) [<IP_ADDRESS>-3] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: displaycal [armhf] (disco-proposed/universe) [<IP_ADDRESS>-3] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: dar [s390x] (disco-proposed/universe) [2.6.0-1] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: dar [i386] (disco-proposed/universe) [2.6.0-1] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: dar [ppc64el] (disco-proposed/universe) [2.6.0-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: dar [amd64] (disco-proposed/universe) [2.6.0-1] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: trollimage [amd64] (disco-proposed/universe) [1.6.3-1] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: pytroll-schedule [amd64] (disco-proposed/universe) [0.5.0-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: trollsift [amd64] (disco-proposed/universe) [0.3.1-2] (no packageset)
[23:26] -queuebot:#ubuntu-release- New binary: dar [arm64] (disco-proposed/universe) [2.6.0-1] (no packageset)
[23:26] -queuebot:#ubuntu-release- New binary: dar [armhf] (disco-proposed/universe) [2.6.0-1] (no packageset)
[23:32] -queuebot:#ubuntu-release- New binary: meep-lam4 [arm64] (disco-proposed/universe) [1.7.0-2] (no packageset)
[23:34] -queuebot:#ubuntu-release- New binary: meep-lam4 [armhf] (disco-proposed/universe) [1.7.0-2] (no packageset)
[23:35] -queuebot:#ubuntu-release- New binary: meep-mpich2 [armhf] (disco-proposed/universe) [1.7.0-2] (no packageset)
[23:51] -queuebot:#ubuntu-release- New binary: meep-mpi-default [arm64] (disco-proposed/universe) [1.7.0-2] (no packageset)
[23:51] -queuebot:#ubuntu-release- New binary: meep-mpich2 [arm64] (disco-proposed/universe) [1.7.0-2] (no packageset)
[23:53] -queuebot:#ubuntu-release- New binary: meep-openmpi [arm64] (disco-proposed/universe) [1.7.0-2] (no packageset)
[23:54] -queuebot:#ubuntu-release- New binary: meep-mpi-default [armhf] (disco-proposed/universe) [1.7.0-2] (no packageset)
[23:56] -queuebot:#ubuntu-release- New binary: meep-openmpi [armhf] (disco-proposed/universe) [1.7.0-2] (no packageset)


[16:32] <mdeslaur> \o
[16:32] <tyhicks> hello
[16:33] <jjohansen> o/
[16:33] <tyhicks> #startmeeting
[16:33] <meetingology> Meeting started Mon Apr 20 16:33:15 2015 UTC.  The chair is tyhicks. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:33] <meetingology> Available commands: action commands idea info link nick
[16:33] <chrisccoulson> hi
[16:33] <tyhicks> The meeting agenda can be found at:
[16:33] <tyhicks> [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting
[16:33] <tyhicks> [TOPIC] Weekly stand-up report
[16:33] <tyhicks> jdstrand: you're up
[16:38] <jdstrand> ]sorry
[16:38] <jdstrand> this week is again, snappy focused
[16:39] <jdstrand> I plan on working on finalizing the seccomp glue layer today and test the applied policies, updating ubuntu-core-security as necessary
[16:40] <jdstrand> I also need a piece for updating the already generated policies when ubuntu-core-security-seccomp is updated (like we do with apparmor-easyprof-ubuntu)
[16:41] <jdstrand> I made a change to snappy for updating dbus bus policy last week and need to make a change to snappy build to make it fail if the package.yaml is malformed when bus-name is specified
[16:41] <jdstrand> (not apparmor related)
[16:41] <jdstrand> then review tools
[16:41] <tyhicks> whew
[16:41] <tyhicks> lots of stuff :)
[16:42] <jdstrand> yeah
[16:42] <jdstrand> that's it from me
[16:42] <tyhicks> mdeslaur: you're up
[16:42] <mdeslaur> I just published some php5 updates
[16:42] <mdeslaur> and am currently working on new mysql versions
[16:42] <mdeslaur> after that, I'll be going down the list, there's stuff piling up
[16:43] <mdeslaur> that's pretty much it...oh, I am on bug triage this week
[16:43] <mdeslaur> that's it for me, sbeattie, tag, you're it.
[16:43] <sbeattie> I'm on cve triage this week
[16:44] <sbeattie> I'm finishing up openjdk testing, though I've hit a small snag where the icedtea plugin isn't working in my test environment on trusty/i386 (but other i386 and trusty/amd64 worked fine), so I need to dig in a bit to what's going on there
[16:45] <sbeattie> I also need to finish releasing apaprmor 2.9.2 and merge the python bits into my in progress trusty sru.
[16:45] <sbeattie> and also continue the gcc-pie work
[16:45] <sbeattie> that's my week. tyhicks?
[16:46] <tyhicks> I'm in the happy place this week
[16:46] <tyhicks> I'm going to review the snappy launcher code
[16:46] <tyhicks> I'll also review some snippets at the request of IS
[16:46] <tyhicks> still need to revisit the Vivid systemd/sbuild/schroot bugs (LP: #1427264) (LP: #1438942)
[16:46] <tyhicks> and still need to restart work on AppArmor kernel keyring mediation for user data encryption
[16:47] <tyhicks> that's it for me
[16:47] <tyhicks> jjohansen: you're up
[16:48] <jjohansen> I'm working on the apparmor upstream cleanup again this week. I'll kick in any help on 2.9.2 and 2.10 that sbeattie needs
[16:48] <jjohansen> and I have some kernel sru prep for the current release cycle
[16:49] <tyhicks> nice
[16:49] <tyhicks> sounds like you'll get some time to focus on the upstreaming effort this week
[16:50] <jjohansen> yes
[16:50] <jjohansen> I think that is it for me sarnold you are up
[16:51] <sarnold> I'm on community this week
[16:52] <sarnold> I'm going to be continuing my travels through openstack country, my travelogues will be for sale in the gift shop..
[16:52] <sarnold> I'll also try to do some minor apparmor patch reviews as interest allows
[16:52] <sarnold> that's it for me, chrisccoulson?
[16:53] <tyhicks> sarnold: last week you mentioned the conntrack mir
[16:53]  * tyhicks checks on the status
[16:53] <chrisccoulson> This week, I've probably got a firefox update. I also need to get oxide 1.6 out
[16:53] <tyhicks> (LP: #1381450)
[16:54] <chrisccoulson> I'll be spending some time to work through code reviews
[16:54] <sarnold> tyhicks: yeah, I didn't get to it, and I suspect it's too late for this cycle at this point; if you think it isn't, I'd be happy to pick it up asap..
[16:54] <chrisccoulson> other than that, I'm working through the list of bugs as usual
[16:54] <chrisccoulson> That's me done
[16:54] <tyhicks> sarnold: ok, we'll discuss it a little more afterwards
[16:56] <tyhicks> [TOPIC] Highlighted packages
[16:57] <tyhicks> The Ubuntu Security team will highlight some community-supported packages that might be good candidates for updating and or triaging. If you would like to help Ubuntu and not sure where to start, this is a great way to do so.
[16:57] <tyhicks> See https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures for details and if you have any questions, feel free to ask in #ubuntu-security. To find out other ways of helping out, please see https://wiki.ubuntu.com/SecurityTeam/GettingInvolved.
[16:57] <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/libxml-security-java.html
[16:57] <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/mediawiki-extensions.html
[16:57] <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/maven-indexer.html
[16:57] <tyhicks> [TOPIC] Miscellaneous and Questions
[16:57] <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/unace.html
[16:57] <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/not-yet-commons-ssl.html
[16:57] <tyhicks> Does anyone have any other questions or items to discuss?
[16:58] <tyhicks> jdstrand, mdeslaur, sbeattie, jjohansen, sarnold, ChrisCoulson: Thanks!
[16:58] <tyhicks> #endmeeting
[16:58] <meetingology> Meeting ended Mon Apr 20 16:58:50 2015 UTC.
[16:58] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2015/ubuntu-meeting.2015-04-20-16.33.moin.txt
[16:58] <mdeslaur> thanks tyhicks!
[16:59] <sarnold> thanks tyhicks !
[16:59] <jjohansen> thanks tyhicks
[17:01] <sbeattie> tyhicks: thanks!


[18:27] <xhaker> doko: found a bug
[18:27] <xhaker> xhaker@xps:~$ grep browser_dirs= /var/lib/dpkg/info/icedtea-gcjwebplugin.postinst
[18:27] <xhaker> browser_dirs="firefox iceape iceweasel mozilla midbrowser xulrunner"
[18:44] <xhaker> doko: after a no change rebuild of the source packages unchanged it's fixed
[18:44] <xhaker> doko xhaker@xps:~$ grep browser_dirs= /var/lib/dpkg/info/icedtea-gcjwebplugin.postinst
[18:44] <xhaker> browser_dirs="xulrunner-addons"
[18:45] <xhaker> could the buildd daemons be claiming to be Debian machines? :D
[18:45] <xhaker> buildd servers*
[18:45] <mohbana> why dont you guys just get help from fedora they do a perject job at making sure icedtea is running
[18:46] <xhaker> mohbana: in relation to what i'm saying, that has no value, since the packaging is correct, the builders just messed up
[18:47] <xhaker> mohbana: but you might not be talking about what i was entering above. in that case speak..
[18:47] <xhaker> mohbana: you're a ubuntu user wishing it had more java support?
[18:48] <mohbana> just generally speaking, icedtea is not working, eclipse is outdated in repos.  xhaker i use fedora the vast majority of the time but i have ubuntu on the
[18:48] <mohbana> another partion just incase and mainly to play about aswell
[18:49] <xhaker> mohbana: you're using what version on that partition? testing hardy?
[18:49] <mohbana> i am using gusty
[18:49] <doko> mohbana: we are removing the icedtea-java7 packages; no need to fix these for hardy
[18:50] <mohbana> so what is going to happen?
[18:50] <mohbana> just sun?
[18:50] <doko> mohbana: please send your eclipse packaging fixes to me, or file bug reports with the fixes attached
[18:51] <mohbana> why do you guys just get help from fedora there doing a really good job.  doko sorry i dont quiet understand what your talking about
[18:51] <xhaker> mohbana: hardy has openjdk-6 proper now
[18:51] <mohbana> xhaker, ok thats nice to hear ... is the mozzila plugin working/
[18:51] <xhaker> mohbana: that's what i was talking about with doko earlier
[18:52] <doko> mohbana: you're welcome to prepare an openjdk-6 backport for gutsy
[18:52] <xhaker> mohbana: it is not working yet with firefox3 due to a bug in the builder maybe
[18:53] <xhaker> doko: i believe mohbana is not a developer, and is dissatisfied because fedora has better java, etc.
[18:54] <doko> xhaker: then mohbana should at least file bug reports about issues which he discovers
[18:54] <mohbana> xhaker, no i am a uni student but yes thats very true
[18:55] <mohbana> ok
[18:55] <xhaker> doko: will you have a look at the icedtea-gcjwebplugin issue, just built the package in pbuilder and the binaries were very different
[18:55] <mohbana> any news on eclipse 3.3 on repo for hardy/
[18:56] <xhaker> sorry for not filling the bug myself, was trying to understand what as wrong with the scripts but couldn't finf anything of course :D
[18:56] <xhaker> mohbana: eclipse 3.3 is not in hardy, and won't be unless it gets backported from the next version
[18:56] <xhaker> you can however use the latest version of netbeans in hardy
[18:57] <xhaker> with openjdk-6 :)
[18:58] <xhaker> i would like to see eclipse in the repositories too, but it won't happen in hardy
[18:59] <doko> xhaker, mohbana: fixed icedtea-gcjwebplugin uploaded, should be available within two hours
[19:00] <mohbana> what about after the release, is it likely that its going to appear in the repo?
[19:00] <doko> mohbana: it's not that easy to package eclipse, if there are no volunteers to do the packaging, then there won't be a package
[19:00] <xhaker> mohbana: since you have ubuntu on a seperate partition and you seem eager to try new stuff, install the hardy beta available at the site, and file any bugs you find
[19:00] <xhaker> doko: it's not easy indeed, could upstream easy the burden in any way in the future?
[19:01] <xhaker> doko: i'm asking because i've tried before to package 3.3
[19:02] <doko> there's a ML about eclipse in unix distributions
[19:02] <xhaker> i might try again, since i haven't heard from the guy that clearly stated he was working on it, and it seems he wasn't
[19:05] <xhaker> doko: that was tricky. why would my pbuilder not need lsb-release? short answer welcome
[19:06] <doko> look at the build log
[19:06] <doko> maybe lsb-release is installed in your chroot?
[19:13] <xhaker> maybe, i'm using gdebi for the dependencies resolution, it might be pulling lsb-release :)


[05:29] <Bashing-om> No longer having fun, so retiring for the eve . G nite .
[06:38] <ducasse> morning all
[11:22] <BluesKaj> Howdy folks
[11:26] <ducasse> morning, BluesKaj
[11:26] <BluesKaj> 'Morning ducasse
[11:27] <BluesKaj> or 'Afternoon rather in your case :-)
[11:38] <ducasse> close enough :)
[21:45] <Bashing-om> Gonna go do lawnwork ... back in some bit .
[23:51] <Bashing-om> And ... mission accomplished . Back ,, on IRC .
[23:54] <OerHeks> good good
[23:54] <OerHeks> next one ..
[23:54] <OerHeks> what type of cloud is so lazy, it will never get up?
[23:55] <OerHeks> a Fog.
[23:57] <Bashing-om> Yuk yuk ^^ .. sounds like a condition of my mind .. foggy and wont get going . But I did !


[00:08]  * Foskasse Já tenho (sqrt(350)-0.7082869*cos(20)-0.4192478) ANOS!
[00:08]  * Foskasse Happy birthday to me guys!!
[01:56] <lifeless> hi
[01:57] <mwhudson> hi lifeless
[01:57] <mwhudson> lifeless: isn't it like 3am for you now?
[01:58] <lifeless> 4
[01:58] <bob2> ep?
[01:58] <lifeless> GYADEV
[01:58] <mwhudson> lifeless: eurg
[01:58] <Odd_Bloke> lifeless: Ah, are you at GUADEC?
[01:59] <Odd_Bloke> I'll take 'GYADEV' as a 'yes'. :p
[02:00] <lifeless> yes
[02:00] <lifeless> Currently jetlagging; and waking up jamesh
[02:00] <mwhudson> lifeless: just woke up, or still awake?
[02:01] <lifeless> just woke \
[02:02] <lifeless> poolie: on NEWS (420MB corpus), bit of a pathological case perhaps:
[02:02] <lifeless> gaip it all: 136MB
[02:02] <lifeless> bzip it : 36MB
[02:02] <poolie> hello lifeless
[02:02] <lifeless> our knit hunks in bzr.dev: 4.5MB
[02:02] <poolie> did you mean gzip?
[02:03] <lifeless> 7zip(lzma) the 420MB as one file ccatted together - 215KB
[02:03] <lifeless> poolie: yes
[02:04] <lifeless> git repacking at 200,200 638KB
[02:04] <bob2> how about rzip?
[02:04] <lifeless> my first attempt with my new compressor: 600KB
[02:04] <lifeless> bob2: dunno
[02:05] <lifeless> and its outputting some really badly chosen sequences thanks to sequence matcher
[02:09] <lifeless> lp:~lifeless/+junk/bzr-groupcompress
[02:12] <Odd_Bloke> A gnome-terminal extension that made those clickable would be awesome.
[02:21] <poolie> lifeless: nice
[02:22] <poolie> or an irc bot that expands them to http url
[02:31] <mwhudson> can i rename a thread in a loom?
[02:31] <lifeless> mwhudson: there is a bug, I would love a ptch
[02:31] <lifeless> mwhudson: it includs the workaround
[02:32] <lifeless> call to prayer has just starter
[02:34] <mwhudson> lifeless: i can't find the bug, although https://bugs.edge.launchpad.net/bzr-loom/+bug/203287 and https://bugs.edge.launchpad.net/bzr-loom/+bug/203203 are relevant to what i'm trying to do
[02:35] <lifeless> mwhudson: basically make a new thread called newname and delete oldname
[02:35] <mwhudson> lifeless: but i want to create a new bottom thread
[02:35] <lifeless> mwhudson: you want to rename the bottom thread?
[02:35] <mwhudson> lifeless: yeah
[02:35] <lifeless> so do what I said
[02:36] <mwhudson> well, i just started again, the loom was about 10s old
[02:36] <lifeless> mwhudson: switch bottom && create-thread foo && swtich bottom && combine-thread
[02:37] <mwhudson> lifeless: ah right
[03:23] <lifeless> wooo
[03:23] <lifeless> new version;
[03:24] <lifeless> 360181
[03:25] <lifeless> and 0.5 seconds to get it back
[03:25] <lifeless> which is 0.03 seconds slower than bzr.dev
[03:27] <lifeless> pushing now, trying to sleep again
[03:28] <Odd_Bloke> lifeless: Sleep well!
[05:08] <alecwh> I'm trying to push to a repository, and I'm getting this error: bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ephpns-team/phpns/head/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
[05:08] <alecwh> the command I used: "bzr push lp:phpns"
[05:08] <mwhudson> bzr launchpad-login
[05:09] <alecwh> No Launchpad user ID configured.
[05:09] <alecwh> How do I fix this?
[05:10] <bob2> bzr launchpad-login yourlaunchpadusername
[05:11] <alecwh> mwhudson: bob2: Thanks a bunch, that worked!
[05:46]  * arjenAU prods igc
[06:17] <lifeless> poolie: how is stacking landing going?
[06:29] <stewart> i'm having an issue. bzr serve using recent 1.6 tree on linux, trying to "bzr branch" from the server on a Windows XP install of 1.5 and getting "Could not understand response from smart server: ('error', ",module' object has no attribute 'SmartServerRepositoryStreamRevisionsChunked'')
[06:37] <spiv> stewart: hmm, sounds like a bug.  1.5 is the version on the server?
[06:37] <poolie> hello lifeless, i'm debugging the anotate failures atm
[06:37] <poolie> arjenAU: he's sick today i think
[06:37] <stewart> spiv: no, 1.5 is client.
[06:37] <poolie> or away anyhow
[06:37] <arjenAU> poolie: he's awake and talking to me anyway ;-)
[06:37] <spiv> stewart: ah, hmm.  I'll just take a look
[06:37] <arjenAU> poolie: but tnx
[06:37] <stewart> spiv: i'm pulling latest dev tree for server now, i'll see if that helps.
[06:38] <spiv> stewart: I see the bug, and it's still in bzr.dev
[06:38] <spiv> stewart: I'll just send a patch to fix it, thanks for the report!
[06:38] <stewart> spiv: cool. easy fix by any chance?
[06:39] <stewart> spiv: can you cc me on the patch? stewart @ mysql dot com
[06:39] <spiv> Yeah, just deleting some lines from bzrlib/smart/request.py
[06:40] <spiv> (We unimplemented some RPCs in 1.6 as part of the fallout from the VersionedFiles reworking Robert did.  Performance impact should be minimal for pack format repositories.)
[06:40] <spiv> stewart: I'll do that.
[06:42] <stewart> spiv: thanks!
[06:43] <stewart> will try patch as soon as i receive it.
[06:49] <spiv> stewart: sent
[07:25] <arjenAU> stewart: can you be on im?
[07:25] <stewart> arjenAU: yepp... am now
[07:25] <arjenAU> good lad
[07:50] <stewart> spiv: now i'm getting (on client) "Server is too old for streaming pull, reconnecting. (Upgrade the server to Bazaar 1.2 to avoid this)". Is that intentional?
[07:51] <spiv> stewart: heh.  Yes, although that is a bit confusing it's unavoidable I think.
[07:51] <stewart> spiv: well, at least it's doing something now. i'll see how long the branch takes
[07:52] <spiv> stewart: thanks.  Let us know if it takes noticeably longer than having 1.5 on the server.
[07:58] <stewart> spiv: no disk space has been used on client yet :(
[08:03] <spiv> stewart: is that worse than before?  Damn.
[08:04] <stewart> spiv: haven't tried explicitly with 1.5 server... but would have expected quicker.
[08:05] <spiv> You could try "bzr -Dhpss ..." instead of "bzr ..." and looking at the ~/.bzr.log to see what it's doing.
[08:05] <spiv> Hmm...
[08:05] <stewart> spiv: it's a mysql tree, generally, over the internet branching it should take about 20mins. the majority of that being at about full speed of the network link. Now it's transferring something though... but only at up to about 200k/sec
[08:05] <stewart> sometimes bursts...
[08:05] <spiv> If it is dropping back to the <1.2 RPCs, it's probably going to take longer fetch graph data.
[08:07] <spiv> Part of the reason for the protocol changes in 1.6 is so we don't need unnecessary reconnections with mismatched client/server versions in future.
[08:11] <stewart> spiv: at least it's going... but not fast. at least, i'd expect faster considering on local network.
[08:12] <spiv> stewart: yeah, that doesn't sound good.  I think 1.5 is figuring that if the server doesn't support streaming pull, it also doesn't support get_parent_map
[08:13] <stewart> spiv: it's getting data now... but only 82.3MB so far
[08:13] <spiv> Streaming pull shouldn't matter too much with a pack repo, but get_parent_map still does.
[08:13] <spiv> (Especially if the repo hasn't been packed recently)
[08:14] <stewart> spiv: there's 15 pack,s one of which is 550MB
[08:14] <spiv> Some friction is unavoidable when client and server are different versions :/
[08:15] <stewart> spiv: yeah, no doubt. perhaps when 1.6 windows installers are up it'll be better...
[08:16]  * spiv nods
[08:16] <stewart> hopefully branching subsequent branches into the repository is a lot faster
[08:16] <spiv> I think mhammond posted a test 1.6b3 installer to the list.
[08:16] <spiv> Yeah, it should be.
[08:16] <stewart> 113MB now
[08:17] <spiv> Upgrading the client will definitely help, when that becomes possible for you.
[08:18] <stewart> spiv: is this what you meant: http://www.nabble.com/Experimental-1.6b3-windows-binaries-available-td18168374.html
[08:18] <spiv> Right.
[08:25] <AfC> Oh, for the love of...
[08:25] <AfC> Launchpad: The URI scheme "bzr" is not allowed.  Only URIs with the following schemes may be used: bzr+ssh, ftp, http, https, sftp ... This is the external location where the Bazaar branch is hosted.
[08:25] <AfC> (when trying to add a remote branch)
[08:26] <andrea-bs> AfC: you have to use bzr+ssh:// or lp: , not bzr://
[08:27] <AfC> Ridiculous.
[08:29] <stewart> spiv: tried with new version. instead getting "socket.error: (10055, 'No buffer space available')". so this time it doesn't work at all :)
[08:29]  * stewart will try rebooting the windows client vm... it did say to do that in the installer...
[08:29] <spiv> stewart: woah!
[08:30] <stewart> darn non-operating operating systems
[08:30] <spiv> stewart: That's surprising.  I thought we'd squished all those.
[08:30] <spiv> And I wouldn't have expected the changes in 1.6 to cause that.
[08:30] <spiv> stewart: please file a bug with a traceback for that
[08:31] <stewart> spiv: will do.
[08:31] <spiv> stewart: past experience with that error suggests we know what to do about it once we get a traceback :)
[08:31] <stewart> will just double check
[08:48] <stewart> spiv: filed at https://bugs.launchpad.net/bzr/+bug/246180
[08:50] <spiv> stewart: Thanks!
[08:50]  * spiv heads to the shops
[08:50] <stewart> now to go back to 1.5 so i can actually get the source tree there
[09:00] <arjenAU> stewart: funny how your bug ended up here and mine did not. it's #246178 also for bzr
[09:00] <stewart> joy... i just have to swear at windows a lot now...
[09:00] <stewart> gah
[09:26] <mathrick> so, what is the proper way of accessing bzr from non-python languages
[09:28] <beuno> mathrick, one way is using the xmloutput plugin
[09:36] <lifeless> beuno: hiya
[09:37] <beuno> lifeless, evening!
[09:38] <AfC> Ah, Launchpad, crashing my browser. I love it.
[09:41] <siretart> is there an easy (scriptable) way to report the latest revision of the current branch?
[09:41] <siretart> with revid, that is
[09:42] <spiv> bzr revision-info
[09:43] <RAOF> siretart: There was also a recent blog post about incorporating bzr into the build process; there was a bzr command to substitude various branch info in a string.
[09:45] <RAOF> Ah, right.  bzr version-info is what I'm thinking of.
[09:47] <siretart> aah, that's cool. thanks
[10:11] <mathrick> beuno: mhm, and is there some more systematic approach to calling into python from outside
[10:12] <mathrick> ?
[10:13] <beuno> mathrick, well, I suppose that depends on the language, it's bindings, etc
[10:14] <mathrick> beuno: yeah, but how do you bind from, say, C to python?
[10:14] <beuno> mathrick, I wouldn't know  :)
[10:14] <mathrick> particularly I'm interested in common lisp -> python, but C is good enough, I can manage from there
[10:14] <mathrick> beuno: oh
[10:15] <mathrick> so you were just saying without any actual background?
[10:15] <mathrick> I mean, the bindings etc. need to work somehow
[10:15] <mathrick> I guess it's #python time
[10:15] <beuno> mathrick, sounds like something outside of bzr's scope, yes
[10:49] <Odd_Bloke> poolie: We could do with having a chat.  I'm currently pretty much on GMT+7 sleeping patterns, so sometime tomorrow morning for you would be best (as I'm pretty tired and about to head bedwards).
[10:54] <poolie> heh me too :)
[10:55] <poolie> well, not sleep, but go offline
[11:13] <lifeless> spiv: ping
[11:32] <Laibsch> How do I merge two bzr branches?  "bzr branch $branch1;cd $branch1;bzr merge $branch2" tells me that revision $XY is not present in object $YZ
[11:33] <Laibsch> The two branches are unrelated as far as bzr is concerned, there is no common ancestor or something like that
[11:36] <markh> Let's say I made a branch of bzr.dev, made local commits and pushed it to a *new* branch.  What is the fastest way to get a diff against the original branch?
[11:37] <AfC> bzr diff -r ancestor:../path/to/branch
[11:38] <AfC> Can be quite useful
[11:38] <AfC> bzr diff -r branch:../path/to/branch
[11:38] <AfC> on other occasions
[11:38] <markh> ah, cool, thx.  'ancestor' is a special 'keyword'?
[11:38] <AfC> markh: whether that applies to you in your situation I couldn't say
[11:39] <markh> it gives me a clue I didn't have, so gives me something to read up on - thx!
[11:39] <AfC> markh: it's a namespace, yes. Like tag: and the others at
[11:39] <AfC> bzr help revisionspec
[12:12] <Stavros> hmm, bzr 1.5 crashes rather frequently :/
[12:12] <Stavros> is this a known issue?
[12:13] <fredo> Hello!
[12:14] <Peng> Stavros: Um, details?
[12:14] <Peng> Stavros: And, you mean that it exits with a traceback, right?
[12:15] <fredo> Just one question: Is it possible to integrate bzr into a python application? Let's say I want to write a version controlled wiki, can I interface bzr from within my app without calling it on the command line?
[12:15] <Stavros> Peng, yes, it crashed with various errors at least three times in the past two days
[12:15] <Stavros> i'm reporting one of them right now
[12:16] <Peng> Stavros: Good. You should report the others too. :)
[12:16] <Stavros> it just crashes too frequently for comfort, even during commits :/
[12:16] <Stavros> the others were reported already
[12:16] <Peng> fredo: import bzrlib
[12:16] <fredo> Peng: Thanks!
[12:16] <fredo> Where do I find the docs for bzrlib?
[12:16] <Peng> fredo: bzrlib is the entirety of Bazaar. The bzr script is just a simple wrapper that calls into bzrlib.
[12:17] <fredo> Ah, ok. Thanks!
[12:17] <Peng> fredo: Um, there are API docs somewhere. There's also other stuff in doc/ in the source and the website.
[12:17] <fredo> I'll have a look into this.
[12:17] <fredo> Yes, I think I found the API doc.
[12:18] <semslie> quick question about bzr-svn: I have some branches that were checked into subversion via bzr-svn (for the purposes of working with the other members of our team). I've noticed that when those branches are checked out into a new repository then "bzr visualise" doesn't show the branch history, but rather one flat line of history. However it obviously does know about its branch-point, because merging that branch into another will produce the correct history.
[12:19] <jelmer> semslie: It doesn't push the right hand side revisions, though it does know about them
[12:34] <AfC> jelmer: do you have a minute? (pm)
[12:35] <jelmer> AfC, yeah
[12:35] <AfC> k
[12:35] <LarstiQ> stewart: out of interest, which bugs are those?
[12:35] <Peng> Oh, look. I've been having a problem with bzr-svn for a couple days, and I was just abotu to report it, but it works correctly now. :)
[12:35] <LarstiQ> ehm
[12:35] <semslie> jelmer: okay, I think that makes sense with that I'm seeing
[12:35] <LarstiQ> s/stewart/Stavros/
[12:36] <jelmer> semslie: if you pull in the changes from elsewhere (the original bzr branch for example) it will show them
[12:36] <LarstiQ> jelmer: when are you at guadec?
[12:37] <jelmer> LarstiQ: didn't make it
[12:38] <semslie> jelmer: the situation is that a work mate is getting interested in all the bazaar activity and gave it a try. The visualisation tool gives a tangible sense of the activity that has been taking place on the bazaar side, so he was a bit disappointed not to see it straight away.
[12:38] <LarstiQ> jelmer: hokay
[12:38] <LarstiQ> jelmer: I have a free bed here at EP ;)
[12:40] <Peng> Cool, bzr-svn is importing tags now too. :)
[12:42] <jelmer> semslie: see also bug 158883
[12:42] <jelmer> LarstiQ: :-)
[12:44] <semslie> jelmer: nice to see its on the list. what are the challenges in pushing non-lhs revisions?
[12:45] <jelmer> semslie: They can't be pushed to the same location as the lhs revisions
[12:45] <jelmer> semslie: Since they don't have the same ancestry
[12:46] <jelmer> semslie: So they have to be pushed to /branches/foo
[12:47] <semslie> jelmer: so is it not just a case of storing metadata about the non-lhs revisions? I've noticed that if I made the branch in my bazaar repo, then push to svn, then check out again into the same repo then I see all the threads of activity.
[13:00] <jelmer> semslie: metadata about what the non-lhs revisions are is already stored
[13:00] <jelmer> semslie: the revisions themselves are just not stored
[13:00] <jelmer> semslie: You'll see that if you run "bzr log --show-ids" the non-lhs revisions are mentioned
[13:04] <semslie> jelmer: oh right, that makes sense and would explain why you then see those revisions as soon as they become available
[13:57] <jelmer> beuno, ping
[13:57] <jelmer> semslie: Yep
[13:57] <beuno> jelmer, pong
[13:59] <jelmer> beuno: bzr-upload was rejected due to faulty upload
[14:00] <beuno> jelmer, hrm, so the DD uploaded wrong?  or was it an issue with the packaging?
[14:01] <jelmer> beuno: It was uploaded incorrectly
[14:02] <beuno> jelmer, ugh, I'll ping the DD and nag then, sorry
[14:02] <jelmer> beuno: No worries, the sponsoring is much appreciated :-)
[14:03] <lifeless> Jc2k: ping
[14:03] <Jc2k> lifeless: pong
[14:05] <lifeless> Jc2k: so, JFDI huh? thought thats what we were doing :).
[14:06] <Jc2k> lifeless: they dont know that yet
[14:07] <Jc2k> i mean, we still need to jfdi for the supporting stack
[14:07] <Jc2k> wrong words
[14:07] <Jc2k> we need to fix bkors stuff :)
[14:07] <lifeless> Jc2k: totally; thought I get the impression hes given it a go and it just worked :)
[14:07] <lifeless> Jc2k: e.g. bonsai -> bzr-search :)
[14:08] <Jc2k> eh
[14:08] <lifeless> s/thought/though
[14:09]  * Jc2k looks forward to "Bazaar JFDI" post :)
[14:09] <lifeless> we need the precommit hooks trasnscribed
[14:10] <Jc2k> where are you guys at?
[14:10] <Jc2k> have retreated to hotel to hack for a bit
[14:10] <lifeless> I'm in the vcafeteria getting power
[14:10] <lifeless> the evolution talk was interesting
[14:15] <Jc2k> ahh i think i'd already left
[14:15] <Jc2k> DVCS DVCS Swag taxi hacking :)
[14:16] <lifeless> Jc2k: :)
[14:16] <lifeless> Jc2k: you're at the golden horn ?
[14:17] <Jc2k> lifeless: about 5 minutes away at hotel aslan
[14:18] <lifeless> in sultanahmet
[14:18] <siretart> is there a shortcut for 'bzr revert file -r"the branch I'm merging from"'?
[14:18] <siretart> in case of conflicts, that is
[14:19] <Peng> siretart: You can use the .OTHER file.
[14:19] <james_w> siretart: "mv file.OTHER file" ?
[14:19] <james_w> siretart: but other than that I don't think so (e.g. if you have resolved the file, or there weren't conflicts in the first place)
[14:19] <lifeless> Jc2k: cool
[14:23] <siretart> james_w: Peng: that doesn't resolve the 'conflited' state
[14:24] <Peng> siretart: Yeah, then you need to run bzr resolved $file.
[14:24] <siretart> Peng: bzr revert doesn't require that. but it is rather clumsy to loop up 'the other' revision id
[14:26] <quicksilver> maybe there shuld be
[14:26] <quicksilver> bzr resolve-other FILE
[14:26] <quicksilver> bzr resolve-this FILE
[14:26] <quicksilver> would be a trivial plugin.
[14:27] <siretart> bzr resolve --other would do it, I think
[14:29] <jelmer> Laibsch, ping
[14:31] <mathrick> jelmer: bzr: ERROR: Repository KnitPackRepository('file:///home/mathrick/Dev/python/.bzr/repository/') is not compatible with repository<EMAIL_ADDRESS>[14:31] <mathrick> which one is compatible?
[14:31] <jelmer> mathrick: bzr upgrade --rich-root-pack
[14:31] <mathrick> aha, thanks
[14:45] <mathrick> jelmer: humm, how do I make the shared svn / bzr checkout?
[14:46] <jelmer> mathrick: How do you mean?
[14:48] <mathrick> jelmer: I want a dir that's both a valid svn working tree and a bzr branch
[14:49] <jelmer> mathrick: You mean something that has both a .bzr and .svn subdirectory ?
[14:50] <jelmer> you need to pass --no-plugins to bypass bzr-svn to do that
[14:51] <mathrick> jelmer: or alternatively, if I bzr commit to an svn working tree, will it do what I want?
[14:52] <jelmer> mathrick: Yes, committing in a svn working tree should work
[14:53] <mathrick> jelmer: good, and what happens if I svn up it behind bzr's back?
[14:54] <jelmer> that will work as well
[14:54] <mathrick> cool
[14:54] <jelmer> the only two things that don't work are merge and revert
[14:54] <mathrick> so bzr ci will be local, and svn will still work?
[14:54] <jelmer> bzr ci won't be local
[14:54] <jelmer> it will upload the changes to subversion
[14:55] <jelmer> (since there is no local branch)
[14:55] <mathrick> oh
[14:55] <jelmer> if you would like to use offline commits, use a bzr branch locally
[14:56] <jelmer> commit to that, and once you're done, "bzr push" into Subversion
[14:57] <mathrick> jelmer: the thing is that I wanted to work on stuff I manage with jhbuild, and which is in an upstream svn repo. So I wanted jhbuild to be able to do its stuff (ie. update the checkout and compile and install things), but have it also backed up by a local branch
[14:57] <mathrick> does it make sense?
[14:58] <mathrick> it would be no problem to have the local bzr branch if it wasn't for the fact that it's the svn working dir the source gets installed from
[14:58] <jelmer> mathrick: How hard would it be to add bzr support to jhbuild?
[14:58] <mathrick> dunno, I think it already does it
[14:59] <mathrick> right, I can just create a local moduleset
[14:59] <mathrick> jelmer: thanks for making me think straigtht :)
[14:59] <jelmer> (-:
[15:10] <Laibsch> jelmer: pong
[15:11] <lifeless> Jc2k: thumper would like to clone your svn update logic
[15:11] <lifeless> Jc2k: can you spare some time to tell him, or jamesh about this?
[15:15] <jelmer> Laibsch, Were you Rolf?
[15:16] <fredp> mathrick: Jc2k has his work on bzr-mirror support for jhbuild; but it is already possible to set bzr as the program to do svn checkout
[15:19] <lifeless> mathrick: also, http://bzr-mirror.gnome.org:8080/jhbuild/trunk/changes
[15:19] <lifeless> mathrick: (you can just pull jhbuild from there using bzr  :)) - hmm, actally remove the :8080, thats only the web viewer
[15:20] <fredp> also don't hesitate to report enhancement requests to jhbuild bugzilla
[15:20] <Laibsch> jelmer: Yes
[15:23] <mathrick> fredp, lifeless: ah, thanks, will look into it
[15:27] <jelmer> Laibsch: I was wondering whether there would be any chance you can try reproducing bug 245763 with a later bzr-svn
[15:28] <Jc2k> lifeless: sure
[15:29] <Laibsch> jelmer: later than 0.4.9-1?  Where to get it for hardy?
[15:29] <Laibsch> well, actually debian sid
[15:29] <Laibsch> this was on a remote machine
[15:29] <jelmer> Laibsch: Debian sid has 0.4.10-2 now
[15:29] <Laibsch> OK, I can try that
[15:30] <Laibsch> once I get a connection ;-)
[15:30] <Laibsch> right now the machine seems to be down
[15:35] <lifeless> Jc2k: we're heading to hotel now; but perhaps you could mail the scripts etc to them?
[16:45] <fredp> is there any tool like cvs2cl or svn2cl, to produce a ChangeLog from bzr history?
[16:45] <fredp> bzr log --log-format=changelog would sure be nice.
[16:46] <jelmer> fredp: there is a plugin that does that I think
[16:46] <jelmer> It's probably listed on the plugin page (http://bazaar-vcs.org/BzrPlugins)
[16:46] <fredp> GNU changelog formatter for bzr log
[16:46] <fredp> nice
[16:47] <fredp> google had a lot of noise
[18:04] <jelmer> Laibsch: no hurry :-)
[18:05] <Laibsch> I'm afraid you might need to remind me
[18:05] <Laibsch> The machine is still down
[18:07] <jelmer> k, will do
[18:07] <CyberSnooP> Hi everyone. Am I supposed to be able to create tags in an bzr svn checkout?
[18:07] <jelmer> CyberSnooP: only when using the 0.4 branch, not in any released version
[18:08] <CyberSnooP> Ah, okay. Spend some time in the wiki, but couldn't find it as a limitation
[18:10] <jelmer> there is an open bug report about it
[18:16] <kdehoff> Hi.  I need to run an odd setup and I'm not sure if it's even possible.
[18:17] <leo2007> is there any convention how to write a log entry when checking in using BZR
[18:17] <jelmer> kdehoff: ?
[18:17] <kdehoff> I'm attempting to set up a set of repositories on an old sun server
[18:18] <CardinalFang> leo2007, for what project?
[18:18] <kdehoff> They need to be accessed from within and outside of a firewall, with HTTP/S being the only transport optin
[18:18] <kdehoff> But the users want to control who can and cannot read and/or write to their files
[18:18] <leo2007> just for general guideline, CardinalFang
[18:19] <kdehoff> From the documentation, it doesn't look promising, but access control isn't really touched on much
[18:20] <CardinalFang> leo2007, generally, make sure your log audience understands what you're doing.
[18:23] <james_w> leo2007: there isn't a general one, but keeping a short first line summary makes for better output with the line log formatter.
[18:24] <jelmer> kdehoff: I think there's indeed not an awful lot at the moment
[18:24] <jelmer> you may be able to use apache access control to some extend but I don't have experience with that
[18:27] <kdehoff> So for the HTTP server, the files are generally served as any other web page?
[18:29] <leo2007> james_w: thanks
[18:30] <jelmer> kdehoff: there are several methods
[18:30] <jelmer> kdehoff: you can use webdav to upload to .bzr/ using the webdav plugin for Bazaar
[18:30] <jelmer> kdehoff: or you can use the smart server which I think relies on mod_python
[18:31] <jelmer> kdehoff: with the webdav plugin you should be able to control who can read/write to a particular branch
[18:31] <jelmer> kdehoff: it wouldn't allow access control within the branch
[18:31] <jelmer> I'm not sure whether something like that is also possible with the smart server, it may well be
[18:32] <jelmer> the smart server will most likely be faster than the webdav plugin
[18:32] <jelmer> also, the smart server works out of the box for all clients whereas webdav would require the clients to install the webdav plugin first
[18:33] <kdehoff> would the apache "user" need write access for the smart server?
[18:33] <jelmer> I think so
[19:28] <Pieter> Jc2k: was the meeting bad?
[20:07] <james_w> hey rockstar. You were after me the other day, sorry I missed you. Was it anything I can still help with?
[20:39] <alf> Hello
[20:41] <alf> I was wondering what is the recommended way of handling trivial changes to a project
[20:43] <alf> eg is it better to have a 'trivial' branch instead of creating a feature branch for each small change
[20:47] <alf> or perhaps commit directly on the trunk?
[20:48] <beuno> alf, a trivial branch sounds fine
[20:48] <beuno> but it's so cheap making branches in a shared repo, I usually just do a branch
[20:52] <alf> beuno, thanks, what about changing the (local branch of) trunk directly (svn style)
[20:53] <beuno> alf, well, that's cheaper I suppose, although for the workflow I have, that doesn't work
[20:53] <beuno> I have a branch of trunk locally
[20:53] <beuno> and pull regularly
[20:53] <beuno> and I don't change it so I don't have to merge
[20:58] <alf> beuno, you mean you don't have to merge with the remote trunk, just push?
[20:59] <beuno> alf, right, I pull a copy locally
[20:59] <beuno> and merge that into other branches
[21:01] <alf> beuno, and when you wang to publish changes you merge them directly to the remote trunk or through the local copy?
[21:02] <beuno> alf, I merge trunk into my feature branch, and push that branch into the mainline
[21:02] <beuno> I basically keep a mirror of trunk locally
[21:07] <alf> beuno, thanks, there are so many ways of using bzr and finding your own way can be a challenge :-)
[21:08] <beuno> alf, yeah, you may even find more then one that fits you well
[21:12] <alf> beuno, perhaps it would be useful if some of the experienced users/developers published their own ways (eg in the bzr wiki) so that newer users can see some alternatives
[21:13] <beuno> alf, there was a thread on the mailing list recently...
[21:13] <beuno> let me dig that up for you
[21:14] <beuno> hrm, can't find it
[21:19] <jelmer> beuno: if you have some time, any chance you can do more bzr-gtk reviewing?
[21:20] <beuno> jelmer, sure, I'll try and do some later tonight
[21:20] <alf> beuno, it's ok, i'll take a look myself and perhaps send an email to the list
[21:20] <jelmer> beuno: Thanks :-) I'll see if I can do that release at the end of the week
[21:21] <alf> beuno, you have been very helpful, thanks
[21:21] <beuno> jelmer, sounds great. I'll still be distracted this week, but hopefully I'll get some time in the hotel
[21:21] <beuno> alf, my pleasure
[21:23] <Verterok> beuno, jelmer: hi
[21:23] <jelmer> Verterok, hi!
[21:23] <beuno> hey Verterok!
[21:24] <Verterok> jelmer: thanks for bb:approve ;)
[21:25] <jelmer> Verterok: You're welcome :-) bzr-svn already uses that functionality if it's present
[21:27] <Verterok> nice! :)
[21:49] <mwhudson> hello
[21:49] <jelmer> mwhudson!
[21:52] <mwhudson> this seems a bit ominous
[21:54] <jelmer> oh noes, that's a dictionary word
[21:54] <jelmer> mwhudson: not to worry, I only filed a few more launchpad-bazaar bugs...
[21:55] <mwhudson> jelmer: oh, ok, i'm sure i'll get round to reading my bugmail folder at some point
[22:02] <mwhudson> jelmer: the most recent one is a duplicate in fact
[22:02] <jelmer> mwhudson: oh, ok. sorry
[22:02] <mwhudson> np


[10:08] <ompaul> is there an account delete button?
[10:15] <ompaul> I'll take that as a no.
[11:26] <geser> wgrant: are some archive.u.c mirrors out of sync?
[11:27] <geser> only <IP_ADDRESS> is out of sync, the others seem to be up-to-date
[11:28] <geser> since 3 days
[11:30] <wgrant> Yeah, cursa seems to be out of sync
[11:30]  * wgrant prods sysadmins
[11:30] <geser> thx
[16:31] <qengho> Hi. I'm trying dput to ppa.launchpad.net, and it sends files, but I get two rejections.  One, when I include the orig.tar.gz file, says that file has been uploaded in the past [true], and can't be uploaded again.  Because I do not have that first otgz file any more, and don't know the hash of that file, and can't make the right .dsc file to upload.
[16:33] <qengho> So, can I find the first tarball or the right checksum to include?
[16:34] <qengho> I've tried anon-ftp, and getting the original filename, but that doesn't seem to exist there now.
[16:46] <qengho> So, this is my question: Can I get a file I uploaded previously?
[17:07] <maxb> qengho: Often, but not always.
[17:08] <maxb> Can you show the name of the PPA, the package and version you're trying to upload?
[17:11] <qengho> maxb: yes.  Do you want it?
[17:14] <qengho> ppa, ~cmiller/chromium-browser-stable-daily
[17:14] <qengho> file I'm trying to build upon, but do not have: chromium-browser_22.0.1229.94~r161065.orig.tar.gz
[17:18] <qengho> And the full package version I'm trying to upload is 22.0.1229.94~r161065-0ubuntu2~cm2
[17:27] <maxb> qengho: It looks like the appropriate .orig.tar.gz is still downloadable if you go "view packages" and select to see all packages not just published ones
[17:28] <qengho> maxb: ah!  So it is!  Thank you.
[17:53] <Marzatha> hi


[01:40] <surferdude> Hi all, I just tried to build Ubuntu 10.10 for my BeagleBoard xM. On the serial console I get a login prompt but I don't know what to type in. Does anyone know what the default is?
[01:50] <surferdude> I'm not even getting any video output on the hdmi port
[03:27] <GrueMaster> It depends on what image you used and what rev board you have.
[03:27] <GrueMaster> surferdude: ^^^
[04:04] <Sp0tter> are there any ebook readers taht run ubuntu?
[04:04] <Sp0tter> (v-ink displays, not tft)
[08:27] <hrw> morning
[08:28] <dex`> g.m.
[09:55] <ranjith> hi all
[10:05] <ranjith> is there only ubuntu netbook for omap4 blaze ..?
[10:05] <ranjith> or is there any noraml ubuntu image avalable for omap4 blaze .?
[10:08] <rsalveti> ranjith: you mean the default ui?
[10:08] <ranjith> yes
[10:08] <rsalveti> you can install whatever ui you want later on
[10:08] <rsalveti> the netbook efl is just the default
[10:09] <ranjith> ok. so that means only the netbook binaries are available for omap4 blaze..
[10:09] <rsalveti> yes
[10:09] <ranjith> but this is not that much different form default one..
[10:09] <rsalveti> it's the only image we're producing for arm
[10:10] <ranjith> so first i have to get the netbook prebuilt image running and then unstall the default ui if required..
[10:10] <rsalveti> yes
[10:10] <ranjith> one more doubt.. is there any reason that there is not arm ubuntu with the default ui ..?
[10:11] <ranjith> because I want to develope some applications that is intended to run in ubuntu running in omap4 blaze ..
[14:06] <ndec> ogra: rsalveti: hi! have you tried already a USB headset on panda?
[14:07] <rsalveti> hm, not yet, but can easily try
[14:07] <rsalveti> let's see
[14:07] <ogra_ac> nope, but it should just work
[14:07] <ndec> ogra: rsalveti: it does not work for me. I can see the the USB driver detects the USB peripheral, and the model (logitech), but PA does not see it.
[14:07] <ogra_ac> weird
[14:08] <ndec> if i compare when I plug the same headset in my laptop I have one extra debug mess in dmesg: usbcore: registered new interface driver snd-usb-audio
[14:08] <ndec> perhaps something broken in the kernel config
[14:08] <ogra_ac> hmm
[14:08]  * ogra_ac checks
[14:08] <ndec> bug USB_AUDIO and SND_USB_AUDIO are set
[14:08] <ogra_ac> ah, crap, my panda isnt booted
[14:08] <ndec> ogra: that can be fixed easily ;-)
[14:09] <ogra_ac> no, i have to go to my office for that ;)
[14:09] <ndec> damn it!
[14:09] <rsalveti> currently I'm on natty, and my logitech usb headset worked fine
[14:10] <rsalveti> let my try on maverick
[14:11] <ogra_ac> hatty hs definitely all the fixes, probably ndec misses one on maverick
[14:11] <rsalveti> just booting maverick
[14:14] <ndec> rsalveti: ogra: well it looks like my panda does not my usb webcam too... crashed the board
[14:15] <ogra_ac> ouch
[14:15] <ogra_ac> that sounds like some more low level problem
[14:16] <rsalveti> ndec: also worked fine
[14:16] <rsalveti> same way as natty
[14:16] <ndec> rsalveti: for sound or cam?
[14:16]  * rsalveti currently listening absolute classic rock radio on rhythmbox
[14:17] <ndec> over wlan?
[14:17] <rsalveti> ndec: sorry, sound
[14:17] <rsalveti> nops, ethernet, but should be fine over wlan
[14:19] <rsalveti> ndec: are you using the default ubuntu kernel for panda?
[14:19] <ndec> rsalveti: ogra: ok. so ASOC detects it. i can see the headset in /proc/asound. so it's something with PA config ;-) since I am using a custom config, that might be the problem...
[14:20] <rsalveti> probably
[14:20] <ndec> rsalveti: no, i am using a more recent kernel with power management ;-)
[14:20] <ogra_ac> aha
[14:20] <ogra_ac> you didnt say that ;)
[14:20] <rsalveti> ndec: cool, is it working fine already?
[14:20] <ogra_ac> changed pulse config will very likely break it
[14:20] <ndec> not too bad.
[14:21] <ndec> you should be able to build from sebjan tree, btw.
[14:21] <ndec> or better, we should push a package in the PPA
[14:21] <rsalveti> true, just need to fine time to do some testing
[14:21] <rsalveti> *find
[14:21] <rsalveti> we should also ask cooloney to help testing this tree
[14:22] <ogra_ac> ndec, cooloney should just shove it into natty
[14:22] <ogra_ac> so we get wider user testing
[14:22] <rsalveti> at least for now it should be fine if we get into natty
[14:22] <ndec> sebjan: ^^^ any thoughts?
[14:22] <rsalveti> later on when we fully tested it we can port it to maverick
[14:23] <ndec> it's .35 based, still.
[14:23] <ndec> but you might be right... let's discuss in the call !
[14:23] <ndec> it will break the ducati stuff.
[14:24] <ogra_ac> oh, that will make robclark cry
[14:24]  * rsalveti runs to get some food before the call
[14:24] <ogra_ac> oh, good idea
[14:25] <ndec> ogra_ac: this is a 4PM call for you ;-) no need for food...
[14:25] <ogra_ac> ndec, i have a 2h release meeting right after it
[14:25] <ndec> ogra: ;-)
[14:25] <ogra_ac> (and then vacation til end of the year) ;)
[14:43] <janimo> ogra, rsalveti is there another call shortly?
[14:44] <Sp0tter> are there any ereaders with the e-ink displays taht work with ubuntu
[14:53] <armin76> Sp0tter: doubt there any armv7 ebooks
[14:53] <Sp0tter> drats
[14:54] <Sp0tter> i just bought a kindle3
[14:54] <Sp0tter> was hoping to do more with it than just read books :(
[14:54] <ogra_ac> armin76, there are
[14:54] <Sp0tter> really just wanted an ssh client
[14:54] <armin76> ogra_ac: examples?
[14:54] <ogra_ac> the nook is v7 based afaik
[14:55] <armin76> Sp0tter: you don't need ubuntu to have an ssh client...debian could do, for example
[14:56] <Sp0tter> yea taht would work fine too
[14:56] <Sp0tter> i don thave an ubuntu preference over debian
[14:56] <Sp0tter> i just figured thisis a good place to ask about linux on devices
[14:57] <armin76> ogra_ac: nookdevs.com/teardown says armv6
[14:57] <ogra_ac> the new one with the color display is supposed to be omap based
[14:57] <Sp0tter> seems to be more interest in the nook than kindle
[14:57] <Sp0tter> for third party devs
[14:57] <Sp0tter> why is that
[14:57]  * ogra_ac wonders why anyone would do anything beyond reading with an ebook reader
[14:58] <Sp0tter> why not?
[14:58] <ogra_ac> for arm development there are cheaper or more powerful systems
[14:58] <Sp0tter> people also hack ebooks to add more fonts and languages
[14:58] <Sp0tter> but if you are going to take your book somewhere, why not take IRC also
[14:59] <ogra_ac> because i usually have my ac100 in my bag anyway ;)
[14:59] <Sp0tter> you said people
[14:59] <Sp0tter> not you
[14:59] <Sp0tter> heh
[14:59] <robclark> ndec / ogra_ac: libdce (and therefore gst-ducati) already works with L24.11 kernel...  if the issue you were worried about breaking ducati was related to kernel migration..
[14:59] <ogra_ac> you said you above ;)
[14:59] <armin76> ogra_ac: right, the nook color is omap3621
[15:01] <ndec> robclark: if you are authorized to release ducati firmware for L24.11 then I should be too ;-)
[15:01] <Sp0tter> ogra_ac: what do you liek about th eAC100 over  a regualr asus EEE netbook
[15:01] <robclark> ndec: you don't need to change the codecs.. the only parts I had to update for L24.9->L24.11 was libdce which is already opensrc ;-)
[15:01] <ogra_ac> Sp0tter, its arm and i can do my development work on it
[15:02] <hrw> Sp0tter: size?
[15:02] <ogra_ac> Sp0tter, beyond that you need to physically compare them
[15:02] <robclark> ndec: and btw, it already has some error recovery/cleanup that the official fw doesn't have ;-)
[15:02] <ogra_ac> ac100 is a quater of the weight and has no moving parts inside
[15:02] <Sp0tter> hrw: are you asking me?
[15:02] <hrw> Sp0tter: ac100 (or efikasb) are ~half of atom netbooks
[15:02] <ogra_ac> its as thin as a folder
[15:03] <ndec> robclark: well, that's because you don't use OMX!
[15:03] <robclark> it does simplify some things, doesn't it ;-)
[15:03] <ndec> robclark: definitely.
[15:06] <Sp0tter> i wodner if its really worth it to get a closed-device like a Kindle to have the e-ink over a regualr screen
[15:06] <Sp0tter> was only $140
[15:08] <hrw> you can always sell it or give as a gift to someone
[15:08] <Sp0tter> thats true
[15:08] <Sp0tter> i think i can return it to amazon in 30 days with no restocking fee also
[15:08] <Sp0tter> supposed to get here on monday
[15:09] <Sp0tter> but i've been getting more skeptical since i ordered it heh
[15:09] <hrw> or you will start to use it
[15:09] <Sp0tter> yea i may love it, i just hate to know it could also use irc
[15:09] <Sp0tter> but it can
[15:09] <Sp0tter> cant
[15:09] <hrw> Sp0tter: eink has slow refresh
[15:10] <hrw> Sp0tter: it you want something for irc and such size then nook color (or other android tablet) would be better
[15:10] <Sp0tter> i want ebook reader first
[15:10] <Sp0tter> then other features second
[15:10] <Sp0tter> i have a good netbook arleady
[15:11] <hrw> netbooks... I have efikasb here and it is good only for light use. even with 2GHz dualcore x86-64 I would prefer to not use this size of device as main one
[15:12] <Sp0tter> my main computer is a 4gh 6 core athlon
[15:12] <Sp0tter> :)
[15:13] <hrw> I am waiting for buldozer cpus
[15:14] <Sp0tter> what's the best android tablet out?
[15:14] <hrw> no idea
[15:14] <ogra_ac> ndec, bug 664431
[15:14] <Sp0tter> why is that AC100 so expensive?
[15:14] <ubot2> Launchpad bug 664431 in qt4-x11 (Ubuntu Natty) (and 3 other projects) "QT on armel is built with NEON by default (affects: 4) (dups: 1) (heat: 44)" [High,Triaged] https://launchpad.net/bugs/664431
[15:14] <Sp0tter> it hoguht the arm based laptops were looking to be cheap
[15:20] <Sp0tter> the kindle3 is $140 + free shipping on aazon, and its going on ebay for $180 shipped
[15:20] <Sp0tter> ebay is retarded.
[15:45] <ogra_ac> ndec, http://cdimage.ubuntu.com/ubuntu-netbook/releases/natty/alpha-1/
[15:45] <rsalveti> cool, can see the link already :-)
[15:45] <rsalveti> there we go, alpha-1 image for panda
[15:46] <rsalveti> ogra_ac: change the topic :-)
[15:46] <ogra_ac> yeah
[15:46] <ogra_ac> :)
[15:47] <rsalveti> ogra_ac: typo: aplha/alpha
[15:48] <ogra_ac> oops
[15:48] <ogra_ac> sorry for the noise
[15:48] <rsalveti> now it's fine :-)
[15:56] <ogra_ac> bug 663642
[15:56] <ubot2> Launchpad bug 663642 in linux-linaro (Ubuntu Maverick) (and 3 other projects) "DVI doesn't work at BeagleBoard xM rev A3 (affects: 1) (heat: 97)" [Undecided,Fix released] https://launchpad.net/bugs/663642
[15:56] <ogra_ac> bug 673509
[15:56] <ubot2> Launchpad bug 673509 in linux (Ubuntu) "Beagleboard-xm chooses a new IP address on each boot (affects: 1) (heat: 176)" [Undecided,Confirmed] https://launchpad.net/bugs/673509
[15:57] <ogra_ac> bug 673504
[15:57] <ubot2> Launchpad bug 673504 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "Pandaboard chooses a new IP address on each boot (affects: 2) (heat: 192)" [High,Fix committed] https://launchpad.net/bugs/673504
[15:57] <ogra_ac> rsalveti, GrueMaster, arent the latter two "fix released" ?
[15:58] <rsalveti> probably, let me check
[15:58] <GrueMaster> I think they were in the .19 release kernel which is still in proposed.
[16:00] <ogra_ac> ok
[16:01] <rsalveti> ogra: the first one, for beagle is not yet released
[16:03] <ogra_ac> yeah, fine then
[16:03] <rsalveti> ogra: for panda is already on proposed, but not at updates yet
[16:03] <ogra_ac> ok
[16:06] <rsalveti> ogra_ac: just to know, were you able to do some work on the alsa-utils update bug?
[16:06] <rsalveti> that got into main accidentally
[16:06] <ogra_ac> rsalveti, nope, not yet
[16:06] <rsalveti> ok, np, just to know
[16:07] <ogra_ac> thats why its still on the release report
[16:07] <ogra_ac> (else i would have moved it from SRU to released)
[16:07] <rsalveti> yeah, that's why I wanted to check with you
[16:07] <rsalveti> ok
[17:34] <LetoThe2nd> xdeb as mentioned in the topic breaks in the command "xdeb -aarmel --only-explicit --apt-source linux-linaro
[17:35] <ogra_ac> LetoThe2nd, -> hrw
[17:37] <LetoThe2nd> hrw: log/messages: http://pastebin.com/Vr9iUt8x
[18:06] <Neko> anyone know how when you get a disk check happening it updates plymouth with a multi-line, progress counter display rather than just the lame plymouth --message stuff I've been using?
[18:07] <Neko> is there a script somewhere in udev or initramfs-tools or something that does this?
[18:21] <hrw> LetoThe2nd: known, fixed in newer versions iirc
[18:21] <hrw> versions of linux-linaro
[18:24] <LetoThe2nd> hrw: ok.. but the same or at least similar errors also occur if i just want to build some relatively simple thing, like screen for example.
[18:50] <LetoThe2nd> hrw: like here, when trying bash.
[20:33] <Neko> asking again anyone know how plymouth is sent the messages from disk checks and so on, with updating percentage and multiple lines of text?
[20:45] <Neko> ohhhh I found it.. it's mountall
[22:43] <GrueMaster> rsalveti: There?
[22:49] <GrueMaster> It would appear that today's image does not have full networking capability.  Unfortunately, I am working with limited testing capabilities while in downtown Portland with the PDX team.
[22:49] <GrueMaster> Had originally planned to work on my blueprint today.  Sigh.
[22:58] <tmzt> got my chroot init program mostly working
[22:59] <tmzt> might be useful for testing with Xephyr I don't know quite yet
[23:00] <tmzt> it doesn't ptrace so it should work with qemu-arm
[23:00] <dcordes> tmzt: hi! sounds good
[23:00] <dcordes> congrats
[23:00] <tmzt> dcordes: oh, and I had to build a new image, did the same instructions and launcher and panel work together perfectly
[23:00] <dcordes> :)
[23:01] <tmzt> yeah, now if it would just launch from the android app like it's supposed to
[23:01] <dcordes> any new hacks we should document in htc linux wiki or in smartphone lp project ?
[23:01] <tmzt> no, didn't need any
[23:01] <dcordes> oh somebody added instructions on how to use adb in ubuntu !
[23:01] <tmzt> I have script that mostly converts an ubuntu-minimal though
[23:01] <tmzt> nice
[23:02] <tmzt> with usb_composite that should work well
[23:02] <dcordes> http://htc-linux.org/wiki/index.php?title=Ubuntu/Leo#ADB
[23:02] <tmzt> adb+ether been waiting since g1 for that
[23:02] <dcordes> could you publish the script ?
[23:02] <tmzt> soon
[23:02] <dcordes> that will be nice
[23:02] <tmzt> have to tweak it a little bit
[23:02] <dcordes> I tried to rootstock ubuntu-desktop recently and failed
[23:03] <dcordes> did you use rootstock for the ubuntu-minimal ?
[23:32] <tmzt> yes
[23:32] <tmzt> just something -s ubuntu-minimal
[23:32] <tmzt> dcordes: I have a vps to put a rootstock builder on, somebody just wrote some download code for us for the downloader


[00:00] <mhall119> davidcalle: mhr3 paste-binned the missing gschema.xml file,I copied that into /usr/share/glib-2.0/schemas/org.compiz.unityshell.gschema.xml and re-ran glib-compile-schemas as root on that directory
[00:01] <davidcalle> mhall119, could you please paste the paste-bin link?
[00:01] <mhall119> http://pastebin.com/e7UEugLi
[00:02] <davidcalle> mhall119, ty
[00:04] <mhall119> np
[00:20] <bschaefer> fg
[00:20] <bschaefer> fg
[00:22] <davidcalle> mhall119, https://plus.google.com/117867558830601601230/posts/A7sAen7HRV7 \o/
[00:23] <bschaefer> opps
[00:23]  * bschaefer keeps killing unity
[01:00]  * mhall119 is purging the staging ppa
[01:00] <mhall119> too unstable atm
[17:21] <bschaefer> MCR1, yup, np. Though its always better to decrease the growth rate of the algorithm rather then  change the linear speed of it :)
[17:31] <MCR1> bschaefer: Do you know how it can be that my launcher can hide while the mousecursor still hovers over it ?
[17:31] <bschaefer> MCR1, yeah, I just fixed a few of those bugs...
[17:32] <bschaefer> if you click on an icon?
[17:32] <bschaefer> or exit scale more?
[17:32] <bschaefer> spread* i think
[17:32] <MCR1> no, if I push to reveal with the mouse and stop moving the mouse once it is revealed
[17:32] <bschaefer> MCR1, yeah it should stay open
[17:33] <bschaefer> MCR1, do you have trunk?
[17:33]  * bschaefer updates trunk
[17:33] <MCR1> yes, but I had that problem before your fixes, so do not worry
[17:33] <MCR1> and still have it
[17:34] <bschaefer> MCR1, hmm so you just reveal the launcher then keep the mouse over it? Then it autohides?
[17:34] <MCR1> maybe it is due to my special config - launcher on autohide, launcher just on main (left) monitor, 3 displays
[17:34] <MCR1> yes exactly
[17:34] <MCR1> bschaefer: There should be a condition added to NEVER hide the launcher if the mouse hovers over it
[17:35] <MCR1> or is there ANY case it should hide then ?
[17:35] <bschaefer> MCR1, hmm I can't reproduce it, but there were some changes added to unity
[17:35] <bschaefer> MCR1, well there was an option added TO autohide when certain actions happened. One was an idle mouse
[17:35] <bschaefer> which I though I removed...
[17:35] <MCR1> bschaefer: The last time I asked nobody could reproduce it either, but it is hunting me all the time ;)
[17:36] <bschaefer> MCR1, hmm it could be a multi monitor problem....hmm Ill have to see if I can reproduce it when I hook my laptop up to a second monitor
[17:37] <MCR1> I also have this problem when just using 2 screens (3rd disabled)
[17:37] <bschaefer> what about 1 screen?
[17:38] <MCR1> i'll try - one moment
[17:40] <MCR1> still working on it - can be a pain to change displays sometimes...
[17:41] <MCR1> have to reboot, brb
[17:42] <MCR1> back
[17:42] <MCR1> this time it worked :)
[17:43] <MCR1> bschaefer: I can reproduce it with one monitor as well
[17:43]  * MCR1 is turning on sticky edges
[17:43] <bschaefer> MCR1, very odd...yeah let me know what config options you have on so I can try to reproduce it
[17:43] <MCR1> does not change anything either
[17:44] <bschaefer> hmm are you on trunk unity?
[17:44] <MCR1> bschaefer: yes, unity staging ppa and compiz ppa, both trunk
[17:44] <bschaefer> cause I swear I literally removed that entire option
[17:44] <bschaefer> MCR1, oo, i don't think my fix has landed in either of those haha
[17:45] <bschaefer> it was just merged this week
[17:45] <bschaefer> ie. bzr branch lp:unity -> is where the fix is at
[17:46] <MCR1> haha
[17:46] <MCR1> no staging should have it then as it rebuilds all the time
[17:46] <MCR1> r2583 is the unity version I have
[17:47]  * bschaefer checks the rev
[17:48] <bschaefer> o
[17:48] <bschaefer> MCR1, well I did not know that haha
[17:48]  * bschaefer doesn't use staging ever
[17:48] <MCR1> and the edges stopped being sticky as I just noticed
[17:48] <MCR1> but the option in displays is still there
[17:49] <bschaefer> MCR1, would you be able to make a video showing the launcher autohide thing?
[17:49] <MCR1> bschaefer: http://imagebin.org/225027 <- the option is still there
[17:49] <MCR1> bschaefer: Don't you trust me ? ;) Yes, I could.
[17:50] <bschaefer> MCR1, I do, I just want to see whats going on :)
[17:50] <bschaefer> MCR1, that is also odd...
[17:50] <bschaefer> MCR1, ill have to test that out later
[17:50]  * MCR1 is launching kazam
[17:50] <bschaefer> gtk-recordmydesktop is pretty good
[17:51] <MCR1> bschaefer: I jsut do not have an youtube account - where should I share the video ?
[17:51] <bschaefer> hmm email me it
[17:51] <bschaefer> umm
[17:56] <MCR1> got it ?
[17:57] <MCR1> bschaefer: ?
[17:57] <bschaefer> MCR1, yup, and odd! It looks like the launcher doesn't detect your mouse...
[17:58] <MCR1> as you saw - if I move it a few pixels to the right it stops autohiding
[17:58] <bschaefer> MCR1, yeah, what resolution do you have?
[17:58] <bschaefer> though that shouldn't matter haha
[17:58] <MCR1> 1920x1200
[17:59] <MCR1> I have another mousepointer as well, but that shouldn't matter either
[17:59] <bschaefer> hmm, that is indeed odd, did you change the size of your icons?
[17:59] <MCR1> nope
[17:59] <bschaefer> wait what? You have 2 mouse pointers?
[18:01] <MCR1> no, but two keyboards and two mice and an individual mousepointer (gfx only) - but this should not matter - after all I am also revealing the launcher with the mouse
[18:01] <MCR1> and all other mouse-detection stuff works as well (corner detections in Compiz for example)
[18:02] <bschaefer> MCR1, well Im not with r2583...let me recompile
[18:03] <MCR1> bschaefer: I bet you won't have this problem - but I have it since I remember
[18:03] <MCR1> so how can this happen code-wise ?
[18:03] <bschaefer> MCR1, well it doesn't think the mouse is on the launcher :)
[18:03] <bschaefer> soooo it autohides
[18:04] <bschaefer> as you can see the launcher icons don't show their tool top
[18:04] <bschaefer> tip
[18:04] <MCR1> they do
[18:04] <MCR1> look at the video again
[18:04] <bschaefer> when it was autohiding right away it wasn't
[18:04] <MCR1> I have demonstrated how I am able to maintain the launcher
[18:04] <bschaefer> yeah let me check...i just broke my ABI with unity sooo I have to recompile
[18:05] <MCR1> I have to move the mouse a few pixels to the right - then it stops autohiding, tooltips work, quicklists work on right click (is not in the video)
[18:06] <bschaefer> MCR1, what im saying is when you had it move far to left and it was autohiding quickly the tooltips didn't show
[18:07] <bschaefer> MCR1, either way, it looks like the launcher thinks the mouse is outside the launcher...
[18:07] <MCR1> bschaefer: I can even make the tooltip show and the launcher still disappears
[18:07] <bschaefer> hmm
[18:07] <bschaefer> well i still can't reproduce it :)
[18:08] <MCR1> bschaefer: If I move the mouse over an icon, but just a few pixels from the edge, the tooltip appears, but the launcher still hides
[18:08] <bschaefer> MCR1, well that shouldn't happen...
[18:09] <MCR1> I guess so (and it is quite annoying as you might imagine)
[18:10] <MCR1> bschaefer: maybe the reveal shadow is over the launcher ?
[18:10] <bschaefer> yes, I would think....well I suppose you could file a bug and maybe someone else could reproduce it
[18:11] <MCR1> and the pointer is detected over the shadow, which is over the launcher ?
[18:11] <bschaefer> MCR1, hmm I don't think the shadow is a window
[18:11] <MCR1> the shadow is a png iirc
[18:12] <bschaefer> well it could be the problem though Im not sure where that is getting drawn in unity
[18:12] <bschaefer> for panel shadow is drawn using OpenGL
[18:13] <bschaefer> which is why I thought that launcher shadow was, which shouldn't cause it to block the mouse...
[18:13] <MCR1> bschaefer: I do not want to steal more of your time, especially because this is just MCR specific and noone seems to be able to reproduce it...
[18:13] <bschaefer> MCR1, yeah, just file a bug :), and link the video
[18:14] <MCR1> although I had this problem on all of my machines with precise as well :(
[18:15] <bschaefer> thats an old problem!
[18:15] <MCR1> bschaefer: The best thing that should happen to the launcher would be an intellihide mode
[18:16] <MCR1> but I do not mean dodge, but intellihide
[18:16] <MCR1> all good launchers/docks have it
[18:16] <MCR1> they just hide if the active window dodges
[18:16] <bschaefer> I think that use to be in...
[18:16]  * bschaefer isn't sure though
[18:16] <MCR1> unity-2d was automatically acting that way as well
[18:17] <MCR1> no it was just dodge
[18:17] <MCR1> which means the launcher hid from every window
[18:18] <MCR1> bschaefer: try docky or cairo dock and set mode to intellihide -> the launcher would be sooo much more useful
[18:18] <MCR1> with this feature
[18:19] <bschaefer> MCR1, hmm yeah it would be nice, but I think any kind of window dodging was shot down
[18:19] <bschaefer> IIRC
[18:19] <MCR1> I do not think this option was discussed (and I almost read the whole bugreport on it)
[18:20] <MCR1> it was just -> give us dodge back
[18:23] <bschaefer> hmm well yeah it would be nice, but the problem your having would still be around
[18:23] <MCR1> yeah sure - it was ot
[18:23] <MCR1> ;)
[18:52] <Debolaz> Meh, Unity still isn't working in vmware.
[18:53] <Debolaz> Screen isnt drawing stuff properly, windows mix into each other, etc.
[20:04] <mhr3> MCR1, btw i think you should read http://psankar.blogspot.cz/2011/03/pre-vs-post-increment-performance.html
[20:10] <MCR1> mhr3: Interesting.
[20:14] <mhr3> MCR1, bottom line with optimizations the two are equivalent for primitive types, for complex types it might still make some difference depending on how smart the compiler is
[20:23] <MCR1> mhr3: Thanks for the summary. In my last merge request I also changed a primitive type to prefix, but in the previous ones (already merged) I just changed non-primitive types AFAIK.
[20:24] <mhr3> MCR1, that's why i dug it out actually :P


[01:08] <amurray> mardy: sure will do
[02:07] <mup> PR snapd#11831 opened: interfaces/mount-observe: Allow read access to /run/mount/utab <Created by alexmurray> <https://github.com/snapcore/snapd/pull/11831>
[02:37] <KenSharp> any idea how to even begin to debug the following?
[02:37] <KenSharp> error: cannot install "vlc": cannot query the store for updates: got unexpected HTTP status code
[02:37] <KenSharp>        408 via POST to "https://api.snapcraft.io/v2/snaps/refresh"
[02:38] <KenSharp> it work for five minutes if I purge all the config files, then craps out again
[02:38] <KenSharp> works* - i can install things for five minutes
[04:26] <KenSharp> if i nuke /var/lib/snapd then i can get it working, but obviously i need to install everything again, which i can't because it simply refuses to work for more than five minutes.
[04:55] <mardy> amurray: hi! Did you cancel the meeting only for John, or for everybody? (it's still in my calendar)
[04:56] <amurray> mardy: oh I thought I had cancelled it for everyone today... I meant to
[04:57] <amurray> ah I see - I thought i had created it but mvo owns it - so all I did was delete it from my own calendar... sigh.
[05:07] <mardy> amurray: np :-)
[05:18] <mborzecki> morning
[05:44] <mardy> mborzecki: hi!
[05:46] <mborzecki> mardy: heya
[07:06] <pstolowski> morning
[08:08] <zyga[m]> good morning
[09:08] <mup> PR snapcraft#3770 opened: extensions: fix gnome run environment <Created by sergio-costas> <https://github.com/snapcore/snapcraft/pull/3770>
[11:49] <mup> PR snapd#11832 opened: interfaces: dynamic loading of kernel modules <Created by mardy> <https://github.com/snapcore/snapd/pull/11832>
[12:09] <mup> PR snapd#11833 opened: secboot, boot: TPM provisioning mode enum, introduce reprovisioning <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/11833>
[14:03] <mup> PR snapcraft#3771 opened: extensions: don't fail during installation <Created by sergio-costas> <https://github.com/snapcore/snapcraft/pull/3771>
[14:04] <mup> PR snapd#11834 opened: o/snapstate: exclude services from refresh app awareness hard running check <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/11834>
[15:55] <mup> PR snapd#11835 opened: many: add debug command to migrate snap homes <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/11835>
[19:58] <mup> PR snapcraft#3770 closed: extensions: fix gnome run environment <Created by sergio-costas> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3770>
[20:03] <mup> PR snapcraft#3761 closed: extensions: Give priority to local environment <Created by sergio-costas> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3761>
[21:24] <mup> PR snapcraft#3766 closed: extensions: prepend and append functions for ENV <Created by sergio-costas> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3766>
[23:39] <mup> PR snapcraft#3768 closed: extensions: Fix install command <Created by sergio-costas> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3768>