=== ValicekB_ is now known as ValicekB
=== StevenK_ is now known as StevenK
=== rjdohnert_ is now known as RobertJdohnert
=== Laney is now known as Guest45203
=== Ursinha-afk is now known as Ursinha
=== _salem is now known as salem_
=== salem_ is now known as _salem
[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
=== buxy_bak is now known as buxy
[06:55] <ion> that
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
=== willcooke_ is now known as willcooke
=== Guest45203 is now known as Laney
=== ochosi_ is now known as ochosi
[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
=== udevbot_ changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== warp10_ is now known as warp10
[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
=== MacSlow is now known as MacSlow|lunch
=== Trewas666 is now known as trewas
=== _salem is now known as salem_
=== MacSlow|lunch is now known as MacSlow
[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?
=== Ursinha is now known as Ursinha-afk
=== salem_ is now known as _salem
[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
=== beuno_ is now known as beuno
=== greyback__ is now known as greyback
=== _salem is now known as salem_
[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
=== Ursinha-afk is now known as Ursinha
[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
=== cyphermox_ is now known as cyphermox
[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?
=== Ursinha is now known as Ursinha-afk
[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?)
=== Ursinha-afk is now known as Ursinha
[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
=== salem_ is now known as _salem
[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?
=== elopio_ is now known as elopio
[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
=== Ursinha is now known as Ursinha-afk
[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.
=== _salem is now known as salem_
=== dholbach__ is now known as dholbach
[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 )
=== Ursinha-afk is now known as Ursinha
=== broder_ is now known as broder
=== roadmr is now known as roadmr_afk
[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
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
=== roadmr_afk is now known as roadmr
=== Ursinha is now known as Ursinha-afk
[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.
=== Ursinha-afk is now known as Ursinha
[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
=== gaspa_ is now known as gaspa
[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:21] <ubottu> bug 1370230 in Apport "apport-retrace has become slower" [Undecided,New] https://launchpad.net/bugs/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. :(
=== salem_ is now known as _salem
[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)
=== kentb is now known as kentb-out
[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.