[06:19] <pitti> Good morning
[06:44] <tsimonq2> o/ pitti, how are you? :)
[06:46] <pitti> tsimonq2: quite well, thanks! back home now. how about yourself?
[06:46] <tsimonq2> great :)
[07:36] <mwhudson> is there a way of producing the changelog merge-o-matic produces locally?
[07:41] <mwhudson> ah maybe ~rbasak/ubuntu-git-tools/git-reconstruct-changelog
[07:43] <mwhudson> no, more git-reconstruct-changelog
[08:04] <rbasak> mwhudson: also git-merge-changelogs? That's probably the trickier bit.
[08:26] <jamespage> doko, hey - my recent uploads for ryu address your original MIR review points for bug 1500950
[08:26] <jamespage> it would be nice to get that worked through if possible to unblock neutron from proposed migration
[08:27] <jamespage> :)
[09:25] <pitti> doko: is the python3-defaults in https://launchpad.net/ubuntu/trusty/+queue?queue_state=1 still actually relevant? bug 1348954 does not have a trusty task for it nor a description of the changes, and the changelog doesn't say either
[12:55] <xnox> on a side note - i really hate libvirt & qemu source code
[14:47] <jtaylor> speaking of it in 14.04->16.04 apparmor prevents libvirt from starting, missing capability net_bind_service
[14:54] <xnox> sarnold, ^
[15:21] <semiosis> Odd_Bloke: hey i was real busy with $dayjob yesterday and didnt have a chance to reply.  i'm really excited to see the merge accepted.  let me know what the next steps are if I need to do anything for the xenial SRU.  thanks!!!
[15:21] <Odd_Bloke> semiosis: So if you'd like to, I was hoping I could convince you to prepare the SRU patch. :)
[15:22] <Odd_Bloke> semiosis: (I have a sprint week of meetings next week, so will be unlikely to get to it any time soon)
[15:23]  * semiosis arm doesnt take much twisting
[15:23] <semiosis> i'll do it!  is there a doc I can read about the process?  any tips?
[15:24] <Odd_Bloke> semiosis: https://wiki.ubuntu.com/StableReleaseUpdates is the documentation.
[15:24] <Odd_Bloke> You'll need to get someone to target https://bugs.launchpad.net/cloud-images/+bug/1565985 to xenial (I don't have the powers, unfortunately).
[15:29] <semiosis> Odd_Bloke: thanks I'll read the docs.  how much longer will you be around today in case I have questions?
[15:31] <Odd_Bloke> semiosis: Around 90 minutes, though I'll probably see pings in IRC after that. :)
[15:48] <lfaraone> I'm intending to make update-initramfs reference https://help.ubuntu.com/community/Lubuntu/Documentation/RemoveOldKernels if the disk is full -- should I link to it directly (moved out of Lubuntu) or reference some other URL redirector?
[15:48] <lfaraone> I'm intending to make update-initramfs reference https://help.ubuntu.com/community/Lubuntu/Documentation/RemoveOldKernels if the disk is full -- should I link to it directly (moved out of Lubuntu) or reference some other URL redirector?
[17:30] <sarnold> jtaylor: that seems surprising, I've used libvirt remotely on 16.04 LTS without having to do anything.. got a bug number?
[18:01] <jtaylor> sarnold: do you have that cap in your apparmor file?
[18:06] <sarnold> jtaylor: no, there's no net_bind_service. Now I'm insanely curious..
[18:09] <jtaylor> sarnold: and its in enforce?
[18:11] <sarnold> jtaylor: yeah, and I can't spot any DENIED entries in my logs
[18:12] <jtaylor> sarnold: I'll try my desktop
[18:15] <jtaylor> hm I got a different apparmor profile
[18:17] <jtaylor> oh no it was just reorded by aa-logprof
[18:17] <jtaylor> and it works which is weird
[18:17] <jtaylor> maybe an upgrade from 14.04 leaves some configuration file which triggers some other behavior?
[18:23] <sarnold> it could be you've got a different libvirt config, I'm surely not a power user..
[18:34] <jtaylor> me neither, i'll file a bug with the logs
[18:34] <sarnold> thanks
[18:43] <jtaylor> sarnold: bug 1605727, ubuntu-bug was run on my desktop so its not the same as the affected machine
[18:45] <sarnold> jtaylor: do you have "network netlink," in your profile?
[18:46] <jtaylor> sarnold: the apparmor profile?
[18:47] <jtaylor> yes its in there
[18:49] <sarnold> ah, good. hmm.
[18:55] <nacc> Akuli: how did you decided on 50?
[18:56] <nacc> Akuli: are you 100% sure there are no commands that are 50 characters?
[18:56] <teward> nacc: I think we need to clarify "command" here
[18:56] <Akuli> just a random number
[18:56] <nacc> Akuli: that's probably not a suitable fix then :)
[18:56] <nacc> teward: it's whatever is passed to "command-not-found" afaict
[18:56] <teward> nacc: "If I enter an invalid command that is a few thousand characters long"  <-- what's the likelihood of this?
[18:56] <Akuli> but that part is easy to change, preferably it should be in a setting file
[18:57] <Akuli> well if someone else like me feels like hey i have boring lets try that :)
[18:57] <teward> nacc: right, but what's the likelihood of something thousands of characters long really being paseed through to the command-not-found?
[18:57] <Akuli> well
[18:57] <dobey> teward: cats do it all the time
[18:57] <Akuli> today i froze my system twice with that so
[18:57] <Akuli> there you go
[18:57] <teward> dobey: cats. :P
[18:57] <nacc> teward: it's any arbitrary string you type at the terminal, i think (by default)
[18:57] <teward> Akuli: not my point
[18:57] <nacc> teward: i'm *guessing* it's a page overflow
[18:57] <dobey> Akuli: why were you trying to type an arbitrary string that's so long into the terminal?
[18:58] <nacc> or some other buffer overflow
[18:58] <teward> nacc: right, but what's the practical likelihood that someone's going to have to type in 2000+ characters
[18:58] <Akuli> i have no idea :)
[18:58] <Akuli> i don't think its a buffer overflow
[18:58] <nacc> teward: practically, no, but it shouldn't crash the system if you do, right?
[18:58] <Akuli> i mean. its python
[18:58] <nacc> then why is it crashing your system?
[18:58] <Akuli> because there's no check for the length
[18:58] <nacc> you mean it OOMs your system?
[18:58] <dobey> its' not crashing the system
[18:58]  * teward grabs a lorem ipsum string 3000 long
[18:59] <Akuli> has spaces
[18:59] <dobey> it's making the system unusable
[18:59] <Akuli> won't do
[18:59] <Akuli> dobey, indeed unusable
[18:59] <nacc> dobey: ah, ok
[18:59] <Akuli> 5 minutes of fighting with running out of ram
[18:59] <sarnold> four seconds of looking four the executable /usr/src/linux-headers-4.4.0-21/tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh
[18:59] <dobey> well really, it should have a length equivalent to that of the filename length restriction
[19:00] <nacc> sarnold: :)
[19:00] <teward> E: Cannot Reproduce @ 1000, 2000.
[19:00] <Akuli> i have no idea what that is, people who know that better than i do can change that
[19:00] <nacc> dobey: ack, that seems most appropriate for a true fix
[19:00] <dobey> teward: you have too much RAM
[19:00] <dobey> teward: cat /dev/urandom | command-not-found
[19:01] <Akuli> i think their command searching function should be O(1) anyway
[19:01] <sarnold> *snort*  /usr/lib/x86_64-linux-gnu/ubuntu-system-settings/private/Ubuntu/SystemSettings/SecurityPrivacy/UbuntuSecurityPrivacyHelper
[19:01] <Akuli> not O(n) like it seems to be
[19:01] <nacc> dobey: is that 255 characters still? or is that the best common default (iirc, it's fs-specific)
[19:01] <teward> dobey: i'm doing this in a 512 RAM VM?
[19:01] <teward> at 6500+ and not able to reproduce
[19:02] <teward> with that low resources it should die off
[19:02] <Akuli> it needs to be command
[19:02] <Akuli> not arguments
[19:03] <teward> well
[19:03] <dobey> nacc: 255 sounds good to me
[19:03] <teward> it took 35 seconds for my 8GB system to run, and only took 400MB
[19:04] <dobey> Akuli: i think that's well understood :)
[19:04] <teward> dobey: 255 sounds good to me too, because what sane command would be more than 255 characters long
[19:04] <teward> excluding malware executable strings
[19:04] <dobey> teward: nothing sane is even that long
[19:04] <Akuli> um
[19:04] <Akuli> what sane program name would be more than 255 characters long
[19:04] <teward> Akuli: none.
[19:05] <Akuli> right
[19:05] <teward> dobey: then could we not use even less than 255?>
[19:05] <dobey> ones in german might have a "name" that long, but the exectuable command shouldn't be :)
[19:05] <teward> TBH
[19:05] <nacc> http://paste.ubuntu.com/20490401/
[19:05] <teward> I really think this is a 'corner case'
[19:05] <dobey> teward: very certainly a corner case
[19:05] <nacc> it's a usability issue, arguably
[19:05] <dobey> teward: well i think the limit should match what is allowed by dpkg
[19:06] <Akuli> nacc, you have a syntax error in your code
[19:06] <nacc> Akuli: bah
[19:06] <Akuli> unbalanced parenthesis
[19:06] <teward> dobey: what's the upper limit there then?
[19:06] <nacc> http://paste.ubuntu.com/20490547/
[19:06] <nacc> Akuli: --^
[19:06] <teward> bah almost out of power >.<
[19:06] <teward> (on my laptop)
[19:06] <dobey> teward: i'm not entirely sure. it would be whatever the tar format limit is, for the tar format version being used
[19:06] <nacc> i dont' think it's accurate to print 'command not found' as it wasn't searched for
[19:06] <dobey> which i /think/ is 255
[19:07] <nacc> i mean, 255 is a sane limit; there might be more optimal choices
[19:07] <Akuli> nacc, it was
[19:08] <Akuli> bash searches the command before command-not-found runs
[19:08] <sarnold> someone should hunt around java applications that install things into /opt. if anyone's going to have ultra-long command names that seems like the group that would do it :)
[19:08] <Akuli> without command-not-found it would print 'command not found' no matter what
[19:08] <dobey> well it wasn't found and it's not going to be searched for in the package archives, either
[19:09] <dobey> sarnold: but they have to all get wrapped in a shell script with a shorter name, becuase it's the arguments to java that are long, there
[19:10] <Akuli> hmm
[19:10] <Akuli> i tried that in a virtual machine, and it started attempting to kill command-not-found
[19:11] <Akuli> but the vm is frozen anyway
[19:17] <Akuli> reading the code more, the fix is actually pretty awful
[19:17] <Akuli> it ignores options.ignore_installed
[19:18] <dobey> that's a bit rude
[19:18] <Akuli> indeed
[19:18] <dobey> no, i mean your statement is
[19:19] <Akuli> i meant, it doesnt do anything with options.no_failure_message
[19:19] <Akuli> sorry i was confusing two things
[19:23] <dobey> i meant, you called nacc's work "actually pretty awful" when the time was taken to help create a patch for your problem, which was only reported today, and is really an extreme corner case, while you refuse to "download the source for a 3 line change" to make a patch
[19:23] <dobey> ie, it's rude :)
[19:24] <Akuli> i made the original implementation
[19:24] <Akuli> nacc just changed one number
[19:24] <Akuli> oh wait..
[19:25] <Akuli> he changed much more than i thought he did
[19:25] <Akuli> that looks great to me
[19:34] <emanuel7> how is php 7.1 plans ?
[19:35] <emanuel7> need an rebuild everiting ?
[19:38] <emanuel7> another transition, and bug everyone againg for ftbfs ?
[19:39] <emanuel7> ups, I mean again
[20:33] <nacc> emanuel7: there aren't any php7.1 plans right now?
[20:34] <nacc> emanuel7: i don't think it's packaged in debian or ubuntu yet
[20:37] <emanuel7> thanks for rapid feedbak, @nacc
[20:39] <nacc> emanuel7: np, i think php7.1 is still in beta anyways
[20:39] <nacc> emanuel7: let me see if debian has anything cooking
[20:39] <nacc> emanuel7: with the understanding that if it exists anywhere, it would be 16.10+, probably 17.04
[20:39] <emanuel7> you are the packager ? also in debinan ?
[20:41] <nacc> emanuel7: i did the php7 transition (with help) in ubuntu
[20:41] <nacc> emanuel7: and work with the debian maintainers a bit
[20:41] <nacc> emanuel7: https://anonscm.debian.org/cgit/pkg-php/php.git/log/?h=master-7.1 looks like they have some stuff in git, but not yet packaged/published
[20:43] <emanuel7> it will help to pan early...
[20:43] <emanuel7> plan
[20:43] <nacc> emanuel7: what version of ubuntu are you referring to?
[20:44] <emanuel7> of course the latest one
[20:44] <nacc> emanuel7: 16.04 will never have php7.1
[20:44] <nacc> emanuel7: unless you mean 16.10?
[20:44] <nacc> emanuel7: that's why i asked.
[20:46] <emanuel7> I mean the developing one 16.10, and of course debian unstable
[20:48] <emanuel7> or testing
[20:48] <emanuel7> look at golang
[20:49] <nacc> emanuel7: debian unstable has no php7.1 either
[20:49] <emanuel7> they get testing
[20:49] <emanuel7> at beta now
[20:50] <nacc> emanuel7: i'm not sure what you're saying
[20:50] <nacc> emanuel7: there is no packaged php7.1 in debian or ubuntu
[20:52] <emanuel7> https://lists.ubuntu.com/archives/yakkety-changes/2016-July/004343.html
[20:53] <emanuel7> ok golang is not the latest version
[20:53] <emanuel7> now is rc3
[20:53] <nacc> emanuel7: i thought you were asking about php?
[20:54] <emanuel7> the same about php
[20:54] <nacc> same what?
[20:54] <emanuel7> why not testing the latest version ?
[20:54] <nacc> !latest | emanuel7
[20:56] <emanuel7> there are fixes for bugs, not changes in language
[20:56] <emanuel7> and that is all I will say about
[20:57] <nacc> emanuel7: you are saying random statements, I'm having trouble following.
[21:03] <emanuel7> @nacc usually the newer version is better, fixes bugs, etc.
[21:03] <udevbot> Error: "nacc" is not a valid command.
[21:07] <nacc> emanuel7: php7.1 is not bc with php7.0 necessarily, they add features, etc. It's not just bugfixes, if you simply glance at the NEWS file upstream.
[21:07] <nacc> emanuel7: and, again, php7.1 is not yet published in debian, so we don't have it in ubuntu
[21:08] <emanuel7> that is why I made an parallel to an other language like golang.
[21:08] <emanuel7> ok
[21:09] <nacc> and just like php5, php7.0 will presumably continue to get bugfixes
[21:10] <dobey> and you're free to build newer versions in a PPA to test if you need to
[21:10] <nacc> dobey: +1, good point
[21:11] <dobey> or get involved with the packagers of php in debian if you want more testing of it in unstable.
[21:11] <dobey> but you need to go to the debian channel for that, not here :)
[21:17] <emanuel7> what I want to say is deep respect to people doing the transitions, tons of work going unnoticed
[21:19] <nacc> emanuel7: ^5, it's a pain :)
[21:19] <nacc> emanuel7: i wills ay, i don't think php7.1 will be the same
[21:20] <nacc> emanuel7: what will probably ahppen is php7.1 will be an alternative in the metapackages (e.g. php) and it will "just work"
[21:20] <nacc> that's an eventuality, though
[23:20] <semiosis> Odd_Bloke: the SRU -- https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1605795
[23:22] <Unit193> flexiondotorg, infinity: Know what's up with the whole -core thing?  Not heard anything about it for a while is everything still pending on the reviewers?
[23:29] <infinity> Unit193: Yeah, I need to revisit it.  Especially since flexiondotorg bought me beer.
[23:29] <Unit193> Hah!  What type?
[23:30] <infinity> Unit193: Whatever random hefeweizen the hotel bar had on tap. :P
[23:30] <Unit193> infinity: FWIW, core is pretty popular with our users, got an email about a point release too. :P
[23:31] <infinity> s/core/base/ ;)
[23:31] <infinity> And noted.
[23:31] <infinity> Hopefully I can find some down time when I get home.
[23:31] <Unit193> Eh...
[23:32] <Unit193> Right now it's pretty well known as 'Core', though it seems it'll get renamed soon™  Thanks, hope you do get time.