[00:00] <genii> Is there a decent channel or resource to find out what is available for ARM platforms?
[00:01] <genii> (more specifically Cortex A8)
[00:06] <jdong> who in ~core-dev usually cares about Transmission (the bittorrent client)?
[00:06] <jdong> in bug 460620, people are reporting that private trackers are starting to ban transmission <=1.75
[00:07] <jdong> in which case, 1.76 is a fairly unintrusive, bugfix-only minor release.
[00:07] <jdong> it may be worth sticking that into -proposed.
[00:37] <ajmitch> jdong: they're banning something only a couple of days after a new version is released?
[00:38] <jdong> ajmitch: it doesn't make much sense to me either
[00:38] <ajmitch> the world of bittorrent is full of crack
[00:39] <jdong> yeah private torrent trackers are some sort of black magic groupthink.
[01:01] <lifeless> ogra: whats up with http://www.plugcomputer.org/plugwiki/index.php/Ubuntu_9.0.4_Plug_Computer_Distribution saying karmic isn't supported?
[01:16] <ebroder> Is there a reason that Karmic has a Debian-native source package but a non-native version number?
[01:16] <lifeless> ebroder: EPARSE
[01:17] <ebroder> Err, sorry - typo. "Is there a reason that Karmic's dbus has a Debian-native..."
[01:19] <ajmitch> someone made a mistake in the upload?
[01:19] <ajmitch> or it could be intentional, it looks like it goes back a few revisions
[01:20] <ebroder> Looks like it started with the first 1.2.16 upload
[01:20] <ebroder> The 1.2.14 releases had .diff.gzs
[01:22] <ebroder> I'll file a bug
[01:23] <jdong> looks to me like it "accidentally" mutated into a debian-native package :)
[01:23] <ebroder> Agreed
[01:23]  * jdong starts a bzr-related conspiracy theory!
[01:25] <ajmitch> though if it's in bzr, it should at least mention that somewhere in the package
[01:25] <ebroder> bug #462326 if you want to follow along
[01:54] <hyperair> is there any way at all to get the $host string as autotools' configure sees it, from, say dpkg-architecture?
[02:00] <lifeless> apparently we're meant to for all packages nowadays
[02:00] <lifeless> I haven't looked up the $foo to do that
[02:04] <hyperair> well yeah
[02:04] <hyperair> but the problem is configure detects i486-pc-linux-gnu
[02:04] <hyperair> and dpkg-architecture says i486-linux-gnu
[02:04]  * hyperair grumbles. why can't it all just be standardized already?!
[02:23] <zooko> doko__: good job identifying that GNU assembler patch.
[02:37] <Rovanion> How do I get hold of makeinfo?
[02:40] <TheMuso> Rovanion: Its in texinfo I think.
[02:41] <Rovanion> Thank you, and what's the package name for the c++ g++ compiler?
[02:42] <Rovanion> I found it, build-essential
[02:51] <ScottK> zooko: So you got it firgured out?
[02:52] <zooko> doko has isolated the change to binutils that causes the problem and opened a ticket with them.  That's progress.
[02:52] <ScottK> Cool.
[02:54] <ScottK> zooko: Any way to figure out if there are affected packages in the archive?  I'd guess there are ...
[03:06] <zooko> I have no idea, but you're right that this should be investigated.
[03:06] <zooko> The first thing we can do is exclude all packages that were built before the bad binutils version.
[03:06] <zooko> The next thing is that as far as we know this affects only assembly code, not C or C+.
[03:06] <zooko> C++.
[03:06] <zooko> But I have almost no understanding of the actual issue in binutils.
[03:08] <zooko> I'm tired and I'm feeling the strong urge to play a game.
[03:08] <zooko> Buuut I guess there are a few important tasks for my open source project that I should do first...
[03:13] <zooko> Hm, I see that Alan Modra posted an example on http://sourceware.org/bugzilla/show_bug.cgi?id=10856
[03:14] <zooko> If I understand correctly this issue affects only asm code with ".intel_syntax".
[03:20] <zooko> I can't stand it anymore.  I'm giving into my craving and starting a game of Dungeon Crawl.
[06:53] <scarface[94]> hi guys. just wondering what time i will be able to update to 'karmic koala', no the RC. Preferably in AEDST.
[06:54] <TheMuso> scarface[94]: If you intend to update your system via apt-get upgrade, thats possible now.
[06:54] <scarface[94]> to the final release, not the RC?
[06:56] <StevenK> scarface[94]: Your best bet is to wait for the release annoucement
[07:04] <hyperair> YokoZar: ping
[07:05] <dholbach> good morning
[07:05] <hyperair> YokoZar: is it okay if i use i486-linux-gnu (what dpkg-architecture returns) instead of i486-pc-linux-gnu (what configure detects and places in $host)?
[07:05] <hyperair> for ia32-libs, that is
[07:05] <hyperair> morning dholbach =)
[07:05] <dholbach> hey hyperair
[07:06] <hyperair> =)
[08:31] <mvo> Riddell: bug #444979 seems to be relatively frequent on kubuntu upgrades :/ I get it here in my test machine too
[08:35] <SteveA> has something changed in ssh timeouts for karmic?
[08:36] <SteveA> I'm getting idle ssh connections closed, and they weren't doing that a few weeks ago
[08:47] <pitti> Good morning
[09:19] <soren> cjwatson: If I have suggestions for       * Colin (I just helped a bit) interviewed all the members of ~motu that are not ~ubuntu-core-dev yet and asked which future permissions they need.
[09:19] <soren> Whoops.
[09:20] <soren> Gah..
[09:20] <soren> cjwatson: If I have suggestions for http://people.canonical.com/~cjwatson/packagesets, what do I do?
[09:21] <soren> cjwatson: Just tell you here or is this tracked somewhere else where I can propose it?
[09:22] <cjwatson> soren: preferably not at all, they're automatically generated from seeds
[09:22] <cjwatson> I don't ever want to be maintaining that by hand, and I wish that Daniel had not advertised it
[09:22] <cjwatson> people are not supposed to need to look at that directly - it's an intermediate file
[09:23] <soren> cjwatson: Ah, sorry.
[09:23] <cjwatson> there are tools to look at the sets in Launchpad, which we should brush up and make easier to use
[09:23] <cjwatson> try lp:ubuntu-archive-tools, you can use edit_acl.py for this
[09:25] <soren> cjwatson: So.. Although they're based on something called seeds, this is different from the current seeds, right? If I propose adding a package to ubuntu-server, will that change anything in terms of expected support level, or is it simply about upload rights?
[09:25] <cjwatson> can I get back to you about this later please?
[09:25] <soren> Certainly.
[09:25] <cjwatson> briefly, though, there is only one meaning of "seeds" involved here
[09:25] <soren> I'll ping you later. Forget about it.
[09:25] <Mamarok> hi, I just added a comment to this bug report, seems there is a hard limitation to a max. of 1024 open files that causes crashes on various applications needing databases: https://bugs.launchpad.net/ubuntu/+bug/417025
[09:26] <Mamarok> Riddell: seb128 I subscribed you both since it affects both KDE and Gnome apps AFAICT
[09:29] <seb128> Mamarok, I've no clue about that issue but that doesn't seem a GNOME bug
[09:51] <ogra> lifeless, it's true ... we only support armv6 and above with karmic, the gcc default config is set to build with armv6 and vfp
[09:55] <Tm_T> ogra: hmm, wasn't it that way before too?
[09:55] <ogra> Tm_T, jaunty was v5 and only a selected bunch of packages was compiled with vfp (libc etc ..)
[09:56] <Tm_T> roger
[09:57]  * Tm_T is with v4 device so wouldn't notice any difference (;
[09:58] <pitti> ScottK: there are still two universe uploads in the queue; do you still think they are fine to go in? or should they be rejected and become SRUs?
[10:04] <slangasek> pitti: ScottK has re-delegated those decisions to us
[10:04] <slangasek> pitti: I only see one universe package in the -release queue, though
[10:04] <pitti> ah, lmms is -proposed, right
[10:40] <Chipzz> Mamarok: your assertion that that is a hard limit is false
[10:41] <Chipzz> since it can be configured
[10:43] <Chipzz> add a value for fs.file-max in /etc/sysctl.conf (http://www.faqs.org/docs/securing/chap6sec72.html)
[10:44] <Chipzz> Mamarok: may I suggest you do your homework properly next time? ;P
[10:54] <dholbach> pitti: bug 429322 has A LOT of duplicates
[10:55] <dholbach> looks like a new record :)
[10:59] <pitti> 158 dups? hmm, could be
[11:10] <YokoZar> hyperair: probably, I'm not sure if there's an established standard as it is
[11:11] <hyperair> YokoZar: alright then
[11:14] <dholbach> pitti: I personally think it might be just something that happens during shutdown
[11:14] <joaopinto> does anyone know the bug nr for the unuable VTs ?
[11:15] <dholbach> pitti: and apport popping up on next login
[11:15] <pitti> dholbach: yeah, I guess we'd have noticed much earlier if it was genuinely broken; I guess pretty much every developer on gnome will use that
[11:15] <joaopinto> unusable
[11:16] <dholbach> pitti: how does the traceback look to you?
[11:17] <dholbach> it didn't seem to be much to do with seahorse-plugins? something changed in gtk dealing with iconsets and stuff?
[11:19] <pitti> it doesn't tell me anything, I'm afraid
[11:19] <pitti> I'll ask Robert about it
[11:22] <dholbach> pitti: maybe we can make pedro_ fix bug 429322
[11:22] <dholbach> I'm sure he can do it
[11:25] <pitti> dholbach: I assigned it to robert_ancell for now; if you think that pedro can, feel free to reassign ;)
[11:25] <pedro_> dholbach, pitti I'm not *too* sure about that :-P
[11:26] <seb128> dholbach, crashes in iconset functions are usually corruptions
[11:26] <pedro_> dholbach, i'll fix it if you give me the patch, sure :-)
[11:26] <seb128> dholbach, ie need valgrind
[11:26] <seb128> pedro_, and by fix you mean assign the bug to me for reviewing the changes?
[11:26] <seb128> and upload too
[11:27] <pedro_> seb128, you got it ;-)
[11:27] <seb128> lol
[11:27] <dholbach> :-)
[11:58] <kevix1> I was compiling a program on jaunty, I ran the configure script and the script said some file was not present. but I checked the script and it was looking for the file only if it was '-x'. the file was present but not '-x'. So I chmod +x the file, and this make the configure script finish. should the file /usr/lib/libSDL_ttf* be +x? if so, I should file a bug?
[11:59] <cjwatson> libraries should not normally be +x. sounds like a configure script bug
[11:59] <cjwatson> (libc is an exception to this, before you say :-) )
[12:00] <kevix1> oh. the famously red-haired cj watson. wow, that is great service :)
[12:01] <kevix1> ok. that was my inclination.
[12:50] <tordne> @jstrand: hey JStrand, last time you answered me on my problem for apparmor
[12:51] <tordne> @jstrand: after two days looking on internet i just uninstalled it
[12:52] <tordne> @jstrand: I just wanted to try again and as you said it wasn't include in my /boot/config.2.6.* file
[12:53] <tordne> so I searched in the other config files and just copied the few lines from apparmor in the file currently used
[12:53] <tordne> now after restarting it said that the module was loaded
[12:53] <tordne> @jstrand: so thanks for the tip
[12:53] <jdstrand> tordne: great :)
[13:01] <snth> I changed the label for my SWAP partition and made sure to change it in /etc/fstab. However, after I reboot the kernel says that it can't resume from "the old-label" .. but everything else works fine.
[13:01] <snth> Does anyone know where is this old label at? How can I change it?
[13:13] <soren> snth: /etc/initramfs/conf.d/resume, I would guess.
[15:00] <ScottK> doko_: Do we need to worry about having misbuilt packages in the archive due to 461303?
[15:03] <doko_> ScottK: if packages directly code asm, using intel syntax, yes. I doubt these are many
[15:03] <ScottK> I suppose no easy way to find out?
[15:07] <doko_> you could search for .intel_syntax
[15:10] <ScottK> Now if only I had an local mirror...
[15:11] <doko_> maybe mvo can help, I think he has some scripts
[15:23] <Mamarok> Chipzz: sorry, had to run
[15:23] <Mamarok> also, you probalby misread what I said
[15:24] <Mamarok> Chipzz: just because one can confugre it, doesn't mean the default is set correctly, and it definitely is too low, check the number of crash reports with that error message
[15:25] <markey> ahoy
[15:25] <mvo> bug #461303
[15:25] <Chipzz> the bug-report doesn't even mention that it's about the default
[15:26] <kees> doko_: I can do that search
[15:26] <Chipzz> you say: this doesn't work, it's a bug.
[15:26] <Chipzz> which it isn't, it's a default that doesn't happen to work for you
[15:26] <Mamarok> Chipzz: that is not my report, I added a comment, read that
[15:26] <mvo> doko_, ScottK: I can create a script that crawles the archive for this, but I expect it will take a very long time to complete
[15:27] <kees> mvo, doko_, ScottK: I have a local mirror, existing scripts, and 4 CPUs.  I'll have it in about an hour.
[15:27] <mvo> cool, thanks kees
[15:27] <ScottK> kees: Excellent.
[15:27] <markey> Chipzz: may I suggest that you think before writing?
[15:27] <markey> I hear that helps
[15:28] <markey> just because you can change it doesn't make it a good default
[15:28] <markey> or sane in any way
[15:28] <markey> 1024 was a good default.. 1995
[15:28] <markey> computers have changed, our use cases have changed
[15:29] <Chipzz> markey: say what?
[15:30] <Chipzz> markey: may I suggest YOU think before writing?
[15:30] <markey> go ahead
[15:30] <Chipzz> markey: ubuntu can be installed as a desktop, as a server, as a mythtv backend/frontend...
[15:30] <Mamarok> Chipzz: you can't expect all users to know how to change that or even to know why their applications crash
[15:31] <Mamarok> and we talk about dektop applications that everybody uses, noobs
[15:31] <Chipzz> there is no such thing as one default which works for everyone of those use-cases, so the ubuntu devs probably choose the one which consumed the least resources by default
[15:31] <Mamarok> Chipzz: you one of these devs?
[15:32] <Chipzz> no, but I have substantial experience with debian and ubuntu, and have done quite a bit of unofficial packaging
[15:32] <Mamarok> Chipzz: *sigh*
[15:33] <Chipzz> actually I'm going to correct myself here
[15:33] <Chipzz> the 1024 default isn't even a default chosen by the ubuntu devs, it is the default which originates from the kernel
[15:35] <Keybuk> 1024 is the default for what?
[15:35] <Chipzz> Mamarok: and for the record, I just reread your report. Unless my reading comprehension is failing me, you do not mention this is about a default
[15:35] <Chipzz> Keybuk: maximum number of open files
[15:35] <Keybuk> if any software considers that a limit, that's a bug in the software
[15:36] <Chipzz> Keybuk: fs.max-file sysctl
[15:36] <Keybuk> Chipzz: has nothing to do with that value ;)
[15:36] <Mamarok> Keybuk: it is the default value in Ubuntu, and this is defintely too low for software that uses databases
[15:36] <Keybuk> Mamarok: then file bugs upstream on those pieces of software for not handling -ENOFILE properly
[15:37] <Keybuk> 1024 is a soft limit, the hard limit is over 1,000 times higher
[15:37] <Keybuk> apps are quite free to raise their own limit
[15:38] <Chipzz> Keybuk: Mamarok was claiming this was a hard limit, not me :)
[15:38] <Mamarok> Chipzz: I never did, I just said the default value was too low
[15:38] <slangasek> and what kind of database requires more than 1024 file descriptors?
[15:38] <Chipzz> Mamarok: you most certainly did
[15:38] <slangasek> A large database /engine/, perhaps, with dozens of dbs, but you don't say that
[15:38] <Keybuk> /proc/sys/fs/nr_open contains the hard limit
[15:38] <Chipzz> 10:25 < Mamarok> hi, I just added a comment to this bug report, seems there is a hard limitation to a max. of 1024 open files that causes crashes on various applications needing databases:  https://bugs.launchpad.net/ubuntu/+bug/417025
[15:39] <Keybuk> the default soft limit is "low" to stop buggy software from consuming vast amounts of kernel memory by opening files
[15:40] <Mamarok> well, wrong wording on my side then, still the default value is too low IMHO
[15:40] <Keybuk> the fact that your software fails to handle the returned errno certainly classifies it as buggy
[15:40] <Chipzz> Keybuk: am I misreading http://www.faqs.org/docs/securing/chap6sec72.html then? "The file-max file /proc/sys/fs/file-max sets the maximum number of file-handles that the Linux kernel will allocate. We generally tune this file to improve the number of open files by increasing the value of /proc/sys/fs/file-max to something reasonable..."
[15:40] <Keybuk> Mamarok: in my very un-humble opinion, the limit is perfect
[15:41] <slangasek> Chipzz: what does 'cat /proc/sys/fs/file-max' say on your system?
[15:42] <Chipzz> chipzz@sophos:~$ cat /proc/sys/fs/file-max
[15:42] <Chipzz> 101699
[15:42] <slangasek> that's distinctly not 1024
[15:42] <Keybuk> Chipzz: that number gets a bit randomly set ;)
[15:42] <slangasek> the only limit that's 1024 is the soft ulimit
[15:42] <Chipzz> not sure if that's the default though, but only ubuntu box I have access to right away ;)
[15:43] <slangasek> so as Keybuk says, it's an application bug
[15:43] <Chipzz> chipzz@sophos:~$ ulimit -n
[15:43] <Chipzz> 1024
[15:43] <Keybuk> that's still a soft limit ;)
[15:43] <Chipzz> yeah, just saying where the 1024 value comes from
[15:43] <slangasek> Chipzz: the default for file-max is calculated by the kernel taking the size of your available memory and shooting cosmic rays at it
[15:44] <Chipzz> cosmic rays uh? :)
[15:44] <slangasek> yes, to randomly flip bits
[15:44] <Chipzz> slangasek: is there actually a way of setting the default soft-limit for non-login shells?
[15:45] <slangasek> depends on what it is that you're trying to set a limit on
[15:45] <slangasek> if it's cron as the bug title suggests, then /etc/pam.d/cron already calls pam_limits
[15:45] <slangasek> so /etc/security/limits.conf is your friend
[15:46] <Chipzz> slangasek: general daemons started at bootup
[15:46]  * Mamarok should probably have filed a separate bug, then...
[15:46] <Chipzz> slangasek: I've run into a problem where a daemon like nginx requires more than the default number of handles, and I can't get it to work out of he box
[15:47] <Chipzz> slangasek: well, the problem is more: make sure it works without restarting the daemon. because if I log in to the box, make sure ulimit is set corectly etc, and restart the daemon, it gets the correct values. just never when booting
[15:48] <slangasek> Chipzz: usually a 'ulimit' call in the init script; upstart jobs also support setting ulimits with a 'limit' directive; I don't think trying to change the soft limit system-wide is the right way to address this
[15:48] <Chipzz> which results in having to manually log in after each reboot
[15:48] <Chipzz> slangasek: hacky :S
[15:48] <slangasek> no
[15:49] <Chipzz> slangasek: hacking an init script to include a call to ulimit is sth I'ld rather avoid ;)
[15:50] <slangasek> then convert it to an upstart job
[15:50] <slangasek> or fix the daemon to do something sensible on its own
[15:51] <Chipzz> slangasek: actually this is on a debian system so I guess off-topic for this chan ;)
[15:51] <Keybuk> limit nofile 1048576 1048576
[15:51] <Keybuk> upstart ftw
[15:52] <slangasek> Chipzz: upstart, coming soon to a Debian release near you
[15:52] <Chipzz> slangasek: oh? debian converting to upstart too?
[15:52] <Mamarok> just so you know, guys, there are roughly 20 open bugs on Launchpad that all refer to that very problem
[15:52] <Chipzz> I must have missed the memo ;)
[15:52] <kees> doko_: here is main: http://pastebin.osuosl.org/29735  universe is still running
[15:54] <slangasek> Chipzz: once a compatibility mode is available for the non-Linux ports
[15:57] <doko_> kees: none of these were built after the binutils upload, and binutils itself is a false positive (testsuite)
[15:57] <kees> sure, I think gccxml is a false positive too (it just emits it, doesn't use it itself)
[15:58] <kees> I'm getting a lot more hits in universe.  up to "r" currently.
[16:03] <tordne> tordne
[16:06] <kees> doko_: http://pastebin.osuosl.org/29738 universe
[16:06] <kees> doko_: no hits in multiverse
[16:07] <doko_> kees: what do you mean by "hits"?
[16:08] <kees> doko_: no file in the contents of a source package in multiverse contained ".intel_syntax"
[16:09] <doko_> ahh, did misread this for universe.
[16:09] <doko_> ScottK: well, then just check the list to see if any of those was uploaded after binutils 20091014 did enter the archive
[16:10] <ScottK> Will do.
[16:11] <ScottK> doko_ and kees: If the bad binutils will cause a bad build of binutils, how do we fix it?
[16:12] <ScottK> Since that's the first one on the list ....
[16:13]  * kees doesn't know about that
[16:14] <doko_> ScottK: these are false positives (the testsuite has test cases)
[16:14] <ScottK> doko_: Good to hear.
[16:14]  * ScottK relaxes
[16:19] <ScottK> doko_ and kees: Main is clear.
[16:25] <doko_> ScottK: yes, I checked for that, just not universe
[16:26] <ScottK> doko_ and kees: Universe is clear too.  Closest hit was two days before.
[16:26] <ScottK> kees: Thanks for doing the search.
[16:28] <kees> ScottK: sure, no problemo
[16:43] <cjwatson> ScottK: should such a thing happen, we'd produce temporary build chroots with an older binutils put on hold, and push through a binutils build
[16:44] <ScottK> cjwatson: Thanks.
[17:20] <rbrito> Hi there.
[17:20] <rbrito> Is there anything that can be done to get live CDs for the ports?
[17:20] <rbrito> Especially regarding powerpc?
[17:20] <rbrito> Some of the ports' CDs have not been auto-built for some time now. :-(
[17:21] <rbrito> And I would sincerely love to have a new operating system for my iBook G3.
[17:22] <rbrito> If anybody needs a hand, I'm here to help a little bit. I'm a Debian Maintainer, if that means anything.
[17:23] <rbrito> And I care about the PowerPC platform.
[17:23] <rbrito> (Actually, I care about some of what people would treat as second-class citizens).
[17:28] <rbrito> I've been keeping an eye on the live images for PowerPC and it seems that both Ubuntu, Kubuntu, and Xubuntu images are oversized.
[17:29] <rbrito> Also, the non-live images are oversized.
[17:30] <sebner> rbrito: hasn't ubuntu dropped ppc support? So nobody cares for oversized stuff, be happy that you can find that stuff still ^^
[17:30] <rbrito> BTW, talking about ports, are the ports archives mirrored?
[17:30] <Riddell> rbrito: I fear you are too late for this cycle, there's less than a day until release.  but in general people to test the images and fix whatever the issues are with them are welcome
[17:31] <rbrito> Riddell, I've filed at least one bug some days ago.
[17:31] <Riddell> rbrito: very few developers currently care about powerpc, I think it needs someone to fix the bugs rather than just report them
[17:31] <rbrito> sebner, As I understood it, the ports support would be offered on a best-effort basis.
[17:31] <ccheney> wow garmin is taking a beating from google today
[17:32] <sebner> rbrito:  well official supported ports != ports available
[17:32] <rbrito> Riddell, any pointers for how the images are auto-built?
[17:32] <rbrito> sebner, Thanks, I know that.
[17:33] <ScottK> rbrito: For this cycle the images are what they are.  It's acutally a testement to work on ports that there are live CD images at all.  It's been several releases since we managed that.
[17:33] <Riddell> rbrito: there are seeds at launchpad.net/ubuntu-seeds which create the meta packages of what should go on the CDs.  CDs are built with cdimage (also somewhere in launchpad)
[17:33] <ScottK> They should work OK if you burn them on a dvd.
[17:34] <rbrito> Riddell, Thanks for the pointer. I didn't know about the modus operandi of creation of Ubuntu images.
[17:34] <rbrito> ScottK, no DVD reader here on my iBook.
[17:35] <rbrito> Anyway, I'm offering some man-hours, if that's welcome. :-)
[17:35] <rbrito> I'd be glad to contribute in one way or another.
[17:36] <rbrito> Even if it doesn't make it the 9.10 release.
[17:36] <rbrito> (Say, if it made it to the first point release, I would be happy).
[17:36] <slangasek> there are no point releases of 9.10
[17:36] <ScottK> rbrito: We can work on it for 10.04 though.
[17:37] <ScottK> rbrito: Can your iBook boot to USB?
[17:37] <rbrito> slangasek, so, things are different regarding to Debian, vorlon?
[17:37] <slangasek> rbrito: sure, a release every 6 months is different from Debian
[17:38] <rbrito> ScottK, I think that I can, but I will have to mess with Open Firmware...
[17:38] <rbrito> slangasek, I had the impression that Ubuntu had point releases. Is that only for your long term releases?
[17:38] <ScottK> I've no idea about Mac stuff, but you can burn the image to a USB card/stick.
[17:38] <ScottK> rbrito: That's correct.  Only LTS
[17:38] <rbrito> ScottK, right. Nice to know about it.
[17:39] <rbrito> (And, BTW, I'm not only worried about Macs, but also about Linux running on some embedded computers, but I guess that this is completely out-of-scope for Ubuntu).
[17:40] <ScottK> We have only one or two developers that even have PowerPC hardware, so we need all the help we can get.
[17:40] <rbrito> ScottK, great. I'd be willing to help with that.
[17:40] <rbrito> I'm mostly doing things in Debian...
[17:41] <ScottK> rbrito: TheMuso is the guy to talk to then.
[17:41] <rbrito> Great. I will talk to Luke, then.
[17:41] <ScottK> He's in .au, so probably sleeping unless my TZ math is off
[17:41] <rbrito> ScottK, I'm in .br, which is -0200 now.
[17:42] <rbrito> (Daylight Savings Time)
[17:44] <rbrito> Well, I think that I'll install ubuntu the hard way, then (a minimal businesscard with wired connection and then a straight side-grade to Ubuntu).
[17:48] <rbrito> Well, thanks for your comments. So, for starters, I should check the ubuntu-seeds part of launchpad?
[17:52] <rbrito> OK. Thanks for all the comments.
[17:53] <rbrito> I'm going now.
[17:59] <jcastro> Keybuk: is there a way to replicate a day's slots for the rest of the week in summit? Or am I doomed to make them all by hand?
[18:01] <Keybuk> jcastro: only by SQL
[18:02] <jcastro> Keybuk: what would it cost me for you to do that for me. It will take me forever to do the rest of the days. :(
[18:02] <jcastro> name your price sire.
[18:02] <slangasek> asac: hmm, bug #455045> if a user screws up their /etc/network/interfaces and comments out lo, would NM do anything with it?
[18:04] <ebroder> So, uh, now that Karmic is spinning down, anybody from ubuntu-sru willing to take a look at bug #330766?
[18:04] <jdong> when is the big magical archive reorg due to happen?
[18:05] <ebroder> We've had a tested patch for about 2.5 months now...
[18:06] <asac> slangasek: the idea is that NM ups lo
[18:06] <slangasek> asac: ... uh.
[18:07] <asac> yes
[18:07] <asac> the code is still there
[18:08] <slangasek> blah
[18:08] <slangasek> and does NM hook into upstart, to emit net-device-up events?
[18:08] <slangasek> (or does it hook into /etc/network/if-up.d?)
[18:09] <jdong> ebroder: fastest way is probably to capture a core-dev sponsor and shove it into the -proposed queue ;-)
[18:09] <asac> if-up.d but loopback might be special
[18:09] <ebroder> jdong: I...can do that?
[18:09] <asac> oh
[18:09] <asac> slangasek: heh
[18:09] <asac> ok so the Debian backend runs /sbin/ifup lo ...
[18:09] <asac> :/
[18:09] <asac> so yeah
[18:10] <jdong> ebroder: there's never been explicit declaration whether the SRU ACK comes before the upload or vice-versa. In universe I prefer the former as it's easier to review, but for -main the SRU guys overlap quite a bit with those managing the queue anyway
[18:11] <asac> slangasek: so what behaviour do we want from NM?
[18:11] <ebroder> I see. In, uh, that case, any core-devs willing to upload the SRU fix for bug #330766? :)
[18:11] <asac> isnt it right to not up "lo" if there is no configuration in interfaces? otherwise you cannot opt-out at all anymore
[18:12] <slangasek> asac: what do you mean, opt out?
[18:12] <asac> comment "lo"
[18:12] <asac> in interfaces
[18:12] <slangasek> if someone does that, why should NM do anything?
[18:13] <slangasek> anyway, my real question here is: is NM bringing up the interface in a way that /etc/init/portmap.conf doesn't see it
[18:13] <asac> slangasek: it runs /sbin/ifup lo
[18:13] <slangasek> why does it do that at all?  /etc/init/networking.conf will already do that
[18:14] <slangasek> (and if lo is missing from /etc/network/interfaces, what is 'ifup lo' supposed to get you?)
[18:14] <ScottK> kees: New clamav release is out with (AFAICT) no security fixes in it.
[18:15] <kees> ScottK: ok
[18:16] <mvo> Riddell: can I help with bug #459471 in any way? I would love to get it into -proposed asap, otherwise I see more triage work for upgrade failures coming my way
[18:18] <Riddell> mvo: just looking at it now
[18:19] <mvo> cool, many thanks Riddell
[18:29] <Riddell> mvo: I think this should do it http://bazaar.launchpad.net/~kubuntu-members/kdebindings/ubuntu/revision/64
[18:32] <mvo> Riddell: cool, thanks. -proposed is ready for uploading, I can do a test upgrade from a ppa as well to ensure the fix works (tomorrow morning)
[18:33] <hdon> hi all. for some reason when i use valgrind --db-attach=yes, i get no debugging symbols when the debugger attaches. the backtrace is just ????. is that a known problem on jaunty?
[18:33] <Riddell> mvo: uploading then
[18:33] <mvo> Riddell: thanks
[19:33] <jmadgin> hi there! I've just come over from a convo with videolan channel, they told me you guys may be able to help! since i upgradfrom 9.04 to 9.10 my avi's dont seem to work in movie player or vlc. I checked the readout from vlc diagnostic and it said the encoder couldnt be found. I checked the encoder in synaptic and its there?
[19:33] <jmadgin> i'm tearing my hair out trying to fix this, any advice?
[19:44] <ebroder> What time will Karmic release, again? Is it midnight GMT "tonight" or "tomorrow night"?
[19:44] <jmadgin> dont kno
[19:45] <sebner> ebroder: when it's ready ;)
[19:45] <ebroder> sebner: "Will that be before or after Perl 6 and Mailman 3?" :-P
[19:45] <sebner> ebroder: tomorrow :P
[23:20] <DGMurdockIII> whats that tool that in ubuntu that run a system test then send the info back to the ubuntu dev
[23:21] <beuno> DGMurdockIII, I think it's called checkbox
[23:22] <DGMurdockIII> is that the tool the is built in to the the ubuntu os with te gui and everthing
[23:23] <DGMurdockIII> it used to be somthing else
[23:26] <ScottK> ubuntu-bug
[23:26] <ScottK> ubuntu-bug <packagename>
[23:27] <cjwatson> ebroder: we've never promised midnight, although people routinely get confused and think we have
[23:27] <cjwatson> it's, furthermore, never been anywhere especially close to midnight
[23:29] <slangasek> cjwatson: there's a LP bug that misleads people into thinking we do
[23:29] <slangasek> due dates are entered as dates and exit as timestamps
[23:32] <davmor2> cjwatson: in fact hardy was half way through the party wasn't it :D
[23:33]  * joaopinto brings some beer
[23:34] <cjwatson> slangasek: yeah
[23:35] <cjwatson> slangasek: I just have trouble believing that all the people who think it's midnight have picked it up from LP
[23:35] <slangasek> I don't :)
[23:36] <ajmitch> word of mouth spreads these vicious rumours a long way :)
[23:36] <slangasek> cjwatson: particularly when https://launchpad.net/ubuntu/karmic says "Expected in 24 minutes" :)
[23:36] <cjwatson> that doesn't help, true
[23:43] <mathiaz> kees: so I've doing some more testing with the RAID1 install
[23:43] <mathiaz> kees: Is there a reason why the array would reassemble itself automatically?
[23:44] <mathiaz> kees: use case: boot the system with one drive only.
[23:44] <mathiaz> kees: boot the system with the other drive only.
[23:44] <mathiaz> kees: boot the system with both drives again - RAID array are automatically rebuilt
[23:45] <mathiaz> kees: http://paste.ubuntu.com/303896/
[23:45] <mathiaz> kees: this^^ is after the last reboot
[23:47] <slangasek> mathiaz: shouldn't happen if both bits of the array have been written to separately, but were they?
[23:48] <mathiaz> slangasek: hm - I added a file to one of the degraded array
[23:48] <mathiaz> slangasek: but haven't touched the other degraded array
[23:49] <mathiaz> slangasek: I'm retesting and make sure that both degraded array will diverge
[23:49] <slangasek> mathiaz: so if nothing touched the other one (which would be unlikely with current filesystems, but) - the kernel has enough info to tell which one is out-of-date
[23:49] <kees> mathiaz: depends on the ordering.
[23:49] <kees> mathiaz: in some situations the raid will rebuild
[23:50] <mathiaz> kees: what surprises me is that it's done *automatically*
[23:50] <kees> mathiaz: if one or the other device had newer time stamps or something, I think it'll abort the re-build
[23:50] <kees> mathiaz: that's why the default is to _not_ boot a degraded array.  ;)
[23:53] <mathiaz> kees: ok - so now I've booted the guest twice - each time with a degraded array
[23:54] <mathiaz> kees: and created a different file with different content each time
[23:54] <mathiaz> kees: and the guest is reconfigured to have *both* drives enabled
[23:54] <mathiaz> kees: if I boot the system what should happen?
[23:55] <kees> mathiaz: you booted each drive separately with the other out of the system?
[23:55] <mathiaz> kees: yes
[23:55] <mathiaz> kees: ie drive commented out in the libvirt file and redefined each time
[23:56] <kees> ok, in theory, if you boot now with both drives in, you will boot from whichever drive udev mounts first, and the raid will refuse to add the second drive.
[23:56] <slangasek> it should allow you to boot in degraded mode if configured to do so, but not reassemble the array, right
[23:56] <kees> slangasek: right
[23:56]  * mathiaz boots the guest to confront theory with practice
[23:57] <kees> slangasek: actually, it'll boot even if you don't want degraded boot since it's a misnomer with MD RAIDs.  we should call this option "unexpected raid state".
[23:57] <kees> if you booted degraded once, md is back in an expected (though degraded) state, and will boot fine next time, since nothing "changed".
[23:57] <slangasek> ah
[23:58] <kees> we had this debate in intrepid.  oh the pain
[23:58] <slangasek> I was blissfully out of earshot :-)
[23:58] <mathiaz> kees: http://paste.ubuntu.com/303903/ - :(
[23:58] <kees> mathiaz: ok, cool, so it did an auto sync
[23:59] <kees> mathiaz: that's okay too, but is the reason degraded-boot is not the default.  the system cannot answer the question "which drive is best?" in all cases.
[23:59] <mathiaz> kees: yeah - with the earliest degraded filesystem
[23:59]  * kees nods
[23:59] <slangasek> kees: in the case he's described, both drives are dirty, it /shouldn't/ answer the question "which drive is best?" there...