[01:57] <Logan_> what is the easiest way to remove a file from the .diff.gz?
[02:00] <RAOF> filterdiff?
[02:03] <Logan_> good call
=== Ursinha-afk is now known as Ursinha
[02:37]  * mdeslaur learns about filterdiff
[04:37] <pitti> bdmurray: known issue, duped to bug 1362496
[04:37] <ubottu> bug 1362496 in base-files (Ubuntu-rtm 14.09) "LSB release and /etc/os-release still say "Utopic", needs to be RTM" [High,Triaged] https://launchpad.net/bugs/1362496
[04:38] <pitti> sarnold: hm, nothing stuck, let me check
[04:39] <pitti> sarnold: ah yes, I think I see the problem; I'll look into it
[04:39] <pitti> Good morning
[05:12] <andrewrk> is utopic going to update to the official libav 11 release? current version in utopic is 11~beta1
[05:46] <pitti> sarnold: I'm afraid I need to rebuild the apt-ftparchive db on ddebs.u.c., which takes painfully long :( (about 24 hours); I'm afraid the retracers will stay broken until then
[06:03] <YokoZar> oops, I let this sync request stagnate: https://bugs.launchpad.net/ubuntu/+source/libcdio/+bug/1361047
[06:03] <ubottu> Launchpad bug 1361047 in libcdio (Ubuntu) "Please sync libcdio" [Undecided,New]
[06:07] <Logan_> stagnation is sad
[06:30] <thopre01> Hi there
[06:31] <thopre01> I submitted a Feature Freeze Exception on 1st September and I was wondering if there is any chance it's going to be processed before the release
[06:32] <thopre01> (given the short time remaining before release)
[06:32] <thopre01> The FFe in question is for the ARM embedded toolchain: https://bugs.launchpad.net/ubuntu/+source/gdb-arm-none-eabi/+bug/1363788 https://bugs.launchpad.net/ubuntu/+source/libstdc++-arm-none-eabi/+bug/1363790 https://bugs.launchpad.net/ubuntu/+source/newlib/+bug/1363791 https://bugs.launchpad.net/ubuntu/+source/gcc-arm-none-eabi/+bug/1363792
[06:33] <ubottu> Launchpad bug 1363788 in gdb-arm-none-eabi (Ubuntu) "FFe: Sync gdb-arm-none-eabi 6 (universe) from Debian unstable (main)" [Undecided,New]
[06:33] <ubottu> Launchpad bug 1363790 in libstdc++-arm-none-eabi (Ubuntu) "FFe: Sync libstdc++-arm-none-eabi 4 (universe) from Debian unstable (main)" [Undecided,New]
[06:33] <ubottu> Launchpad bug 1363791 in newlib (Ubuntu) "FFe: Sync newlib 2.1.0+git20140818.1a8323b-1 (universe) from Debian unstable (main)" [Undecided,New]
[06:33] <ubottu> Launchpad bug 1363792 in gcc-arm-none-eabi (Ubuntu) "FFe: Sync gcc-arm-none-eabi 11 (universe) from Debian unstable (main)" [Undecided,New]
[06:59] <dholbach> good morning
[07:00] <thopre01> Morning
[07:03] <LocutusOfBorg1> hi people
=== tarman is now known as zyga
[08:06] <apachelogger> stgraber: more lxc problems :) http://paste.ubuntu.com/8416404/  <-  this from an unpriv container start done through a daemon (jenkins) that was sudo started from a user other than the one owning the container
[08:07] <apachelogger> the execution env in both cases is exactly the same except for jenkins job variables, so I am not quite sure why it happens or how to prevent it (short of not restarting the daemon from other users anyway)
[08:49] <cjwatson> andrewrk: Yeah, we always intended to.  I've thrown a sync into the queue.
[08:50] <Laney> thopre01: I'll look at thos thanks for the pointer
[08:51] <Laney> gremlins ate my "e,"
[08:51] <thopre01> Laney: Thanks a lot
[09:32] <caribou> before I go and make a mistake, now that I have PPU rights for sosreport & my fixes are in Utopic, all I have to do for my SRU is to upload (using dput) to trusty-proposed & subscribe ubuntu-sru to the bug, right ?
[09:33] <caribou> and the difference b/w uploading to debian & to ubuntu is that, with ubuntu I upload the *source.changes, no binary
[09:46] <RAOF> caribou: You don't actually need to subscribe ubuntu-sru to the bug; we'll process it from the unapproved queue.
[09:47] <caribou> RAOF: ah, ok. Old habbit
[09:47] <caribou> RAOF: so just the dput is enough
[09:47] <RAOF> Yup.
[09:48] <RAOF> Of course, you need to close the bugs from the changelog, but I presume you're doing that anyway :)
[09:49] <caribou> RAOF: yep, it was already in the utopic upload
[09:49] <caribou> hmm, rejected, no upload rights; looks like it has not been processed yet
[09:58] <pitti> caribou: upload rights are configured by release, I figure it was just forgotten to also add you to previous releases
[09:58] <pitti> (or maybe that's on purpose/by policy, I'm not sure)
[09:59] <caribou> pitti: maybe only because my PPU rights got voted on by the DMB monday & they did not have the time to act upon it
[09:59] <caribou> pitti: trying to upload was one way to check that out
[10:00] <caribou> pitti: & true, I did not try to upload to Utopic yet
[10:00] <pitti> caribou: ah, utopic is usually configured first; I thought the utopic upload worked and the trusty one didn't
[10:00] <pitti> caribou: so yes, probably not acted upon yet
[10:01] <caribou> pitti: no, it was sponsored to Utopic
[10:01] <caribou> pitti: but thanks for the details :)
=== MacSlow is now known as MacSlow|lunch
[12:31] <smoser> cjwatson, i had a question for you at https://bugs.launchpad.net/curtin/+bug/1373137 .
[12:31] <ubottu> Launchpad bug 1373137 in curtin (Ubuntu) "need to run update-grub when grub-install" [High,Triaged]
[12:32] <smoser> basically, after blatting a tarball to disk, is there some way that i can know when i need to run update-grub. it seemed that dpkg-reconfigure would sometimes run it.
[12:37] <cjwatson> smoser: subscribing me to the bug gives me more chance of seeing the question in mail :)
=== nik90 is now known as nik90|Lunch
[12:39] <smoser> cjwatson, i realized that i'd forgotten to subscribe you sometime in the middle of the night.
=== _salem is now known as salem_
[12:41] <cjwatson> answered, anyway
=== superm1_ is now known as superm1
=== dholbach_ is now known as dholbach
=== MacSlow|lunch is now known as MacSlow
=== smow is now known as pfsmorigo
=== nik90|Lunch is now known as nik90
[13:51] <smoser> cjwatson, so is just 'touch /boot/grub/grub.cfg' enough to convince dpkg-reconfigure to run update-grub ?
[13:51] <smoser> i do suspect that os_prober is what was slow (and i've disabled that when running it). but doing less is nicer if i can.
[13:59] <dholbach> pete-woods, everything all right? I'm not sure how I'm supposed to understand "Oh noes. The mod-bot got me!"? :)
=== gusnan_ is now known as gusnan
[14:02] <cjwatson> smoser: err I'm not sure, I suppose so, seems weird but if it produces sane output ...
[14:02] <stgraber> apachelogger: can you pastebin /proc/self/cgroup? I suspect that your current user doesn't own the cgroup it's in and so can't create the cgroups required for lxc
[14:02] <cjwatson> it's just a test -e
[14:02] <cjwatson> smoser: I'm pretty sure os-prober can be sped up, that said :)
[14:03] <pete-woods> dholbach: oh, the auto moderation bot rejected it because of the accounts policy
[14:03] <cjwatson> I made a start on that last week, but I have ninety concurrent things to do so it hasn't got too far yet
[14:03] <pete-woods> dholbach: although I still got an email saying it was published
[14:03] <dholbach> beuno, ^
[14:03] <smoser> cjwatson, thats fine. this is low priority. i'm worried about saving a couple seconds. not a big deal. thanks for your help.
[14:03] <apachelogger> stgraber: earliest in 12 hours or so, assuming that is the case is there any way to make sure this doesn't happen?
[14:05] <cjwatson> smoser: it was annoying me because I was debugging a crash so running it over and over again ...
[14:05] <pete-woods> dholbach: I'm hoping you're still able to override the "accounts" failure, like happened the previews few times
[14:05] <dholbach> pete-woods, Approved version:1.0.12
[14:05] <dholbach> The last submitted upload (1.0.13) failed review.
[14:05] <dholbach> hum hum
[14:05] <dholbach> I can't see how to override it
[14:05] <beuno> pete-woods, I'll take a look
[14:05] <dholbach> thanks a bunch
[14:05] <pete-woods> :)
[14:05] <dholbach> beuno, if you'd prefer I ping somebody else about it, let me know
[14:06] <stgraber> apachelogger: your best bet is to fix the permissions of the cgroup before dropping privilege to that user, you can do that with something like:
[14:06] <stgraber> apachelogger: cgm create all <username>
[14:06] <beuno> pete-woods, link?
[14:06] <stgraber> apachelogger: cgm chown all <username> <uid> <gid>
[14:06] <stgraber> apachelogger: cgm movepid all <username> $$
[14:06] <apachelogger> it's a cgroup problem http://paste.ubuntu.com/8418342/
[14:07] <stgraber> apachelogger: that'll move the current process (your shell) into a newly created batch of cgroups that are owned by the user you'll be switching to
[14:07] <apachelogger> stgraber: I do wonder, shouldn't sudo su $user adjust the cgroup accordingly?
[14:07] <pete-woods> beuno: this is app number 971 (youtube scope). it's been uploaded to the store at version 1.0.13 and the auto moderation bot as failed it because it uses the accounts policy group
[14:07] <smoser> cjwatson, and for this particular use case, my solution of chmod -x is perfectly fine.
[14:07] <cjwatson> yep
[14:08] <stgraber> apachelogger: it's something we've been wondering and I believe it'd make sense but I guess that's not happening because sudo doesn't go through the right parts of the PAM stack and so logind never creates a new session
[14:08] <smoser> as i dont *want* it to find other operating systems. i just installed the one i want.
[14:08] <pete-woods> beuno: but dholbach can't seem to override this fail like has happened previously
[14:08] <smoser> thanks again
[14:08] <apachelogger> stgraber: I see
[14:08] <stgraber> apachelogger: so ultimately that's a logind problem and not one we felt confident working around in Ubuntu as it's probable that some stuff depends on that behavior
[14:08] <apachelogger> *nod*
[14:08] <pete-woods> beuno: if you're not familiar, the accounts profile group is only currently allowed for canonical / trusted scopes
[14:09] <stgraber> apachelogger: for one thing, if we were to do that, any process you spawn through sudo in your session will not be linked to your session anymore and so will not be killed at exit time (if you have that logind option enabled)
[14:09] <beuno> pete-woods, right, we're working out the kinks with these auto-reviews
[14:09] <beuno> sorry about that
[14:09] <beuno> let me fix this for you
[14:10] <pete-woods> beuno: the weird part, is that I still got an email saying my app had been published. even though the bot failed it
[14:10] <beuno> pete-woods, indeed, that sounds like a bug
[14:12] <cjwatson> smoser: (GRUB_DISABLE_OS_PROBER=true in /etc/default/grub or /etc/default/grub.d/foo is simpler, though.)
[14:13] <beuno> pete-woods, the email bug is known and in progress, I'll figure out why it was left as rejected, and how to approve it while we fix and deploy it
[14:14] <smoser> cjwatson, and that will work for 12.04 + ?
[14:14] <smoser> then that is great.
[14:16] <cjwatson> smoser: Yes.  Added in GRUB 1.98.
[14:16] <smoser> gracias. and do you recommend me doing that in /etc/default/grub
[14:16] <smoser> or in /etc/grub/default.d/file.conf
[14:16] <cjwatson> smoser: s/conf/cfg/, but I'd recommend the latter.
[14:17] <smoser> that is 12.04 also i think .right ?
[14:21] <beuno> pete-woods, I approved it
[14:21] <beuno> pete-woods, can you verify for me that the package you get on the phone is correct?
[14:21] <beuno> I did something... "innovative" to get around this bug
[14:22] <cjwatson> smoser: yes
[14:22] <cjwatson> smoser: (I SRUed that)
[14:24] <smoser> cjwatson, ok. last bother i promise. do you suggest updating GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub or putting that in default.d also
[14:25] <xnox> argh I hate gnutls =) specifically old gnutls https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1373422
[14:25] <ubottu> Launchpad bug 1373422 in gnutls26 (Ubuntu) "gnutls fails to connect to https://01.org in trusty" [Undecided,New]
[14:26] <xnox> looks like gnutls26 decides not to trust if intermediate certificate is not trusted, or some such. Any idea as how to best resolve that issue?
[14:26] <cjwatson> smoser: if you can keep /etc/default/grub pristine then that will cut down on swearing later
[14:26] <xnox> given that mass upgrading trusty to gnutls28 by default is not an option.
[14:26] <cjwatson> smoser: although for GRUB_CMDLINE_LINUX_DEFAULT I think the scripting is supposed to handle it ...
[14:27] <cjwatson> it's rather fragile though, it's really the one bit of the grub2 packaging I haven't yet summoned the fortitude to understand in totality
[14:27] <smoser> cjwatson, agreed. i've been through the swearing. and i figure i'll still have more at some point. but thank you for your advice.
[14:27] <cjwatson> smoser: but d-i updates GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub directly so we have to deal with that in any case
[14:28] <pete-woods> beuno: thanks, just going to have a look now
[14:30] <pete-woods> beuno: okay, cool, that looks good :)
[14:30] <beuno> pete-woods, sweet. We've found the bug (that check wasn't marked as a manual review step), we'll fix it and deploy tomorrow
[14:30] <beuno> so it shouldn't happen again
[14:31] <beuno> it won't get auto-approved as it requires a special permission
[14:31] <beuno> and we haven't gotten to whitelisting permissions
[14:31] <pete-woods> sure, that's fine, as long as it doesn't stop the manual moderators from overriding :)
[14:32] <beuno> jdstrand, I'm going to mark that one as a manual review in the scripts  ^
[14:48] <smoser> cjwatson, just fyi, this change is going to actually fix my issue with petiboot, i'm pretty sure.  i found about this because there was no /boot/grub/grub.cfg , and i'm pretty certain that petiboot was loading/parsing that file. so it did not know of my installation as that file wasn't getting created.
[14:50] <cjwatson> smoser: that would certainly make sense
[14:54] <juliank> Security people, please take a look at the privilege dropping in APT and tell us if you find any error; thank you: http://anonscm.debian.org/cgit/apt/apt.git/tree/apt-pkg/contrib/fileutl.cc?h=debian/experimental#n2176
[14:55] <juliank> That's inspired by tor's switch_id code, but only checks for errors.
[14:55] <juliank> and does not log success
[14:56] <juliank> We'll probably also put it in a seccomp sandbox for even more security
[14:56] <juliank> (It = The methods fetching files)
[14:59] <RoyK> how can I get bug 1364091 fixed? the solution is there...
[14:59] <ubottu> bug 1364091 in mdadm (Ubuntu) "Possible RAID-6 corruption" [Undecided,Confirmed] https://launchpad.net/bugs/1364091
[15:00] <kdeuser56> cjwatson: os-prober does not detect ubuntu installs that have a btrfs root file system
[15:01] <kdeuser56> cjwatson: regardless if mounted or not
[15:03] <cjwatson> kdeuser56: yes, that's a bug, just not one it looks like I'm going to have time to fix
[15:06] <kdeuser56> cjwatson: remeber the bug number?
[15:06] <cjwatson> no, sorry
[15:06] <kdeuser56> cjwatson: maybe https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/1294638 ?
[15:06] <ubottu> Launchpad bug 1294638 in os-prober (Ubuntu) "os-prober does not detect ubuntu installations in btrfs subvolumes with EFI partitioning" [Undecided,Confirmed]
[15:06] <cjwatson> I guess
[15:06] <cjwatson> I'm doing about five other things
[15:06] <kdeuser56> cjwatson: hm ... someone other with commit access and the skills to fix it?
[15:07] <cjwatson> commit access doesn't matter, send patches
[15:07] <kdeuser56> cjwatson: ok, one question though: did os-prober in ubuntu ever support detecting subvolumes on btrfs partitions?
[15:08] <cjwatson> I'm sorry I don't remember right now
[15:08] <kdeuser56> cjwatson: is there one common upstream for os-prober or does every distro develop their own?
[15:08] <cjwatson> I don't have the attention available to think about this
[15:08] <cjwatson> it's developed as part of the debian-installer project, in Debian
[15:08] <cjwatson> that is the one common upstream
[15:09] <kdeuser56> cjwatson: then I guess that fedora patch did never go upstream: https://bugzilla.redhat.com/attachment.cgi?id=676324&action=diff
[15:10] <cjwatson> I don't know, did they send it?
[15:10] <cjwatson> that's a fairly fearsomely large patch
[15:11] <kdeuser56> cjwatson: it seems not ... they changed the output format of os-prober (common.sh)
[15:11] <cjwatson> kdeuser56: looks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688336
[15:11] <ubottu> Debian bug 688336 in os-prober "update-grub finds only one system on btrfs volume" [Normal,Open]
[15:13] <kdeuser56> cjwatson: ah thanks ... the patch is proposed there ... a shame no one integrated it :-(
[15:24] <kdeuser56> cjwatson: ok thanks again ... it seems fedora is using the patch already for its last two major releases ... I'll download and test fedora, afterwards report back on the debian bug report, thanks!
[15:31] <pete-woods> cjwatson: you're a distro-ish kinda person. so random question here. we noticed that the package libunity-core-6.0-9 is no-longer on the devel-proposed phone images, but it is on the RTM ones still
[15:31] <pete-woods> cjwatson: it provides some icons that the scopes use
[15:31] <pete-woods> so now it's gone, it means that some fallback icons (for albums with no art, for example) don't appear
[15:32] <cjwatson> shouldn't you depend on it if you need it?
[15:32] <pete-woods> do you know how I can find out why / where it went?
[15:32] <pete-woods> well that's a fair point
[15:32] <pete-woods> so we should install-depend on it, and it'll come back then, seems fair I guess
[15:32] <cjwatson> although its ABI keeps changing of course; icons shouldn't be in an ABI-versioned package like that
[15:32] <cjwatson> I don't know why it went away; I assume all its dependencies went away
[15:33] <cjwatson> all the packages that depend on it, that is
[15:33] <pete-woods> okay, just wanted to check it wasn't purged intentionally
[15:33] <cjwatson> this sort of thing is not generally micromanaged, it's controlled by dependencies
[15:33] <cjwatson> I can find out what happened if you really need it but it will take about half an hour to track it all down
[15:34] <pete-woods> no, that's fine, just wanted to check it wasn't on someone's kill list
[15:34] <cjwatson> doesn't work that way :)
[15:34] <cjwatson> looks like it first disappeared in http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20140920/ if that helps
[15:35] <pete-woods> thanks for the info :)
[15:35] <cjwatson> hm, no, http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20140919.1/
=== salem_ is now known as _salem
[15:40] <cjwatson> pete-woods: actually, you know what, I got curious and that wasn't too hard to find.  It dropped out because of http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/1276
[15:46] <pete-woods> cjwatson: awesome, thanks. turns out that we only need a single icon from that package. so would seem a bit nuts to pull it in just for that. (so we'll probably leave it out)
[15:46] <pete-woods> but again, thanks for the help!
[15:48] <cjwatson> np
=== bladernr_ is now known as bladernr_30kFeet
[17:00] <infinity> pitti: Were those langpack uploads you?
=== ev__ is now known as ev
[17:17] <stgraber> pitti: I just posted my updated init scripts patch to the mailing-list now
[17:54] <sarnold> pitti: thanks for tending to the retracers :)
=== _salem is now known as salem_
=== roadmr is now known as roadmr_afk
[18:56] <seb128> jibel, I reassigned #1371651 to jodh, that doesn't seem to be a lightdm issue but an upstart/plymouth/udev/... one, I don't think desktop is going to tackle it
[18:58] <jibel> seb128, k
[19:11] <seb128> hum, the session indicator is listing hibernate for me in utopic, is that a known issue?
[19:11] <seb128> slangasek, pitti, whoever knows that stack, ^?
[19:11] <seb128> didn't we disable that by default some cycles ago?
[19:11] <slangasek> seb128: erm - I thought that was disabled at the level of the indicator itself
[19:11] <slangasek> so... it was desktop team ;)
[19:12] <seb128> slangasek, hum, I doubt we did
[19:13] <seb128> that would be tedious, it would mean patching the indicator, gnome-session, unity, lightdm, etc
[19:13] <slangasek> ok, I don't know then
[19:13] <seb128> didn't we change the polkit rights on the logind/upower actions?
[19:13] <seb128> http://ubuntuhandbook.org/index.php/2014/04/enable-hibernate-ubuntu-14-04/ suggests tweaking the polkit permissions to re-enable it
[19:13] <slangasek> I don't know, I wasn't involved
[19:14] <seb128> ok
[19:14] <seb128> I guess that's one for pitti then
[19:16] <seb128> slangasek, just for the record, http://launchpadlibrarian.net/83287567/policykit-desktop-privileges_0.7_0.8.diff.gz seems to be how it was done
[19:16] <seb128> there is also a similar change on the logind interface
[19:16] <slangasek> alright
[19:17] <seb128> that file still has
[19:17] <seb128> [Disable hibernate by default in logind]
[19:17] <seb128> Identity=unix-user:*
[19:17] <seb128> Action=org.freedesktop.login1.hibernate
[19:17] <seb128> ResultActive=no
[19:17] <seb128>  
[19:17] <seb128> I wonder if systemd changed
[19:18] <seb128> pitti, ^ I guess you are off for today, but a topic for tomorrow if you have some spare cycles to discuss that ;-)
=== roadmr_afk is now known as roadmr
=== salem_ is now known as _salem
[22:13] <xnox> mdeslaur: you win! I owe you beverages of your choice next time you are in London =)
[22:15] <xnox> mdeslaur: if I prepare gnutls update for trusty, would you take that into security pocket or updates only? given that it's effectively false negatives?
[22:15] <xnox> mdeslaur: everything works as expected now, after flipping the certs around.
[22:16] <xnox> bug #1371651
[22:16] <ubottu> bug 1371651 in lightdm (Ubuntu) "Daily does not boot into graphical interface after installation" [Critical,Triaged] https://launchpad.net/bugs/1371651
[22:35] <cjwatson> hallyn: How do I get cgmanager to let go of a mount?  I have a stale half-created schroot session that I want to kill off, whose only reference appears to be in /proc/27583/mounts, where that pid is cgmanager
[22:45] <hallyn> cjwatson: is that cgmanager one that was started inside the schrot?
[22:46] <hallyn> cgmanager shouldn't have any references to anyone else's mounts...
[22:46] <hallyn> just doing 'stop cgmanager' should be fine, cgmangaer doesn't keep any state
[22:48] <cjwatson> hallyn: I don't think so, /proc/27583/root -> /
[22:48] <cjwatson> but thanks, will try stopping it
[22:48] <cjwatson> oh I should perhaps mention that pid 1 is currently systemd
[22:49] <hallyn> cjwatson: /proc/pid/root always says it points to '/' :)
[22:49] <hallyn> check under /proc/27583/root/proc to see if it's the same as /proc
[22:50] <cjwatson> eh, no, /proc/pid/root can say other things if it's chrooted and you're looking at it from outside the chroot
[22:50] <cjwatson> anyway, too late, "sudo systemctl restart cgmanager" has cleared it up
[22:50] <hallyn> systemd version 208?
[22:50] <cjwatson> yeah, utopic
[22:50] <hallyn> hm
[22:51] <hallyn> (i ask bc then at lesat systemd didn't make /sys/fs/cgroup ro)
[23:07] <mdeslaur> xnox: oh, cool...with the patch, or you got the certs changed on the server?
[23:11] <xnox> mdeslaur: certs ordering got changed on half the servers, so i'm still pondering about the patch. And I don't like the thing posted on the mailing list = the flags constants values are different from 3.x, off by one.
[23:12] <sarnold> it'd be worth fixing the ordering, I understand firefox still enforces proper certificate order
[23:12] <mdeslaur> sarnold: oh? I didn't think nss cared about cert order
[23:12] <xnox> which is dangerous since 3.x DO_NOT_ALLOW_OUT_OF_ORDER, would become ALLOW_OUT_OF_ORDER, if one uses bitmasks/values instead of contants names.
[23:12] <mdeslaur> xnox: I see
[23:13] <xnox> and the tests have not been backported as part of that patch.
[23:13] <mdeslaur> yeah, the patch probably needs work
[23:15] <xnox> sarnold: we are only discussing bug in missconfigured servers vs old-gnutls. I can trivially test with curl compiled against each of the libraries. openssl passed, gnutls passes with 3.x, didn't test nss
[23:16] <xnox> but i think it handles out of order certchains fine.
[23:17] <sarnold> a friend was whinging two days ago about firefox and gnutls26 enforcing order and complained that "everyone else" (chrome, gnutls28, openssl) supported random ordering just fine...
[23:23] <mdeslaur> sarnold: huh...firefox and chrome both use nss...I was definitely under the impression it was a gnutls26 only thing
[23:23] <sarnold> mdeslaur: wonder why he was upset then :)
[23:23] <mdeslaur> usually it's because of git :)
[23:24] <sarnold> hahahaha
[23:27] <xnox> it is git in my case
=== timrc is now known as timrc-afk