[00:25] <cody-somerville> ockham, no
[00:34] <emgent> cjwatson: ping
[02:50] <slangasek> kenvandine: is empathy bzr in an uploadable state?  (Just committed a change there, would like to get it to the archive)
[03:02] <kenvandine> slangasek, it is
[03:03] <slangasek> kenvandine: thanks, will upload :)
[03:03] <kenvandine> np
[03:19] <xnox> Outstanding merges pages got a small overhaul =)
[05:18] <fabrice_sp> barry: would it make sense to merge system-config-lvm and if yes, are  you taking care of it, or may I work on it?
[05:20] <siretart> ion: \o/
[05:20] <ion> \☺/
[06:18] <superm1> slangasek, re bug 496765, is the eventual intention that plymouthd won't even be in the initrd but instead just an upstart job that gets started after the initrd is done?
[06:18] <slangasek> superm1: yes; there are some practical hang-ups preventing us from doing that right now (plymouth and gdm will race)
[06:19] <superm1> slangasek, what about the time it takes for casper though in the initrd right now?
[06:19] <slangasek> hmm?
[06:19] <superm1> that's a long time to be spinning some text on the screen
[06:19] <slangasek> if you mean 'plymouth should be in the initramfs for liveCDs', casper can drop in an initramfs-tools config snippet to ask for plymouth to be included
[06:20] <superm1> Ok
[06:20] <slangasek> (in theory - I haven't looked at whether this is the right thing for casper to do)
[06:21] <superm1> well then the question I guess is; should it be though?  maybe it's worth investigating moving the tasks casper do out of the initramfs and into the livefs itself
[06:21] <slangasek> that's what I was immediately wondering, yes :)
[06:21] <slangasek> but I'm not really familiar enough w/ casper to answer this myself
[07:03] <dholbach> good morning
[08:00] <dholbach> when are we going to have the next auto-sync run? I'm waiting on a new tex-common :)
[08:00] <dholbach> for bug 509981
[09:02] <tseliot> slangasek: just FYI in the man page of update-alternatives there's an example with alternatives with a different number of slave links
[09:05] <slangasek> tseliot: well, ok :)
[09:06] <tseliot> slangasek: I didn't remember where I saw it when I mentioned it to you and of course it was the man page. My memory...
[09:06] <tseliot> ;)
[09:19] <lool> superm1: FYI performance of casper is abysmal on armel, and JamieBennett is looking into improving that for armel and as a result for everybody; often, the scripts are simply way too heavy and were never optimized
[09:19] <lool> superm1: See e.g. bug #357690
[09:24] <ogra> lool, pfft, everybody blames casper ... its debconf ;)
[09:48] <cjwatson> emgent: yes?
[09:50] <cjwatson> ogra: no it's not
[09:50] <ogra> i thought its template.dat being loaded by debconf
[09:50] <cjwatson> ogra: casper doesn't need to start up debconf a zillion times.  I've already been working with Jamie on this
[09:50] <cjwatson> if it started it up just once, it would be loads faster
[09:50] <ogra> yeah, indeed
[10:43] <hdon> hi all. a recent karmic update seems to have blown away my swap? i chose an encrypted home filesystem when i installed, and when this update arrived i think karmic did the sensible thing and tried to offer me encrypted swap as well, but that blew away the UUID for my swap partition, making the /etc/fstab settings useless. this caused *seriously weird stability problems* even though i never actually came close to even 25% RAM usage.
[10:44] <hdon> disabling swap altogether has fixed the stability issues
[10:48] <seb128> james_w, slangasek, pitti, cjwatson, Riddell: is somebody doing syncs?
[10:48] <pitti> not me
[10:48] <seb128> the queue has some items
[10:48] <cjwatson> me
[10:49] <seb128> cjwatson, can you sync-source.py -b cassidy -S unstable telepathy-glib while you are there?
[10:49] <cjwatson> I was attempting an autosync, it seems to have fallen over
[10:49] <cjwatson> seb128: one moment - is there an associated bug?
[10:49] <seb128> cjwatson, no, IRC ping only
[10:49] <cjwatson> ok
[10:49] <seb128> cjwatson, I can do that later though
[10:50] <cjwatson> I'll do it in a moment
[10:51] <hdon> how is a partition's UUID determined?
[10:51] <cjwatson> partitions don't have UUIDs, filesystems have UUIDs
[10:52] <cjwatson> they're randomly generated when the filesystem is created
[10:52] <hdon> good to know. what about swap, then?
[10:52] <cjwatson> same
[10:52] <cjwatson> hdon: karmic *update*, or an installation over the top of a previous installation?
[10:52] <hdon> just a routine software update, like several before it
[10:52] <cjwatson> that is seriously weir
[10:52] <cjwatson> d
[10:52] <seb128> cjwatson, thanks
[10:53] <cjwatson> hdon: do you have any idea specifically which packages were updated?
[10:53] <hdon> but this is a relatively new system (just got it from system76 about 10 days ago) so i didn't get much time to familiarize myself with things prior to the updates
[10:53] <hdon> cjwatson, any way to find out? i know the kernel and video drivers were updated, but that's all fine as long as i disable swap
[10:54] <cjwatson> hdon: should be possible to dredge it out of /var/log/dpkg.log
[10:54]  * hdon looks
[10:54] <cjwatson> seb128: done
[10:54] <seb128> cjwatson, thank you
[10:55] <hdon> i'm guessing cryptsetup is the package. it looks like it was installed alongside the other updates. i never deliberately picked this package out with any apt tools myself.
[10:55] <hdon> 2010-01-15 10:37:20 status installed cryptsetup 2:1.0.6+20090405.svn49-1ubuntu7.2
[10:56] <cjwatson> slangasek: ^-
[10:56] <cjwatson> hdon: looks quite plausible, please file a bug
[10:56]  * hdon launchpads
[10:57] <cjwatson> I don't see a trivial fix, I expect it requires some thought
[10:57] <cjwatson> we certainly can't just casually mkswap over the top of things without care though
[11:02] <hdon> ;)
[11:07] <hdon> i keep getting kicked to https://help.ubuntu.com/community/ReportingBugs :\
[11:07] <hdon> i guess i'm supposed to read it
[12:12] <xteejx> Hey guys, when will the fix for bug 511014 be available in the repos?
[12:16] <chrisccoulson> xteejx: when it's built and published
[12:16] <chrisccoulson> it was only uploaded 35 minutes ago
[12:17] <xteejx> chriscoulson: Oh ok, I didn't know how long it takes, no worries :) Thank you
[12:30] <pitti> slangasek, crimsun: is bug 490634 still an issue in current lucid? I thought Intel HDA power management was disabled by default again?
[12:31] <davidc_> mvo: can I ask you a quick question please? :)
[12:32] <mvo> davidc_: yes
[12:32] <davidc_> woo!
[12:32] <davidc_> you know those debconf screens on some packages when doing apt-get install packagename
[12:32] <davidc_> is there a way to skip them by passing some arguments to the apt-get install command?
[12:33] <davidc_> say if you install apt-get install dbpackage and it pops you a debconf screen asking for a host
[12:33] <davidc_> what I'd like to do is have an bash script to automate the install and do something like apt-get install dbpackage --host=xxx
[12:33] <davidc_> or whatever the actual param from the package is which I can easily find
[12:34] <mvo> davidc_: you can use "DEBIAN_FRONTEND=noninteractive" in the environment
[12:34] <davidc_> But can I automate them? let me google up noninteractive first :P
[12:35] <mvo> yes, pre-seeding should too, but I don't have a example ATM
[12:37] <cjwatson> debconf-set-selections is the program you want
[12:37] <davidc_> ah nice one, tahnks
[12:37] <cjwatson> you can find the relevant keys (at least) by running through a test installation with DEBCONF_DEBUG=developer set
[12:37] <davidc_> well it's our own package but our sysadmin is on holidays :D
[12:38] <davidc_> so was wondering if I could try to get this running on my personal test servers
[12:38] <davidc_> finding the names of the arguments isn't a prob
[12:46] <lool> cjwatson: Not sure you're Cc:ed on the vmbuilder grub2 bug (509609); FYi I'm hitting a segfault, so I intend to try again with a noopt nostrip build of grub2
[12:46] <cjwatson> I'm probably CCed but bugmail is a bit argh
[12:47] <lool> cjwatson: Actually I didn't see you in the Cc:s
[12:49] <cjwatson> am now
[12:49] <cjwatson> lool: would be good to try with --verbose
[12:50] <lool> Ok; thanks
[12:50] <cjwatson> lool: actually --verbose --verbose
[12:50] <cjwatson>   if (verbosity > 1)
[12:50] <cjwatson>     grub_env_set ("debug", "all");
[12:51] <lool> Ack; I remember this from the debug session I did on my RAID10 issue
[12:51] <lool> cjwatson: BTW a RAID10 install with 3 disks out of 4 (partially degraded) works fine as expected
[12:51] <lool> But you can not boot with 2 disks out of 4 either
[12:52]  * lool broke 4 hard disks out of 6 in the last 2 weeks
[12:52] <cjwatson> right, I haven't got round to getting that grub bug fixed yet
[12:54] <hdon> lool, how are you breaking HDDs so fast?
[12:58] <ogra> hdon, he wants them to grow bigger, so he waters them ;)
[12:59]  * hdon giggles
[12:59] <chrisccoulson> does watering them not work then? ;)
[13:04] <ogra> /dev/sda6: clean, 146107/2321984 files, 951738/9277521 blocks (check deferred; on battery)
[13:04] <ogra> does anyone know where the check for being on battery is performed here ? is that e2fsck itself ?
[13:07] <soren> ogra: Yes.
[13:07] <ogra> thanks
[13:07] <soren> e2fsck/unix.c[is_on_batt]
[13:07] <ogra> trying to find out why it always thinks its on battery on armel systems
[13:08] <ogra> these boards dont even have a battery :P
[13:08] <soren> It looks at /proc/apm and /proc/acpi/ac_adapter/*/state
[13:08] <ogra> yeah
[13:08] <ogra> no ACPI on arm machines :)
[13:09] <ogra> but /proc/apm ...
[13:20] <zul> pitti: can you approve the MIR for python-openid, nagios-nrpe, and pastescript please? thanks
[13:22] <lool> hdon: Sad stories   :-(
[14:42] <pitti> zul: they are already approved
[14:42] <zul> k
[14:43] <pitti> ah, they are on component-mismatches now
[14:43]  * pitti promotes
[14:45] <pitti> zul: pastescript is not on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt yet
[14:46] <zul> pitti: k ill have a look
[14:47] <zul> pitti: how often does the script run?
[14:47] <pitti> zul: every hour, after the publisher run
[14:48] <zul> pitti: ok thanks
[14:48] <zul> can you promote nagios-nrpe-server as well?
[14:49] <pitti> zul: I promoted all binaries from those sources
[14:49] <zul> pitti: thanks!
[15:05] <sgallagh> tjaalton: Just released SSSD 1.0.3, which includes the fix for the linker bug you found.
[15:07] <tjaalton> sgallagh: great, thanks
[15:07] <sgallagh> tjaalton: No, thank you for catching that.
[15:08] <tjaalton> sgallagh: no problem. now if just SASL worked with AD ;)
[15:09] <sgallagh> tjaalton: Right now, I think we only support GSSAPI for SASL
[15:11] <tjaalton> sgallagh: yeah but AD expects an UPN and barfs at SPN's. it's the same with rpc.gssd from nfs-utils, but I'm about to fix that
[15:12] <sgallagh> Ah, gotcha
[15:12] <sgallagh> Patches welcome :)
[15:12] <tjaalton> sure, I need to look at it..
[15:13] <tjaalton> could be that given the time constraints I don't have time to fix sssd anytime soon, but use winbind or something in the meantime
[15:13] <tjaalton> or, certs with sssd instead of gssapi
[16:15] <jdstrand> cjwatson: how often is lp:debian/... updated? I wanted to do a libvirt merge and debian/squeeze and debian/sid are very out of date
[16:15] <jdstrand> cjwatson: hi btw! :)
[16:16] <StevenK> jdstrand: james_w would be the person to ask ?
[16:17] <jdstrand> StevenK: right, I noticed he wasn't around atm, and thought cjwatson might know...
[16:18] <jdstrand> cjwatson: if you don't know off-hand, no worries
[16:19] <geser> jdstrand: the import probably failed, check if it listed on http://package-import.ubuntu.com/
[16:19]  * jdstrand checks
[16:20] <cjwatson> jdstrand: -> james_w
[16:20] <cjwatson> I don't know the answer
[16:20] <cjwatson> jdstrand: if in doubt, you can file a bug on the 'udd' project
[16:21] <jdstrand> cjwatson: k, thanks
[16:22] <jdstrand> geser: yeah, it traced back
[16:39] <ockham> hi, i'm a newbie with a rather trivial question: what do i have to specify in debian/rules if the actual sources (including autotools files and everything) are in a subdirectory of a package?
[16:39] <ScottK> ockham: Basic packaging questions are better asked in #ubuntu-motu
[16:39] <ockham> ok, i'll ask there
[16:41] <cyberix> good day
[16:41] <cyberix> I've been thinking about trying to get miredo into Lucid+1
[16:42] <cyberix> Installing the package by default would make IPv6 work for Ubuntu users
[16:42] <cyberix> the package is currently pointing to a server run by its developer
[16:43] <cyberix> and I doubt it would be pollite to have _all_ Ubuntu users use his server
[16:44] <cyberix> Can I somehow discus this with someone running stuff at ubuntu.com or canonical.com?
[16:45] <cyberix> I understood the traffic should not be too heavy
[16:45] <cjwatson> you can ask #canonical-sysadmin
[16:45] <cyberix> thanks
[16:49] <BenC> bdmurray: Hey, would you know how to setup apparmor rules to give a program that's not running as root the ability to seteuid(0)?
[16:49] <bdmurray> BenC: No kees or smb would know better.
[16:49] <bdmurray> er sbeattie
[16:50] <BenC> kees: any ideas?
[16:50] <smb> bdmurray, BenC Or at that time of day jjohansen
[16:50] <pitti> BenC: hey
[16:50] <BenC> I forgot jj is on
[16:50] <pitti> BenC: I don't think that's possible
[16:50] <BenC> pitti: hey :)
[16:50] <pitti> apparmor can only restrict privs, not increase them
[16:50] <kees> BenC: \o/ hey man, good to see you.  :)
[16:50] <pitti> (which is a feature IMHO)
[16:50] <BenC> pitti: ah, that sucks...I need an apache2 module to be able to seteuid(0) temporarily :(
[16:50] <pitti> oh, that's a .so, isn't it?
[16:50] <kees> pitti: technically, that's not true; it can grant capabilities.
[16:51] <pitti> kees: oh?
[16:51] <BenC> there's a hackish blinkcap kernel module that allows you to do it via LSM, so I suspect apparmor could do it
[16:51] <pitti> seems my knowledge is outdated by a few years then, sorry
[16:51] <pitti> bah
[16:51] <kees> pitti: "capability foo," allows, and "set capability foo," elevates.
[16:52] <BenC> kees: hey back :)
[16:52] <kees> BenC: yeah, unfortunately I don't think AA has a way to elevate uid.  jjohansen any thoughts?
[16:52] <jjohansen> yep
[16:52] <jjohansen> you can do it with pam_apparmor
[16:52] <kees> BenC: can you write a setuid helper or something?
[16:52] <BenC> doesn't seteuid have a capability associated with it?
[16:52] <pitti> kees: so you could just grant CAP_SETUID?
[16:52] <BenC> setuid I guess would be fine too
[16:52] <jjohansen> but not at the setuid barrier currently
[16:53] <jjohansen> kees, BenC: just double checking what do you mean by elevate uid?
[16:53] <maxb> Does anyone know why the bzr branches at https://code.launchpad.net/debian/+source/subversion have been deleted?
[16:54] <kees> BenC: oh right, I always forget about CAP_SETUID
[16:54] <BenC> jjohansen: I have an apache2 module that I want to allow to seteuid(0) temporarily without running apache2 as root
[16:54] <jjohansen> kees: if you mean elevate uid to have a capability, yes and no
[16:54] <BenC> or setuid(), either way works I guess
[16:54] <jjohansen> BenC: apparmor setting of capabilities will raise none root users cap
[16:54] <kees> BenC: just a module will be tricky without a full mod-apparmor changehat configuration.
[16:55] <jjohansen> BenC: but it won't overcome any DAC checks for uid hard coded in the kernel
[16:55] <BenC> I thought the whole purpose of caps was to allow non-root programs to use root related syscalls and such :)
[16:55] <kees> jjohansen: can't it grant CAP_SETUID and then the module calls setuid(0); *stuff* setuid(getuid()); ?
[16:55] <jjohansen> kees: yes
[16:56] <BenC> basically the module currently exec's sudo and runs a script, and I want to move that into the module for stability and cleanliness
[16:56] <BenC> jjohansen, kees: that's exactly what I want
[16:56] <kees> BenC: the trouble is that AA confines processes, not libraries.
[16:57] <BenC> kees: not a problem to me...I realize that while elevated as uid 0, the whole process and whatever libs are loaded also get privs, but it's a risk I'm willing to take
[16:57] <kees> so to get this to work with apache, you'd need a full mod-apparmor configuration (which isn't hard, it's just bigger than a "simple" change)
[16:57] <kees> BenC: is this under Karmic, I hope?
[16:57] <BenC> kees: hardy
[16:58] <kees> hrm
[16:58] <kees> under Karmic the changehat stuff for mod-apparmor is well tested.  hardy, less so.  and I suspect you don't want to just run all of apparmor with CAP_SETUID.
[16:58] <BenC> it's basically running mount (on arbitrary mount points, so fstab is not involved) and calling dm_* functions
[16:58] <jdstrand> kees: I have only barely been following this, but I use change_hat on hardy
[16:59] <jdstrand> kees: though not for raising privs
[17:00] <kees> BenC: if you want to go the changehat route, read through the instructions here: http://bazaar.launchpad.net/~apparmor-dev/apparmor/master/annotate/head%3A/profiles/apparmor.d/usr.lib.apache2.mpm-prefork.apache2
[17:00] <BenC> kees: thanks
[17:00] <kees> BenC: based on what you're saying, it sounds like using sudo or a wrapper would be much saner, though.
[17:01] <BenC> kees: I want to avoid exec though, since it's killing performance to do that for every request at the rate I'm getting them
[17:02] <kees> BenC: I'm terrified that you have such a high volume of calls to mount/dm_* and the exec is the bottleneck.  :)
[17:02] <kees> BenC: you could write the wrapper to do the mount() calls directly instead of re-execing to "mount" the utility
[17:03] <BenC> kees: it's not mounting everytime, but I need root to check the dm state (dm-crypt, lvm, mount)
[17:03] <kees> cool
[17:13] <dantti> cjwatson: hi! Did you have time to work on that DBus thing for debconf?
[17:13]  * sebner is wondering who the fsck/filesystem guy is in here :)
[17:14] <cjwatson> dantti: unfortunately not, a hugely time-consuming project intervened
[17:15]  * cjwatson puts it on our sprint agenda for the first week of Feb, in order that it might actually happen :)
[17:17] <JFo> apologies pitti, I am having a bad day
[17:17] <pitti> JFo: no worries, no harm done; it just didn't quite look fitting into the current conversation :)
[17:17] <JFo> heh, it wasn't :)
[17:18] <dantti> cjwatson: hmm, I'd like to help if let me to, do you remember my proposals?
[17:25] <dantti> cjwatson: do you prefer to talk about that in Feb?
[17:26] <cjwatson> I'll have a lot more state in my head about it if we talk about it in Feb
[17:26] <cjwatson> so that might be more sensible; sorry again for the annoying delay
[17:28] <dantti> cjwatson: np, thanks, good luck with your stuff :)
[17:37] <kees> known issue?
[17:37] <kees>   docbook-utils: Depends: jadetex but it is not going to be installed
[17:46] <persia> kees: I can't reproduce with lucid amd64 : where do you see that?
[17:46] <kees> persia: http://launchpadlibrarian.net/38274976/buildlog_ubuntu-lucid-i386.wine1.2_1.1.36-0ubuntu3_FAILEDTOBUILD.txt.gz
[17:46] <kees> and my lucid chroots
[17:47] <jjardon> join #ubuntu-desktop
[17:47] <persia> Hrm.  My chroots must be out of date.  I can install for all of i386, amd64, and powerpc.
[17:47] <kees> aptitude says tex-common is broken
[17:47] <kees> but... it hasn't changed in lucid
[17:48] <persia> kees: New upload of tex-common just under 6 hours ago.
[17:52] <kees> persia: ah, that must be it.
[17:55] <kees> persia:
[17:55] <kees> Conflicts: tetex-base (<< 2007), texlive-common (<< 2009)
[17:55] <kees> texlive-base | 2007.dfsg.2-4ubuntu1 | lucid/main
[17:55] <persia> That would be it, and my apt-caches may well be > 6 hours old.
[17:56] <cjwatson> it was a sync pass, maybe check for build failures
[17:56] <kees> cjwatson: the problem is that tex-common requires a newer texlive-base that hasn't been merged.
[17:56] <persia> There's some tex stuff listed in NEW as well, which may have an impact.
[17:56] <cjwatson> right, lack of merge is entirely plausible
[17:57] <cjwatson> I'll process NEW
[17:57] <kees> and... *drumroll* I touched it last!
[18:03] <cjwatson> I've flushed all the TeX stuff from NEW
[18:07] <superm1> lool, something else to consider is moving scripts that are specific to any remix/derivative into a package that only gets seeded when you are building an image for that derivative
[18:07] <superm1> i already moved a lot of the mythbuntu stuff out
[18:09] <kees> cjwatson: can you sync texlive-base from testing?  that's the root problem afaict.  I'll have a LP bug # shortly.
[18:10] <cjwatson> no need for a bug if that's all it is
[18:10] <cjwatson> well
[18:10] <kees> well, requestsync already ran...
[18:10] <cjwatson> actually, yeah, a bug would be good
[18:11] <kees> cjwatson: oh, it's there already, heh: 509981
[18:13] <cjwatson> kees: you should poke bhavi for failing to contact you before doing that work
[18:13] <cjwatson> I've spoken to him before about this
[18:13] <kees> cjwatson: okay, I'll drop him a line.
[18:13] <cjwatson> and what's that nonsense set of dups?
[18:14] <cjwatson> meh, upgrade bugs
[18:23] <kees> cjwatson: thanks for the sync
[18:57] <slangasek> pitti: 490634> it's still an "issue" in that we shouldn't have pops when setting it; but we can probably drop the release target (done)
[18:58] <JFo> slangasek, sorry bout my blurb of useless info during the release meeting today
[18:59] <slangasek> JFo: no worries :)
[18:59] <JFo> :)
[18:59] <slangasek> it was one of the more coherent interruptions we've seen ;)
[19:00] <JFo> hahaha
[19:09] <zul> slangasek: i was wondering if you are any closer to upstarting samba yet?
[19:11] <slangasek> zul: I'm not closer yet to understanding why nmbd was failing to start, and I need to resolve that before we know which way the upstart job should be written.  I'll work on it today - though first up is "why does plymouth fail for everyone not using intel"
[19:12] <zul> ah i see priorities ;)
[19:16] <ScottK> slangasek: Because they don't love Software Freedom enough.
[19:17] <JFo> heh
[19:17] <slangasek> ScottK: I mean the plymouth bug, not the industry bug :)
[20:47] <slangasek> cjwatson: the only issue I can see with bug #511137 (hdon's cryptsetup issue from last night) is that something left a bogus unencrypted swap line in /etc/fstab when configuring crypted swap.  What installer component is responsible for configuring crypted swap when enabling crypted homedirs?
[20:51] <kees> can an archive admin process the NEW queue for texlive-2009-7?  it's holding up some builds.
[20:55] <geser> texlive-base? yes please
[20:55] <kees> yeah
[20:56] <jdstrand> slangasek, cjwatson: I've got texlive
[20:56] <slangasek> jdstrand: ok, cheers
[20:57] <sistpoty> slangasek: from ubuntu+1: <wm_> im running lucid, i did an apt-get update last night, shut machine down, i come in today and try to boot machine and its stuck at "Starting init crypto disks" .  what am i doing wrong ?
[20:57] <sistpoty> slangasek: might be related?
[20:58] <slangasek> sistpoty: not at all related to the above conversation
[20:58] <sistpoty> sorry, just figured that I didn't read karmic until now :(
[21:10] <mathiaz> kees: hi!
[21:11] <hdon> slangasek, that's my assessment, too.
[21:11] <mathiaz> kees: is there a reference to the Ubuntu policy that states: no open ports on default installations?
[21:12] <jcastro> mathiaz: https://wiki.ubuntu.com/SecurityTeam/Policies
[21:12] <jcastro> I just happened to be on that page!
[21:12] <mathiaz> jcastro: thanks!
[21:16] <hdon> lol, funny someone named "castro" telling us the governing policy about what ports we can have open ;)
[21:16] <jcastro> ubuntu libre!
[21:20] <kees> mathiaz: sorry, was in code.  jcastro got you sorted out though.  :)
[21:20] <geser> kees: is a merge of texlive-extra needed now too to unbrake texlive in lucid?
[21:23] <niktaris> hi, where can I find syslinux theme of the ubuntu .iso ?
[21:23] <kees> geser: hrm, yeah, looks like it.  whee
[21:24] <geser> kees: how big is your internet connection?
[21:24] <geser> from the Ubuntu changelog the merge looks easy but the package is big: around 500 MB source
[21:25] <kees> geser: oowchy
[21:25] <kees> geser: I will attempt a merge from the canonical datacenter, one sec
[21:57] <cjwatson> slangasek: err, not entirely sure.  might be user-setup?
[21:58] <cjwatson> slangasek: this is an "I get code dumps from kirkland" kind of thing
[21:58] <cjwatson> niktaris: I suspect you're looking for gfxboot-theme-ubuntu
[22:12] <niktaris> cjwatson, yes found it and trying to apply it to debian :-)
[22:36] <mathiaz> slangasek: hi
[22:36] <mathiaz> slangasek: with upstart jobs, is /etc/default/service still recommended for a service configuration?
[22:37] <mathiaz> slangasek: or is it now better to modify the upstart job directly?
[23:14] <geser> kees: thanks for the texlive-extra merge
[23:16] <geser> wow, LP produced a 108.3 MiB diff
[23:16] <elmo> it can produce hundreds of GB diffs in the right cirumstances (hi udev!) :-p
[23:18] <kees> heh
[23:19] <fagan> elmo: why are the diffs so large?
[23:20] <fagan> Oh and dont the launchpad guys hate when the they take up lots of space?
[23:20] <jpds> 'disk is cheap'
[23:21] <fagan> then why do we only get 1gb per ppa?
[23:21] <fagan> :)
[23:21] <StevenK> Because disk *isn't* cheap
[23:22] <fagan> Well I suppose 1tb is 50 pounds so its not so bad
[23:22] <StevenK> Say, you want to scale to 10,000 PPAs. At 1GB per, that's 10,000GB with all PPAs using all their space, or 10TB
[23:22] <StevenK> Now price 10TB with server class drives using SCSI
[23:23] <elmo> fagan: because of a bug in debdiff, I was kidding
[23:23] <elmo> but I'm very glad we've gotten into a 'disk is cheap'
[23:23] <elmo> excuse me while I go and throw myself off the roof
[23:23] <cody-somerville> lmao
[23:23] <fagan> hah
[23:29] <geser> kees: texlive should be (hopefully) unbroken now. Ideally an archive admin could remove texlive-base-bin from the NBS side to be on the safe side
[23:29] <geser> texlive-binaries provide texlive-base-bin and the most dependencies are unversioned (jadetex uses a versioned one -> bug #511399)
[23:31] <geser> I don't know if the buildds will pickup the right package: texlive-base-bin is real but uninstallable, while texlive-binaries is installable but only provides texlive-base-bin
[23:31] <kees> geser: whee
[23:38] <mathiaz> kees: would you say that apparmor profiles are safer than chroots for daemons?
[23:39] <mathiaz> kees: ex: is it safer to run bind9 under an apparmor profile or chrooting them?
[23:40] <mathiaz> kees: or to put it another way: should daemons that usually run chrooted be migrated to apparmor profiles?
[23:41] <kees> mathiaz: hrm
[23:41] <kees> mathiaz: I don't think I can make a blanket statement
[23:41] <kees> mathiaz: daemons running as non-root in a chroot are pretty well isolated.
[23:41] <kees> mathiaz: I would prefer apparmor profiles for daemons that run as root
[23:42] <kees> mathiaz: using a profile is great, but I'm not sure if it makes sense to carry a delta.
[23:42] <kees> mathiaz: note that it can do both.  :)
[23:42] <kees> i.e. write a profile for the chroot'd service.
[23:42] <mathiaz> kees: right - I'm writting my UDW session about server packages (ie daemons)
[23:42] <mathiaz> kees: and one of the topic is apparmor profiles
[23:43]  * kees nods
[23:43] <mathiaz> kees: I just wanted to compare them to chroot
[23:43] <mathiaz> kees: as chroot is often seens a way to secure daemons
[23:43] <kees> chroot is more system agnostic, but I think apparmor is stronger
[23:43] <kees> but they're not mutually exclusive.
[23:45] <mathiaz> kees: would it be fair to say that AppArmor profiles provide an alternative to chroots?
[23:45] <mathiaz> kees: *for* daemons
[23:46] <jdstrand> mathiaz: apparmor and chroots are different
[23:46] <jdstrand> like kees said, you can chroot *and* apparmor
[23:46] <kees> it's an alternative, yeah, but since they're not mutually exclusive, there's no reason to stop chroot'ing or stop using a profile
[23:46] <mathiaz> jdstrand: agreed
[23:46] <jdstrand> apparmor allows for confining capabilites and networking
[23:46] <jdstrand> you don't get that in a chroot
[23:46] <kees> if you have a daemon without either, I would do a profile.
[23:46] <jdstrand> the biggest benefit is that you don't have to maintain a chroot with apparmor
[23:47] <jdstrand> we did bind9 and mysql because though they could be configured to use them, they were not in packaging
[23:47] <jdstrand> postfix on the other hand, there is no compelling reason to write a profile for it
[23:48] <jdstrand> if a package already has a working chroot setup, I'd say look elsewhere rather than migrate
[23:49] <jdstrand> packaging an apparmor profile can also be considerably easier than a chroot
[23:49] <lamont> jdstrand: if I didn't have an ugly history of installed base, I expect bind would wind up chrooted, or at least !root
[23:49] <lamont> but since it drops all privs early on, I'm not too terribly ashamed that it starts as root
[23:49] <jdstrand> sure
[23:50] <StevenK> Bind is also fairly easy to chroot
[23:50] <lamont> StevenK: in a fresh install yes.  automatically doing it in an upgrade? not so much
[23:50] <StevenK> lamont: Well, yes :-)
[23:50] <lamont> esp since the admins out there like to roll their own world in total violation of FHS
[23:50]  * lamont looks askance of milli
[23:50] <jdstrand> of course, that is a problem for profiling, but easier to fix
[23:50] <lamont> hrm. was that my outloud voice?