[05:45] <cpaelzer> good morning
[06:05] <Skuggen> elbrus: I'm MySQL upstream by the way, so you could poke me about anything mysql-specific
[06:05] <Skuggen> And yeah, we started the transition much too late. Sorry :|
[06:09] <pitti> Good morning
[06:11] <Unit193> Heya, pitti.
[06:14] <Skuggen> Morning :)
[06:43] <nhaines> Hmm, I'm missing avidemux in xenial.  Question: how can I check when and why it was dropped from the archives?
[06:56] <popey> nhaines: odd.. https://launchpad.net/ubuntu/+source/avidemux/+publishinghistory
[06:57] <popey> back in yakkety
[06:58] <nhaines> popey: yup, I noticed.
[06:58] <nhaines> Huh, x264 lib transition problem.  Huh.
[06:59] <nhaines> Wish I'd known!
[06:59] <nhaines> I wonder where that was discussed...
[06:59] <popey> bug 1585504 probably needs updating
[07:04] <nhaines> popey: if I can get it working again, can it go into xenial-updates?  Or is that off-limits once a release has been sealed?
[07:30] <Tm_T> this isn't yet in ubuntu security tracker? https://security-tracker.debian.org/tracker/CVE-2016-5118
[07:34] <popey> nhaines: I suspect backports is the way to xenial from yakkety
[07:35] <pitti> infinity: ATM we seed "init" into "required"; once we make it non-essential, what do you think would be the correct seed? minimal, I suppose?
[07:36] <nhaines> popey: Ooh, thanks.  I'll have to... I guess I'll have to look into that.
[07:37] <pitti> infinity: i. e. something that does not end up in the buildd chroots, but on every actual image/product
[07:40] <pitti> RAOF: the mir main→ universe demotions on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt -- ok/intended, or do some seeds need to be updated?
[07:40]  * RAOF looks
[07:42] <RAOF> pitti: One or more of mir-graphics-drivers-android or mir-graphics-drivers-desktop should be seeded somewhere, I think.
[07:42] <RAOF> Presumably mir-graphics-drivers-android should be seeded for the touch image, and -desktop for a desktop image.
[07:45] <nhaines> That's crazy talk!
[07:58] <six86> Hello. I'm packaging software which depends on java. Our software is tested with 1.6, 1.7 and 1.8 but has problems with java 1.9. To be flexible in the future we want to depend on the virtual packages java7-runtime and java8-runtime. But this leads to installation of java 1.9 jre... how can we prevent this?
[08:10] <six86> Or simpler: how can i depend on java <= 1.8 with using the virtual package abstractions?
[08:27] <LocutusOfBorg> can anybody please run gdal autopkgtest against vtk6/proposed? thanks
[08:32] <pitti> smoser: that cloud-init python hash seed issue is a real nuisance; do we have a workaround for that yet?
[08:40] <LocutusOfBorg> hi, does anybody know what is wrong with this build? https://launchpad.net/ubuntu/+source/python-tornado/4.3.0-2ubuntu1/+build/9818460
[08:41] <LocutusOfBorg> I can't reproduce the build failure on debian, ppa, local
[08:41] <LocutusOfBorg> pbuilder, sbuild etc
[08:41] <LocutusOfBorg> something is preventing sockets to be reused from python, but only on armhf and buildd system (Ubuntu)
[08:53] <infinity> pitti: minimal == Priority:important, which seems correct, yes.
[09:01] <Saviq> pitti, hey, during the arm64 enablement we're encountering quite  a bit of "uninstallable ... missing runtime dep */arm64" - slangasek mentioned that this felt overly stringent on things that were not available/installable for that arch in the first place, think we could allow those through automagically?
[09:02] <Saviq> adding "artificial" B-Ds to avoid building for an arch feels weird
[09:06] <Saviq> maybe we would not copy the arch, but that'd feel detrimental to the process of enabling the missing dependency, because would require you to hunt for packages that are not in the archive - but if the archive can only have installable packages, then maybe that's what we do?
[09:08] <infinity> The goal is certainly for everything in the archive to be installable.
[09:10] <infinity> Saviq: Where are you seeing the issues?
[09:10]  * infinity doesn't see anything suspicious in excuses.
[09:12] <Saviq> infinity, right now it's fine in excuses I think, but we had that before with the upstart s390x deletion - also we've just enabled unity8 arm64 in a silo, but that didn't pass britney because of oxide-qt not having arm64 yet
[09:12] <infinity> Well, if unity8 depends on oxide-qt, it's somewhat useless to publish it?
[09:13] <Saviq> infinity, "somewhat" - would go a fair way to allow people enabling oxide-qt to verify their work
[09:14] <Saviq> I think my worst complaint is the need to add artificial B-Ds to avoid that
[09:14] <infinity> Artificial B-Ds are one option, arch-restricting is another.
[09:15] <infinity> Having uninstallable packages in the archive doesn't really help anyone.
[09:15] <infinity> Having them in a PPA can help, certainly.
[09:17] <Saviq> infinity, ack, I wonder if proposed migration could just skip them (only if they were not available for that arch before), then? so we can still get to them through LP?
[09:17] <infinity> Saviq: "skip" them how?
[09:17] <infinity> Saviq: You mean delete the arm64 binaries?
[09:17] <infinity> Saviq: That's not something we're going to do automatically.
[09:18] <Saviq> infinity, well, not migrate them
[09:18] <Saviq> ack
[09:18] <infinity> We migrate based on source packages, not binary.
[09:18] <infinity> So, the whole source is ready to go, or none of it is.
[09:19] <Saviq> infinity, ok, was just asking - we'll manage - not like this will be a constant source of trouble
[09:19] <infinity> Certainly, when enabling an arch, we have hacks to let an arch be a bit broken for a while, but enabling arm64 happened years ago, you missed that boat.
[09:19] <Saviq> :)
[09:20] <infinity> (And I will point out that I got annoyed even back then about people making assumptions like "we'll never make an arm64 desktop/phone product, so meh". :P)
[09:24] <Saviq> ;)
[11:29] <six86> How can I define in a deb to install stable java 8 and not 9? When depending on java8-jre, openjdk-9-jre is installed :(
[11:42] <six86> How can I block java 9?
[11:43] <LocutusOfBorg> Trevinho, hi, can you please upload a compiz without libpng12-dev build-dependency?
[11:43] <LocutusOfBorg> ginggs, ^^^
[11:57] <cpaelzer> pitti: if there is a package that has no dep8 test adt-run after the build obviously just says SKIP, is there a way to get into the adt-run session anyway - like --shell?
[11:58] <cpaelzer> pitti: reason: laziness - I just would like to (mis-)use that env as test-env without having to set up an own one :-)
[12:12] <pitti> cpaelzer: you are using qemu?
[12:12] <cpaelzer> pitti: yes
[12:12] <pitti> cpaelzer: if there's no actual test, then there also won't be any specific setup like isntalling packages
[12:12] <pitti> cpaelzer: so you could just as well boot the VM with QEMU directly
[12:12] <cpaelzer> pitti: so I could just qemu into the image
[12:13] <cpaelzer> pitti: ok
[12:13] <cpaelzer> pitti: thanks
[12:13] <pitti> cpaelzer: I do that all the time indeed, to get a throaway VM for experimentatino
[12:13] <cpaelzer> pitti: that is just what I wanted in my case :-)
[12:13] <pitti> cpaelzer: i. e. I boot it with ssh forwardning and -snapshot
[12:14] <pitti> cpaelzer: I usually call "vm adt-yakkety-amd64-cloud.img -snapshot" where vm is http://people.canonical.com/~pitti/scripts/vm
[12:15] <cpaelzer> pitti: works like a charm for me!
[12:16] <pitti> cpaelzer: oh, and you might want -nographic too
[12:16] <cpaelzer> that allows me to throw away some of my semi-persistent uvt-kvm instances
[12:16] <cpaelzer> pitti: I'm fine adding random qemu options as I need them, great
[12:17] <pitti> cpaelzer: I don't put -nographic into my "vm" script as I also use it to boot desktop VMs, but if you only use it for that purpose, it's more convenient there of course
[12:17] <cpaelzer> I copied your vm script into my ~/bin
[12:18] <cpaelzer> wouldn't there be a use for that "in" the autopkgtest package as little helper script?
[12:18] <cpaelzer> or do you think that is too special
[12:19] <pitti> cpaelzer: if at all, then more like in qemu itself
[12:19] <pitti> that script has nothing to do at all with autopkgtest
[12:19] <cpaelzer> true
[12:19] <pitti> I guess pretty well everyone who regularly boots VMs has their own little set of scripts
[12:57] <Trevinho> LocutusOfBorg: mh, what's the problem?
[13:00] <LocutusOfBorg> Trevinho, libpng12 needs to die, using libpng-dev only is the solution
[13:01] <LocutusOfBorg> I want to remove it from the archive :)
[13:07] <eoli3n> hi, just want to know where is located files of this loading screen -> http://img15.hostingpics.net/pics/703002201605301501361298x972scrot.png
[13:07] <eoli3n> i manage clients with ansible, and i created a service which is launched before lightdm.service
[13:08] <ginggs> Trevinho: if you are uploading a new compiz, would you change libjpeg8-dev to libjpeg-dev as well, please?
[13:08] <eoli3n> i want to see if i can edit this screen to add some graphics information about ansible-pull process
[13:09] <Trevinho> ginggs, LocutusOfBorg: ok... You can also propose that if you can/want: just do a MP against lp:compiz
[13:36] <LocutusOfBorg> Trevinho, https://code.launchpad.net/~costamagnagianfranco/compiz/compiz/+merge/296044 ?
[13:36] <pitti> infinity: you'll lose not one, but two init systems soon :) http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt
[13:36] <LocutusOfBorg> is it ok? (note, it is my first try)
[13:37] <Trevinho> LocutusOfBorg: fine
[13:37] <Trevinho> LocutusOfBorg: thanks
[13:38] <pitti> infinity: sysvinit-utils is too soon though (debian bug 810018), I'll seed that
[14:08] <mapreri> Laney: can you kick AS for scribus/xenial-proposed?
[14:19] <pitti> infinity: i-s-h and seed changes done for making init not essential/required any more; let's see what breaks :)
[14:49] <pitti> infinity: so the first three sections in http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt are now as  I'd like them -- does that look reasonable to you? but I'm not sure where the two others ({standard,optional} → important) come frmo
[14:50] <pitti> infinity: oh, because init moved to "minimal", and systemd recommends libpam-systemd, which needs dbus
[14:50] <pitti> infinity: thus previously when init was in required, we didn't install the recommends; hmm
[15:53] <Bluefoxicy> needs more readyboost-config
[15:53] <Bluefoxicy> http://man7.org/linux/man-pages/man7/lvmcache.7.html
[15:54] <Bluefoxicy> I guess this is n/a to btrfs
[15:58] <Bluefoxicy> https://www.rath.org/ssd-caching-under-linux.html bcache
[15:58] <Bluefoxicy> I wonder how long this will stay relevant.  You can get a 6TB HDD for like $150, or a 0.5TB SSD for that now, so SSD is 12x as expensive
[15:59] <Bluefoxicy> there's new technology closing that gap, though.
[16:00] <Bluefoxicy> sucks to implement complex caching only to have this lug of ridiculous floatsam bogging up your system 5 years later when the high-speed caching device is cheaper than the high-capacity backing device
[16:16] <roadmr> Is there a bug about the non-actionable "Software Updates Available" bubble?
[19:40] <infinity> pitti: Those changes look fine to me, they already match the minimal task, the priority being wrong was a bug, IMO, not a feature.