=== inaddy is now known as tinoco
=== Trevinho_ is now known as Trevinho
=== elijah__ is now known as elijah
=== greyback__ is now known as greyback
=== magic is now known as Guest15440
=== inaddy is now known as tinoco
=== FourDollars_ is now known as FourDollars
=== dkessel_ is now known as dkessel
=== Pici` is now known as Pici
=== om26er is now known as om26er|dinner
=== tarpman_ is now known as tarpman
=== kees__ is now known as kees
=== om26er|dinner is now known as om26er
[17:48] <filipsohajek> Hello, can you please mark this bug as triaged and set importance to critical? https://bugs.launchpad.net/ubuntu/+source/poco/+bug/1361610
[17:48] <ubot5> Ubuntu bug 1361610 in poco (Ubuntu) "libPCRE3 8.31 regex matching is not working" [Undecided,Confirmed]
[17:49] <filipsohajek> Oh, sorry importance High
[17:49] <teward> i was about to say... :p
[17:51] <teward> filipsohajek, that's "Won't Fix".  13.10 is EOL
[17:51] <filipsohajek> Yes, i can confirm it in 14.04, and there's 12.04 proof
[17:51] <teward> it EOL'd on July 17
[17:52] <teward> filipsohajek, provide the output as it shows in 14.04 please
[17:52] <teward> (I'll set it if you do that)
[17:52] <teward> as long as it only provides the 13.x one i'm not sure it's valid
[17:52] <teward> (as is)
[17:53] <teward> filipsohajek, i'm being anal about that because the bug only refers to 13.10
[17:53] <teward> and says NOTHING about 14.04
[17:53] <teward> and I would also like you to test Utopic if you can
[17:53] <teward> (or have someone test Utopic)
[17:53] <teward> because Utopic would need the fix to (maybe first?)
[17:54] <filipsohajek> Yes, i will test it, but i don't have daily iso
[17:54] <teward> nor do I, at least not here
[17:54] <teward> i'm still waiting for a monitor so I can install ESXi on my new server xD
[17:54] <teward> then I can spin up a VM :)
[17:54] <filipsohajek> :)
[17:55] <teward> oooo that and i have to finish the firewall rules for that VLAN... and then configure the switch... >.<
[17:56] <filipsohajek> iptables -A INPUT -j DROP : that's the best firewall ever :)
[17:56] <teward> filipsohajek, *buzzer* wrong, i've been able to bypass that twice in test labs :p
[17:56] <teward> you may be right, on client ends its useful if there's nothing else
[17:56] <teward> in my environment the BIG DADDY firewall is a pfSense box at the border
[17:57] <teward> and the VLANs protect the system and allow isolation from my other systems
[17:59] <filipsohajek> Added output in 14.04
[18:01] <teward> filipsohajek, i see both pcre3 and poco on here, is one affected because it depends on the other, or can they both, operating independently of one another, produce the issue?
[18:02] <teward> i.e. does poco rely on pcre3 for actual processing of the regex, or the other way around does pcre3 depend on poco for processing of the regex and such
[18:02] <filipsohajek> I will look
[18:03] <teward> filipsohajek, i ask that because i'm hesitant to triage both of them if one is actually handling the processing whereas the other doesn't.
[18:04] <filipsohajek> It appears not.
[18:05] <teward> filipsohajek, so they *both* independent of each other, with one installed and the other not, will have this issue?
[18:05] <filipsohajek> +
[18:06] <filipsohajek> yes
[18:06] <teward> (the reason being is, if they both independently produce this, without depending on each other or one depending on the other to process, then it may be both of them needing a fix, or neither)
[18:06] <teward> okay.
[18:06] <filipsohajek> I checked it with apt-cache show libpoco* | grep prce . Shows nothing
[18:06] <teward> make a note that that's the case and i'll triage em.  you can mention i asked you to check that to make sure it wasn't one making the issue and affecting the other
[18:07] <teward> ooop wait a second
=== cyphermox_ is now known as cyphermox
[18:08] <teward> filipsohajek, there's a builddep on pcre3
[18:08] <teward> i'd be interested to see if PCRE in other implementations has an error like this
[18:08] <filipsohajek> Oh, sorry. I checked only binary packages
[18:08] <teward> right, it LOOKS like poco depends on pcre3 at build time
[18:09] <filipsohajek> Ok, i will look in debian/control
[18:10] <teward> filipsohajek, if it does indeed rely on PRCE3 then it's likely a bug in PCRE3 and not poco, but i'm not 100% familiar with eitiher package
[18:10] <teward> that and i need to fix my computer, back in a bit
[18:12] <filipsohajek> Checked in debian/control of source package poco. Pattern *prce* not found
[18:24] <teward> filipsohajek, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/poco/utopic/view/head:/debian/control
[18:24] <teward> 5th line
[18:24] <teward> same line in trusty http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/poco/trusty/view/head:/debian/control
[18:25] <teward> line 6 in precise: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/poco/precise/view/head:/debian/control
[18:25] <filipsohajek> Oh, i'm sorry. I searched to prce instead of pcre :)
[18:27] <teward> looks like you might have a dependency causing the problem.  Is this a really high impact issue, though, severe enough for "High"?  I think this might apply, but how crucial is it?  "Renders essential features or functionality of the application or dependencies broken or ineffective"
[18:29] <teward> filipsohajek, i would also check poco upstream to see if they know about it (i.e. their devs) because while pcre3 is in main and problems in that will probably get looked at, poco is in Universe and may not be fixed
[18:31] <filipsohajek> Yes, it might get High priority, because it's not matching simple regexp
[18:34] <filipsohajek> Wait... poco is not affected. Why checking it upstream?
[18:38] <filipsohajek> Oh, sorry. It's affected by depedency. I'm disoriented.
[18:47] <teward> actually if the issue is in PCRE and not Poco then it's INvalid for Poco (because Poco is not where the bug is) and valid for PCRE
[18:47] <teward> but now i'm stuck on my phone for IRC so i can't do much :/
[18:47] <teward> (stupid internet)
=== magic is now known as Guest64580
=== Guest64580 is now known as ItsMagic
=== ItsMagic is now known as magic
[20:24] <frezix> hi, during a netinstall, if it's not possible to remove encrypted LVM partitions (even when passphrase is known), would this be considered a bug
[20:28] <Ampelbein> frezix: I'd say yes
[20:30] <Ampelbein> frezix: And someone reported it on LP already, bug 652641. But no further action has been taken in the last ...4 years.
[20:30] <ubot5> bug 652641 in debian-installer (Ubuntu) "debian-installer doesn't allow removing encrypted partition" [Undecided,Confirmed] https://launchpad.net/bugs/652641
[20:32] <brainwash> also, it has not been forwarded to the debian guys
[20:34] <Ampelbein> debian bug 451535 looks kindof related I think
[20:34] <ubot5> Debian bug 451535 in partman-crypto "debian-installer: allow to 'reuse' encrypted volumes" [Grave,Open] http://bugs.debian.org/451535
[20:34] <frezix> oh wow 4 years, interesting
[20:36] <frezix> how should I forward it to the Debian people? I'm not familiar with the whole bug reporting process
[20:37] <Ampelbein> I think the debian bug I linked is essentially the same issue: partman-crypto/debian-installer is unable to access the existing LVM partitions.
[20:38] <teward> if the bug exists upstream then it's kinda irrelevant to report it again
[20:41] <brainwash> makes sense
[20:42] <teward> Ampelbein, if that's the case we could link them on LP
[20:43] <Ampelbein> I just did that.
[20:43] <teward> nice
[20:43] <teward> grrrrr, stupid VLANing is painful >.<   why can't they make switch configuration EASY
[20:43] <teward> (sorry i'm ranting, i'll be quiet now)
=== inaddy is now known as tinoco