[00:01] seb128: ah, there was a problem with a repo [00:01] seb128: it seems like something other people will run into though [00:01] bdmurray, k, so gnome-software should handle that better [00:01] yeah [00:01] shouldn't impact the default install though [00:02] so probably fine to fix in a sru [00:08] infinity, I've just seen you release freeze email. [00:08] I've got a number of bugs fixes in the sponsor queue, is there any reason I can have those included? [00:16] 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] 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] seb128: I do not; see LP: #1521299 [00:58] Launchpad bug 1521299 in freetype (Ubuntu) "Please merge freetype 2.6.3-3 from Debian testing" [Wishlist,Triaged] https://launchpad.net/bugs/1521299 [01:12] slangasek, k [02:42] flexiondotorg: You can get them in, just be quick about it. === superm1_ is now known as superm1 === slangase` is now known as slangasek [03:50] Good morning [03:51] 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] 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] yeah, that's what I thought :) [03:56] stgraber: I thought for classic lxc 1 nesting should work OOTB; do I need to enable anything specific for that? [03:56] I have a custom apparmor profile which allows mounting [03:57] wgrant: hey, how are you? [03:57] depending on kernel you may also need an extra include for the nesting.conf file we ship in /usr/share [03:57] wgrant: can we do that full langpack export now? (the "full" box is ticked) [03:57] stgraber: trusty kernel for armhf (newer ones don't boot on the calxeda) and xenial kernel for s390x [03:59] pitti: For xenial? Sure. [03:59] wgrant: right, for xenial [04:36] pitti: Eh? Newer ones don't boot on Highbank? Since when? [04:36] 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] pitti: If that regressed, it was an accident, not intentional. [04:36] 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] pitti: So we lost a CONFIG in a rebase, probably. I wish someone had mentioned it. [04:37] actually maybe that's moot [04:37] hallyn: It should be able to be any path, surely? [04:39] libc seems to only do paths under /dev [04:39] 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] really i guess it's the same question as the one raised by pt_chown [04:40] .. to which the answer is surely "More booze!" [04:41] it might be [04:41] \o/ [04:41] 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] 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] oh i can, [04:43] nope, wrong again [04:44] drat so now i have to go through and actually read that long thread again. [04:45] I don't see any systemcalls that look helpful; I'm not sure this is a solvable problem [04:46] you may not be able to do a 100%-correct job on this one [04:46] hallyn: can't stat it? [04:47] that's what i was trying - ah yeah the major/minor are actually helpful [04:48] 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] 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] if not the same, then still return "/proc/self/fd/0" [04:48] should work [04:48] yep [04:49] .. can you check that the /proc/self/fd/0 is actually a tty device? [04:49] it already does that [04:49] yeah, libc actually does that part right [04:49] so what libc does right now is readlink the name, then stat the result. [04:49] if that gives -ENOENT then it returns null. else it returns the link value [04:49] but both of those can be wrong [04:50] 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] ok, so my patch will add some overhead, but i think it's worthwhile [04:50] heh [04:50] hallyn: ttyname isn't something that's called all that often, a tiny overhead to have it DTRT should be fine [04:51] .. and heck even if it is called all the time, being correct may be that much more important :) [04:51] agreed. i'll try to get that and the new kernel patch sent tomorrow [04:51] heh, yeah [04:52] in fact it also will fix the "other kerfuffle which will not be named" [04:52] all right, to the batcave. thanks gents. [04:52] also leaving for the night, talk to you tomorrow [04:53] \o === dax is now known as dank === dank is now known as dax [05:36] good morning [05:50] wgrant: just to confirm, is this running now? [05:51] pitti: Yep [05:51] wgrant: cheers [05:51] np [06:01] Can I request some sponsoring assistance please? [06:01] infinity, Has said I need to get my bug fixes in promptly. [06:01] They are mostly Syncs from Debian and some small updates. [06:02] https://bugs.launchpad.net/ubuntu/+source/mate-menu/+bug/1570554 [06:02] Launchpad bug 1570554 in mate-menu (Ubuntu) "Sync mate-menu 5.7.1-1 (universe) from Debian unstable (main)" [Undecided,New] [06:02] https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1570652 [06:02] Launchpad bug 1570652 in ubuntu-mate-welcome (Ubuntu) "ubuntu-mate-welcome 16.04.8 bug fix and translations [dsc attached]" [Undecided,New] [06:02] https://bugs.launchpad.net/bugs/1569732 [06:02] Launchpad bug 1569732 in caja-dropbox (Ubuntu) "Sync caja-dropbox 1.12.0-3 (multiverse) from Debian unstable (non-free)" [Undecided,New] [06:03] https://bugs.launchpad.net/bugs/1569731 [06:03] Launchpad bug 1569731 in mate-tweak (Ubuntu) "Sync mate-tweak 3.5.10-1 (universe) from Debian unstable (main)" [Undecided,New] [06:03] https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1569320 [06:03] Launchpad bug 1569320 in ubuntu-mate-settings (Ubuntu) "ubuntu-mate-settings 16.04.5 release [.dsc included]" [Undecided,New] [06:03] flexiondotorg: Have you given any thought as to whether MATE will be an LTS release for 16.04? [06:03] https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-meta/+bug/1568773 [06:03] Launchpad bug 1568773 in ubuntu-mate-meta (Ubuntu) "Please update ubuntu-mate-meta package" [Undecided,New] [06:03] infinity, Yes, we are absolutely doing LTS. [06:04] https://bugs.launchpad.net/ubuntu/+source/x2goclient/+bug/1569310 [06:04] Launchpad bug 1569310 in x2goclient (Ubuntu) "FFe: Sync x2goclient 4.0.5.1-1 (universe) from Debian unstable (main)" [Undecided,New] [06:04] 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] That is my sponsor requests. [06:04] infinity, Yeah, this is new. [06:04] We just assumed we'd be doing 5 years. [06:04] And thet is what we're up for. [06:05] infinity, I've posted all most sponsoring bugs above. Any chance you can process those? [06:05] 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] 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] infinity, OK, will send mail later. [06:06] infinity, So if I can another sponsor to process my bugs that is fine right? [06:06] infinity, All that is required is to unblock them? [06:07] 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] infinity, OK. I'll give that some thought. [06:08] 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] What constitutes the MATE bit in Ubuntu MATE is actually very small. [06:08] flexiondotorg: If they're massively FFe-breaking gross, not so much. [06:08] infinity, Everything is a fix. [06:09] infinity, In the spirit of your email adding these fixes will make Ubuntu MATE "good enough". [06:09] 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] flexiondotorg: But your call, obviously. Last LTS, the flavours were split about 50/50 on 3/5. [06:10] infinity, So one deployment we know we'll have is for several large remote terminal server deployments. [06:10] inaddy, Hence the x2goclient FFe. [06:11] infinity, For how many years are point release images mades? Like 16.04.1, 16.04.2 etc. [06:13] flexiondotorg: Last point release is 16.04.5, which coincides (within a week or so) with 18.04.1 [06:13] flexiondotorg: Which is ~3mo after 18.04 release. [06:14] flexiondotorg: So, after that, it's just SRUs for critical fixes, but no more installer validation and ISO madness. [06:14] OK, so with in the 3 year LTS window. [06:14] It would seem 3 years is sufficient then. [06:15] I'll discuss with the X2Go guys. [06:15] Do I need to file a plan for 3 year LTS? [06:16] 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] 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] infinity, Thanks for the advice. [06:31] dholbach, is there an existed FFe for seeding snappy? or do I need to file one? [06:32] darkxst, When I did it I filed an FFe just for Ubuntu MATE. [06:33] 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] infinity, ok cool, will do [06:34] infinity, Can you refresh ubuntu-mate-meta please? https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-meta/+bug/1568773 [06:34] Launchpad bug 1568773 in ubuntu-mate-meta (Ubuntu) "Please update ubuntu-mate-meta package" [Undecided,New] [06:34] It's a tiny update. [06:35] flexiondotorg: Refreshing. [06:35] infinity, ty! === athairus is now known as afkthairus [06:47] flexiondotorg: I don't see any cheesiness in that update (thought I do see some other bits) [06:48] Wait, no. [06:48] I see no changes. [06:48] I'm not awake enough. :P [06:50] flexiondotorg: Oh, that bug is ancient. I've uploaded your meta much more recently. [06:50] * infinity just closes it. [07:07] infinity, can you take a look at the casper part on bug 1561302 ? [07:07] bug 1561302 in casper (Ubuntu) "gdm won't allow passwordless login" [Critical,Triaged] https://launchpad.net/bugs/1561302 [07:08] 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] stgraber: ok, lxd is now running for autopkgtests :) (https://plus.google.com/+MartinPitti/posts/QJnjsUci4Wi) [09:39] Laney: ^ FYI [09:42] apw, jdstrand: do you have an interpretation of the regression in http://autopkgtest.ubuntu.com/packages/l/linux/xenial/ppc64el/ ? [09:42] that openssl version should be a functional no-change (just some patch cleanup) [09:43] pitti: nice [09:43] are the SS instances long running? [09:44] Laney: well, they tend to auto-destruct after a day or two [09:44] Laney: but in principle they are meant to, yes [09:44] ya, that bug [09:44] 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] Laney: (for nova boot --userdata) [09:45] 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] but it can help with the backlog for sure [09:45] and we can collect some experience with hit [09:45] it [10:00] mvo: FYI, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd regression [10:06] pitti: did anything in infrastucture change? it looks like an io error/timeout from a store download [10:07] mvo: not that I know of; something could have changed in the scalingstack config behind my back of course [10:07] 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] pitti: interessting [10:08] and that's consistent across all arches === kees_ is now known as kees [10:09] 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] ah, that would explain it indeed then [10:09] mvo: store access might not work through a proxy then? [10:10] we set http_proxy and friends in /etc/environment and in the test env [10:10] pitti: thats possible, I don't think we tested this [10:10] pitti: let me check that, thanks, thats useful [10:11] mvo: we can also give you access to a production instance where this fails, if needed [10:11] but I'm running out of time today (I took half-day off, need to run in 3 mins, sorry) [10:11] pitti: that would be nice, I suspect its because we use https for everything [10:11] if Laney has time he might be able to help [10:11] pitti: ok, who else could help? [10:11] mvo: we set https_proxy too [10:11] pitti: ta [10:12] pitti: run and thanks for your help [10:12] 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] you can't directly ssh from outside to a scalingstack instance [10:34] nacc: libvirt-php is building and passing the php extension build system tests [10:34] on php7 [10:38] nacc: so once you build a ppa package, I can test it === hikiko is now known as hikiko|ln === hikiko|ln is now known as hikiko [12:08] hi, question: today is the last day to sync stuff from debian? [12:08] correct? [12:09] LocutusOfBorg: if seeded, then we're already past final freeze. The release team will consider essential fixes though, see the announcement. [12:10] rbasak, I *need* to have virtualbox in [12:10] :) [12:10] xorg 1.18 fixes, and kernel too [12:10] as usual, I have to break stuff [12:10] damn broken dinstall [12:12] can't ubuntu sync from incoming.d.o? (citation needed) [12:12] LocutusOfBorg: you can still sync, subject to the freeze criteria. I believe. [12:12] sync from incoming? [12:13] No, I don't think that works. === shuduo is now known as shuduo-afk [12:13] :( [12:13] Launchpad needs to have imported into launchpad.net/debian for sync to work, AIUI. [12:13] --no-lp? [12:13] I don't know. [12:13] I tried once, but failed [12:13] You could just upload what you uploaded as an Ubuntu delta. It wouldn't make any difference now this close to release. [12:14] (though you'll need to sync once again in X+1) [12:14] I would like to avoid that, but yeah [12:14] with dak broken, if it can't wait for dak to be fixed, it would have to be manual in some way. [12:14] indeed [12:14] rbasak: there's always ~build1 or similar [12:14] cjwatson: ah, OK [12:14] 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] pitti: regarding http://autopkgtest.ubuntu.com/packages/l/linux/xenial/ppc64el/ it seems to have resolved itself? === shuduo-afk is now known as shuduo [12:28] hi, is secureboot implemented in 16.04? will it warn user if a unsigned kernel is loaded? [12:29] i am referring to Launchpad bug 1401532 [12:29] Launchpad bug 1401532 in grub2 (Ubuntu) "GRUB's Secure Boot implementation loads unsigned kernel without warning" [Wishlist,In progress] https://launchpad.net/bugs/1401532 === _salem is now known as salem_ [12:53] 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] i noticed https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1569590 but it's not an ath* device on my machine [12:55] Launchpad bug 1569590 in network-manager (Ubuntu) "wireless card disabled in network-manager" [High,Triaged] === shuduo is now known as shuduo-afk [13:24] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815633 please update the symbols file ... solution: remove it :-/ [13:24] Debian bug 815633 in ilmbase "ilmbase: symbols file update for kfreebsd" [Important,Fixed] [13:34] superm1: right [13:34] hmm, the openexr test failure succeeds locally [15:07] Pharaoh_Atem: ack, thanks [15:18] nacc: no problem [15:21] Pharaoh_Atem: was that the version in unstable? -- aka can you check debian unstable as it is now? [15:23] pitti: how do you want patches to autopkgtest? [15:23] nacc: give me a second, I'll check [15:24] Pharaoh_Atem: thanks, it might still be publishing tbh, but rmadison shows a newer version in usntable from what we saw yesterday === Spads_ is now known as Spads === nobuto_ is now known as nobuto === kgunn is now known as Guest72262 [15:36] nacc: it's a slight fork [15:36] nacc: http://anonscm.debian.org/cgit/pkg-php/libvirt-php.git/log/ [15:36] it doesn't yet match upstream [15:36] also, I've figured out where those weird git hashes are coming from [15:37] 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] Pharaoh_Atem: ah ack, makes sense [15:39] personally, not a fan of that [15:40] it makes things more complicated then it needs to be === Trevinho_ is now known as Trevinho [16:07] Are there any other repos besides the Ubuntu one that support by-hash? I'm wondering if I implemented it correctly. [16:07] Unit193: not to my knowledge [16:07] well, PPAs support it too, but same code [16:07] Unit193: there's https://wiki.debian.org/RepositoryFormat#indices_acquisition_via_hashsums_.28by-hash.29 [16:09] bdmurray, hey, did you see bug #1570947 [16:09] bug 1570947 in ubuntu-release-upgrader (Ubuntu) "Trusty to Xenial upgrade KeyError: 'SUDO_UID'" [Critical,Confirmed] https://launchpad.net/bugs/1570947 [16:09] seems to be due to the landing you did today with the change from darkxst [16:09] jibel, willcooke, ^ [16:10] cjwatson: Ah, re-reviewing did answer it, thanks. [16:12] Unit193: Cool. The tricky bit is dealing with expiry, which depends how clever you want to be. [16:12] Indeed, no idea how I'm going to deal with that one. [16:14] 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] seb128: I didn't, thanks [16:14] Unit193: The algorithm in LP isn't (I think) too hard to read if you want inspiration. [16:15] hallyn, I'd say there's worse people to be added ... :) [16:15] Might be handy. [16:16] wish we had an official UDD-style tree [16:16] 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] ByHashes (and its child ByHash) is defined further up in that file. [16:18] ArchiveFile is in lib/lp/soyuz/model/archivefile.py, although the details are quite LP-specific. [16:18] (http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/soyuz/model/archivefile.py) [16:19] 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] stgraber: sarnold: fwiw http://sourceware.org/ml/libc-alpha/2016-04/msg00391.html. [16:19] sourceware.org bug 2016 in libc "argp --help infloop, via ARGP_HELP_FMT envvar" [Normal,Reopened] [16:19] 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] Launchpad bug 1531864 in Release Notes for Ubuntu "HTTP/2 disabled in Apache httpd" [Undecided,New] [16:19] let's see hwo i get roasted [16:20] ubottu, go home, you're drunk [16:20] hallyn: I am only a bot, please don't think I'm intelligent :) [16:21] infinity: see http://sourceware.org/ml/libc-alpha/2016-04/msg00391.html I mentioned that issue here a little while back [16:21] sourceware.org bug 2016 in libc "argp --help infloop, via ARGP_HELP_FMT envvar" [Normal,Reopened] [16:21] darkxst: you might be interested in bug 1570947 [16:21] bug 1570947 in ubuntu-release-upgrader (Ubuntu) "Trusty to Xenial upgrade KeyError: 'SUDO_UID'" [Critical,Confirmed] https://launchpad.net/bugs/1570947 [16:23] bdmurray, it's like 2am for him so I doubt he's going to be around [16:23] 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] bdmurray, maybe cyphermox or infinity can help you there? [16:24] 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] 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] alkisg: which would get them the backported package [16:26] 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] 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] OK, ty [16:28] 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] dholbach: mate-menu> snap [16:33] rbasak, that is not how to create snap packages :P [16:34] heh [16:34] one day ... [16:35] ogra_`: ? [16:35] stgraber: How is that not a kernel/namespace bug? [16:35] Oh [16:35] :) [16:35] :) [16:35] stgraber: Why would /proc/self/* ever point to something in another namespace? [16:36] infinity: you can absolutely pass fds between namespaces, or in this case have an open fd before switching to another namespace (setns) [16:37] 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] 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] 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] 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] stgraber: Yes, hence my assertion that this is a kernel bug. :P [16:40] stgraber: I'm not sure how returning the link to (effectively) nowhere is significantly more helpful than the current broken behaviour. [16:40] stgraber: You still can't use it for anything. [16:40] infinity: because you can absolutely open /proc/self/fd/0 and it'll work fine [16:41] Even if it's a symlink to a file that doesn't exist? [16:41] yep [16:41] *raise brow* [16:41] infinity: http://paste.ubuntu.com/15853488/ [16:42] 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] infinity: the fix hallyn submitted fixes the "tty" command, as well as screen, byobu, ... anything which uses ttyname [16:42] (woot) [16:43] 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] infinity: the kernel knows but it can't show you that path [16:43] infinity: that path is completely outside the scope of your container so you can't possibly reach it [16:43] 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] stgraber: And show fd/0 as a file instead of a link. [16:44] stgraber: Anyhow, meh. Also obviously not a glibc regression, so we'll get there if we get there, or SRU later. [16:45] 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] (or well, a symlink looking thing) [16:46] 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] rbasak: huh? with git, mut far from kbd until sunday [16:56] tjaalton: OK. Well, it went wrong. Thought you should know. [17:00] ok, can't check what went wrong [17:00] sorry === ogra_` is now known as ogra_ [17:25] 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] "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?" === mjeanson_ is now known as mjeanson === ]reed[ is now known as [reed] === Punna is now known as Pwnna [17:31] 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] hallyn: But feel free to challenge Florian on security concerns. [17:31] hallyn: Most of the time, you'll be wrong, but he can take a healthy debate. [17:33] geez ... doing a do-release-upgrade with the canonical vpn enabled is really badly killing bandwidth [17:34] infinity: yeah i think i'm cranky from a too-much-email morning; i'll replywhen i'm not whiny [17:40] hallyn: nice patch. pity about the coding standards, I like your version just fine ;) [17:40] 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] 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] hallyn: if it were longer I might have come to the same conclusion :) === sforshee` is now known as sforshee [17:58] still wonder whether i should also do it for ptsname.c. i probably should. [17:59] that's the most immediately obvious security relevant one [18:04] wowzer: [18:04] Please use formfeed characters (control-L) [18:04] to divide the program into pages at logical places (but not within a function). === barry` is now known as barry [18:07] I'm still stunned whenever I see that in source [18:08] Well, it's handy if you want to print out the source :-P === rbasak_ is now known as rbasak [18:08] (you do that, right?) [18:08] what? I don't think I've ever seen that [18:08] sarnold: what source, you've made me curious :) [18:09] I'm not sceptical, I just want to know which source to mock [18:09] mdeslaur: coreutils [18:09] I was reading nproc the other day.. [18:10] $ grep -r ^L . | wc -l [18:10] 1290 === manjo` is now known as manjo [18:12] 1290? wowzer [18:12] that grep is wrong, try again [18:12] hm, i may have lied to Florian. *can* i verify that the device is devpts? [18:13] yeah major should be never-changing [18:14] mdeslaur: it was umt download, so all releases.. and I used ^V^L of course to construct the ^L .. [18:14] mdeslaur: oh it's also got loads of cscope hits :/ [18:15] hah! I see them now...wow, insane [18:24] wtf. 'git checkout' just overwote my changes. normally it says 'no you have changes'... [18:25] ok i really *am* having a bad friday [18:38] Hello [18:39] 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] with ssh -v I see that it tries to use id_rsa but not id_dsa [18:40] is that a recent change because DSA is not considered safe anymore? [18:43] xclaesse: dsa is disabled in openssh 7.0 for security reasons, yes [18:44] xclaesse: you can re-enable it, see here: http://www.openssh.com/legacy.html [18:44] xclaesse: or ideally use rsa or something else [18:45] mdeslaur, ok thanks [18:45] 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] xclaesse: yeah :) [18:48] 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] mdeslaur: lol [18:52] mdeslaur: please make sure it fits on 3x5 index cards. [18:55] sbeattie: I used to own one of these: http://i.ebayimg.com/00/s/MTIwMFgxNjAw/z/8OMAAOSwaA5WkxOq/$_12.JPG?set_id=880000500F [18:56] no linefeeds necessary :) [18:56] hehe [18:56] wow, 24, 32, _and_ 40 columns? [18:57] whoaaa === chuck__ is now known as zul [19:09] sarnold: used to? wtf! === AndyTechGuy_ is now known as AndyTechGuy [19:29] hallyn: I no longer have it. I'm such a fool. I called it...Rosebud. [19:39] 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] mdeslaur: yeah, there are a few things i wish i'd never given up :) [19:43] seb128: no [19:43] try to reset the online state too [19:46] cyphermox, install is ongoing atm, going to try once it's done [19:51] Pharaoh_Atem: so are you saying the debian version (pacakged already) is not complete? [19:59] nacc: no, it's not [19:59] in fact, it's got the wrong fix, according to Michal and Remi [19:59] it can cause stack mashing or something like that [20:03] 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] this gets better and better [20:03] hallyn: Do you want to go back to bed and try the day over? [20:03] ashwin: /boot/config* [20:03] so use 2 spaces for indent, but then use a tab if there are 8 spaces. check [20:04] hallyn: that alone is probably why we're not all using hurd right now. [20:04] 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] jibel, ^ [20:04] Unit193: maybe [20:04] is that an option? [20:05] sarnold: Thanks!! Gotta improve my google-fu :) [20:05] ashwin: it's not an easy one to search for [20:05] ashwin: the kernel team actually p7ublishes their configs somewhere, but I can never find the site when I want it [20:06] sarnold: i woulda sucked it up if i wasn't also chastised for unthinkingly adding a signed off by [20:06] hallyn: wha?? o_O they don't do the origin-thing/ [20:06] sarnold: I don't suppose you mean their git? (http://kernel.ubuntu.com/git/) [20:07] Unit193: probably this http://kernel.ubuntu.com/~kernel-ppa/configs/trusty/ [20:07] Unit193: my issues with git is something else entirely.. [20:08] nacc: that package needs to be rebased on the current git master [20:08]