[00:15] <kees> james_w: when you're fixing FTBFS (wiipdf, vobcopy) can you send the patches to Debian too?
[00:15] <james_w> kees: done
[00:18] <james_w> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511971 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511978 for those two, the others are all filed too
[00:21] <kees> james_w: cool!  :)
[00:21] <kees> james_w: normally I include something like  (debug bug #...)  in the changelog so it can be checked during a merge
[00:22] <james_w> yeah, but I prefer not to have to wait for a round trip with the Debian BTS
[00:22] <james_w> thought that does seem to be a lot quicker recently
[00:54] <slangasek> kees, jdstrand: is there an Ubuntu security 'overview' page I can link to from this debconf message?
[00:54] <slangasek> something that tells the user how bad they are for not installing security updates on a regular basis? :)
[00:54] <kees> slangasek: hrm
[00:55] <slangasek> ubuntu.com/usn isn't it; I don't find anything under help.ubuntu.com that looks good
[00:56] <slangasek> if there isn't one, we can certainly punt for now
[00:57] <kees> punt, then.  I can't find anything either
[00:57]  * kees adds it to his todo list
[02:27] <billisnice> where is ubuntu 9.04 alpha 3?
[02:28] <Hobbsee> gone.
[02:30] <Hobbsee> it hasn't been released yet
[02:30] <billisnice> i thought it was due out today?
[02:30] <billisnice> the 15
[02:31] <pochu> billisnice: delays happen sometimes :) it will be announced to the appropriate mailing list when it's available
[02:31] <Hobbsee> as far as i know, it's still being tested, and will be released today or tomorrow
[02:32] <pochu> which is ubuntu-devel-announce
[02:35] <billisnice> will ext4 be in this release?
[02:36] <Hobbsee> by default?
[02:37] <billisnice> by default
[02:38] <billisnice> better yet, are there instruction for installing linux 2.26.28 with ext4 on 8.94?
[02:39] <billisnice> 8.10
[02:40] <Hobbsee> i'm sure #ubuntu+1 can help you with questions of that nature, and I don't believe it's by default
[02:40] <slangasek> no.  Why is ext3 insufficient?
[02:41] <slangasek> using ext4 on 8.10 would certainly be an unsupported configuration
[02:41] <billisnice> 8.10 is slow on my old compaq, i though ext4 would speed it up
[02:41] <slangasek> it almost certainly won't
[02:41] <billisnice> no speed difference?
[02:42] <slangasek> not in any meaningful sense
[02:42] <billisnice> ok
[02:42] <billisnice> i wish it were faster
[02:43] <billisnice> Arch Linux is so much faster on my old machine, but i like ubuntu
[02:44] <slangasek> there are a lot of factors that may be contributing to that; the filesystem is not likely to be a major factor though, ext3 is already a very good filesystem and it's hard to go very far up from there for general desktop use
[03:57] <RAOF> Hm.  There don't appear to be alpha-3-candidiate desktop images for testing. Are there likely to be some soon, or shall I just test alternate instead :)
[06:25] <dholbach> good morning
[06:32] <det> morning
[08:05] <tritium> kirkland: screen-profiles looks useful not only for server machines with no graphical desktops, but also for mythbuntu boxes with overscan issues, where it's often hard to see the top panel, and hence easy to miss update-manager notifications, etc.
[08:06] <tritium> Very nice!
[09:02] <dholbach> kees, seb128: did you have a look at huats' check-symbols script? :)
[09:02] <seb128> dholbach: no
[09:02] <seb128> dholbach: I've no real interest to it to be honest
[09:02] <seb128> I like my version better and use that one ;-)
[09:03] <huats> seb128: no real interest in my stuffs ... thanks seb128 :P
[09:03] <dholbach> seb128: because your version has french messages?
[09:03] <seb128> dholbach: no, because I don't use pbuilder and I'm not interested to something which wants build and install things
[09:03] <dholbach> seb128: he changed the tool to not require that
[09:03] <seb128> the version I'm using compare the build directory to the system version
[09:04] <seb128> dholbach: right, to work on deb thoughs, which still means downloading the current version deb
[09:04] <seb128> where I do use the installed version ;-)
[09:04] <seb128> anyway I will have a look but I had other things on my todolist for this week
[09:05] <huats> seb128: sure :)
[09:15] <mvo> seb128: is your version public ;) ?
[09:16] <seb128> mvo: no, it's too much of quickly written code to be published on the web ;-)
[09:16] <mvo> :)
[09:16]  * mvo hugs seb
[09:16]  * mvo hugs seb128
[09:16]  * seb128 hugs mvo
[09:18] <mvo> dholbach: that would be a good topic for the developer week, library packaging 101
[09:19] <dholbach> mvo: the schedule is full already, but if you'd do it the next time, that'd be awesome :)
[09:19] <dholbach> seb128: freedom hater! :)
[09:19] <dholbach> you're saying that for years already
[09:19] <seb128> lol
[09:19] <dholbach> I had to write my own script
[09:19] <dholbach> !!!
[09:19] <seb128> I think I gave you my version
[09:20] <seb128> it just doesn't work for you pbuilder lovers ;-)
[09:20] <seb128> since pbuilder clean the build directory after build and give you debs and my version uses the build directory
[09:20] <dholbach> it was written in French!
[09:20] <Mithrandir> dholbach: French is the new Chinese
[09:20] <seb128> which everybody knows is the universal language ;-)
[09:20]  * dholbach hugs seb128
[09:20]  * seb128 hugs dholbach
[09:20] <dholbach> Mithrandir: eh?
[09:21] <Mithrandir> indeed.
[09:22] <liw> I wanted to switch to reprepro for updating my local mirror, but it seems to want to create Release.gpg itself, so that's a bummer
[09:22] <Keybuk> 6
[09:22] <Mithrandir> liw: I think you can tell it not to
[09:23] <liw> Mithrandir, you can tell it to not sign it, but I can't figure out a way to get it to just use the one from Debian or Ubuntu
[09:24] <liw> debmirror is OK with me, though, it just occasionally barfs
[09:24] <directhex> Mithrandir, french would be the new chinese if the people who were meant to be spreading it weren't on strike
[09:25] <pochu> anybody from Valencia on the channel? :)
[09:25] <dholbach> pochu: tried #ubuntu-es too? :)
[09:26] <pochu> good idea :)
[10:18] <Keybuk> it seems mean to say this, but compared to Fedora and OpenSUSE, our installer is a bit ugly
[10:28] <lool> It seems it's fun day today
[10:28] <lool> cupsd: ../sysdeps/posix/getaddrinfo.c:1457: rfc3484_sort: Assertion `src->results[i].native == -1 || src->results[i].native == a1_native' failed.
[10:29] <RAOF> Universe is meant to be enabled by default, right?
[10:29] <Mithrandir> Keybuk: compared to RHEL, it's wonderful.
[10:29] <lool> Of course I need to print something right now
[10:29] <persia> RAOF, Ought be.
[10:29] <RAOF> Ok.  So, it isn't on the amd64 livecd.
[10:30] <persia> It's enabled by default in the installed system, but not on the livecd.
[10:30] <lool> Why don't I get an apport crash?  It's an abort and I get a core file
[10:30] <Keybuk> lool: development release?
[10:30] <lool> Keybuk: Yes, and apport enabeld
[10:32] <lool> and EDS wants all my CPU now *sigh* someone let me do my work
[10:36] <lachlan__> Hello.  Where do you do your automount, is that in one of the gnome packages, HAL, or somewhere of its own?
[10:38] <Keybuk> lachlan__: of plugged in devices?  a number of different packages are all involced
[10:39] <lachlan__> Ok.  But if I remove GNOME, can I put something in there to speak to HAL and do the automounting, or is there something else?
[10:39] <Keybuk> yes, KDE has a similar architecture, for example
[10:40] <lachlan__> Ok, thanks, that's what I was hoping :)
[10:41] <RAOF> Hm.  Where should "Universe not enabled on amd64 livecd" be filed?
[10:42] <StevenK> RAOF: I can recall a similar bug already filed on livecd-rootfs
[10:42] <RAOF> Yup, just found it, thanks.
[10:44] <persia> Should that be a bug?
[10:45]  * persia thought it was intentional, to reduce download size, etc. in the temporary system
[10:47] <ogra> it should be enabled in the final sources.list, not during build of the livefs
[10:47] <ogra> livecd-rootfs switches over in the end
[11:48] <RAOF> Hm.  Ubiquity's being a bit of a problem child.
[12:36] <kirkland> tritium: thanks!
[13:32] <Notch-1> i'm in live usb persistent mode (kubuntu intrepid), and i can't disable autologin, why? after reboot it is enabled again...
[13:57] <cpufreak> w 23
[14:04] <ion_> benc: compcache 0.5 has been released. It would be nice to get it into jaunty’s kernel.
[14:04] <jcastro> I have post UDS announcements in the -devel and -devel-announce queue if someone can approve those sometime today that would be swell.
[14:23] <LordMetroid> Where can I leave suggestions?
[14:24] <LordMetroid> I am thinking it would be useful if rm or overwriting files in general would move them to the gnome-trash, don't know if it is such a good idea though so I would like some feedback...
[14:25] <Pici> !brainstorm | LordMetroid
[14:26] <LordMetroid> Thank you pici
[14:28] <cjwatson> jcastro: hmm, I noticed that you'd used the wrong date just after approving the -devel-announce message
[14:28] <cjwatson> "which took place from 8-12 April"
[14:28] <cjwatson> jcastro: want to correct the -devel one?
[14:31] <evand> jcastro: devel approved
[14:34] <jdstrand> cjwatson: hi! I'd like to test preseeding with a new ufw package before uploading. I know about mini.iso and I know about preseed files. what I'm not sure about is how to specify multiple mirrors in the preseed file (ie, the main one, and one with my new ufw package). Is this possible? Can you point me to a url for docs on how to do it?
[14:34] <cjwatson> jdstrand: yeah, search for "apt-setup/local" in the installation guide
[14:35] <jdstrand> cjwatson: thanks!
[14:35] <cjwatson> jdstrand: beware that there are some ordering issues in how the system is installed
[14:35] <savvas> does anyone know if there are plans for /etc/security/time.conf to have a folder as well? /etc/security/time.conf.d/ ?
[14:36] <cjwatson> jdstrand: the bulk of stuff installed by tasksel is done without honouring apt-setup/local*/*, I think - you'd be best off arranging for an absolutely minimal installation, and then using pkgsel/include to get ufw
[14:36] <savvas> *for pam time module
[14:36] <cjwatson> savvas: in general, we only do that when it is necessary for packages to drop in extra files. Users should just edit that file directly
[14:36] <jdstrand> cjwatson: excellent. thanks :)
[14:37] <cjwatson> jdstrand: hmm, this may be a bit tricky since ufw is in standard
[14:37] <jdstrand> tasksel tasksel/first multiselect ubuntu-minimal?
[14:37] <jcastro> cjwatson: yikes, april, I don't know what I'm thinking
[14:37] <jdstrand> that was what I was going to try...
[14:37] <cjwatson> jdstrand: no, that won't work
[14:38] <cjwatson> jdstrand: try: 'tasksel tasksel/skip-tasks string standard'
[14:38] <savvas> cjwatson: I need it for timekpr, a 'computer nanny' sort-of, to limit computer usage - but /etc/security/time.conf belogs to a package, isn't that breaking a policy?
[14:38] <cjwatson> and then 'd-i pkgsel/include string ufw'
[14:38] <cjwatson> savvas: yes, it would be. You'll need to file a bug on pam requesting support
[14:38] <savvas> ok thanks :)
[14:38] <cjwatson> and there might be some other way you can achieve the same effect
[14:38] <jdstrand> cjwatson: I current have 'tasksel tasksel/first multiselect ubuntu-standard', should I leave that and use what you just recommended with it?
[14:39] <cjwatson> after all, time.conf is the configuration for a specific pam module
[14:39] <cjwatson> jdstrand: you can take that out permanently since it isn't needed
[14:39] <jdstrand> ok, cool
[14:39] <cjwatson> (and is the wrong name anyway, the task name is just 'standard')
[14:39] <cjwatson> standard is installed by default; in this case, you need to turn that off so that it gets installed from your local repository
[14:40] <jdstrand> (I'm looking at a preseed file from hardy, so it likely needs other changes)
[14:40] <jdstrand> cjwatson: gotcha :)
[14:41] <savvas> cjwatson: I'm currently using debian/postinst and debian/postrm to make it work with /etc/security/timekpr.conf, but it would be easier if there was such a folder to drop in my package-related time.conf - maybe I should file a bug directly upstream ?
[14:41] <cjwatson> savvas: file a bug with Ubuntu pam to start with
[14:41] <savvas> ok
[14:42] <savvas> will do
[14:42] <savvas> thanks for the help :)
[15:24] <gpled> is their any chance the power update script would put my second monitor is sleep mode?
[15:27] <Keybuk> mvo: around? need some help with python-apt
[15:27] <mvo> Keybuk: yes
[15:28] <Keybuk> mvo: I'm trying to map from a binary package name to a source package name
[15:28] <Keybuk> and can't seem to figure out how ;)
[15:28] <Keybuk> I've been reading the extensive documentation for literally seconds!
[15:28] <gpled> i lost one of my 4 monitors after the last update
[15:28] <gpled> second monitor on first card
[15:29] <Keybuk> gpled: have you tried looking under things on your desk?
[15:29] <gpled> is their a way i can check if it is being forced to sleep mode?
[15:29] <cjwatson> gpled: I would never put anything much past acpi-support, but I would doubt that the update was responsible
[15:29] <cjwatson> all it did was hdparm
[15:29] <gpled> the monitor works, until xorg kicks end
[15:29] <gpled> then it goes black
[15:30] <gpled> if i shutdown, or reboot, it comes back to life after x is done
[15:30] <mvo> Keybuk: import apt; apt.Cache()["upstart"].sourcePackageName
[15:31] <mvo> Keybuk: it that sufficient ?
[15:31] <Keybuk> aha!
[15:31] <Keybuk> I had the cache object from apt_pkg.somethingorother, and that didn't have any properties
[15:32] <cjwatson> python-apt has two layers, one of which looks like apt's C++ layer and one of which looks like Python
[15:32] <ScottK> python-ogre?
[15:32] <cjwatson> for most purposes nowadays you really want the stuff from the apt module, even if it does raise a FutureWarning ;-)
[15:32] <ScottK> What with the layers and all.
[15:33] <mvo> Keybuk: the apt_pkg interface is a bit low-level, I would recommend not using it unless there is stuff in it that is not available via the "apt" interface
[15:34] <mvo> Keybuk: there is even good documentation available for all this these days: http://people.debian.org/~jak/python-apt-doc/
[15:37] <mvo> cjwatson: *cough* I need to remove that stupid^Wover-cautious warning
[16:15] <Riddell> salut mathiaz, able to accept my post to ubuntu-server mailing list?
[16:15] <mathiaz> Riddell: yop - I'll get to it in a moment
[17:00] <LordMetroid> !packages
[18:08] <tjaalton> hmm, are we ever going to have a real lib64 dir and leave lib for 32bit stuff?
[18:08] <tjaalton> there are proprietary apps which assume that
[18:08] <srid> I'm just curious if folks are working on automated testing, or have they dropped it already? https://launchpad.net/ubuntu/+spec/automated-testing
[18:08] <srid> I'd be interested in contributing to it as I am working on similar efforts at my job
[18:10] <ogra> tjaalton, did you see the fix for evtouch ?
[18:11] <tjaalton> ogra: yes, thanks :)
[18:11] <james_w> srid: #ubuntu-testing may be a good place to discuss it
[18:11] <ogra> should work for other input drivers as well
[18:12] <jdstrand> cjwatson: fyi-- your suggestions for ufw preseed testing are working wonderfully. thanks again! :)
[18:12] <cjwatson> jdstrand: excellent
[18:15] <tjaalton> ogra: yeah, there are quite a few which ftbfs, but no one uses them..
[18:15] <maxb> tjaalton: Was having /usr/lib pointing at libs for a non-default ABI ever considered? It seems bit strange.
[18:16] <ScottK> srid: I think #ubuntu-qa is where to discuss automated testing.
[18:16] <ScottK> Or testing....
[18:17] <tjaalton> maxb: no idea
[18:18] <tjaalton> I'm just a bit surprised that for instance Bakbone lists Ubuntu as supported for both 32 and 64bit client/server (and Debian too), where it fails to install on 64bit..
[18:18] <tjaalton> since it assumes lib64 is for 64bit, and lib for 32bit libs -> fail
[18:18] <maxb> Oh, I misread your earlier question as querying the state of an ongoing debate.
[18:19] <tjaalton> maxb: it was, I don't know what the status is
[18:21] <tjaalton> maxb: wait, what debate?-)
[18:23] <maxb> The concept that /usr/lib would contain 32-bit stuff on an amd64 system seems pretty bizarre to me. I've never seen anyone suggest it before, so I'm wondering if there's some mail thread somewhere that I've missed, or if it was before I started following the lists
[18:24] <tjaalton> that's what the rpm world is doing
[18:24] <tjaalton> and what LSB assumes
[18:25] <tjaalton> we have the lib64 symlink pointing to lib..
[18:25] <maxb> Yikes.
[18:25] <maxb> How odd.
[18:25] <tjaalton> inherited from debian
[18:26] <maxb> No, I mean the rpm and LSB behaviour is odd
[18:26] <tjaalton> ok, what do you suggest?-)
[18:26] <maxb> I don't pay much attention to either, but it surprises me that they would do something different to what the FHS says
[18:26] <tjaalton> and what does it say
[18:26] <tjaalton> ?
[18:27] <tjaalton> see for instance http://lists.debian.org/debian-amd64/2004/07/msg00039.html
[18:28] <maxb> FHS says /lib<qualifier> and suggests that /lib would be a symlink to one of them (the platform default, I'd hope)
[18:29] <tjaalton> what would that help?
[18:30] <tjaalton> then you'd have lib, lib32 and lib64 on a 64bit system
[18:30] <tjaalton> and lib, lib32 on 32bit
[18:30] <cjwatson> what the rpm world is doing> I'm not sure switching to become incompatible with the Debian world is obviously better
[18:31] <tjaalton> cjwatson: I understand, that's why I'm not suggesting to do the move, but asking if someone would know if there are any plans in the debian world to do something about it
[18:31] <cjwatson> as far as I'm aware, the Debian world thinks that the rpm world is wrong in this and should be fixed
[18:31] <tjaalton> heh
[18:31] <cjwatson> are there any plans in the rpm world to do something about it?
[18:32] <tjaalton> not that I know of
[18:33] <srid> hmm, #ubuntu-qa has no members
[18:33] <srid> ScottK: ^^
[18:33]  * ScottK misremembered then.  Sorry
[18:33] <ScottK> #ubuntu-testing then
[18:34] <cjwatson> I bet there are proprietary applications expecting the Debian-style approach too
[18:36] <Strassen_lecker_> hi
[18:36] <Strassen_lecker_> german?
[18:36] <Strassen_lecker_> deutsch?
[18:37] <tjaalton> cjwatson: well, AIUI LSB says that lib64 and lib should be separate, so if the vendors assume that things will break in debian & derivatives
[18:38] <cjwatson> that's as may be, but it's essentially impossible to change in Debian systems without a total rebuild of everything (completely breaking mirrors, etc.) and so is very unlikely to happen; so the LSB would be better served by figuring out a way to support both (e.g. with clever personality hacks) rather than standardising something which isn't standard
[18:38] <tjaalton> "isn't standard" meaning what's out there and not what's in LSB? :)
[18:39] <tjaalton> I realize it would be a huge effort, therefore I'll just contact Bakbone support and ask for an explanation :)
[18:40] <maxb> I'm left utterly bemused on what train of thoughts led to the LSB deciding that on amd64 systems, /usr/lib should *not* contain libraries of the default ABI
[18:40] <tjaalton> maxb: what default ABI?
[18:40] <cjwatson> tjaalton: yes, I mean reality not what's written down
[18:40] <maxb> The, uh, one after which the platform is named? :-)
[18:40] <cjwatson> tjaalton: default ABI, i.e. what your main userspace is
[18:41] <cjwatson> I'm entirely with maxb on this
[18:42] <cjwatson> it isn't necessary in general since the linker can say (at least in theory, I forget whether it really does this but it clearly could) "oh, it's a 32-bit application, I'd better look in that library path over there instead"
[18:42] <cjwatson> you might have to run it under linux32
[18:43] <walters> except that application installers need to know where to put things
[18:44] <cjwatson> the lsb is not short of query tools
[18:44] <cjwatson> they could easily have created one that asks
[18:44] <cjwatson> and of course lsb applications should not be installing into /usr/lib anyway
[18:45] <tjaalton> sorry, was on the phone
[18:45] <walters> eh, the whole issue sucks and i can understand debian not adopting multilib; what i think would be crazy though is adopting multilib, but reversing the naming from the multilib everyone else uses
[18:46] <tjaalton> ok I get the ABI issue now..
[18:47] <cjwatson> except that adopting what everyone else uses would mean a rebuild of world and an ABI event
[18:47] <cjwatson> and that third-party applications should really *not* need to depend on the system library path
[18:48] <cjwatson> the LSB should be nominating a safe subset of practices rather than a wishlist
[18:53] <walters> cjwatson: yeah, ABI break is a problem...i guess the only other option is incompatibility forever
[18:54] <cjwatson> being different is not necessarily being incompatibl
[18:54] <cjwatson> e
[18:54] <cjwatson> there is no intrinsic reason why having a different default library path is actually an incompatibility, with properly written applications
[18:54] <cjwatson> (yes, I know there are lots of little glitches, but those are system bugs rather than intrinsic incompatibilities, IMO)
[18:59] <walters> cjwatson: the problem is that this knowledge does end up in a variety of tools; years ago I had to untangle gstreamer which does some caching of its plugin .so files, it had to be made aware of multilib
[18:59] <cjwatson> right, that was the sort of "little glitch" I was referring to; those are things the system can and should fix, though, and are not in principle things the LSB ought to have to worry about
[19:00] <cjwatson> i.e. a more productive LSB approach would have been to cause those sorts of problems to result in LSB test failures
[19:00] <cjwatson> but not otherwise mandate particular paths
[19:00] <walters> anyways, back to working on code and pretending flash doesn't exist
[19:03] <tjaalton> thanks for the conversation :)
[19:05] <tjaalton> I understand the issue a whole lot better now
[19:06] <ogra> oh, you were cornered by the colin mafia :)
[19:06] <tjaalton> more like the 2&4 year old mafia
[19:07] <tjaalton> and got distracted
[19:09] <tjaalton> (the kids..)
[19:10] <albuntu> hello to all
[19:10] <albuntu> sorry if i am wrong here but i wanted to ask how to edit the gnome panel from terminal
[19:13] <Pici> albuntu: you'd need to modify the gconf keys that control that data by using gconftool.  I dont know the paths for those keys off the top of my head.
[19:14] <albuntu> Pici: thanks :) gconf can be used via terminal right ? because i dont want the gui one
[19:14] <albuntu> i know i have to look for the xml files
[19:15] <albuntu> and i am trying to find them
[19:15] <ScottK> #ubuntu for help.
[19:16] <albuntu> ScottK: ok thanks. i tried there but i got no answer and thought to try here. sorry
[19:17] <simira> albuntu: I believe there's also #ubuntu-help
[19:18] <albuntu> simira: it takes to ubuntu
[19:18] <albuntu> i know it :)
[19:18] <simira> ok
[19:18] <albuntu> thank you :)
[21:42] <calc> ok so seagate put out the KB article now acknowleding the drives are defective
[21:42] <calc> waiting on hold to get a firmware update now
[21:44] <Nafallo> calc: which drives?
[21:46] <directhex> 1.5tb ones are known dodgy
[21:47] <directhex> dunno if calc means thosed
[21:47] <Nafallo> ah. good I bought WD instead then :-)
[21:47] <Nafallo> there was someone in -server saying he had just bought 4 of those... he might be interested in the news :-)
[21:48] <directhex> afaik it's fixed in a new firmware
[21:48] <directhex> but still
[21:49] <directhex> i'll stick with samsung tyvm
[21:49] <Nafallo> :-)
[21:52] <directhex> http://www.engadget.com/2009/01/16/seagate-barracuda-7200-11-drives-said-to-be-failing-at-an-alarmi/
[21:54] <Nafallo> ouch. all 7200.11... that's more than 1.5TB
[21:54] <calc> Nafallo: http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=207931
[21:54] <calc> they finally put the KB article back up a bit ago
[21:54] <calc> it affects all seagate 11th generation drives including maxtor apparently
[21:55] <Nafallo> wow
[21:55] <calc> it looks like it might not affect the 1.5TB drive so maybe they fixed the issue earlier and hoped not to worry about it for the smaller capacities
[21:56] <calc> it affects from the list 1tb, 750gb, 640gb, 500gb, 320gb, 250gb, 160gb drives
 i'll stick with samsung tyvm
[21:56] <calc> i'll let you know how it goes once i get through the phone queue, however long that takes
[21:56] <calc> directhex: samsung spinpoint f1?
[21:57] <calc> directhex: aiui they have some problem as well, but i don't have one so didn't look into that much
[21:57] <directhex> calc, generally. been using them since the old p80 series appeared
[21:57] <Nafallo> WD Green for me :-)
[21:58] <calc> apparently the hitachi are good as well now that IBM isn't involved anymore ;-)
[21:58] <directhex> i like samsung. they do what seagate were famous for - quiet, low-noise
[21:58] <tritium> Nafallo: nice, quietest and lowest power-consumption drives you can buy.  :)
[21:58] <directhex> and cool-running
[21:58] <Nafallo> tritium: yea. part of why I wanted them so badly :-)
[21:58] <calc> i think i'll get a 2-3tb drive at the end of the year
[21:58] <directhex> heat matters in confined spaces
[21:58] <calc> plenty of room to build OOo then ;-)
[21:58] <tritium> Nafallo: I'm putting the new WD Green 1TB in my next HTPC build.
[21:59] <directhex> deathstars are still hotter than the surface of the sun after a couple of minutes
[21:59] <Nafallo> tritium: putted my two into a small enclosure using hardware raid1 :-)
[21:59] <calc> i tried building one of those Shuttle sff systems a few years ago and it was very easy to overheat drives in that, ended up returning the system
[21:59] <tritium> Nafallo: sweet!
[21:59] <Nafallo> well.. "small"
[21:59] <Nafallo> http://www.edge10.com/digital_storage.php <-- DAS200
[22:00]  * tritium drools
[22:00] <directhex> calc, wifey has a shuttle, with a spinpoint ni it - no overheating issues ;)
[22:01] <calc> directhex: i think the newer ones are a bit bigger as well to help alleviate the heat issues
[22:01] <calc> directhex: the one i got was an i865G based system
[22:02] <directhex> calc, this one's p31 based, but uses the ancient g2 chassis
[22:02] <directhex> g5 IS bigger
[22:02] <calc> directhex: of course i was also trying to overheat the drive to make sure it wouldn't fail on me when doing dev work
[22:02] <calc> directhex: i ran a couple full disk reads on it and monitored the heat ;-)
[22:03] <directhex> the real hot spot, literally, is the geforce 8800 - since the pcie slot is on the outside of the mobo, the card has about 5mm next to it until it's got the outside of the chassis... no airflow...
[22:06] <calc> 27m and going for hold queue
[22:06] <calc> their 800 number was actually busy earlier when i tried calling
[22:19] <sbeattie> calc: really? I've had a few different 2 hd shuttles that have been rock solid -- but they're all servers so I've never added video cards to cook my disks with.
[22:24] <calc> sbeattie: the i865G i had was integrated graphics and still got too hot, but that was around 4 years ago now i think
[22:26] <mattias_> hi um... where can i get started in regards of learning to write a program for ubuntu?
[22:27] <sbeattie> calc: I have an i845g that I've had running since before then, with the disks in software raid 1.
[22:32] <calc> so the fix isn't actually done yet they thought they had fixed it and announced the issue then found out the bug wasn't fully fixed yet (i suppose) and will be sending it via email to everyone once its done
[22:32] <calc> doh
[22:36] <slangasek> kirkland: is bug #309541 still a going concern in alpha-3?  The bug is still only marked 'fix committed' for Linux
[22:37] <superm1> are we still frozen for a3 or is /t just not updated yet?
[22:37] <directhex> oh, minor note: if your gdm default session changes (e.g. to 'mythbuntu'), guest sessions don't work
[22:39] <slangasek> superm1: feel free to consider us unfrozen, the milestone will be published shortly
[22:39] <superm1> slangasek, great thanks
[22:43] <tedg> Why is there PPA builds in queue if there are idle machines (instances)?  https://launchpad.net/+builds
[22:45] <slangasek> that page claims they aren't in queue :)
[22:48] <tedg> slangasek: Heh, well the aren't now.   I think it's a cron thing, they get moved in at a specific interval.
[23:05] <TheMuso> bryce_: The mitac audio patch you put together is now upstream. Will be pulling it and a few others to pass onto the kernel team next week.
[23:06] <bryce_> TheMuso: awesome