[00:27] <haasn> Hmm, it seems MAAS uses `ipmipower` to interact with IPMI 2.0 clients, but `ipmipower` does not seem to work on my server (always answers “invalid password”)
[00:27] <haasn> ipmitool on the other hand works fine
[00:28] <haasn> I wonder if it would be possible to get this changed
[00:42] <haasn> Seems like ipmitool works and FreeIPMI does not
[01:23] <haasn> Hmm, it seems like there used to be an ipmi.template in use but it was changed to a “native” ipmi controller written in python in some version that I can't quite discern
[01:24] <haasn> The bazaar web interface is virtually unusable for trying to figure out when this change happened, anybody got a clue? I'm trying to pull the “last” version of ipmi.template out of the history so I can rewrite it using ipmitool instead of freeipmi
[01:26] <haasn> Ah, I can do a bzr checkout then convert that to git format using bzr fast-export | git fast-import in order to get it in a usable format :)
[01:30] <haasn> incidentally, I tried setting up a RAID6 with 4 disks using the new storage config stuff in 1.9 and it flat-out doesn't work at all: https://0x0.st/XWQ.txt
[02:28] <haasn> I tried it again and it (inexplicably) got farther, this time erroring out in GRUB
[02:28] <haasn> but that seems to be a grub issue
[03:12] <haasn> https://0x0.st/XWg.txt head /dev/zero > /dev/disk ?
[03:12] <haasn> Isn't that horrendeously slow compared to dd if=/dev/zero of=/dev/disk bs=1M ?
[05:46] <mup> Bug #1542982 opened: maas http_proxy does not accept username and password for proxy <MAAS:New> <https://launchpad.net/bugs/1542982>
[05:49] <mup> Bug #1542982 changed: maas http_proxy does not accept username and password for proxy <MAAS:New> <https://launchpad.net/bugs/1542982>
[05:52] <mup> Bug #1542982 opened: maas http_proxy does not accept username and password for proxy <MAAS:New> <https://launchpad.net/bugs/1542982>
[05:55] <mup> Bug #1542982 changed: maas http_proxy does not accept username and password for proxy <MAAS:New> <https://launchpad.net/bugs/1542982>
[05:58] <mup> Bug #1542982 opened: maas http_proxy does not accept username and password for proxy <MAAS:New> <https://launchpad.net/bugs/1542982>
[06:48] <haasn> Hmm. I'm at the point where I've run into so many issues since switching from 1.8 to 1.9 that I just want to downgrade to see if the universe still makes sense at all, what ppa can I add to give me the 1.8 versions? The maas/stable one only contains 1.7 and 1.9 (and a few others)
[07:10] <haasn> (turns out upgrading other stuff solved at least some of the most important issues)
[11:17] <BlackDex> Hello there. I'm using maas 1.9, and i need to have two different vlan's on a single bond. is this possible?
[11:26] <BlackDex> Ah, i think i have found it. Adding the vlan via the maas cli, and after that i'm able to use that in the GUI ;)
[14:50] <mup> Bug #1541640 changed: MaaS region controller 1.9 fails on Ubuntu 15.10 <MAAS:Invalid> <https://launchpad.net/bugs/1541640>
[14:50] <mup> Bug #1542761 changed: MAAS will not import images and there is no error as to why <MAAS:Invalid> <https://launchpad.net/bugs/1542761>
[15:23] <jamespage> blake_r, hey - time for a bit of maas 1.9 network tuning?
[15:23] <jamespage> I need to figure out how to set MTU on MAAS configured interfaces
[15:33] <blake_r> jamespage: only one interface or the whole vlan?
[15:34] <jamespage> blake_r, well mtu applies at the physical link level - I'm not actually using vlan's here
[15:34] <blake_r> jamespage: yes but if you set it on the vlan that all the interfaces are connected to, then when you deploy those nodes, any that have a connection to that vlan will have the mtu set to that value
[15:35] <blake_r> jamespage: that way you don't have to go to every node and set the mtu in MAAS
[15:35] <jamespage> blake_r, ah right ok
[15:35] <blake_r> jamespage: so if that is what you want
[15:35] <blake_r> jamespage: just do this "maas my-maas-session vlan update 1 mtu=1500"
[15:35] <jamespage> blake_r, I absolitely want everything connected to have the same mtu
[15:35] <blake_r> jamespage: 1 being the vlan id
[15:36] <blake_r> jamespage: not the vid
[15:36] <blake_r> jamespage: use "maas my-maas-session vlans read" to get the list of vlans"
[15:37] <jamespage> blake_r, hmm - not liking that command
[15:37] <blake_r> jamespage: the update?
[15:38] <jamespage> vlans read
[15:38] <jamespage> blake_r, using 1.9.0 from the stable PPA
[15:38] <blake_r> jamespage: do "maas refresh" first
[15:38] <blake_r> jamespage: that way the maas client has the updated API interface
[15:39] <jamespage> blake_r, gotcha
[15:39] <jamespage> can I apply mtu to the untagged vlan?
[15:40] <blake_r> jamespage: yes its jsut like another vlan in MAAS
[15:40] <blake_r> jamespage: you will see it in the vlans listing
[15:40] <jamespage> blake_r, {"__all__": ["Cannot modify the default VLAN for a fabric."]}
[15:40] <jamespage> eek
[15:42] <blake_r> jamespage: ah crap
[15:42] <blake_r> jamespage: that should be allowed for the mtu value, crap
[15:42] <blake_r> jamespage: file a bug please, will get that fixed in 1.9.1
[15:42] <blake_r> jamespage: no you have 2 options
[15:42] <blake_r> jamespage: now*
[15:42] <jamespage> blake_r, will do
[15:42] <blake_r> jamespage: either set it on each interface
[15:43] <blake_r> jamespage: or I can show you how to do it manually using the maas shell
[15:43] <jamespage> either is good with me - its only 9 interfaces in total
[15:43] <blake_r> jamespage: then lets just do it over the API
[15:44] <blake_r> jamespage: "maas my-maas-session interface update {node-system-id} {interface-id} mtu=1500"
[15:52] <jamespage> blake_r, ok - trying that out now
[15:52] <jamespage> maas applied to all interfaces on all nodes...
[15:58] <blake_r> jamespage: ??
[16:03] <jamespage> blake_r, testung now
[16:03] <jamespage> blake_r, http://paste.ubuntu.com/14993910/
[16:05] <blake_r> jamespage: looks good
[16:13] <jamespage> blake_r, 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq master juju-br0 state UP group default qlen 1000
[16:13] <jamespage> looking good!
[16:16] <blake_r> jamespage: cool
[16:16] <blake_r> jamespage: please file that bug
[16:17] <jamespage> blake_r, promise I will!
[16:17] <blake_r> jamespage: thanks
[16:25] <jamespage> blake_r, https://bugs.launchpad.net/maas/+bug/1543195
[16:38] <mup> Bug #1543195 opened: unable to set mtu on default VLAN <api> <networking> <MAAS:Triaged> <MAAS 1.9:Triaged> <https://launchpad.net/bugs/1543195>
[17:15] <jamespage> blake_r, hey - so I think xfs support for disks formats is on the roadmap right?
[17:15] <jamespage> apologies for the questions - so close to 0 post deploy hacks...
[17:18] <roaksoax> jamespage: xfs will be added yes
[17:18] <jamespage> roaksoax, awesome - thanks for confirming
[17:19] <roaksoax> jamespage: in fact, i think we can even get it to 1.9
[17:19] <jamespage> \o/
[17:42] <mup> Bug #1531843 changed: [Xenial 1.10] IPMI query fails <1.10> <ipmi> <python3> <xenial> <MAAS:Incomplete> <https://launchpad.net/bugs/1531843>
[20:16] <haasn> the power status for one of my machines is stuck on “power error”, with the last machine event being: Failed to query node's BMC - Power state could not be queried: [Errno 8] Exec format error
[20:16] <haasn> I have fixed the problem in question and verified it works by manually opening a python instance and running os.execl on the file in question
[20:16] <haasn> (/usr/sbin/ipmipower)
[20:17] <haasn> But for some reason maas doesn't seem to get this. There are no machine events since then, despite me hammering the “check now” button. I don't see any ipmipower processes being spawned either. I tried rebooting the machine, restarting apache2 etc. but maas just doesn't seem to want to retry
[20:19] <roaksoax> haasn: what maas version are you using? What hardware are you using? Are you sure the power credentials in MAAS are the correct ones?
[20:19] <roaksoax> haasn: is there anything more on the logs (pastebin)
[20:20] <haasn> roaksoax: maas v1.9, hardware of the machine in question is a sun fire x4200, I am sure the power credentials in MAAS are the correct ones because I can copy/paste them from the webUI to my own ipmipower invocation and turn the machine on and off
[20:20] <haasn> e.g.
[20:20] <haasn> su - maas
[20:20] <haasn> /usr/sbin/ipmipower -D LAN_2_0 -h X.Y.Z.Z -u maas -p <snip> --stat  # this works fine
[20:20] <roaksoax> haasn: is anything shown on the logs ?
[20:21] <haasn> Hmm, seems there's a new entry as of 20:18: “password invalid”
[20:21] <haasn> why it took half an hour for it to switch from “exec format error” to “password invalid” I do not know
[20:22] <haasn> This seems like it might be executing the wrong version of ipmipower. I replaced ipmipower by my own version which contains a patch for the “password invalid” bug on X4200 servers and moved it to /usr/sbin/ipmipower and the first one to /usr/sbin/ipmipower-orig
[20:22] <haasn> Is it possible it's executing /usr/sbin/ipmipower-orig somehow?
[20:22] <roaksoax> haasn: not at all
[20:23] <haasn> I can't find the exact location of the command it's executing in src/provisioningserver/drivers/power/ipmi.py anywhere
[20:24] <haasn> Okay, some update: It *is* spawning new ipmipower processes, they just exit so ridiculously fast that I couldn't see them in `watch`. With -n0.1 I see them popping up for a split second
[20:24] <haasn> Maybe it's time to install auditd and log all process spawns so I can figure out what it's executing? Unless there's a simpler way
[20:25] <haasn> Why it can't include the command it executed in the log files is beyond my understanding
[20:25] <haasn> Well, then again, so is “why can't it log every failure to the log files instead of only every 30 minutes?”
[20:29] <roaksoax> uhmm
[20:29] <roaksoax> haasn: you could try hacking ipmi.py to log out what IPMI command is being send
[20:29] <roaksoax> in MAAS' logs
[20:33] <koaps> heya
[20:34] <koaps> does anyone know what happened to MAAS 1.8.3? I don't see it available in stable anymore
[20:35] <roaksoax> koaps: it has been superseeded by 1.9
[20:35] <koaps> ya, but shouldn't it still be avail to get if I use the version name? I see 1.7.6 and 1.7.3 there
[20:36] <haasn> Heh, auditd didn't want to work but I found a beautifully simple way to accomplish what I wanted: while true; do pgrep -a ipmipower; sleep 0.1; done
[20:36] <haasn> this gave me a nice log of (virtually) all executed ipmipower commands
[20:37] <haasn> Okay, I found the error and solved it
[20:38] <haasn> The problem was that it was adding -W opensesspriv, and the -W flag overrides previous flags - so my “patched” version of ipmipower (which was really just ipmipower-orig -W sun20 "$@") didn't really do anything. I changed it to ipmipower-orig "$@" -W sun20 and that way my sun20 workaround flag overrides the previous opensesspriv work-around flag
[20:38] <haasn> Now it works
[20:38] <haasn> And I can control the power status of all my servers just fine
[20:39] <haasn> maas desperately needs some mechanism for adding your own IPMI workaround flags to nodes
[20:47] <roaksoax> koaps: i wonder if the PPA removed it, since we have not made the removal of the version from the PPA itself
[20:47] <roaksoax> haasn: you can always file a bug :)
[20:48] <haasn> roaksoax: there is already a bug on the issue, I commented on it
[20:48] <haasn> But I don't really want to be spending the next few months manually running ipmipower commands until it gets fixed
[20:51] <roaksoax> haasn: well, that may seem like an issue with the firmware rather than MAAS itself
[20:51] <roaksoax> haasn: since the firmware requires non-standard paramters
[20:53] <haasn> roaksoax: Yes okay but that doesn't really help admins who want to provision servers with MAAS. FreeIPMI contains these work-arounds for a reason, not exposing the ability to use them to the admins in charge of running the machines when it would literally be nothing more than one input box and one line of code for appending it to the command line is just being annoying for the sake of annoying, IMO
[20:59] <roaksoax> haasn: right, but in situations like this, providing ability to do work around is not always something that will improve MAAS' robustness
[20:59] <roaksoax> haasn: as this is an isolated issue
[21:03] <mup> Bug #1543286 opened: Exception: 'Node' object is not iterable <MAAS:New> <MAAS 1.10:New> <https://launchpad.net/bugs/1543286>
[22:03] <mup> Bug #1543301 opened: MAAS should only allow creating 15 partition <storage> <MAAS:Triaged> <https://launchpad.net/bugs/1543301>
[22:06] <mup> Bug #1543301 changed: MAAS should only allow creating 15 partition <storage> <MAAS:Triaged> <https://launchpad.net/bugs/1543301>
[22:09] <mup> Bug #1543301 opened: MAAS should only allow creating 15 partition <storage> <MAAS:Triaged> <https://launchpad.net/bugs/1543301>
[22:53] <haasn> This is weird. Often, when I try deploying to a VM, I end up in the weird situation where the deploy process seems to be complete but the machine then just gets stuck in an offline state after it was supposed to reboot
[22:53] <haasn> if I ssh into the machine, I see The system is going down for reboot NOW!
[22:53] <haasn> But.. it never reboots. It just powers off
[22:53] <haasn> And MAAS also still thinks it's turned on until I manually hit “check now”
[22:54] <haasn> Power control is via virsh
[22:54] <haasn> What could possibly be going wrong here? Evidently the machine thinks its rebooting, it just.. doesn't
[22:59] <haasn> Hmm, seems to be an inherent part of KVM; “sudo reboot” has the same issue for some reason
[23:03] <fluxcore> I use plenty of KVM stuff outside of maas/openstack and don't have any such problems...
[23:05] <haasn> I've used dozens of KVM VMs on this same vm host, and it's running like 5 other VMs right now that all work fine
[23:05] <haasn> as in I can reboot them
[23:06] <haasn> but the ones used by maas have this inexplicable failure
[23:08] <roaksoax> haasn: Is this during deployment ?
[23:08] <roaksoax> haasn: also, maas doesn't query the VM's/BMC's every second. WE do it ever few minutes to ensure BMC's dont go crazy
[23:10] <roaksoax> haasn: i deploy about ~100 to ~200 vm's every few weeks for testing, and have not seen such behavior. However, I've seen a few occurrences where they all fail to PXE at once because there are too many VM's on the same host
[23:10] <roaksoax> haasn: but that's how the host's bridge was configured
[23:13] <haasn> roaksoax: Yes, this is during deployment
[23:14] <haasn> I just reproduced it again: clicked the machine, hit “deploy” in the web UI, chose ubuntu 14.04 lts and default kernel
[23:14] <haasn> it started deploying up until the point where rebooted the machine
[23:14] <haasn> and now it's just offline
[23:14] <haasn> I'll try removing the machine and re-adding/commissioning it in kvm. Maybe something got messed up because I used an xml dump to batch-create a bunch of VMs
[23:35] <haasn> destroyed the VM and recreated it and it seems to be working now
[23:35] <haasn> must be some weird failure to do with the way it was created, idk


