[00:02] <xnox> .... one must not run -proposed on development release....
[00:02]  * xnox is not ssure where tmartins went.
[00:35] <ThiagoCMC> xnox, why not enable proposed on development branch ? Everything is fine here, it was my confusion...   =)
[00:36] <xnox> ThiagoCMC, humans should not run -proposed on the devel release.
[00:37] <xnox> ThiagoCMC, it's not meant for end user consumption, and only for automated systems. it has all abi transitions in progress, and shall be used by buildds only, and automated testing. once things are good, things migrate to release pocket. Hence for "rolling" release one should run devel release only, without -proposed enabled. -proposed has like 700 broken packages at the moment. Whereas devel without -proposed should be entirely installable.
[00:38] <xnox> and we remove things from -proposed when we realise we uploaded really broken things, that fail testing.
[00:38] <xnox> (e.g. autopackage tests, and britney transitions, arch skew etc.)
[00:39] <ThiagoCMC> got it
[00:39] <ThiagoCMC> thank you!
[00:40] <xnox> ThiagoCMC, in practice, without -proposed one gets shiny stuff, daily, with a small delay, and never broken things. Or so is the effort =)
[00:41] <ThiagoCMC> sounds cool
=== mnepton is now known as mneptok
[02:57] <goddard> why doesn't the resolution get set on tty and lightdm when inside unity?
[02:58] <goddard> i have a 2k laptop screen, but i run in 1080p because it saves battery and is more readable, but my tty and lightdm screens are 1440p
[02:58] <goddard> why don't they just read what Unity has set?
=== imcleod_ is now known as imcleod
[06:04] <infinity> pitti: Hrm.
[06:05] <infinity> pitti: What will trigger libselinux to retry against the new glibc?
[06:06] <Mirv> pitti: I guess autopkgtest infra is still struggling and there's a new glibc too. anyway, updated kwin + marble were copied from a landing PPA 12h ago so for now I just wait
[06:21] <pitti> Mirv: right, see http://autopkgtest.ubuntu.com/running.shtml -- I suppose at some point we need to cut off the triggered tests for glibc, they won't ever all succeed anyway; but we should give it some time so that we get enough results to be confident
[06:21] <pitti> infinity: at the moment this needs to be done manually; there's a bug report against britney to do it automatically
[06:46] <pitti> infinity: I re-ran selinux now
=== cpaelzer is now known as cpaelzer_afk
[08:03] <Saviq> Mirv, morning, I've been havnig trouble with xenial proposed unfortunately, upgrading to it made unity8 crash-loop :/, trying from scratch again, but another thing is that apt reported additional 24MB of disk space used, we should make certain what's happening there...
[08:05] <Mirv> Saviq: did you remove QML cache?
[08:06] <Saviq> Mirv, d'oh
[08:06] <Mirv> :)
[08:07] <Saviq> Mirv, any case, the "additional 24MB" is scary
[08:08] <Saviq> Mirv, but yeah, removing QML cache helped :)
[08:08] <Mirv> Saviq: right, do you have scrollback of the upgrade? I remember some new dep was being installed, but I thought it was small. I wonder what has then bloated and how much.
[08:09] <Mirv> Saviq: yes, I was at some point apport-retrace:ing and seeing "wow, crashing inside v4!" until I remebered that right... this feels familiar
[08:09] <Saviq> Mirv, no, scrolled off I'm afraid, but I'll try from scratch anyway
[08:10] <Mirv> Saviq: ok, let's check the newly installed packages first and then consider comparing the package sizes of themselves
[08:12] <Mirv> Saviq: there seems to be also new poppler and apt libraries in proposed that when upgrading are installed alongside the old ones, those make up >4MB already
[08:13] <Saviq> Mirv, right, might try going the silo route instead
[08:13] <dholbach> good morning
[08:13] <Saviq> moi
[08:13] <Saviq> n
[08:15] <Mirv> Saviq: FYI necessary packages are spread to two silos 012 + 059 so that'd mean manual configuring and pinning of both
[08:16] <Saviq> Mirv, ack
=== cpaelzer_afk is now known as cpaelzer
[09:03] <zzarr> hello! is there a way to install a 16.04 framework (kit) in Qt (Ubuntu SDK)?
[09:18] <Unit193> cjwatson: Dang you are on top of it then, just saw your comment in the twisted bug about switching to Pyca.  Nice!
[09:22] <Odd_Bloke> doko: Did you get a chance to look at the new comment on bug 1500768?  It looks like we still have a problem with the urllib3 that's bundled in python-virtualenv.
[09:22] <ubottu> bug 1500768 in python-virtualenv (Ubuntu Trusty) "python3.4.3 SRU break requests" [Undecided,New] https://launchpad.net/bugs/1500768
[09:48] <snkt> hiii
[09:49] <snkt> Can anyone help me how to customize Live ubuntu ISO to autologin with root
[11:03] <caribou> Anything obvious could explain the fact that, on one node, rsyslog exits with a SEGV when started by upstart but works fine if started from a shell ?
[11:35] <cjwatson> Unit193: Well, that was only in passing really, I'm not actually working on the Twisted->PyCA thing
=== _salem is now known as salem_
[11:35] <Unit193> Didn't look like you were, just looked like you were watching it.
=== cpaelzer is now known as cpaelzer_afk
=== cpaelzer_afk is now known as cpaelzer
[12:06] <cjwatson> Unit193: The really horrible archaisms (SHA-1 only) are out of the way now, but it'd certainly be nice to be able to add ECC and whatnot.
[12:07] <Unit193> cjwatson: Indeed, personally I'm waiting for Ed25519 support.  I'm trying to use it everywhere, even though the router's dropbear sshd won't get it anytime (soon.)  Already was crazy enough to cross build putty for PA.c.  Anywho, no need to be taking up your time here with this.
[12:27] <cjwatson> doko: Mind if I merge ncurses?
[12:57] <pete-woods> pitti: it's that time again! (https://github.com/martinpitt/python-dbusmock/pull/17)
=== cpaelzer is now known as cpaelzer_afk
[13:29] <doko> cjwatson, please do
[13:30] <cjwatson> doko: ok, thanks
[13:53] <davidsha> Quick question, is pciutils supposed to support libkmod on Ubuntu? I've seen it's supported on fedora and I'm just curious.
[13:56] <cjwatson> davidsha: you seem to have filed a bug, which I think is the appropriate thing to do.  I'll forward it to Debian though.
[13:57] <davidsha> cjwatson: thanks, sorry for bugging you guys about it!
[14:09] <cjwatson> davidsha: forwarded, and linked the LP bug
[14:09] <cjwatson> (https://bugs.launchpad.net/bugs/1516095)
[14:09] <ubottu> Launchpad bug 1516095 in pciutils (Ubuntu) "pciutils built without libkmod support" [Wishlist,Triaged]
[14:12] <davidsha> cjwatson: thanks!
[14:25] <ubiquity> how to create official ISO from ubuntu source?
[14:30] <highvoltage> you can't create official ISOs
[14:31] <highvoltage> (well afaik)
[14:32] <sladen> ubiquity: google for Ubuntu ISO customisation
[14:34] <xnox> doko, it is ok to upgrade to new cython point release? =)
[14:34]  * xnox uploaded it...
[14:36] <ubiquity> livecd customization can create the same iso as the official one?
[14:36] <doko> xnox, why do you ask then? ;p
[14:37] <xnox> ubiquity, if it ends up the same, why customize. if it's different, it's not official anymore now is it =) only ubuntu publishes official images ;-)
[14:37] <xnox> ubiquity, it will boot and it will install. but if you use packages or sources not from the archive, you will have to support it yourself.
[14:38] <ubiquity> i want to know the process to create the official ISO
[14:43] <doko> xnox, fyi, https://launchpadlibrarian.net/228711711/buildlog_ubuntu-xenial-s390x.gcc-5_5.3.1-0ubuntu1_BUILDING.txt.gz
[14:43] <xnox> doko, >infinity ^
[15:05] <smoser> xnox, was away yesterday. wrt qemu, talk to hallyn
[15:06] <xnox> smoser, cool, thanks.
[15:06] <xnox> hallyn, i'd like to have qemu 2.5 sooner, rather than later. Can we start working on packaging rc release? and are we targetting to ship with 2.5? Should we package them in ubuntu proper, or ppa?
[15:08] <xnox> stgraber, i see you mark procps as please take, on MoM. I shall take it, as I need fixes from the merge.
[15:09] <xnox> ... unless doko do you want to merge procps? =)
[15:12] <doko> xnox, go ahead
[15:27] <stevenm_> Hey, anyone here familiar with the ubiquity installer?  i'm looking at the bottom of the ubiquity/plugins/ubi-prepare.py file
[15:28] <roaksoax> pitti: howdy! is there a way to force an app to use a newer postgress in packaging? ie. upgrading from trusty to xenial would mean a change of postgres versions
[15:28] <roaksoax> pitti: how can I ensure that my app uses the latest postgresq ?
[15:31] <roaksoax> pitti: specially when the packaging is using dbconfig-common
[15:35] <hallyn> xnox: mjt has started packaging 2.5 for debian.  are you on oftc#debian-qemu?  that's where we generally discuss that
[15:36] <hallyn> think you used to sit there... if memory serves :)
[15:45] <pitti> roaksoax: you can of course depend on postgresql (>= 9.4) or so
[15:45] <pitti> roaksoax: or perhaps better postgresql-9.4 | postgresql (>= 9.4), in case someone doesn't want the metapackage
[15:47] <roaksoax> pitti: will that ensure than the DB is migrated to use postgresql-9.4 from 9.3 ?
[15:47] <roaksoax> pitti: and all handled by dbconfig-common ?
[15:47] <pitti> roaksoax: no, you can't, that needs to be done by the admin after the upgrade
[15:50] <smoser> infinity, hey. i know that you have more than a few things that you take care of...
[15:50] <smoser> but just pinging on presense of 'wily-netboot' at http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/installer-amd64/current/images/
[15:50] <smoser> https://bugs.launchpad.net/maas-images/+bug/1511497
[15:50] <ubottu> Launchpad bug 1511497 in maas-images "No hwe-w kernel for 14.04" [Medium,Confirmed]
[15:52] <roaksoax> pitti: ok, so is this something we can do in packaging ?
[15:52] <roaksoax> pitti: rather than have the admin do it?
[15:52] <pitti> roaksoax: no, we can't do programmatic DB upgrades
[15:53] <roaksoax> pitti: ok, cool! So then I guess we need to cry out load that users upgrade from trusty -> xenial will need to upgrade their DB's
[15:53] <cjwatson> That's always been the case anyway
[15:53] <pitti> roaksoax: that sohuld alreayd happen via debconf
[15:53] <cjwatson> Launchpad would be very sad if you tried to do it automatically ;-)
[15:57] <roaksoax> pitti: ok cool
[15:57] <pitti> the package used to try in-place upgrades until 2005, it was all really brittle and sorry, so we stopped that
[15:58] <didrocks> tseliot: apw: is the video framebuffer still part of the kernel or of any use? I'm looking at our custom vga16fb for plymouth and wonder if we shouldn't drop it?
[16:00] <tseliot> didrocks: we should be able to drop it soon enough
[16:01] <tseliot> didrocks: fglrx and nvidia are still the reason why we have that in place
[16:01] <didrocks> tseliot: yeah, so, it's still a valid thing for xenial and plymouth should support it?
[16:05] <tseliot> didrocks: yes
[16:06] <didrocks> tseliot: I hope you have hardware to test the merge once done (thanks for volunteering btw :p) ;)
[16:07] <tseliot> didrocks: yes, assuming I'm not on holiday by the time you do it ;)
[16:08] <didrocks> tseliot: around next week? I hope to be done "soon" :)
[16:09] <tseliot> didrocks: yep, except for Tuesday
[16:09] <didrocks> oh, sounds excellent then! Will bother you ;) Thanks!
[16:10] <tseliot> :)
=== _salem is now known as salem_
[17:22] <pitti> wow -- the s390x builders rock
[17:22] <pitti> they went through 8 hours of buildd backlog in < 1 hour!
[17:23] <cjwatson> it is nice to have fast and pretty stable builders for a new arch, for once
[17:23] <cjwatson> only one kernel problem so far
[17:25] <TJ-> could someone take a look at this affecting Vivid>Wily upgrades  'dpkg --configure' returns 10 - looks like someone forgot the .postinst runs with 'set -x' but needs confirming that's the correct fix: bug 1495302
[17:25] <ubottu> bug 1495302 in openssl (Ubuntu) "subprocess installed post-installation script returned error exit status 10" [High,Triaged] https://launchpad.net/bugs/1495302
[17:25] <ogra_> can you still call it a 8h backlog then ?
[17:26] <cjwatson> ogra_: buildd queue lengths are a guesstimate based on package sizes estimated on 2010 x86 hardware
[17:27] <ogra_> ah, a metric then :) (despite an old one)
[17:27] <cjwatson> ogra_: at least in the case where we have no historic build data, as with a new arch
[17:27] <ogra_> yeah
[17:28] <cjwatson> the fallback estimate is: if we know the package size, then 6KB/second plus a minute for general overhead; if we don't, then five minutes
[17:28] <cjwatson> we prefer the duration of the most recent successful build, though
[17:29] <ogra_> wow, so there is actual math behind it
[17:29] <cjwatson> it's not *complete* lies
[17:29] <cjwatson> just frequently
[17:29] <ogra_> :)
[17:30] <cjwatson> anyway, they are definitely very nice builders, they've built 2/3 of their backlog and 27/28 of them have only been operational for about a day
[17:31] <cjwatson> bodes well for generally keeping out of people's way
=== tsg is now known as tsg_away
[18:59] <ThiagoCMC> hey guys! Any plans to upgrade InfluxDB to 0.9.5 for Xenial ?
[18:59] <ThiagoCMC> I'm planning to build a InfluxDB Cluster with it, when ready...
[19:23] <botato> is there something for ubuntu that will make sure someone who has access to your machine won't have access to certain files. and when they try to access those certain files, a prompt will show up that will ask for a special password whcih isn't the same as the password they used to ssh into the machine?
[19:28] <infinity> smoser: Soon.  I've been on vacation most of the week (and still am), only popping in for s390x bootstrapping.
[19:28] <infinity> doko: Oops.  Will fix.
[19:29] <doko> infinity, take -0ubuntu2
[20:00] <infinity> doko: Should be happier now.
[20:08] <dobey> botato: samba, vsftp, or something else, that only allows access via some other protocol. bug #ubuntu is the place to ask ubuntu support questions like that
[20:09] <botato> ok thanks
=== salem_ is now known as _salem
[20:36] <chiluk> pitti: I think it was you who was thinking about helping out by syncing findutils from debian-unstable to xenial.. so I checked and debian has 4.5.14, which does contain the fix for https://bugs.launchpad.net/ubuntu/+source/findutils/+bug/1347788
[20:36] <ubottu> Launchpad bug 1347788 in findutils (Ubuntu Xenial) "find crashed when current working directory is not readable and -exec or -execdir used" [Low,Confirmed]
[21:20] <ancaemanuel> Hi devs
[21:21] <ancaemanuel> I sent an email to ubuntu-devel but is waiting for moderation
[21:23] <dobey> ok
[21:23] <ancaemanuel> My comment is about the current algorithm for the builders
[21:24] <dobey> your question is about PPAs?
[21:25] <ancaemanuel> I will post it here
[21:25] <ancaemanuel> The current algorithm for building 12000 packages for an new architecture is:
[21:25] <ancaemanuel> For a* to z* try build.
[21:25] <ancaemanuel> Of course you will need lib* and *dev first, and you will waste a lot
[21:26] <dobey> i doubt it
[21:26] <ancaemanuel> of time trying to compile things.
[21:26] <ancaemanuel> My proposal: try to find an algorithm for dependencies.
[21:26] <dobey> new architectures don't get added often
[21:26] <ancaemanuel> If package A depends on package B to be build, B gets an +1 for priority.
[21:27] <ancaemanuel> there is mips ...
[21:28] <dobey> ubuntu supports mips again?
[21:28] <dobey> or you're talking about debian?
[21:29] <ancaemanuel> No, jut an ideea
[21:29] <ancaemanuel> just
[21:30] <dobey> well there are lots of architecutres that ubuntu doesn't support
[21:30] <ancaemanuel> am Im talkinh about https://launchpad.net/ubuntu/xenial/+builds?build_text=&build_state=built&arch_tag=s390x
[21:30] <dobey> eh, the s390x hardware is incredibly fast
[21:30] <stgraber> ancaemanuel: the problem is that to know what a package needs to be built, you need to unpack the source and run it through the package resolver in a chroot of the right architecture
[21:31] <dobey> exactly
[21:31] <stgraber> which is why we can't resolve and prioritize the right build ordering ahead of time, well, we could, but it'd be just as painful as just trying to build the damn thing
[21:31] <stgraber> so instead we add build records for everything, typically starting with main which we know can be built in a self-contained manner and is typically what's used for the rest of the packages
[21:32] <ancaemanuel> And when you build it, you can record the dependencies
[21:32] <ancaemanuel> save for later
[21:32] <stgraber> when something fails to build, Launchpad figures out why it failed to build (parses that from sbuild) and makes the package depwait
[21:32] <stgraber> then attempts to build again once that package the depwait package is published
[21:34] <stgraber> no you can't because we've got that thing called alternatives, a package may depend or build-depend on one out of a set of packages, the final one being picked depending on avaibility (whether it's built and available in an allowed component), the ordering matters there, the first being favored, so when bootstrapping an arch, less favored ones may be picked, but on a rebuild, you'd want the first to be picked
[21:35] <stgraber> anyway, the effort of even trying to encode all of the resolver logic outside of the chroot, parsing all source packages at upload, ... would far exceed the average cost of just retrying a build
[21:35] <stgraber> yes, a new arch bootstrap is a bit of a special case as the first packages to build have a high chance of failing to build, but we usually have done some manual bootstrapping outside of LP first so already know what the bootstrap stages are
[21:36] <stgraber> so those build records can be created in the right order and then we can throw the rest at the buildds and wait a couple of days
[21:36] <stgraber> which is never a real issue since we usually start building the distro way before anyone has hardware they can use it on, so nobody is actually waiting on those packages as they're still busy getting access to hardware to do their bits (most important one being setting up image builds)
[21:37] <ancaemanuel> I am talking about dumb trying to build from a* to z* packages without *dev first
[21:38] <dobey> that is your opinion, yes
[21:38] <JanC> I guess stuff like glibc gets uploaded first anyway  :)
[21:38] <stgraber> I know, I'm just saying that even with that, the cost of adding the logic to figure out those things without throwing them at a buildd far exceeds that of just throwing them at a buildd
[21:38] <dobey> and it's not simply a-z. it's first-queued
[21:38] <stgraber> In average that is. If we were to bootstrap a new architecture every week, that'd be different
[21:40] <dobey> bootstrapping is hard (TM)
[21:40] <dobey> let's go to pub
[21:40] <stgraber> dobey: well, when we add a new arch, it's effectively what is done, we just create new build records for everything that exists in the archive. Except that we already have a minimal functional chroot that was pre-built by hand ahead of time (so the very low level stuff already exists) and that main builds before universe so we take care of a ton of libs that way.
[21:40] <Unit193> s/hard/fun/
[21:40] <dobey> stgraber: exactly. that was my point :)
[21:41] <dobey> not like you can build a compiler without a compiler to compile it, either
[21:42] <JanC> <stgraber> so those build records can be created in the right order and then we can throw the rest at the buildds and wait a couple of days | <dobey> let's go to pub → so that's what you do after starting the build? :P
[21:43] <stgraber> JanC: pretty much
[21:43] <dobey> JanC: you're assuming we're not in the pub when we start the build :)
[21:43] <JanC> and that's why you don't want it to go too fast...
[21:43] <stgraber> this time around, it'd be a question for cjwatson, wgrant and infinity :)
=== kitterma is now known as ScottK
=== _salem is now known as salem_
[22:34] <ben___> any advice on debugging these "dpkg-shlibs: warning ... contains an unresolvable reference to symbol" issues? http://paste.ubuntu.com/13681422/