[02:47] <calc> has anyone reported yet that the drm-intel-nightly builds are broken?
[02:48] <calc> http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/
[02:49] <calc> it started back up yesterday but the build.log indicates its not finding the git commit for checkout
[08:59] <apw> calc (N,BFTL), seem so indeed, will investigate
[13:48] <Odd_Bloke> I'm running the ubuntu_ecryptfs tests in a pristine VM (using ./runner ubuntu_ecryptfs) and I'm seeing "/bin/bash: make: command not found" for every test it is running.
[13:48] <Odd_Bloke> Is there an expectation that make/build-essential will already be installed, or is the test missing some setup?
[13:52] <cking> Odd_Bloke, i believe build-essential is assumed, but I'm not sure what the ./runner is doing or meant to expect for the minimal install config
[13:53] <cking> Odd_Bloke, if you want to just run the eCryptfs tests, perhaps the following notes are useful: http://smackerelofopinion.blogspot.co.uk/2012/08/testing-ecryptfs.html
[13:55] <Odd_Bloke> cking: I'm working on running the kernel tests on cloud instances, and just chose one at random.  I'll ensure build-essential is installed. :)
[13:56] <cking> Odd_Bloke, have you also considered hammering it to death with stress-ng? http://kernel.ubuntu.com/~cking/stress-ng/
[14:00] <Odd_Bloke> cking: I haven't, but I will now. :)
[14:00] <cking> it can make the vm subsystem cry
[14:37] <bjf> Odd_Bloke, when running the tests i have a separate step for installing all the dependent pkgs
[14:45] <Odd_Bloke> bjf: Cool, noted.  I'm working on tooling around the kernel tests; are there any tests that run particularly quickly (so I can have a quick turn-around while testing Jenkins job wrappers etc.)?
[14:45] <bjf> Odd_Bloke, ubuntu_qrt_kernel_security
[14:53] <Odd_Bloke> Thanks!
[19:20] <cmagina> so, the latest utopic-proposed kernel, 31.43 does not contain any of the stability fixes (specifically the arm64 fix), when can i expect those to land?
[19:20] <cmagina> they all appear to be in the 32.42 tag
[20:01] <infinity> cmagina: 32.42 and 31.43 will be merged into 32.44 (or similar), and the SRU cycle will continue.  This was a single-commit security update that superseded the SRU.
[20:04] <cmagina> infinity: i figured as much, just checking on a possible time table, thanks
[20:28] <mozmck> I would like to build a kernel with the preempt-rt patch and make .debs that would be widely compatible with ubuntu 14.04 systems.  Can I copy the debian and debian.master directories to a mainline kernel that is supported by preempt-rt patches and use that?
[20:28] <mozmck> Or would it be better to use make-kpkg?
[20:29] <mozmck> I would like to have the .config be as close to the same as the ubuntu kernel as I can.
[21:12] <DalekSec> apw: Hello, I'm unsure where to make the proposal, but can you add linux-initramfs-tool as an alt dep in the kernels to "fix" bug 1109029?
[21:42] <apw> DalekSec, that is likely a viable thing to do, though i'd need to discuss the packaging ramifications before one could commit, which series would that affect??
[21:43] <apw> mozmck, we copy in the debian and debian.master from a "close" version when we make mainline builds for this
[21:43] <apw> mozmck, so it hsould be viable
[21:44] <infinity> apw: It's not a particularly useful thing to do, as nothing in userspace has changed, but that also means it's entirely harmless for you to do. :P
[21:44] <DalekSec> apw: Devel (vivid) would make the most sense, and FWIW I stripped out initramfs-tools, added dracut which regenerated the initrds, and rebooted.  Kernel worked.
[21:44] <infinity> (Since any normal Ubuntu system will pretty much be forced to have initramfs-tools, regardless of the kernel's alt dep)
[21:45] <apw> infinity, yeah i assumed this was to allow playing with dracult rather than a plan for us to change any time soon
[21:45] <apw> and that its just vivid seems ok for testing then
[21:45] <DalekSec> infinity: There's not all that much preventing it from functioning, plymouth needs a few things merged from Debian and just some alt deps missing.  I'm going to try in an encrypted LVM soon and see how badly that breaks. :D
[21:47] <infinity> DalekSec: I'm sure it more or less works, but we won't support it.  That's no reason to actively block people using it, however.
[21:47] <DalekSec> infinity: Excatly my thought, glad you agree.
[21:49] <infinity> DalekSec: I will confess, I'll never understand people's obsession with replacing working software with something else, though.  *shrug*
[21:49] <infinity> And, no, "it integrates with systemd" is not an argument, because a full-featured init in your initrd and pivoting back to your initrd because clean shutdowns are "hard" aren't features.
[21:49] <apw> infinity, because "someone" tells their s/w is the one and only way
[21:50] <infinity> apw: Harald hasn't typically had much of an ego about dracut, he and I have had many good talks about the differences between the two.  But it does seem that getting caught up in the systemd vortex has changed how lots of other people see it.
[21:50] <DalekSec> infinity: It's like playing with systemd before it's in Ubuntu.  Do I plan to play with dracut?  Sure.  Would it be interesting to see what one can do with it?  Sure.  Would I put it on a production system?  Heck no.
[21:51] <retabell> apw: will you have a look at 1426113, maybe it was the wrong place where i filled a bug
[21:51] <retabell> ?
[21:53] <apw> bug #1426113
[21:54] <apw> retabell, ? that is a bug i filed, and fixed
[21:54] <retabell> yes, i posted a patch, maybe wrong place..
[21:54] <retabell> check if symlink exist
[21:55] <apw> retabell, ok, that fix got applied separatly when it blew up for me later, whats in the repo now should have the same effective form
[21:57] <infinity> apw: Why does "[ ! foo ] && action" always bug me so much?
[21:57] <apw> retabell, let me know if not, in general when you find a new issue like that a new bug and mentioning it in the old is good
[21:58] <apw> infinity, becuase it is totally vile, but its short
[21:58] <infinity> apw: I know POSIX ignores failure in a pipe like that, so it's fine, but it feels like it's missing the "else".
[21:58] <infinity> apw: Yeah, I prefer the inverted (and shorter) form: "[ foo ] || action"
[21:58] <apw> infinity, i should have done it as a loop with a fully formed if in the thing
[21:59] <apw> then all of us would have been happy ... and i should have made that script read the debian/foo file which has the list in too
[21:59] <apw> and ... life shouldn't suck and it hsould cope with bloody links
[22:00] <infinity> apw: I wasn't at all arguing for readability or verbosity, just a serious OCD issue on my part with a pipe that obviously has a false evaluation in it and *should* fail, if POSIX wasn't broken. :P
[22:00] <retabell> apw ok thx
[22:02] <apw> retabell, thanks for reporting, if we hadn't noticed (because it was so severe) i would have been more appreciative :)
[22:03] <retabell> i think this only happens when build the source with quilt
[22:04] <retabell> rules clean seems to be called twice
[22:05] <apw> retabell, or if you clean your tree twice and make a tarball indeed
[22:05] <retabell> yes
[22:06] <apw> which is how i noticed it, someone here had a proceedure which did so, cleaning, then -S without -nc


[04:24] <Mirv> if a core-dev around, there'd be a trio of simple debian/ changes to ack for CI Train at https://ci-train.ubuntu.com/job/ubuntu-landing-001-2-publish/
[04:25] <Mirv> for signon-plugin-oauth2, the new account-plugin-google comes from account-plugins in the same landing
[04:31] <Mirv> also, ubuntu-app-launch getting cgmanager and newer upstart dependencies: https://ci-train.ubuntu.com/job/ubuntu-landing-013-2-publish/3/artifact/packaging_changes_ubuntu-app-launch_0.4+14.10.20140915.3-0ubuntu1.diff
[04:54] <pitti> Good morning
[06:43] <pitti> infinity: hey, happy birthday!
[06:51] <dholbach> good morning
[06:55] <ion> that
[09:35] <cjwatson> mardy: Could you get https://code.launchpad.net/~cjwatson/signon-ui/pre-0.17-upgrades/+merge/234788 or equivalent into utopic reasonably quickly?  This bug rather disastrously broke my trusty-to-utopic upgrade yesterday (it happened that enough packages were unconfigured that "dpkg --configure -a" gave up, so proceeding required a lot of manual operations; I was able to recover, but most users wouldn't).
[10:16] <pale3> hi, I'm building package wiich has /usr/share/doc/package/html dir with bunch of html,css stuff. I suppose that this isn't required for creating deb pakacge. I there way to prevent installation of this dir
[10:19] <pale3> also one more question, as upstream package versions is 2.0.0.rc.1, what versins shuld I use. Could anyone suggest appropriate notation
[10:20] <pale3> /versins/version
[10:23] <Laney> oops
[10:23] <Laney> @pilot out
[10:35] <mardy> cjwatson: looks good, thanks! I'll try to get it into utopic
[10:46] <cjwatson> mardy: lovely, thanks
[10:46] <cjwatson> pale3: why not just remove it in debian/rules after calling dh_auto_install or similar?
[10:46] <cjwatson> pale3: something like 2.0.0~rc1-1 (where the trailing -1 etc. is the packaging revision) would be usual
[10:50] <pale3> cjwatson: I dind't tested, will this work if i add rm -rf /usr/share/doc/package/html in override_dh_auto?
[10:51] <pale3> cjwatson: thx for versioning suggestion
[10:52] <pale3> i mean override_dh_auto_install
[11:05] <cjwatson> pale3: not /usr/share/doc/package/html!  Remember that that's your system's directory ...
[11:05] <cjwatson> pale3: you want debian/package/usr/share/doc/package/html
[11:05] <pale3> I figgured that I need more work dir, build failes
[11:06] <pale3> cjwatson: thx
[12:05] <shadeslayer> stgraber: ping
[12:05] <shadeslayer> stgraber: lxc question, how do I make a container that I can use with the download template?
[13:06] <ogra_> cjwatson, could we get tcpdump into rtm for debugging purposes ?
[13:11] <cjwatson> ogra_: Sure, copied.  Are you intending to put it on any images?  If so please seed it ...
[13:11] <ogra_> no, just for sergiusens to debug some connectivity stuff
[13:11] <ogra_> we dont need it seeded
[13:11] <shadeslayer> anyone else who's a lxc expert and can advise on how to create downloadable lxc rootfs's?
[13:13] <sergiusens> cjwatson: ogra_ thanks
[14:08] <hallyn> slangasek: of course.  but note that the autoloading for x86 is actually done by the kernel package nawadays.
[14:14] <stgraber> shadeslayer: hey
[14:15] <shadeslayer> stgraber: hi ho, see my question :)
[14:16] <stgraber> shadeslayer: so basically if you want to make your own image, what you need is .tar.xz compressed version of a rootfs where all hostnames have been replaced by LXC_NAME.
[14:16] <shadeslayer> I see
[14:18] <stgraber> shadeslayer: then you need to create a second tarball called meta.tar.xz which contains the following files: build_id (image version string), config (the basic container config), create-message (message displayed post-create, expiry (UNIX EPOCH for cache expiry) and templates (list of files that contain LXC_NAME and need to be sent through sed)
[14:19] <stgraber> shadeslayer: those files are the ones you usually see in /var/cache/lxc/download/...
[14:20] <stgraber> shadeslayer: if you care about unprivileged containers, some of those files will have to be different in that case. You can create a <filename>-user file which will override the main one. e.g. config-user will let you ship a different configuration for unprivileged containers
[14:20] <shadeslayer> oh my, seems a fair amount of work that has no scripts to do it?
[14:21]  * shadeslayer started looking into docker
[14:21] <stgraber> shadeslayer: you can do a local test run by making say /var/cache/lxc/download/test/test/amd64/default, unpacking meta.tar.xz in there and placing rootfs.tar.xz. Then call lxc-create -t download -n blah -- -d test -r test -a amd64
[14:21] <stgraber> shadeslayer: right, we have scripts upstream to generate the public images but I'm not sure how re-usable those would be
[14:22] <stgraber> shadeslayer: if all you care about is shipping containers between machines, your best bet is a big tarball of /var/lib/lxc/<container> and shipping that between hosts for now (we're working on a better workflow and better tooling but that's still at the design stage)
[14:23] <shadeslayer> I see
[14:23] <shadeslayer> stgraber: the thing is, I want to run a arch lxc container on a ubuntu host
[14:23] <shadeslayer> and that is currently impossibru
[14:23] <shadeslayer> because ubuntu doesn't have pacman
[14:23] <shadeslayer> which is what the lxc template uses to bootstrap things
[14:24] <stgraber> ok, so for a one off kind of thing, I'd create an arch VM, install LXC, create a container in there, make a tarball out of it and copy that to an Ubuntu host, call it tpl-arch or something like that and then use lxc-clone to make copies of it
[14:26] <stgraber> a clean solution would be to do the same first steps but then update github.com/lxc/lxc-ci to know about pacman and archlinux, get an initial i386 and amd64 arch container loaded on the CI infrastructure and then use that to bootstrap the creation of daily arch containers on images.linuxcontainers.org
[14:26] <stgraber> we've already done that exact same thing with opensuse (same problem, their package manager wasn't available on Ubuntu)
[14:27] <shadeslayer> hmm
[14:37] <rbasak> infinity: ping, re: mysql
[14:37] <rbasak> infinity: also, some light reading: http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2014-September/007040.html
[14:38] <slangasek> hallyn: sure; and we'd like the autoloading done by the kernel on ppc64el, but no idea when that will get done :)
[14:41] <hallyn> slangasek: so i guess the solution is to move qemu-system-x86.qemu-kvm.upstart to qemu-system-common.qemu-kvm.upstart, and have it check the host arch
[14:42] <hallyn> probably best if we can coordinate with the sysvinit script (i.e. debian)
[14:43] <hallyn> slangasek: would you want this for utopic?
[14:47] <mitya57> ScottK: pyqt5 failed to migrate because of a typo in d/tests/control,
[14:47] <mitya57> can you please upload http://paste.ubuntu.com/8358366/plain/ when you have time?
[14:48] <mitya57> (Or should I just put it into the queue?)
[14:51] <dobey> anyone know how to twiddle BIOS settings via /dev/nvram? or update the BIOS?
[14:52] <dobey> (update it via /dev/nvram that is)
[14:56] <Guest11861> dd if=/dev/nvram of=/path/to/nvram_name_here.bin   ???
[14:57] <Guest11861> dd if=/dev/nvram of=/path/to/nvram_name_here.bin.old   to save it to a file
[14:58] <slangasek> hallyn: eh, currently in utopic the script appears to be called /etc/init.d/qemu-system-x86; I think it's sensible to have a separate script per arch
[14:58] <Guest11861> dd if=/path/to/new_nvram.bin of=/dev/nvram to write to it?
[14:58] <slangasek> hallyn: otherwise you have to go renaming conffiles which is annoying
[14:58] <slangasek> hallyn: and yes, it would be good to have this for utopic :)
[14:58] <Guest11861> dobey :
[14:59] <dobey> Guest11861: i know how to use dd. that doesn't tell me how to do what i need to do exactly though :)
[15:00] <dobey> Guest11861: i need info on the deeper technical bits of it
[15:00] <Guest11861> dobey : define twiddle?
[15:00] <dobey> Guest11861: find a specific setting and change it to a valid value
[15:11] <hallyn> slangasek: that's the init script, but the upstart script is called qemu-kvm (for legacy reasons)
[15:14] <Guest11861> dobey : do you have the memory map? And a hex editor? Or are you looking for an api?
[15:15] <dobey> no i don't have the memory map
[15:15] <dobey> i guess if i did i probably wouldn't be asking, but eh :)
[15:15] <dobey> what i have is a motherboard where i can't see the bios setup screen when i enter it on boot, and no way to upgrade the bios outside of the bios, becuase i don't have windows
[15:16] <Guest11861> throw coreboot onto it?
[15:16] <dobey> and i'm trying to find some way to resolve it or at least fix my video memory allocation, because the default 256MB setting isn't cutting it
[15:16] <dobey> i'd like to avoid breaking my machine in the process though
[15:17] <dobey> anyway, need to get food
[15:17] <slangasek> hallyn: right; see latest bug followup
[15:18] <hallyn> k
[15:18] <hallyn> slangasek: it's not true though
[15:18] <hallyn> we only ship the upstart job
[15:19] <slangasek> hallyn: then you have not cleaned up the init script on upgrade
[15:19] <hallyn> ?
[15:19] <hallyn> you're saying a fresh install now installs both?  (but i installed htis laptop from utopic a month ago)
[15:19] <slangasek> hallyn: I'm saying that I have it on my system, and it belongs to the package
[15:20] <slangasek> the fact that it's not on a fresh install (and the fact that it's listed as an 'obsolete' conffile) confirms that it's not in the current package
[15:20] <hallyn> slangasek: probably from a bug prior to 2.0.0+dfsg-2ubuntu2
[15:20] <slangasek> but the fact that it's still on my system means that the current packaging is buggy and failed to remove it on upgrade
[15:20] <hallyn> slangasek: so yes, the reason i haven't renamed qemu-kvm.conf is bc i'm not sure how to do it reliably in terms of packaging
[15:20] <hallyn> i'd be fine with renaming it to qemu-system-x86.conf
[15:21] <hallyn> (though that's ugly :)
[15:21] <slangasek> well, you could even have qemu-kvm.conf shipped by qemu-system-x86:{amd64,i386} and by qemu-system-ppc:ppc64el, and not by other archs
[15:22] <slangasek> since you wouldn't be installing native versions of those qemu-system-* packages at the same time, the file would just be owned by different packages on each arch
[15:22] <slangasek> not sure if that's more or less sensible than renaming the conffile
[15:23] <hallyn> would that hae to be done through debian/rules then, or can that be done through debian/qemu-system-x86.install?
[15:26] <hallyn> slangasek: so should postinst remove /etc/init.d/qemu-system-x86 (on ubuntu)?
[15:26] <slangasek> hallyn: you should use dpkg-maintscript-helper rm_conffile
[15:27] <hallyn> ok, thx, will post a debdiff before doing anything (first finishing up with libvirt)
[16:03] <slangasek> kees, pitti: TB meeting?
[16:08] <pitti> slangasek: argh, yes, joined
[16:33] <hallyn> mdeslaur: hey.  so virt-install shipping from virt-manager introduces 2 new regressions in qrt's test-libvirt.py.  just curious if you've looked at those yet and already knew how to fix them
[16:33] <hallyn> (one is bc virt-install changed the filename it creates from .img to .qcow 2 :( )
[16:34] <mdeslaur> hallyn: no, sorry, haven't looked at it at all
[16:34] <hallyn> mdeslaur: ok, thanks, just didn't want to be wasting time.  ttyl
[16:34] <mdeslaur> hallyn: cool, thanks
[16:35] <mdeslaur> hallyn: I wasn't expecting a virt-manager upload to break the libvirt test script, so I don't even think I tried it
[16:35] <dobey> oh well, guess i'll have to live without games on pc for a while
[16:36] <hallyn> mdeslaur: heh.  yeah.  ($&%% virt-install.
[16:55] <doko> jamespage,  did the golang packagers stop shipping .a files at all?
[16:55] <jamespage> doko, did they ever?
[16:55] <doko> I thought so, for their first packages ...
[17:01] <shadeslayer> stgraber: got a moment?
[17:02] <stgraber> shadeslayer: in a meeting, should be free in about an hour if you're still around?
[17:03] <shadeslayer> stgraber: works for me, mind putting this to download http://curl.io/get/mhrxqen2/901e295b9b2cd6cc2ee135d83f2147475d68a2db  :P
[17:03] <shadeslayer> so that we can start right away :)_
[17:03] <shadeslayer> ( its the arch lxc container I'm working on )
[17:41] <stgraber> shadeslayer: ok, I'm sort of around for the next 50min
[17:42] <shadeslayer> stgraber: right, so if you have that container downloaded, you want to rename it to : manjaro.tar.gz
[17:42] <shadeslayer> and untar it
[17:42] <shadeslayer> and a config option needs editing in the config file so that it picks up lxcbr0 instead of br0
[17:44] <stgraber> ok
[17:45] <stgraber> so how was that container produced?
[17:45] <shadeslayer> stgraber: via a manjaro ( a arch derivative ) VM
[17:45] <stgraber> ok, on which you installed lxc and created a regular arch container?
[17:45] <shadeslayer> yes
[17:46] <shadeslayer> ( FWIW the error I get on ubuntu when starting the container is : Failed to mount cgroup at /sys/fs/cgroup/systemd: Permission denied )
[17:46] <shadeslayer> oh oh
[17:46] <shadeslayer> running it as a unconfined container makes it work
[17:47] <shadeslayer> though I'm not exactly happy with that
[17:47] <stgraber> systemd in unpriv containers tends to fail pretty badly usually
[17:48] <shadeslayer> oh lol, it also modifies my volume xD
[17:48] <shadeslayer> stgraber: I see, well, networking is still broken
[17:49] <shadeslayer> but atleast it starts, hurray
[17:53] <stgraber> shadeslayer: lxc.aa_profile=unconfined will make it start mostly fine but with the usual downsides that this is terribly unsafe
[17:53] <shadeslayer> stgraber: got a better idea on how to make it work?
[17:54] <stgraber> patch systemd to be less stupid? :)
[17:54] <shadeslayer> :p
[17:54] <stgraber> systemd attemps to mount /sys/fs/cgroup/systemd whether it's already there or not and fails badly if it can't
[17:54] <shadeslayer> something that does not involve me throwing my life into systemd and taking up drinking copious amounts of alcohol
[17:54] <stgraber> allowing a container to mount cgroupfs in that way is a very bad thing because the container can then bypass any limit set on it
[17:55] <shadeslayer> I see
[17:55] <stgraber> well, you can run it with lxc.aa_profile=unconfined and then just never run anything you don't trust in there, assuming you trust those arch binaries to begin with
[17:56] <shadeslayer> heh, this is going to grow into a build system :p
[18:08] <hallyn> mdeslaur: all right i think those are fixed.  /win 26
[18:08] <mdeslaur> hallyn: great
[18:09] <hallyn> though my re-pull didn't show my pushes... hm
[18:10] <hallyn> that's annoying
[18:11] <hallyn> that's better
[18:57] <doko> mlankhorst, new try to build mesa with 3.5?
[19:02] <desrt> can someone help me with installing an ubuntu image on a 2012 n7?
[19:03] <desrt> i know this is unsupported, but really i just want a way to test arm builds of some stuff from time to time by sshing to it
[19:03] <desrt> otherwise, what am i meant to do with this wonderful piece of otherwise-useful canonical-owned hardware?
[19:04] <desrt> (it was working before with a very old OS version on it and i made the mistake of attempting to reflash the newer stuff -- now it's a shiny brick)
[19:28] <slangasek> infinity: commit #6188 on the glibc packaging svn - has this been tested at all as part of a bootstrap build?  Because the 'ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)' check in debian/rules.d/build.mk seems to be the exact opposite of what the cross-toolchain packages are patching this to do
[19:29] <infinity> slangasek: The cross toolchain packages need adjusting (and maybe glibc in response, etc) to these changes being made, that's on my short list.
[19:51] <hallyn> slangasek: arges: do you know the name of the kvm kernel module on ppc64le?
[19:51] <slangasek> hallyn: kvm-hv
[19:51] <hallyn> thx
[19:56] <hallyn> and output of uname -m?
[19:56] <hallyn> slangasek: ^ i'll assume it's precisely "ppc64le" ?
[20:00] <slangasek> hallyn: hum, I can't readily check at the moment, the porter box is down and the other machines I have access to at the moment are hosts running in BE mode
[20:00] <slangasek> smoser: ^^ can you confirm the correct uname -m on ppc64el?
[20:02] <smoser> slangasek, looking
[20:04] <smoser> $ echo "dpkg=$(dpkg --print-architecture) uname_m=$(uname -m)"
[20:04] <smoser> dpkg=ppc64el uname_m=ppc64le
[20:04] <smoser> slangasek, ^
[20:05] <hallyn> smoser: thx
[20:11] <infinity> slangasek: THe porter is down?
[20:15] <infinity> slangasek: Fixed.
[20:20] <slangasek> infinity: ah, you fixeded it?  yay
[20:21] <bdmurray> pitti: Could you have a look at bug 1370230?
[20:25] <infinity> slangasek: ppc64el looked like it had been halted when someone meant to reboot.  powerpc was down too, due to a kernel bug.  I need to see if I can get more traces on that and escalate to benh/antonb.
[20:25] <slangasek> mmk
[20:26] <infinity> It's a bit of a blocker for shutting down our old precise ppc buildds, since the gcc testsuite (at least) can reliably crash the trusty kernel every time. :(
[21:22] <mlankhorst> doko: try x-staging
[21:22] <mlankhorst> doko: I won't try with 10.1 any more, it kept regressing
[21:23] <mlankhorst> erm 10.2
[21:42] <hallyn> slangasek: http://paste.ubuntu.com/8360612/  at least removes the bad old sysvinit file;  it seems like it *should* install the right upstart file on ppc64le
[21:43] <hallyn> (built fine in ppa and tested from there)
[22:14] <infinity> hallyn: Except that it was removing the init script that was a mistake.  Both should exist (but be named the same).
[22:15] <infinity> hallyn: Highly recommend renaming that to /etc/init.d/qemu-kvm in both Debian and Ubuntu and mv_conffileing it, not rm_conffile.
[22:16] <hallyn> infinity: why should both exist?  i thought not too long ago that was not in vogue
[22:16] <hallyn> infinity: but i don't think i can convince mjt to rename it to qemu-kvm
[22:16] <infinity> hallyn: Our "remove all init scripts" fervor was misguided. :P
[22:16] <hallyn> drat
[22:16] <infinity> hallyn: And we went about adding them all back recently, along with an upstart hack that ignores the init script if a same-named upstart job exists.
[22:17] <infinity> hallyn: This allows smaller (or no) deltas with Debian, and a smoother transition to other init systems.
[22:17] <hallyn> infinity: ok, but so in slangasek's case we would have to detect tha tthe files are different, and remove his sysvinit version
[22:17] <hallyn> oh, i gues not
[22:17] <hallyn> i'm being silly
[22:17] <hallyn> ok, lemme ping mjt.  i think i can make a good case
[22:17] <infinity> hallyn: So, either the init script needs to be renamed, or reintroduce it and rename the upstart job.
[22:18] <infinity> hallyn: But I think renamiing the init script is sane, since it's clear what it does (enables kvm for qemu) and you've just made it not arch-specific.
[22:18] <hallyn> right, arch-specific will start to suck soon
[22:21] <infinity> hallyn: For ease of maintenance, I might suggest merging the scripts with branching for different arches, to cut down on duplicate code.
[22:21] <hallyn> yeah i was thinking they'd be more different when i started out
[22:21] <infinity> hallyn: But that's your call.
[22:22] <hallyn> infinity: so then should it just move to qemu-system-common for ease,
[22:23] <hallyn> (then it can just be called qemu-system-common.qemu-kvm.upstart/init/default, instead of renaming something to qemu-system-$arch.qemu-kvm.upstart)
[22:24] <hallyn> course i'm getting a bit sick of moving files between packages
[22:24] <cjwatson> Oh!  I think I just had a brainwave about fixing all the zillion man-db error reports / bugs I get when it's triggered and debconf doesn't work ...
[22:24] <cjwatson> Or at least arranging for some other package to be the victim :-)
[22:25] <infinity> As long as it's not one of my packages, I fully support this.
[22:25] <cjwatson> Dunno.  It'd probably be whichever one next tries to use debconf
[22:26] <infinity> That could be one of my packages. :P
[22:26] <cjwatson> Or maybe it's only broken during triggers for some reason, but anyway, my immediate motivation is "stop reporting errors against man-db" :-P
[22:26] <cjwatson> Maybe they'll end up somewhere where the failure is comprehensible.
[22:34] <cjwatson> And of course it might just be that using debconf in a trigger is unsafe because it runs at points when the relevant perl frontend module is unavailable.
[22:41] <infinity> cjwatson: That would be a fundamental flaw in the whole design, then, since postinsts tend to invoke debconf, and triggers invoke postinsts...
[22:45] <cjwatson> infinity: postinst configure is a superset of postinst triggered, but not the other way around.  So it can be handled.
[22:46] <cjwatson> infinity: http://paste.debian.net/121373/ is what I'm playing with at the moment.
[22:48] <infinity> cjwatson: To be fair, that fix is correct even without triggers being involved.
[22:48] <infinity> cjwatson: deconf-is-not-a-registry and all that.
[22:48] <infinity> (Though, a bit more malleable when it's influencing maintscript behaviour rather than package runtime, I guess)
[22:51] <cjwatson> infinity: It's actually backwards from debconf-is-not-a-registry.
[22:51] <cjwatson> Because it's caching information from debconf in the filesystem, rather than the other way round.  But in this case debconf is the agreed interface, so.
[22:53] <infinity> cjwatson: Hrm, fair point.  Why didn't you just do it as a conffile/semaphore originally, with debconf reading/setting it?
[22:57] <cjwatson> Well, that's what I'm doing now :)
[22:58] <cjwatson> It didn't occur to me that using debconf in this way would be a problem, and then I had a mental block on the proper fix that didn't involve changing the interface.


[00:01] <slangasek> yes; I see that commit, and I'm quite sure the package I sponsored already had no use of 'service' in the init script
[00:01] <mbiebl> slangasek: hallyn asked me for feedback on this commit, and I just tried to provide that
[00:02] <slangasek> ok; it appears these are changes to upstream init scripts that don't correspond to what was included in the package <hmM>
[00:03] <mbiebl> the current cgmanager init script uses /etc/init.d/cgproxy stop from within the cgmanager init script
[00:03] <mbiebl> I don't think that's much better
[00:03] <mbiebl> as said, maybe for sysvinit a single sysv init script is the cleanest solution
[00:07] <mbiebl> hallyn: hm, rm -f $PIDFILE in start)
[00:18] <hallyn> yeah i copied that from libvirt;  probably silly though
[00:22] <hallyn> wont' do harm though
[00:22] <hallyn> slangasek: the changes in the commit are destined for the debian package;  i just wanted some feedbcak before pushing to debian
[00:24] <hallyn> (the only 'service' calls are in removed lines)
[00:30] <hallyn> updated with using --retry.
[00:41] <hallyn> and yeah, i've considered one job;  that may make the most sense.
[01:14] <hallyn> slangasek: pushed new package to mentors;  seems to fix all of the start up bugs (tested here on sid)
[15:44] <saizai> Any ETA on when http://changelogs.ubuntu.com/meta-release-lts will get updated for 14.04.1?
[17:45] <Azendale> https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1315733 is it reasonable to set this back to confirmed? I don't want it to fall through the cracks because it's currently listed as wontfix (even though upstream definitely sounds like the consider it a valid issue and plan on fixing it)
[17:51] <ScottK> Won't fix and invalid aren't the same thing.
[17:52] <ScottK> Once there's an upstream fix available might be a good time to link to the fix in the bug and ask again.
[17:53] <Azendale> ScottK: ok, thanks, will do


[00:09] <philipballew> kdub_, yet music artists still are all about cd's
[00:15] <rww> negronjl: ah, never mind that ubottu PM, I didn't see you'd already been poked about it
[03:07] <MarkDude> Pics from Open Source Convention >> https://picasaweb.google.com/tuxwingsgroup/OSCON2011
[03:18] <philipballew> nice MarkDude !
[03:19] <MarkDude> ty
[03:23] <grantbow> fire! quite an exhibit in a couple of those pics
[03:27] <MarkDude> That was the bigass party
[03:27] <MarkDude> http://marchfourthmarchingband.com/
[03:27] <MarkDude> those peeps were there
[03:28] <MarkDude> and amin Tobin
[05:59] <bkerensa> :D Hi all
[06:04] <philipballew> bkerensa, whats up?
[06:04] <bkerensa> nothing much
[06:04] <bkerensa> how are you?
[06:04] <bkerensa> :D
[06:04] <philipballew> i am great. fellow ubuntu user i see here?
[06:05]  * philipballew hasnt had the pleasure of meeting this person
[06:24] <bkerensa> :D
[06:24] <bkerensa> I live in Oregon but I'm California born
[06:32] <philipballew> oh nice, you part of the orgon loco? bkerensa
[06:52] <bkerensa> Yeah
[06:52] <bkerensa> Team Lead
[07:04]  * MarkDude is soo happy to hear that
[17:43] <kdub_> this wednesday is probably not enough notice to slap together an ubuntu hour, i'd guess...
[17:59] <MarkDude> Jono >> http://www.meetup.com/Community-Manager-Breakfast/events/24906431/
[17:59] <pleia2> tsk, members only
[18:00] <aaditya> "This group's content is available only to members"
[18:00] <aaditya> :(
[18:00] <aaditya> hey MarkDude, pleia2 o/
[18:00] <MarkDude> Hmm, meetup sorta sucks sometimes
[18:00] <pleia2> g'day aaditya :)
[18:00] <aaditya> MarkDude: how was your trip!?
[18:00] <MarkDude> My bad, you have to be approved to do it.
[18:01] <MarkDude> Awesome
[18:01] <aaditya> You back, right?
[18:01] <MarkDude> https://plus.google.com/photos/105095769731159704550/albums/5636077067410952689
[18:01] <MarkDude> Since late Saturday night
[18:02] <MarkDude> This event tonight is open to view- although it cost $10 to go
[18:02] <MarkDude> https://www.mogotix.com/events/1816
[18:02] <pleia2> aaditya: there was a comment at our meeting sunday night that registration for the linuxpicnic wasn't open yet (site says "Expect the RSVP database open in late Spring or early Summer."), any ETA on that?
[18:02] <MarkDude> Community management: what is it, where it's been and where it's going?
[18:03] <aaditya> pleia2: We're meeting this week to discuss that, so I should have some concrete info by the end of this week.
[18:03] <seidos> booooo
[18:03]  * seidos is a ghost
[18:03] <pleia2> aaditya: ok, thanks :)
[18:03] <aaditya> you're welcome. :)
[18:03] <aaditya> MarkDude: so lots of fun was had at OSCON!
[18:04]  * aaditya wishes he could attend.
[18:04] <MarkDude> Bigtime
[18:05]  * MarkDude has a bit of SWAG from there. Mostly Fedora stuff tho ;)
[18:07] <seidos> i wasted 2.99 on some work from home scam, i got screenshots though
[18:07] <seidos> wanted to do some investigating...it's a pretty airtight scheme really
[18:08] <seidos> going to create a blog post
[18:08] <seidos> blah blah blah
[18:58] <kdub> airtight for them?
[21:15] <nhaines> akgraner: \o_
[22:13] <akgraner> nhaines, \o
[22:15] <nhaines> akgraner: been keeping busy?  :)
[22:16] <akgraner> as busy as possible all things considered, but now I am getting back on track...:-)   How are things with you?
[22:19] <nhaines> akgraner: busy, busy.  But doing pretty good!  Even if oneiric did eat my laptop?
[22:21] <nhaines> And by ? I mean !
[22:21] <akgraner> nhaines, well even ocelots need to eat...;-p
[22:22] <akgraner> just kidding  - that stinks when stuff like that happens  - did you recover...
[22:25] <nhaines> akgraner: hehe, nah, that's what my laptop is for, mostly.  So between Ubuntu One and my flash drive I was well prepared.  :D
[22:25] <nhaines> I'm sticking with it until Alpha 3 but I might thunk back to natty.