[04:19] <pitti> Good morning
[06:40] <ricotz> infinity, doko, hi, I saw there were some new gcc-5 builds, what about fixing the non-stripped binaries like /usr/lib/gcc/x86_64-linux-gnu/5/lto1
[07:27] <infinity> ricotz: Apparently, that's a feature, not a bug.
[07:27] <infinity> ricotz: But doko intends to strip them before release.
[07:44] <ricotz> infinity, I see, thanks for clarifying
[08:05] <smb> rbasak, In order to move forward with DPDK I updated bug 1487538 with links to source and my PPA. I think the next step is to subscribe sponsors, right?
[08:07] <seb128> what should packages handle deluser calls in postrm/purge that fail because the user is logged in
[08:07] <seb128> like lightdm when users try to remove the package from a system when the login manager is in use
[08:07] <pitti> seb128: TBH I think nothing should ever call deluser automatically
[08:07] <pitti> if a postrm is trying to, then at least with || true
[08:07] <seb128> pitti, so purging lightdm should just let a lightdm user around?
[08:08] <pitti> but the possibility of reusing a previously removed uid for a new account is a security issue
[08:08] <pitti> seb128: yeah, I think that's the lesser evil
[08:09] <seb128> pitti, so you would just drop the deluser call?
[08:09] <seb128> rather than adding || true?
[08:09] <pitti> lightdm is prone to leaking processes and leftover sessions unfortunately
[08:10] <pitti> seb128: no strong opinion between || true and drop, but I'd prefer dropping it, yes
[08:10] <seb128> pitti, thanks
[08:10] <seb128> robert_ancell, ^
[08:10] <pitti> seb128: so the problem is:
[08:10] <pitti> 1. you uninstall package foo with sysuser foo, removing the sysuser foo with uid 123
[08:11] <pitti> 2. you install a package bar, adding sysuser bar with uid 123 (reusing)
[08:11] <pitti> 3. now bar's daemons "take over" any running processes of foo, and can meddle with its leftover files, etc.
[08:11] <robert_ancell> pitti, fair point
[08:11] <seb128> right
[08:12] <pitti> in some cases (when foo doesn't write any files, or makes sure to kill its processes), deluser is a nice cleanup, but this should be ascertained before
[08:12] <pitti> and lightdm in particular writes lots of files and leaks lots of sessions and processes
[08:13] <pitti> at least while it's running I always have a lightdm session around; not sure whether that's still true after stopping lightdm
[08:29] <rbasak> pitti: I think I'd put that a different way. A postrm to clean up a user is fine, but only if it first cleans up anything that is still using that uid first.
[08:29] <pitti> rbasak: yes, that sounds more positive indeed :)
[08:49] <infinity> pitti: FWIW, I was right.  Just noticed the old open tab.  The rerun of the bluetooth indicator boottest worked.
[08:49] <infinity> pitti: So, it's just when it's tied to a bluez transition that it breaks, because upgrading bluez breaks.
[08:49] <infinity> (Yay phone)
[08:49] <pitti> ah, I see
[09:29] <ypwong> Laney, re indicator-bluetooth, do they just need to rebuild image?
[09:30] <ypwong> ... for ubuntu kylin
[09:31] <Laney> ypwong: if they want the new one yeah
[09:32] <ypwong> Laney, i'm sure they do, thanks
[10:20] <Riddell> cyphermox: are you able to take a look at bug 1488838? fails upgrade
[11:21] <rbasak> freeradius in Trusty FTBFS with sbuild -j4 (the same as dpkg-buildpackage -j4 AIUI) but succeeds with DEB_BUILD_OPTIONS=parallel sbuild with no -j flag. Looks like debian/rules just calls $(MAKE) (no debhelper). Presumably it won't fail in Launchpad because that sets DEB_BUILD_OPTIONS and not -j/MAKEFLAGS directly? Should I consider this a buggy package? Or is using sbuild -j wrong?
[11:23] <rbasak> uh, DEB_BUILD_OPTIONS=parallel=4
[11:23] <rbasak> s/no debhelper/ no dh/
[11:24] <infinity> rbasak: sbuild -j and dpkg-buildpackage -j are broken by design.
[11:24] <rbasak> infinity: ah, OK. Thanks. I had always assumed that -j to sbuild just set DEB_BUILD_OPTIONS and used it as a shortcut. Only looked up the definition just now that I got differing behaviour.
[11:25] <infinity> rbasak: Yeah, dpkg-buidlpackage -j sets MAKEFLAGS, it's pure evil.
[11:25] <infinity> rbasak: In wily's dpkg, it now has a safe -J that does what -j should have done.  Making sbuild call that is probably the right answer.
[11:26] <rbasak> That sounds useful. I look forward to getting my shortcut back :)
[11:26] <infinity> rbasak: Anyhow, totally not a bug IMO that a package that in no way avertises parallel build capability fails to build when you try to force the issue.
[11:26] <infinity> rbasak: Who needs a shortcut?  It's shortest to not type -j at all!
[11:26] <infinity> rbasak: I just have this in my .bashrc:
[11:27] <infinity> export DEB_BUILD_OPTIONS="parallel=$(nproc)"
[11:27] <infinity> Which means no thought required on my part.
[11:27] <rbasak> infinity: understood it's not a buggy package - I figured it was either buggy packaging or buggy tooling and was not sure.
[11:27] <rbasak> infinity: I often build on VMs, so need to adjust my VM-setting-up-script to set a sensible parallel= field, that's all.
[11:43] <cyphermox> Riddell: looks like it's much more than modemmanager: all of dbus looks messed up
[11:43] <Riddell> !
[11:43] <cyphermox> Riddell: what were you upgrading from?
[11:44] <cyphermox> direct 15.04 to 15.10?
[11:44] <Riddell> cyphermox: yes, with do-release-upgrade
[11:51] <Riddell> bdmurray, mvo: I fixed bug 1488843 in ubuntu-release-upgrader, how do I upload, is the packaging somewhere in bzr or do I just get it from the archive?
[12:04] <mvo> Riddell: its in lp:ubuntu-release-upgrader
[12:39] <colonolGron> hi
[12:39] <colonolGron> is there any requirement when one woulds like a package to be added to ubuntu?
[12:47] <pitti> colonolGron: it must be free software (or at least freely redistributable, for multiverse), and there needs to be someone looking after it
[12:48] <pitti> i. e. it's not a "throw it over the fence" thing, but an ongoing commitment
[12:49] <colonolGron> well i would like to have a program in ubuntu, but i am not a developer
[12:49] <colonolGron> pitti, this one: https://github.com/jubalh/nudoku/
[12:49] <colonolGron> there seems to be openSUSE and Gentoo package but not Ubuntu :(
[12:51] <pitti> license wise that seems fine
[12:59] <colonolGron> pitti, so i need to find someone who is willing to maintain the deb package and then thats it?
[12:59] <pitti> colonolGron: pretty much, yes
[13:00] <colonolGron> maybe someone in here steps up, i dont know any developers :)
[13:40] <mterry> bdmurray, ~ubuntu-server will look after python-pymsql in main, FYI
[14:05] <flexiondotorg> didrocks, I'd like to make a small UI change to the Ubiquity Slideshow for Ubuntu MATE. Is lp:ubiquity-slideshow the correct branch to submitted merge proposals against?
[14:07] <didrocks> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/ubiquity-slideshow/".
[14:07] <didrocks> I would say no :p
[14:08] <didrocks> flexiondotorg: seems the branch is at lp:~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html
[14:08] <didrocks> (from Vcs-Bzr)
[14:09] <didrocks> but package version 98 is not in, so please import it
[14:09] <flexiondotorg> didrocks, I branch this - bzr branch lp:ubiquity-slideshow-ubuntu
[14:09] <flexiondotorg> And yes. It is version 97 only. Which prompted my question.
[14:09] <flexiondotorg> import it?
[14:09] <didrocks> IIRC, you did propose a branch with it
[14:09] <didrocks> I guess people with commit right to the branch didn't push it
[14:10] <didrocks> let me check, I guess I didn't have commit rights
[14:10] <didrocks> yeah, core-dev don't
[14:11] <didrocks> cyphermox: mind pushing flexiondotorg's changes to this branch?
[14:11] <didrocks> (I guess core-dev should have access to the branches as well, as per Vcs-Bzr)
[14:11] <cyphermox> Ah, sure
[14:12] <didrocks> cyphermox: the branch corresponding to latest upload is lp:~didrocks/ubiquity-slideshow-ubuntu/mate-slideshow
[14:12] <didrocks> so, should be just a matter of pull && push
[14:12] <cyphermox> Yep
[14:12] <didrocks> thx ;)
[14:13] <didrocks> flexiondotorg: meanwhile, branch from my one ^
[14:13] <flexiondotorg> didrocks, Understood. Thanks.
[14:13] <didrocks> yw
[14:50] <vertago1> Hey I was testing 15.10 on one of my systems and ran into a potential issue with dm-raid and systemd's fsck at boot. Any tips on how to get at any log information which would help me out?
[14:53] <brendand> barry, do you know if the use of \ is mentioned in pep8?
[14:56] <barry> brendand: there is some mention of it.  essentially, if you can use parens/braces/brackets to continue lines, do that.  but there are a few cases where only backslashes will work (or where using parens are a bit contrived)
[14:56] <barry> so backslashes aren't prohibited
[15:11] <degorenko> hello here! Is here anyone around, who can help me? I want to fix this bug: https://bugs.launchpad.net/ubuntu/+source/sahara/+bug/1452698 I found this instruction: http://packaging.ubuntu.com/html/fixing-a-bug.html is it correct? jamespage coreycb can you help? :)
[15:13] <coreycb> degorenko, hello, I can work with you on it but zul will need to sponsor you (james is out)
[15:13] <coreycb> degorenko, definitely appreciate the helping hand :)
[15:14] <coreycb> degorenko, this is kilo?
[15:14] <degorenko> coreycb, yes :)
[15:15] <coreycb> degorenko, ok you can work from the kilo branch here:  https://code.launchpad.net/~ubuntu-server-dev
[15:15] <degorenko> and also this bug in official ubuntu repos (vivid, wily)
[15:15] <coreycb> degorenko, we'll land it in vivid, wily and then backport to the cloud archive
[15:17] <coreycb> degorenko, for liberty we've switched to git and this is the process we're following:  https://wiki.ubuntu.com/ServerTeam/OpenStackPackaging
[15:43] <hallyn_> arges: smb: hey, i don't think i'll be in a good place for the bug party today.  Would same time tomorrow work for you guys?
[15:43] <smb> hallyn_, would be ok with me
[15:45] <arges> hallyn_: yea works for me
[15:46] <hallyn_> cool, thx
[15:46] <rbasak> arges: please could you take another look at bug 1321425? I'm not happy about the whitespace noise in the diff but you already sponsored that to Wily so I don't want to make the submitter run round unnecessarily.
[15:47] <rbasak> (there also looks to be quilt refresh noise in unrelated patches eg. the trusty debdiff)
[15:49] <arges> rbasak: iirc the wily upload didn't have those issues
[15:49] <rbasak> arges: http://launchpadlibrarian.net/211349484/irqbalance_1.0.6-3ubuntu1_1.0.6-3ubuntu2.diff.gz - no quilt patch noise, but the whitespace noise in comments is there
[15:50] <arges> rbasak: ack, i see it now.
[15:52] <arges> rbasak: I would at least let jorge know what happened, perhaps its some editor setting he should be aware of in the future. Are you planning on sponsoring the other SRus?
[15:54] <rbasak> arges: I'd be happy to, but I'd like the noise gone before I do.
[15:55] <rbasak> arges: if you're OK with that, I'll ask in the bug.
[15:57] <arges> rbasak: yea lets do it right. i should have caught that
[15:57] <rbasak> OK, thanks.
[16:05] <hallyn_> mdeslaur: arges: I'm wondering whether the ubuntu qemu development tree ought to go back to lp now that it supports git (it's at debian right now, would be nice if you guys could have write access)
[16:07] <hallyn_> (just a thought;  not doing that today)
[16:12] <hallyn_> well shucks.  in w we moved the qemu initscript func into a common script, and moved the scripts from qemu-system-{x86,ppc} to qemu-system-common.  Now I keep bikeshedding over hwo to do it in v,
[16:13] <hallyn_> just putting the full functionality into the original scripts seems simplest;  i can't just add the common script in v without moving it to the new pkg or else v-to-w upgrades will balk
[16:13] <hallyn_> i can move them now into the qemu-system-common pkgs, but htat's not the simplest way, and this is sru...
[16:14] <hallyn_> it's "just" v so we won't be keeping the duplicated scripts around for long
[16:14] <hallyn_> guess i'll do that
[16:14]  * hallyn_ delets the source and starts over
[16:16] <hallyn_> urgh but that'll be easy to get a little bit wrong
[16:29] <hallyn_> dannf: test pkgs for the vivid qemu sru you worked on long ago are at ppa:serge-hallyn/kvm-pxe-backport fwiw (bug 1457639)
[16:29] <hallyn_> well, still building
[16:31] <hallyn_> hm, yeah, those init scripts aren't right
[16:34] <hallyn_> eh maybe they are
[16:56] <mdeslaur> hallyn_: oh, hrm, didn't know we had a tree at debian for that...yeah, lp would be nice
[16:56] <mdeslaur> hallyn_: you're going to make me learn git, aren't you?
[18:57] <hallyn_> mdeslaur: :)
[20:31] <sladen> .
[20:32] <Unit193> ᗣ ᗣ ᗣ   ᗧ * * * * * *
[20:35] <Pici> wakka wakka
[21:18] <dannf> hallyn: ack, i'll test
[21:30] <hallyn> dannf: i've run the qa-regression-tests, all passed,
[21:30] <hallyn> so i pushed to -proposed just a min ago
[21:31] <dannf> hallyn: perfect - i'll wait till it builds there to verify then
[21:32] <hallyn> cool
[21:51] <barry> doko: i think we need to merge dh-python from unstable.  is that something you want to look at or should i?


