[00:16] <owh> I'm about to take control over a zone entry for a domain which is currently delegated to a DNS server outside my control. I've been advised to use named-xfer to make a backup of the zone, but that tool doesn't appear to exist in Ubuntu. Was it replaced, or am I not looking properly?
[00:20] <Sattvic> Does anyone know about Google Apps for email and what happens if you switch hosting companies?
[00:26] <owh> Sattvic: Not sure I understand what you're asking, since Google Apps is hosted with Google. Switching hosting companies doesn't make sense to me in that context. What do you really mean?
[00:27] <Sattvic> My static html files are on a shared server.  I am using Google apps to host my email by pointing my MX mail records to them.  But now I want to switch web hosting providers and I want to know how that will effect my email
[00:29] <owh> Sattvic: Well, that depends on who controls your DNS. If you only change the CNAMES for your web space, the MX records will not be affected, but if your hosting company controls the DNS, make sure that they don't "help" you by changing everything.
[00:29] <owh> I'm going offline, back in about 30 minutes.
[00:30] <Sattvic> I will be using zoneedit for my DNS management - will this manage MX records too them?
[00:31] <jmarsden> owh: There is no named-xfer in bind v9.  named itself can do the same thing named-xfer used to do.  This is mentioned in http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.ch06.html
[01:23] <erichammond> soren, smoser: Is there any way that vmbuilder might somehow remove /dev/null and other /dev files? I interrupted a vmbuilder run and /dev was practically empty.  Fortunately, this was on a brand new EC2 instance so I'll just kill it and start another. http://paste.ubuntu.com/331411/
[02:07] <AndyGraybeal> does anyone have a single-sign-on implementation with ubuntu server?  i'm reading this: https://help.ubuntu.com/community/SingleSignOn  it says it's still a work in progress, and i'm just assuming this is all the documentation on this subject for ubuntu because google isn't turning much else up.
[02:09] <AndyGraybeal> looks like the overview is to install kerberos and ldap ;  i was wondering or considering also using radiuis for the accounting part.. can anyone help steer me?
[02:09] <AndyGraybeal> *radius
[02:56] <obscure> My motd tells me there are 19 packages to be upgraded some of which are security fixes, If i run apt-get upgrade to update the packages on Ubuntu Server, (apache2, php5, etc...) do I need to reconfigure them again?
[02:57] <ScottK> obscure: Not as a rule, no.
[02:57] <obscure> Ok, good. Thanks ScottK
[02:57] <Pici> Unless something wants to use an updated config file, in which case it will present you with the option to use the new one, the old one or a diff.
[02:58] <obscure> very cool
[03:21] <wolfrein> hi guys,
[03:21] <wolfrein> how can i route internet traffic through one interface using shorewall
[03:21] <wolfrein> basically, i have two internet lines
[03:22] <wolfrein> i want to shift internet traffic from one line to the other
[03:22] <wolfrein> all internet traffic onto the other line, how can i do this on shorewall
[03:22] <wolfrein> please advise
[03:26] <jmarsden> wolfrein: I'm not familiar with shorewall, but assuming simple static routing, just set the default gateway to be the line you want the traffic on.
[03:28] <wolfrein> where do i set the defaultroute?
[03:32] <jmarsden> In shorewall's config files, I would think, or if not, in /etc/network/interfaces as usual on any Ubuntu server.
[04:31] <khelvan> Hello, has anyone installed and configured fuppes on an Ubuntu Server (I'm running 8.10) via ssh before?
[04:35] <jmarsden> Yes, someone has, it seems: http://ubuntuforums.org/showthread.php?t=1310511
[04:35] <jmarsden> Ah, no that was for Karmic...
[04:41] <mushroomblue> is there a reason you'd be be using fuppes?
[04:42] <mushroomblue> meh.
[05:21] <uvirtbot`> New bug: #490201 in samba (main) "samba fails to open shares because of fixed unknown password" [Undecided,New] https://launchpad.net/bugs/490201
[05:49] <maxagaz> Is there some command line tool to check in real time the load of my network interfaces ?
[05:52] <jmarsden> maxagaz: Maybe bandwidthd (and read the CDF logs it generates)?
[05:53] <jmarsden> Most people would just use something like mrtg to graph network traffic and look at it with a web browser...
[05:54] <maxagaz> jmarsden, I'd like something like top or htop, to be used in a command line
[05:54] <maxagaz> as a command line
[05:55] <jmarsden> ntop has a browser interface but is otherwise somewhat close to that.
[05:55] <jmarsden> Hmmm, maybe jnettop -- I have not tried it...
[05:56] <jmarsden> maxagaz: Yes, looks liek jnettop will do what you want.
[06:16] <maxagaz> jmarsden, thanks! :)
[06:16] <jmarsden> maxagaz: You're welcome.
[06:19] <clusty> hey
[06:20] <clusty> i am trying to synchronize a local development version of a site to the web server. what i am looking for is a protocol that minimizes data transmission
[06:20] <clusty> could one upload data via rsync?
[06:22] <jmarsden> clusty: Absolutely.  rsync over ssh would seem very appropriate for that.
[06:23] <jmarsden> I rsync backups around that way quite a bit :)
[06:23] <clusty> rsync-backup or how is it called?
[06:24] <clusty> does rsync have any auth mechanism?
[06:24] <jmarsden> If you use it over ssh, ssh keys are the auth mechanism :)
[06:24] <clusty> or i simply make rsync remote demon not listen on the standard port
[06:24] <jmarsden> Don't use the rsync daemon.
[06:24] <clusty> and simply tunnel connection over ssh ?
[06:24] <clusty> ohh ok
[06:25] <clusty> so how would that work?
[06:25] <clusty> the local client would figure out the diff ?
[06:25] <clusty> local=development
[06:26] <jmarsden> Did you man rsync?    Something like rsync -avz -e ssh remoteuser@remotehost:remotedir /local/dir/    # rsyncs from remote to local...
[06:27] <clusty> ok got it
[06:52] <twb> Watch those trailing slashes
[08:22] <xgpt> hello
[08:22] <xgpt> is anyone still awakE?
[08:43] <twb> xgpt: no
[08:43] <xgpt> twb, lol
[08:43] <xgpt> nice
[09:39] <soren> erichammond: I've certainly meant to err on the side of caution when cleaning up, but it's not impossible there's a bug somewhere that would cause that. :-/
[09:40] <twb> xgpt: did you have a question?
[10:03] <AlexC_> morning
[10:03] <AlexC_> I've got an issue regarding partitions that need resizing on a live production server (yes, kill me later). http://ubuntuforums.org/showthread.php?p=8412551#post8412551 - I could really do with some help in this
[10:11] <maxb> AlexC_: Sounds like you actually need to move hundreds of gigabytes around on the platters. I don't see you have any options other than shutting the entire thing down, and rebuilding the new desired layout on a new physical drive, then swapping out the physical drives
[10:11] <AlexC_> ouch, not what I wanted to hear :P
[10:13] <AlexC_> well, let me throw this out there:
[10:14] <AlexC_> resize sda9 to be smaller, say by 10gb. Mv sda8 and sda7 below sda9 (to fill the new space I've just created) and then expand sda6 into the space that sda6 and 7 used to take?
[10:15] <AlexC_> That would give me, 6gb extra for /var
[10:15] <maxb> better, because it reduces the "move partition" dataset to 2.8G
[10:16] <AlexC_> do you believe this would be viable?
[10:16] <maxb> oh, sda8 is tiny
[10:16] <maxb> not 2.8G, less than a gig
[10:16] <AlexC_> yes it's /tmp and sda7 is swap
[10:17] <maxb> that seems a lot more viable
[10:17] <AlexC_> as you can probably tell - this entire partition table is messed up. I'm not sure what the installer did when I first did it, but to start with, / was 500mb =)
[10:17] <AlexC_> so I've had to do something like this few months back
[10:18] <maxb> The key thing here is to not be moving the start of any large partition, because that will force a full data-copy from one location on the disk to another
[10:18] <AlexC_> quick question, obviously I'm going to have to disable swap which is fine - but how will the kernel handle an unmounted /tmp partition?
[10:20] <maxb> The kernel shouldn't care. But userspace stuff might well
[10:20] <AlexC_> ok, well I can shutdown most if not all services
[10:21] <maxb> Still, you seem to have enough space on / that it should be able to get by with /tmp living on the root partition for a little while
[10:21] <AlexC_> ah, yes - that'll do it
[10:21] <maxb> Just remember to set the permissions properly on the /tmp mountpoint after you've unmounted it
[10:22] <AlexC_> how'd you mean?
[10:23] <maxb> I mean, the permissions on the underlying mountpoint will likely not be the proper ones for an active /tmp directory
[10:23] <maxb> Because once mounted, it is the permissions on the mounted device which matter
[10:23] <AlexC_> oh right, yes
[10:24] <maxb> Thought for the future: I don't see any reason for partitioning so aggressively at all - not if everything's on the same underlying disc anyway
[10:25] <AlexC_> true
[10:29] <AlexC_> maxb, silly question, how do I actually get /tmp on /? Simply unmount and remove entry from fstab, then kernel should just start using /tmp on /?
[10:33] <maxb> The kernel doesn't really use /tmp
[10:33] <maxb> Use lsof +D /tmp to get an idea of what processes you'll need to stop / kill
[10:33] <maxb> check and rememember the current permissions
[10:33] <maxb> unmount and reapply permissions
[10:34] <maxb> update fstab just in case, I guess
[10:49] <AlexC_> maxb, how about http://ubuntuforums.org/showthread.php?p=8412551#post8412551 ? Seems like it could work smoother
[11:02] <AlexC_> hum, /home is busy - how can I resolve that?
[11:14] <qman___> AlexC_, umount -l will prevent new operations from starting, wait for current operations to finish, and then unmount it
[11:14] <qman___> presuming that's what you were referring to
[11:38] <mdz> ttx: I've made a pass over the blueprints this morning as well; they are all now either approved or back to drafting
[11:38] <mdz> except for the two QA specs, which are awaiting review/approvel from marjo
[11:48] <AlexC_> qman___, a ha, awesome - thanks, shall try that later on
[12:11] <IcyPolecat> hiya, does anyone know if it's possible to configure ftp (pro, vs or other) to work with the www-data user and group used by apache for multiple users?
[12:12]  * soren lunches
[12:33] <ttx> mdz: ok, I completed my first pass this morning as well.
[12:34] <ttx> mdz: will sync with smoser today to help him add details to his specs, if needed.
[12:46] <maxagaz> how to have a persistent resolv.conf with ppp connection
[12:46] <maxagaz> it's always replaced by the provider stuffs
[12:52] <soren> mdz: server-lucid-other-cloud-providers and server-lucid-vmbuilder-multiple-outputs are still set to "review". I'm not entirely sure what to make of that.
[12:55]  * zul hates snow
[12:56] <mdz> soren: they aren't on https://blueprints.edge.launchpad.net/ubuntu/lucid?searchtext=server-lucid
[12:57] <soren> ?!?
[12:57] <soren> Oh /lucid!
[12:57] <soren> Erm.. Yeah, that's unfortunate.
[12:58] <mdz> soren: in terms of targeting things for lucid, I'm worrying first about the things we are doing for the first iteration (alpha 2)
[12:58] <mdz> we'll be re-juggling priorities at that point anyway
[12:58] <mdz> I think we have enough to do for alpha 2 already
[12:58] <soren> Ok.
[13:02] <mdz> ttx: that reminds me, what should we do with java-library-fixes?
[13:03] <ttx> mdz: it's reasonable to target it to post-alpha2, I'd say alpha-3
[13:03] <mdz> you already have euca-remote-registration and eucalyptus-karmic-retro work to do for alpha 2; do you think java-library-fixes is doable as well?
[13:04] <mdz> ok, let's leave it un-milestoned then
[13:04] <ttx> mdz: those are all "good to have" fixes for LTS rather than new features
[13:04] <mdz> ttx: bug-zapping is milestoned for alpha 1(?!) but has no spec yet
[13:05] <ttx> mdz: yes, kirkland targeted it, I think the idea was to have it started early in the cycle
[13:05] <ttx> mdz: though it could be considered "completed" by the end of the cycle
[13:06] <ttx> depending on whether the spec covers just the process setup or the zapping sessions as well.
[13:06] <mdz> ttx: I don't even know what work is involved since there is no spec or work items
[13:09] <ttx> mdz: kirkland should work on that one when UEC testing is fixed. Should be unmilestoned until you get more info
[13:10] <soren> mdz: I just thought we wanted to have everything spec'ed by the end of last week, not just the stuff for alpha 2 (which AIUI is yet to be completely defined)?
[13:11]  * ScottK is still trying to finish his mail integration spec.
[14:12] <AlexC_> maxb, alive?
[14:13] <maxb> hello
[14:13] <AlexC_> hey
[14:14] <AlexC_> right, what I did was split /dev/sda9 up to make another 50gb partition. What I then did was 'dd if=/dev/sda6 of=/dev/sda10' to copy the old /var over to the new partition. However when doing an 'fsck -n /dev/sda10' it came up with filesystem errors regarding inodes. So, I did 'mkfs.ext3 /dev/sda10' and 'cp -ar /var /vartmp' (mounted /dev/sda10 as /vartmp)
[14:15] <AlexC_> however - while files do seem to be in the new /var, some things aren't. I don't think a 'cp' is the best way to do this. How else can I copy the older (smaller) partition data to the newer, larger one?
[14:16] <maxb> I would have thought a cp -a would have done the job
[14:16] <AlexC_> I shall try it again, it actually looks like nothing was copied. Hum
[14:23] <smoser> soren, saw erichammond's question from yesterday about vmbuilder failing and removing /dev files. i've seen this too. (on nectarine)
[14:25] <AlexC_> maxb, k, working. Thanks for all the help. Sorry for bothering you again
[14:25] <AlexC_> much appreciated
[14:48] <soren> smoser: Yikes.
[14:48] <soren> smoser: /me ponders
[14:48] <soren> smoser: I can't imagine why that would happen.
[14:50] <Ng> are final karmic images heading for the UEC imagestore? :)
[15:05] <soren> Ng: They're.. not.. there? O_o
[15:05] <Ng> soren: shows RC images for me
[15:05]  * soren sighs
[15:05] <Ng> they might be the same, but they identify as RC
[15:06] <Ng> there's two of them and the mediawiki test image thing
[15:06] <soren> Right.
[15:07] <smoser> i'm fairly sure they *are* rc
[15:07] <smoser> per aubre
[15:08] <Ng> bug #457283 makes it a little irrelevant I suppose, since they don't boot anyway ;)
[15:09] <Ng> also while I'm on the subject - I'd like to check for, or file a bug about the naming of images pulled from the imagestore - which component is actually doing that?
[15:09] <Ng> image-store-proxy I think?
[15:12] <smoser> Ng, the released images should boot fine. and the RC were tested as functional, so i think the issue of "they don't boot" isn't 100% true. Multiple people have reported it, but i have not seen it, and personally did test the RC images on UEC before release.
[15:12] <ttx> Ng: could also be in eucalyptus itself
[15:13] <ttx> Ng: since some of the image store code is implemented there.
[15:14] <Ng> smoser: I only just installed eucalyptus on some random hardware at home to test the image store and I'm seeing the above bug booting either image. I'd happily boot the instances without the (to me useless) ephemeral storage :)
[15:14] <Ng> ttx: ok, well I'll start with the image-store-proxy and see what gustavo does with the suggestion
[15:14] <smoser> Ng, you see that bug booting the release images ?
[15:14] <ttx> Ng: sounds good.
[15:15] <Ng> smoser: I haven't tried them, I just clicked the image store buttons to install those. I'm happy to try other images
[15:15] <smoser> oh. ok.
[15:15] <smoser> Ng<EMAIL_ADDRESS>?
[15:16] <smoser> pretty please update that?
[15:23] <kirkland> ttx: hey
[15:23] <kirkland> ttx: couple of questions/comments about the pending Eucalyptus SRU
[15:23] <ttx> kirkland: yo
[15:23] <ttx> kirkland: the 7.3 one ?
[15:23] <kirkland> ttx: you were telling me you have another one queued up?
[15:23] <kirkland> ttx: yeah, so, i have two things
[15:23] <ttx> yes, I've a branch ready
[15:24] <kirkland> ttx: first, i can confirm that 7.3 euca_rootwrap powerwake stuff works
[15:24] <ttx> kirkland: cool
[15:24] <kirkland> ttx: second, i have identified a breakage and a fix for the POWERSAVE problem
[15:24] <kirkland> ttx: i'm not sure if 7.3 caused that regression, or if it's there already
[15:24] <kirkland> ttx: but here's what I'm thinking ....
[15:24] <smoser> ttx, kirkland... i know that it has seen no work, and you want to get a refresh out... but we really need a fix for the user-data.
[15:25] <ttx> smoser: the eucalyptus part of that fix is in my branch
[15:25] <kirkland> ttx: i think i can just sign off on 7.3 as is, and add my one-line fix to your 7.4
[15:25] <kirkland> ttx: what do you think?
[15:25] <ttx> kirkland: sounds good to me
[15:25] <smoser> ttx, where?
[15:25] <kirkland> cool
[15:25] <ttx> that way 7.4 will be in -proposed for smoser to play with :)
[15:26] <ttx> smoser: https://code.launchpad.net/~ttx/eucalyptus/karmic-sru2
[15:26] <ttx> + my PPA for your testing pleasure
[15:26] <ttx> smoser: see https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/461156/comments/27
[15:27] <smoser> rock on ttx
[15:27] <kirkland> ttx: is smoser's user-data fix in your SRU?
[15:27] <kirkland> ttx: 7.4?
[15:27] <ttx> smoser: i'm trying to see if the euca2ools SRU yo uprepared should also include bug 450044
[15:27] <ttx> kirkland: smoser's fix is in euca2ools
[15:28] <ttx> 461156 needs two fixes, one in eucalyptus and one in euca2ools
[15:28] <smoser> personally i dont care so much about that one
[15:28] <ttx> the one in eucalyptus needs to go before (orr at the same time) as the euca2ools one
[15:28] <smoser> bug 461156
[15:28] <kirkland> ttx: where's your branch?
[15:29] <smoser> kirkland, https://code.launchpad.net/~ttx/eucalyptus/karmic-sru2
[15:29] <ttx> ^
[15:29] <ttx> kirkland: feel free to merge once 7.3 is cleared
[15:30] <smoser> ok. ttx, so i dont care all that much about the rebunding (euca-bundle-vol). i wouldn't postpone release for it unless it is very close.
[15:30] <ttx> smoser: ok
[15:30] <ttx> so process is ack 7.3 out of the door, prepare 7.4 from my branch + kirkland's POWERSAVE fix (file bug about that one), commit to proposed both the euca2ools and the eucalyptus 7.4
[15:31] <smoser> rebundling on a live instance doesn't make all that much sense to me, when you can just download the pristine image and chroot to change it
[15:31] <kirkland> ttx: i just pinged pitti to let him know
[15:31] <ttx> we'll try to sneak the rampart fix in the second bundle as well, if nurmi acks it
[15:32] <smoser> ttx, so what do you need from me.
[15:32] <ttx> bug 460085 -- requiring both the eucalyptus fix (in my branch) and a rampart SRU
[15:32] <ttx> smoser: nothing, I think
[15:32] <ttx> smoser: a debdiff / merge proposal for your euca2ools fix, maybe
[15:33] <ttx> (if not already submitted)
[15:33] <smoser> that is easy to produce if you want it. i will do that.
[15:34] <zul> ttx: ping
[15:35] <zul> ttx: for the daily vcs spec "I would split the work for each package: have one "Import debiandir + Write recipes" item and one "Upload to PPA + publicize" item for each selected package." are you refereing to the workitems?
[15:35] <ttx> smoser: the debdiff in your PPA should be ok for that
[15:36] <ttx> smoser: no real need to resubmit it.
[15:36] <ttx> zul: yes
[15:36] <smoser> ok. i was just about to post a link to it.
[15:36] <zul> ttx: ok thanks
[15:38] <ttx> smoser: if you need any help in fixing your blueprints based on the reviews, let me know
[15:38] <ttx> smoser: you have a lot to do and it's your first time through this process :)
[15:38] <smoser> i'll dig through those today and will get back to you. i agreed that there was little infomration about the boot hooks :)
[15:52] <ttx> kirkland: hm, about bug 490382...
[15:52] <kirkland> ttx: yeah
[15:52] <ttx> I think it's a feature.
[15:52] <kirkland> ttx: i found it helped to move the rm -f /var/lib/eucalyptus/CC/* a bit higher
[15:53] <kirkland> ttx: hmm, well, it's keeping SCHEDPOLICY changes from taking affect at all
[15:53] <ttx> kirkland: let me dig some context
[15:54] <ttx> https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/460089
[15:55] <ttx> so this is indeed a regression in the -proposed package
[15:55] <ttx> since this was introduced in 7.2
[15:55] <ttx> kirkland: you should probably stop the presses
[15:56] <kirkland> ttx: hrm, well, if I can "sudo restart eucalyptus CLEAN=1" and get the behavior I want, I can just update the documentation
[15:56] <ttx> kirkland: we already know this is necessary if you change network things in eucalyptus.conf
[15:56] <ttx> kirkland: which (imo) is more than confusing
[15:57] <kirkland> ttx: okay, now I'm confused as to your recommendation
[15:57] <kirkland> ttx: what do you recommend?
[15:57] <ttx> see https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/464384
[15:58] <ttx> kirkland: just a sec
[15:58] <ttx> kirkland: could you check that using CLEAN=1 is ok to workaround the "take POWERSAVE into account" issue ?
[15:58] <kirkland> ttx: sure, i'll test that now
[15:58] <ttx> then I'd just release 7.3
[15:59] <ttx> and we make sure we fix bug 460089 with more deocumentation/helpers
[15:59] <ttx> arh
[15:59] <ttx> not that one
[15:59] <ttx> and we make sure we fix bug 464384 with more deocumentation/helpers
[16:02] <ttx> kirkland: let me know if anything remains fuzzy, should be clear after reading those two bugs
[16:02] <kirkland> ttx: okay, i'm testing now
[16:02] <kirkland> ttx: unfortunately it takes a long time to test these
[16:02] <ttx> ok
[16:02] <kirkland> ttx: as it takes ~5 minutes to put the nodes to sleep
[16:03] <ttx> personally I'm not that convinced about the CLEAN=1 trick. I expect configuration changes to kick in at restart. But that's a tradeoff, being able to update a running eucalyptus without losing running VMs is quite interesting as well
[16:04] <ttx> kirkland: in the end it's more a documentation issue, which is the point of filing bug 464384
[16:04] <kirkland> ttx: https://help.ubuntu.com/community/UEC/PowerManagement
[16:04] <kirkland> ttx: yeah, i just added it to there
[16:05] <ttx> kirkland: in my testing I did use CLEAN=1 though, and failed to get it to work, so...
[16:05] <ttx> better confirm that first.
[16:07] <kirkland> ttx: hmm, there's still something wrong
[16:07] <kirkland> -rw-------  1 eucalyptus eucalyptus<PHONE_NUMBER> 2009-11-30 10:00 eucalyptusCCInstanceCache
[16:07] <kirkland> ttx: that file is not getting cleared
[16:08] <ttx> hrm
[16:09] <ttx> kirkland: it clears the others but not that one ? Do they have different permissions ?
[16:10] <kirkland> ttx: no diff on perms
[16:10] <kirkland> ttx: it doesn't look like the $CLEAN var is being passed
[16:10] <kirkland> ttx: as if i remove the $CLEAN = 1 test, it does remove the files
[16:10] <ttx> arh, more upstart mysteries
[16:11] <ttx> then it's a regression... we should hold that -proposed release
[16:11] <ttx> kirkland: if you pined pitti, you should ask him to pause
[16:11] <ttx> pinged
[16:12] <ttx> maybe it's the bashism
[16:12] <kirkland> ttx: i think it's a shell bashism
[16:12] <kirkland>         [ "${CLEAN}" = "1" ] && rm -f /var/lib/eucalyptus/CC/*
[16:12] <kirkland> vs.
[16:13] <kirkland>         [ "${CLEAN}" = 1 ] && rm -f /var/lib/eucalyptus/CC/*
[16:13] <kirkland> "1" works
[16:13] <kirkland> 1 doesn't work
[16:13] <kirkland> ttx: i think that's all there is to it
[16:13]  * kirkland tests some more
[16:13] <kirkland> ttx: yup
[16:14] <kirkland> ttx: that's it
[16:14] <ttx> kirkland: what's your opinion ? we probably shouldn't release 7.3 without a way to CLEAN the cc env, imo
[16:15] <kirkland> ttx: yeah, i agree
[16:15]  * ttx grumbles
[16:15] <kirkland> ttx: i know ....
[16:15] <kirkland> ttx: it takes so long to get all parties to agree on an SRU
[16:15] <ttx> two options, fast-tracking a 7.4 with only the one-liner fix
[16:16] <ttx> or do a complete 7?4
[16:16] <ttx> 7.4
[16:16] <ttx> I prefer the one-liner option
[16:16] <ttx> since I'd like long testing of the rampart/ memleak fix
[16:16] <kirkland> ttx: well, if we release 7.3 as is, it's at least 1 week before -updates users get this CLEAN restart fix
[16:17] <kirkland> ttx: okay, i'll upload a 7.4 with this one-liner fix
[16:20] <kirkland> ttx: is mathiaz working today
[16:20] <kirkland> ttx: i'd like him to ack this simple change
[16:20] <ttx> kirkland: he should
[16:20] <kirkland> ttx: cool
[16:21] <kirkland> ttx:  http://paste.ubuntu.com/331811/
[16:21] <kirkland> ttx: i'd like to upload that to karmic-proposed now
[16:21] <kirkland> ttx: and ask pitti to hold off on promoting 7.3
[16:24] <ttx> kirkland: do you have the power to reject it from -proposed, as an AA ?
[16:25] <kirkland> ttx: yes, I think so, but we're not supposed to touch our own uploads
[16:25] <ttx> ok
[16:26] <kirkland> ttx: hrm ...
[16:32] <cj> any canonical reps here?
[16:33] <cj> if so, pm or email<EMAIL_ADDRESS>- thinking about offering support for our cloud stuff
[16:48] <pipedream> .
[16:50] <jpds> cj: Would be a better idea to send an email through the links at: http://www.ubuntu.com/cloud/support
[17:14] <smoser> jjohansen, ping
[17:30] <EtienneG> hey guys
[17:31] <EtienneG> seems like I have not spent enough quality time with Eucalyptus 1.6 yet ... when/why would it use a tap device?
[17:31] <EtienneG> I thought it was only for inter-cluster communication, is that right?
[17:57] <jjohansen> smoser: pong
[17:57] <smoser> hm... i think i figured out what i was going to ask.
[17:57] <smoser> but i do have one question
[17:57] <smoser> what do the lucid kernels look like for ec2 ?
[17:57] <smoser> they have any changes to karmic in them?
[17:58] <jjohansen> yeah, I rolled in ext4, and virtaudio
[17:58] <jjohansen> I uploaded a test kernel last week
[17:59] <jjohansen> smoser: I still need to finish going through the configs, but the kernel should start showing up as part of the daily builds this week
[18:00] <jjohansen> smoser: 64bit 2.6.32 test kernel aki-c4c527ad, ari-d8c527b1
[18:00] <smoser> ok. so the ones that are in the archive now are just karmic, but later this week you'll push "real lucid"
[18:00] <smoser> right?
[18:00] <jjohansen> right
[18:01] <jjohansen> apw: was doing some packaging work on it this morning
[18:01] <smoser> so you'll expect that 428692  would be fixed
[18:02] <apw> bug #428692
[18:02] <apw> jjohansen, yep, my test builds are going now
[18:02] <smoser> so those would be turned on.
[18:02] <jjohansen> smoser: yep
[18:02] <apw> jjohansen, are those config changes in your branch i took?
[18:02] <smoser> the other part of that bug is "more like -virtual"
[18:02] <jjohansen> apw: yes
[18:02] <apw> jjohansen, ok thanks
[18:02] <smoser> ie, pruning of non-virutal related modules
[18:03] <apw> jjohansen, you happy with the ocntents of your branch, as a first stab -ec2 kernel for lucid?  assuming my builds pass now ?
[18:03] <jjohansen> smoser: I haven't rolled in all the virtual config options but I did grab the ones we have some bugs against, ext4, loop, virtaudio
[18:03] <jjohansen> apw: yeah
[18:03] <apw> jjohansen, ack, ok my test builds look ok, so i'll be getting it up shortly
[18:04] <jjohansen> apw: thanks
[18:04] <smoser> jjohansen, ok... thats good, just wanting it also to be smaller, no reason for lots of drivers in ec2
[18:05] <jjohansen> yeah, this first round is bigger than it needs to be, but the configs will get tightened up
[18:07] <kirkland> mathiaz: hi!
[18:08] <kirkland> mathiaz: i have some questions about eucalyptus clean-restart
[18:08] <kirkland> mathiaz: something about this is making powersave not work quite right
[18:14] <kirkland> mathiaz: also, i need to talk to you about the uec-testing spec
[18:28] <cj> jpds: thanks.  I didn't know that existed.
[18:36] <RoAkSoAx> kirkland, I'll work on testdrive as soon as I finish my exams :)
[18:36] <kirkland> RoAkSoAx: ;-)  awesome
[18:37] <RoAkSoAx> kirkland, btw... you want it to support other distributions and not only '*Ubuntu Desktop/Server/Netbook' right?
[18:42] <alex88> hi all..i have a pc with ubuntu and a brand new install..is possible to use the installed debs via synaptic and install on the fresh install? cause i haven't a high speed internet here
[18:44] <alex88> ok found some in /var/cache/apt/archives/
[18:48] <cj> jpds: hurm, I think /cloud/support is aimed more at end-users... I want to find a way to potentially integrate a support offering in to a cloud service
[18:57] <bogeyd6> !firewall
[19:07] <benedikt> I need an idea for backups. I have a private server on a remote location. Now it backups up my personal stuff from home and itself and puts it on a usb drive. I want something safer (for the server data) but i cant figure out a smooth backup plan. And i use rsnapshot for the backups.
[19:09] <cemc> on my Karmic in mysql console the reverse search (Ctrl+R) does not work. how can I enable it ?
[19:13] <cj> cemc: you prolly need to install readline
[19:13] <cj> libreadline6
[19:13] <cj> I bet mysql-client recommends it
[19:15] <cj> well, the lenny one does
[19:15] <cj> $ apt-cache show mysql-client-5.0 | grep -i rec
[19:15] <cj> Recommends: libterm-readkey-perl
[19:16] <cj> try installing libreadline6 and libterm-readkey-perl
[19:18] <cemc> cj: they are installed. it seems in Karmic mysql is not built with readline, found some forum thread
[19:37] <cj> cemc: ah.  yeah, there were some license issues that I recall from my tenure there...
[19:37] <cj> cemc: which mysql-client do you have installed?  you might try mysql-client-5.0 if you've currently got 5.1
[19:47] <cemc> cj: if I try to install mysql-client-5.0, it wants to remove mysql-client-5.1 AND mysql-server
[19:49] <cj> that's crazy.  do you need any of the features from 5.1?
[19:50] <cj> it might be better to build your mysql-client-5.0 package yourself.  either that or connect to your server remotely
[19:50] <cj> I rarely need to use the run the mysql client on the server
[19:55] <cj> s/use the /
[20:01] <cj> er, I meant it might be better to build your mysql-client-5.1 package yourself, since that's the one missing readline support.
[20:02] <cj> it's like it's lunchtime all over the world
[20:04] <micahg> was there a decision to stick with PHP 5.2 in lucid?
[20:22] <genii> !info php5 lucid
[20:25] <micahg> I guess it doesn't mean anything as 5.3 isn't even in debian unstable yet
[20:25] <ttx> kirkland: howdy
[20:25] <kirkland> ttx: hey
[20:25] <kirkland> ttx: i told pitti to go ahead and publish to -updates
[20:26] <kirkland> ttx: as I think I was just seeing the racy behavior reported elsewhere
[20:26] <kirkland> ttx: which we should fix subsequently
[20:26] <ttx> kirkland: ok, not a regression then
[20:26] <kirkland> ttx: i'm also nearly done with the initial 1.6.1 merge
[20:26] <kirkland> ttx: i don't think so
[20:27] <ttx> kirkland: ok
[20:27] <ttx> kirkland: We need to implement CLEAN in start anyway
[20:28] <kirkland> ttx: yes, we do
[20:28] <kirkland> ttx: i didn't want to block what we had alraedy any longer, though
[20:28] <ttx> kirkland: might workaround the race in stop.
[20:28] <zooko> Folks: what's the state of the art in union filesystems for Karmic?  I'm trying to build a USB flash drive for boot, and ideally a union with a RAM disk so that writes don't actually reach the flash.
[20:28] <kirkland> ttx: i thought that it would be best to get the fixes we have out now
[20:28] <kirkland> ttx: so that we can focus on the next round of fixes
[20:28] <ttx> kirkland: agreed.
[20:28] <kirkland> ttx: good ;-)  i was hoping we'd see eye to eye on this one
[20:29] <ttx> kirkland: could you file a bug about the missing start/CLEAN=1 ?
[20:30] <kirkland> ttx: well, or convert the one i opened to actually say that
[20:30] <ttx> kirkland: we'll have to test if restart / CLEAN=1 as well, dunno how well tat would work
[20:30] <ttx> kirkland: sure.
[20:30] <kirkland> ttx: mathiaz is having some hardware issues with his laptop today
[20:30] <ttx> though the race in stop is actually a separate issue from missing start/CLEAN=1 support
[20:30] <kirkland> ttx: i was going to sync up with him once he's back online
[20:31] <ttx> ok, see you tomorrow then.
[20:31] <ttx> keep the bugs updated ;)
[20:48] <zooko> https://wiki.edubuntu.org/KernelTeam/ReleaseStatus/Karmic says that aufs is chosen as the union mechanism for karmic, but https://lists.ubuntu.com/archives/kernel-team/2009-April/005184.html says that it is disabled for karmic.  Which is newer?
[20:51] <zooko> Hm, and https://blueprints.launchpad.net/ubuntu/+spec/update-manager-aufs-karmic seems to say that aufs will be supported in karmic.
[20:53] <aljosa> anybody knows if there is a reason why zenoss is not available in ubuntu?
[20:57] <cj> heya jono
[20:57] <jono> hey
[20:57] <cj> I listened to your interview the other day ;)
[20:58] <cj> how's it feel to be a celeb?
[21:01] <soren> mdz: So, as you say lucid-server-other-cloud-providers is not on b.l.p/ubuntu/lucid. It /is/ proposed for Lucid, though. Is there no way to reject it, or is there some other reason it's kept in limbo?
[21:02] <soren> mdz: As a lowly minion, I can only suggest blueprints for a particular release series, not approve them.
[21:21] <mathiaz> kirkland: reading the backlog - seems you've pushed the SRU?
[21:21] <mathiaz> kirkland: do you need any help on thi?
[21:21] <mathiaz> kirkland: this
[21:21] <kirkland> mathiaz: yes, to both
[21:21] <kirkland> mathiaz: we did push the sru
[21:21] <kirkland> mathiaz: however, CLEAN=1 doesn't always work for me
[21:21] <kirkland> mathiaz: i think there's a race condition
[21:22] <kirkland> mathiaz: or some non-determinism
[21:22] <mathiaz> kirkland: hm ok.
[21:22] <kirkland> mathiaz: we've decided to fix that in the next upload
[21:22] <mathiaz> kirkland: IIRC CLEAN=1 is a new feature ?
[21:22] <kirkland> mathiaz: i think you added it in 7.2
[21:22] <mathiaz> kirkland: well - we've changed the default behavior of the init script, then added an option to fall back to the old behavior if needed
[21:23] <kirkland> mathiaz: right, and I'm saying that I don't think the fallback code (CLEAN=1) is quite adequate
[21:23] <kirkland> mathiaz: ie, i sometime restart with CLEAN=1 and my /var/lib/eucalyptus/CC is *not* cleaned
[21:24] <mathiaz> kirkland: ok.
[21:24] <kirkland> mathiaz: but sometimes it is
[21:24] <mathiaz> kirkland: we can fix that in another SRU I guess
[21:24] <mathiaz> kirkland: now it may be related to upstart?
[21:24] <kirkland> mathiaz: yeah, ttx already has another branch going
[21:24] <mathiaz> kirkland: great - anything else I can help with?
[21:24] <kirkland> mathiaz: yes, as a matter of fact
[21:25] <kirkland> mathiaz: i'm also working on the eucalyptus upstream merge for lucid
[21:25] <kirkland> mathiaz: it seems that they have added a debian/ directory
[21:25] <kirkland> mathiaz: this is giving me some trouble
[21:25] <mathiaz> kirkland: right - they mentioned that at UDS
[21:25] <kirkland> mathiaz: when i do a "bzr export" from their 1.6 branch, i get a debian/ in the tarball
[21:26] <kirkland> mathiaz: bzr bd -S doesn't like this at all
[21:26] <mathiaz> kirkland: hm... I kind of understand why
[21:27]  * mathiaz thinks about a solution
[21:27] <kirkland> mathiaz: we could manually create the tarball
[21:27] <kirkland> mathiaz: bzr export really should have a --exclude option
[21:27] <kirkland> mathiaz: i've been asking the bzr guys this for >1 year
[21:27] <mathiaz> kirkland: right - but don't you run into problem when you merge the upstream branch in the ubuntu branch?
[21:28] <kirkland> mathiaz: oh, well, yeah, that's another part of the problem
[21:29] <mathiaz> kirkland: let me try something..
[21:29] <mathiaz> kirkland: you're still using lp:~ubuntu-core-dev/eucalyptus/ubuntu/ as the branch to work from?
[21:29] <mathiaz> kirkland: for your lucid branch?
[21:30] <mathiaz> kirkland: and what's the upstream branch you're trying to merge?
[21:33] <kirkland> mathiaz: on the phone with nurmi
[21:36] <jdstrand> soren: hi! fyi, I'll be working on the libvirt merge today/tomorrow
[21:37] <soren> jdstrand: Merge with Debian or upstream or both?
[21:37] <jdstrand> soren: well, both
[21:37] <jdstrand> soren: upstream just has a couple of things
[21:38] <soren> jdstrand: You're kidding, right?
[21:38] <jdstrand> soren: 0.7.2 has almost everything, but needs a few extra bits
[21:38] <soren> jdstrand: the changelog from 0.7.2 -> 0.7.4 is gigantic.
[21:38] <jdstrand> soren: oh, gosh, not 0.7.4
[21:38] <jdstrand> soren: I meant merge Debian, and apply a couple small commits for the AA driver
[21:38] <soren> jdstrand: Ah, ok. That's what I meant by "with upstream" :)
[21:39] <jdstrand> soren: after this merge, it won't be as important that *I* do it
[21:40] <jdstrand> soren: this one is slightly messy cause 0.7.0 has the sVirt patch and 0.7.2 has it included
[21:40] <ScottK> Of course then you'll be TIL and stuck with it forever anyway.
[21:40] <ScottK> ;-)
[21:40] <soren> ScottK: ssshh.. All part of my master plan :)
[21:41] <jdstrand> heh, maybe I'll 'accidentally' forget the changes to ubuntu15 ;)
[21:42] <soren> jdstrand: Feel free to comment out the eventtest unit test. I need to poke at that a little bit.
[21:42] <soren> jdstrand: Without that one, everything should work just fine.
[21:42] <jdstrand> soren: ok
[21:45] <kirkland> mathiaz: okay, back now
[21:46] <kirkland> mathiaz: lp:eucalyptus/1.6 and lp:~ubuntu-core-dev/eucalyptus/ubuntu
[21:46] <kirkland> mathiaz: i think it's going to be easiest just to create the tarball myself --excluding .bzr and debian/
[21:46] <mathiaz> kirkland: ok - thanks. I'll try a couple of things to handle the debian/ directory
[21:46] <kirkland> mathiaz: cool, let me know what you find
[21:46] <mathiaz> kirkland: yeah - that won't solve the case of the merge though
[21:47] <kirkland> mathiaz: fwiw ... http://paste.ubuntu.com/331961/
[21:47] <kirkland> mathiaz: i'm trying to document what needs to be done each time i merge
[21:47] <kirkland> mathiaz: i have the TODO of merging Eucalyptus into Lucid every Monday, once a week
[21:47]  * mathiaz oks
[21:48] <kirkland> mathiaz: those instructions are kinda broken right now, due to the debian/ wonkiness
[21:50] <kane_> kirkland++ # scripting
[21:51] <zooko> FWIW, the Tahoe-LAFS project is planning our next release to be early enough to get into Lucid: http://allmydata.org/pipermail/tahoe-dev/2009-November/003169.html
[21:51] <kirkland> kane_: is that an affirmation?  :-)
[21:52] <kane_> positive karma for automating tasks, right? :)
[21:52] <kirkland> kane_: ah, yeah :-)
[21:52] <mathiaz> kirkland: seems I got the merge working:
[21:53] <kirkland> mathiaz: hrm, what was I doing wrong?
[21:53] <mathiaz> kirkland: branch upstream-1.6, bzr remove debian/, bzr ci
[21:53] <mathiaz> kirkland: branch lucid, bzr merge upstream-1.6-nodebian
[21:53] <kirkland> mathiaz: oh, that's cheating :-)
[21:53] <mathiaz> kirkland: well - hopefully upstream will do the same soon ;)
[21:54] <kirkland> mathiaz: i talked to dan; he was going to see about removing debian/
[21:54] <kirkland> mathiaz: but no promises right now
[21:54] <kirkland> mathiaz: i suggested that he creates a packaging/ dir, and bzr mv's debian to there
[21:54] <mathiaz> kirkland: ok - so they'll probably do the same thing
[21:54] <kirkland> mathiaz: and symlinks to it when they want to build their package or something
[21:54] <kirkland> tar zcvf eucalyptus_$VER~bzr$REVNO.orig.tar.gz --exclude .bzr --exclude debian eucalyptus_$VER~bzr$REVNO
[21:54] <kirkland> mathiaz: ^ is what i'm doing for now
[21:55] <mathiaz> kirkland: right - did you add to a get-orig-source rule?
[21:55] <mathiaz> kirkland: get-orig-source target in the debian/rules file?
[21:56] <kirkland> mathiaz: no ... but I will if i can make this work in an automated fashion
[21:56] <mathiaz> kirkland: and the merge shouldn't be that hard actually - we know which version of the file we want
[21:56] <mathiaz> kirkland: there isn't any manual editing to be done
[21:56] <kirkland> mathiaz: what "file" ?
[21:56]  * mathiaz tries
[22:11] <majuk> I feel duuuumb. Say I have a user in group X (but is not its primary group) which is the group-owner of folder Y... with 770 permissions I can't access Y with user X. Am I missing something?
[22:11] <majuk> *with user in group X
[22:12] <majuk> Does it have to be that user's primary group in order to access the folder with those perms? That doesn't make any sense to me, but I am often crazy.
[22:16] <kirkland> mathiaz: okay, i like your bzr rm debian method
[22:16] <kirkland> mathiaz: seems to work well enough
[22:17] <mathiaz> kirkland: well...
[22:17] <mathiaz> kirkland: I'm looking at another way
[22:17] <mathiaz> kirkland: I don't know how things will work for the *next* merge
[22:18] <mathiaz> kirkland: another option is to merge upstream-1.6
[22:18] <majuk> I am dumb, relogging in ftw
[22:18] <mathiaz> kirkland: that will create a conflict with the ubuntu debian/ directory being moved to debian.moved (with upstream in debian/).
[22:18] <mathiaz> kirkland: then you'd commit the change as is (resolving the other conflict.)
[22:19] <mathiaz> kirkland: and then move back all the files from debian.moved/  to debian/
[22:19] <mathiaz> kirkland: but that doesn't really solve the problem...
[22:19] <mathiaz> kirkland: it would probably be a bigged mess for the next merge
[22:19] <mathiaz> kirkland: bigger mess
[22:20] <kirkland> mathiaz: yeah
[22:20] <mathiaz> kirkland: at least here we know what files are from upstream (debian/), and which ones are from ubuntu (debian.moved/)
[22:21] <mathiaz> kirkland: I think the intermediate branch is the best option
[22:21] <mathiaz> kirkland: we can construct the tarball from the intermediate branch (upstream-1.6-nodebian)
[22:28] <dragon> I'm unable to SSH into my Ubuntu server anymore, and I suspect it's because of a recent update.
[22:29] <dragon> Automatic updates are enabled and nothing else has changed for the server.
[22:29] <dragon> It's running well, still serving expected content on port 80.
[22:29] <dragon> the only thing that is broken is OpenSSH server.
[22:29] <dragon> currently there's no other way of accessing the server.
[22:30] <cj> dragon: do you connect to the port, or is the port not open?
[22:31] <mattgyver> Hi, im installing 9.10 server on my home server.  When i get to 'Installing Grub' it just knocks me out and back to the ubuntu installer main menu, any ideas?
[22:31] <dragon> cj, port is open and I get as far as authentication
[22:31] <dragon> cj, both password and public key methods fail.
[22:31] <dragon> cj, actually they don't fail, they go through and then it hangs.
[22:31] <dragon> it reminds me of an old bug that went away in Fedora 3.
[22:35] <dragon> *, http://pastebin.com/d1535ebbd
[22:38] <cj> dragon: try logging in as root?
[22:38] <cj> dragon: maybe your home directory mount point is busted?
[22:39] <dragon> cj: as far as I remember, I set root login ot without-password, so that's not expected to work
[22:39] <ScottK> cj: root isn't enabled by default on Ubuntu.
[22:39] <dragon> cj: my home directory was a part of /, but I can think of a different unrelated nfs mount point that is broken.
[22:39] <cj> try rsync?
[22:39] <cj> -e ssh, of course
[22:40] <dragon> rsync goes through ssh by default...
[22:40] <cj> oh?  maybe I'll start dropping -e ssh in that case.
[22:40] <mathiaz> kirkland: hm - I may have another solution to merge the upstream branch directly in the ubuntu branch
[22:40] <mathiaz> kirkland: discussing it currently in #bzr
[22:40] <kirkland> mathiaz: okay
[22:41] <mathiaz> kirkland: so basically you just merge the upstream branch into the ubuntu branch : bzr merge ../upstream
[22:41] <cj> dragon: rsync might skip whatever point is failing in your login workflow
[22:41] <mathiaz> kirkland: that will create a conflict with the debian directory with the ubuntu debian/ directory being moved to debian.moved/
[22:42] <mathiaz> kirkland: to resolve that conflict: bzr remove --force debian/ ; bzr move debian.moved/ debian/
[22:42] <kirkland> mathiaz: hmm, okay
[22:42] <kirkland> mathiaz: i can give that a shot
[22:42] <mathiaz> kirkland: a bzr st should show no changes being made to the debian directory
[22:42] <mathiaz> kirkland: now the question is what is going to happen on subsequent merges (when there is a change made by upstream in the debian/ directory)
[22:43] <kirkland> mathiaz: i'm perfectly comfortable doing your original suggestion
[22:43] <kirkland> mathiaz: in fact, i've already scripted it
[22:43] <kirkland> mathiaz: it's working well
[22:43] <kirkland> mathiaz: and i've moved on to fighting with debian/patches conflicts
[22:44] <mathiaz> kirkland: ok - that works as well.
[22:44] <kirkland> mathiaz: http://paste.ubuntu.com/331994/
[22:44] <kirkland> mathiaz: wait, that's old
[22:45] <kirkland> mathiaz: no, that's right
[22:45] <mathiaz> kirkland: REVNO=$(bzr log | head -n2 | tail -n1 | awk '{print $2}') - try to use bzr revno instead
[22:45] <dragon> cj: same problem with rsync, so it's not skipping that point
[22:45] <kirkland> mathiaz: see lines 4..14
[22:46] <dragon> cj: i tried `ssh hostname.local ls` earlier, and encountered the same problem.
[22:46] <kirkland> mathiaz: ok
[22:46] <mathiaz> kirkland: REVNO=$(bzr revno)
[22:46] <kirkland> mathiaz: got it
[22:47] <dragon> cj: narrowing it down, I think it's an NFS share mounted on /data/common, which was pointing to another server that no longer exists.
[22:49] <mathiaz> kirkland: LAST_REVNO=$(head -n 1 debian/changelog | sed "s/^.*bzr//" | sed "s/-.*$//")
[22:49] <mathiaz> kirkland: so I've found a gem to do that directly using bzr
[22:50] <kirkland> mathiaz: using tags?
[22:50] <mathiaz> kirkland: LAST_REVNO=$(bzr log -r ancestor:ubuntu/ 1.6
[22:50] <mathiaz> kirkland: LAST_REVNO=$(bzr log -r ancestor:ubuntu/ 1.6)
[22:51] <mathiaz> kirkland: using the log command with the ancestor
[22:51]  * mathiaz is proud of this one
[22:51] <mathiaz> kirkland: I'm using it to figure the base revision of a debian and ubuntu package for my get-merge script
[22:52] <kirkland> mathiaz: hmm, that's not working for me
[22:52] <mathiaz> kirkland:  bzr log -r ancestor:lucid/ upstream-1.6/ | grep revno | cut -d\ -f2
[22:52] <mathiaz> kirkland: ^^ that gives the last revno in the upstream branch
[22:53] <mathiaz> kirkland: my local directories are named differently than ubuntu and 1.6
[22:55] <ivoks> we should really go mariadb instead of mysql
[22:56]  * kirkland grumbles about axis2c
[23:29] <kirkland> soren: i have some questions about 04-axis2c-1.6.0-rampart-1.3.0.patch
[23:29] <kirkland> soren:  in eucalyptus/debian/patches
[23:30] <kirkland> soren: it's the only remaining conflict i have in my merge
[23:30] <kirkland> soren: the configure changes are rejected, particularly the large blob
[23:30] <kirkland> soren: i'm wondering if you could take a look at that
[23:30] <kirkland> soren: tell me if it's still necessary


[07:06] <ochosi> hm, have any of you guys used thunar's file templates ever?
[07:07] <ochosi> i personally haven't, but i feel it sucks a bit that we have a menu that's always empty there...
[07:07] <ochosi> File > Create Document > No templates installed (is what i'm referring to)
[07:10] <forestpiskie> ochosi: nope - not me
[07:11] <ochosi> morning pixie/elfy
[07:12] <elfy> morning ochosi
[09:36] <bluesabre_> morning ochosi/elfy
[09:45] <ochosi> hey bluesabre_
[09:45] <knome> g'day
[09:45] <bluesabre> hey knome
[09:45] <bluesabre> whats up guys?
[09:46] <knome> manually upgrading a wordpress 3.5 site to 3.9.2. fun!
[09:47] <bluesabre> woo!
[09:48] <knome> well, it's easier now
[09:48] <knome> ...that i've just manually upgraded a wordpress 3.6 site to 3.9.2
[09:48] <knome> one more to go after this ;)
[10:21] <ochosi> bluesabre: tested light-locker's dbus interface today for the first time
[10:22] <ochosi> it's a bit more than half-ready i guess
[10:23] <bluesabre> yeah, saw that
[10:23] <bluesabre> slow and steady, eh
[10:23] <bluesabre> :)
[10:30] <elfy> hi bluesabre
[10:33] <bluesabre> hey elfy
[10:33] <bluesabre> how are things?
[10:33] <knome> hey elfy
[10:34] <elfy> hi knome
[10:34] <elfy> bluesabre: ok thanks :) week off and the sun is mostly out
[10:34] <knome> woot :)
[10:34] <knome> hope the sun isn't too hot ;)
[10:40] <elfy> nope - this IS england :p
[10:43] <knome> hah, well this is finland and it's too hot in here...
[10:47] <ochosi> bluesabre: lordy, ppl still keep commenting on the black screen bugreport...
[10:48] <bluesabre> ochosi: yes, I have no love for light-locker these days
[10:51] <ochosi> bluesabre: not sure what to do about that though
[10:52] <bluesabre> at this point, I think it's probably more of an issue with Xorg
[10:52] <ochosi> well, it's multiple problems, but i guess the main issue is VT switching + suspend
[10:52] <ochosi> or, even more compressed: VT switching
[10:52] <bluesabre> yeah
[10:52] <elfy> trouble is we don't know what these people posting have done in the meantime - only what they say they've done
[10:53] <bluesabre> yup
[10:53] <ochosi> yeah, and in fact ppl are misattributing all kinds of issues to this bug
[10:53] <elfy> I'd bet my last penny - that they are different bugs
[10:53] <ochosi> it has become a sort of catch-all
[10:53] <bluesabre> yup
[10:54] <bluesabre> several times we've had reports from ubuntu users
[10:54] <bluesabre> where their compositor froze and left them with a black screen
[10:54] <elfy> so how about
[10:54] <bluesabre> which had nothing to do with light-locker, which they didn't have installed
[10:54] <ochosi> yeah, or those folks that just have general suspend bugs because of the graphics stack or xorg or whatever...
[10:55] <elfy> unsubscribe us from it - make a note that the original bug is fixed and if people have other issues they should create new bug reports as we're no longer monitoring this one
[10:55] <ochosi> yeah, that sounds sensible
[10:56] <elfy> and specifically if *we* get notification once xubuntu-bugs is unsubscribed deal with that locally
[10:56] <elfy> shall I do that now ochosi ?
[10:56] <ochosi> yup, that'd be great
[10:56] <ochosi> thanks elfy
[10:58] <ochosi> still, in the long run we have to deal with this somehow
[10:58] <ochosi> if vt switching is causing so much headache
[10:59] <brainwash> light-locker 2.0 :)
[10:59] <ochosi> yeah, but we need at least some sort of idea when that's going to happen
[11:00] <ochosi> thing is, that's something *i* definitely can't implement
[11:00] <ochosi> i guess cavalier wants to clean up the dbus branch first and release that as ll 1.6
[11:00] <elfy> ochosi: This bug has become a catch-all for issues that appear to be similar. The original issue is now fixed, the Xubuntu Team is no longer monitoring this bug.
[11:00] <elfy> too blunt?
[11:00] <ochosi> :>
[11:00] <elfy> or just elfy enough
[11:00] <brainwash> going back to xscreensaver is not an option =S
[11:01] <ochosi> it's quite blunt, but as i've mentioned this a few times in the report already, go for it
[11:01] <ochosi> brainwash: why not?
[11:01] <elfy> ok - xubuntu-bugs is unsubscribed and I've posted that :)
[11:01] <ochosi> thanks
[11:01] <elfy> we might get them via xfpm though - not sure
[11:02] <brainwash> because we just switched to light-locker which is the better (looking) solution
[11:02] <ochosi> well i'm not the last person to admit an honest mistake, if we start to feel that way
[11:03] <ochosi> what will suck though with xscreensaver is the fun settings duplication with xfpm :)
[11:03] <knome> i think we should just work wiht light-locker and keep improving it
[11:03] <ochosi> in a way, i'd personally prefer if we tried to improve the situation though
[11:03] <elfy> yay - they fixed the images \o/
[11:03] <knome> even if it took until 16.04
[11:04] <brainwash> right, 14.10 is just a play ground anyway, so no need to switch back
[11:05] <ochosi> well, "just a playground" might be a bit exaggerated, but yeah, i tend to see it that way
[11:06] <ochosi> as the recent vote on xchat has shown, the team doesn't agree on this though
[11:10] <bluesabre> the ones not in favor seem like they'd be in favor of having hexchat though for the sake of quick irc
[11:10]  * bluesabre advocates nothing
[11:12] <brainwash> knome: is this bug still present? bug 1307929
[11:12] <knome> to me, it looks like some people interpreted the question as "should we drop xchat forever" instead of "should we do an experiment with no xchat on one release"
[11:12] <knome> brainwash, i'll check that later today, or sth
[11:13] <bluesabre> yup
[11:13] <brainwash> knome: thanks
[11:14] <bluesabre> time for work, bbl
[11:14] <ochosi> hf bluesabre, ttyl
[11:15] <ochosi> elfy: if now a shitstorm arises, i hope we won't be subscribed anymore ;)
[11:15] <elfy> I disagreed on removing something and leaving nothing in it's place - pidgin is not a replacement
[11:15] <elfy> ochosi: LOL
[11:16] <elfy> that argument is like taking a car from someone and giving them a motorbike as a replacement almost ;)
[11:16] <ochosi> do you really wanna start this discussion now? (cause i'm about to head out for lunch...)
[11:17] <elfy> nah not at all - that's all done now :)
[11:21] <ochosi> alright :)
[11:21] <ochosi> in that case i can quietly head out ;)
[11:22] <elfy> yep - have some lunch for me :)
[11:23]  * ochosi is on a diet
[11:23] <ochosi> but i'll make an exception for you, elfy
[11:24] <ochosi> bbl
[11:24] <knome> bon appetit
[11:29] <elfy> ochosi: when you're back - I like the tab swicher :)
[15:23] <Unit193> Good luck with the CC check-in.
[16:10] <knome> oh.
[16:11] <skellat> Crap
[16:11] <skellat> What time was that supposed to be?
[16:11] <knome> in 50 mins.
[16:12] <knome> skellat, did you catch this link from IRC or the ML: http://xubuntu.org/team-calendar/ ? :)
[16:12] <skellat> No, actually I didn't
[16:13] <knome> well, there you go :)
[16:13] <knome> it incorporates the team calendar and the trello calendat
[16:13] <knome> *calendar
[16:24] <elfy> is there anything that we need from the CC?
[16:24] <elfy> that anyone else knows ...
[16:24] <knome> don't think that we "need" anything
[16:25] <elfy> I didn't think so
[16:26] <Unit193> Mental help for the entire team...
[16:26] <elfy> can't ask for that ...
[16:26] <knome> doubt the CC can help with that..
[16:26] <elfy> 2 of the team would have to self-administer ...
[17:08] <knome> ochosi, pi-ping!
[17:09] <elfy> even anyone other than us two from team would be good ;)
[17:11]  * Unit193 pokes in for two seconds then out. ->
[17:34] <elfy> thanks knome :)
[17:34] <knome> np, and ty elfy
[17:34] <elfy> :)
[17:40] <knome> bbl