[00:41] <arrrghhh> hm.  is this a good place to ask about lirc?  I can 'see' the button presses with irw when I run lircd by hand but I can't seem to get it working thru the service/config file...
[00:42] <arrrghhh> I think my hardware.conf isn't right, but I'm not sure how to change it haha
[12:31] <qwebirc62865> Can you watch live tv with this?
[21:13] <qwebirc71019> Hi, I was going to download the Mythbuntu 64bit ISO, but it has a ext of torrent and zsync and the files are very small.  i figured that i neeed another program to d/l them using those files, so I downloaded BitTorrent and uTorrent but they don't seem to install.  so I looked at the zsync and saw that there was a rsync for Windows, but it crashes win I run it.  How do you d/l the ISO for the new 16.04 version?
[21:18] <tgm4883> qwebirc71019: either download via torrent software, or grab it from releases.ubuntu.com
[21:19] <qwebirc71019> thank you for teh help,
[21:20] <qwebirc71019> found it on the releases.ubuntu.com i thought the releases in the folder was a file not a folder, thanks you


[14:59] <cyphermox> o/
[14:59] <sil2100> o/
[14:59] <barry> o/
[15:01] <caribou> o/
[15:01]  * slangasek waves
[15:01] <slangasek> #startmeeting
[15:01] <meetingology> Meeting started Thu Oct  6 15:01:46 2016 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:01] <meetingology> Available commands: action commands idea info link nick
[15:02] <slangasek> [TOPIC] Lightning round
[15:02] <slangasek> $ echo $(shuf -e barry doko bdmurray slangasek caribou infinity sil2100 robru cyphermox pitti tdaitx xnox chiluk mwhudson)
[15:02] <slangasek> doko caribou bdmurray sil2100 slangasek infinity xnox cyphermox chiluk tdaitx mwhudson pitti robru barry
[15:02] <slangasek> doko_: hullo!
[15:02] <barry> win!
[15:03] <doko_> - last week Linaro Connect, Monday bank holiday
[15:03] <doko_>  - cross toolchain updates
[15:03] <xnox> ah
[15:03] <doko_>  - lintian update, makedumpfile for arm64
[15:04] <caribou> doko_: makedumpfile fix is in the upcoming debian pkg
[15:04] <doko_>  - "final" GCC update, seeing timeouts on arm64 with new kernels
[15:04] <doko_> (done)
[15:04] <caribou> Bugfix:
[15:04] <caribou>  /etc/multipath/wwids not updated upon restart (LP: #1621835)
[15:04] <caribou>     Blocked by potential regression with .14 (LP: #1629644)
[15:04] <caribou>  Request to backport rsyslog Xenial to trusty
[15:04] <caribou>     NAK, dependancy problems.
[15:04] <caribou>  Slow SSH login
[15:04] <caribou>     - Could be the same as LP: #1591411
[15:04] <caribou>     - Asked to test sil2100 PPA fix
[15:04] <caribou> Development :
[15:05] <caribou>  Working on a sosreport charm :
[15:05] <caribou>  - Submitted for review & inclusion in the charm store
[15:05] <caribou>  tomsfastpath MIR :
[15:05] <caribou>   - clamav fixed to use 'in package' library
[15:05] <caribou>   - upload blocked on llvm-toolchain-3.6 FTBS
[15:05] <caribou>  makedumpfile not working on kernel 4.8 (LP: #1626269)
[15:05] <caribou>   - Still under investigation, waiting on upstream
[15:05] <caribou>  Working on a sosreport and gtimelog snap
[15:05] <caribou> Misc
[15:05] <caribou>  meeting
[15:05] <caribou> & some makedumpfile work
[15:05] <caribou> ☑ Done
[15:05] <bdmurray> phased-updater changes to look at release pocket for regression comparisons
[15:05] <bdmurray> investigation into LP: #1574193, uploaded SRUs for it
[15:05] <bdmurray> investigation into LP: #1614576, uploaded Y fix for it
[15:05] <bdmurray> uploaded Yakkety, Xenial fix of LP:  #1619188
[15:05] <bdmurray> reported software-properties bug LP: #1630731
[15:05] <bdmurray> bug triage of LP: #1444682
[15:05] <bdmurray> upload update-manager fix for LP: #1629900 to Yakkety
[15:05] <bdmurray> SRU training with rbasak
[15:06] <bdmurray> irc discussion with nuclearbob re upgrade testing
[15:06] <bdmurray> foundations, iso-testing bug triage
[15:06] <sil2100> caribou: yeah, from what people said this fix didn't really work though, will try another one from the proposals in the upstream bug
[15:06] <bdmurray> unattended-upgrades bug triage
[15:06] <bdmurray> ✔ done
[15:06] <caribou> sil2100: ok, keeping an eye on it
[15:06] <sil2100> - Landing team work, silo coordination, preparing landing e-mails
[15:06] <sil2100> - RTM status meetings
[15:06] <sil2100> - xenial arm64: * Reviewing all xenial touch systemd merge requests * Prepare and test lxc-android-config silo with all changes * Poke about upstart getting released * Filling in RT for an arm64 scalingstack node for the custom tarball jenkins * Importing first arm64 frieza custom tarball * Building and importing first systemd enabled touch rootfs image
[15:06] <sil2100> - Fixing xenial i386 builds, yakkety armhf builds
[15:06] <sil2100> - Improve the instrumentation sync scripts to allow remote patch management
[15:06] <sil2100> - More work on the landing-team-tools snap - dealing with some minor issues now
[15:06] <sil2100> - Look into the s390x pyzmq unit test failure, attempt building a workaround
[15:06] <slangasek> caribou: why are you using llvm-toolchain-3.6 instead of llvm-toolchain-3.8?  (I think I saw this question asked on #ubuntu-devel the other day...)
[15:06] <sil2100> - Promote emulator OTA-13 images
[15:07] <sil2100> - Fix small breakage in commitlog generation
[15:07] <sil2100> - Help out with ubuntu-push dead-dependencies removal for MIR
[15:07] <sil2100> - Work on documenting the new landing process for snaps
[15:07] <sil2100> (done)
[15:07] <pitti> sil2100: did I read "emulator"?
[15:07] <caribou> slangasek: higher than 3.6 requires sensible modification of the package & debian is not done yet
[15:07] <sil2100> pitti: yeah, the ubuntu-emulator images ;)
[15:07] <pitti> sil2100: *\o/* !
[15:08] <caribou> slangasek<EMAIL_ADDRESS>[15:09] <slangasek> doko_, xnox: could one of you help caribou with his clamav vs. llvm problem, so we can un-stick this for release?
[15:09] <xnox> ok.
[15:10] <caribou> slangasek: right now, debian has the same problem as they are transitioning to llvm-3.8 and clamav no longer builds there either
[15:11] <slangasek>  * releasey stuff - lots of queue reviews and update_excuses prodding
[15:11] <slangasek>  * finished landing unity8 session on the desktop ISO \o/
[15:11] <slangasek>  * fixed a few unaligned access SIGBUSes on armhf, exposed by the change to launchpad builder config; these cause previously-working packages to FTBFS and sometimes now fail autopkgtests (python-xmp-toolkit) and are reproducible on porter-arm64 but not porter-armhf
[15:11] <slangasek> (done)
[15:11] <slangasek> -infinity
[15:11] <slangasek> xnox:
[15:13] <xnox> fixing bridge_role attribute race in s390-tools (in a silo)
[15:13] <xnox> adding apt-key support to ubuntu-release-upgrader
[15:13] <xnox> merge proposal for archive signing for next series
[15:13] <xnox> upstart review/merge for systemd bridge support
[15:13] <xnox> d-i version stamp fixes for automated testing
[15:13] <xnox> testing zfcpdump kernel for apw
[15:13] <xnox> done
[15:13] <cyphermox> xenial:
[15:13] <cyphermox> - grub2 ipv6 fixes SRU (bug LP: #1229458)
[15:13] <cyphermox> yakkety:
[15:13] <cyphermox> - hw-detect modprobe fix (bug LP: #1602717)
[15:13] <cyphermox> - shim revert to 0.8
[15:13] <cyphermox>   - davmor2 caught a fail there because MokManager.
[15:13] <cyphermox> - d-i respin for shim fix
[15:13] <cyphermox> - open-iscsi autopkgtest debugging
[15:14] <cyphermox> - more open-iscsi autopkgtest debugging
[15:14] <cyphermox> - ppc64el issue partitioning with JFS (bug LP: #1630017)
[15:14] <cyphermox> - sync e2fsprogs for segfault fix (bug LP: #1627608)
[15:14] <cyphermox> - upload ubiquity 16.10.12
[15:14] <cyphermox> - ubiquity kde frontend porting to pyqt5
[15:14] <cyphermox>   - to unbreak the slideshow...
[15:14] <cyphermox> - zomg ubiquity icon and UI fixes
[15:14] <cyphermox> ±other stuff:
[15:14] <cyphermox> - coordinating with juju team
[15:14] <cyphermox> - netcfg hostname magic (bug LP: #1452202)
[15:14] <cyphermox> - review probert PR: read NM leases in networkd format
[15:14] <cyphermox> - review subiquity/probert pull requests
[15:14] <cyphermox> (done)
[15:15] <slangasek> cyphermox: so on the shim revert... best idea I can think of is to rescue the MokManager binary from the original 0.8 package and pass it through.  We still have all the source for it, we just wouldn't use the one we're building because $reasons
[15:15] <cyphermox> slangasek: that was my plan too
[15:15] <cyphermox> no other way about it anyway
[15:15] <cyphermox> just *omg it's still borken*
[15:16] <slangasek> ok
[15:16] <slangasek> chiluk: hi
[15:18] <slangasek> tdaitx is having Internet problems today
[15:18] <slangasek> pitti:
[15:18] <pitti> just a 3-day week (conference days Thu/Fri and national holiday Mon)
[15:18] <pitti> autopkgtest:
[15:18] <pitti> - Debug endless retry loop with broken kernel (#1630578)
[15:18] <pitti> - Fix autopkgtest.u.c. navbar in mobile mode
[15:18] <pitti> - Fix virt-qemu for user/password logins on ttyS0 [ongoing] (#1630963)
[15:19] <pitti> - Investigate and fix missing/hidden test requests
[15:19] <pitti> - Various generalizations for running system-image tests from GitHub, barry's system-image tests are now in place
[15:19] <pitti> distro:
[15:19] <pitti> - cloud-init: Investigate DNS resolution deadlock in early boot (#1629797)
[15:19] <pitti> - glibc: Debug/fix locale-related crash (#1577460)
[15:19] <pitti> - gnome-keyring: Fix dependency loop
[15:19] <pitti> - systemd: Fix the previous security patch for notify assertion (#1628687)
[15:19] <pitti> - systemd, gnome-session: Robustify and simplify run-systemd-session, no shell polling loops any more
[15:19] <pitti> lots of yakkety archive admin/reviews and SRU processing
[15:19] <pitti> 🔚
[15:19] <barry> s/system-image/ubuntu-image
[15:20] <pitti> "project"
[15:20] <slangasek> :)
[15:20] <slangasek> robru:
[15:20] <barry> btw, it works great (modulo hopefully a minor issue) - thanks pitti!  so much better than travis+docker
[15:21] <pitti> robru: haven't forgotten your britney branch review, just swamped; will still get to it this week
[15:22] <slangasek> barry: and now you can use it for testing s390x all-snap images!
[15:22] <barry> \o/
[15:23] <slangasek> barry: no sign of robru, go ahead?
[15:23] <pitti> no nested qemu for s390x yet, needs scalingstack
[15:23] <barry> ubuntu-image: LP: #1617445 (coverage branch)
[15:23] <barry> debuntu: python-pluggy 0.4.0-1; unfutz debian machine; testing gpg-agent/upstart problem this morning
[15:23] <barry> misc: kiwi pycon trip report
[15:23] <barry> ✔ done
[15:23] <slangasek> alrighty
[15:23] <slangasek> any questions?
[15:23] <slangasek> one week to release
[15:23] <slangasek> I think you maybe all know what to do :)
[15:24] <pitti> I think it's time for an early 4.9 kernel!
[15:24] <xnox> AOB: why did she not choose Bernie as VP? Also, only 80 sleeps until Christmas. Regent Street decorations are going up.
[15:24] <barry> pitti: yes, because bisecting kernel failures for 4.8 was so much fun!
[15:25] <pitti> "if it's hard, do it more often"
[15:25] <xnox> i still see a few bugs w.r.t. 4.8 kernel filed for ppc64el....
[15:25] <pitti> barry: "was" → "is"
[15:25] <pitti> also on x86
[15:25] <pitti> https://bugs.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=kernel-4.8
[15:25]  * xnox doesn't use legacy architecutres
[15:25] <barry> awesome
[15:25] <slangasek> xnox: because politics is complicated and political advisors all have their own bias when it comes to deciphering what will win an election :)
[15:25]  * pitti wants to see xnox's s390x phone
[15:25] <cyphermox> xnox: for you legacy == !s390x?
[15:26] <xnox> cyphermox, not made by IBM =)
[15:26] <slangasek> [TOPIC] AOB
[15:26] <slangasek> anything else, for realsies?
[15:26] <cyphermox> you know, people could argue the other way around...
[15:26] <cyphermox> not from me ;)
[15:26] <cyphermox> oh actually
[15:26] <slangasek> Monday is nat hol in the US
[15:26] <pitti> any OMGcritical installer bugs known that are in foundation land?
[15:26] <xnox> perfect timing
[15:26] <cyphermox> also thanksgiving in Canada
[15:26] <xnox> pitti, well just the last minute port from Qt4 to Qt5.
[15:26] <slangasek> oh indeed
[15:27] <slangasek> so a few of us will be snoozing Monday
[15:27] <cyphermox> pitti: other icon stuff
[15:27] <cyphermox> (for ubiquity)
[15:27] <bdmurray> what's the status of bug 1626622?
[15:27] <xnox> are both cyphermox & infinity going to celebrate extended thanksgiving? is that on a thursday?
[15:27] <cyphermox> but I've finished the pyqt5 porting, and the icons I will fix in a bit
[15:27]  * xnox googles when is canadian thanksgiving
[15:27] <cyphermox> monday
[15:27] <xnox> ah monday.
[15:28] <slangasek> yes, Canadian is at a higher latitude, so the harvest comes earlier, therefore it's on a Monday instead of a Thursday
[15:28]  * cyphermox read altitude
[15:28] <xnox> slangasek, right......
[15:29] <bdmurray> xnox: Are you still looking at bug 1611256?
[15:29] <xnox> you could have fooled me
[15:29] <bdmurray> Oh, bug 1626622 seems fixed so don't worry about that.
[15:33] <slangasek> seems like that's everything
[15:34] <slangasek> unless robru or chiluk have anything to add
[15:34] <bdmurray> xnox: Are you still looking at bug 1611256?
[15:34] <chiluk> sorry slangasek.. not much from me this week.. just tracking down kernel bugs.
[15:34] <xnox> bdmurray, no.
[15:35] <bdmurray> xnox: Do you have time to?
[15:35] <slangasek> chiluk: ok
[15:35] <xnox> bdmurray, i really should.
[15:35] <xnox> it was trivial to reproduce, cause my laptop hit it
[15:36] <slangasek> [ACTION] xnox to investigate bug #1611256
[15:36] <meetingology> ACTION: xnox to investigate bug #1611256
[15:36] <slangasek> #endmeeting
[15:36] <meetingology> Meeting ended Thu Oct  6 15:36:39 2016 UTC.
[15:36] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2016/ubuntu-meeting.2016-10-06-15.01.moin.txt
[15:36] <slangasek> thanks :)
[15:37] <pitti> thanks everyone
[15:37] <xnox> lol
[15:38] <barry> o/
[15:38] <caribou> thanks!


[18:32] <tastenheld[m]> Hi again.
[18:32] <tastenheld[m]> Finally installed the ubuntu-studio-meta update without any issues. Works.
[18:32] <tastenheld[m]> But autojack still doesn't start up on boot. I will check further tomorrow
[22:25] <Eickmeyer> tastenheld[m]: With regards to autojack, I'm out of ideas. I suggest reporting the issue to https://github.com/ovenwerks/studio-controls . Although it was originally developed for Ubuntu Studio, it's now an upstream project and I'm not sure what's going on, but that's more likely to be the correct place.


[02:06] <elacheche_anis> o/
[23:53] <AlanD> A woman at a local convenience store had trouble with her XP laptop so I agreed to look at it. The Windows disk couldn't find a bootable hard drive, so I tried Ubuntu. Worked great.
[23:55] <AlanD> I loaded Ubuntu hoping that the XP disk would recognize the hard drive, but I still can't load XP for her. Any ideas as to why Ubuntu works but XP wouldn't
[23:56] <AlanD> I know that Ubuntu is supposed to be better than Microsoft, but this is interesting.
[23:59] <wxl> AlanD: most likely something about the XP install is corrupted. I'd suggest recommending Ubuntu to her but using it to grab all her files off the XP disk.


[23:47] <JPeterson> how do i apply the change after editing /var/spool/cron/crontabs/user manually? (not through crontab -e)
[23:49] <gustav_> JPeterson: sudo service crontab restart
[23:49] <gustav_> JPeterson: Edit with crontab -e. Not manually.
[23:49] <JPeterson> doesnt make a difference
[23:49] <gustav_> What difference? You are doing things without defined behaviour.
[23:50] <JPeterson> so your point is ignorance is bliss?
[23:51] <JPeterson> link me to your stack exchange account
[23:52] <JPeterson> gustav_:
[23:52] <phunyguy> one would think that crontab -e is easier...
[23:52] <phunyguy> why not use it?
[23:53] <JPeterson> gustav_ link me to your stack exchange account because i'm now curious about the insight present in your messages there regarding your opinion about knowing how things work
[23:53] <phunyguy> unless you are editing for a different user?
[23:53] <gustav_> JPeterson: If you want to know how crontab works I suggest you look at the source.
[23:53] <JPeterson> good point, didnt think of that
[23:53] <phunyguy> *sigh*
[23:53] <JPeterson> gustav_: the link
[23:53] <fxhp> Anyone have a decent partman recipe for small device (20G) vms
[23:53] <JPeterson> to your stack exchange account
[23:53] <fxhp> ?
[23:54] <xiaclo> I have a really strange issue with logrotate, for some reason /var/lib/logrotate.status is showing a file as rotated even though it isn't.  Running logrotate manually obviously says it doesn't need rotating, and logrotate -f works as expected.  Any ideas what could be causing it to not rotate or falsely update the status?
[23:55] <JPeterson> gustav_: the link
[23:55] <JPeterson> gustav_: whats your top three reupations on stack exchange?
[23:55] <JPeterson> by site
[23:55] <phunyguy> JPeterson, this probably isn't the place for that
[23:55] <JPeterson> it is now because gustav has spoken
[23:55] <phunyguy> no it isn't.
[23:56] <JPeterson> if speaking its reasonable that there exist a way to determine of knowledge exist
[23:56] <capoderra> question: if the graphics isn't recognized while using a live USB, does that mean it won't work when I install Ubuntu?
[23:56] <k1l_> JPeterson: stop that.
[23:56] <phunyguy> capoderra, depends on the hardware
[23:57] <capoderra> Nvidia GeForce m... i think 330
[23:57] <JPeterson> it's uncalled for to ask for the http://askubuntu.com/ rating for a person that gives a retarded answer?
[23:57] <phunyguy> are you in LiveUSB now?
[23:57] <phunyguy> capoderra, ^^^
[23:57] <capoderra> yes
[23:57] <phunyguy> capoderra, 12.10?
[23:57] <JPeterson> it seems like that opinion would demand a reasoned discussion
[23:57] <k1l_> JPeterson: yes it is. last time now: drop that and stick to the issue or leave the channel
[23:57] <Eth0Z> heya
[23:57] <capoderra> 12.10
[23:57] <phunyguy> JPeterson, it may, but this isn't the place for the discussion.
[23:58] <phunyguy> capoderra, go into software sources via the dash
[23:58] <capoderra> done
[23:58] <phunyguy> then additional drivers tab
[23:58] <phunyguy> see if anything comes up for graphics.
[23:59] <capoderra> Hmm? what additional drives tab?
[23:59] <phunyguy> installation probably wont be possible, but it may tell you that one is available, and if so, you would have working graphics after an install of the OS, then an install of the restricted drivers


[02:32] <rockstar> anyone around for a few reviews?
[03:06] <jamalta> thanks bac
[03:06] <bac> jamalta: np.  sorry i didn't get to it earlier.  (had to go to the movie!)
[03:06] <jamalta> bac: heh no worries, i'm sure there is no rush with a trivial bug like that :)
[03:07] <jamalta> considering the majority of users won't even see that dialog ;)
[03:07] <bac> nope.  good work still.
[03:09] <jamalta> thanks
[09:46] <mrevell> Anyone wanna take a look at a small tour text change branch? https://code.edge.launchpad.net/~matthew.revell/launchpad/tour-commercial-tweak-bug-393348/+merge/17666
[14:04] <jamalta-afk> well, looks like some people didn't like my change :( (bug #509791)
[14:04] <mup> Bug #509791: "sources.changes" is not a well-known term <Soyuz:Triaged by julian-edwards> <https://launchpad.net/bugs/509791>
[14:08] <jamalta> i guess i'll just make the change to "changes file" ...
[14:13] <leonardr> gary, want to start the day off with a quick review?
[14:13] <leonardr> https://code.edge.launchpad.net/~leonardr/lazr.restful/multiversion-rename-params/+merge/17741
[14:14] <gary_poster> leonardr sure
[14:24] <jamalta> could someone approve the change to "changes file" instead of "sources.changes" from bug 509791 so i can push this branch really quick?
[14:24] <mup> Bug #509791: "sources.changes" is not a well-known term <Soyuz:Triaged by julian-edwards> <https://launchpad.net/bugs/509791>
[14:34] <jamalta> bigjools: https://code.edge.launchpad.net/~jamalta/launchpad/changesfile-509791
[14:50] <bigjools> jamalta: looking
[14:51] <jamalta> bigjools: sorry about that, i tried to make sure i used a good term to replace changesfile with :(
[14:52] <bigjools> jamalta: np, easily fixed!
[14:52] <bigjools> approved, thank you, I'll land it shortly
[14:52] <jamalta> bigjools: yeah, specially since i already had a diff with the changes to sources.changes
[14:52] <jamalta> bigjools: thanks! glad to hear this is better :)
[15:09] <gary_poster> leonardr: I'd like to see an example of the typical use of getting a given version of the declarations.  All I see in webservice-declarations is using pop, which doesn't seem likely to be the usual usage.  Is the expectation that you will say special_dict.stack[version_name][name that you want]?
[15:10] <leonardr> gary: no, i'm actually going to be using pop
[15:10] <leonardr> i'm going to create the most recent version, then the version before that, etc
[15:11] <gary_poster> leonardr: oh, huh.  So this is really a very transient data structure
[15:11] <gary_poster> ok
[15:11] <gary_poster> leonardr: the only other comment I've scribbled into the text box so far is that, for the name, VersionedDict makes sense to me, particularly with new approach.  OTOH, BleedThroughDict has the vampire-ish connotations that are so in vogue.
[15:11] <leonardr> VersionedDict is good
[15:12] <gary_poster> leonardr: ok cool.  I'll approve, with that suggestion.
[15:21] <rockstar> EdwinGrubbs, do you mind if I chuck some branches in for review (I have 4 of them).
[15:22] <EdwinGrubbs> rockstar: go for it
[15:28] <rockstar> EdwinGrubbs, https://code.edge.launchpad.net/~rockstar/launchpad/upgrade-job-2.0-changes/+merge/17701
[15:28] <rockstar> https://code.edge.launchpad.net/~rockstar/launchpad/upgrade-ui/+merge/17704
[15:28] <rockstar> https://code.edge.launchpad.net/~rockstar/launchpad/pedantry-round2/+merge/17705
[15:29] <rockstar> https://code.edge.launchpad.net/~rockstar/launchpad/pedantry-round3/+merge/17706
[15:29] <gary_poster> leonardr: approved, with some small comments
[15:36] <leonardr> gary: i may get rid of the class in the future, but who knows--it might get more complicated before this is all over
[15:38] <gary_poster> leonardr: ack, cool
[15:39] <henninge> mrevell: can you please revert lib/lp/translations/browser/product.py in your branch? Ursula is fixing that in hers.
[15:40] <mrevell> henninge, My branch won't pass the test suite if I revert it, though, won't it?
[15:41] <henninge> mrevell: no, they are just warning atm.
[15:41] <mrevell> ah, okay, thanks henninge
[15:43] <henninge> bac: I am not sure now, actually. As sinzui's branch has landed, are import violations still warnings?
[15:43] <sinzui> henninge: There were some that were introduced after I landed my branch
[15:44] <henninge> sinzui: the question is if the test suite will pass if the branch has import violations.
[15:44] <sinzui> yes, that is how we got so many in the first place
[15:45] <sinzui> henninge: there is one import violation in devel:
[15:45] <sinzui> There were 1 imports of names not appearing in the __all__.
[15:45] <sinzui> You should not import IProductSeries from lp.registry.interfaces.product:
[15:45] <sinzui>     lp.translations.browser.product
[15:45] <henninge> sinzui: that's the one we are talking about ... ;-)
[15:45] <EdwinGrubbs> sinzui: do you still need someone to review your needs-linking-bug-507937 branch?
[15:45] <Ursinha> sinzui: I just fixed that, as mrevell
[15:45] <Ursinha> :)
[15:46] <sinzui> EdwinGrubbs: yes please
[15:46] <henninge> mrevell: didn't I review this branch before?
[15:46] <mrevell> henninge, no, this is a new branch
[15:47] <henninge> mrevell: but it also renames a button from Continue to Close. That looks awfully familiar.
[15:47] <henninge> Did you not land the first branch?
[15:48] <mrevell> henninge, Ah, I see. I merged that first branch into this one as I've had trouble getting it through the test suite, but needed the changes there. I'll land that branch and then ask you to review this new one.
[15:49] <henninge> mrevell: you can add that branch as a pre-requisite when creating the mp for the new one and it will create a correct diff.
[15:49] <mrevell> Ah, just a moment then
[16:10] <bac> henninge: yeah, they are still warnings
[16:11] <bac> henninge: but that particular one will be fixed in many branches.
[16:16] <henninge> bac: we weren't sure earlier but is that likely to cause merge conflicts
[16:16] <henninge> ẞ
[16:16] <henninge> ?
[16:16] <henninge> ^
[16:17] <bac> henninge: probably
[16:20] <henninge> so that's why I asked Matt to back it out.
[16:20] <henninge> bac: do you know of a branch that has the fix that is about to land?
[16:21] <bac> henninge: i don't.  it's complicated to try to shepherd through.  perhaps it would be best just to do a simple rs branch to fix it
[16:22] <henninge> bac, I guess that's true. rs=bac?
[16:22] <bac> henninge: sure
[16:22] <bac> it's a two line fix...
[16:24] <henninge> I know ...
[16:28] <henninge> mrevell: so you only show the popup on the dashboard? What about the +translate page?
[16:29] <mrevell> henninge, I'm not sure there's a suitable place for it on the +translate page. What do you think?
[16:30] <henninge> mrevell: have you seen the balloon?
[16:31] <henninge> mrevell: I wonder if we could just put another (not dismissiable) one on top of that "Translating for the first time? Read the tips for new translators."
[16:31] <henninge> for no-karma people.
[16:31] <mrevell> henninge, that'd be ideal. I still don't see the balloon -- where is it on this page, for example? https://translations.edge.launchpad.net/ubuntu/karmic/+source/gfxboot-theme-ubuntu/+pots/bootloader/en_GB/+translate
[16:35] <henninge> mrevell: the en_GB team doesn't have any instructions, either.
[16:36] <henninge> mrevell: see the German version:
[16:36] <henninge> https://translations.edge.launchpad.net/ubuntu/karmic/+source/gfxboot-theme-ubuntu/+pots/bootloader/de/+translate
[16:36] <mrevell> heh, ok
[16:36]  * mrevell looks
[16:37] <mrevell> Ah, yes, that'd be perfect henninge
[16:38] <henninge> mrevell: only I'd not make it dismissible because that requires Javascript.
[16:38] <henninge> mrevell: It is dismissed when people start translating.
[16:38] <mrevell> Sounds good
[16:39] <henninge> cool
[16:39] <henninge> mrevell: BUT
[16:39] <henninge> we do need an UI review for this ...
[16:39] <mrevell> henninge, right
[16:39] <henninge> two stacked balloons, maybe martin does not like that.
[16:40] <henninge> mrevell: I think both ui reviewers (I know of) are unavailable today.
[16:40] <henninge> but there are a few ui* reviewers on the schedule.
[17:10] <intellectronica> EdwinGrubbs: busy review shift, eh?
[17:11] <EdwinGrubbs> intellectronica: it seems like it
[17:11] <intellectronica> EdwinGrubbs: i wanted to ask for another review, but i'll try to see if someone else can do it
[17:16] <intellectronica> deryck: https://code.edge.launchpad.net/~intellectronica/launchpad/patch-in-mailnotification/+merge/17761
[17:17] <EdwinGrubbs> sinzui: is the hotness being updated by triggers yet?
[17:18] <sinzui> I do not know. I do not think that is a issue in my branch
[17:39] <bac> sinzui: i've been reviewing your comments on https://code.edge.launchpad.net/~bac/launchpad/bug-499351-batching-dls/+merge/17492 together with beuno's.  i think i need to have a call after lunch to figure it out.
[17:47] <sinzui> bac: okay
[17:51] <rockstar> EdwinGrubbs, does the topic reflect your review progress?
[17:51] <EdwinGrubbs> rockstar: now it does
[17:52] <rockstar> EdwinGrubbs, okay, thanks.
[18:08] <EdwinGrubbs> Ursinha-nom: do you need someone to review lp:~ursinha/launchpad/bug422056-add-translation-focus?
[18:09] <Ursinha-nom> EdwinGrubbs: yes, please
[18:10] <EdwinGrubbs> rockstar: fyi, your upgrade-ui branch shows zero diff lines on the +activereviews page.
[18:10] <rockstar> EdwinGrubbs, yes, this is why I put the real diff in the comment.
[18:11] <rockstar> EdwinGrubbs, and if you didn't see the comment in the prereq branch, you've already reviewed all the code in the upgrade-ui branch.
[18:11] <rockstar> EdwinGrubbs, it might be some artifact of the pipeline.  I'm not sure.
[18:29] <rockstar> EdwinGrubbs, howgoesit?
[18:29] <EdwinGrubbs> rockstar: I'm working on Ursinha's branch.
[18:30] <rockstar> EdwinGrubbs, ah, okay.
[18:30] <rockstar> EdwinGrubbs, I'll probably be heading to eat something in 30 minutes, so you may want to do the pedantry branches first (they're small).
[18:31] <EdwinGrubbs> rockstar: I'll be getting something to eat soon, too.
[18:31] <rockstar> EdwinGrubbs, great, that works out well then.
[18:32] <rockstar> I also have another branch that I'll probably need to cut in front of adiroiban with, if that's okay.
[18:32] <adiroiban> no hurry from my side :)
[18:35] <rockstar> adiroiban, great, because I kinda do have a hurry on my side.
[18:35] <adiroiban> go, go, go
[18:54] <bac> jamalta: ping
[18:55] <jamalta> bac: hey there
[18:55] <jamalta> or rather
[18:55] <jamalta> pong :)
[18:55] <bac> hi jamalta have you arranged for anyone to land your changes from yesterday?
[18:55]  * jamalta tries to remember which changes from yesterday bac is referring to
[18:55] <jamalta> bigjools said he would land my changes from today
[18:56] <bac> jamalta: the two merge proposals i reviewed for you
[18:56] <jamalta> as for yesterday, let me have a look
[18:56] <jamalta> bac: oh
[18:56] <jamalta> no, i didn't know i was supposed to find someone to land them
[18:56] <bac> jamalta: ah, ok.  yeah it doesn't happy automatically
[18:56] <bac> jamalta: i'll be glad to do it.
[18:56] <jamalta> bac: well i know that! what i meant is that usually whoever approved them took care of landing them
[18:56] <bac> jamalta: it's best if you can remember to either ask the reviewer or someone else
[18:56] <jamalta> bac: thanks! that would be great
[18:57] <jamalta> bac: right, well next time i'll make sure to ask :) thanks
[18:57] <bac> jamalta: i should've asked.
[18:57] <bac> if we both try to remember perhaps one will
[18:57] <jamalta> bac: haha, sounds like a deal
[19:00] <jamalta> well thanks for pointing that out
[19:00] <jamalta> i really appreciate it
[19:00] <EdwinGrubbs> Ursinha: what information do I need to add to make a series translatable?
[19:01] <Ursinha> EdwinGrubbs: you need to add a template so you have what to translate on it
[19:01] <Ursinha> EdwinGrubbs: to be really honest I've tested that by adding it in the tests, with factories
[19:05] <bac> jamalta: can you go to the MPs and set the commit message.  it is the text used when we send it to PQM
[19:05] <bac> https://code.edge.launchpad.net/~jamalta/launchpad/newtag-statement-redundancy/+merge/17670
[19:05] <jamalta> bac: sure thing
[19:05] <jamalta> sorry, forgot to do it for those
[19:07] <jamalta> bac: ok it's changed
[19:07] <bac> thx
[19:11] <Ursinha> danilos: are you there?
[19:11] <Ursinha> or henninge :)
[19:11] <Ursinha> henninge: which scripts need to be run for the imports to be approved in my local instance?
[19:13] <henninge> Ursinha: AFAIK you need to make run_all
[19:13] <henninge> Ursinha: and then
[19:13] <henninge> Ursinha: uploads or bzr imports?
[19:13] <Ursinha> henninge: uploads
[19:14] <EdwinGrubbs> Ursinha: since this came up in the reviewer meeting, I'll ask, did you have a pre-impl call with someone on the translations team.
[19:15] <Ursinha> EdwinGrubbs: yes
[19:16] <henninge> Ursinha: you can approve manually from the queue, unless you wish to try out the gardener
[19:16] <Ursinha> henninge: admin user isn't a rosetta admin?
[19:17] <henninge> Ursinha: and then "cronscripts/rosetta-poimport.py"
[19:17] <Ursinha> henninge: because the Approve option is grayed
[19:17] <henninge> Ursinha: you need to set an import target first.
[19:18] <henninge> Ursinha: edit the entry
[19:19] <henninge> Ursinha: if it's a new template, make up a domain and template name
[19:19] <Ursinha> henninge: now everything makes sense :)
[19:34] <Ursinha> henninge: what must happen for the imports to leave the queue?
[19:35] <Ursinha> henninge: I see they were imported here, and approved, and still on the list
[19:35] <henninge> Ursinha: the gardener will clear them out after a few days.
[19:35] <henninge> Ursinha: same for "Deleted" entries.
[19:35] <Ursinha> henninge: I see
[19:36] <henninge> Ursinha: you do know what the gardener is?
[19:36] <Ursinha> henninge: I presume it's a script that cleans things
[19:37] <henninge> Ursinha: it used to called the "auto approver", it approves and cleans, yes.
[19:37] <henninge> That's why jtv renamed it.
[19:38] <Ursinha> henninge: I see
[19:41] <Ursinha> thanks for the explanation
[19:41] <gary_poster> flacoste or gmb: review https://code.edge.launchpad.net/~gary/launchpad/bzr-builder-symlink/+merge/17774 for testfix?
[19:42] <flacoste> gary_poster: r=me
[19:42] <gary_poster> flacoste: thanks
[19:45] <Ursinha> henninge: merging caused no conflicts :)
[19:45] <henninge> Ursinha: See how smart Bazaar is? ;-)
[19:45] <Ursinha> henninge: hehehe :)
[19:52] <bac> jamalta: your branches have been sent off to ec2.  they will certainly fail when submitted to PQM due to buildbot being in testfix but i'll land them later.
[19:54] <flacoste> bac: testfix mode should be off
[19:54] <flacoste> i just reviewed gary's fix
[19:55] <bac> flacoste: so it'll be a foot race
[19:55] <bac> flacoste: and, sadly, i have a head start
[19:55] <flacoste> bac: i think gary will submit his branch directly to PQM
[19:55] <flacoste> so it should land before yours EC2 tests complete
[19:55] <gary_poster> flacoste, bac, yes
[19:56] <gary_poster> bac, it is in PQM now
[19:56] <bac> flacoste: ah, right, so we go out of testfix as soon as buildbot starts working on it, not finishing?
[19:56] <flacoste> bac: yes
[19:57] <bac> excellent
[19:57] <flacoste> bac: as soon as PQM sees a testfix revision, it considers that the tree is clean
[19:57] <flacoste> optimist algorithm
[19:57] <gary_poster> from flacoste, the optimist :-)
[20:02] <jamalta> bac: ah ok
[20:02] <jamalta> thanks for everything :)
[20:10] <bac> jamalta: np.  you did all the hard work.
[20:12] <jamalta> bac: well, i really appreciate the help and insight :)
[20:13] <jamalta> it's really helping me learn launchpad
[20:24] <bac> adiroiban: thanks for the fix.  i've approved the MP with a two-line change
[20:25] <adiroiban> bac: ok. will you send the branch for testing ? or should I run the full tests?
[20:25] <bac> adiroiban: i will land it for you
[20:25] <bac> adiroiban: just let me know when it is finalized
[20:25] <adiroiban> bac: finalized?
[20:26] <bac> adiroiban: also, i note some of the changes you made introduced trailing whitespace.  if you can remove those it'd be great.
[20:26] <bac> adiroiban: yes, i make one  final code change suggestion
[20:26] <bac> adiroiban: sorry if i'm being unclear
[20:26] <adiroiban> bac: ah. got the email :)
[20:26] <bac> ok
[20:26] <adiroiban> a bit of delay
[20:26] <adiroiban> ok
[20:37] <adiroiban> bac: done. I was thinking that „make lint” can catch such errors
[20:39] <bac> adiroiban: so you have pushed your changes and want me to land it as is?
[20:39] <adiroiban> bac: what are the outstanding problems?
[20:40] <bac> adiroiban: none.  i just got your diff and it looks good
[20:40] <bac> adiroiban: so i will land it as is.  thanks.
[20:41] <adiroiban> thanks for your help and guidance! much appreciated
[20:54] <rockstar> EdwinGrubbs, hi.  Do you have any questions so far?
[20:54] <EdwinGrubbs> rockstar: not yet. sorry I've been slow starting on it.
[20:55] <rockstar> EdwinGrubbs, that's okay, as long as you can get to the branch upgrade ones today.  The pedantry branches can probably get done tomorrow.
[20:57] <EdwinGrubbs> rockstar: so, is BZR_BRANCH_8 the same as 2a?
[20:58] <rockstar> EdwinGrubbs, no, BZR_BRANCH_8 is a branch format.  2a is a repository format.
[20:58] <rockstar> EdwinGrubbs, in a follow up branch, I add BZR_BRANCH_7 to the non-upgradables as well, since BZR_BRANCH_8 is still considered a development format.
[21:02] <rockstar> EdwinGrubbs, also, all these branches will probably land in one final branch together (hopefully today)
[21:14] <EdwinGrubbs> rockstar: I see where BranchUpgradeJob.create() checks upgrade_pending, but I don't see where that attribute is set. Is that in another branch?
[21:15] <rockstar> EdwinGrubbs, which branch are you looking at?
[21:15] <EdwinGrubbs> rockstar: upgrade-job-2.0-changes
[21:16] <rockstar> EdwinGrubbs, it's a property defined in the model code.
[21:22] <EdwinGrubbs> rockstar: Shouldn't lp/code/configure.zcml specify that requestUpgrade() requires launchpad.Edit instead of launchpad.View?
[21:22] <rockstar> EdwinGrubbs, yes, you are right.
[21:23] <rockstar> EdwinGrubbs, also, I'd like to expose that through the API eventually, but exposing jobs in the API right now is a little awkward.
[21:25] <leonardr> gary: given edwin's queue, would you like to review another of my branches?
[21:25] <leonardr> do you have time today?
[21:26] <gary_poster> leonardr: I'll give it a whirl, sure
[21:27] <EdwinGrubbs> rockstar: review sent
[21:28] <rockstar> EdwinGrubbs, cheers! One down, five to go.
[21:28] <rockstar> EdwinGrubbs, I can take adiroiban's review if you'd like.
[21:28] <EdwinGrubbs> rockstar: you make it sound like a drinking game.
[21:28] <EdwinGrubbs> rockstar: I would appreciate it if you take his mp
[21:28] <rockstar> EdwinGrubbs, only when it's Soyuz branches.
[21:31] <rockstar> adiroiban, ping
[21:31] <adiroiban> rockstar: hi
[21:31] <rockstar> adiroiban, why the change to lib/lp/registry/browser/peoplemerge.py
[21:32] <rockstar> Or rather, any of the people-merge stuff.
[21:32] <adiroiban> I messed up something
[21:32] <rockstar> adiroiban, actually, most of this branch looks unrelated to the bug you reference.
[21:34] <adiroiban> hm...somethings get messed durring the devel merge
[21:36] <rockstar> adiroiban, you submitted the merge against db-devel
[21:37] <adiroiban> ah...
[21:37] <adiroiban> true
[21:37] <adiroiban> can I change the MP?
[21:37] <adiroiban> or should I create a new one for lp-devel?
[21:38] <leonardr> gary: https://code.edge.launchpad.net/~leonardr/lazr.restful/operation-removed-in/+merge/17784
[21:38] <gary_poster> leonardr: ack, looking
[21:39] <adiroiban> rockstar: sorry, here is the MP https://code.edge.launchpad.net/~adiroiban/launchpad/bug-359180-take-2/+merge/17785
[21:39] <rockstar> adiroiban, could you please delete the old one then?
[21:39] <gary_poster> leonardr: typo versuibed
[21:39] <adiroiban> done
[21:40] <leonardr> gary: i fixed that but haven't pushed yet
[21:40] <gary_poster> leonardr: cool
[21:40] <adiroiban> the new diff looks ok
[21:40] <rockstar> adiroiban, yes, this looks much better.
[21:40] <rockstar> adiroiban, I'm assuming you talked to someone in translations about this?
[21:41] <adiroiban> rockstar: yes. the big discussion is on the but comments
[21:41] <adiroiban> and this is also the second part of the change
[21:42] <rockstar> adiroiban, line 104 of the patch needs force returns in it.  It is too long.
[21:43] <gary_poster> leonardr: in @call_with(fixed=...), I am not familiar with that kwarg feature.  That means that, when the webservice calls the method, it includes the value as a kwarg (and does not allow a webservice caller to override it)?
[21:43] <adiroiban> rockstar: yes. I don't know why make lint did not catch that error. I'm fixing my MP script to catch such errors
[21:43] <rockstar> adiroiban, it's a pagetest, and lint doesn't look at non-python files for lint.
[21:44] <leonardr> gary: yes, that argument does not show up as part of the named operation's signature
[21:44] <gary_poster> leonardr: got it, thanks
[21:49] <gary_poster> leonardr: approved
[21:50] <leonardr> gary, great
[21:51] <jamalta> i have to admit, that's one rockstar queue
[21:52] <rockstar> jamalta, it's the best kind.
[21:52] <jamalta> rockstar: ;)
[22:02] <EdwinGrubbs> rockstar: it took me a while to find the upgrade link, since I expected it in the action menu for the branch as opposed to thinking about it as editing an attribute. Can you create a screenshot of that and ask beuno about the placement?
[22:02] <rockstar> EdwinGrubbs, well, this isn't the final UI.  I have one more branch that does all the polish, etc. but I need some graphics.
[22:03] <rockstar> EdwinGrubbs, I think the link needs to be much more prominent in these cases, since we REALLY want people to upgrade.  It's possible, however, that we'll be backing out the UI for this before next week's rollout.
[22:03] <EdwinGrubbs> rockstar: yeah, it also seems you would want to encourage users to press the upgrade button but also warn them about what they are about to do on the form.
[22:04] <rockstar> EdwinGrubbs, basically, I want a big button, but big buttons are a no-no now, apparently.  I'm not sure how it's going to happen, but I'm going to leave that until we know the rest of the feature is okay.
[22:05] <rockstar> The plan is to spend today and tomorrow QAing.  If the actual process is good, then the new UI will land as soon as PQM opens back up.
[22:05] <rockstar> (merely because UI work is not release critical)
[22:24] <bac> adiroiban: could you set the commit message on https://code.edge.launchpad.net/~adiroiban/launchpad/bug-340662-take-2/+merge/17598
[22:28] <adiroiban> bac: done
[22:28] <bac> adiroiban: thanks
[22:29] <gary_poster> flacoste: are you available for a pretty quick review of the hack fix for bug 491705, https://code.edge.launchpad.net/~gary/launchpad/bug-491705-hack/+merge/17788 ?
[22:29] <mup> Bug #491705: AttributeError: 'NoneType' object has no attribute 'utf_8_decode' <Launchpad Foundations:In Progress by gary> <https://launchpad.net/bugs/491705>
[22:29] <flacoste> gary_poster: was actually looking at it right now :-)
[22:29] <gary_poster> flacoste: :-) thanks
[22:30] <adiroiban> bac: was the import warning solved on devel?
[22:30] <adiroiban> for IProduct
[22:30] <bac> yes
[22:31] <adiroiban> ok
[22:32] <adiroiban> there is one more thing regarding translations tests.
[22:32] <adiroiban> it looks like they are launched twice
[22:32] <adiroiban> Tests with failures: lib/lp/translations/browser/tests/pofile-views.txt lib/lp/translations/tests/../browser/tests/pofile-views.txt
[22:37] <bac> adiroiban: odd, i haven't seen that before
[22:37] <bac> adiroiban: are those tests failing now?
[22:37] <EdwinGrubbs> rockstar: when registering a new branch, I only see Hosted, Mirrored, and Remote branch types. How does an Imported branch get added?
[22:37] <rockstar> EdwinGrubbs, there's a different flow for import branches.  It's on a link that says "Import a branch"
[22:38] <rockstar> EdwinGrubbs, gnome-terminal/imported is a sample import branch.
[22:40] <EdwinGrubbs> rockstar: is there any reason that a branch such as ~vcs-imports/evolution/main, which has an Imported branch type, but hasn't been imported yet, should not show that link?
[22:40] <rockstar> No, I don't think so.
[22:40] <rockstar> EdwinGrubbs, unless you don't have permission to see the link.
[22:41] <rockstar> EdwinGrubbs, your best bet is to log in as mark.
[22:42] <adiroiban> rockstar: I've fixed all long lines from that file.
[22:42] <rockstar> adiroiban, great, thanks.
[22:42] <adiroiban> bac: ah.. the test are not failing. Is just they are run twice
[22:43] <adiroiban> bac: for testing, I changed a test so that it will fail... and I can see the test is run twice
[22:45] <bac> adiroiban: that's interesting but unrelated to your branch.  perhaps you could open a bug
[22:46] <EdwinGrubbs> rockstar: it's apparently caused by the <tal:has-codeimport condition="branch/code_import"> conditional in branch-import-details.pt. Do you think it would be ok to move it outside that condition?
[22:47] <rockstar> EdwinGrubbs, I don't think.  An import branch shouldn't ever exist without a code_import as well.
[22:47] <rockstar> I just fixed a bug pertaining to that.
[22:47] <rockstar> EdwinGrubbs, so in this case, the sample data sucks.
[22:47] <EdwinGrubbs> rockstar: ok, sounds good. r=me
[22:47] <rockstar> EdwinGrubbs, great, thanks.
[22:48] <EdwinGrubbs> rockstar: do you want me to review pedantry3 or jam-suggested-changes next?
[22:48] <rockstar> EdwinGrubbs, probably the one from jam next, please.
[22:54] <adiroiban> bac: bug filled
[22:55] <adiroiban> rockstar: do I need to set the commit message for this branch ?
[22:55] <bac> adiroiban: great.  your branch is off at ec2 running.  i'll bounce you the email when it comes back.
[22:55] <rockstar> adiroiban, do you need your that branch landed?
[22:55] <adiroiban> rockstar: what do you mean? :)
[22:56] <adiroiban> should I found someone else to land it?
[22:56] <rockstar> adiroiban, my answer to your question is in direct relation to the answer to my question.  If you want it landed, then yes, please set the commit message.
[22:59] <adiroiban> rockstar: :) done :)
[23:12] <EdwinGrubbs> rockstar: I sent the review. I will be afk for a little bit, but I'll be able to look at your reply and the last branch today.
[23:48] <EdwinGrubbs> rockstar: I'm back
[23:53] <rockstar> EdwinGrubbs, looking at your comments now.
[23:55] <EdwinGrubbs> rockstar: btw, I just sent the other review.