[00:24] <slangasek> kirkland: ah - if he cares, I guess he probably already pruned it when committing :)
[00:28] <mdz> booting the latest karmic only blew up a little for me (grub.cfg/MBR mismatch)
[00:55] <TheMuso> Is there an easy way to search for ITP bugs in bugs.debian.org?
[00:56] <ajmitch> the only way I know of is looking at bugs.debian.org/wnpp
[00:57] <TheMuso> ajmitch: thanks
[01:19] <TheMuso> dtchen: Lennart really pushes the boundary. We will not be able to offer pulse 0.9.16 for testing till we have kernel 2.6.31. :S
[01:21]  * TheMuso goes and fumes in the corner.
[02:18] <ScottK> That'll teach dtchen to promise we're dropping our diff from upstream.
[02:22] <TheMuso> ScottK: Well its not really a diff. Its having to wait till we move onto the newer kernel version.
[02:22] <ajmitch> TheMuso: we'll be getting 2.6.31 for karmic?
[02:23] <TheMuso> ajmitch: I believe so.
[02:23] <TheMuso> Its even mentioned in the #ubuntu-kernel channel topic.
[02:24] <ajmitch> ok
[02:24]  * ajmitch doesn't visit there :)
[02:25] <TheMuso> At one point I would have said that thats pushing things a bit far, but now that Pulse needs it, I await it eagerly.
[02:25] <TheMuso> Pulse development is still moving very rapidly.
[02:26] <ion> Why does it need 2.6.31?
[02:26] <ScottK> So it's a 3 kernel version release agaon.
[02:26] <ScottK> again ....
[02:26] <TheMuso> ion: Pulse specifically doesn't, but pulse now depends on rtkit which needs 2.6.31.
[02:26] <ScottK> That worked out soooo well last time.
[02:27] <TheMuso> ScottK: I tend to agree.
[02:27] <ajmitch> ScottK: hopefully with a few more people working on it this time it'll be a bit less problematic
[02:27] <ion> rtkit, huh. /me looks it up. Probably not as bad as it sounds. ;-)
[02:27] <TheMuso> ion: its a new Lennart creation.
[02:27] <ScottK> ajmitch: What makes you think there will be more people working on the kernel in Karmic than Intrepid?
[02:28] <ajmitch> ScottK: I thought that the team had grown a little in the last year or so
[02:28] <TheMuso> I believe it has.
[02:28] <ScottK> OK.  Well I hope so.
[02:28] <ScottK> Intrepid was the first time I had systems I couldn't upgrade due to kernel problems.
[02:30] <ajmitch> I don't recall too many people saying that intrepid's kernel was buggier than previous releases
[02:33] <ScottK> My personal experience was pretty awful, but of course everyone has different stuff, so see it differently.
[05:54] <lifeless> yay karmic
[05:54] <lifeless> $ python
[05:54] <lifeless> Python 2.6.2+ (release26-maint, Jun 19 2009, 15:16:33)
[05:54] <lifeless> [GCC 4.4.0] on linux2
[05:54] <lifeless> Type "help", "copyright", "credits" or "license" for more information.
[05:54] <lifeless> >>> import qt
[05:54] <lifeless> Segmentation fault
[05:55] <NCommander> lifeless, by some definitions, that's a feature
[06:28] <mrooney> haha, truly
[06:40] <dholbach> good morning
[06:48] <pitti> Good morning
[06:53] <directhex> microsoft-sponsored party this evening. i feel it is my duty to wear my uds crew shirt
[06:57] <pitti> didrocks: lol! have fun
[06:57] <enrico> directhex: and to eat and drink as much as possible, so that as much as possible of their money gets spent on free software people!
[07:00] <pitti> (with drinking not necessarily into free software _quality_ :-P)
[07:02] <Chipzz> NCommander: rofl :)
[07:24] <pitti> tkamppeter_: when you merge, please use debuild -S -v<previous version in Ubuntu>, so that the .changes gets the merged changelogs from Debian as well; thanks!
[07:28] <tkamppeter> pitti, sorry.
[07:28] <pitti> tkamppeter: no problem, just a reminder for the future; nicer to read on karmic-changes@
[07:29] <tkamppeter> pitti, now my only missing merge is Gutenprint, but I will wait for the 5.2.4 release which will come in the next days.
[07:29] <pitti> tkamppeter: that'll go into Debian soon?
[07:31] <tkamppeter> pitti, depends on the Debian maintainer.
[07:32] <tkamppeter> I want to have it in Karmic anyway.
[07:33] <tkamppeter> pitti, by the way, Poppler 0.11.0 did not make it into Debian yet.
[07:39] <pitti> tkamppeter: ah, I thought you wanted to wait with the merge until .4 is in Debian
[07:39] <pitti> tkamppeter: poppler> they'll wait for 0.12 to get the stable series; Seb said it should get released in a few weeks
[07:41] <tkamppeter> pitti, if the Debian maintainer quickly updates I can get gutenprint 5.2.4 in by merge, if not I will take it directly to get it in before FF.
[07:46] <tkamppeter> pitti, OK if 0.12 gets into Debian before our FF, we simply reactivate pdftoopvp in the cups package, if it comes too late, we need to reactivate pdftoopvp in a Ubuntu-only way.
[07:48] <pitti> tkamppeter: gutenprint> sure; but if that will still take a while, don't hesitate to merge it now (also to get our remaining patches to Debian), then the next merge will be easier, and Debian can also apply patches to their 5.2.4 upload
[07:48] <pitti> tkamppeter: poppler> right, that will be a little tricky in the cups package, but doable
[07:57] <dholbach> does anybody else have held mono packages in karmic? (amd64?)
[08:00] <TheMuso> dholbach: Yeah when I upgraded earlier today I did.
[08:01] <dholbach> does anybody know what the hold up is there?
[08:01]  * dholbach wants his gnome-do to work again
[08:02] <pitti> works fine here; only held back package here is libgdl-1-common
[08:02] <pitti> (I guess due to amd64/i386 build skew)
[08:02] <persia> dholbach, Likely arch-all vs. arch-any and a publisher run, try refreshing your cache.
[08:03] <dholbach> persia: it's stuck since yesterday
[08:04] <persia> dholbach, Erg.  That's too long.  What's at the bottom of the stack?
[08:04]  * persia doesn't currently have any working amd64 hw, and can't check.
[08:05] <persia> Alternately, if you don't want to chase the stack, just feed rmadison a *really* long line including all the packages you have held back, and see if there is any skew.
[08:05] <dholbach> The following packages will be REMOVED:
[08:05] <dholbach>   mono-2.0-runtime mono-common mono-jit ubuntu-desktop update-manager
[08:05] <dholbach>   update-notifier
[08:05] <dholbach> The following NEW packages will be installed:
[08:05] <dholbach>   binfmt-support libmono-i18n-west2.0-cil
[08:05] <dholbach> The following packages will be upgraded:
[08:05] <dholbach>   libmono-corlib2.0-cil libmono-data-tds2.0-cil libmono-data2.0-cil
[08:05] <dholbach>   libmono-getoptions2.0-cil libmono-posix2.0-cil libmono-security2.0-cil
[08:05] <dholbach>   libmono-sharpzip2.84-cil libmono-sqlite2.0-cil libmono-system-data2.0-cil
[08:05] <dholbach>   libmono-system-web2.0-cil libmono-system2.0-cil libmono2.0-cil mono-2.0-g
[08:05] <dholbach>   mono-gac mono-gmcs mono-runtime update-manager-core
[08:05] <dholbach> hi mvo :)
[08:05] <pitti> dholbach: oh, I think I had that yesterday, and I just had it remove them
[08:05] <mvo> hey dholbach
[08:05] <pitti> dholbach: it looked like -runtime got split into several smaller libs or so
[08:05] <pitti> dholbach: I didn't really care
[08:05] <persia> It did.  Part of the continued effort to make mono take less space on the CD.
[08:06] <pitti> dholbach: (btw, that's not "held back", that's usual conflicts/replaces:)
[08:06] <dholbach> hum
[08:07] <directhex> it had better be! if it was held back i'd be sad
[08:08] <dholbach> ok, looks like gnome-do works again :)
[08:08] <Hobbsee> yay, gnome-do!
[08:09] <dholbach> gracias
[08:11]  * dupondje waiting for busybox to get fixed :P
[08:13] <hyperair> is anyone else besides me noticing update-manager-core having a newer version, but update-manager not?
[08:14]  * hyperair scratches his head
[08:14] <pitti> update-manager-core |    1:0.122 |        karmic | i386
[08:14] <pitti> update-manager-core |    1:0.123 |        karmic | amd64
[08:14] <pitti> update-manager |    1:0.122 |        karmic | all
[08:14] <pitti> I'd say that i386 FTBFSed
[08:16] <mvo> its waiting in binary NEW
[08:16] <mvo> well, auto-upgrade-tester is waiting there I would guess
[08:17] <dupondje> hyperair: same here indeed :p
[08:17] <StevenK> pitti: So, I suck, and didn't upload last night.
[08:17] <hyperair> ah i see
[08:18] <dupondje> https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/391299
[08:18] <dupondje> fixxor plz :)
[08:19] <pitti> ah, is that why I'm thrown into a busybox shell now?
[08:19] <pitti> (just ctrl-d'ing helps)
[08:20] <seb128> same here
[08:21] <dupondje> yep pitti
[08:21] <dupondje> I have a fixed version in my ppa
[08:22] <pitti> I'd wait for cjwatson to comment, though
[08:22] <dupondje> well the previous versions had a patch included
[08:22] <dupondje> custom
[08:22] <dupondje> to support sleep 0.1
[08:23] <dupondje> the newest version (used in karmic) has sleep for floats built in, so no more patch included. But its a configuration option that needs to be enabled. If its not enabled ofc, it will not work :P
[08:28] <dupondje> should be pushed into repo's imo :) nothing fancy changed ;)
[08:31] <pitti> dupondje: I expect cjwatson to turn up in about 30 minutes, I'll confirm with him and then upload
[08:31] <pitti> dupondje: thanks for your investigations!
[08:32] <directhex> anyway, yays @ mono 2.4 in karmic
[08:32] <directhex> should mean a little saving on the cd (possibly a couple of apps need to be rebuilt to pick up on lighter dep tree)
[08:32] <pitti> directhex: \o/ rock
[08:32] <directhex> and a <=25% drop in RAM consumption
[08:33] <directhex> pitti, when (not if, when!) the latest tomboy goes into Experimental & gets requestsynced, that gives you 5 meg
[08:33] <dupondje> pitti: np :) at least its working here again with the changes :)
[08:33] <pitti> directhex: wow! *hug*
[08:33]  * pitti sheds a tear
[08:34] <pitti> directhex: admittedly, _every_ upload has a <= 25% drop in RAM consumption :)
[08:34] <pitti> erm, at least almost all
[08:34] <directhex> pitti, it's thanks to a snippet of debian/rules wizardry which symlinks gnome doc images with matching md5sums, since stupid gnome help requires a full set of images for every translation (even though the images are usually dupes)
[08:35] <pitti> directhex: ah, we have that in cdbs for quite a whilw
[08:35] <pitti> I wasn't aware that tomboy didn't catch that
[08:35] <pitti> nice air to be squeezed out indeed
[08:36] <directhex> pitti, well, the theory is 25% drop in mono's runtime overhead in the new jitter - but real-world in apps, much of the memory consumption comes from the underlying gtk+ and mono's not to blame, so real-world gui apps will give less than 25%
[08:39] <hyperair> directhex: does 25% drop mean a 25% decrease in startup time then? =D
[08:40] <hyperair> oh RAM consumption only =(
[08:40] <directhex> hyperair, tomboy in karmic is <=50% faster to start up due to changes in the way it works with mono-addins
[08:40] <hyperair> cool
[08:40] <hyperair> but it doesn't help my incredibly long login time
[08:40] <hyperair> it takes longer to log in than to boot
[08:40] <hyperair> =(
[08:41] <hyperair> in fact, i think i can take a shit faster than it can log in
[08:41] <StevenK> !ohmy
[08:42]  * hyperair facepalms
[08:42] <hyperair> shit is now a swear word eh
[08:42] <directhex> i run no mono apps on login, and login is slow
[08:42] <directhex> hyperair, always has been
[08:43] <StevenK> hyperair: The image is ... not attractive, hm?
[08:43] <hyperair> fine. i take a shorter time to defecate than it takes for my notebook to log in
[08:43] <StevenK> That doesn't help!
[08:43] <Hobbsee> hyperair: dude...
[08:44] <Hobbsee> hyperair: besides, if you want a faster boot time, switch to metacity, adn don't use copiz
[08:44] <hyperair> i know, damnit.
[08:44] <directhex> or dump gnome and use twm
[08:44] <directhex> erm, wait, don't use the word "dump" there. um...
[08:44] <hyperair> but why can't we put some effort into speeding up the login process instead of the bootup process?
[08:44] <hyperair> it's so fast already!
[08:45]  * Hobbsee throws both hyperair and directhex into the gutter
[08:45] <Hobbsee> hyperair: who's to say that they aren't?
[08:45] <directhex> hyperair, such things ARE being worked on. there was a talk about it at UDS
[08:45] <hyperair> oh there was?
[08:45] <hyperair> it seemed that bootup time got more attention
[08:45] <StevenK> Boot time means BOTH
[08:46] <directhex> hyperair, the 10 second boot time being talked about for lurid lemur is grub->desktop not grub->login
[08:46] <pitti> hyperair: we will
[08:46] <hyperair> heh okay
[08:46] <hyperair> lurid lemur..
[08:46] <hyperair> nice name
[08:46] <pitti> hyperair: seb128 wants to work on nautilus, I'll look into speeding  up the panel
[08:46] <hyperair> cool =D
[08:46] <pitti> maybe robert_ancell and mvo can make the compiz startup faster, this is dreadful right now
[08:47] <directhex> the panel occasionally wants to delete half my widgets on login. i wish i knew why
[08:47] <pitti> those are the three main offenders, the rest is pretty negligible
[08:47] <hyperair> the applets crashed
[08:47] <hyperair> that's why
[08:47] <directhex> pitti, those specifically, or their deps? e.g. does gconf take time to behave?
[08:47] <mvo> we did ~30% faster startup last cycle :)
[08:47] <mvo> (with compiz)
[08:47] <pitti> directhex: those specifically; well, with panel you have bonobo and all the applets, which are deps in some way
[08:47] <hyperair> that's 30%?
[08:48] <seb128> mvo, still 70% to go ;-)
[08:48] <pitti> lol
[08:48]  * mvo hugs seb
[08:48] <pitti> yeah, must take zero time!
[08:48] <Hobbsee> agreed!
[08:48] <pitti> mvo: we so much need KCWM
[08:48] <directhex> seb128, sorry btw, my fault tomboy 0.15.1 is late. i went for beer with meebey on monday so he couldn't sponsor it
[08:48]  * hyperair read that compiz took a lot of time to just read configuration
[08:49] <seb128> directhex, this "waiting on debian" doesn't really make sense why don't we upload to ubuntu and sync when they wake up in some weeks?
[08:49] <seb128> it's blocked for debian for almost 2 weeks now
[08:49] <seb128> on debian
[08:50] <directhex> seb128, poke Laney about it - i think he's been using git in a sufficiently sensible way that it should be safe to do so
[08:51] <seb128> he tell me every day that it will be uiploaded to debian today
[08:51] <seb128> but apparently that's not happening
[08:51] <directhex> well, yes, there's a bottleneck there.
[08:52] <directhex> if only we had more than one DD in that team (http://lists.debian.org/debian-newmaint/2009/06/msg00037.html)
[08:53] <cjwatson> dupondje: ok, thanks, looking
[08:54] <cjwatson> pitti: I don't think the patch as attached is quite right so please don't sponsor it directly
[08:54] <pitti> cjwatson: good morning
[08:54] <pitti> cjwatson: right, I had a feeling it was better to wait for you :)
[08:54] <dupondje> cjwatson: did my best ;) it works here anyway ;)
[08:54] <pitti> cjwatson: like, you might not need it in the udeb, etc.
[08:55] <directhex> seb128, i think Laney is using pristine-tar so there shouldn't (!) be any problems with mismatched origs from a 0ubuntu1
[08:55] <cjwatson> exactly
[08:55] <pitti> dupondje: nothing to worry about; tracking it down was the hardest part here
[08:55] <cjwatson> definitely my fault though, I knew about the new config option and it obviously just slipped my mind
[08:56] <dupondje> quit the drugs :)
[08:56] <cjwatson> I don't think we need FANCY_SLEEP
[08:56] <dupondje> yep u need it
[08:56] <dupondje> FLOAT depends on it
[08:56] <cjwatson> oh, but yes you're right
[08:56] <dupondje> if u don't enable FANCY then FLOAT doesn't work
[08:56] <cjwatson> u => you please
[08:57] <pitti> cjwatson: so, that patch with static and udeb dropped?
[08:57] <cjwatson> anyway, I'm on it :)
[08:57] <pitti> okay
[08:57] <pitti> thanks
[08:57]  * directhex blames twitter for making txt spk fashionable again
[08:57] <cjwatson> I just want to think briefly about whether we actually do need it in the udeb
[08:59] <cjwatson> we didn't have FANCY_SLEEP turned on there before, but the prior patch didn't require FANCY_SLEEP for fractional sleep
[09:06] <cjwatson> uploaded, anyway
[09:09] <dupondje> cjwatson: your computer was to fast, so it didn't need to sleep :) Looks like some people fixed it by replacing UUID by /dev/sd* etc. Cause everything worked, but if it really needed to sleep a bit, it wasn't
[09:09] <cjwatson> probably
[09:09] <cjwatson> ah well, sorry about that anyway :-/
[09:10] <dupondje> bugs happen :)
[09:17] <maxb_> Ah, I just filed a bug about that sleep issue
[09:18] <maxb_> Anyway, on the trail of *another* bug, where does hal keep its device information these days? I need to find whatever rules it's applying for synaptics touchpads and apply them to another device name
[09:18] <cjwatson> maxb_: you already duped it?
[09:18] <maxb> I filed mine on initramfs-tools
[09:19] <cjwatson> ah, I'll dup it now
[09:20] <maxb> ok, I was just hunting scrollback for the number to dupe it to
[09:20] <MTecknology> pitti: you around?
[09:20] <pitti> MTecknology: hi
[09:21] <MTecknology> pitti: I have a question about a bug report
[09:21] <MTecknology> You think this is still valid? https://bugs.edge.launchpad.net/ubuntu/+source/swfdec-gnome/+bug/188150
[09:21] <cjwatson> maxb: oh, note that you'll need to run 'sudo update-initramfs -u' by hand after the upgrade
[09:21] <maxb> ah, thanks
[09:22] <cjwatson> busybox-initramfs is a dependency of initramfs-tools, so can't itself run update-initramfs ...
[09:22] <cjwatson> annoying, but there it is
[09:22]  * maxb scratches head on why for one boot only, synaptics device was called 'PS/2 Synaptics TouchPad' not 'SynPS/2 Synaptics TouchPad'
[09:22] <pitti> MTecknology: nobody followed up on it recently, so right now I don't consider it valid
[09:23] <MTecknology> pitti: care if I close it?
[09:24] <pitti> MTecknology: I'm fine with that
[09:25] <MTecknology> pitti: you think you have enough open bugs?
[09:25] <pitti> heh, yes :)
[09:26] <dupondje> what should I do when I find bugs of Ibex Beta ... mark as Invalid ? cause no need to keep them open ?
[09:27] <cjwatson> err, that depends on whether they are still bugs in karmic
[09:28] <cjwatson> bugs are not automatically invalid just because they were filed on intrepid!
[09:28] <cjwatson> http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2009-02-27-bug-triage-rants.html
[09:28] <dupondje> https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/278434 <- this for example :)
[09:29] <cjwatson> the correct procedure is to figure out what the problem was
[09:29] <cjwatson> if that problem is fixed, fix released
[09:29] <cjwatson> if that problem is not fixed, leave it open
[09:30] <cjwatson> I've reassigned that bug to linux, where it likely belongs
[09:30] <cjwatson> it should definitely not be summarily marked invalid
[09:31] <MTecknology> pitti: what is your job at canonical?
[09:31] <cjwatson> not without further investigation
[09:31] <dupondje> ok :)
[09:31] <pitti> MTecknology: see https://launchpad.net/~pitti
[09:34] <MTecknology> pitti: i just saw you're karma score too. It makes me feel like my 30k look like I don't do a single thing in lp :P
[09:34] <MTecknology> convert that to decent english in your head.. I must be tired
[09:34] <pitti> MTecknology: well, I do quite a lot, but admittedly most of my karma is a bug (see bug 373772)
[09:35] <MTecknology> wow
[09:36] <MTecknology> I thought soyuz was for packaging ppa
[09:36] <cjwatson> soyuz does the Ubuntu archive
[09:37] <MTecknology> I think I'd need to learn too much to understand all that
[09:38] <MTecknology> maybe
[09:38] <cjwatson> briefly, Soyuz is the component of Launchpad that accepts uploads, publishes them in archives, etc.
[09:39] <StevenK> pitti: If I upload this package now, can you review it soonish?
[09:39] <pitti> StevenK: yes, I can
[09:44] <StevenK> pitti: Uploaded, unr-meta. If you can put it into universe for the moment, I'll look at getting it thrown to main when all of its depends are.
[09:45] <cjwatson> TheMuso: was the 386 kernel flavour not meant to have been merged along with the rest of ports?
[09:47] <dupondje> Launchpad will be going offline for maintenance in 13 minutes.
[09:47] <dupondje> eeek :)
[09:48] <pitti> StevenK: not in the queue yet
[09:49] <StevenK> pitti: I just checked, I did at least target karmic
[09:50] <cjwatson> I do wish people would NEW kernel udebs properly :-/
[09:50] <cjwatson> and not just casually dump stuff into universe
[09:50] <pitti> cjwatson: hm, kernel-overrides should catch them, doesn't it?
[09:50] <cjwatson> only if they match a previously existing package
[09:51] <pitti> ah, so "real" NEW
[09:51] <pitti> StevenK: still not in the queue; did you get a reject mail?
[09:51] <cjwatson> you're supposed to check the results of kernel-overrides, not just go kernel-overrides; q accept :)
[09:51] <cjwatson> I've cleaned up the overrides now
[09:51] <StevenK> pitti: Lemme check
[09:56] <mvo> cjwatson: do you mind if I upload grub2 with the following patch http://paste.ubuntu.com/202725/ to support crashkernel= in it?
[09:56] <StevenK> pitti: Seems like I didn't get a mail about it at all
[10:01] <TheMuso> cjwatson: apw, rtg and I were discussing this the other day. I didn't merge 386 thinking there was a chance that Ubuntu would move to 586 only. There is also the issue of the 386 kernel possibly breaking kernel builds, since it has kernels that are supported. I await their decision as to whether it gets put back in for now.
[10:07] <cjwatson> mvo: spell "crashkernel" correctly in the patch name :)
[10:08] <robbiew> lol
[10:08] <cjwatson> mvo: um, it's OK for upload now, but that file is mainly maintained by upstream and we'd like to stay close to them. Could you please send it to<EMAIL_ADDRESS>as well to discuss what a good upstreamable solution would be?
[10:09] <cjwatson> TheMuso: I was under the impression we were planning to *tune* for 586 (-mtune vs. -march), but could be misremembering
[10:09] <cjwatson> actually it's possible I am misremembering since 586 isn't a good tune target :)
[10:10] <mvo> cjwatson: *cough* sorry for the typo - I will fix that and send the patch to the devel list as well
[10:11] <cjwatson> mvo: (you might need to give grub-devel some background, of course ...)
[10:18] <mvo> cjwatson: thanks , I will add that info too
[10:54] <freinhard> hi!
[11:10] <ogra> cjwatson, do we have a udeb that sets up a serial console ?
[11:10] <cjwatson> does it need a separate udeb?
[11:10] <cjwatson> I thought rootskel did that if you followed the directions in the installation guide
[11:11] <ogra> well, we're just discussing a) debootstrapped systems  and b) the possible need to set up a serial console later in an installed system
[11:11] <cjwatson> debootstrapped systems get to configure some stuff themselves. I'm uninterested in "fixing" that
[11:11] <cjwatson> finish-install does serial console setup in that case
[11:11] <ogra> i'm in the camp that we should just have a serial-console package that has preseedable options for device speed etc
[11:12] <cjwatson> err, let me rephrase that. "now that I understand what you mean, finish-install is where the code lives"
[11:12] <ogra> and drops the /etc/event.d file in place
[11:12] <cjwatson> it really doesn't need a separate udeb
[11:12] <ogra> ok, well, i was hoping if there is a udeb we could just make an easy change to make the source spit out an additional deb :)
[11:13] <cjwatson> no point in it being preseedable, we just fish the options out of the serial console on which the installer is already presumptively running by means of stty
[11:13] <ogra> right, in case of the installer
[11:13] <cjwatson> sounds like overengineering. just tell people how to set it up; debootstrapped systems already require quite a bit of manual setup after debootstrapping.
[11:13] <ogra> in case of me using debootstrap inside qemu i wont have the actual device string the target HW will use
[11:13] <cjwatson> serial console is just one tiny piece of that.
[11:16] <ogra> well, my original prob is that plenty of people use my arm-rootfs-builder script ... i drown in requests from people not being able to set up the serial parts after rolling the rootfs.tgz ... i would like to add an option to my script ... and i dont want to addd anything self hacked but something we all benefit from :)
[11:16] <ogra> specifically i'D like to obsolete https://help.ubuntu.com/community/SerialConsoleHowto
[11:17] <freinhard> anyone else with broken wlan on karmic? http://paste.ubuntu.com/202401/
[11:21] <cjwatson> ogra: for the moment, I think you should just extend your script
[11:21] <ogra> ok ...
[11:21] <cjwatson> I don't see a purpose in creating a deb that solves just this one piece of the configure-after-debootstrap problem, and not the whole thing
[11:22] <ogra> indeed and the deb would only be a postinst dropping 7etc/event.d/serial (or some such) in place
[11:28] <lifeless> slangasek: getting there before d-d does; 'Why do you hate freedom?'
[11:32] <dupondje> python-xml is renamed to python-xmlbase in karmic ?
[11:35] <maxb> dupondje: I'd suggest you check the removal reason... but LP is down for maintenance.
[11:35] <maxb> But I'd guiess that python-xml is removed in karmic
[11:35] <dupondje> yea indeed, seems so
[11:35] <maxb> Yup, it's on the sync-blacklist
[11:36] <dupondje> its now for default in python or so ?
[11:37] <dupondje> damn launchpad :) when its down you realise you use it ALOT :)
[11:46] <StevenK> pitti: Is it there now? *whine*
[11:47] <pitti> StevenK: as you can check yourself with "q info unr", no :/
[11:47] <StevenK> pitti: Hmmm.
[11:47] <StevenK> :-(
[11:47] <pitti> perhaps because LP is read-only ATM?
[11:54] <StevenK> pitti: I uploaded it before that, but hopefully it hasn't disappeared
[12:01] <maxb> Could someone giveback dia/i386? Looks like some kind of weird transient problem (CHROOTWAIT / Resource temporarily unavailable) - https://launchpad.net/ubuntu/+source/dia/0.97-2/+build/1087621
[12:21] <StevenK> pitti: Just got the e-mail, please NEW it
[12:21] <pitti> StevenK: so apparently it was stuck by the LP rollout
[12:22] <pitti> StevenK: "Copyright 2004, Canonical Ltd." -- please fix in bzr
[12:23] <pitti> StevenK: also, debhelper 4 is deprecated, please use at least 5
[12:23] <pitti> (and S-V 3.8.2 while you are at it)
[12:23] <pitti> StevenK: accepted
[12:31] <cjwatson> maxb: done
[12:40] <StevenK> pitti: Thanks!
[12:44] <bigon> https://edge.launchpad.net/ubuntu/+source/empathy/2.27.3-1ubuntu1/+build/1091194 failed to upload
[12:44] <bigon> :/
[12:53] <cjwatson> bigon: no idea what happened there, but I've retried everything in the failed-to-upload state
[12:53] <cjwatson> if it happens again, let me know and we'll investigate
[12:53] <wgrant> cjwatson: It was demoted during the build.
[12:53] <wgrant> Known bug.
[12:54] <wgrant> Well, not during, but before a publisher.
[12:57] <cjwatson> ah
[12:58] <wgrant> So, due to the demotion plus the downtime, there were two non-superseded publishings, so it got confused.
[13:02] <bigon> mmm and why empathy has been demoted?
[13:03] <seb128> bigon, to get it to build I though the previous build failed because of universe build-depends
[13:03] <seb128> bigon, could have been wrong, I will promote it again once it has build
[13:05] <StevenK> seb128: Won't promoting it to main also rebuild it?
[13:05] <seb128> StevenK, no
[13:06] <seb128> why would a component change trigger a rebuild?
[13:06] <seb128> we don't have bin-nmu anyway
[13:15] <ScottK> pitti: I have an SRU question.  In amavisd-new, we have an issue in Jaunty where the secondary virus scanner function doesn't successfully call clamav.  Would that be SRU material do you think or should I just backport the new version from Karmic?  The fix itself is quite small.
[13:18] <Kano> hi, why is a ? in the console-setup/layoutcode?=xx option in karmic iso images?
[13:18] <Kano> when you check with: cat /proc/cmdline
[13:19] <Kano> that must be wrong
[13:20] <juanje1> Kano: hummm... it seems so to me...
[13:24] <cjwatson> Kano: no, it's correct
[13:25] <Kano> define correct
[13:25] <Kano> it is definitely not german when i boot it
[13:25] <cjwatson> Kano: ?= means "set value, but don't mark as seen"
[13:25] <cjwatson> if it isn't working, it's not because of the ?=
[13:26] <cjwatson> (see scripts/casper-bottom/24preseed)
[13:26] <cjwatson> (or indeed scripts/casper-bottom/19keyboard)
[13:29] <Kano> btw. you should set de-latin1-nodeadkeys for install-keymap
[13:29] <Kano> in case of german
[13:29] <cjwatson> no we shouldn't. That's for console-data which we haven't used since edgy.
[13:30] <Kano> and do you really think that karmic works correctly
[13:31] <cjwatson> I didn't say karmic worked correctly. I said that the ?= is not the problem.
[13:31] <cjwatson> nodeadkeys: I'm not going to change the default variant on the word of a single person - file a bug and get consensus from German users
[13:32] <cjwatson> since I don't use German layouts myself, it would be inappropriate for me to be deciding on what's best, and inappropriate to flip-flop in response to single bug reports
[13:33] <freinhard> Kano: please post the bug id, i'll vote for nodeadkeys ;)
[13:33] <cjwatson> I get a German layout in X when booting with the German layout
[13:33] <cjwatson> it's just the console that's broken
[13:34] <cjwatson> and I think it's broken for everyone, not just German
[13:34] <cjwatson> it'll be some horrible initramfsy thing
[13:34] <ogra> beyond that there was a vote on the forums and german mailing list to keep deadkeys
[13:35] <kenvandine_wk> cjwatson, is there a work around?
[13:35] <ogra> we touched that topic end of jaunty/start of karmic
[13:35] <cjwatson> kenvandine_wk: for broken console? run 'sudo setupcon' after boot
[13:35] <kenvandine_wk> ok
[13:36] <Kano> cjwatson: and you like brokin console,do you
[13:37] <cjwatson> Kano: huh? of course I don't
[13:37] <cjwatson> Kano: if you're just going to abuse me, please go away
[13:37] <cjwatson> it's clearly a bug at present
[13:39] <cjwatson> and in fact I noticed it myself on my normal system with a UK layout earlier today, but hadn't got round to doing anything about it yet
[13:39] <Kano> fine
[13:39] <Kano> will check it next week again
[13:40] <ogra> ah, damned, he's gone ... http://forum.ubuntuusers.de/topic/welches-deutsche-tastaturlayout-benutzt-du/ ...
[13:43] <ogra> freinhard, you missed the vote :)
[13:44] <freinhard> that vote asks the wrong question! shouldn't be "which keyboard layout do you use" but rather "which keyboard layout should be default"
[13:45] <ogra> well, the according mail i wrote made the issue pretty clear, i admit the poll question isnt perfect :)
[13:45] <freinhard> i use deadkeys as well, but that's because i'm to lazy to change it
[13:47] <ogra> i hate deatkeys and switch it during install ... but the thread and forum discussion brought up way to valid reasons to keep deadkeys as default
[13:47] <ogra> so it wont be switched
[13:48] <ogra> https://lists.ubuntu.com/archives/ubuntu-de/2009-April/016569.html is the thread
[13:51] <bigon> seb128: so you've planned to put empathy back to main?
[13:51] <seb128> yes, why not?
[13:51] <seb128> I just wanted to get the new version to build and I though the issue was universe requirements
[13:52] <pgraner> asac: what the plan for ff 3.5 for Karmic, still a ppa or will it become the default?
[13:52] <bigon> ok no problem do you know if some ppl have asked a mir for the needed packages?
[13:53] <seb128> issues are being worked yes
[13:54] <kenvandine> seb128, btw... fedora has a patch that moves the gst plugins empathy needs to -good
[13:54] <asac> pgraner: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-firefox-3.5
[13:54] <kenvandine> so that is their fix
[13:54] <seb128> cool
[13:54] <kenvandine> doesn't mean upstream agrees yet
[13:54] <kenvandine> but maybe we should follow suit
[13:54] <pgraner> asac: show off.... I must have missed it... I even looked... *sigh*
[13:54] <asac> pgraner: its in universe
[13:54] <asac> pgraner: go ahead and start using it ;)
[13:54] <asac> (its just not yet officially branded)
[13:55] <asac> pgraner: apt-get install firefox-3.5 :)
[13:55] <pgraner> asac: I have been for months now from your ppa
[13:55] <pgraner> asac: thats why I was asking
[13:55] <asac> pgraner: ah ok. so yeah. things are moving; its quite a lot of work though ;)
[13:56] <bigon> seb128: don't forget to put geoloc stuff (libchamplain and geoclue) in main too :)
[13:57] <seb128> we are not likely to use those by default
[14:00] <pgraner> asac: I use the weave extension and it only works with that version...
[14:00] <pgraner> asac: thanks for the info
[14:00] <robbiew> pgraner: I didn't know you wore a weave extension :P
[14:00] <pgraner> robbiew: trying to keep hip and all :-/
[14:03] <pitti> ScottK: is it a regression from intrepid?
[14:03] <pitti> ScottK: OTOH it almost sounds like a -security issue, is it?
[14:27] <mvo> hm, could someone please check/binary-NEW auto-upgrade-tester from my latest update-manager upoad?
[14:28] <mdz> cjwatson: Keybuk: do you recall  which TB meeting it was where we outlined the patent policy?  I have an overdue action to write it up
[14:29] <Keybuk> mdz: off hand, about three
[14:29] <Keybuk> Jono's drafts were Apr 07 and Apr 15
[14:29] <Keybuk> in which he said "a few weeks back"
[14:29] <Keybuk> so Mar-Apr sometime ;)
[14:29] <mdz> Keybuk: I'm looking for the one where Mark turned up
[14:29] <Keybuk> Feb 18 minutes say "assigned to Jono"
[14:30] <mdz> Keybuk: hmm, that's right, it's coming back to me now
[14:32] <Keybuk> it appeared on the agenda from about Jan 4 through to March by the looks it
[14:33] <mdz> and then jono wrote something up, and emailed asking for feedback
[14:33] <mdz> and then I lost the plot
[14:34] <cjwatson> mdz: the TB meeting action gives the date
[14:34] <cjwatson> 15:19 <cjwatson> [ACTION] mdz to write up patent policy minutes from 2009-03-24 meeting
[14:34] <Keybuk> I used Jono's draft text for the position statement
[14:34] <cjwatson> http://irclogs.ubuntu.com/2009/03/24/%23ubuntu-meeting.html
[14:34] <mdz> cjwatson: was that before or after jono was involved?
[14:34] <Keybuk> after
[14:34] <mdz> so I have the ball
[14:34] <cjwatson> the meeting log suggests it was after
[14:35] <mdz> but I'm not sure what I need to do
[14:35] <mdz> I'm about to just copy Jono's draft to the tb list and add my commentary
[14:35] <cjwatson> what I intended by that action was simply a write-up of the discussion in that meeting
[14:35] <Keybuk> that seems like a good idea
[14:35] <cjwatson> but if there's already a draft policy to amend with it, all the better
[14:40] <mdz> cjwatson: Keybuk: sent to t-b@
[14:40] <cjwatson> ta
[14:47] <StevenK> pitti:   * Removed udev-extras from standard
[14:47] <StevenK> pitti: From a germinate on ubuntu.karmic ...
[14:47] <pitti> StevenK: that depends on Keybuk uploading udev 143
[14:47] <superm1> StevenK, all of udev-extras got pulled into udev for udev 143
[14:48] <pitti> don't upload that yet, please
[14:48] <ScottK> pitti: It's a regression in that clamav changed (we have 0.95 in Jaunty) and the new clamav works slightly differently.  I think it's not security since it's a functional failure, not any kind of access issue.
[14:48] <StevenK> pitti: Right, I'll wait until my tomorrow.
[14:48] <pitti> ScottK: I meant in the sense of "bypassing viruses to the scanner"?
[14:48] <pitti> ScottK: anyway, if that worked in intrepid, fine to SRU
[14:49] <ScottK> pitti: OK.  Thanks.
[14:49] <superm1> pitti, do you think you'll get some time this week to look at the jockey-text frontend I proposed?
[14:49] <ScottK> pitti: With the clamav stuff if I really look at it hard almost everything could be a security issue.  It's hard to know.
[15:15] <pitti> superm1: sorry, that seems to have slipped my attention?
[15:18] <seb128> hum
[15:18] <seb128> james_w, is that normal that I get emails about code imports failing?
[15:18] <james_w> seb128: shouldn't get them from me
[15:18] <james_w> seb128: forward me the email and I'll take a look
[15:19] <seb128> james_w, those are not from you, I just figured you might know ;-)
[15:19] <james_w> heh
[15:20] <seb128> "Subject: Code import gvfs/trunk status: Failed
[15:20] <seb128> Hello,
[15:20] <seb128> The import has been marked as failing.
[15:20] <seb128> https://code.launchpad.net/~vcs-imports/gvfs/trunk
[15:20] <seb128> You are receiving this email as you are subscribed to the branch."
[15:20] <seb128> basically
[15:20] <seb128> same for nautilus and gnome-control-center
[15:21] <seb128> I guess that's rather a launchpad question than a bzr one
[15:21] <cjwatson> well, you *are* subscribed to the branch
[15:22] <cjwatson> I assume https://code.launchpad.net/~vcs-imports/gvfs/trunk will let you unsubscribe
[15:22] <seb128> cjwatson, I was rather wondering about the failure than the email ;-)
[15:22] <cjwatson> it seems to be having trouble due to (perhaps?) a git rebase
[15:23] <cjwatson> but yes, it's a launchpad-bazaar question
[15:23] <seb128> yeah sorry I first though that was due to the packages import in bzr
[15:23] <seb128> I pinged too quickly
[15:23] <ttx> cjwatson: thx for sponsoring the ecj thing. I'll file a bug with update-maintainer, it doesn't comply with new DebianMaintainerField.
[15:23] <seb128> cjwatson, james_w: thanks
[15:24] <james_w> seb128: no problem, just glad it wasn't me for once :-)
[15:24] <cjwatson> ttx: don't bother, I'll fix it in bzr now. I thought it was fixed already but apparently now
[15:24] <cjwatson> not
[15:25] <ttx> cjwatson: ok
[15:26] <cjwatson> ttx: uh ... I do apologise. I misremembered what DebianMaintainerField said ...
[15:26] <cjwatson> I'll fix it properly this time. The e-mail address was fine but the name was wrong (and the latter is fixed in bzr)
[15:28] <ttx> cjwatson: heh :)
[15:29] <ttx> cjwatson: about the other part of that GCJ email, would you find the "any" trick still valid if it covers 7-10 packages ?
[15:30] <ttx> cjwatson: the overhead will be more significant but I'm not sure we can find a better solution in the karmic timeframe
[15:31] <amitk> Keybuk: how does one update the readahead list on an upgraded system (jaunty->karmic)?
[15:32] <Keybuk> amitk: boot with "profile" on the kernel command line
[15:33] <amitk> nice... and easy
[15:33] <Keybuk> it's easier with sreadahead
[15:33] <Keybuk> it just does it itself once a month ;)
[15:36] <dholbach> a bunch of packages have<EMAIL_ADDRESS>as their maintainer address and the list gets lots of<EMAIL_ADDRESS>mails due to that
[15:36] <dholbach> can you please use<EMAIL_ADDRESS>(what 'update-maintainer' from the ubuntu-dev-tools package will do for you)?
[15:36] <amitk> Keybuk: is sreadahead a drop-in replacement for readahead?
[15:37] <Keybuk> on SSD, yes
[15:37] <Keybuk> though use the one from the ubuntu-boot PPA, since that doesn't uninstall ubuntu-desktop <g>
[15:38] <amitk> so it is not recommended on platters?
[15:38] <Keybuk> it'll be quite pessimal on platters
[15:38] <amitk> or its benefits are only seen on SSDs
[15:38] <amitk> ?
[15:46] <superm1> pitti, ah i had thought it might have (last time i sent a merge request on jockey it got lost in filters for a while too) : https://code.edge.launchpad.net/~superm1/jockey/jockey-text/+merge/7781
[15:58] <cjwatson> ttx: I'm not that bothered ...
[16:10] <cjwatson> StevenK: are you guys planning to merge libhildon? it should not be my merge
[16:13] <ogra> cjwatson, i doubt we care in the mobile team, there is a new MID community team that casers for moving MID to mer ... (yay for confusing abbreviations)
[16:14] <ogra> *cares
[16:14] <ogra> YokoZar1, ^^^ do you guys need libhildon ?
[17:26] <JohnTeddy> yahoo broke for all pidgin users of Jaunty's version of pidgin. the problem/solution is located here: http://theflamingbanker.blogspot.com/2009/06/some-clarification-on-yahoo-issues.html ... I updated my pidgin and it works. I think this should go into jaunty repositories. this is an fyi if anyone cares.
[17:27] <YokoZar1> persia: ^^ ~ ogra
[17:29] <JohnTeddy> This is for 2.5.5 update to 2.5.7, not many changes except mostly yahoo authentication stuff to fix yahoo. binaries located here: http://pidgin.im/download/ubuntu/
[17:55] <kees> is anyone available to test bug 336554 in -proposed and comment on the bug?  I'd do it, but I was the fixer.  :)
[17:58] <mac9416> Can someone point me to some documentation explaining how apt-get dist-upgrade works?
[17:59] <ScottK> mac9416: Did you already read man apt-get?
[17:59] <mac9416> ScottK, unfortunately, I'm on a Windoze machine ATM.
[18:00] <cjwatson> mac9416: manpages.ubuntu.com
[18:00] <YokoZar1> If foo-1 and foo-2 both Provides: foo and Conflicts: foo, will installing foo-2 uninstall foo-1?
[18:00] <cjwatson> type 'apt-get' into the search box, hit "Title"
[18:01] <cjwatson> YokoZar1: you might need a Replaces: as well, possibly, but yes
[18:01] <YokoZar1> cjwatson: thanks
[18:01] <YokoZar1> cjwatson: you mean Replaces: foo I assume
[18:02] <cjwatson> yes
[18:02] <cjwatson> YokoZar1: lots of packages use this pattern with mail-transport-agent
[18:02] <YokoZar1> Thanks, that's exactly what I want then
[18:14] <cjwatson> lool: I don't suppose you could merge cairo? I don't really know what I'm doing there, but am TIL due to a no-change rebuild
[18:14] <cjwatson> fta: or you maybe?
[18:25] <lool> cjwatson: TIL?
[18:28] <kirkland> james_w: around?
[18:29] <cjwatson> lool: touched it last
[18:29] <lool> I'm looking into it
[18:30] <cjwatson> thanks
[18:32] <james_w> kirkland: hey
[18:32] <kirkland> james_w: hey, i've been struggling for several weeks now with vcs-imports
[18:32] <james_w> of git?
[18:33] <kirkland> james_w: i'm giving up on LP for the moment and trying to get it working locally, and i'll just cronjob an import/push until LP gets straightened out
[18:33] <kirkland> james_w: yes
[18:33] <kirkland> james_w: i'm trying to chase down all the bzr, plugins, dulwich, and such necessary to get this to work
[18:33] <kirkland> james_w: i'm simply trying to: bzr branch git://git.savannah.nongnu.org/qemu.git
[18:34] <kirkland> james_w: or bzr git-import git://git.savannah.nongnu.org/qemu.git
[18:34] <kirkland> james_w: at this point, i think i'm stuck with a version of dulwich that is too old
[18:34] <kirkland> james_w: i installed from https://edge.launchpad.net/~dulwich/+archive/ppa
[18:35] <kirkland> james_w: bzr: ERROR: exceptions.ImportError: bzr-git: Dulwich is too old; at least 0.3.1 is required
[18:36] <cjwatson> I used to have that kind of problem, but my problems went away upon upgrading to karmic
[18:36] <james_w> I guess you have to install from lp:dulwich
[18:36] <kirkland> cjwatson: is that directed at me, or lool?
[18:36] <cjwatson> you
[18:36] <kirkland> james_w: where do i install that to?
[18:36] <james_w> setup.py install should do it
[18:37] <james_w> or just grab the branch and use PYTHONPATH
[18:37] <kirkland> james_w: okay, i'll try that
[18:38] <kirkland> james_w: cool, thanks, that gets me a bit further
[19:02] <genii> Hello. Is there some place .deb pre/postinst pre/postrm scripts get cached and used other than perhaps /var/lib/dpkg/info/packagename.scriptname  ? I had an error in the postrm, manually fixed it there (/var/lib...postrm) which allowed removal. But then after install of the new package with the fix, it seems to be using the old version for some reason.
[19:03] <cjwatson> no, only /var/lib/dpkg/info
[19:04] <cjwatson> of course if you installed a new version then dpkg will likely have overwritten that
[19:04] <genii> Weird.
[19:05] <genii> cjwatson: I required an -f on an update-rc.d line... made the fix (on another box), rebuilt the deb, scp'd it over and installed... then the postrm somehow reverts to the previous one in /var/lib even after a rm'd it. Maybe scp is caching??
[19:11] <cjwatson> genii: scp doesn't cache
[19:11] <cjwatson> I think you almost certainly just made a mistake somewhere
[19:14] <YokoZar1> pitti: ~ Karmic Wine Integration: were you referring to slower startup by starting clamd at login or slower startup by starting clamd upon opening executable-handler?  clamd takes about 5 seconds to start, but it takes very little memory to leave running and can be started in parallel (eg at login).
[19:18] <ScottK> Virtually all of the time is spent reading in virus definitions, so the time wil be related to HD speed.
[19:18] <ScottK>  ... and how much else is going on at the same time.
[19:20] <YokoZar1> ScottK: would making it a low priority task that ran at login be reasonable?
[19:20] <ScottK> YokoZar1: I don't know enough about the boot process to know, but since it's reading from the HD the entire time it'll slow other stuff down if one is IO bound.
[19:21] <YokoZar1> ScottK: also is there a way to tell if clamd is starting up but isn't yet started yet?  We could have it run as the very last thing after the user logs in, and then if they happen to open an executable in the first 5 seconds the script could just wait till it's started
[19:21] <ScottK> YokoZar1: I think if you call it while it's reading in the signatures it'll just block until it's finished.  I'd test this.
[19:23] <YokoZar1> ScottK: hmm that sounds like exactly what we want
[19:23] <ScottK> YokoZar1: Yes, but as I said, I'd test it and make sure.
[19:24] <genii> cjwatson: Weird. When I have the deb on box1, open and examine the postinst there, is correct. On box2 after I scp it over, timestamp is same as original but extracting the postinst shows it is the previous one.
[19:25] <pochu> pitti: hi! pkg-create-dbgsym's dh_strip is missing "-k" for the "--keep-debug" option handling
[19:25] <pochu> pitti: that is, it should be "-k|--keep-debug)"
[19:27] <pochu> pitti: oh, there's a bzr branch... I'll create my own and request a merge if I have further changes :-)
[19:27] <pochu> pitti: just started looking at the ddebs project
[19:30] <pochu> pitti: same for --exclude= and -X
[19:30] <pochu> pitti: I'll look at creating a branch and requesting a merge ;)
[19:34] <genii> OK, found the issue. box1 deb is on an NFS mount which hadn't synced
[20:09] <pochu> huh, are there still packages with debhelper compat 1?
[20:27] <chrisccoulson> mdke - is there a reason that ubuntu-docs no longer ships a /usr/share/omf/about-ubuntu/about-ubuntu-C.omf file anymore in karmic, or is that a mistake?
[20:29] <chrisccoulson> cjwatson - just looking at your gnome-session issue. do you see the same issue with the dialog flicker if you logout instead of rebooting?
[20:42] <ebroder> Any SRU-types around? I have a few bugs that I've been trying to get someone to look at for a few weeks now
[20:46]  * beuno nudges cody-somerville and runs away
[20:52] <slangasek> lifeless: I hate freedom because it makes people lazy and stupid, of course :)
[21:03] <ScottK> slangasek: Would you mind having a look at kubuntu-meta in binary New?  I'm working on getting ready for kubuntu-netbook images early.
[21:12] <nixternal> pitti: just used ubuntu-bug from the command line for the first time, I think I like it better than the GUI :)
[21:24] <slangasek> ScottK: I'm traveling today, don't really have the bandwidth to look at that currently
[21:24] <ScottK> slangasek: OK.  Thanks for lettting me know.
[21:25]  * ScottK shops for archive admins ....
[21:25] <ScottK> jdstrand: Could you  have a look at kubuntu-meta for binary New?
[21:27]  * ScottK notices the time and runs off ....
[21:27] <jdstrand> ScottK: sure
[21:28] <ScottK> jdstrand: Thanks.
[21:33] <jdstrand> ScottK: I'm going to accept it, but kubuntu-netbook doesn't seem to do anything...
[21:36] <Sarvatt> speaking of metapackages, someone was having a problem with netbook remix not pulling in udev-extras (ubuntu-standard?) so they werent getting permissions set right for dri in karmic
[21:38] <Sarvatt> https://bugs.launchpad.net/bugs/384934
[22:01] <ebroder> Is anyone from motu-sru around?
[22:37] <micahg> will there be another round of importing before the freeze tomorrow or do I need to file a requiest at this point?
[22:40] <ripps> Hey, can anybody here give me some help, I'm trying to help Qball, the developer for gmpc, to fix his libnotify plugin to properly display album images in his libnotify plugin.
[22:41] <kirkland> hrm
[22:42] <kirkland> up-to-date karmic
[22:42] <kirkland> gdm login, then kicks me out immediately
[22:42] <kirkland> known issue?
[22:44] <maxb> kirkland: Intel graphics?
[22:45] <maxb> try rolling back the latest mesa update
[22:45] <bryce> kirkland, I've got a fix in my ppa -  mesa - 7.4.1-1ubuntu4
[22:45] <Chipzz> ripps: pls read the topic
[22:46] <bryce> kirkland, once it's finished building and someone can verify, I'll be uploading
[22:48] <kirkland> bryce: thanks
[22:48] <kirkland> maxb: yes, intel
[22:49] <bryce> kirkland, people were complaining about how boringly stable X.org had been so far in karmic
[22:49] <kirkland> bryce: great, thanks for shaking it up some
[22:49] <kirkland> sheesh
[22:49] <bryce> hehe
[22:49] <mathiaz> kees: jdstrand: is it know that apparmor init script fails to reload properly in karmic?
[22:49] <mathiaz> *known*
[22:50] <jdstrand> mathiaz: yes-- apparmor hasn't been forward ported to the karmic kernel yet
[22:50] <kirkland> bryce: ping me if you notice it's done building and i'll test for you
[22:50] <kirkland> on an unrelated note...
[22:50] <mathiaz> jdstrand: ok - should I file a bug for it?
[22:50] <kirkland> karmic seems to be running *very* hot on my thinkpad
[22:50] <dtchen> existing bug, mathiaz
[22:51] <kirkland> 60+ degrees hotter
[22:51] <ajmitch> bryce: are the nvidia 185.x drivers in the PPA liable to make my system crash & burn then, since X.org is so boring? :)
[22:51] <jdstrand> mathiaz: no, it is well known: bug #375422
[22:51] <dtchen> mathiaz: 375422
[22:52] <jdstrand> it is being actively worked on
[22:52] <bryce> ajmitch, sadly no, they should be mind numbingly boring.  We believe they actually make some well loved bugs go away.
[22:53] <ajmitch> I noticed that the package name was still referring to 180, so wasn't sure if it was wise to upgrade
[22:54] <bryce> ajmitch, should be fine.  I'm not sure if we're going to s/180/185/ for consistency; need to chat with tseliot about that
[22:54] <bryce> ajmitch, I'm just waiting on some positive user testing cases and will upload
[22:56] <ajmitch> bryce: alright, I'll try it out
[22:57] <NCommander> Is there a good trick to getting USB modules available in the initramfs?
[22:58] <NCommander> I'm trying to do some debugging in it on ia64, and I find my keyboard is useless there :-/
[22:59] <bryce> kirkland, amd64 and lpia builds ready.  i386 still in progress.  https://edge.launchpad.net/~bryceharrington/+archive/ppa
[23:03] <ScottK> jdstrand: I think that's inevitable the first time through since it's recurseive.
[23:04]  * ScottK prepared to find out I'm wrong.
[23:04] <dtchen> NCommander: /etc/initramfs-tools/modules
[23:04] <dtchen> NCommander: regenerate (update) the initramfs afterward
[23:05] <ebroder> Any motu-sru types around to look at a few bugs? I've had a few waiting for motu-sru review for a few weeks now
[23:05] <NCommander> dtchen, now, you won't happen to know what voodoo is needed to get /dev/fb0 working on ia64 now would you ;-)?
[23:06] <dtchen> NCommander: not offhand, no
[23:08] <maco> ebroder, i think there are only 3 people on the motu-sru team, so that could be why
[23:08] <maco> dtchen, that team you were supposed to start...did ya?
[23:09] <dtchen> maco: no
[23:09] <ebroder> maco: Sounds like they should expand the team, not let bugs fester for weeks/months at a time
[23:09] <dtchen> it's fairly ineffective without seeding the group with people who actually have upload privileges
[23:09] <NCommander> ebroder, maco there's been two open slots for ages
[23:10] <ebroder> I'm kind of frustrated at the moment because I've been practically unable to get anybody to touch my bugs for both SRUs or just normal sponsorship for the last 2 months or so
[23:11] <maco> NCommander, oh, so we need to convince a random motu to go apply for it?
[23:11] <dtchen> ebroder: yes, i know well the feeling. that's the idea behind the "ubuntu-reviewers" (name not set) LP team.
[23:11] <maco> ah! that's the channel missing from my buffer list
[23:11] <maco> (must find a better name than "buffer" for that in quassel. suggestions?)
[23:11] <RAOF> Channel?
[23:12] <maco> motu
[23:12] <RAOF> I meant: maybe "channel" is a better name than "buffer" :)
[23:12] <maco> oh :P well they use it for PMs too
[23:15] <Fenix|work> Greetings...
[23:15] <Fenix|work> TheMuso, Would you happen to be around?
[23:17]  * maxb  installs bryce's mesa
[23:18] <Fenix|work> Does anyone have TheMuso's email address?
[23:19] <maco> Fenix|work, i'd guess he'd be on in about 12 hours
[23:19] <maco> thats when i usually see folk from his area on IRC
[23:19] <DktrKranz> Fenix|work, look at ~themuso on LP
[23:20] <Fenix|work> yeah, I just thought of that<EMAIL_ADDRESS>[23:20] <ajmitch> maco: closer to 2 hours, it's just past 8am there
[23:20] <bryce> maxb, possibly there is still one crash (which there is also a patch for, just not enabled in the ppa build yet)
[23:21] <maco> ajmitch, oh yeah, im still not accustomed to this "awake before noon" idea ;)
[23:21] <dtchen> bryce: 185.18.14-0ubuntu1~xup~1 WFM on C67/GeForce 7150M
[23:21] <maco> (slightly kidding...i get up before dawn...which i contend is still night)
[23:22] <ajmitch> maco: it's a hard life...
[23:22] <bryce> dtchen, thanks
[23:23] <maxb> bryce: It's working fine for me. I can't crash it by doing what I could reliably crash 1ubuntu3 by doing
[23:25] <Fenix|work> Just sent him an email.  We'll see if I get a response. :)
[23:25] <Fenix|work> Thanks all.  Have a good night.
[23:26] <bryce> maxb, aha excellent
[23:28] <kirkland> bryce: installing
[23:29] <cjwatson> chrisccoulson: I didn't see one with m.Logout(dbus.UInt32(2))
[23:30] <chrisccoulson> cjwatson - hmmm, that is strange, as it activates the same code path i think. i'll try and recreate this tomorrow when i get the chance
[23:30] <chrisccoulson> the other thing that can cause the inhibit dialog to appear is a client not responding to the QueryEndSession fast enough
[23:31] <cjwatson> chrisccoulson: should be pretty easy to recreate with the python snippet I posted and a karmic desktop cd
[23:31] <kirkland> bryce: fixed
[23:32] <cjwatson> unless I'm totally on crack of course :)
[23:32] <bryce> kirkland, sweet, thanks.  Upload coming
[23:32] <cjwatson> chrisccoulson: (and thanks for looking at it)
[23:32] <chrisccoulson> cjwatson - i'll have another look at it tomorrow when i finish work
[23:33] <cjwatson> it's not especially urgent, just seems likely to be a bit ugly at the end of installations
[23:33] <cjwatson> although even with the ugliness it's well worth killing off the old code
[23:34] <cjwatson>  23 files changed, 5119 insertions(+), 16381 deletions(-)
[23:41] <maco> why does http://package-import.ubuntu.com/ not include karmic packages yet?
[23:49] <james_w> maco: we are transferring over to LP, and trying to keep two imports going at the same time was too much
[23:50] <maco> oh
[23:50] <james_w> sorry if that confused you
[23:50] <maco> james_w, is nothing going into import or is it that stuff-on-lp isnt in import?
[23:51] <james_w> stuff-on-lp is new branches
[23:51] <james_w> which will include Debian as well, so they don't share revision history
[23:51] <james_w> so it wasn't just a case of pushing to two places
[23:54] <mathiaz> james_w: what's the state of the branches actually?
[23:54] <james_w> the LP ones are starting to appear
[23:55] <mathiaz> james_w: where can I find them?
[23:55] <james_w> we've got what is apparently an LP problem to try and diagnose, but we're pretty much at the point where it's just a case of churning through the packages to import them
[23:55] <james_w> https://code.launchpad.net/~ubuntu-branches houses them all
[23:56] <james_w> you can also get to branches from a package from https://code.launchpad.net/<distro>/<distroseries>/+source/<sourcepackagename>
[23:56] <james_w> the other overview pages are coming
[23:57] <redvamp128> Okay developers- I have a rather strange issue that involves enlightenment(opengeu) and gnome- I have looked for a room on this and there is none (this is a default 8.04 install)
[23:58] <redvamp128> I can sign into the window manger just fine-- and then sign back into my gnome-- and it put shortcuts to drives on my default desktop
[23:59] <redvamp128> It uses thunar-- but why does it not do that when I use the XFCE but does that with that D-E (window manger) any clues?


