[02:43] <Guest43> Installing Gazelle torrent tracker with 16.04 apache and php 7.1 - get a white screen upon install.. have php errors on but nothing but a white screen.. any help?
[02:44] <sarnold> check error logs?
[02:52] <Guest43> yep
[02:52] <Guest43> empty
[02:52] <sarnold> do you get better diagnostics if you connect via localhost rather than a public internet?
[02:53] <sarnold> s/internet/interface/ stupid fingers
[02:54] <Guest43> same
[03:22] <keithzg> Hmm, in the process of upgrading a bunch of servers, and I haven't yet actually upgraded the one that runs apt-cacher-ng for our repo mirroring/caching. But one of the VMs already upgraded is now refusing to update from that mirror because it "does not have a Release file".
[03:27] <keithzg> Does anybody know if this would be expected to work again once I upgrade the server in question that's running the apt-cache-ng instance to 16.04 as well? Or will there be some further steps I'd have to take? Or, worst-case scenario, is apt-cacher-ng now being left behind by changes to apt security?
[03:29] <sarnold> even 0.6-1 knew to treat the InRelease files specially https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622272
[03:30] <sarnold> so I'd hope whatever acng you've got installed is prepared to work with releases that prefer InRelease
[05:15] <eatingthenight> hello, I have 4 interfaces on my server but only one is plugged in normally ifconfig only shows the interface that is plugged in such as eth0. however on a new server class i got if config is showing all of the interfaces.
[05:15] <eatingthenight> even though 2 of them are not plugged in
[05:15] <eatingthenight> currious what is causing this to happen and what i can look into to better understand why this is happening.
[05:25] <eatingthenight> also cat /sys/class/net/eth1/speed reports -1
[05:25] <eatingthenight> which as far as i know is not even a valid output
[05:26] <eatingthenight> this is on bare metal not inside a container/vm where i would expect this kind of strange behavior
[06:49] <cpaelzer> mwhahaha: thanks for the FYI - I'll take a look at libvirt if that needs a conffile change or even more
[06:53] <cpaelzer> mwhahaha: that was already the case for yakkety (libvirt 2.1)
[06:55] <cpaelzer> mwhahaha: but I see you are in the cloud archive version of these things, yet there seems to be a valid set of breaks/replaces between libvirt-bin and libvirt-daemon-system and a debian/libvirt-daemon-system.maintscript that should take care of the move
[06:55]  * cpaelzer is looking if the version statements in there could cause any issues
[07:01] <cpaelzer> hmm the mv_confile says 1.3.3-2, while I'd have expected 2.1.0-1ubuntu1~ to be more correct but still, on a normal upgrade cycle this should match as xenial is on 1.3.1-1ubuntu10.6
[07:01] <cpaelzer> maybe that is special to the upgrade paths you take through ubuntu cloud archive upgrades
[07:04] <cpaelzer> coreycb: jamespag`: could that be an issue only along the path of versions a cloud archive user traverses on upgrades? ^^
[08:07] <fishcooker> http://vpaste.net/WKF7A which is the failed one if i have 16 DIMM installed and this configuration http://imgur.com/WjLTxfJ is it C2 or C1 or something else  this is my manual https://data2.manualslib.com/pdf2/33/3250/324995-asus/rs720e7rs12e.pdf?6a64c52263547b881f8e426b24b633a8
[08:25] <lordievader> Good morning.
[08:27] <Raboo> morning
[08:27] <lordievader> Hey Raboo
[08:27] <Raboo> Hey, how's it going?
[08:27] <lordievader> Doing okay, waiting for coffee.
[08:28] <Raboo> hmm, brb gotta make some tea
[08:30] <Raboo> now i got a hot bewerage
[08:30] <Raboo> i'm having a problem, and don't really know where to start looking for solutions.
[08:31] <lordievader> What is the problem?
[08:31] <Raboo> i wrote a ubuntu cloud image to a hdd on bare metal
[08:31] <Raboo> but when it boots, it's super slow
[08:32] <Raboo> takes like 30 minutes
[08:32] <Raboo> http://i.imgur.com/sr1Aodp.png
[08:33] <Raboo> i'm trying to build some scripts to make it possible to deploy the cloud images to bare metal
[08:35] <lordievader> What hypervisor are you using?
[08:36] <Raboo> no hypervisor, told you, my intention is to push these images to bare metal nodes
[08:36] <Raboo> i'm using https://theforeman.org/ + pxe to deploy the image
[08:46] <lordievader> Ah, bare metal. Missed that.
[08:46] <Raboo> so basically what i do is partition the disk, dd the raw image to rootfs partition
[08:47] <Raboo> mount it and add som cloud init configs, interfaces + resolv.conf
[08:47] <Raboo> install grub
[08:47] <Raboo> unmount, reboot..
[08:48] <Raboo> and it boots, but it takes forever
[08:49] <Raboo> and i know it's using linux-image-XXX-generic so it should have support for the hardware
[08:54] <Raboo> i found one thing, gonna try that, https://bugs.launchpad.net/cloud-images/+bug/1598108
[09:29] <qsong> Can ubuntu 16.4 support selinux on s390x?
[09:31] <lordievader> Ubuntu has Apparmor.
[09:38] <qsong> Has anyone use selinux to replace apparmor
[09:38] <qsong> I just want to known whether selinux can be supported on ubuntu
[09:39] <Raboo> qsong i think selinux is "EL" specific
[09:39] <Raboo> RHEL, CentOS, SuSE.. etc..
[09:39] <qsong> Yes, EL support by default
[09:40] <qsong> but we need to consider whether ubunbu is also support
[09:40] <Raboo> i don't think you will find anyone that have implemented selinux on Ubuntu
[09:40] <qsong> our application need to work on ubuntu, need to consider whether it will be blocked by selinux
[09:41] <Raboo> Apparmor is similar to selinux
[09:42] <qsong> Does any official document on Ubuntu has listed that selinux is not recommend.
[09:42] <Raboo> don't think so, I just figure it's not implemented
[09:42] <qsong> Yes, I know, what I want to do is to verify that our APP can work well even selinux is enabled on Ubunut
[09:45] <qsong> Thanks Raboo, will pursuade other team members to abandon this test
[09:45] <Raboo> selinux exists for ubuntu, but my personal believe is that not many use it.
[09:46] <Raboo> i could be wrong
[09:47] <qsong> Yes, I agree with you, Apparmor is the default choice.
[11:51] <xnox> lordievader, Raboo: i think we have all security things enabled (at least in kernel) selinux, apparmor, smack.
[11:51] <xnox> i think somebody did use selinux... but it's not default and they made their own policies for /everything/ they used.
[11:51] <xnox> the default is apparmor, but one can use selinux with determination
[12:46] <cpaelzer> jamespage: Debian now has DPDK 16.11-1 https://buildd.debian.org/status/package.php?p=dpdk
[12:46] <cpaelzer> jamespage: note that ppc now is also enabled
[12:47] <cpaelzer> jamespage: I'd like to sync that into zesty, but then I know that openvswitch needs a rebuild after that
[12:47] <cpaelzer> jamespage: never done a sync, nor a sync caused need for rebuild
[12:47] <cpaelzer> jamespage: if you'd have a minute to tell me who-does-what in this case that would be great
[12:48] <cpaelzer> jamespage: btw - that version is (almost) identical to what I tested at https://launchpad.net/~paelzer/+archive/ubuntu/dpdk-packaging-tests
[12:51] <cpaelzer> seems to be syncpackage + waiting + no-change-rebuild upload of openvswitch
[12:51] <cpaelzer> yet doing these particular steps the first time a mini-coordination would be nice
[13:03] <mwhahaha> cpaelzer: it's not so much upgrades as our tooling (puppet) broken because the file location change and also the group changed
[13:05] <cpaelzer> mwhahaha: ah I see, so the package upgrade makes sure that the old content is transferred (if you had any)
[13:05] <cpaelzer> mwhahaha: but I see - if you had externel references that is an issue
[13:05] <mwhahaha> we're updating but it broke a bunch of stuff
[13:05] <cpaelzer> mwhahaha: :-/
[13:05] <mwhahaha> there's also some ceilometer and aodh issues we're working through with the last update to the ocata cloud stuff
[13:07] <cpaelzer> mwhahaha: then at least it broke due to the file no more being there instead of silently going on changing a file that has no effect - that was the bug I first thought would occur
[13:07] <cpaelzer> conffile changes are a defined thing, I wonder if there is a way to generate a list of all conffile changes along an upgrade so that automation (or at least operators) could be aware
[13:11] <cpaelzer> mwhahaha: not sure if that would help, but with "dpkg-query -W -f='${Conffiles}\n' | sort" you can get a list of all configfiles on a system
[13:12] <cpaelzer> mwhahaha: doing so before & after a major upgrade test and diffinf git could identify changed location and/or changed default content (via the checksum)
[13:12] <cpaelzer> that would allow you to process all changes logically one by one instead of trial&error into whatever shows up
[13:12] <mwhahaha> unfortunately the way the cloud archive updates are applied it's not possible to understand the diffs between the updates as the previous version of the package no longer exists
[13:13] <mwhahaha> i'm not dealing with newton->ocata, but rather the live ocata repos
[13:13] <cpaelzer> ah I see
[13:13] <mwhahaha> so what worked monday, got broken tuesday because of packaging
[13:13] <cpaelzer> and your external puppet now needs fixes to be able to handle, gotcha
[13:14] <mwhahaha> so i'm part of the puppet openstack team and so these are changes that used to work (for many cycles) that were broken with this latest update. and since there's no warning it just breaks all of our ci
[13:32] <rbasak> mwhahaha: I'm not familiar with most of this, but I believe that we pre-publish all proposed updates before they land for regression testing. Given you have CI, can you hook into that? Then you could report back before updates land, possibly blocking or fixing the update, etc.
[13:39] <mwhahaha> rbasak: I can look into that as well. But rather than pushing that to us, perhaps it would be more beneficial for you to leverage our CI? we already integrate with RDO so they are aware of possible regressions. It'd be nice to get visibility UCA current work
[13:40] <rbasak> mwhahaha: not my department, I'm afraid. I'm just suggesting the possibility in the hope that it is helpful.
[13:40] <coreycb> zul, https://review.openstack.org/#/c/417591/
[13:40] <rbasak> beisner, jamespage: ^
[13:44] <zul> coreycb: yeah thats because keystoneauth was hiting the same issue keystone is and they made a backward/forward compatible change https://bugs.launchpad.net/keystone/+bug/1657452
[13:45] <zul> coreycb: this is my incomplete/perhaps wrong attempt to fix it https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/keystone/tree/debian/patches/webob-1.7-fixes.patch
[13:48] <coreycb> mwhahaha, sorry i'm just looking, is there a package bug?
[13:48] <mwhahaha> coreycb: i did not create one as it seems to be intentional, just wasn't sure if people were aware of the impact of these things
[13:49] <coreycb> mwhahaha, can you catch me up?  i'm missing context.
[13:50] <mwhahaha> coreycb: new ocata packages, broken puppet openstack due to many new changes. first one we found was libvirt upgrade changed /etc/default/libvirt{-bin,d} and group libvirt{d,}
[13:50] <mwhahaha> coreycb: still working throught all the other items that were broken by the new packages (ceilometer, aodh are known for ow)
[13:51] <coreycb> mwhahaha, much of b2 was promoted to ocata-proposed yesterday.  ocata-updates is still the old packages fwiw.  once we get everything promoted i plan to send an announcement.
[13:51] <coreycb> mwhahaha, we moved a bunch of api's to mod_wsgi
[13:51] <mwhahaha> coreycb: right we already handle the mod_wsgi bits so the automatic file creation is problematic for us
[13:52] <mwhahaha> coreycb: we might be running proposed instead of updates i'm still getting spun up for the day so i haven't looked a that yet
[13:52] <coreycb> mwhahaha, ok I'd need to look into that.  we backported libvirt from zesty to the xenial-ocata cloud archive
[13:53] <mwhahaha> coreycb: i'm working on updating the puppets to handle the new locations and stuff, i just wanted to raise awareness that these things have impacts on external tooling
[13:53] <coreycb> mwhahaha, of course :)
[13:54] <coreycb> mwhahaha, we're definitely aware of that.  we maintain juju charms too so we know there are updates throughout every release that need to be made.
[13:58] <coreycb> mwhahaha, ok we hit that libvirt one too.  we had to put some logic in the charms to use different groups etc based on what release is being used.
[13:58] <mwhahaha> coreycb: yea but we don't have that concept, so it makes our puppet-nova incompatible with the previous one. so that breaks our desire to keep modules at least 1 version backwards compatible
[13:59] <mwhahaha> coreycb: so like i said, we're updating but it's not great for backwards compatibility :(
[14:00] <coreycb> mwhahaha, we'd have to chat with libvirt folks on that one.  i'm not too up-to-date as to why that stuff changed.
[14:00] <mwhahaha> probably to align it with the debian version
[14:00] <cpaelzer> coreycb: to drop a major delta to debian
[14:00] <cpaelzer> done already in the early yakkety cycle
[14:00] <cpaelzer> like "big changes post-LTS"
[14:00] <cpaelzer> to give time to adapt pre next LTS
[14:01] <coreycb> cpaelzer, ack thanks
[14:01] <mwhahaha> oh btw we do use proposed
[14:01] <mwhahaha> so that's why we hit it yesterday
[14:02] <coreycb> mwhahaha, that makes sense
[14:10] <jamespage> coreycb, mwhahaha: fwiw it might be worth running the puppet models CI gate against -updates, we a regular test against proposed for early vis of these types of changes
[14:10] <jamespage> models/modules
[14:13] <jamespage> gosh I can't type today
[14:13] <jamespage> we/with
[14:16] <coreycb> jamespage, mwhahaha: that would make sense. just make sure you run a regular test against proposed to see these changes coming.
[14:27] <zul> jamespage: btw glance https://bugs.launchpad.net/glance/+bug/1657459
[14:28] <jamespage> zul, reason for build failures in proposed right?
[14:28] <zul> jamespage: yeah...
[14:28] <zul> jamespage: glance/nova probably as well
[14:54] <mwhahaha> jamespage: so it's kinda when we want to get hit by these, honestly running against updates means we'd just get hit by these later. Since we can't control the promotion process, it's more beneficial to get these sooner than later :D specifically these changes are not backwards compatible so we'd get broken either way. it would just be a matter of time
[15:05] <coreycb> jamespage, zul: yeah so webob issues with 1.7.0 look like they run deeper than just test failures
[15:05] <zul> coreycb: gah
[15:05] <coreycb> zul, well based on that glance bug you posted
[15:05] <zul> coreycb: yeah...im not too happy about this
[15:36] <jge> hey all good morning, I'm trying to find out what process is sending a bunch of UDP traffic out onto the network but I'm not getting anything.. I did a tcpdump on the box, found out the local port: 3955 then do a netstat -apn | grep 3955 but nothing
[15:36] <jge> the connection is active as I'm seeing that traffic flowing
[15:36] <jge> I'm trying to find out what process (if any) is sending it
[15:36] <jge> any ideas?
[16:28] <rbasak> jge: try with --inet6
[16:28] <rbasak> (even if it's IPv4 traffic you're seeing)
[16:44] <jge> rbasak: I did a netstat -apn --inet6 | grep 3955 and nothing
[16:46] <DammitJim> what log tells me information with timestamps of a shutdown?
[16:46] <DammitJim> I'm trying to figure out why when shutting down a server, it takes close to 10 minutes
[16:47] <DammitJim> and the last thing I see on the screen is: Stopped LVM2 metadata daemon
[16:47] <DammitJim> Thanks!
[16:49] <rbasak> jge: I'm not sure then, sorry. Try without the -a and separately with --inet and --inet6 instead, only because that's what I normally do. If that doesn't work, then the only things I can think of are rootkit and a process that doesn't hold the socket for long, so it's racing you.
[16:49] <rbasak> There probably a simpler, less serious explanation but I cannot think of one.
[16:50] <rbasak> iptables can do logging of origin user I think. If not try nftables if you have a new enough system.
[16:53] <jge> rbasak: it's a bunch of UPnP traffic, which I automatically associate with something up to no good, so I'm not throwing away the idea of a rootkit or malicious process, if iptables do do logging of origin user would it show a PID or the likes?
[16:54] <jge> I captued about 2-3 minutes worth of traffic and around %50 of it was all UPnP broadcasts, which seems excessive but it could also be that this box doesn't see a lot of traffic flowing
[16:54] <rbasak> jge: oh. There's a thought. Could it be a raw socket?
[16:54] <rbasak> UPnP is more likely than average to use raw sockets.
[16:54] <rbasak> jge: iptables may be able to capture pid as well.
[16:55] <jge> I used 'ss -w -a' to check that and three connections come up but they're binded to *:icmp and :::ipv6-icmp
[16:55] <rbasak> jge: if it's using a raw socket, it'll show up in netstat but not under --inet or --inet6 and it won't show you port numbers.
[16:57] <jge> I did a netstat, under proto all show up as unix
[16:59] <jge> if it's a rootkit or process that doesnt hold socket for long, would I be able to see it if I fire up the netstat command under "watch 1" for example?
[17:21] <rbasak> jge: I think your netstat would take orders of magnitude of attempts in order to win the race.
[17:22] <rbasak> I'm not sure it's that likely though.
[18:34] <cpaelzer> rbasak: ping, still around?
[18:47] <jfk-cm> I don't know where to ask this question. I was on #ubuntu and someone suggested this. I'm having problems running Selenium Standalone server on Ubuntu 16.10. It seems to start in Terminal but when I try to create a session it says "Unable to create new session". It works fine in Fedora.
[18:50] <sarnold> does it have a verbose option that would give some useful information? or an error log?
[18:51] <DammitJim> what log tells me information with timestamps of a shutdown?
[18:51] <DammitJim> I'm trying to figure out why when shutting down a server, it takes close to 10 minutes
[18:51] <DammitJim> and the last thing I see on the screen is: Stopped LVM2 metadata daemon
[18:53] <jfk-cm> This is what shows when I try to run a Nightwatch test:
[18:53] <jfk-cm> Error retrieving a new session from the selenium server
[18:53] <jfk-cm> Connection refused! Is selenium server started?
[18:53] <jfk-cm> { state: 'unhandled error',
[18:53] <jfk-cm>   sessionId: null,
[18:53] <jfk-cm>   hCode: 920681884,
[18:53] <jfk-cm>   value:
[18:53] <jfk-cm>    { localizedMessage: 'Could not initialize class sun.security.ssl.SSLContextImpl$TLSContext',
[18:53] <jfk-cm>      cause: null,
[18:53] <jfk-cm>      suppressed: [],
[18:53] <jfk-cm>      message: 'Could not initialize class sun.security.ssl.SSLContextImpl$TLSContext',
[18:53] <jfk-cm>      hCode: 728090681,
[18:53] <jfk-cm>      class: 'java.lang.NoClassDefFoundError',
[18:53] <jfk-cm>      screen: null },
[18:53] <jfk-cm>   class: 'org.openqa.selenium.remote.Response',
[18:53] <jfk-cm>   status: 13 }
[18:53] <jfk-cm> I don't know how to find any logs
[18:53] <teward> !pastebin | jfk-cm
[18:53] <teward> for the future
[18:53] <sarnold> oy, if you're going to paste more than about two lines it's best to use a pastebin site :)
[18:53] <teward> sarnold: ohai
[18:53] <sarnold> morning teward :)
[18:54] <jfk-cm> Thanks. I'm new to this.
[18:54] <teward> sarnold: I assume you saw my pings from over 24 hours ago
[18:54] <teward> ?
[18:54] <sarnold> jfk-cm: so, that thing at least says the server isn't running. that's a starting point. use ss or netstat to look for the server on the ports you expect it to be on.
[18:54] <sarnold> teward: maybe? which ones.. sorry.
[18:55] <teward> sarnold: in -hardened
[18:55] <jfk-cm> I can go to the localhost port and see the server is up. But even when I try to create a browser connection through that interface it says "Connection refused"
[18:56] <sarnold> teward: aha, right, the pie/pic problem :( I really wish they just used bloody makefiles as they were intended rather than trying to generate magic makefiles with scripts that are longer than the things they were generating. I'm sure of it.
[18:56] <teward> sarnold: well i'm going to *try* and implement a fix that we did back in the 14.04 days to fix some of the Perl compile fails anyways
[18:56] <teward> but, I'm not sure it'll work
[18:56] <teward> because even with fPIE disabled, I'm still getting a lot of fails
[18:56] <sarnold> jfk-cm: just to be clear, when you see 'the server is up', is that the selenium server that you see up? or your website?
[18:57] <sarnold> teward: ugh
[18:57] <teward> sarnold: so for now i'm just working on standard builds, without dynamic modules.  For now.
[18:57] <teward> (next LTS, I want it all merged heh)
[19:02] <jfk-cm> http://imgur.com/a/lovtd
[19:51] <kyle__> cleaning up an old server, and noticed an entry in /etc/passwd where the second col starts with 8+.  I'm used to $6$, $5$, $2a$, $2y$, $1$...is .... is that seriously a 3DES password in there?
[19:57] <sarnold> wow :)
[19:59] <blacknred0> is there a way to sync ~/.ssh/known_hosts ?
[19:59] <blacknred0> is rsync my answer :P :)
[20:02] <sarnold> blacknred0: depending upon what you're trying to do, look into monkeysphere and sshfp
[20:03] <blacknred0> sarnold: i'll take a look at both, but essentially every time i add a host to one server i would like to have that host sync across other servers
[20:24] <DammitJim> what is ens160?
[20:32] <sarnold> DammitJim: looks like a NIC http://www.ehowstuff.com/new-naming-scheme-for-the-network-interface-on-rhel-7centos-7/
[20:53] <DammitJim> so, I guess we need to learn to use ens now
[20:58] <sypher> DammitJim: Not always "ens."
[21:01] <DammitJim> WOOT?
[21:56] <teward> sarnold: I think i may have found the issue
[21:56] <teward> maybe
[22:32] <teward> sarnold: holy crap I think I fixed the build failures...
[22:32] <teward> it just has to finish compiling a few more modules and I'll know if it worked
[22:35] <teward> HOLY HELL I GOT IT WORKING
[22:35] <teward> sarnold: ^ that's... good news, because I only disabled -fPIE in the perl flags heh
[22:35] <teward> the rest is... working, I think
[22:35] <teward> gonna push to a PPA and test
[22:50] <PryMar56> teward, or append to cflags: -fno-pie
[22:50] <PryMar56> ^^ was it yakkety?
[22:52] <teward> PryMar56: it was all distros
[22:52] <teward> PryMar56: it was actually lacking -fPIC as a build flag
[22:52] <teward> adding that seems to make it work
[22:54] <teward> while disabling -fPIE in the hardening flags for the perl modules specifically
[23:00] <sarnold> teward: sweeeet :D
[23:01] <teward> sarnold: HOLY HELL IT BUILDS!
[23:01] <sarnold> PryMar56: the thing is, nginx's makefiles are a mess. it's quite hard to just say "please build with -fpic" :(
[23:01] <sarnold> teward: well done :D
[23:01] <teward> sarnold: does this look sane?  http://paste.ubuntu.com/23824662/
[23:02] <teward> 'cause while this lands in the PPAs, it's going to land in the merge delta
[23:02] <teward> unless I can get Debian to include the -fPIC changes, which will fix a lot of the issues
[23:02] <teward> (even though it doesn't break in Debian, getting it there will help if something ever *does* break in Debian)
[23:03] <sarnold> teward: I'm a touch surprised about the hardening=+all, but all that machinery predates me, so I never learned it well
[23:03] <teward> sarnold: i have an sbuild log if you want to review that too
[23:03] <teward> sarnold: that's actually still in Debain
[23:03] <teward> Debian*
[23:04] <teward> but hey it works and fixes some build explodes, so blarghl
[23:04] <sarnold> teward: oh right right
[23:04] <teward> sarnold: some of that is left over from 14.04
[23:04] <teward> when we implemented to address a wishlist to enable bindnow and PIE
[23:05] <teward> but hey I have something that builds heh
[23:05] <sarnold> teward: have you had a chance to run hardening-check on the results?
[23:06] <teward> sarnold: no, but for the PPAs I'm more concerned about getting that building first
[23:06] <teward> since the PPAs are, what, three months behind?
[23:06] <teward> i'll hardening-check that after it's uploaded
[23:07] <PryMar56> take a look at: dpkg-buildflags --export | sed -e '/fix me/', insert into the debian/rules after importing default.mk
[23:51] <teward> sarnold: holy crap, look at all the successful builds!  ^.^   https://launchpad.net/~teward/+archive/ubuntu/nginx-stable-testing/+packages
[23:51] <teward> (except the two that are waiting)
[23:51] <teward> sarnold: once amd64 builds go through, i'll install and hardening-check it
[23:53] <sarnold> sweeeet
[23:58] <teward> sarnold: that means now all I have to do is apply the Ubuntu delta to a base from Debian, and add in the delta for fixing fPIE/fPIC, and boom
[23:59] <sarnold> teward: heh is there no chance to get debian to accept the different package splits I forced on you?