[02:38] <hallyn> sarnold: jdstrand sadly, i'm getting the qcow corruption you do.  since i'm on a buggy thinkpad i haven't disproven that it's a thinkpad-only bug
[02:38] <sarnold> hallyn: yay?
[02:39] <sarnold> hallyn: sorry it hit you too, but hopefully that'll make recreating it easier..
[02:39] <sarnold> I'd really hope qcow2 is pretty boring and not care about the hardware it's running on; it doesn't feel like a special-enough snowflake to care, you know?
[02:43] <jdstrand> hallyn: I would hope it wasn't thinkpad specific like you said, but yeah, 'yay'?
[02:43] <jdstrand> hallyn: is this on utopic or trusty?
[02:43] <jdstrand> hallyn: I'm on utopic now, but haven't tried 2.1 since I've been needing my VMs lately
[02:48] <hallyn> i'm on utopic
[02:48] <hallyn> unfortunately it's interfering with my attempts to test qemu live migration through libvirt
[02:48] <hallyn> i wasn't (yet) looking to reproduce it :)
[05:51] <Unit193> After the upstart upgrade, the following files are considered obsolete: /etc/X11/Xsession.d/00upstart /etc/X11/Xsession.d/99upstart /etc/cron.daily/upstart /etc/bash_completion.d/upstart /etc/upstart-xsessions
[05:55] <pitti> xnox: I did an initial cleanup of the "uncategorized" ones in http://pad.ubuntu.com/missing-systemd-units
[05:56] <pitti> slangase`, xnox: ^ what Unit193 said: that's what I meant by "needs dpkg-maintscript for migration" (same for conffile questions)
[06:51] <dholbach> good morning
[07:54] <doko> tvoss, please don't close MIR issues in changelog entries
[07:54] <doko> tvoss: lp: #1338587 is incomplete
[07:56] <tvoss> doko, I can get rid of gcovr for the package
[07:57] <tvoss> doko, and I thought all of qt is in main?
[07:57] <doko> tkamppeter, pitti: foo2zjs build-depends on lcms which is in universe. only lcms2 is in main, you need to port to lcms2 if you want to have  foo2zjs built
[07:57] <doko> tvoss, wishfull thinking =)
[07:57] <doko> Mirv, ^^^
[08:09] <Mirv> tvoss: um, why is trust-store using qtquick1-5-dev, nothing we use should be using it?
[08:10] <tvoss> Mirv, just patching it out
[08:10] <Mirv> tvoss: maybe an accidental build dependency?
[08:10] <Mirv> tvoss: ok, thanks!
[08:10] <Mirv> Qt upstream indeed has some funky naming that can cause confusion
[08:10] <tvoss> Mirv, yup
[08:11] <Mirv> ("qtquick1" source package provides "libqtdeclarative" library, while "qtdeclarative" source package provides "libqtquick" and "libqtqml")
[08:12] <Mirv> the explanation is something along the lines that Qt4 also had declarative, so for the version 1 they stuck with that source package name, even though Qt 5 has the new version 2 declarative too
[08:12] <Mirv> s/source package name/library name/. see, the confusion.
[08:13] <tvoss> Mirv, https://code.launchpad.net/~thomas-voss/trust-store/remove-unneeded-build-dependencies/+merge/229907
[08:13] <tvoss> doko, ^
[08:32] <darkxst> pitti, so 214 seems to be working well with both upstart and systemd boot, although I am getting very occasional, races on upstart boot where gdm/X fails to start (pretty sure that has happend on 208 as well though
[08:41] <pitti> darkxst: ah, great to hear!
[08:57] <tkamppeter> doko, pitti, the lcms1 build dependency in foo2zjs is bogus, it actually does not depend on any lcms library (any more). I will remove it.
[09:03] <tkamppeter> doko, pitti, OdYX, has freshly introduced this dependency to the obsolete library, as there was some utility program copied from lcms1 in the source code of foo2zjs. I will ask him whether there is a way he can solve it with lcms2. If we do not get a quick solution I will put up an out-of-sync vesion simply taking the newest upstream source but not changing anything else.
[09:14] <xnox> jdstrand: ping bug #1341083 will you upload that, or shall i?
[09:22] <xnox> ogra_`: do you agree that ubuntu-defaults-nexus7 can be removed? bug #1353922
[09:23] <mlankhorst> xnox: I can't even get it to work on raring or later
[09:23] <ogra_`> xnox, yeah,, burn it with fire
[09:23]  * mlankhorst tried
[09:24] <xnox> excellent, mark it as "ported to systemd by means of removal"
[09:32] <pitti> and *swoosh* gone it is, updated bug
[10:48] <pitti> xnox: very nice, systemd-sysv is now installable in an utopic-proposed chroot (and upstart can be removed)
[10:49] <pitti> xnox: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt still complains about systemd-sysv, so I figure before britney is happy we'll need to fix *all* dependencies to upstart (and we don't actually want that..)
[11:06] <xnox> pitti: hm. but systemd-sysv does declare conflicts and replaces upstart right?
[11:06] <xnox> something is odd, we do know they are not co-installable. and plenty of other packages/providers act the same way.
[11:06] <xnox> pitti: latest upload 208-7ubuntu4 ?
[11:07] <pitti> xnox: no, not replaces: (that would be wrong), just conflicts:
[11:07] <pitti> skipped: systemd (20 <- 270)
[11:07] <pitti>     got: 40+0: i-40
[11:07] <pitti>     * i386: systemd-sysv
[11:08] <pitti> it's not very verbose, but I take it it's complaining about it being uninstallable
[11:08] <pitti> xnox: or perhaps it didn't yet take the new sysvinit into account (that's not yet in _output, as mysql-5.6 is still running)
[11:10] <xnox> wait and see i guess.
[11:40] <cjwatson> pitti: that'll mean it's uninstallable in isolation
[11:40] <cjwatson> when considering release pocket + whatever set of uploads it's considering at that point
[11:42] <pitti> cjwatson: "in isolation" means "just on a debootstrapped env", i. e. just essential+required packages?
[11:42] <xnox> i thought it was just recursive depends
[11:42] <pitti> anyway, seems it's happy now
[11:42] <pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt doesn't have systemd-sysv any more, so it was just lagging behind the sysvinit publication
[11:43] <pitti> final: systemd,sysvinit,trust-store
[11:43] <pitti> all good now and accepted
[11:46] <xnox> \o/
[11:49] <cjwatson> pitti: this is pure dependency analysis, no debootstrap or anything like that
[11:50] <cjwatson> pitti: take release's Packages files, take the set of sources that are being considered, remove all old entries corresponding to those sources, add new entries ditto, see if anything new is uninstallable
[11:50] <cjwatson> or strictly, see if the uninstallable count increases
[12:01] <mpt> ev, do you remember where the usb-creator a.k.a. Startup Disk Creator design spec is? I’ve gone through a dozen wiki pages and haven’t found it
[12:02] <mpt> https://wiki.ubuntu.com/USBInstallationImages has early Ascii art, but I remember doing proper sketches afterward :)
[12:25] <ev> mpt: not sure - I'll dig through my email
[12:30] <tvoss> doko, build-deps are patched out of trust-store
[12:32] <doko> tvoss, great! any update on net-cpp?
[12:32] <tvoss> doko, next on my list
[12:32] <tvoss> doko, but likely not today
[12:34] <xubincs>  #ubuntu-mir
[13:33] <jdstrand> pitti: hey, is there a wiki page on how to change init systems? (testing the ufw change)
[13:33] <jdstrand> xnox: ^
[13:33] <jdstrand> wiki page or similar
[13:34] <pitti> jdstrand: boot with init=/bin/systemd in the grub shell
[13:35] <pitti> jdstrand: there's https://wiki.ubuntu.com/systemd with that too (but slightly out of date)
[13:36] <xnox> jdstrand: init=/lib/systemd/systemd (init=/bin/systemd requires new enough initramfs, thus may fail)
[13:36] <xnox> on kernel boot params.
[13:36] <pitti> right, init=/lib/systemd/systemd has worked since utopic's early days
[13:38] <jdstrand> I have an up to date utopic vm
[13:40] <pitti> jdstrand: yep, that'll do; once booted, check with "systemctl" that you get a lot of output, instead of an error message that you can't connect
[13:41] <pitti> jdstrand: in particular, "systemctl status ufw"
[13:41] <pitti> jdstrand: should look something like http://paste.ubuntu.com/7979840/
[13:42] <tedg> Now that I'm using libmir-client I can't build on powerpc or ppc64el. What's the recommend way of showing that?
[13:42] <tedg> Just list the arch in the control file?
[13:43] <tedg> Can I say "everything that mir builds on" ?
[13:43] <pitti> tedg: kind of, if you build-dep on mir, it will just fail to build on ppc*
[13:43] <pitti> which is fine
[13:48] <xnox> tedg: no need for arch restrictions, just build-deps on things you need. FTBFS are not blockers, regressions in FTBFS across arches are but can be cleaned up by archive admins when intentional.
[13:48] <jdstrand> pitti: oh heh, I guess I need to install systemd :)
[13:48] <xnox> (e.g. previous version build everywhere, new one depends on libmir-client and hence need binaries removed to migrate in britney)
[13:49] <pitti> jdstrand: it's pretty hard to not have it installed..
[13:49] <xnox> jdstrand: =)
[13:49] <pitti> tedg: right, we need to remove the ppc binaries of the previous version, then it'll propagate
[13:49] <pitti> jdstrand: is that a minimal server-like VM or so? on a desktop it's a very firm dependency (since saucy)
[13:51] <jdstrand> pitti: no, full desktop. been upgrading for a while. I was guessing it didn't have it installed-- it didn't come up. still diagnosing
[13:51] <pitti> jdstrand: verify in /proc/cmdline?
[13:52] <jdstrand> I didn't get that far
[13:52] <jdstrand> pitti: I'm just updating /etc/default/grub to have:
[13:52] <jdstrand> GRUB_CMDLINE_LINUX_DEFAULT="init=/lib/systemd/systemd"
[13:53] <jdstrand> then doing 'sudo update-grub'
[13:53] <tedg> pitti, xnox, okay, cool. So how do I request the binaries to be deleted?
[13:53] <jdstrand> huh, weird, it came up this time
[13:53] <pitti> jdstrand: hm, that sounds right; what happened then?
[13:53] <jdstrand> I did install systemd-ui before rebooting
[13:54] <pitti> jdstrand: ah, I never tried -ui
[13:54] <jdstrand> pitti: I missed the early boot-- it was just a blck screen
[13:54] <jdstrand> when I looked
[13:54] <xnox> tedg: you don't have to, unless it's already stuck in proposed-migration.
[13:54] <jdstrand> might be unrelated and a kvm issue
[13:54] <xnox> tedg: what packages are you talking about?
[13:54] <tedg> xnox, pay-service, my issue is that ci-train doesn't think it's built, figure it's checking the same thing.
[13:54] <jdstrand> pitti: it appears to be working :)
[13:55] <jdstrand> pitti, xnox: thanks for your help!
[13:55] <xnox> tedg: i don't know what ci-train looks for. I'm only talking about general ubuntu archive rules.
[13:55] <jdstrand> pitti: I need to do a little more testing, then will just sponsor your changes
[13:56] <jdstrand> pitti: thanks again for your work on this!
[13:56] <xnox> robru:  sil2100: pay-service will be regressing in supported architectures due to new build-dependencies, does ci-train handle that sensibly? or is something needed to be done there.
[13:56] <pitti> jdstrand: great, you're welcome!
[13:57] <sil2100> xnox: you mean, it will now not build for some architectures?
[13:57] <xnox> sil2100: correct.
[13:57] <xnox> sil2100: well, it will rather FTBFS on some.
[13:58] <sil2100> xnox: so, sadly CI Train might have some problems with that, as long as the archive still provides binaries for the packages in the archive
[13:58] <xnox> sil2100: well, dep-wait on libmirclient-dev.
[13:58] <sil2100> But if those will be dropped from the archive, CI Train will work ok
[13:58] <xnox> sil2100: horum.
[13:59] <sil2100> I guess we could also just ignore the failing architectures, which is possible but a bit dirrrty, as build failures will have to be ignored
[13:59] <xnox> tedg: so you need an archive-admin to review the diff and request removal of binaries by an archive admin.
[14:00]  * tedg looks for an archive admin to delete powerpc
[14:00] <tedg> ;-)
[14:00] <pitti> tedg: i. e. all powerpc binaries of the "mir" source?
[14:01] <pitti> ah no, that already doesn't exist on ppc
[14:01] <tedg> Heh, no I was joking about the architecture
[14:01] <pitti> tedg: what does "I" expand to?
[14:01] <pitti> in "Now that I'm using libmir-client I can't build on powerpc"
[14:01] <tedg> Probably easiest way to see the diff is the one that is generated by the PPA: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-008
[14:02] <tedg> pitti, pay-service source package
[14:02] <tedg> pitti, Generates libpay* pay-service
[14:03] <pitti> unity-scope-click and unity8 also build-dep on libpay2-dev, so these would need to go as well
[14:03] <pitti> ah, they don't build on ppc, so that's fine
[14:03] <tedg> Are they there? I believe the click scope is not.
[14:04] <tedg> Not having Mir on PPC is resulting a large set of packages not building there.
[14:06] <pitti> tedg: so to be completely clear, you are going to upload a new pay-service source which is going to build-dep on Mir?
[14:07] <pitti> because, if you are not going to, then the next upload of pay-service will just bring them back
[14:07] <tedg> pitti, Yes, I'd like to publish silo 8, which depends on mir.
[14:07] <pitti> tedg: usually I'd only remove the binaries from utopic if there was a new version waiting in -proposed, but I suppose the CI airline doesn't work that way
[14:08] <tedg> You can rest assured that *I* won't upload anything :-)
[14:08]  * pitti turns the LP crank, go faster!
[14:09] <pitti> tedg, sil2100: go wild: http://paste.ubuntu.com/7980028/
[14:09] <tedg> pitti, awesome, thanks pitti
[14:09] <sil2100> \o/
[14:57] <cjwatson> tedg: Can the package in question build without mir?  If so, the correct answer is mir [amd64 arm64 armhf i386].  If not, removing the binaries was correct.
[14:57] <tedg> cjwatson, No, it needs Mir now.
[14:57] <cjwatson> Right.
[14:57] <tedg> The trusted prompt support specifically.
[15:01] <bdmurray> pitti: is there something wrong with ddebs.ubuntu.com? all the -security pockets seem empty
[15:02] <bdmurray> http://ddebs.ubuntu.com/dists/saucy-security/
[15:10] <xnox> bdmurray: better that than publishing them before USN notices & unembargo go out
[15:10] <pitti> bdmurray: yes, I removed them as they were horribly outdated
[15:10] <pitti> bdmurray: they aren't really needed either
[15:10] <pitti> people were complaining about hash sum mismatches, etc.
[15:11] <pitti> -security is just a subset of -updates these days anyway; I haven't yet taught ddeb-retriever about building -security properly (that'll again double all the special cases of emulating soyuz)
[15:12] <bdmurray> pitti: some notification about that would have been nice as the retracers have been failing since that happened
[15:12] <pitti> bdmurray: oh, if they use them, how did they not fail before?
[15:12] <pitti> as their Packages could never be authenticated through the Release files
[15:13] <pitti> bdmurray: anyway, it's probably possible to build them properly, but it'll again take a while to sort that out
[15:14] <pitti> jdstrand: traincon? ufw is on the touch images?
[15:14] <bdmurray> pitti: http://pastebin.ubuntu.com/7980482/
[15:14] <jdstrand> pitti: yes, it is and its part of the smoke image tests
[15:14] <pitti> bdmurray: argh, sorry about that
[15:15] <slangasek> pitti: do you have a handle on this, or do you want me to look into it?  I'm not sure if it just needs recreating the files?
[15:15] <pitti> slangasek: we can copy the old (and broken) files, if that helps any
[15:15] <pitti> but frankly it might be just better to drop the -security ddeb apt sources from the retracers
[15:15] <bdmurray> pitti: well I can just disable the -security pocket in the sources.list files for the retracers but it would have helped to do that before they were removed
[15:16] <pitti> bdmurray: well, want me to put the old ones back?
[15:16] <pitti> well, that still wouldn't update the Release files, but apparently that didn't stop the retracers
[15:17] <bdmurray> pitti: how long would it take to put the old ones back?
[15:17] <slangasek> pitti: I think the point here is that ddebs.u.c, for all its bodgery, is a critical dependency of errors.u.c; so if you need to make changes to it, however innocuous, could you please keep bdmurray in the loop so he doesn't have to root-cause from the other end?
[15:17] <pitti> slangasek: ack, will do next time
[15:18] <pitti> bdmurray: a few minutes
[15:18] <bdmurray> pitti: that is probably faster than submitting an RT and finding a webop
[15:19] <pitti> bdmurray: done
[15:19] <bdmurray> pitti: thanks!
[15:19] <bdmurray> pitti: so I should still remove -security though?
[15:20] <pitti> bdmurray: yeah, please; they are useless and not updated anyway
[15:20] <doko> barry, any update on the MIR fron?
[15:20] <doko> front even
[15:20] <barry> doko: not much.  been busy with other things. :(
[15:37] <rbasak> I'm flipping some binary packages from being generated by mysql-5.5 to being generated by mysql.5.6.
[15:38] <rbasak> Just to check, I don't need to do anything special, do I, except to upload both to migrate from utopic-proposed together?
[15:38] <rbasak> They should be ABI compatible, and will have a higher packaging version number.
[15:39] <rbasak> This will create some component mismatches too, but I presume that this will just be flipped afterwards by archive admins?
[15:39] <rbasak> (to demote 5.5 and promote 5.6)
[16:00] <pitti> rbasak: binary overrides won't change due to an upload, so yes, it'll appear in component-mismatches afterwards
[16:00] <pitti> would be nice to fix mysql-5.6's autopkgtest if it wants to become the new default version (5.5's work)
[16:14] <rbasak> pitti: yeah, I get dep8 failures here. I've asked upstream to take a look.
[16:19] <rbasak> infinity: there's some confusion about HWE EOL prompts before 14.04.1 is recommended by update-manager, which I think is fair.
[16:19] <rbasak> infinity: users are asking if the block is for some reason that might mean they should delay forcing an update.
[16:19] <rbasak> infinity: http://irclogs.ubuntu.com/2014/08/07/%23ubuntu-server.html#t15:24
[16:20] <rbasak> infinity: do we have an answer for that question please, until 14.04.1 is recommended?
[17:38] <hallyn> zul: so yeah.  feh!  systemd-shim is now being used by libvirtd, and not quite doing the right thing bc it only expected logind to talk to it
[19:23] <hallyn> SUCCESS
[19:28] <hallyn> zul: I'm going to push http://paste.ubuntu.com/7982242/ to utopic to fix standard migration;  then I will probably push http://paste.ubuntu.com/7982241/ to support migration from precise, as well as push Alex Bligh's qemu patch (also required)
[19:42] <Elv1313> Hello, we have build issues on our PPA since a few day because of an upstream package change that seem to conflict with its own dependencies. Can someone take a quick look and revert that chnage? https://launchpadlibrarian.net/181543532/buildlog_ubuntu-utopic-amd64.sflphone-daemon_1.4.1-rc20140804~ppa1~utopic_FAILEDTOBUILD.txt.gz
[20:05] <hallyn> just running qrt first...
[23:40] <hallyn> xnox: :(
[23:40] <hallyn> (#server)
[23:40] <sarnold> :(
[23:41] <xnox> i've kept -devel, -desktop (cause seb128 is funny when he is trolling), -dmb, -installer, -motu, -uk
[23:41] <xnox> and #upstart, #lxcontainers and #cgmanager.
[23:41] <xnox> undecided about a few others.
[23:42] <xnox> hallyn: sarnold: such is life =)
[23:43] <hallyn> \o see you at plumbers :)
[23:43] <xnox> hallyn: yeah, need to register and organize travel there.
[23:43] <sarnold> xnox: heh, if you're at plumbers and at debconf, I might actually see you more -after- you've left ...
[23:44] <xnox> sarnold: *giggle* true
[23:44] <hallyn> zul: ok, if you could take a look at the qemu and libvirt pkgs in ppa:serge-hallyn/virt, each has 2 extra packages in it, i intend to push them to utopic tomorrow
[23:44] <sarnold> (i'm not actually doing much for debconf, but some of the debian folks interested in apparmor want to get together, sounds like fun...)
[23:44] <hallyn> never been to debconf myself
[23:44] <xnox> sarnold: oh, that does sound like fun!
[23:46] <xnox> sarnold: hallyn: this one looks busy. Best one was in Nicaragua. Excellent location, cheap bear, 8 talks per day across 2 rooms, breakfast / lunch / dinner / hack labs, 1 full day sightseeing day trip.
[23:46] <xnox> it's very laidback.
[23:47]  * hallyn jealous
[23:47] <shadeslayer_> xnox: did you have a look at the ubiquity bug I pinged you about?
[23:48] <xnox> shadeslayer_: nope, been testing/fighting to push out 12.04.5. Let me look at it.
[23:48]  * shadeslayer_ is pondering about coming to conf week
[23:49] <xnox> shadeslayer_: conf week? DebConf that is?
[23:51] <shadeslayer_> no, the large conference week at Düsseldorf
[23:53] <shadeslayer_> with linux plumbers conf and couple of other ones
[23:54] <stgraber> I know quite a few Ubuntu folks will be there, we'll be a bunch from Foundations and there will be all the kernel team too I think
[23:55] <shadeslayer_> Embedded Linux Conference was the one I was thinking about
[23:56] <shadeslayer_> there's also Cloud Open Europe and the KVM forum that happens the same week
[23:56] <shadeslayer_> mental ^_^
[23:58] <shadeslayer_> xnox: re ubiquity, its something to do with privilege escalation
[23:59] <xnox> shadeslayer_: hm.
[23:59] <shadeslayer_> it complains about not being able to run commands as a different user, and works fine when using sudo, which sounds like a privilege escalation issue to me