[02:44] <sbalneav> Evening all
[03:08] <stgraber> evening sbalneav
[04:53] <sbalneav> stgraber: Got a minute? I'd like an opinion.
[05:14] <stgraber> sbalneav: sure
[05:15] <stgraber> sbalneav: sorry for the delay, was writting a blog post for the bug day
[05:23] <sbalneav> NP, so I've been hacking around tonight with pam-sshauth.
[05:24] <sbalneav> I think I've settled on what I want to do, but I just want an opinion as to if this seems sane or not.
[05:24] <sbalneav> So, we use libssh for authentication, and handling the password change.
[05:25] <sbalneav> but once we've done the auth, rather than duplicate a bunch of code, seems to me the best thing to do would be to spawn off just an ssh, using the password we've just gotten.
[05:26] <sbalneav> seeing as how it's a pam module, we shouldn't need to worry about the ssh's password expiring, since if it DID expire, we would have just handled that.
[05:26] <sbalneav> so theoretically, by the time we drop to handling the session part, we can just do the ssh hostname, an pass the password we've gotten.
[05:27] <sbalneav> and the spawned ssh will handle the x11 and command socket stuff.
[05:32] <stgraber> hmm, wouldn't that block PAM in some way ?
[05:33] <stgraber> it'd perfectly be fine to have a module option to keep the SSH in the background and have a master socket created
[05:33] <stgraber> so we can then use that to do whatever we want and that will still act just like a regular PAM module
[05:34] <stgraber> so if someone uses that module for authentication on his laptop against one of his company's ssh server, he'll still get a local console and not a remote one and if wanted he'd also get access to a SSH control socket so he doesn't need to authenticate again for that SSH server.
[21:09] <nixternal> http://blog.lydiapintscher.de/2010/01/10/kde-edu-irc-meeting-and-release-parties/
[21:10] <nixternal> KDE-Edu team is having an irc meeting at 20:00 UTC on January 14th in #kde-edu here on Freenode for those that might be interested


