[00:01] <bdmurray> seb128: ah, there was a problem with a repo
[00:01] <bdmurray> seb128: it seems like something other people will run into though
[00:01] <seb128> bdmurray, k, so gnome-software should handle that better
[00:01] <seb128> yeah
[00:01] <seb128> shouldn't impact the default install though
[00:02] <seb128> so probably fine to fix in a sru
[00:08] <flexiondotorg> infinity, I've just seen you release freeze email.
[00:08] <flexiondotorg> I've got a number of bugs fixes in the sponsor queue, is there any reason I can have those included?
[00:16] <psusi> can I poke anyone familiar with my work over the years to endorse my application for core-devel? https://wiki.ubuntu.com/PhillipSusi/DeveloperApplication2
[00:40] <seb128> slangasek, do you plan update freetype from 2.6.1 to 2.6.3 before release? Just saw https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2016-March/016293.html that claims that the update might fix some security issues, just pointing it in case if that's something that got overlooked
[00:58] <slangasek> seb128: I do not; see LP: #1521299
[01:12] <seb128> slangasek, k
[02:42] <infinity> flexiondotorg: You can get them in, just be quick about it.
[03:50] <pitti> Good morning
[03:51] <pitti> LocutusOfBorg: thanks! No *saml* on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html any more and ruby-saml landed, so I figure that's sorted out
[03:52] <pitti> stgraber, balloons: note, we don't have lxd based runners in production right now, I'm still setting these up; production uses good old lxc (as root)
[03:53] <stgraber> yeah, that's what I thought :)
[03:56] <pitti> stgraber: I thought for classic lxc 1 nesting should work OOTB; do I need to enable anything specific for that?
[03:56] <pitti> I have a custom apparmor profile which allows mounting
[03:57] <pitti> wgrant: hey, how are you?
[03:57] <stgraber> depending on kernel you may also need an extra include for the nesting.conf file we ship in /usr/share
[03:57] <pitti> wgrant: can we do that full langpack export now? (the "full" box is ticked)
[03:57] <pitti> stgraber: trusty kernel for armhf (newer ones don't boot on the calxeda) and xenial kernel for s390x
[03:59] <wgrant> pitti: For xenial? Sure.
[03:59] <pitti> wgrant: right, for xenial
[04:36] <infinity> pitti: Eh?  Newer ones don't boot on Highbank?  Since when?
[04:36] <hallyn> any of the libc-savvy people in here know whether there is a (seemingly unwritten) rule that ttyname should return something under /dev?
[04:36] <infinity> pitti: If that regressed, it was an accident, not intentional.
[04:36] <pitti> infinity: not sure if I tried a vivid kernel, but vivid or wily; it gets stuck very early, missing some block device driver or so
[04:37] <infinity> pitti: So we lost a CONFIG in a rebase, probably.  I wish someone had mentioned it.
[04:37] <hallyn> actually maybe that's moot
[04:37] <infinity> hallyn: It should be able to be any path, surely?
[04:39] <hallyn> libc seems to only do paths under /dev
[04:39] <hallyn> i'm trying to find if there is any reason why returning /proc/self/fd/0 is not ok, if that resolves to a valid device which isn't bound in the current mntns
[04:40] <hallyn> really i guess it's the same question as the one raised by pt_chown
[04:40] <sarnold> .. to which the answer is surely "More booze!"
[04:41] <hallyn> it might be
[04:41] <rharper> \o/
[04:41] <hallyn> bc while i thin it's ok to return /proc/self/fd/0 if that points to /dev/pts/20 and that doesn't exist,
[04:41]  * rharper hands out 750s 
[04:41] <hallyn> the problem remains that if there *is* a /dev/pts/20 i can't tell if that's the right one or not
[04:42] <hallyn> oh i can,
[04:43] <hallyn> nope, wrong again
[04:44] <hallyn> drat so now i have to go through and actually read that long thread again.
[04:45] <sarnold> I don't see any systemcalls that look helpful; I'm not sure this is a solvable problem
[04:46] <sarnold> you may not be able to do a 100%-correct job on this one
[04:46] <stgraber> hallyn: can't stat it?
[04:47] <hallyn> that's what i was trying - ah yeah the major/minor are actually helpful
[04:48] <stgraber> right, I was thinking of comparing the major/minor of the /proc/ entry to that of the device in /dev, if it matches, return that, if it doesn't, return the /proc path
[04:48] <hallyn> so if the readlink is stat()able then compare major/minor of the resulting path to the lstat of /proc/self/fd/0,
[04:48] <hallyn> if not the same, then still return "/proc/self/fd/0"
[04:48] <hallyn> should work
[04:48] <stgraber> yep
[04:49] <sarnold> .. can you check that the /proc/self/fd/0 is actually a tty device?
[04:49] <hallyn> it already does that
[04:49] <stgraber> yeah, libc actually does that part right
[04:49] <hallyn> so what libc does right now is readlink the name, then stat the result.
[04:49] <hallyn> if that gives -ENOENT then it returns null.  else it returns the link value
[04:49] <hallyn> but both of those can be wrong
[04:50] <stgraber> which is why the "tty" command right now exits 0 but prints an error which confuses quite a few things :) Because it is a tty, but ttyname returns an empty string
[04:50] <hallyn> ok, so my patch will add some overhead, but i think it's worthwhile
[04:50] <sarnold> heh
[04:50] <stgraber> hallyn: ttyname isn't something that's called all that often, a tiny overhead to have it DTRT should be fine
[04:51] <sarnold> .. and heck even if it is called all the time, being correct may be that much more important :)
[04:51] <hallyn> agreed.  i'll try to get that and the new kernel patch <sob> sent tomorrow
[04:51] <hallyn> heh, yeah
[04:52] <hallyn> in fact it also will fix the "other kerfuffle which will not be named"
[04:52] <hallyn> all right, to the batcave.  thanks gents.
[04:52] <stgraber> also leaving for the night, talk to you tomorrow
[04:53] <hallyn> \o
[05:36] <cpaelzer> good morning
[05:50] <pitti> wgrant: just to confirm, is this running now?
[05:51] <wgrant> pitti: Yep
[05:51] <pitti> wgrant: cheers
[05:51] <wgrant> np
[06:01] <flexiondotorg> Can I request some sponsoring assistance please?
[06:01] <flexiondotorg> infinity, Has said I need to get my bug fixes in promptly.
[06:01] <flexiondotorg> They are mostly Syncs from Debian and some small updates.
[06:02] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/mate-menu/+bug/1570554
[06:02] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1570652
[06:02] <flexiondotorg> https://bugs.launchpad.net/bugs/1569732
[06:03] <flexiondotorg> https://bugs.launchpad.net/bugs/1569731
[06:03] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1569320
[06:03] <infinity> flexiondotorg: Have you given any thought as to whether MATE will be an LTS release for 16.04?
[06:03] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-meta/+bug/1568773
[06:03] <flexiondotorg> infinity, Yes, we are absolutely doing LTS.
[06:04] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/x2goclient/+bug/1569310
[06:04] <infinity> flexiondotorg: I was going to send an email out for flavours to pick 3/5 (or not LTS) based on the fact that everyone's done this before, and I just realized that you haven't. :P
[06:04] <flexiondotorg> That is my sponsor requests.
[06:04] <flexiondotorg> infinity, Yeah, this is new.
[06:04] <flexiondotorg> We just assumed we'd be doing 5 years.
[06:04] <flexiondotorg> And thet is what we're up for.
[06:05] <flexiondotorg> infinity, I've posted all most sponsoring bugs above. Any chance you can process those?
[06:05] <infinity> flexiondotorg: So, traditionally, letting a flavour be LTS requires a bit of a plan of how you intend to commit to maintenance for your N chosen years, send to the techboard mailing list, and we'll +1/-1 based on exposure to you over the past few cycles and the sanity/realism in your plan.
[06:05] <infinity> flexiondotorg: I can try to look at your bugs in a bit.  It's late here, and I'm grinding away at my own stuff, so we'll see.
[06:06] <flexiondotorg> infinity, OK, will send mail later.
[06:06] <flexiondotorg> infinity, So if I can another sponsor to process my bugs that is fine right?
[06:06] <flexiondotorg> infinity, All that is required is to unblock them?
[06:07] <infinity> flexiondotorg: If your community is spread fairly thin or lightly-staffed (which I suspect is true right now), you might want to go for 3 instead of 5.  Gives you a year overlap with 18.04, instead of 3.
[06:07] <flexiondotorg> infinity, OK. I'll give that some thought.
[06:08] <infinity> flexiondotorg: If all your sponsorship requests are things that would be valid SRUs, any old sponsor will do, we'll review in the queue.
[06:08] <flexiondotorg> What constitutes the MATE bit in Ubuntu MATE is actually very small.
[06:08] <infinity> flexiondotorg: If they're massively FFe-breaking gross, not so much.
[06:08] <flexiondotorg> infinity, Everything is a fix.
[06:09] <flexiondotorg> infinity, In the spirit of your email adding these fixes will make Ubuntu MATE "good enough".
[06:09] <infinity> flexiondotorg: Sure, I realize your package set is pretty small, but so is your team, so judge accordingly.  IMO, 5y LTS is really only meaningful if you're targetting slow-moving environments (large corporation rollouts, etc).  Most average users would upgrade from 16.04 to 18.04 withing days/weeks of update-manager telling them to anyway, so the extra 2 years is just a burden.
[06:09] <infinity> flexiondotorg: But your call, obviously.  Last LTS, the flavours were split about 50/50 on 3/5.
[06:10] <flexiondotorg> infinity, So one deployment we know we'll have is for several large remote terminal server deployments.
[06:10] <flexiondotorg> inaddy, Hence the x2goclient FFe.
[06:11] <flexiondotorg> infinity, For how many years are point release images mades? Like 16.04.1, 16.04.2 etc.
[06:13] <infinity> flexiondotorg: Last point release is 16.04.5, which coincides (within a week or so) with 18.04.1
[06:13] <infinity> flexiondotorg: Which is ~3mo after 18.04 release.
[06:14] <infinity> flexiondotorg: So, after that, it's just SRUs for critical fixes, but no more installer validation and ISO madness.
[06:14] <flexiondotorg> OK, so with in the 3 year LTS window.
[06:14] <flexiondotorg> It would seem 3 years is sufficient then.
[06:15] <flexiondotorg> I'll discuss with the X2Go guys.
[06:15] <flexiondotorg> Do I need to file a plan for 3 year LTS?
[06:16] <infinity> flexiondotorg: Yeah.  The 3/5 decision is entirely your call, those last two years are generally easier (fewer fixes you're willing to consider "critical" when you can just tell people to upgrade to the next LTS instead), though worth noting that when something *needs* to be fixed in 4yo software, the backporting can suck. :P
[06:17] <infinity> flexiondotorg: But we need the email regardless.  The 3/5 thing is just something you need to mull over in the next few days so we can set the right number in LP and have it show up right in packages files.  And once it does, you're stuck.  So choose wisely. :P
[06:18] <flexiondotorg> infinity, Thanks for the advice.
[06:31] <darkxst> dholbach, is there an existed FFe for seeding snappy? or do I need to file one?
[06:32] <flexiondotorg> darkxst, When I did it I filed an FFe just for Ubuntu MATE.
[06:33] <infinity> darkxst: Don't bother filing, just seed snapd (as a recommends, if you want to follow what most are doing) and upload a refresh of your meta.
[06:33] <darkxst> infinity, ok cool, will do
[06:34] <flexiondotorg> infinity, Can you refresh ubuntu-mate-meta please? https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-meta/+bug/1568773
[06:34] <flexiondotorg> It's a tiny update.
[06:35] <infinity> flexiondotorg: Refreshing.
[06:35] <flexiondotorg> infinity, ty!
[06:47] <infinity> flexiondotorg: I don't see any cheesiness in that update (thought I do see some other bits)
[06:48] <infinity> Wait, no.
[06:48] <infinity> I see no changes.
[06:48] <infinity> I'm not awake enough. :P
[06:50] <infinity> flexiondotorg: Oh, that bug is ancient.  I've uploaded your meta much more recently.
[06:50]  * infinity just closes it.
[07:07] <darkxst> infinity, can you take a look at the casper part on bug 1561302 ?
[07:08] <elbrus> nacc: I see your pings regarding cacti, but I don't see what you want... (sorry, I have been busy the last days)
[09:39] <pitti> stgraber: ok, lxd is now running for autopkgtests :) (https://plus.google.com/+MartinPitti/posts/QJnjsUci4Wi)
[09:39] <pitti> Laney: ^ FYI
[09:42] <pitti> apw, jdstrand: do you have an interpretation of the regression in http://autopkgtest.ubuntu.com/packages/l/linux/xenial/ppc64el/ ?
[09:42] <pitti> that openssl version should be a functional no-change (just some patch cleanup)
[09:43] <Laney> pitti: nice
[09:43] <Laney> are the SS instances long running?
[09:44] <pitti> Laney: well, they tend to auto-destruct after a day or two
[09:44] <pitti> Laney: but in principle they are meant to, yes
[09:44] <Laney> ya, that bug
[09:44] <pitti> Laney: autopkgtest-cloud/tools/armf-lxd-slave.userdata has everything to set them up, though, so it's simple to spin up new ones
[09:44] <pitti> Laney: (for nova boot --userdata)
[09:45] <pitti> Laney: this still needs logic for the controller node to run workers automatically, see/register the available remotes etc., so still a PoC
[09:45] <pitti> but it can help with the backlog for sure
[09:45] <pitti> and we can collect some experience with hit
[09:45] <pitti> it
[10:00] <pitti> mvo: FYI, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd regression
[10:06] <mvo> pitti: did anything in infrastucture change? it looks like an io error/timeout from a store download
[10:07] <pitti> mvo: not that I know of; something could have changed in the scalingstack config behind my back of course
[10:07] <pitti> mvo: but given that 1.9.2 passed *after* the 1.9.3 failure, I doubt that (http://autopkgtest.ubuntu.com/packages/s/snapd/xenial/amd64/)
[10:07] <mvo> pitti: interessting
[10:08] <pitti> and that's consistent across all arches
[10:09] <mvo> pitti: hrm, we actually test more now than in 1.9.2 :/ this is why it fails, i.e. the failure in 1.9.3 are network releated and we did not use network before AFAICS
[10:09] <pitti> ah, that would explain it indeed then
[10:09] <pitti> mvo: store access might not work through a proxy then?
[10:10] <pitti> we set http_proxy and friends in /etc/environment and in the test env
[10:10] <mvo> pitti: thats possible, I don't think we tested this
[10:10] <mvo> pitti: let me check that, thanks, thats useful
[10:11] <pitti> mvo: we can also give you access to a production instance where this fails, if needed
[10:11] <pitti> but I'm running out of time today (I took half-day off, need to run in 3 mins, sorry)
[10:11] <mvo> pitti: that would be nice, I suspect its because we use https for everything
[10:11] <pitti> if Laney has time he might be able to help
[10:11] <mvo> pitti: ok, who else could help?
[10:11] <pitti> mvo: we set https_proxy too
[10:11] <mvo> pitti: ta
[10:12] <mvo> pitti: run and thanks for your help
[10:12] <pitti> Laney: we have a "jump host" (instance name "debug") in prodstack, ssh to that, ssh-import-id lp:mvo, then from there folks can ssh to an instance of a manual adt-run with -s
[10:12] <pitti> you can't directly ssh from outside to a scalingstack instance
[10:34] <Pharaoh_Atem> nacc: libvirt-php is building and passing the php extension build system tests
[10:34] <Pharaoh_Atem> on php7
[10:38] <Pharaoh_Atem> nacc: so once you build a ppa package, I can test it
[12:08] <LocutusOfBorg> hi, question: today is the last day to sync stuff from debian?
[12:08] <LocutusOfBorg> correct?
[12:09] <rbasak> LocutusOfBorg: if seeded, then we're already past final freeze. The release team will consider essential fixes though, see the announcement.
[12:10] <LocutusOfBorg> rbasak, I *need* to have virtualbox in
[12:10] <LocutusOfBorg> :)
[12:10] <LocutusOfBorg> xorg 1.18 fixes, and kernel too
[12:10] <LocutusOfBorg> as usual, I have to break stuff
[12:10] <LocutusOfBorg> damn broken dinstall
[12:12] <LocutusOfBorg> can't ubuntu sync from incoming.d.o? (citation needed)
[12:12] <rbasak> LocutusOfBorg: you can still sync, subject to the freeze criteria. I believe.
[12:12] <LocutusOfBorg> sync from incoming?
[12:13] <rbasak> No, I don't think that works.
[12:13] <LocutusOfBorg> :(
[12:13] <rbasak> Launchpad needs to have imported into launchpad.net/debian for sync to work, AIUI.
[12:13] <LocutusOfBorg> --no-lp?
[12:13] <rbasak> I don't know.
[12:13] <LocutusOfBorg> I tried once, but failed
[12:13] <rbasak> You could just upload what you uploaded as an Ubuntu delta. It wouldn't make any difference now this close to release.
[12:14] <rbasak> (though you'll need to sync once again in X+1)
[12:14] <LocutusOfBorg> I would like to avoid that, but yeah
[12:14] <cjwatson> with dak broken, if it can't wait for dak to be fixed, it would have to be manual in some way.
[12:14] <LocutusOfBorg> indeed
[12:14] <cjwatson> rbasak: there's always ~build1 or similar
[12:14] <rbasak> cjwatson: ah, OK
[12:14] <cjwatson> we did actually arrange for incoming to have acls that would let us sync from it, but never got round to setting that up in LP; there were concerns about making sure we could correctly handle unaccepts and suchlike
[12:17] <jdstrand> pitti: regarding http://autopkgtest.ubuntu.com/packages/l/linux/xenial/ppc64el/ it seems to have resolved itself?
[12:28] <sruli> hi, is secureboot implemented in 16.04? will it warn user if a unsigned kernel is loaded?
[12:29] <sruli> i am referring to Launchpad bug 1401532
[12:53] <superm1> cyphermox: i don't know if you've had reports of this yet, but i've noticed the new NM sometimes thinks my wifi device turned into an ethernet device
[12:55] <superm1> i noticed https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1569590 but it's not an ath* device on my machine
[13:24] <doko> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815633  please update the symbols file ... solution: remove it :-/
[13:34] <cyphermox> superm1: right
[13:34] <doko> hmm, the openexr test failure succeeds locally
[15:07] <nacc> Pharaoh_Atem: ack, thanks
[15:18] <Pharaoh_Atem> nacc: no problem
[15:21] <nacc> Pharaoh_Atem: was that the version in unstable? -- aka can you check debian unstable as it is now?
[15:23] <mgz_> pitti: how do you want patches to autopkgtest?
[15:23] <Pharaoh_Atem> nacc: give me a second, I'll check
[15:24] <nacc> Pharaoh_Atem: thanks, it might still be publishing tbh, but rmadison shows a newer version in usntable from what we saw yesterday
[15:36] <Pharaoh_Atem> nacc: it's a slight fork
[15:36] <Pharaoh_Atem> nacc: http://anonscm.debian.org/cgit/pkg-php/libvirt-php.git/log/
[15:36] <Pharaoh_Atem> it doesn't yet match upstream
[15:36] <Pharaoh_Atem> also, I've figured out where those weird git hashes are coming from
[15:37] <Pharaoh_Atem> he's managing it as an in-tree repository, like with php, which means that you can't rely on the git revs to match upstream for snapshots
[15:39] <nacc> Pharaoh_Atem: ah ack, makes sense
[15:39] <Pharaoh_Atem> personally, not a fan of that
[15:40] <Pharaoh_Atem> it makes things more complicated then it needs to be
[16:07] <Unit193> Are there any other repos besides the Ubuntu one that support by-hash?  I'm wondering if I implemented it correctly.
[16:07] <cjwatson> Unit193: not to my knowledge
[16:07] <cjwatson> well, PPAs support it too, but same code
[16:07] <cjwatson> Unit193: there's https://wiki.debian.org/RepositoryFormat#indices_acquisition_via_hashsums_.28by-hash.29
[16:09] <seb128> bdmurray, hey, did you see bug #1570947
[16:09] <seb128> seems to be due to the landing you did today with the change from darkxst
[16:09] <seb128> jibel, willcooke, ^
[16:10] <Unit193> cjwatson: Ah, re-reviewing did answer it, thanks.
[16:12] <cjwatson> Unit193: Cool.  The tricky bit is dealing with expiry, which depends how clever you want to be.
[16:12] <Unit193> Indeed, no idea how I'm going to deal with that one.
[16:14] <hallyn> smb: meh, looks like i need to make wgrant a mmember of the libvirt-maintainers group so he can use the lp git tree :)
[16:14] <bdmurray> seb128: I didn't, thanks
[16:14] <cjwatson> Unit193: The algorithm in LP isn't (I think) too hard to read if you want inspiration.
[16:15] <smb> hallyn, I'd say there's worse people to be added ... :)
[16:15] <Unit193> Might be handy.
[16:16] <hallyn> wish we had an official UDD-style tree
[16:16] <cjwatson> Unit193: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/archivepublisher/publishing.py#L1008 (_updateByHash) is the entry point
[16:16]  * hallyn makes a note to straighten that out in the xenial tree later, not now
[16:17] <cjwatson> ByHashes (and its child ByHash) is defined further up in that file.
[16:18] <cjwatson> ArchiveFile is in lib/lp/soyuz/model/archivefile.py, although the details are quite LP-specific.
[16:18] <cjwatson> (http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/soyuz/model/archivefile.py)
[16:19] <Unit193> Thanks, though I don't believe this adds much benefit to me it still might be handy, moreso if I can upstream it.
[16:19] <hallyn> stgraber: sarnold: fwiw http://sourceware.org/ml/libc-alpha/2016-04/msg00391.html.
[16:19] <rbasak> tjaalton: how did you merge apache2? Looks like you inadvertently reintroduced http2.load which led to https://bugs.launchpad.net/ubuntu-release-notes/+bug/1531864/comments/5
[16:19] <hallyn> let's see hwo i get roasted
[16:20] <hallyn> ubottu, go home, you're drunk
[16:21] <stgraber> infinity: see http://sourceware.org/ml/libc-alpha/2016-04/msg00391.html I mentioned that issue here a little while back
[16:21] <bdmurray> darkxst: you might be interested in bug 1570947
[16:23] <seb128> bdmurray, it's like 2am for him so I doubt he's going to be around
[16:23] <hallyn> sbeattie: ugh, i didn't group-reply with that email.  do you mind replying to it with a 'ok' or something so the list sees it? :-)
[16:24] <seb128> bdmurray, maybe cyphermox or infinity can help you there?
[16:24] <alkisg> stgraber: ltsp is completely broken in 14.04, but no one is interested in doing an SRU for ~50 bugs. On the other hand, the newest xenial ltsp package works fine in 14.04. Is there any way in the ubuntu policy to get the newest ltsp backported to 14.04?
[16:25] <stgraber> alkisg: as an SRU, no, unless it's a bugfix only release but I doubt that'd be the case. You can request a backport though at which point users would be able to run say: apt-get -t trusty-backports install ltsp-server
[16:26] <stgraber> alkisg: which would get them the backported package
[16:26] <alkisg> stgraber: that will still leave the normal way to install ltsp broken. No ways around that, right?
[16:26]  * alkisg directs people to do an SRU or use his ppa, just to make sure he isn't pointing them wrong...
[16:27] <stgraber> alkisg: right, we do not push new features in existing releases. If upstream LTSP was making bugfix-only releases (as is the case for many other projects), then those could go in without the paperwork for every individual bug, but getting a complete new release full of new features through SRU isn't allowed by policy, no
[16:27] <alkisg> OK, ty
[16:28] <alkisg> Maybe the policy should allow replacing a broken version with a fixed newer version with new features, but that's a bigger talk, not for now...
[16:30] <rbasak> dholbach: mate-menu> snap
[16:33] <ogra_`> rbasak, that is not how to create snap packages :P
[16:34] <nacc> heh
[16:34] <nacc> one day ...
[16:35] <rbasak> ogra_`: ?
[16:35] <infinity> stgraber: How is that not a kernel/namespace bug?
[16:35] <rbasak> Oh
[16:35] <rbasak> :)
[16:35] <ogra_`> :)
[16:35] <infinity> stgraber: Why would /proc/self/* ever point to something in another namespace?
[16:36] <stgraber> infinity: you can absolutely pass fds between namespaces, or in this case have an open fd before switching to another namespace (setns)
[16:37] <infinity> stgraber: Sure, but isn't the point of /proc/self that it should be internally consistent with the process's state?  If the path differs in the current namespace, I'd expect it to be updated to match.
[16:37] <stgraber> infinity: the main reproducer for the issue is getting a shell inside a container. To do that, the user spawns a process on the host, that process then setns into the container and execs a shell. It's still attached to the user's pts device on the host (and should be as we want it to be an interactive shell)
[16:38] <stgraber> infinity: the container has its own devpts instance on /dev/pts so /proc/self/fd/0 points to a path in the host namespace
[16:39] <stgraber> infinity: readlink on /proc/self/fd/X gives you the path which was provided at fd open time, it doesn't give you the path the file is currently at
[16:40] <infinity> stgraber: Yes, hence my assertion that this is a kernel bug. :P
[16:40] <infinity> stgraber: I'm not sure how returning the link to (effectively) nowhere is significantly more helpful than the current broken behaviour.
[16:40] <infinity> stgraber: You still can't use it for anything.
[16:40] <stgraber> infinity: because you can absolutely open /proc/self/fd/0 and it'll work fine
[16:41] <infinity> Even if it's a symlink to a file that doesn't exist?
[16:41] <stgraber> yep
[16:41] <infinity> *raise brow*
[16:41] <stgraber> infinity: http://paste.ubuntu.com/15853488/
[16:42] <stgraber> infinity: that's the linux kernel for you, and it's something people have been relying on for a while, so ain't gonna change
[16:42] <stgraber> infinity: the fix hallyn submitted fixes the "tty" command, as well as screen, byobu, ... anything which uses ttyname
[16:42] <kirkland>  (woot)
[16:43] <infinity> stgraber: This also implies that the kernel knows where the *real* fd/0 lives, which furthers my assertion that this is a bug in procfs. :P
[16:43] <stgraber> infinity: the kernel knows but it can't show you that path
[16:43] <stgraber> infinity: that path is completely outside the scope of your container so you can't possibly reach it
[16:43] <infinity> stgraber: No, but if, in the current namespace, the path is unresolvable, the least it could do is remove the link to nowhere.
[16:43] <infinity> stgraber: And show fd/0 as a file instead of a link.
[16:44] <infinity> stgraber: Anyhow, meh.  Also obviously not a glibc regression, so we'll get there if we get there, or SRU later.
[16:45] <stgraber> infinity: I agree it would make sense for the kernel to do that, unfortunately I don't see this changing due to it being basically API at this point (it's been like that forever) and I don't believe there is any precedent for a /fd/ entry to be anything but a symlink
[16:45] <stgraber> (or well, a symlink looking thing)
[16:46] <stgraber> infinity: and yeah, not a regression, just an annoying issue that a lot of our users ran into or will run into (do-release-upgrade fails for example). I don't think we should rush it though which is why hallyn sent the fix upstream rather than distro-patching
[16:49]  * cyphermox -> lunch
[16:56] <tjaalton> rbasak: huh? with git, mut far from kbd until sunday
[16:56] <rbasak> tjaalton: OK. Well, it went wrong. Thought you should know.
[17:00] <tjaalton> ok, can't check what went wrong
[17:00] <tjaalton> sorry
[17:25] <hallyn> stgraber: i'm having to postpone my reply bc i'll be too snarky right now.  not sure how i'm *expected* to react to that...
[17:26] <hallyn> "so you want me to make my eyes bleed more with your ugly-ass coding style but don't want to actually take the patch bc you think fixing a security issue has securiyt implications?  Do you not see the relevance to the ptchown disaster?"
[17:31] <infinity> hallyn: You might want to skip the bit about GNU coding standard (we almost all agree it's ugly, but picking a new standard and reindenting millions of lines would be worse).
[17:31] <infinity> hallyn: But feel free to challenge Florian on security concerns.
[17:31] <infinity> hallyn: Most of the time, you'll be wrong, but he can take a healthy debate.
[17:33] <ogra_> geez ... doing a do-release-upgrade with the canonical vpn enabled is really badly killing bandwidth
[17:34] <hallyn> infinity: yeah i think i'm cranky from a too-much-email morning;  i'll replywhen i'm not whiny
[17:40] <sarnold> hallyn: nice patch. pity about the coding standards, I like your version just fine ;)
[17:40] <sarnold> hallyn: I agree with infinity, at the very least push back on asking him to describe what yours introduces -- or why the current behaviour isn't worse..
[17:43]  * hallyn finally got some breakfast, maybe that's my problem
[17:56] <hallyn> sarnold: nah even my version made my eyes bleed.  And ebiederman couldn't follow the flow he said bc of the 2 spaces :)
[17:56]  * hallyn looks for the gnu coding style guide
[17:57] <sarnold> hallyn: if it were longer I might have come to the same conclusion :)
[17:58] <hallyn> still wonder whether i should also do it for ptsname.c.  i probably should.
[17:59] <hallyn> that's the most immediately obvious security relevant one
[18:04] <hallyn> wowzer:
[18:04] <hallyn> Please use formfeed characters (control-L)
[18:04] <hallyn> to divide the program into pages at logical places (but not within a function).
[18:07] <sarnold> I'm still stunned whenever I see that in source
[18:08] <rbasak_> Well, it's handy if you want to print out the source :-P
[18:08] <rbasak> (you do that, right?)
[18:08] <mdeslaur> what? I don't think I've ever seen that
[18:08] <mdeslaur> sarnold: what source, you've made me curious :)
[18:09] <mdeslaur> I'm not sceptical, I just want to know which source to mock
[18:09] <sarnold> mdeslaur: coreutils
[18:09] <sarnold> I was reading nproc the other day..
[18:10] <sarnold> $ grep -r ^L . | wc -l
[18:10] <sarnold> 1290
[18:12] <hallyn> 1290?  wowzer
[18:12] <mdeslaur> that grep is wrong, try again
[18:12] <hallyn> hm, i may have lied to Florian.  *can* i verify that the device is devpts?
[18:13] <hallyn> yeah major should be never-changing
[18:14] <sarnold> mdeslaur: it was umt download, so all releases.. and I used ^V^L of course to construct the ^L ..
[18:14] <sarnold> mdeslaur: oh it's also got loads of cscope hits :/
[18:15] <mdeslaur> hah! I see them now...wow, insane
[18:24] <hallyn> wtf.  'git checkout' just overwote my changes.  normally it says 'no you have changes'...
[18:25] <hallyn> ok i really *am* having a bad friday
[18:38] <xclaesse> Hello
[18:39] <xclaesse> I just upgraded to ubuntu 16.04, and now when I try to ssh to servers that has my DSA key in authorized_keys, it says Permission denied (publickey).
[18:39] <xclaesse> with ssh -v I see that it tries to use id_rsa but not id_dsa
[18:40] <xclaesse> is that a recent change because DSA is not considered safe anymore?
[18:43] <mdeslaur> xclaesse: dsa is disabled in openssh 7.0 for security reasons, yes
[18:44] <mdeslaur> xclaesse: you can re-enable it, see here: http://www.openssh.com/legacy.html
[18:44] <mdeslaur> xclaesse: or ideally use rsa or something else
[18:45] <xclaesse> mdeslaur, ok thanks
[18:45] <xclaesse> mdeslaur, I knew DSA was considered weak nowadays, just need to temporaly re-enable it so I can copy my new RSA id :)
[18:48] <mdeslaur> xclaesse: yeah :)
[18:48] <mdeslaur> sarnold: I'm almost done with a patch to add linefeeds to apparmor, I just need to print it all out to test. Are we aiming for letter, legal or A4 paper?
[18:50] <sarnold> mdeslaur: lol
[18:52] <sbeattie> mdeslaur: please make sure it fits on 3x5 index cards.
[18:55] <mdeslaur> sbeattie: I used to own one of these: http://i.ebayimg.com/00/s/MTIwMFgxNjAw/z/8OMAAOSwaA5WkxOq/$_12.JPG?set_id=880000500F
[18:56] <mdeslaur> no linefeeds necessary :)
[18:56] <sbeattie> hehe
[18:56] <sarnold> wow, 24, 32, _and_ 40 columns?
[18:57] <Pici> whoaaa
[19:09] <hallyn> sarnold: used to?  wtf!
[19:29] <mdeslaur> hallyn: I no longer have it. I'm such a fool. I called it...Rosebud.
[19:39] <seb128> cyphermox, trying today's daily in a virtualbox (which is online), the first page has the "download update" option disabled (can't be clicked), is that a known issue?
[19:41] <hallyn> mdeslaur: yeah, there are a few things i wish i'd never given up :)
[19:43] <cyphermox> seb128: no
[19:43] <cyphermox> try to reset the online state too
[19:46] <seb128> cyphermox, install is ongoing atm, going to try once it's done
[19:51] <nacc> Pharaoh_Atem: so are you saying the debian version (pacakged already) is not complete?
[19:59] <Pharaoh_Atem> nacc: no, it's not
[19:59] <Pharaoh_Atem> in fact, it's got the wrong fix, according to Michal and Remi
[19:59] <Pharaoh_Atem> it can cause stack mashing or something like that
[20:03] <ashwin> where can I get the .config file for ubuntu trusty for kernel v4.2 ? I just made a minor change and want to recompile the kernel
[20:03] <hallyn> this gets better and better
[20:03] <Unit193> hallyn: Do you want to go back to bed and try the day over?
[20:03] <sarnold> ashwin: /boot/config*
[20:03] <hallyn> so use 2 spaces for indent, but then use a tab if there are 8 spaces.  check
[20:04] <sarnold> hallyn: that alone is probably why we're not all using hurd right now.
[20:04] <seb128> cyphermox, reconnecting doesn't work, it says it's disabled because there is no internet connection ... unsure if that's a vb issue or a side effect of the nm 1.1 update
[20:04] <seb128> jibel, ^
[20:04] <hallyn> Unit193: maybe
[20:04] <hallyn> is that an option?
[20:05] <ashwin> sarnold: Thanks!! Gotta improve my google-fu :)
[20:05] <sarnold> ashwin: it's not an easy one to search for
[20:05] <sarnold> ashwin: the kernel team actually p7ublishes their configs somewhere, but I can never find the site when I want it
[20:06] <hallyn> sarnold: i woulda sucked it up if i wasn't also chastised for unthinkingly adding a signed off by
[20:06] <sarnold> hallyn: wha?? o_O they don't do the origin-thing/
[20:06] <Unit193> sarnold: I don't suppose you mean their git? (http://kernel.ubuntu.com/git/)
[20:07] <sarnold> Unit193: probably this http://kernel.ubuntu.com/~kernel-ppa/configs/trusty/
[20:07] <sarnold> Unit193: my issues with git is something else entirely..
[20:08] <Pharaoh_Atem> nacc: that package needs to be rebased on the current git master
[20:08] <cyphermox> seb128: probably a bug in NM, but in part made easier to reproduce because virtualbox is evil and broken
[20:08] <Pharaoh_Atem> nacc: also, it should be treated as 0.5.1+ snapshot date, since he hasn't decided what it'll be released as
[20:09] <seb128> cyphermox, let me know if need debug info from me or if you can reproduce
[20:09] <Unit193> sarnold: Also, FWIW.  Netsplits left you unidentified.
[20:09] <sarnold> Unit193: gah I keep forgetting that I never set up certfp over here once they added it..
[20:09] <Unit193> Yeah that one is a fantastic backup.
[20:10] <cyphermox> seb128: any details you can add to the bug report are helpful
[20:10] <ashwin> sarnold: Yup, and page where that was had config for an old version (not 4.2 that is on trusty's linux-generic)
[20:11] <hallyn> sarnold: lots of people don't do it, but few act as though their git repo will segfault if it sees one
[20:11] <infinity> ashwin: The config for your installed kernel is /boot/config-$(uname -r), that's the easiest place to grab it.
[20:13] <Unit193> infinity: Not that you are too interested, but for the insane trying out dracut in Xenial is pretty darn easy now, just have to drop a shell wrapper in /usr/sbin/update-initramfs for kernels that call it directly (but triggers take care of it later.)
[20:14] <infinity> Unit193: Yeah, I'm not sure I consider that a feature. :)
[20:14] <ogra_> ugh
[20:23] <nacc> Pharaoh_Atem: taht's why it's 0.5.2~
[20:23] <nacc> Pharaoh_Atem: means precedes 0.5.2
[20:23] <nacc> Pharaoh_Atem: i'm 99% sure ondrej just took your ML change ... is it actually wrong?
[20:24] <hggdh> which package should I assign on a bug about hostnam being called with -b at busybox time (xenial)?
[20:24] <infinity> hggdh: "At busybox time"?
[20:27] <infinity> hggdh: You mean in the initramfs?
[20:28] <hggdh> infinity: yes
[20:29] <infinity> hggdh: initramfs-tools, but I'm kinda curious why you think that's a bug.
[20:30] <hggdh> infinity: bad parameter: http://picpaste.com/busybox_error_16.04-b4eZkmJt.JPG
[20:30] <infinity> hggdh: Ah.  Well, that would indeed be a bug. ;)
[20:31] <infinity> hggdh: One almost no one sees because most people don't have an /etc/hostname in their initrd.
[20:31] <hggdh> infinity: heh. And because it flashes very fast on boot time
[20:32] <hggdh> I will open a bug on it. I understand it is most probably not bad, but anyways.
[20:32] <infinity> hggdh: I'm not even sure how you have an /etc/hostname.  Can you give me an "rgrep hostname /usr/share/initramfs-tools" ?
[20:33] <hggdh> infinity: http://paste.ubuntu.com/15859220/
[20:33] <ogra_> uuh
[20:33] <infinity> hggdh: Ahh, zfs.  Yeah, not a common thing yet, hence the lack of complaint.  Will fix.
[20:34] <hggdh> infinity: need a bug for that?
[20:34] <sarnold> heh, have I rebooted since creating my pool? :)
[20:34] <infinity> hggdh: Nah.
[20:34] <sarnold> I don't recall seeing that screen..
[20:36] <infinity> The -b argument there is entirely pointless anyway, since we test for /etc/hostname first.
[20:36] <infinity> (The whole point of -b is to behave sanely if the -F arg isn't there)
[20:40] <hggdh> infinity: thanks, sir
[20:42] <infinity> Oh, two bugs.  The redirection there is bad too.
[20:42] <infinity> Though, in your case, that showed the first bug. :P
[20:45] <infinity> hggdh: Fixes uploaded.
[20:47] <nacc> Pharaoh_Atem: ok, can you file a bug or e-mail ondrej with clarification?
[20:47] <nacc> Pharaoh_Atem: unless your last e-mail was clarifying enough
[21:00] <Pharaoh_Atem> nacc: I think it was clarifying enough
[21:00] <Pharaoh_Atem> nacc: though actually, I should probably elaborate
[21:02] <rbasak> reverse-depends still claims gnokii-smsd-mysql [amd64] but chdist disagrees. What is reverse-depends querying? Is it possible that it's behind?
[21:02] <rbasak> "reverse-depends libmysqlclient18" that is.
[21:08] <infinity> rbasak: It queries a private DB built against the archive.  It can certainly lag by a few hours.
[21:12] <infinity> rbasak: http://paste.ubuntu.com/15859911/ <-- What's being done about the *-5.6 rdeps?
[21:24] <rbasak> infinity: mythtv is an alternative so false positive. I can rebuild percona for 5.7 - no significant change in client so it should work equally well with 5.7 (and maybe I can unversion them while at it).
[21:25] <rbasak> Skuggen is looking at pinba.
[21:25] <rbasak> gnokii and kodi are done - database lag.
[21:26] <rbasak> tarantool-lts as well IIRC.
[21:26] <rbasak> So getting there.
[21:26] <rbasak> bareos too - db lag probably
[21:26] <rbasak> cfengine3 Skuggen has a debdiff for me.
[21:26] <rbasak> ntopng done, db lag.
[21:27] <rbasak> infinity: trafficserver is a painful one actually. A major version update in -proposed has FTBFS for various reasons on various archs, Debian too. So I wonder if we could try rebuilding only the version in the release pocket after deleting the proposed version maybe?
[21:27] <infinity> rbasak: I can try the release version in a devirt PPA without proposed enabled.
[21:28] <rbasak> Thanks. Note I haven't tried the release version at all yet.
[21:29] <rbasak> pinba I'm the most concerned about right now.
[21:36] <infinity> rbasak: https://launchpad.net/~adconrad/+archive/ubuntu/staging/+packages
[21:36] <rbasak> Thanks, I'll watch it.
[21:36]  * rbasak goes to bed
[21:36] <rbasak> (check it in the morning I mean)
[21:37] <infinity> rbasak: Anything runtime you need to check, or if it's correctly-linked and doesn't FTBFS, do you want to call it good?
[21:47] <rbasak> infinity: if it doesn't FTBFS I'm calling it good.
[21:47] <infinity> rbasak: Well, no such luck there .:)
[21:47] <infinity> rbasak: Will have to look later.  But it's broken right now.
[21:49] <rbasak> powerpc and s390x are already broken in the release pocket. Looks like ppc64el is a regression though.
[21:51] <infinity> mvo: Are you eating or sleeping between these snapd releases?
[22:01] <mvo> infinity: no
[22:01] <mvo> infinity: but fortunately there is a deadline
[22:02] <mvo> infinity: I mean, the end is near and all that
[22:02] <mvo> infinity: thanks and sorry for the bombardment