[03:20] <Amaranth> tjaalton: wtf, DRI2 doesn't support sync to vblank? I thought intel wanted to have everything do sync to vblank
[03:30] <e1z0_> hi
[04:55] <kees> Keybuk: hrrrm.  I encountered an md/udev race failure this morning on reboot.  one of my raids wasn't all the way up (1 dev of 2), yet the 2nd (missing) device existed.  seems like md's incremental bring-up failed.
[04:56] <kees> rebooted again and it went away (didn't get unlucky that time)
[06:01] <Arkain> exit
[07:03] <pitti> Good morning
[07:04] <dholbach> good morning
[07:07] <dholbach> does anybody know what do do about  http://paste.ubuntu.com/132328 ?
[07:45]  * maxb wonders if this FTBFS error means anything to anyone - is it just skew in arch-all vs arch-specific dependencies getting published? - http://launchpadlibrarian.net/23960162/buildlog_ubuntu-jaunty-amd64.totem_2.26.0-0ubuntu1_FAILEDTOBUILD.txt.gz
[07:45] <maxb> (likewise lpia, ia64, ftr)
[07:47] <RAOF> How old is that log?  libgtk2.0-0 >= 2.15.0 should have been satisfiable for some time.
[07:47] <maxb> less than 12 hours old
[07:47] <RAOF> Oh.  Don't mind me.  I can't read properly.
[07:49] <maxb> likewise gnome-panel and evolution-data-server - though it seems gnome-panel/amd64 may have been given back already
[07:49] <slytherin> maxb: yes, it looks like the skew in publishing.
[07:54] <maxb> Oh, e-d-s is all successfully built now
[08:05] <slytherin> who maintains the package human-icon-theme? There is a small problem in that package which is too small to file a bug.
[08:06] <pitti> slytherin: what's the problem?
[08:06] <slytherin> pitti: typo in filename - ./scalable/apps/gnome-session-hebirnate.svg
[08:13] <pitti> slytherin: uploaded
[08:14] <slytherin> pitti: thanks
[08:16] <maxb> What is the right channel to suggest give-backs? here?
[08:16] <tjaalton> maxb: probably so, yes
[08:17] <slytherin> maxb: depends on the component, main/restricted here, universe/multiverse in #ubuntu-motu
[08:17] <maxb> If so: https://launchpad.net/ubuntu/+builds?build_text=totem&build_state=all and https://launchpad.net/ubuntu/+builds?build_text=gnome-panel&build_state=all <-- totem/{amd64,ia64,lpia}, gnome-panel/{ia64,lpia}, all appearing to be fails due to publishing skew
[08:21] <tjaalton> maxb: given back
[08:22] <maxb> thanks
[08:23] <maxb> tjaalton: launchpad doesn't seem to agree that gnome-panel/lpia has been given back. The other 4 are, though
[08:23] <maxb> oh, now it does
[08:23] <maxb> caching, I suppose
[08:25] <tjaalton> nah, just forgot to apply :)
[08:25] <tjaalton> too many tabs
[08:26] <bryce> how does one make a bash script translatable?
[08:27] <bryce> #!/bin/bash
[08:27] <bryce> echo "Hello world"
[08:27] <bryce> is there a way to turn that into something that can be translated?
[08:27] <slytherin> seb128: good morning
[08:28] <ion_> bryce: I have a faint memory of seeing some sh script use gettext.
[08:28] <bryce> so like
[08:28] <bryce> echo $(gettext "Hello world")
[08:28] <bryce> ?
[08:29] <seb128> hey slytherin
[08:30] <ion_> bryce: . /usr/bin/gettext.sh; eval_gettext foo probably.
[08:30] <slytherin> seb128: bad news, all the updates installed, dvd playback didn't work for me last night.
[08:30] <seb128> slytherin: not really bad news so you can still debug it ;-)
[08:31] <seb128> slytherin: I will try on my desktop when 2.26 updates are done
[08:32] <slytherin> seb128: sure, I will upload my modified package to my ppa tonight so that you can do the analysis whenever you get time. I am not very good at C and autotools
[08:32] <seb128> ok thanks
[08:36] <bryce> ion_: thanks
[08:37] <ion_> bryce: You probably already noticed this, but the eval_ variants substitute shell-style variables in the strings from caller’s environment. If that is not needed or wanted, just use gettext directly.
[08:39] <bryce> ion_: yep, thanks
[08:47] <taavikko> seb128: any info if vino can use ssh-keys only to authorize usage on remote-desktop?
[08:48] <seb128> taavikko: no idea I never tried that
[08:48] <taavikko> vino used to have it IIRC in intrepid.. Now only password for security
[08:49] <taavikko> might as well check changelogs and such to figure it out, there's nothing like added security...
[09:05] <directhex> slangasek, i'm thinking i'd like to put off this docdir problem for another cycle - i.e. merge mono, and re-add the symlink magic so the issue goes away until karmic
[09:18] <directhex> i'd need to maintain SOME kind of workaround up until loquatious lombax anyway, since i need to support upgrades from hardy. so the first release where it stops mattering is masticating mastodon.
[09:23] <DreadKnight> updates ate my totem :O
[09:24] <slytherin> DreadKnight: what do you mean by ate?
[09:24] <directhex> om nom nom
[09:26] <DreadKnight> totem got removed.. and many more stuffs will get removed as well if i update.. i guess dependencies need to be sorted out
[09:27] <slytherin> DreadKnight: dependencies are fine. you upgraded in the middle of large uploads related to gnome
[09:27] <DreadKnight> slytherin, indeed
[09:28] <slytherin> DreadKnight: so wait for another day by when these uploads will be finished probably.
[09:30] <DreadKnight> ok thanks
[10:43] <pitti> thekorn: thanks for your reply wrt. wadllib and nose; nose fixed now
[10:43] <pitti> thekorn: however, now I have bug 344166 :-(
[10:53] <thekorn> pitti: this smells indeed like just another python2.6 incompatibility
[10:53] <pitti> thekorn: right; just followed up on the bug
[10:53] <thekorn> time.struct_time == tuple does not seem to work anymore
[10:54] <pitti> right, time.localtime() is the same effect
[10:55] <pitti> thekorn: I think I'll just update the docstring accordingly
[10:56] <thekorn> sounds good
[10:57] <pitti> thekorn: ah, with print() it works
[10:58] <pitti> ah, no, ignore me
[11:05] <thekorn> pitti: maybe tuple(d.timetuple()) works for all python versions
[11:05] <thekorn> can't check python2.6 here
[11:05] <pitti> thekorn: ah, indeed
[11:13] <MacSlow> mvo_, hey Michael
[11:13] <MacSlow> mvo_, this one https://bugs.edge.launchpad.net/ubuntu/+source/notify-osd/+bug/331564 is due to the missing patch for notify-osd to be part of the window-match rules for the animation-plugin
[11:14] <MacSlow> mvo_, did you have to drop my patch I sent you, because it didn't apply anymore?
[11:14] <MacSlow> mvo_, I can redo it, if you want and send you the new one
[12:04] <Mirv> could someone review https://code.launchpad.net/~timo-jyrinki/example-content/folder_i18n/+merge/4416 before beta freeze, since it's a biggish change in how the package is built?
[12:07] <tkamppeter> Can someone please fix the e-mail notification of Rosetta? I get 66 spam mails on every upload of system-config-printer.
[12:08] <cjwatson> tkamppeter: you're not the only one waiting for a fix, and this channel is not empowered to fix it
[12:08] <cjwatson> the fix has landed in trunk and we're waiting for a rollout
[12:12] <wgrant> cjwatson: Why wasn't it cherrypicked? There's still two weeks until the next release...
[12:12] <elmo> wgrant: asking the wrong people
[12:12] <tkamppeter> cjwatson, OK. Then I know that it will be fixed soon.
[12:13] <dholbach> Mirv: I just had a look at your example-content branch - is there an easy way to test this on a livecd?
[12:14] <wgrant> elmo: Well, he seemed well informed of the situation otherwise.
[12:16] <cjwatson> wgrant: I know little more than the above and have already been badgering people
[12:18] <mvo_> MacSlow: I will double check, it should not be dropped, but patches where shuffled around due to the 0.8.2 release
[12:19] <Mirv> dholbach: the live cd part is afaik not affected really, since that's only about installing the /etc/skel file which gets installed on users' home folders. I guess the live cd symbolic link on the desktop is not done by example-content, so the original title of the bug is a bit wrong.
[12:20] <Mirv> (which leads me to update the bug title to something more sophisticated, though it's explained in the comments)
[12:20] <cjwatson> Mirv: casper does     mv /root/home/$USERNAME/Examples /root/home/$USERNAME/Desktop/
[12:21] <dholbach> Mirv: ah right, so it might need changing in casper
[12:21] <cjwatson> Mirv: therefore it would need to be updated if Examples changed
[12:21] <cjwatson> (preferably in a way that copes with both old and new)
[12:21] <Mirv> cjwatson: ok, so it should be updated in casper as well then, if that symbolic link is now changed into examples.desktop
[12:21] <dholbach> cjwatson: Mirv's idea was to change to a translatable .desktop file instead of a symlink to the directory
[12:23] <Mirv> I now updated the description to include what casper does, and that it would also need updating if examples.desktop is used
[12:23] <cjwatson> dholbach: yes, I read it
[12:23] <dholbach> ok
[12:26] <Mirv> and in the bug report there is this link to the change in use: http://launchpadlibrarian.net/23784986/Kuvakaappaus-test%20-%20tiedostoselain.png (icon could be changed if the default link icon is not wanted)
[12:27] <cjwatson> I haven't reviewed the branch but assuming that casper is changed as well then it all makes complete sense to me
[12:29] <dholbach> Mirv: I'll play with it some more and let you know what I find
[12:49] <ogra> Keybuk, so i still see a 11sec modprobe run in my bootchart in jaunty (making my boot take 33sec)
[12:50] <ogra> Keybuk, http://people.ubuntu.com/~ogra/osiris-jaunty-20090317-1.png
[12:55] <Keybuk> ogra: could you throw me the tarball and udev log?
[12:56] <ogra> Keybuk, sure
[12:57] <ogra> Keybuk, http://people.ubuntu.com/~ogra/osiris-jaunty-20090317-1.tgz and http://people.ubuntu.com/~ogra/udev
[12:57] <ogra> Keybuk, i see a long pause in the early stage of usplash
[12:58] <ogra> which seems to match the udev/modprobe delay shown in the bootchart
[12:59] <Keybuk> add      /devices/pci0000:00/0000:00:1d.2/usb5/5-1/5-1:1.0/0003:1CB6:6680.0003 (hid)                                              0.45  10.63  10.19
[12:59] <Keybuk> add      /devices/pci0000:00/0000:00:1d.2/usb5/5-1/5-1:1.0 (usb)                                                                  0.02  10.63  10.61
[12:59] <Keybuk> add      /devices/pci0000:00/0000:00:1d.2/usb5/5-1/5-1:1.0/usb_endpoint/usbdev5.2_ep81 (usb_endpoint)                             0.02  10.63  10.61
[13:00] <Keybuk> what's the device?
[13:00] <Keybuk> could you give me the modalias of it
[13:00] <Keybuk> (ie. cat /sys/blah/modalias)
[13:01] <ogra> Keybuk, like that ? ogra@osiris:/var/build/babbage$ cat /sys/bus/usb/devices/5-1\:1.0/modalias
[13:01] <ogra> usb:v1CB6p6680d0100dc00dsc00dp00ic03isc00ip00
[13:02] <ogra> i have a usb mouse and usb kbd plugged in atm ... additionally the laptop has a touchscreen and fingerprint reader that are usb devices
[13:02] <Keybuk> 11.63..22.15  1680 (modprobe)
[13:02] <Keybuk> it's a single modprobe call
[13:03] <ogra> oh, and a usb->serial adapter
[13:03] <Keybuk> hmm
[13:03] <ogra> but neither of them takes 10 secs when hotplugged
[13:03] <ogra> (touchscreen and fingerprint reader are indeed not hotpluggable :) )
[13:04] <Keybuk> is there a /sys/devices/pci0000:00/0000:00:1d.2/usb5/5-1/5-1:1.0/0003:1CB6:6680.0003/modalias ?
[13:07] <ogra> Keybuk, ogra@osiris:/var/build/babbage$ ls /sys/devices/pci0000\:00/0000\:00\:1d.2/usb5/5-1/5-1\:1.0/0003\:1CB6\:6680.0003/
[13:07] <ogra> driver  power  subsystem  uevent
[13:09] <Keybuk> ogra: what about the other two?
[13:10] <Keybuk> ogra: what's the driver symlink expand to?
[13:10] <ogra> ogra@osiris:/var/build/babbage$ cat /sys/devices/pci0000\:00/0000\:00\:1d.2/usb5/5-1/5-1\:1.0/modalias
[13:10] <ogra> usb:v1CB6p6680d0100dc00dsc00dp00ic03isc00ip00
[13:11] <ogra> ogra@osiris:/var/build/babbage$ ls -lh /sys/devices/pci0000\:00/0000\:00\:1d.2/usb5/5-1/5-1\:1.0/0003\:1CB6\:6680.0003/driver
[13:11] <ogra> lrwxrwxrwx 1 root root 0 2009-03-17 13:44 /sys/devices/pci0000:00/0000:00:1d.2/usb5/5-1/5-1:1.0/0003:1CB6:6680.0003/driver -> ../../../../../../../bus/hid/drivers/generic-usb
[13:11] <ogra> no modalias in /sys/devices/pci0000\:00/0000\:00\:1d.2/usb5/5-1/5-1\:1.0/usb_endpoint/usbdev5.2_ep81/
[13:14] <ogra> Keybuk, ah, lshal seems to tel mee its the touchscreen
[13:15] <Keybuk> yeah, that's what it looks like to me
[13:15] <ogra> which has no particular driver, it just registers as /dev/input/eventX with the hid driver normally
[13:15] <Keybuk> you're stuck inside kernel driver init() at that point
[13:15] <ogra> (at least it did that up to intrepid)
[13:15] <Keybuk> so iz kernel bug
[13:16] <Keybuk> to test
[13:16] <Keybuk> echo 'KERNEL=="0003\:1CB6\:6680.0003", OPTIONS+="last_rule"' > /etc/udev/rules.d/00-ignore.rules
[13:16] <Keybuk> see if that speeds it up
[13:16] <Keybuk> without the \:s
[13:16] <Keybuk> echo 'KERNEL=="0003:1CB6:6680.0003", OPTIONS+="last_rule"' > /etc/udev/rules.d/00-ignore.rules
[13:18]  * ogra reboots
[13:18] <ogra> Keybuk, err, i guess i need update-initramfs, right ?
[13:19] <Keybuk> no, shouldn't do
[13:19] <ogra> ok
[13:22] <ogra> ehmmm
[13:22] <ogra> since when is my computer supposed to skip the bios on reboots ?
[13:22] <ogra> my machine just went from usplash in shutdown mode directly to usplash in bootup mode without powering off
[13:23]  * ogra tries again
[13:25] <ogra> hmm, i'm confused
[13:25] <ogra> same behavior
[13:25] <Keybuk> try different udev rules to match the device
[13:25] <Keybuk> it may be any of those three
[13:25] <Keybuk> or even all of them
[13:25] <ogra> well, first i would like to be able to switch off my computer
[13:26] <ogra> it just jumps from one usplash to another and boots up directly ... there is no BIOS or power down inbetween
[13:26]  * ogra scratches head
[13:27] <ogra> oh, ah !
[13:27]  * ogra apt-get removes kexec-tools :P
[13:28] <ogra> thats funny ... i didnt know it had that effect
[13:28] <hyperair> seb128: ping.
[13:28] <ogra> ok, next try
[13:28] <seb128> hyperair: contextless ping = no pong
[13:28] <hyperair> seb128: that's pong enough for me ;)
[13:29] <hyperair> seb128: regarding nautilus-share... you've added some stuff to debian/rules
[13:29] <hyperair> seb128: something about intltool. could you tell me what that's about?
[13:29] <hyperair> seb128: examining the debs with/without the intltool stuff seems to show no difference
[13:30] <seb128> hyperair: it's about building a translation template after the build which rosetta imports
[13:30] <seb128> hyperair: so the strings are listed on rosetta for translation
[13:30] <seb128> hyperair: we do that for everything in main actually, why?
[13:30] <hyperair> seb128: i just adopted nautilus-share in debian, and am updating
[13:31] <hyperair> seb128: this is one of the things i'm not sure about. the other is that your diff.gz seems to have config.guess/config.sub changes. why is that?
[13:31] <seb128> hyperair: cdbs magic I guess
[13:31] <seb128> that's a debian thing
[13:32] <seb128> the clean target might be buggy or something
[13:32] <hyperair> seb128: no... it seems that it's an ubuntu-only change
[13:32] <ogra> Keybuk, hmm, the one rule didnt change a thing
[13:32] <seb128> hyperair: it's nothing we did it's coming from the build system, as said probably buggy clean target
[13:32] <seb128> hyperair: try to debuild && debuild clean && debuild in debian
[13:32] <seb128> hyperair: and see if you get the same
[13:33] <seb128> hyperair: debian build tools update those when they are outdated
[13:33] <hyperair> regarding the clean target, i found a snippet in clean which does that
[13:33] <seb128> well dunno and I don't care
[13:33] <seb128> config.guess and config.sub has updated at build time using the system version if outdated
[13:33] <hyperair> http://pastebin.com/f47525987
[13:33] <seb128> that change is just noise, not useful not creating an issue
[13:34] <hyperair> okay then i'll leave it out
[13:34] <seb128> I don't care enough to look at why it's there ;-)
[13:34] <seb128> it's not an on purpose change
[13:34] <seb128> but it's not an issue
[13:34] <seb128> you can take the intltool update call though
[13:34] <ogra> Keybuk, is there a way to match on "product" ?
[13:34] <seb128> it's not useful in debian but doesn't cost a lot
[13:34] <seb128> and so we can probably sync or lower delta
[13:35] <hyperair> seb128: alright then.
[13:37] <ogra> Keybuk, or on something shorter (like 0003:1CB6 only)
[13:46] <ogra> Keybuk, nope, no speedup
[14:21] <unCONDITIONAL> yo
[14:22] <directhex> that was productive :|
[14:59] <jelmer> slangasek: ping
[15:44] <tvakah> I'm having a problem upgrading, dpkg --purge sivp results in: http://pastebin.com/f34bb92f1
[15:45] <tvakah> adding --force-all changes nothing, and this package is currently sticking all the rest of today's updates
[15:46] <tvakah> tried force installing scilab first in the thought that sivp needed to go first, scilab installs and purges jsut fine, but sivp still fails to purge
[15:49] <tvakah> nvm, looks like upgrading sivp to 0.5 first then removing it will fix this
[16:02] <BUGabundo> question: is update-manager supposed/able to jump from hardy to jaunty or any other future devel branch without going throuth all versions in between ?
[16:03] <pitti> BUGabundo: LTS->LTS only, or going through all intermediate releases
[16:06] <BUGabundo> pitti: thants
[16:09] <pitti> tseliot: jockey currently disables nvidia 71 and 96; are they still busted?
[16:10] <tseliot> pitti: 96 works while 71 doesn't
[16:10] <pitti> tseliot: right, it checks "version < 96", sorry
[16:10] <pitti> so it's still correct; thanks
[16:10] <tseliot> pitti: np
[16:15] <slangasek> jelmer: pong
[16:17] <bdmurray> cjwatson, pitti: wrt to the bug fixing report I did fix an issue last week where duplicate bug tasks were being shown, perhaps that caused the change in quantity.
[16:17] <cjwatson> ah, that would make sense
[16:20] <doko> ubuntu-archive: please accept the xom binaries in NEW
[16:26] <pitti> bdmurray: ah, entirely plausible; thanks
[16:26] <bdmurray> let me know if you see any other drastic changes
[16:27] <pitti> so now I have to break the 150 mark a second time :)
[16:29] <bdmurray> some fluxuation due to bugs being reopened is possible but not a lot
[16:38] <pitti> doko: thanks for fixing xom!
[16:41] <doko> pitti: openjdk error, just a work around
[16:45] <rtg> bryce: bug #334101 isn't really targeted to the right packages, is it?
[16:50] <bryce> rtg: what would be the right packages?
[16:50] <rtg> bryce: well maybe the package is correct, but why is my name assigned to it?
[16:54] <asac> TheMuso: ping at-spi crash status? are there concerns with my patch?
[16:59] <bryce> rtg: do you not use bug assignments for tracking bugs you're working on?  I can remove your name if it's a problem...
[17:00] <rtg> bryce: I just keep getting all of these annoying emails about it :)
[17:00] <bryce> rtg, sorry I know each team does things a bit differently, so may be assuming things
[17:00] <rtg> bryce: well, my patch part is done, right?
[17:01] <pitti> rtg: how else do you keep track of them, if not by email?
[17:01] <rtg> pitti: my oblique point was that my name should not have been on this bug 'cause I don't have anything to do with (I think)
[17:01] <rtg> with it
[17:02] <MacSlow> mvo_, compiz uses quilt, right?
[17:02] <pitti> ah, ok; I thought you wanted to merge the kernel bits
[17:02] <bryce> rtg: this is the bug I've been using for tracking the r6xx/r7xx patch work stuff from Alex
[17:02] <bryce> rtg: if you've uploaded those, then yeah the bug can be closed as fixed.  I'll take your name off too, to save you from any subsequent emails
[17:03] <rtg> bryce: no, you're correct. I thought it was being tracked by another bug, but I see that I completely messed up.
[17:04] <bryce> rtg: fwiw, when we do uploads in the X team, we typically need a bug report for the issue being fixed to reference in the changelog
[17:04] <mvo_> MacSlow: yes
[17:04] <bryce> rtg: so I was just thinking we could share this one, assuming you guys do similarly in kernel land (which may be a bad assumption on my part)
[17:04] <rtg> bryce: during the dev process i don't always have a bug number, but I should have for this one.
[17:05] <mvo_> MacSlow: "bzr bd-do " and then "export QUILT_PATCHES=debian/patches; quilt push 029_default_options"
[17:05] <MacSlow> mvo_, ok I'll try to create a distro patch for the fade-plugin (which is part of compiz) to skip notify-osd windows if it is enabled
[17:05] <bryce> ok cool
[17:05] <mvo_> MacSlow: that should do the trick
[17:05] <mvo_> MacSlow: and quilt add metadata/fade.xml.in afterwards
[17:05] <mvo_> MacSlow: when you finished editing "quilt refresh"
[17:05] <mvo_> quilt pop -a
[17:05] <mvo_> exit
[17:05] <mvo_> :)
[17:06] <mvo_> sorry, quilt is a bit "verbose"
[17:06] <pitti> MacSlow: https://wiki.ubuntu.com/PackagingGuide/PatchSystems#quilt%20(example%20package:%20xterm) FYI
[17:06] <MacSlow> bzr bd-do didn't work
[17:06] <davmor2> bryce: I've confirmed the fix for bug 309482 but I think it's linked to upstream too so do you still want it closing?
[17:06] <MacSlow> mvo_, I'm using an apt-get'ed compiz-source not a checked out branch
[17:06] <MacSlow> this is gonna take long then I think
[17:08] <MacSlow> pitti, ah... that was what I was looking for
[17:08] <rtg> bryce: I can see now why my comment confused you. I guess I need some coffee :) I updated the report, but the bot won't update with a changelog 'cause I don't have a  bug number in the changelog.
[17:08] <bryce> davmor2: yep, bug looks fine.  Upstream can pick up the patch from the upstream report whenever they'd like
[17:08] <MacSlow> pitti, I remember to have read this once (about a year ag0)
[17:09] <bryce> rtg: ah ok, then we can close it manually.  Do you have any comment to add?  If not I'd be happy to do the deed.
[17:09] <pitti> rtg: ah, so 2.6.28-10 has the ati bits now? awesome
[17:09] <rtg> bryce: I added the commit URL, beyond that I don't have anything more to say
[17:09] <bryce> ok great
[17:09] <rtg> p-itti-11 bits
[17:09] <rtg> pitti: -11
[17:10] <pitti> ah
[17:10] <rtg> which will get uploaded later today
[17:10] <elmo> cjwatson/wgrant/seb128/etc: the alleged LP fix for that rosetta spam has been CPed into production
[17:10] <pitti> yohoo!
[17:10] <mvo_> wonderful
[17:10]  * pitti shuts down his 10 extra mail servers :)
[17:11] <bryce> rtg: bug updated.  Thanks again :-)
[17:11]  * seb128 hugs elmo
[17:11] <MacSlow> mvo_, before I can successfully do "bzr bd-do" I've to "bzr branch lp:compiz" right? apt-get'ing compiz source will not get me the .bzr directory afaik
[17:11] <mvo_> MacSlow: correct
[17:12] <MacSlow> mvo_, I need to check that out _into_ the directory I got from "apt-get source compiz"?!
[17:12] <mrooney> mvo_: hello fellow michael :)
[17:14] <mvo_> MacSlow: no, just check it out and let bzr-buildpackage /bzr bd-do deal with all the rest :)
[17:14] <mvo_> hey mrooney!
[17:14] <pitti> bryce: can you please ping me when fglrx lands? then I'll re-enable it in jockey
[17:15] <cjwatson> elmo: great, thanks
[17:16] <bryce> pitti: will do.  Still waiting on the final drop from AMD, but expecting it today.
[17:16] <pitti> bryce: right, not hurrying, just saying that we should coordinate this
[17:16] <bryce> okie doke
[17:17]  * pitti ^5s bryce
[17:20] <Lure> MacSlow: https://wiki.ubuntu.com/Kubuntu/Ninjas/QuiltMagic
[17:20] <MacSlow> mvo_, done
[17:20] <MacSlow> mvo_, would it be enough to email you the updated file debian/patches/029_default_options ?
[17:21] <MacSlow> Lure, thanks but I already finished it
[17:21] <mvo_> MacSlow: yes, that is fine
[17:26] <MacSlow> mvo_, sent
[17:30] <mvo_> MacSlow: thanks, checking mail
[17:30]  * MacSlow takes an evening-break
[17:58] <mpt> MacSlow, mat_t: Do either of you know why the Jaunty live CD counts down at GDM, "ubuntu will log in in 10 seconds"?
[17:58] <mpt> It's not as if you can really do much else
[18:02] <ogra> mpt, i think thats a gdm restriction, autologin only works with timed login set, 10 sec is the smallest it accepts
[18:02] <ogra> mpt, seb128 might know more about that
[18:03] <mpt> hm, maybe I imagined it, but I thought the live CDs for previous Ubuntu versions skipped quickly past GDM
[18:03] <ogra> the first boot shouldnt show that
[18:03] <ogra> only if you manually logged out
[18:03] <seb128> mpt: it does autologin
[18:04] <mpt> yes it does
[18:04] <seb128> so what do you do to get the count?
[18:04] <ogra> doesnt count down here with an alpha6 image
[18:05] <seb128> here either
[18:05] <seb128> I did some CD testing for alpha6 and autologin worked correctly
[18:05] <superm1> Keybuk, i'm seeing some weird udev behavior while in the initrd when running casper early scripts w/ 9.04 a6 testing.  stuff like where a call to "chroot /root/ parted -s /dev/sda rm 3" will hang for a few minutes, followed by a line "udevadm settle - timeout of 180 seconds reached, the event queue contains:" "/sys/devices/virtual/vc/vcs12".  any pointers, or recommendations to prevent this happening?
[18:05] <ogra> though you get the countdown if you log out once
[18:05] <Lure> can somebody give-back pyexiv2 (now that exiv2 0.18 binaries are published)?
[18:06] <ogra> which is expected behavior (at least from former releases ... maybe not mpt expected behavior :) )
[18:06] <Keybuk> superm1: no idae
[18:06] <Keybuk> strange thing to hang on
[18:06] <doko> ubuntu-archive: please accept jaxme binaries in NEW (-doc to main)
[18:06] <Keybuk> what's in the process list?
[18:06] <Keybuk> otherwise udevd --debug ftw
[18:06] <mpt> seb128, I don't do anything special to get the count, I just choose "Try Ubuntu without any change to your computer" or whatever it's called
[18:06] <Keybuk> either that, or udevd has crashed ;)
[18:07] <superm1> Keybuk, well being in the middle of the initrd, I'm not sure I can pull another term up to check the process list or what not
[18:07] <Turl> hi
[18:07] <Turl> is it normal for nautilus-cd-burner to be uninstalled with the updates?
[18:07] <Keybuk> superm1: it's not easy ;)
[18:08] <ogra> break=top and do all steps manually :)
[18:08] <seb128> mpt: ok, so that's a new bug
[18:08] <seb128> mpt: is that daily CD?
[18:08] <mpt> seb128, alpha 6
[18:08] <seb128> weird
[18:08] <superm1> ogasawara, i suspect some racey conditions though that i'm not going to expose unless i'm typing fast...  :)
[18:08] <mat_t> mpt, dunno
[18:08] <superm1> oops, ogra ^
[18:08] <seb128> maybe xorg or the session is crashing
[18:08] <Keybuk> superm1: random
[18:08] <Keybuk> have you actually checked udevd is running?
[18:09] <ogra> superm1, add a script to initramfs doing the same and call the script then
[18:09] <seb128> mpt: does the login after the count work correctly or does it go back to gdm again?
[18:09] <Keybuk> it only runs for a smallish part of the intird
[18:09] <seb128> mpt: I would check your CD to start
[18:09] <Keybuk> udevadm settle will wait for three minutes if udevd isn't running
[18:09] <mpt> seb128, I ran a CD check first. I think the same thing happened with alpha 5, but I forgot about it.
[18:10] <superm1> Keybuk, i see it on mostly atom hardware, i've not seen it on any regular laptops.  i'll add some checks into the the scripts to check for udev running and try to have it blurt things like that out every other command so I can see better
[18:10] <seb128> mpt: ok so maybe xorg or gdm is crashing on first try, it goes back to gdm and do the counting
[18:10] <seb128> mpt: I'm busy with GNOME 2.26 today so I will pass on debugging that for now but maybe somebody else can have a look to that with you
[18:10] <Keybuk> superm1: you're playing around with the partition table inside the initrd?
[18:10] <mpt> seb128, ok, thanks for the suggestions
[18:11] <superm1> Keybuk, yeah... kind of have to for factory installs to make sure it's what ubiquity expects when it starts
[18:11] <apw> slangasek, we have a checkbox update pending, and i am wondering who needs to be informed to make sure it hits the beta
[18:36] <slytherin> pitti: is there any plan to update ekiga to 3.0.2? ekiga 3.2 is released today but there are too many features for updating this late in cycle. So we should at least get 3.0.2 (it adds settings migration from 2.x).
[18:41] <seb128> slytherin: kenvandine_wk is working on getting 3.2 before beta I think, you think it's too late in the cycle?
[18:41] <slytherin> seb128: looking at the changelog. I think there are too many features additions.
[18:42] <kenvandine_wk> it is a long list
[18:42] <slytherin> also it is unclear from changelog if the gstreamer support for audio/video capture is finished or not.
[18:53] <NCommander> Any archive admins around to answer a licensing question? (I need to know if a four-clause BSD license is going to end up in universe or multiverse)
[18:53] <NCommander> (I think its the later, but I'd like to make sure)
[18:55] <IntuitiveNipple> Is there any way to get the new libx86-based read-edid package (which works on amd64 as well a x86/lpia) sponsored to replace the existing 32-bit only package? bug #242043
[18:56] <NCommander> IntuitiveNipple, you need a feature freeze exception
[18:57] <IntuitiveNipple> Who's best for that, would you say?
[19:00] <NCommander> IntuitiveNipple, just subscribe to motu-release, and follow the feature freeze exception rules, and hope for the best
[19:00] <IntuitiveNipple> right, thanks
[19:00] <NCommander> IntuitiveNipple, if you get a freeze exception, I can sponsor it.
[19:01] <IntuitiveNipple> thanks.
[19:12] <Keybuk> yay Windows Vista installer
[19:12] <Keybuk> Please chose between
[19:12] <Keybuk>  (A)
[19:12] <Keybuk>  (B)
[19:12] <Keybuk> note that (A) has been disabled
[19:13] <NCommander> Keybuk, that's an improvement from Windows XP in automatic mode
[19:13] <NCommander> :-)
[19:13] <NCommander> (I got a lot of STOP: No error (OK) boxes while getting the bugs out)
[19:14] <Keybuk> we can't bitch
[19:14] <NCommander> We can't?
[19:14] <Keybuk> someone sent me of a screen shot with an error dialog that said "Never show this error to a user" or something
[19:14] <NCommander> Fair enough
[19:14] <Keybuk> GIO/GVfs related iirc
[19:15]  * NCommander kicks RedBoot
[19:15] <NCommander> Bah
[19:16] <NCommander> So does anyone know if a four-clause BSD license will end up in universe or multiverse?
[19:22] <Keybuk> I believe that it is considered DFSG-free
[19:22] <Keybuk> thus it's unlikely that we'd be more restrictive
[19:22] <Keybuk> though note that it's considered a deprecated licence, even by BSD themselves
[19:23] <NCommander> Keybuk, legacy code used in RedBoot unfortnately. I would think it would end up in universe, but I plan to get this package promoted; I have concerns about it in main just because of the adversing cause ....
[19:23] <NCommander> (I dunno if I'm crazy or not)
[19:24] <mrooney> NCommander: did james_w ever get back to you on that update?
[19:24] <Keybuk> NCommander: my recollection is that the 4-clause BSD is DFSG-free not *not* GPL compatible
[19:24] <NCommander> mrooney, not as far as I could tell, if I don't see someone soon, I'll do something.
[19:25] <mrooney> It will make babies cry if those bugs aren't fixed in Jaunty, like this --> ;_;
[19:25] <mrooney> okay thanks :)
[19:25] <NCommander> Keybuk, there is an exception in the GPL code in RedBoot
[19:25] <NCommander> Keybuk, the copyright file is absolute fun. It breaks 1,000 lines
[19:25] <Keybuk> indeed, the DFSG directly references the BSD licence as free; and I believe that at the time it was written, the 4-clause would have been the standard
[19:25] <Keybuk> NCommander: if the copyright file is that long
[19:25] <NCommander> no wait, scratch that, 792, since I removed the full text of the Apache 2 license in lew of the full text.
[19:26] <Keybuk> I would say that the software needs a very careful copyright audit
[19:26] <NCommander> I know :-/
[19:26] <Keybuk> since it is likely that a conflict has been overlooked
[19:26]  * NCommander sighs
[19:27] <NCommander> RedBoot used to be in the archive, it was removed due to it being unmaintained.
[19:27] <Keybuk> at least some of these licences are likely to be incompatible
[19:27] <Keybuk> and it's all well and good adding an exception to the GPL bits
[19:28] <Keybuk> but you need to make sure *ALL* of the GPL bits, even those linked to, have the same exception
[19:28] <Keybuk> and that the exception has been approved by all copyright holders
[19:28] <NCommander> *sighs*
[19:28]  * NCommander wonders if he can shoot himself now.
[19:28] <Keybuk> I've seen situations before where people have slapped an exception on top of GPL code, without checking
[19:28] <Keybuk> thus violating the licence of code in there
[19:29] <NCommander> Keybuk, we need this package for full iMX51 support :-/. I've done a look over, but its a massive package (I'm talking 16MB of source, and thousands of files; although we could probably strip out chunks of it)
[19:30] <Keybuk> I need iTunes to update my phone, but that can't go in main either ;)
[19:30] <NCommander> Keybuk, we could put it in restricted ... *hears a gunshot*
[19:31] <Keybuk> no, we can't
[19:31] <NCommander> I was kidding :-P
[19:31] <Keybuk> I'm not
[19:31]  * NCommander wonders where one can find a crack team of copyright auditers.
[19:32]  * slytherin is glad he does not own a smart phone yet
[19:32]  * NCommander gave up trying to get his blackberry and PC talking ages ago.
[19:32] <ion_> I want one that runs on free software (and is therefore entirely hackable). And preferably doesn’t suck much. :-)
[19:33] <Turl> ion_: an openmoko phone?
[19:33] <NCommander> ion_, I would say Android Development Platform phones, but I dunno how good Android is
[19:34] <ion_> Yeah, i know about them. I’ll take a look at the market at the point i’m actually buying one.
[19:34] <NCommander> I need something that support tethering.
[19:36] <NCommander> Keybuk, so what do you recommend w.r.t. to the copyright audit on Redboot/eCos?
[19:40] <KaiL> ...I guess, the intel display driver is a good candidate for the "daily upstream builds"
[19:41] <Turl> will 2.6.3 from -intel be included in jaunty?
[19:41] <KaiL> I hope 2.7 will be ready then
[19:42] <Turl> the current one is a bit slow
[19:42] <KaiL> because that version is required for the Asus Eee Top :/
[19:43] <KaiL> Turl, eben 2.6.99 isn't really that much faster
[19:44] <Turl> yeah, but it improves a bit
[19:44] <KaiL> but at least a step into the right direction ;)
[19:44] <kklimonda> hey guys, anyone has problem with booting after last uprades of jaunty?
[19:44] <kklimonda> i'm getting invalid or unsupported executable format when i select kernel in grub
[19:44] <Turl> kklimonda: I updated the kernel today, still didn't reboot
[19:44] <kklimonda> i've tested it with -10 and -9 releases
[19:44] <kklimonda> i'm using ext4
[19:45] <kklimonda> and 64bit
[19:45] <KaiL> for me only the CPU stays a 1,6GHz after booting
[19:51] <kklimonda> ok, fixed - i had to manually run grub-install after i've changed ext3 to ext4..
[20:15] <KaiL> grr
[20:15] <KaiL> bug 341573 still there
[20:21] <Keybuk> KaiL: I've an update pending for it
[20:21] <KaiL> ah, ok
[20:21] <KaiL> so it's at least recognised ;)
[20:21] <Keybuk> oh, yes
[20:21] <Keybuk> I didn't realise the kernel team were going to push an update so fast when I asked them to set the default back to performance
[20:22] <KaiL> the idea behind is "booting on performance mode"?
[20:23] <Keybuk> right
[20:23] <KaiL> ..which gave maximun 1 second here ;)
[20:24] <Keybuk> "maximum 1 second" ?
[20:24] <KaiL> sometimes I get 33, sometimes 34 ;)
[20:24] <Keybuk> ??
[20:25] <Keybuk> boot speed you mean?
[20:25] <KaiL> between grub and the drums
[20:25] <KaiL> yes
[20:25] <Keybuk> doesn't mean much without detailed knowledge of your hardware, etc.
[20:25] <KaiL> I've read somewhere in the blueprint, that most testing for this is done on a netbook
[20:25] <kklimonda> anyone knows how to fix virtualenv?
[20:26] <KaiL> don't forget, that their SSDs have must better access times than normal laptop and even desktop disks..
[20:27] <Keybuk> yes, we know
[20:27] <Keybuk> that's why we use SSD
[20:27] <KaiL> imho you mostly shorten times, which are eaten by the disk
[20:27] <KaiL> loading X and gdm takes half the boot time here
[20:28] <Keybuk> doubtful
[20:29] <Keybuk> I'd imagine that the disk readahead takes the most significant portion of your boot
[20:29] <KaiL> hm, ok... 1/3 from usplash disapearing until the drums
[20:30] <Keybuk> do you have a bootchart?
[20:30] <KaiL> I can try to make one
[20:30] <Keybuk> apt-get install bootchart
[20:31] <KaiL> hm.. main-package depending on universe-package ;)
[20:32] <Keybuk> it recommends it, iirc
[20:32] <KaiL> ah, yes
[20:37] <KaiL> http://moba.linuxfaqs.de/bilder/frog-jaunty-20090317-1.png
[20:37] <KaiL> interesting, that it ends at 25, but the drums are at 33s
[20:37] <Keybuk> yeah, you have to mess about to graph the whole thing
[20:38] <Keybuk> but that neatly shows you're spending almost you're entire time in I/O wait
[20:38] <Keybuk> and the disk throughput is dreadfully low
[20:38] <Keybuk> with apallingly high utilisation
[20:38] <KaiL> in short: that hd sucks?
[20:38] <Keybuk> what is that?  A Dell?
[20:38] <KaiL> Asus M2N
[20:38] <Keybuk> why do you boot with nolapic?
[20:39] <KaiL> but the hd isn't original (that one was worse)
[20:39] <Keybuk> HDDs in general suck
[20:39] <directhex> i still need a solution to network mounts causing painful slowdown on shutdown.
[20:39] <KaiL> there was a bug
[20:39] <KaiL> maybe it's gone...
[20:40] <Keybuk> directhex: ?
[20:41] <directhex> Keybuk, on intrepid, if using n-m, a cifs mount in fstab means a 60 second timeout on shutdown, presumably as networking is killed before the umount happens
[20:42] <directhex> delay is per-mount
[20:42] <Pedobearishere> O HAI GUISE
[20:42] <Pedobearishere> LOOKS LIKE UBUNTU KICKED ME INTO HERE
[20:42] <directhex> sigh
[20:42] <Pedobearishere> O_O
[20:42] <KaiL> hm... lapic lets it take one second more
[20:42] <Pedobearishere> I CAN LAST LONGER THAN A SECOND
[20:42] <Pedobearishere> ASK GOLDILOCKS
[20:42] <directhex> !ops
[20:43] <Keybuk> damn ;)
[20:43] <Seeker`> too slow :(
[20:43] <Keybuk> I had a "who's been eating MY porridge" /kick message all lined up
[20:43] <directhex> hm, patrick, why does that ring a bell
[20:43] <slangasek> "this kick message was just right"?
[20:43] <ikonia> Pedobearishere again....
[20:43] <ikonia> just did some other channels
[20:43] <directhex> hi2u ikonia
[20:43] <ikonia> hey
[20:44] <superm1> Keybuk, okay so i'm still seeing rather mixed results.  *should* udev be started and running by the time 24preseed is being ran in the initramfs?  I see references that udevadm gets ran before it in 23networking
[20:44] <directhex> slangasek, was the guy a few weeks ago talking crap about helix a patrick, or am i misremembering?
[20:44] <Keybuk> superm1: no, I think udev will be long dead by then
[20:44] <slangasek> directhex: different Patrick
[20:44] <Keybuk> but I may be wrong
[20:44] <Keybuk> I've not looked at casper in ages
[20:44] <Keybuk> jonmasters: SPIES!
[20:44] <superm1> Keybuk, okay i'll keep grep'ing around then to try to ge ta better idea
[20:45] <jonmasters> Keybuk: :)
[20:46] <Keybuk> jonmasters: where's that kernel patch? :p
[20:46] <jonmasters> Keybuk: oh thanks for reminding me to finish that
[20:47] <directhex> hm. can bootchart chart shutdown as well? or is that an oxymoron, given the process will get killed
[20:47] <Keybuk> directhex: there are ways to do that
[20:48] <Keybuk> how is left as an exercise to the user
[20:48] <jonmasters> Keybuk: only problem with being on here aswell is Freenode has a 10 channel max.
[20:48] <jonmasters> Keybuk: which means I'll probably need to connect another client too
[20:48] <directhex> Keybuk, i'd really like to resolve why samba umounting sucks so hard, it's bugged me for years
[20:48] <ikonia> directhex: locking is the quick answer
[20:48] <kees> doko: I've got 1/3rd of the gcc testsuite cleaned up.  how should I approach upstream with it?
[20:48] <Keybuk> jonmasters: I'm on >10
[20:49] <directhex> ikonia, afaik the cifs module insists in doing a "clean" umount when unmounting, i.e. sending a "im disconnecting now kkthxbye" to the samba server. it's got a hard-coded timeout of some kind on that
[20:49] <directhex> ikonia, try mounting something, pull the cable, then unmount it
[20:49] <ikonia> how delightful
[20:50] <Keybuk> directhex: smb mounts sound like the kind of thing that should be done by fuse these days
[20:50] <superm1> jonmasters, yeah and i just joined an 11th to check.  wfm too
[20:50] <Keybuk> in fact, fuse-nfs; when?
[20:50] <directhex> Keybuk, i'm approx 112.6% in agreement on that.
[20:50] <jonmasters> Keybuk: oh, I mean 20
[20:51] <directhex>   smbnetfs
[20:51] <directhex> i'll try that
[20:53] <soren> jonmasters: If you ask nicely, they'll let you join more.
[20:53] <soren> jonmasters: "/whois soren" for proof.
[20:53] <directhex> argh, except... argh! it doesn't have its own mounter, and fuse isn't considered a network filetype by /etc/network/if-up.d/mountnfs, so it would be mounted all funny-like
[20:53] <soren> jonmasters: Hi, by the way :)
[20:54] <directhex> nothing simple is ever easy
[20:54] <jonmasters> soren: the limit seems arbitrary :)
[20:54] <jonmasters> soren: who do you ask?
[20:54] <jonmasters> soren: hi too :)
[20:54] <soren> jonmasters: I forget whom I asked specifically. Any freenode op, I suppose.
[20:55] <slangasek> Keybuk: your desire to convert people to fuse notwithstanding, there are plenty of users who use the kernel cifs support and this is a bug that should be fixed.
[20:57] <directhex> it is reasonable to have a timeout on connection drops, so IMHO the question is how to ensure netfs is unmounted before network dies
[20:59] <Keybuk> directhex: depends, how is the network up?
[20:59] <directhex> Keybuk, n-m wired dhcp
[20:59] <Keybuk> so there you have the egg
[20:59] <Keybuk> and the network is the chicken
[20:59] <Keybuk> N-M and its various bits are all on /usr
[21:00] <Keybuk> so they're killed (forcing the network done) before we umount filesystems (including network filesystems)
[21:00] <Keybuk> because we support /usr on separate filesystems
[21:00] <Keybuk> indeed, it's one of the most common scenarios for NFS
[21:01] <directhex> so perhaps n-m could be made to not bring down the network on shutdown? what purpose does killing the network serve, exactly?
[21:02] <directhex> DHCP release i suppose
[21:02] <directhex> hm, tricky
[21:02] <slangasek> is the interface actually taken down when NM is killed?
[21:02] <Mithrandir> I wonder why we bother about dhcp release.
[21:03] <KaiL> is there a visible difference for the dhcp server, if there's a ifdown or just a "poweroff"?
[21:03] <slangasek> well, if the interface is actually *deconfigured*, that's an easier case for the cifs code to check and handle correctly
[21:03] <slangasek> which if you're doing a wired network + N-M, I guess that's the case
[21:04] <directhex> is there a pre-down we can abuse?
[21:04] <directhex> mounting netfs in post-up works great
[21:10] <slangasek> directhex: not sanely, because you have to determine that *this* interface is the one associated with the mount in question
[21:10] <directhex> oh christ
[21:10] <slangasek> i.e., check whether taking down this interface takes down the route
[21:10] <superm1> Keybuk, well i'm thinking my resolution to the problem is bind mounting /dev to /root/dev while running any commands in /root from the initramfs.  udev is indeed running, but it looks like the /dev and /root/dev easily get out of sync
[21:10] <directhex> this sounds like a job for sitting down & brainstorming :/
[21:11] <slangasek> but it *is* a bug that the kernel cifs implementation has to time out when asked to unmount a share and it gets a no route to host
[21:13] <soren> slangasek: that's not really that difficult, is it? "ip route get <samba server> | grep -q \\\<$IFACE\\\>"
[21:14] <slangasek> soren: oh, I didn't know we had that, that's useful :)   But you do need to check that this is the *only* interface with a route to it, rather than checking that this interface has a route to it...?
[21:16] <soren> slangasek: Hence the question mark. :)
[21:17] <soren> slangasek: Well.. You could add a check for other interfaces with a route to it, and with the same source address.
[21:17] <kees> Keybuk: you're op'd.
[21:17] <soren> slangasek: I think that is complete enough.
[21:17] <soren> slangasek: More than complete enough, even. :)
[21:18] <slangasek> soren: and then lazy unmount?
[21:18]  * soren reads context again
[21:19] <soren> slangasek: I'm not sure I'd do it lazily. Does that block at all? I want the umount to finish before the route is gone.
[21:20] <slangasek> soren: the trouble is that the unmount won't finish at all if there are processes still using the mount
[21:20] <soren> slangasek: Right you are.
[21:20] <soren> Err..
[21:20] <slangasek> if the interface goes down because you lost sight of the AP, and you're sitting with an open shell with the smb mountpoint as cwd, and...
[21:21] <soren> slangasek: In that particular case, I'd prefer not to unmount at all, I think.
[21:21] <soren> I kind of like being able to walk closer to that AP again and have things just continue where they left off.
[21:22] <directhex> so now we need some kind of heuristic to determine whether we really want to do a speed-unmount. i propose an advanced genetic algorithm
[21:22] <soren> I know a certain office in London where dropping off of the wifi is not an uncommon occurrence.
[21:22] <slangasek> soren: well, there's no way to distinguish that case from the shutdown case then, using pre-down
[21:22] <directhex> slangasek, not even from the runlevel?
[21:22] <KaiL> soren, and same for "i need to sort the cables" on a wired LAN?
[21:22] <slangasek> unless you check runlevel :P
[21:22] <directhex> hax!
[21:22] <directhex> i like hax.
[21:23] <soren> KaiL: Very much, yes.
[21:23] <soren> I always get a warm, fuzzy feeling when I've suspended my laptop for half a day, come back, resume, and my ssh connections are still live.
[21:24] <KaiL> hehe
[21:24] <soren> How this relates to this discussion, I'm not sure.
[21:24] <soren> I'm very tired.
[21:24]  * directhex wonders when more exciting details on UDS are coming
[21:25] <soren> directhex: When you least expect it.
[21:25] <directhex> so thursday, then? totally not expecting it on thursday
[21:25] <KaiL> so we need to separate beween a ifdown manually issued (including shutdown) and one issued by link loss
[21:28] <jussi01> jcastro: ping
[21:32] <TheMuso> asac: no, I'll get it uploaded this morning.
[22:08] <dtchen> cjwatson: / mdz: / Keybuk: sorry about the RT spam, not sure how to prevent that
[22:29] <Rocket2DMn> TheMuso, im looking at bug 243226 - you said you were going to prepare a SRU for Hardy for it but the bug status was never updated.
[22:33] <TheMuso> Rocket2DMn: I got sidetracked. I'll get to it once beta freeze is in effect for jaunty, since I'm rather busy till then.
[22:33] <Rocket2DMn> ok no problem, thanks for looking
[23:00] <cjwatson> dtchen: it's ok, we have explicitly asked to be subscribed to all traffic on that RT queue
[23:00] <cjwatson> dtchen: so it isn't spam for us
[23:01] <cjwatson> mpt: that's an interesting bug (autologin). When you first mentioned it I thought you meant you'd logged out and then seen a countdown, and in that case it does make some sense since if you've logged out from the live environment you probably had some curious reason to do so (such as creating a new user in the live environment)
[23:01] <cjwatson> mpt: I don't believe I've ever seen it act that way on initial boot, though
[23:06] <jpds> a/41
[23:33] <bryce> pitti: btw I've packaged/built -fglrx and will be uploading soon once I've done a little testing
[23:33] <bryce> pitti: version is going to be 8.600-0ubuntu1
[23:41] <directhex> there's a new catalyst?
[23:42] <directhex> or is this a private build again?
[23:48] <NCommander> ScottK, ping?