[12:14] <robertj> Amaranth: thanks, http://ftp-master.debian.org/REJECT-FAQ.html sheds some light on what that phase is for. I assume packes in NEW are reviewed periodically without the need for poking?
[12:15] <Amaranth> i think so
[12:15] <Amaranth> most people poke though
[12:17] <robertj> so who is the most-chosen victim of such attention?
[12:18] <crimsun> robertj: yes, they are.
[12:19] <robertj> so err, don't poke?
[12:19] <crimsun> correct, unless it's a critical package
[12:21] <robertj> ok, no-pokey pokey
[01:59] <jadaz87> hello everyone i was wondering if there is a list somewhere of every package that is installed by default for the ubuntu server distro
[02:00] <Burgundavia> jadaz87: see the seeds, http://people.ubuntu.com/~cjwatson/seeds/
[02:00] <jadaz87> ahh thanks Burgundavia
[02:01] <Burgundavia> jadaz87: no worries
[02:01] <jadaz87> Burgundavia: and it has everything categorized thanks
[02:06] <jadaz87> Burgundavia: may i pm you?
[02:06] <Burgundavia> sure
[02:08] <LaserJock> the seed are also on LP
[02:09] <LaserJock> I'm not sure if they are kept in sync with ^^ or not
[03:33] <warpup_lite> hmm
[03:35] <sistpoty> mjg59: thanks for the feedback on debian/copyright issue... I'll overhaul parts of the FAQ (tomorrow, it's 3.30 here)
[03:35] <warpup_lite> debian copyright?
[03:37] <sistpoty> warpup_lite: see the ubuntu-motu mailing list at lists.ubuntu.com
[04:11] <warpup_lite> i don't have an account at lists.ubuntu.com
[04:12] <infinity> slomo: Done.
[04:12] <bddebian> Heya infinity
[04:21] <Hobbsee> warpup_lite: make one?
[04:22] <sistpoty> mjg59: sorry for last highlight, mixed up nicks here
[04:23] <mjg59> sistpoty: No problem :)
[04:25] <Hobbsee> hi mjg59, and everyone else
[04:30] <mjg59> Oh my god I've been in a converted warehouse and there was loud music and it was entirely I WANT IT TO LOOK JUST LIKE THIS
[04:31] <bddebian> heh
[04:31] <mjg59> jdub: totally
[04:31] <mjg59> We need to bring GUADEC people her next year
[04:31] <mjg59> (I'm in Wolverhampton, which is about 20 minutes from Birmingham)
[04:32] <mjg59> AND YES, IT'S IN THE MIDLANDS
[04:32] <Hobbsee> heh...hi jdub
[04:32] <jdub> morning Hobbsee
[04:33] <jadaz87> repos down?
[04:33] <mjg59> jdub: We watched Jono shave his beard. It was touching.
[04:33] <jdub> mjg59: WHO was touching?
[04:33] <bddebian> jadaz87: Just US afaik
[04:33] <jadaz87> bddebian: oh ok
[04:34] <mjg59> jdub: Bastian
[04:34] <mjg59> Damned Frenchmen
[04:36] <mjg59> Hrm.
[04:36] <mjg59> One of these lightswitches makes the room go dark, the other does nothing
[04:37] <LaserJock> bddebian: I think CA is also down
[04:37] <bddebian> Oh really?  Hmm
[04:39] <Burgundavia> bddebian: ca has been having issue for a while now
[04:40] <bddebian> Well I know that, but I didn't know their archive was having problems.. ;-P
[04:43] <bddebian> Burgundavia: Uh-oh, are you from Canukistan? ;-)
[04:43] <Burgundavia> bddebian: well, lets just say that ubuntu.ca and my home machine resolve to the same IP address
[04:44] <bddebian> Doh :-)
[04:47] <mjg59> Oh christ Linus is sending me bug reports
[04:48] <Burgundavia> mjg59: aren't you special
[04:48] <LaserJock> mjg59: are they good?
[04:48] <bddebian> Heh
[04:51] <mjg59> He's absolutely right - everything only works by accident and we're doomed to death
[04:52] <bddebian> Hmm, joyful outlook
[04:54] <mjg59> It's possible that I should have waited until I was sober
[04:57] <Burgundavia> mjg59: nah, that makes things less fun
[04:57] <Burgundavia> hey js
[04:57] <Burgundavia> jsgotangco, that is
[04:58] <jsgotangco> that is?
[04:58] <mjg59> Burgundavia: But dude, it's Linus
[04:59] <LaserJock> mjg59: maybe he was less than sober when you reported the bug so you are even :-)
[04:59] <LaserJock> *he reported
[05:00] <mjg59> LaserJock: Well, ther were capitals...
[05:01] <LaserJock> uh oh
[05:01] <mjg59> From Linus, not me
[05:52] <jadaz87> hmm it seems the repos errors are only for some people
[05:53] <Burgundavia> jadaz87: uhh?
[05:54] <jadaz87> Burgundavia: i tried sudo apt-get update
[05:54] <jadaz87> and it times out
[05:54] <jadaz87> the first couple go through though
[05:54] <Burgundavia> you using the US or CA repos?
[05:55] <jadaz87> Burgundavia: how can i tell?
[05:55] <jadaz87> Burgundavia: probably the us since i am in NJ
[05:55] <Burgundavia> check your sources.list
[05:55] <Burgundavia> move off the us repos, they have had issue for a while now
[05:56] <jadaz87> Burgundavia: oh ok thanks
[05:56] <jadaz87> :)
[06:00] <jadaz87> interesting does the same thing
[09:48] <davyd> hi all
[09:49] <davyd> has anyone noticed problems with NetworkManager in edgy?
[10:34] <ploum> I think that we really need python-sexy in Edgy
[10:34] <ploum> (python bindings for libsexy)
[10:34] <ploum> Ok, I admit...
[10:34] <ploum> I need them...
[11:55] <lfittl> ploum: please link to the debian rfp when you add it on https://wiki.ubuntu.com/MOTU/Packages/Candidates, thanks
[11:55] <ploum> lfittl: It was not yet listed
[11:56] <ploum> I plan to add the link when it will appear
[11:56] <lfittl> ploum: oh, k :)
[12:24] <Espenfjo> Is there a changelog somwhere? A place i can see what packages have been changed, and why? Mainly in Edgy
[12:26] <Gloubiboulga> Espenfjo, the edgy-changes ML
[12:27] <Gloubiboulga> you can browse the archives
[12:27] <Espenfjo> ok
[12:30] <ulaas> i have a flashing apps menu
[12:30] <jsgotangco> that's known in edgy
[12:38] <ulaas> jsgotangco: thanx
[02:34] <Lathiat> hrm, problems with the websites?
[02:35] <Spads> Lathiat: We are aware of the problem and are working on it.
[02:35] <Lathiat> heh your subnet isnt even in the global route table
[02:35] <Lathiat> awesome :)
[03:06] <sivang> Spads: you the new web master? :)
[03:06] <Hobbsee> sivang!!!!
[03:06] <Spads> sivang: no, not exactly
[04:06] <bddebian> Howdy
[04:29] <bddebian> Uhm, I know some of the archive machines are having problems, but are other machines having issues today?  I can't get to changelogs.u.c..??
[04:30] <shenki> the datacentre is down, apparantly
[04:30] <bddebian> Eeks
[04:30] <shenki> "Spads> shenki: It's a known problem, and we're working on it."
[04:31] <bddebian> Thx shenki
[04:31] <shenki> np
[04:31] <zealot> Can anyone give me an idea of why *ubuntu.com is down? I'm just curious...
[04:31] <shenki> heh
[04:31] <zealot> Did they have a powerfailure in the datacenter or something?
[04:31] <Hobbsee> argh, what'd i miss?
 the crappy ubuntu servers got h4x0red
[07:08] <bluefoxicy> confirm/deny
[07:09] <Spads> Deny.
[07:09] <HiddenWolf> bluefoxicy: they got beamed up by martians
[07:13] <Spads> bluefoxicy: on point of fact, our servers are now more secure than ever
[07:14] <bluefoxicy> what does that mean, stack smash protection everywhere?  Don't say you installed openBSD.
[07:15] <jdub> electricity is *SO* insecure.
[07:15] <HiddenWolf> Spads: yeah, you can't hack em while offline. ;)
[07:15] <Spads> HiddenWolf: exactly :)
[07:16] <HiddenWolf> jdub: it's a blackout?
[07:17] <thom> jdub: http://www.ipapp.com/broadband.html ;P
[07:17] <bluefoxicy> having the power out is not secure
[07:17] <bluefoxicy> it totally drops availability.
[07:17] <jdub> thom: especially that kind!
[07:18] <bluefoxicy> so what this is a case of somebody needing to set up redundant power in the server facility?
[09:24] <robertj> so who was it that tripped over the plug :)
[09:25] <HiddenWolf> Someone without the muscle to put that big heavy plug back in. ;)
[09:26] <Chipzz> network problems guys?
[09:26] <robertj> bunch of former employees leave to form own initiatives...ISP goes down for "unknown" reasons...convenient eh? :)
[09:26] <Chipzz> archive.ubuntu.com (<IP_ADDRESS>) is unreachable
[09:26] <Chipzz> so is security.ubuntu.com (<IP_ADDRESS>)
[09:27] <HiddenWolf> and launchpad.net
[09:27] <HiddenWolf> and markshuttleworth.com
[09:27] <HiddenWolf> and the forums, kubuntu, xubuntu, edubuntu
[09:27] <HiddenWolf> etc. :)
[09:27] <Chipzz> trace seems to die somewhere in the UK (from here)
[09:28] <robertj> not markshuttleworth.com!
[09:29] <HiddenWolf> It's terrible
[09:30] <Spads> We do have staff on-site and are working on the problem
[09:30] <Spads> Unfortunately, it is largely out of our control at the moment.
[09:30] <Chipzz> Spads: thx
[09:31] <Chipzz> Spads: what do you mean with "out of our control"?
[09:31] <Spads> Chipzz: it's not a problem in our cage
[09:31] <Spads> Chipzz: the outage affects many other customers, and it could take a while to meet everyone's needs
[09:32] <Chipzz> Spads: ok :)
[09:33] <Chipzz> Spads: so what is the staff doing on-site if it's a problem with the hosting company? ;)
[09:33] <HiddenWolf> Spads: is it the isp?
[09:33] <zul> maybe trying to help
[09:34] <Chipzz> zul: I work for a company that does hosting in 4 datacenters; I think they would rather be in the way than help
[09:35] <Spads> I haven't spoken to them in a few hours, but I would guess that there's a lot of waiting involved.  When things do come back on-line, there will definitely be a scramble to shepherd things back to normal.
[09:35] <ozamosi> Is there any kind of link that contains info from the hosting company or something like that, that I can show the people that says "ubuntu's been hacked!"
[09:36] <Spads> ozamosi: alas, no.  I'd love one myself.
[09:36] <zul>                  company or something like that, that I can show the people
[09:36] <zul> whoops
[09:37] <Spads> haha
[09:37] <Spads> ooh
[09:37] <Spads> strike a light...
[09:37] <Chipzz> Spads: is it a problem with power or with the network link?
[09:38] <Spads> our systems are beginning to appear again.  Please be gentle, as they're likely to be hammered for a little while.
[09:38] <HiddenWolf> ozamosi: there is a notice upon entering #ubuntu that explains that the servers are out.
[10:37] <Spads> Chipzz: as jdub hinted at, it was a catastrophic power failure in our DC building.
[10:50] <Qwell> Are you guys aware of any (unreported?) bugs relating to the partition tool hanging during install on a Niagara?
[10:51] <Qwell> It happens literally every time...