[00:00] <billisnice> alpha 3 out?
[00:01] <Laney> billisnice: see /topic
[00:01] <billisnice> lol, seeing the topic would be good
[00:01] <billisnice> does ext4 install auto this time?
[00:02] <directhex> is ext4 upgradable live, the way 2->3 is?
[00:03] <Laney> I think so, but you don't get some feature or other
[00:03]  * Laney knows not much about this
[00:03] <billisnice> I still do not know how to switch to ext4? Where are the instructions
[00:04] <Laney> billisnice: Probably best for #ubuntu+1
[00:04] <RAOF> directhex: Yes it is, but some features only apply to new files.
[00:04] <directhex> RAOF, and backward compatible e.g. using the ext2 driver for windows?
[00:04] <RAOF> directhex: Not new files; they'll be using extents, which aren't backwardly compatible.
[00:05] <directhex> hm. i hope someone cobbles together a driver, then
[00:22] <NCommander> persia, you around?
[01:17] <persia> NCommander, ?
[01:17] <NCommander> persia, do you know how to modify a COPYING file to include two licenses (do I just stick the second one in there or do I need to list what files are licensed what (everything has the right header)
[01:22] <persia> NCommander, Context?  You're working upstream, and merging in code with a different license?
[01:22] <NCommander> persia, no, upstream has code under two licenses, the copying file only has one, but they're willing to change the copying file provided I give them a diff :-)
[01:22] <NCommander> (and thus also let me get the compontent into Ubuntu once I repack)
[01:24] <persia> Well, I don't know best practice for that.  My personal preference when reviewing copyright for a package is that COPYING contains information about who holds copyright over which files, and under which licenses, with pointers to external files (also in ./) for specific licenses when multilicensed, or an inline license when there is only one.
[01:26] <persia> I suspect that's against the intent, and that best practice would be for COPYING to contain something like "foo is released under the the GNU Public License version 3, and includes components bar and baz previously released under the GNU Lesser Public License version 2.1, ..."
[01:36] <NCommander> Ok, that works for me.
[02:51] <jharr> cjwatson, maxb: I'm trying to build a bootable chroot. binfmt stuff isn't working (trying to execute perl scripts with [ba]sh); e1000.ko module isn't loading automatically (am I missing a modprobe package or something?).
[02:53] <jharr> cjwatson, maxb: there's a lot of things I could hard-code for my purposes, but I'm trying to get it to work automatically. I'm building a vnfs capsule generator script for perceus and want it work on other hardware.
[02:55] <jharr> If anyone has suggestions as to where to go to ask for this sort of thing, let me know. From what I know about #ubuntu, this question is probably not well suited to that channel :p
[02:55] <persia> jharr, regarding binfmt, is binfmt-support installed in your chroot?
[02:55] <persia> jharr, It's mildly offtopic for this channel, but no, there's probably not a better place (to my knowledge).
[02:56] <jharr> persia: thx :)
[02:56] <jharr> You know, I'm an idiot for not checking this... /usr/bin/perl is there, but it's 0 bytes
[02:59] <jharr> Turns out /dev/pts wasn't being mounted by debootstrap, which borks perl's install.
[03:01] <jharr> Let me see what version of debootstrap I have (I'm doing this from a CentOS 5.2 box and an rpmforge.net verison of debootstrap, don't hit me).
[03:01] <jharr> I'll go poke around with that, thanks for the tips.
[04:35] <bluefoxicy> WARNING: The following packages cannot be authenticated!
[04:35] <bluefoxicy>   libavdevice52 libimlib2 ffmpeg
[04:35] <bluefoxicy> ^^^ is this supposed to happen  after apt-get update fails ENONETCONNECTION?
[05:06] <jharr> Installing binfmt-support in a chroot and it's borking at the "setting up" phase. Apparently because it's getting the wrong info from uname (b/c of the chroot)
[05:06] <jharr> FATAL: Could not load /lib/modules/2.6.26.5-2.nsa1/modules.dep: No such file or directory
[05:07] <dholbach> good morning
[05:08] <jharr> dholbach: good morning
[05:08] <dholbach> hey jharr
[05:14] <jharr> maybe this is in the init script for it
[05:22] <jharr> Is there any way to prevent a package from calling an /etc/init script?
[05:22] <jharr> when it's installed
[05:23] <grndslm> how do the three different repos work (regular, -updates, & -security)??  if an update is made to -security... the code in the other 2 are also updated?  or if an update's made to -updates... the code in -security isn't updated, right?
[05:24] <LaserJock> nothing goes into the regular repo after release
[05:24] <LaserJock> stuff goes into -security for security updates or -updates for critical non-security updates
[05:25] <LaserJock> but often times the stuff in -security get's copied over to -updates to take some of the load off the servers
[05:25] <karthik> hey help me where can i get info on how to create a workspace
[05:25] <LaserJock> grndslm: does that sort of answer the question?
[05:27] <grndslm> LaserJock: kinda
[05:27] <grndslm> mostly yes
[05:27] <LaserJock> karthik: what do you mean by a workspace? I'm guessing this isn't the right channel
[05:28] <karthik> LaserJock: we can some define it as a virtual desktop..
[05:30] <LaserJock> karthik: you should probably ask #ubuntu
[05:31] <karthik> LaserJock: i'm trying to implement using a c program
[06:08] <superm1> jharr, --no-start as an argument to dh_installinit.  there's a variety of other ones too for other situations.  look at dh_installinit's man page for more
[06:11] <jharr> superm1: thx
[06:13] <karthik> hey any one help abt how to create a virtual desktop
[06:13] <karthik> using a c prog
[06:28] <pitti> Good morning everyone!
[06:37] <Hobbsee> hey there pitti!
[06:38] <StevenK> pitti!!
[06:42] <pitti> I'm back from skiing, and still in one piece :)
[08:14] <tkamppeter> pitti, hi
[09:39] <apw> pitti, thanks for applying mdz's patch saves me a job
[09:40] <pitti> apw: you're welcome :)
[09:40]  * apw throws away his debdiff
[09:40] <pitti> apw: I just ran the script, and it works fine here on a Dell Latitude D430 after I fixed "pmi suspend" -> "pm-suspend"
[09:41] <apw> yeah i seem to have something installed on my test boxes which isn't standard and i don't know why
[09:42] <apw> is powermanagement-interface non-standard and if so how have i gotten it
[09:42] <apw> i was under the impression that was the official interface to these operations
[09:44]  * apw wonders how he would find out such a thing
[09:45] <directhex> hm. pitti, you're the oracle for such things. can you tell me why the "ndoc" source package is in main? are there any clues in the vast swathes of files which decide which section to put things in?
[09:46] <pitti> apw: pmi was installed by default until intrepid
[09:46] <apw> hmmm, thats unhelpful
[09:47] <cjwatson> jharr: you don't actually need binfmt-support unless you're trying to get things like Windows executables to execute automatically; #! lines are interpreted by the kernel and the only userspace support they need is for the relevant interpreter to work
[09:47] <apw> i guess i need to go get the launcher and find out what the heck it calls
[09:47] <pitti> directhex: http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.jaunty/rdepends/ndoc/
[09:48] <pitti> apw: "launcher"?
[09:48] <pitti> apw: if you mean the gnome-power-manager applet
[09:48] <pitti> apw: it does a hal call, which in turn calls pm-suspend
[09:48] <apw> i mean the thing that adds the suspend things to the menuything
[09:48] <directhex> pitti, "* Extra seed"?
[09:49] <pitti> directhex: yes, because the library is pulled in via dependencies, we keep the util in main, too
[09:49] <cjwatson> jharr: dh_installinit --no-start is useful if you're building a package but I suspect that superm1 didn't realise you were building a chroot. Usually people just want to stop daemons being started. There are a couple of ways to do that kind of thing which hook in at different levels: to stop just the daemon being started, you can dpkg-divert the start-stop-daemon program; to stop the init script being called at all ...
[09:49] <cjwatson> ... (usually), write a policy-rc.d script (see the invoke-rc.d(8) manual page).
[09:50] <directhex> pitti, hm, i wonder why antlr uses it - it's a java thing!
[09:51] <cjwatson> the antlr source package builds a libantlr2.7-cil binary package
[09:51] <cjwatson> note that the antlr->nant arc is a build-dependency not a dependency
[10:00] <directhex> bah, circular build dep between nant & ndoc
[10:07] <mdz> apw: powermanagement-interface is something which is installed by default, but it's old and should probably be superseded by more recent development
[10:07] <mdz> apw: this part of the stack needs the same sort of analysis and cleanup that slangasek is doing for hotkeys
[10:08] <apw> yeah we are doing some stuff on this on the obsolete acpi duplicate suspend machinary
[10:13] <mdz> TheMuso: I'm noticing that on both systems I've upgraded to Jaunty, my mixer levels are now muted by default, when they used to be set to sensible values
[10:14] <cjwatson> mdz: powermanagement-interface was installed by default, but is no longer in jaunty
[10:14] <cjwatson> that should be read "is no longer installed by default in jaunty" rather than "no longer exists in jaunty"
[10:14] <cjwatson> it's still installed by xubuntu-desktop for some reason
[10:14] <mdz> cjwatson: oh, good.  I didn't notice as it wasn't removed during the upgrade
[10:15]  * mdz purges it
[10:15] <mdz> a piece of history though
[10:24] <mvo> cjwatson: I guess I should add a config entry that remove it for ubuntu-desktop users then on upgrade?
[10:24] <cjwatson> mvo: hopefully it can drop to universe by jaunty release; but in the absence of that, I guess so, yes
[10:26] <mdz> apw: as I wrote in the thread, pmi is actually doing something pretty close to what you'd want (talking to hal via dbus), it's just that it's probably no longer used by much of anything except your script ;-)
[10:26] <mdz> apw: a copy/paste of the dbus-send logic might be the appropriate thing if there's no better tool for this case
[10:27] <mdz> apw: I assume we'll want a very similar script for hibernate testing which will have the same issues
[10:27] <pitti> mdz, apw: "gnome-power-cmd.sh suspend" would replicate it, but it needs to run as user, not roo
[10:27] <pitti> t
[10:28] <pitti> but you need root for programming the automatic wakeup (once that actually works)
[10:28] <apw> and its gnome specifc i guess
[10:28] <mdz> pitti: running as the user sounds like a feature
[10:28] <pitti> yes, it is
[10:28] <pitti> mdz: it would be, yes
[10:28] <mdz> though there are a couple of things in the script which require root at the moment
[10:28] <mdz> enable_trace and disable_trace
[10:28] <apw> yeah the wakeup needs root right now, but that doesn't mean we can't dip in and out
[10:28] <mdz> set_wakeup_timer
[10:29] <mdz> writing the log too
[10:29] <apw> its not impossible to split it into two cooperating halves
[10:29] <thekorn> pitti: hi, when you have a minute, can you please look at bug 314212, I'm wondering if we should work around this in py-lp-bugs by trying to reupload if lp.net/+storeblob timeouts
[10:29] <pitti> apw: you could use $SUDO_USER and such hacks, but I really think that using dbus-send to hal is the right thing to do
[10:29] <pitti> thekorn: hm, I thought that would have been fixed in LP last week?
[10:29] <mdz> apw: we'll need to do it anyway to make it fit nicely into a desktop-oriented test framework
[10:30] <apw> pitti, i tend to agree that next step is probabally to use dbus.  tehn we can work on splitting it so that it can run as user at least in part
[10:30] <mdz> I  think checkbox insists on running as root at the moment, but I'm inclined to consider that a bug (->cr3,heno)
[10:30] <apw> which would fit with what mdz is suggesting there whcih i assume would include a pretty interface
[10:31] <thekorn> pitti: me too, but there were some new reports about it over the weekend and some people complaining in #u-bugs
[10:32] <thekorn> pitti: maybe this needs a launchpad task
[10:32] <mdz> thekorn,pitti: I've had some cloakroom problems this morning as well
[10:32] <mdz> I've seen both a) apport opening file://ubuntu rather than http://launchpad.net in firefox, and b) NotFound on the +filebug URL with the cloakroom ID
[10:33] <pitti> mdz, thekorn: I wonder whether we are really talking about the same thing
[10:33] <mdz> the former was intermittent, the latter persistent
[10:33] <pitti> one was that the upload suceeded, but the +filebug/DEADBEEF page said "no such page"
[10:33] <pitti> the other is that the upload itself times out/fails
[10:34] <mdz> pitti: I agree that using dbus-send is the right thing to do, but it would be nice to abstract it away in a nice function which knows which dbus method to call and which argument to pass, etc...and we are back to pmi :-)
[10:34] <mdz> pitti: is a) either of those, or are there three different problems?
[10:34] <thekorn> pitti: right the "no such page" one was supposed to be fixed in lp last week
[10:34] <pitti> mdz: a) sounds like you are using some test backend again?
[10:35] <mdz> pitti: I literally retried with the same configuration and it worked
[10:35] <pitti> mdz: b) is bug 311690, I believe
[10:35] <mdz> well, a different crash report actually, but otherwise the same
[10:35] <pitti> mdz: if you have a reproducer for file://ubuntu, can you please mail me/create a bug report?
[10:36] <mdz> pitti: 311690 was workaroundable before by waiting a few seconds and reloading; this time it's persistent
[10:36] <pitti> so this needs to be reopened then?
[10:37] <tseliot> hey pitti
[10:37] <pitti> hey tseliot
[10:38] <mdz> pitti: I can reproduce every time on this crash file, I'll send it to you
[10:40] <mdz> pitti: while we're on the subject, I was thinking about whether it's still a good idea to defer collecting the hook information etc. until the user is notified about the report.  don't we have a beter chance of getting accurate and relevant data if we run the hooks and collect package info immediately when the crash happens?
[10:41] <pitti> mdz: two reasons for this: (1) hooks often collect user data (gconf keys), but kernel-triggered apport runs as root, and (2) hooks can potentially take a lot of time, which doesn't have a progress bar when the crash happens
[10:41] <pitti> mdz: however, for quick hooks which depend on timely information, we could have another class of hooks which run right away
[10:42] <mdz> pitti: (1) is a legitimate concern, and perhaps there should be two types of hooks.  we already have both hooks which break because they require root, and hooks which expect user context (e.g. an X display)
[10:42] <mdz> pitti: regarding (2), I think it's OK to run them in the background with high nice+ionice and not worry about how long it takes
[10:43] <mdz> pitti: sometimes I've already installed updates before I report the bug, and the package info will be wrong
[10:43] <pitti> mdz: oh, and a third reason is that at the time when the crash happens, we don't even know which package it belongs to
[10:43] <mdz> pitti: it also makes it harder for things like X, which wants to get the log file before it's rotated away
[10:44] <mdz> pitti: we can look that up, the only reason we don't do it is (2) right?
[10:44] <pitti> mdz: right, because dpkg -S takes so awfully long
[10:44] <mdz> not only because it takes so long, but because it bogs down the system (I think ionice -c3 would address that)
[10:45] <pitti> mdz: ionice/nice would take care for the "bog down system" only partially
[10:45] <pitti> since you still need to wait for that long until the app actually disappears and you can restartit
[10:46] <pitti> but in a dev release that's certainly bearable
[10:46] <mdz> pitti: why? it should be possible to collect the info after the process has ended
[10:47] <pitti> hmm
[10:47] <pitti> apport could fork()/setsid() itself after collecting core dump and /proc, probably
[10:47] <seb128> what is the discussion about? running apport on stable versions?
[10:48] <pitti> seb128: no, running hooks when the crash happens, as opposed to when the UI runs
[10:48] <seb128> ah ok
[10:48] <pitti> running it on stables is not just a performance issue (that's actually the least important reason)
[10:54] <tseliot> seb128: I have fixed this bug and provided upstream with patches (which are no longer workarounds): https://bugs.edge.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/307306
[10:54] <seb128> tseliot: that was not a gnome-settings-daemon bug then?
[10:55] <tseliot> seb128: it was a bug in both gnome-settings-daemon and gnome-power-manager. They use an expensive RandR call every time an event is triggered
[10:55]  * pitti hugs tseliot
[10:56] <seb128> tseliot: ok
[10:56] <tseliot> pitti: the patches are in the upstream reports, if you want to try them
[10:58] <cjwatson> doko_: have you noticed that there are comments in bug 235070 indicating that it isn't fixed in hardy?
[10:59] <cjwatson> (despite the presence of that patch in hardy-updates)
[11:07] <apw> cjwatson, is it reasonable to rely on the fact that a dpkg-buildpackage will 'clean' your source tree before packaging it|
[11:07] <cjwatson> apw: yes
[11:08] <cjwatson> (there's an -nc flag in case you don't want that)
[11:08] <apw> and would it be reasonable to fix permissions in your source tree while cleaning it
[11:08] <apw> you can't say -nc with -S its not legal
[11:08] <cjwatson> yes, but it might be better to fix permissions just before using the scripts in question
[11:09] <cjwatson> actually, I think I may have misunderstood you
[11:09] <cjwatson> you cannot rely on clean being run after extraction
[11:09] <cjwatson> and adding executable bits before building the source package will do you no good - they need to be applied after extraction
[11:09] <apw> so there is no hook for makeing sure the tree is ready
[11:09] <cjwatson> do it in the build target instead
[11:09] <cjwatson> sure there is, 'build' :-)
[11:10] <cjwatson> build can depend on whatever it needs
[11:10] <cjwatson> (or just do it inline)
[11:10] <apw> and thats safe in the face of parallel builds
[11:10] <cjwatson> if debian/rules is written correctly, yes
[11:11] <apw> got any info on what 'correctly' is in this cas
[11:11] <apw> case
[11:11] <cjwatson> info make
[11:11] <cjwatson> I believe it has information on ordering
[11:11] <cjwatson> for example, 'build: dep1 dep2' means that dep1 and dep2 may be run in parallel, while 'build: dep2' and 'dep2: dep1' means that dep1 must be completed before dep2 starts
[11:12] <apw> that would make sense to my expectationh of make behavior
[11:12] <apw> ok will try it that way.  i do not want to fix every build target for the kernel, its toooo likely to go wrong
[11:13] <cjwatson> you already have prepare- targets in debian/rules.d/2-binary-arch.mk
[11:14] <apw> yeah but they are for the binary components, and i need to ensure i beat the headers too
[11:15] <cjwatson> you can also call debian/rules recursively if it makes things easily
[11:15] <cjwatson> easier
[11:16] <cjwatson> so 'rulename:\n\tchmod blah;\n\tdebian/rules prereq1 prereq2'
[11:16] <cjwatson> policy and the dpkg-dev toolset just specify a minimal interface - it's for maintainers to build richer things on top of that
[11:16] <apw> i think i can use the same prepare concept in here for everything, have a general prepare
[11:17] <apw> its just a lot of complexity to paper over the loss of information in the packaging system.  sigh
[11:36] <luisbg> is it a holliday today in the USA?
[11:37] <directhex> MLK today
[11:37] <directhex> i think that's an optional holiday
[11:37] <luisbg> directhex, ok cool thanks
[11:37] <apw> optional?
[11:37] <luisbg> :)
[11:37] <tkamppeter> pitti, please do not yet upload CUPS or pass through my upload into-proposed (bug 310575). I have still to add a fix.
[11:39] <pitti> tkamppeter: ok; I rejected it from the intrepid queue
[11:41] <ogra> urgh, hall in C++ ?
[11:41] <ogra> *hal
[11:41]  * ogra is scared
[11:44] <tseliot> ogra: are you talking about libhal++ or what?
[11:45] <ogra> tseliot, about the recent annoucement on the hal ML
[11:45] <ogra> yes, seems to be libhal++
[11:45] <ogra> a fork/reimplementation
[11:46] <ogra> "HAL/C++ is a _reimplementation_ of libhal and libhal-storage in pure C++, using dbus-C++."
[11:46] <tseliot> aah, this one: http://projects.backtrace.info/pmwiki.php?n=Main.Halmm
[11:46] <tseliot> ok
[11:46] <ogra> right
[11:47] <tseliot> sooner or later we'll use DeviceKit
[11:47] <ogra> "It is modeled after the original libhal and libhal-storage, but does not aim at complete adherance to the original API."
[11:47] <ogra> thats scary
[11:47] <tseliot> it depends on what you plan on doing with it
[11:47] <ogra> well, apps will still use libhal for quite a while ... it takes its time until linked apps will switch
[11:48] <broonie> ogra: It does make some sense to have an API that makes sense in the language you're working with rather than another language that happens to link with it.
[11:48] <ogra> broonie, right, but it doesnt make sense to reimplement it in a fresh fork ...
[11:48] <ogra> instead of just adding to the existing code and thus keep API/ABI compatibility
[11:51] <broonie> Uh, doing something sensible in $OTHER_LANGUAGE rather implies breaking those; one of the wins with DBusing stuff is to keep a cross language ABI at the DBus level rather than lib level.
[11:56] <ogra> well, still new implementation requires new documentaion etc etc ... while as tseliot says a completely new system is in the work
[12:01] <Keybuk> mvo: do you know of anything that would call udev{adm ,}trigger on an upgrade?
[12:15] <james_w> is it fine for any old package to use lzma compression and Pre-Depend on the relevant dpkg version?
[12:17] <pitti> james_w: for most, anyway; it should probably be avoided for base packages, to avoid breaking debootstrap
[12:17] <james_w> it's easystroke in universe
[12:17] <james_w> the contributor, and upstream maintainer, added it in the latest upstream version, I just wanted to make sure it wasn't against policy
[12:31] <tkamppeter> pitti, I have released Foomatic 4.0 last week. Intrepid ships only a BZR snapshot. The BZR snapshot has some bugs, once Intrepid does not pass the LSB 3.2 compliance tests (http://bugs.linuxbase.org/show_bug.cgi?id=2423) and second, there are two bugs reported to Ubuntu: bug 299918 and bug 303691
[12:32] <tkamppeter> So I am thinking about an SRU for Intrepid updating foomatic-filters to 4.0.0 final.
[12:32] <pitti> tkamppeter: are any of those regressions from hardy?
[12:33] <tkamppeter> Yes, as Hardy still shipped the Perl version (3.0.x) of foomatic-filters. All three bugs did noty occur with that version.
[12:35] <pitti> tkamppeter: remember that if you upgrade to the final 4.0, *all* of the changes have to pass SRU criteria, otherwise we should just backport the specific changes (if they are serious)
[12:45] <tkamppeter> pitti, concerning bug 310575 now everything is ready, new fix committed to the BZR and uploaded to -proposed.
[12:49] <Keybuk> what's the right format of version number for an upload to hardy-propsed?
[12:49] <ogra> oldver.1
[12:49] <ogra> and make sure to not clash with security :)
[12:51] <Keybuk> do you have to upload with hardy-proposed in changelog or hardy?
[12:51] <mvo> Keybuk: udev-triggered-on-upgrade> no, but I can try to find out more about it - does it seem to happen on a standard upgrade?
[12:51] <Keybuk> mvo: I guess - mdz is the only person to have reported it so far
[12:52] <pitti> mvo: any idea what to do with bug 241431?
[12:52] <mvo> pitti: uf, the proper fix is to backport the code from the jaunty version so that it auto-detect if it needs to use archive.u.c or old-releases.u.c
[12:53] <mdz> Keybuk: I'm on the machine now; is there anything I can look at for clues?
[12:54] <Keybuk> mdz: I'm surprised there's nothing in /var/log :-/
[12:54] <mvo> Keybuk: ok, is this for bug #317944 ? I have a look on my auto-upgrade testing image if it shows a similar behavior
[12:54] <Keybuk> mvo: right
[12:55] <mdz> Keybuk: syslog shows that syslogd was restarted a few minutes after the ctime on /dev/null, which explains why its socket is unmangled
[12:55] <Keybuk> mdz: no messages from udevd?
[12:55] <pitti> mvo: I don't feel we should do that for feisty, but for gutsy/hardy/intrepid it might be worthwhile?
[12:55] <pochu> Keybuk: hardy-proposed
[12:55] <mvo> pitti: ok
[12:56] <mdz> Keybuk: none (ever, so far as I see)
[12:56] <mdz> the only occurrence of 'udevd' is in dmesg
[12:56] <Keybuk> right, it'll be in your dmesg history
[12:56] <Keybuk> kern.log has timestamps
[12:57] <mdz> Keybuk: it's not in kern.log at all
[12:57] <mdz> dmesg.0:[   20.478679] udevd version 124 started
[12:57] <mdz> dmesg.1.gz:[   22.546635] udevd version 124 started
[12:57] <mdz> dmesg.2.gz:[   19.596002] udevd version 124 started
[12:57] <mdz> dmesg.3.gz:[   18.636002] udevd version 124 started
[12:57] <mdz> dmesg.4.gz:[   19.456003] udevd version 124 started
[12:57] <mdz> those are the only occurrences
[12:57] <mdz> (notably, it isn't in my current dmesg)
[12:58] <lool> bug #223324 has 32 dups and seems to be a dup of bug #221781; is there a way to mass fix the dups of 223324?
[12:59] <lool> If not, I think I'll just close 223324 and point at the other bug in a comment
[13:00] <pochu> lool: not that I know of from Launchpad, but maybe bdmurray has a script to do it with python-launchpad-bugs
[13:01] <pochu> I think I heard about such a script in the past
[13:02] <james_w> https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-March/000800.htm
[13:02] <james_w> https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-March/000800.html I mean
[13:04] <lool> james_w: Thanks
[13:05] <lool> It looks like I should spend some time to clean it up and integrate with u-d-t
[13:06] <seb128> is there anybody working on freetype in ubuntu or talking to upstream sometimes?
[13:07] <seb128> bug #277294 has quite some duplicate
[13:07] <seb128> doko_: http://lists.gnu.org/archive/html/freetype-devel/2008-08/msg00023.html indicates that could be a gcc issue, could you perhaps investigate this one?
[13:27] <Keybuk> mdz: just to confirm something
[13:27] <Keybuk> mdz: /etc/udev/rules.d is basically empty on your box, right?
[13:31] <mvo> Keybuk: upgrade is running, it will be finished in ~30min
[13:36] <soren> I'm working on a new package. It's somewhat lacking in the clear licensing area.  Only a select few source files specify the license, there's no "top level" license file or anything (the few source files with licensing information correctly state the copyright holder and references the Apache license).
[13:37] <soren> I'm curious what the minimum to ask them to add would be for it to be acceptable for us.
[13:37] <soren> I suspect this is not uncommon, so perhaps someone has already written up a template bug text for this sort of thing?
[13:43] <Keybuk> generally a top-level licence is enough
[13:43] <Keybuk> but that licence will likely say each source file should have a reference to it too
[13:43] <cjwatson> missing licences from individual source files is a widespread failure/practice (depending on your POV)
[13:44] <cjwatson> the GPL just says that it's "safest" to add notices to each source file, not that you must
[13:45] <cjwatson> I think the idea there is that if you don't, people might rip out an individual file and say that they didn't know about its licence
[13:45] <mok0> cjwatson: It's an exception that people do it
[13:45] <mok0> cjwatson: exactly
[13:45] <cjwatson> mok0: I wouldn't go that far but it certainly isn't anywhere near universal
[13:45] <Keybuk> we still permit such things in the archive though
[13:45] <cjwatson> I have never heard of a legal basis for saying that a top-level licence wouldn't apply to the other files
[13:46] <mok0> The problem is: if just a couple of files are missing license clause, is it because upstream forgot, or did he rip the file off somebody
[13:46] <ogra> though if you want your package to enter debian at some point you better add a license note to each single file :)
[13:46] <cjwatson> a judge would not be looking at the individual files; he/she would be looking at the whole thing, and if there's a top-level file that says "everything in this package is under licence foo", then you'd have a pretty damn hard time persuading the judge otherwise
[13:47] <mok0> ogra: is that a requirement for Debian?
[13:47] <ogra> mok0, not sure, but i had a bunch of packages i had to work on, even if its not, you will drown in a bunch of bugs about it there
[13:47] <cjwatson> Debian's ftpmasters will complain about inconsistent licences of course, but I've never heard of them complaining about missing licence statements in individual source files
[13:47] <cjwatson> and I would be extremely surprised if they did
[13:48] <mok0> cjwatson: I've done a ton of reviews, and I rarely see the license clauses included properly
[13:48] <ogra> no, its rather the self declared debian license police that pokes you with bugs about it :)
[13:48] <cjwatson> some Ubuntu archive administrators have got into the habit of complaining about that, and personally I think it is substantial overkill
[13:48] <soren> cjwatson: Ok. So if I ask them to add the Apache license to the tarball and have them put a file that said who the copyright holder is and references the Apache license, that would acceptable?
[13:48] <cjwatson> soren: yes, I'd say so
[13:49] <soren> cjwatson: Lovely. Thanks!
[13:50] <mok0> I've been telling uploaders that without a license file in orig.tar.gz, we can't distribute the package
[13:50] <mok0> I've also told them to _attempt_ to get upstream to add clauses to indiv. file
[13:50] <mok0> s
[13:50] <cjwatson> yes, you clearly must have some statement of the licence in the tarball
[13:50] <cjwatson> well
[13:50] <cjwatson> actually, I think it's permissible to get an e-mail clarification from upstream and to put that in debian/copyright, pending a new upstream release
[13:50] <cjwatson> I have done that myself in the past
[13:51] <mok0> cjwatson: that's a good idea
[13:52] <ia> hello. i use alpha-3 with latest updates. http://www.markshuttleworth.com/wp-content/uploads/2008/12/jaunty904_notifications_example1_web_092.swf - this notification system looks very useful, but how can view it in action? i mean, which apps and what kind of events supports such notifications? and technical question - it's just some impove of notification-daemon, or something else? and where i can find out, which api's in which languages allow to initiate s
[13:52] <ia> uch notifications? i will be very appreciate for any useful information :-)
[13:54] <cjwatson> ia: that's work in progress, not (as far as I know) yet in jaunty
[13:54] <ia> cjwatson: oh, right. just in some news they tells, that it's already can be seen in work :-)
[13:58] <ia> however, how do you think, it's some layer over notification-daemon, or some brand new notification system? if second, then how it names?
[14:03] <cjwatson> ia: no idea, sorry
[14:06] <mvo> Keybuk: during my upgrade test in kvm I got no udevd started message (except for one) and the /dev/null permissions look ok too - that was a default ubuntu-desktop base-image that I used for the test
[14:06] <superm1> cjwatson, jharr yes i didn't realize that jharr was building a chroot. thanks for the extra comments
[14:52] <lool> james_w, pochu: Pushed new lp-set-dup script in ubuntu-dev-tools
[14:54] <james_w> lool: cool, did you port it to lplib? :-)
[14:54] <lool> Yes
[14:55] <james_w> ah, nice, thanks
[14:56] <pochu> lool: in the end, bug 78596 should be fixed, but for the meantime that'll be useful :)
[14:56] <lool> pochu: Agreed
[14:56] <lool> james_w, pochu: BTW happy to get any review
[14:58] <lool> jpds: Hey I pushed some 3/4 ubuntu-dev-tools changes; I'd like to upload the package, but would love you to have a look to check I didn't break anything; how are you building the package?  debuild -i good enough?
[15:00] <james_w> lool: looks pretty good to me. Would it be better to do the obvious thing if I request a bug be duplicated against a bug that is already a duplicate of something else?
[15:00] <james_w> though the rarity of that situation and the added complexity of doing a check for circular references may not be worth it
[15:01] <tkamppeter> pitti, back to the foomatic-filters 4.0.0 SRU, all changes (see newest changelog entry in Jaunty package) are bug fixes, and for me it looks like that all are regressions against Hardy. And the Infinite loop when supplying a page range is even a security vulneribility, as a user can block the printing system by sending a job with page-specific option setting.
[15:02] <tkamppeter> pitti, every fix by itself is a small patch (up to 10 modified lines), only the modification to fix the infinite loop is somewhat bigger.
[15:03] <lool> james_w: I preferred failing and offering the good command line to run
[15:03] <pitti> tkamppeter: do we have some LP bugs which correspond to the changes? please use those for the SRU
[15:03] <lool> james_w: (just need to copy paste the suggested command line)
[15:03] <james_w> yeah, it's sensible, but a tool telling you *exactly* what to run is normally pretty bad UI
[15:04] <james_w> the safety check may justify it though
[15:04] <tkamppeter> pitti, for the two items mmarked appropriately in the debian/changelog, yes, I can at least add another one for the infinite loop vulnerability.
[15:04] <lool> james_w: I didn't want to autofix it, but I guess I could prompt to ack the change and proceed indeed
[15:05] <james_w> that could work
[15:05] <liw> what's the proper way of asking for an application to be included in the default Ubuntu desktop install?
[15:06] <pochu> lool: on line 52, suggestion is unused, isn't it?
[15:06] <pochu> as you're dying in the next line without using it
[15:06] <lool> pochu: ah thanks, forgot to drop a die() on line 53
[15:07] <lool> pochu: (fixed)
[15:16] <lool> james_w: I implemented prompting to use the duplicate of main bug
[15:17] <james_w> thanks lool, you rock
[15:17] <lool> Eh thanks for the good comments
[15:19] <tkamppeter> pitti, I have reported the infinite loop problem as bug #318816
[15:28] <tkamppeter> pitti, I have also reported bug 318818 now.
[15:29] <pitti> tkamppeter: is the lsb failure actually something to worry about? it's not something SRU worthy per se
[15:30] <tkamppeter> pitti, I do not know how important LSB failures are considered at Ubuntu. Therefore I reported that. Most important is the infinite loop, and all the rest can be considered as regressions against Hardy.
[15:43] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek to start in #ubuntu-classroom in 17 minutes
[15:55] <NCommander> DktrKranz, ping
[15:55] <cjwatson> pitti: can you have a look at http://launchpadlibrarian.net/21351698/buildlog_ubuntu-jaunty-i386.glib2.0_2.19.5-0ubuntu1_FULLYBUILT.txt.gz ? It looks as if pkgstriptranslations is running twice in parallel on the same package, and the result is a corrupted translations tarball (which is crashing the publisher, which is how we noticed it)
[15:57] <apw> pitti, apport -- when a report is generated i assume its the reporting script's reposinsibility to prevent a double trigger of the report?
[15:59] <grndslm> could somebody please unban me from #ubuntu....  i made one funny ha ha and somebody screamed for the ops
[16:00] <pitti> apw: double trigger? if you mean it triggers while you are still writing it: you need to create it as 000, write it completely, and then chmod it to 600
[16:00] <pitti> cjwatson: looking
[16:00] <cjwatson> grndslm: this isn't an escalation channel - go to #ubuntu-ops, please
[16:00] <grndslm> k thanks
[16:01] <apw> no i mean if i find file /foo and that is my trigger, when i converted that into a spool file, i assume it is _my_ responsibility to remove /foo as well
[16:02] <pitti> cjwatson: ugh, how weird; I don't have an offhand idea, I need to try and reproduce this in a chroot
[16:02] <pitti> apw: it could be done in the apport init script if you don't need it any more for other purposes
[16:04] <apw> my worry is if we don't will we not file the same bug every boot from then on
[16:04] <tkamppeter> pitti, I have added everything for the foomatic-filters SRU to bug 318816 now (you are subscribed to it) and nominated the bug 303691, bug 299918, and bug 318818 for Intrepid.
[16:05] <apw> pitti, ahh we do remove it anyhow, good
[16:06] <jharr> cjwatson: thx for the help. I now realize that with binfmt-support. Somewhere along the line /usr/bin/perl was fine in the chroot, but perceus builds a cpio archive (which was fine) but the kernel apparently has issues decompressing cpio archives that have hardlinked files in them.
[16:06] <cjwatson> jharr: the *kernel* - are you sure? that should be entirely userspace and using only very common syscalls
[16:06] <jharr> cjwatson: perl was ending up as a zeroed file.
[16:06] <cjwatson> if link(2) is failing you have pretty bad problems!
[16:07] <cjwatson> sure, you described the symptoms earlier; I was questioning your attribution of the cause to the kernel
[16:07] <jharr> cjwatson: the cpio archive was the initrd.
[16:07] <cjwatson> ah, I see
[16:07] <cjwatson> you have perl in your initrd?
[16:08] <jharr> cjwatson: yeah, perceus is a tool to pxeboot stateless clusters.
[16:09] <apw> jharr, can't you remove the links in there, and remake them after boot (if the kernel support is inadequate)
[16:09] <cjwatson> jharr: scary. just make them symlinks then, I suppose
[16:09] <jharr> cjwatson: There are several things that could go wrong in between. I won't attribute it to a kernel bug, but I'm going to continue on in my work until I have time to poke around at that specific issue...
[16:09] <cjwatson> well, no, if it's in the initrd you're probably right, that's unpacked entirely in kernelspace
[16:10] <jharr> I do just remove the links for now.
[16:11]  * ogra wonders where to find more infor about a debootstrap error ...
[16:11] <ogra> W: Failure trying to run: chroot / dpkg --force-depends --install
[16:11] <ogra> seems to break at the beginning of the second stage
[16:12] <pitti> thekorn: with p-lp-bugs, can I get the bug's original description somehow?
[16:12] <cjwatson> ogra: /debootstrap/debootstrap.log in the chroot (probably; find -name debootstrap.log)
[16:12] <ogra> well, the prob is that its not a chroot and i cant get that log easily
[16:13] <ogra> its http://people.ubuntu.com/~ogra/arm/build-arm-rootfs
[16:13] <cjwatson> there is a bug about the lack of feedback there
[16:13] <ogra> wrapping the second stage into qemu
[16:13] <cjwatson> oh
[16:13] <ogra> and its not my error, but a users
[16:13] <cjwatson> ogra: upgrade debootstrap to the current version in jaunty
[16:13] <cjwatson> I fixed that very bug last week
[16:13] <ogra> i dont want him to upload his 4G image :)
[16:13] <thekorn> pitti: you mean without removed whitespaces?
[16:13] <thekorn> pitti: .description_raw
[16:13] <cjwatson> (or tell the user to do so; whatever)
[16:14] <ogra> oh, he might be running it on intrepid
[16:14] <pitti> thekorn: no, that's not the originally filed one
[16:14] <thekorn> pitti: ok, got it now, no you cannot
[16:14] <cjwatson> see the debootstrap 1.0.10ubuntu2 changelog; the command was supposed to be 'chroot / dpkg --force-depends --install libc6' but the variable that expands to 'libc6' wasn't being set in --second-stage mode
[16:14] <pitti> thekorn: bug 315728, someone added stuff below the apport data
[16:15] <pitti> thekorn: and in the middle of apport data there are empty lines
[16:15] <ogra> ah
[16:18] <lool> directhex: Hey, I heard you're working on the C# transition which affects f-spot, beagle, tomboy in the default install; it's been some days that these prevent upgrades; is there a bug for whatever blocks progress right now?
[16:18] <thekorn> pitti: if you need it, file a bug, I'm happy to add .original_description, should not be hard
[16:19] <thekorn> or use launchpadlib, it's bug.messages[0] there
[16:19] <pitti> thekorn: I think I'll just try and work around it, since i need to add some code to deal with the empty lines anyway; then it'll also work in stable versions
[16:19] <pitti> thekorn: launchpadlib> can't yet, due to firewall restrictions on the DC host :(
[16:23] <|ntegra|> hello
[16:23] <|ntegra|> I have an idea for ubuntu, but I am not a programmer
[16:24] <cjwatson> brainstorm.ubuntu.com is the place you want, then
[16:24] <|ntegra|> thanx cjwatson
[16:27] <DktrKranz> NCommander: (late) pong
[16:28] <NCommander> DktrKranz, what's the status of dietlibc in Ubuntu?
[16:29] <DktrKranz> NCommander: I had some tests on i386 and amd64, those archs are in good shape. I have some doubts about sparc and ppc, though and I have no hardware to test.
[16:30] <NCommander> DktrKranz, I'm looking at ARM ATM
[16:30] <NCommander> It cores when built with DEBUG=0, but works when built with DEBUG=1
[16:30] <NCommander> :-/
[16:30] <DktrKranz> ah...
[16:30] <DktrKranz> it's probably related to stack protector
[16:31]  * NCommander tries removing that
[16:32] <NCommander> DktrKranz, ARM EABI support only exists in CVS HEAD, whats your feelings on going to a CVS version?
[16:33] <DktrKranz> there were some commits since current version, some interesting ones for ARM, IIRC
[16:33] <jpds> lool: Everything looks OK to me, I build the package by copying it to /tmp, rm -rf .bzr there and debuild -S -sa.
[16:38] <DktrKranz> NCommander: if you want, I can prepare a snapshot upload, have you some PPC hardware to test it? I'd like to readd stack protector support
[16:38] <NCommander> DktrKranz, I can give you a shell on my PowerPC box
[16:39] <DktrKranz> NCommander: that's would be awesome
[16:39] <lool> jpds: Ok; I think you could use "debuild -i -S -sa" instead to skip the copying step if you like; -i will also ignore .bzrignore which is why I was asking how you do it
[16:39] <NCommander> DktrKranz, if I do the same on my ARM box, can I get working ARM support :-)?
[16:39] <DktrKranz> NCommander: I can give it a try
[16:40] <DktrKranz> just prepare me a chroot/pbuilder
[16:40] <NCommander> Well, I'm building diet ATM with -fno-stack-protector to see if I still get a core dump
[16:40] <NCommander> Ugh
[16:40] <NCommander> I think its a problem with -Os
[16:40] <NCommander> :-/
[16:43] <jpds> lool: I don't know what -i does, can't find it in the manpages..
[16:44] <lool> jpds: It's a dpkg-buildpackage falg
[16:44] <lool> Which tells it to use its default exclusion res
[16:44] <lool> jpds: Sorry, I was actually hinting at the wrong flag: it's -I
[16:44] <lool> (I actually pass -i -I via ~/.devscripts)
[16:44] <lool> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-I -i"
[16:45] <apw> pitti, i am trying to test this apport stuff and when i respond to the '*' on the task bar, i get as far as submitting the thing and it tries to send my browser to file:///ubuntu/+source/linux/...
[16:45] <apw> that sounds wrongo
[16:46] <jpds> lool: Oh, neat. Feel free to upload when you want.
[16:47] <lool> jpds: done
[16:48] <apw> pitti, also when it took me to launchpad it didn't have a title set and as i'd not been told anything much about the bug i might not have had a clue what to put in that box?
[16:48] <jpds> lool: Thanks! :)
[16:48] <lool> jpds: BTW I keep getting this on upgrades:
[16:49] <lool> dpkg : ubuntu-dev-tools : avertissement - le conffile « /etc/bash_completion.d/pbuilder-dist » n'est ni un vrai fichier ni un lien (= « /etc/bash_completion.d/pbuilder-dist »)
[16:49] <lool> (file is neither a real file nor a symlink)
[16:49] <lool> And indeed it's a directory
[16:49] <pitti> apw: curious, mdz sent me a similar problem today; I'll look into it
[16:49] <jpds> lool: OK... I personally don't use bash, I think \sh wrote that.
[16:50] <lool> jpds: I don't use bash either, but I get this while installing hte package
[16:50] <lool> In the package I see:
[16:50] <lool> -rw-r--r-- root/root       919 2008-08-18 11:54 ./etc/bash_completion.d/pbuilder-dist
[16:50] <lool> But on my system it's a dir
[16:50] <jpds> Hmm.
[16:51] <lool> Probably since:
[16:51] <lool>   * debian/ubuntu-dev-tools.install: install bash_completion/pbuilder-dist in
[16:51] <lool>     /etc/bash_completion.d/ instead of /etc/bash_completion.d/pbuilder-dist/
[16:51] <lool> Presumably this required some preinst on upgrades which was forgotten
[16:54] <apw> pitti, how does apport decide to push some information into the main body, or as an attachment?
[16:55] <pitti> apw: if it's text, and < 5 lines, it gets into description, otherwise attachment
[16:55]  * pitti -> dinner
[16:55] <apw> hmmm
[17:05] <lool> jpds: Could you check out the preinst snippet I added?  Not perfectly pretty, but couldn't find a way to have it much cleaner but still safe
[17:05] <lool> jpds: Works for me on upgrades; not that I get a conffile merge prompt because I upgaded across multiple versions without really getting the new conffile
[17:07] <jpds> lool: Looks OK; I personally have it installed as a file... no idea where the dir came in.
[17:11] <lool> jpds: For people upgrading between the time the error was introduced and the time it was fixed
[17:12] <mdz> Keybuk: re: CVE-2008-4311, which releases are affected?
[17:12] <Keybuk> mdz: all, ever
[17:13] <lool> jpds: pushed tagged updated changelog for next version uploaded
[17:14] <lool> +,,,,
[17:14] <mdz> Keybuk: ah, I skimmed over the bit that said it was believed not to be exploitable
[17:14] <Keybuk> mdz: right
[17:14] <mdz> Keybuk: so no action is needed in stable releases, but we should fix things up going forward in Jaunty?
[17:14] <Keybuk> so D-Bus was passing messages by default, instead of denying them
[17:14] <Keybuk> but it turns out that's basically ok, since most messages should have been allowed
[17:14] <Keybuk> and the few services that have privileged messages actually took care to deny them to other people anyway
[17:15] <Keybuk> (which implies they tested their policy, found they got through, added the deny rules ... and didn't think to ask anybody why that worked when it shouldn't have :p)
[17:15] <Keybuk> so we can breathe a bit of a sigh of relief, and just fix things going forwards
[17:16] <jpds> lool: Thanks for the fix.
[17:17] <lool> thanks for the review
[17:20] <tseliot> Keybuk: ok, point taken ;)
[17:20] <Keybuk> tseliot:
[17:20] <Keybuk> ?
[17:21] <tseliot> Keybuk: about fixing apps which rely on dbus e.g. my policykit stuff
[17:21] <Keybuk> tseliot: you fixed your ages ago ;)
[17:22] <tseliot> Keybuk: in Jaunty, it wasn't uploaded to Intrepid though.
[17:22] <Keybuk> tseliot: shouldn't need to be aiui
[17:23] <tseliot> ok
[17:23] <apw> pitti, i have proposed a branch for merging to apport, does that get to you direct?
[17:24] <doko_> pitti: which package should bug #318507 be assigned to?
[17:25] <Keybuk> is that a bug?
[17:25] <Keybuk> surely C has no specific first day of the week?
[17:27] <apw> i think the complaint is that the result has changed between intrepid and januty not that it is one day or another
[17:27] <pitti> doko_: isn't C defined in libc6?
[17:29] <apw> and cirtainly that appears to be true here too
[17:29] <ScottK> pitti: Is there a web resource for "I want my package to use apport when it crashes, what do I need to know."?
[17:29]  * ScottK has an upstream he's hoping to get to do it.
[17:29] <doko_> pitti: ahh, ok, yes for C
[17:31] <pitti> apw: in theory I should have gotten a merge request mailed, but I didn't
[17:31] <pitti> doko_: all 'real' locales are in langpack-locales source
[17:32] <doko_> urgh, we don't apply Debian's localedata patches ...
[17:32] <Keybuk> there should be a locale that gives you randomly undefined results ;)
[17:32] <pitti> ScottK: https://wiki.ubuntu.com/Apport is the "homepage" with some further links
[17:32] <ScottK> pitti: Thanks.
[17:32] <pitti> ScottK: and https://wiki.ubuntu.com/Apport/DeveloperHowTo is probably closer to what you are looking for
[17:33] <ScottK> OK
[17:43] <cjwatson> Keybuk: POSIX 2008 doesn't define "first day of week" at all. That said Saturday is probably a silly choice anyway
[17:47] <Keybuk> cjwatson: exactly ;)  it shouldn't be possible to display a calendar in the C locale
[17:47] <Keybuk> since there are no defined names for weekdays, and certainly no defined start of the week :p
[17:47] <cjwatson> Keybuk: it doesn't define "first day of week" for any other locale either, and actually there are defined names for weekdays in C
[17:48] <Keybuk> but then I'm old fashioned about strictly following standards <g>
[17:48] <Mithrandir> Keybuk: does it just omit names and start of week, or does it explicitly say "day names and first day of week is undefined in the C locale"?
[17:48] <cjwatson> day        "<S><u><n><d><a><y>";"<M><o><n><d><a><y>";\
[17:48] <cjwatson>            "<T><u><e><s><d><a><y>";"<W><e><d><n><e><s><d><a><y>";\
[17:48] <cjwatson>            "<T><h><u><r><s><d><a><y>";"<F><r><i><d><a><y>";\
[17:48] <cjwatson>            "<S><a><t><u><r><d><a><y>"
[17:48] <cjwatson> etc., in the POSIX locale
[17:49] <cjwatson> Mithrandir: it defines day names, and omits any mention of first day of week entirely (that's a glibc extension, I think)
[17:49] <Mithrandir> so it's perfectly legal to choose any day, then? :-)
[17:49] <Keybuk> Single Unix extension, apparently
[17:53] <Keybuk> cjwatson: it doesn't necessarily follow that the POSIX locale only contains what's in the POSIX specification ;)
[17:53] <cjwatson> Keybuk: sure, but you said "there are no defined names for weekdays" :-)
[17:53] <Keybuk> defined in the spec ;)
[17:53] <cjwatson> I'm deeply confused. They are defined in the spec.
[17:55] <cjwatson> there's a bit of a difference between the POSIX locale having some extras, and it not having stuff that the spec says it has
[17:55] <Keybuk> I did not think there was a spec for the C locale ;)
[17:55] <cjwatson> 'The strings "C" and "POSIX" are reserved as identifiers for the POSIX locale'
[17:56] <cjwatson> chapter 7 of Base Definitions
[17:56] <Keybuk> fair enough
[17:56]  * Keybuk stands in the corrected corner
[17:57] <cjwatson> ;-)
[18:21] <afflux> the retracer seems to just have closed a crash bug of mine, which is perfectly alright, since I can't reproduce this anyway. The only problem I see here is that I reported this bug more then a month ago, and since then, the package got updated, and with it obviously the debug symbol packages.
[18:22] <afflux> I'm not sure whether this really was intended, so I thought it might be worth it letting you know.
[18:39] <Notch-1> hi, please take a look here: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/318821
[18:59] <doko_> cjwatson: fix for 235070 uploaded using the patch from intrepid
[19:20] <directhex> who feels like giving https://bugs.launchpad.net/ubuntu/+source/nant/+bug/318683 a tickle?
[19:40] <idnzor> hi, i was wondering if someone could help me out with contact information
[19:40] <idnzor> i wanted to start contributing my user experience expertise to the ubuntu project
[19:40] <idnzor> i work for a user experience consultancy as a usability analyst, and want to start working outside of work on ubuntu/gnome based projects to give something back to the community
[19:42] <james_w> idnzor: that's great. The ubuntu-desktop list may be a good place to start to discuss Ubuntu/GNOME usability
[19:43] <idnzor> james_w: thanks, i posted the same above on there, however, i am just waiting for a response
[19:43] <james_w> the channel, or the mailing list?
[19:44] <idnzor> the channel
[19:45] <idnzor> would you recommend the ubuntu-desktop mailing as well then?
[19:46] <james_w> yeah, an email is more lasting, so you don't need the right people to be looking at the channel right now
[19:48] <idnzor> ok thanks, i will look into it
[20:02] <james_w> tedg: you're up!
[20:03] <tedg> james_w: Oh, I thought I was in an hour...
[20:03] <james_w> 'fraid not
[20:11] <NCommander> BTW, random question, does anyone know a good IRC proxy?
[20:12] <maxb> If you like irssi, it can be a proxy itself, at the same time as being a client.
[20:17] <Ape3000> I use irssi as proxy and Xchat as the visible client
[20:24] <asac> TheMuso: what - in theory - needs to be done in jaunty to get my line-in directed to my speakers ;)?
[20:25] <ogra> you take a soldering iron ... some wire ...
[20:27] <asac> heh
[20:27]  * ogra definately did to much ARM HW enablement the recent time 
[20:28] <asac> am i supposed to be in pulse-rt group or something?
[20:29] <asac> http://paste.ubuntu.com/107079/
[20:31] <ogra> "For enabling real-time/high-priority scheduling please acquire the appropriate PolicyKit privileges" heh ... come to our shop at www.policykit-addons-for-cheap-money.com :)
[20:40] <asac> TheMuso: am i supposed to be in pulse-* groups?
[20:55] <DTee> Hi would any developers be willing to answer some questions to help with my FInal Year Dissertation?
[20:56] <DTee> It won't take long.
[21:15] <TheMuso> asac: Depends on the card. It has nothing to do with pulseaudio. You need to adjust the line mixer levels in the alsa mixer.
[21:16] <TheMuso> mdz_: Daniel T Chen aka crimsun committed a fix for that in bzr yesterday, which I uploaded. Latest alsa-utils should fix that issue, and yes its a well reported bug.
[21:16] <mdz_> TheMuso: ok, thanks
[21:28] <asac> TheMuso: i have HDA NVidia Realtek ALC883
[21:28] <TheMuso> asac: Right, you will have to load alsamixer and fiddel with the line mixer, unmuting where necessary.
[21:29] <asac> TheMuso: is there a way to reset alsamixer to default?
[21:29] <TheMuso> asac: sudo alsactl restore should do it
[21:29] <TheMuso> maybe sudo is not needed, but I think it is.
[21:30] <asac> TheMuso: doesnt complain if i dont pass it
[21:30] <superm1> that won't necessarily set it to defaults, but more so to the last set of recorded values wouldn't it?
[21:30] <asac> TheMuso: interestingly i wasnt in pulse-rt group .... when were i supposed to be added there?
[21:31] <TheMuso> asac: You aren't added to that by default, and for the most part its not needed for average use.
[21:31] <asac> TheMuso: hmm ... before i added myself i had no sound at all
[21:31] <TheMuso> superm1: Yes thats right. I think alsactl init will reset values, however you may want to use sudo /etc/init.d/alsa-utils reset
[21:31]  * asac tries to remove himself again
[21:34] <asac> hmm ... gstreamer-properties hangs when testing pulsesrc
[21:35] <TheMuso> asac: Which one exactly?
[21:36] <asac> TheMuso: the default. (just reads pulsesrc)
[21:36] <TheMuso> asac: Is this for input or output?
[21:36] <asac> TheMuso: input
[21:36] <TheMuso> ah ok
[21:37] <TheMuso> asac: have you got a capture device set in the alsa mixer?
[21:37] <asac> TheMuso: i try to get my line-in on my speakery :(
[21:37] <asac> TheMuso: let me double check
[21:37] <TheMuso> asac: Ok, your board's hda code implementatino may not be set entrely correct, or have you gotten line in to work before?
[21:37] <asac> TheMuso: i have two captures: Line and Mic
[21:38] <asac> TheMuso: i cant really remember if it ever worked :/
[21:38] <TheMuso> asac: Right. In alsamixer's capture mode, you can set one of 3 capture sources, or at least thats what mine has. The sources can be set either to line, mic, or front mic.
[21:38] <TheMuso> But you can still only capture from one source at a time.
[21:39] <asac> TheMuso: ok. let me try to plug in a mic
[21:39] <asac> to see if its really just line not working
[21:43] <asac> TheMuso: so if is push up Mic Boost, i can here my voice ;) ... thats good. but capturing source doesnt have any influence at all for that
[21:44] <TheMuso> asac: Right, is the word capture displayed under any of the sources?
[21:45] <asac> TheMuso: only thing i have is two CAPTURE channels, but thats not it, right?
[21:46] <TheMuso> asac: Well if it works anythinglike mine, you can select which source you want, either mic, line, etc. Pressing space bar on one of those should enable it for capture.
[21:46] <asac> oh
[21:46] <asac> let me check
[21:46] <asac> yeah
[21:47] <asac> both had CAPTURE
[21:47] <TheMuso> interesting
[21:48] <TheMuso> asac: What are you using that is plugged into line in?
[21:48] <TheMuso> asac: and in the playback sectino of alsamixer, is line unmuted?
[21:49] <asac> TheMuso: so if i go to the "Capture" view of alsamixer i see 7 things (from left to right): front mic, mic boost, capture, capture 1, digital, Input Source, Input Source 1
[21:49] <asac> TheMuso: currently only the first "capture" has a red CAPTURE above it
[21:49] <TheMuso> asac: Ok, you want to go to input source, and choose line.
[21:50] <asac> TheMuso: problem is that input source has no influence whatsoever ... unless i mute the "Mic", i can hear the mic
[21:51] <asac> TheMuso: atm, both input source things have "Line" ... still mic is working
[21:51] <TheMuso> asac: Right. Go back to the playback sectino of alsamixer, and check the line level, and check if its unmuted.
[21:51] <TheMuso> section
[21:52] <asac> TheMuso: line in playback section is unmuted (i see 00) and has 100/100 level
[21:52] <asac> TheMuso: i have a PS3 connected to line-in ;)
[21:52] <TheMuso> asac: Right, and you are sure its currently playing audio?
[21:55] <asac> TheMuso: pretty sure. a demo is running
[21:55] <TheMuso> asac: Ok.
[21:55] <asac> TheMuso: anyway, dont want to bother you with this. only thing i dont understand is that if i select "Line" for all input sources in alsamixer, the mic is still working
[21:56] <TheMuso> Well if line is unmuted and set to full volume, and input source is set to line and capture is enabled and you still get nothing, theres something up somewhere?
[21:56] <TheMuso> s/?/.?
[21:56] <TheMuso> gah
[21:56] <broonie> It's perfectly normal for hardware to be able to mix multiple inputs together so having to mute others isn't that surprising.
[21:56] <TheMuso> asac: Hearing the mic will always be possible. Even though you can hear the mic, you can't necessarily record it unless the options in the capture are set so you can.
[21:58] <asac> broonie: so you say i should mute everything else?
[21:59] <asac> TheMuso: one last thing. i see hw:0,2 in alsasrc command ... where do those numbers come from?
[22:00] <TheMuso> asac: 0 is the card number, and 2 is the subdevice.
[22:00] <asac> TheMuso: ok. where does that subdevice number come from ;)?
[22:00] <TheMuso> asac: As it stands, I can't help but think that the hda chip on your board is not known properly. Could you either check to see if an existing bug report exists for your board, and if not, file one and assign ubuntu-audio? Then run http://www.alsa-project.org/alsa-info.sh and post the URL in the bug?
[22:01] <TheMuso> asac: THis will help track down the proper information for the hda chip, and I can check upstrea for any patches etc.
[22:01] <TheMuso> asac: THe number of devices on the card, I don't really understand that bit a great deal yet, in terms of alsa.
[22:02] <asac> ok
[22:02] <asac> thanks
[22:02] <TheMuso> asac: np
[22:04] <cjwatson> doko_: thanks
[22:06] <LaserJock> anybody have an obvious reason why Xephyr would be unacceptable for Main?
[22:07] <asac> TheMuso: file against what package?
[22:07] <directhex> LaserJock, what's the sales pitch FOR it being canonical-supoprted?
[22:07] <TheMuso> asac: linux, and assign ubuntu-audio
[22:07] <asac> cool
[22:07] <LaserJock> directhex: because it's better than Xnest?
[22:08] <directhex> reasonable argument ;)
[22:09] <cjwatson> LaserJock: so, with the Edubuntu task renaming you did, there is currently no way to prevent those packages having Task: edubuntu-edubuntu-desktop
[22:09] <cjwatson> and tasksel will have to change accordingly
[22:09] <cjwatson> LaserJock: I don't suppose you want to think up a different name?
[22:09] <LaserJock> good lord
[22:09] <cjwatson> otherwise I have to get Launchpad patched ...
[22:10] <LaserJock> is it just edubuntu-desktop that's the problem?
[22:10] <LaserJock> can I name it like desktop-gnome for instance and it'd be ok?
[22:10] <cjwatson> every task in the edubuntu seeds gets "edubuntu-" prefixed
[22:11] <cjwatson> so desktop-gnome would be fine (and likewise edubuntu-desktop-kde -> desktop-kde)
[22:11] <broonie> asac: It'll probably help.
[22:11] <cjwatson> arguably more descriptive than the present name too
[22:12] <asac> TheMuso: ok its 318985
[22:12] <TheMuso> asac: Ok thanks, if assigned to ubuntu-audio I'll get it in my bugmail.
[22:16] <LaserJock> cjwatson: ok, since we're trying to do a bit more DE-neutral stuff by having both a gnome and kde variant it's maybe best all around to do desktop-gnome and desktop-kde
[22:18] <LaserJock> I'm not sure I want to mess with transitioning edubuntu-desktop .deb to something better for Jaunty though
[22:18] <LaserJock> but for the seeds anyway it makes sense
[22:44] <calc> how do i enable nvidia driver in jaunty?
[22:45] <calc> i thought it was via system->hardware drivers but that just pulls up a completely empty dialog
[22:46] <raof> calc: There'll be the small problem that you'll need to edit xorg.conf & disable ABI checking before they'll work
[22:46] <calc> raof: oh it doesn't work currently due to the transition to xorg 1.6?
[22:53] <raof> calc: The driver works, mostly.  You just need to mess with the config.  The Hardware Drivers thing doesn't work for (at least) that reason.
[22:53] <calc> ok
[22:54]  * calc also isn't too impressed by the new castrated audio setup
[22:54]  * calc hopes his headset still works properly or he may need to switch to something other than Gnome
[22:54] <directhex> i could do with jaunty on my myth box. no hdmi audio from intrepid
[22:54] <cjwatson> LaserJock: yeah, just the seeds will be fine. Thanks!
[22:54] <directhex> or i could just compile my own alsa...
[22:55]  * calc plugs his usb headset in and sees what happens
[22:56] <calc> looks sane enough, but no way to test anything anymore
[22:58] <calc> and it appears to be able to change the volume you now have to change the output in gnome to that device, which is insane
[22:59] <TheMuso> calc: Yeah there have been complaints about the new volume control only controlling pulseaudio. This is not my area, I just maintain the infrastructure underneath. See recent warthogs discussion.
[22:59] <calc> so eg i'm talking on voip and want gnome to play audio from apps through speakers, but voip via the headset to adjust the headset i have to route the gnome audio through the headset now, or resort to using alsamixer/alsactl
[22:59] <calc> TheMuso: ok
[23:00]  * calc wonders what pulse buys us that dmix doesn't?
[23:00] <calc> other than more bugs
[23:01] <TheMuso> calc: Being able to move your VOIP output from speakers to your headset without restarting the VOIP application.
[23:01] <TheMuso> for one
[23:01] <calc> TheMuso: but thats not really a feature thats a bug ;-)
[23:01] <TheMuso> calc: Being able to send audio over the network to another machine.
[23:01] <calc> ok
[23:01] <TheMuso> calc: How is that a bug?
[23:01] <RainCT_> TheMuso: is the application specific volume stuff also from PulseAudio?
[23:01] <calc> TheMuso: to be able to adjust the audio for voip it does that regardless if you want it to or not :-\
[23:01] <RainCT_> or was that also possible with ALSA?
[23:02] <TheMuso> RainCT_: app specific audio volume control is pulse
[23:02] <RainCT_> nice
[23:02] <calc> network audio has been around a long time, just no one used the apis for it
[23:02] <RainCT_> finally it's useful for something :P
[23:02] <calc> at least a decade iirc
[23:02] <TheMuso> calc: Yeah but again you can move it over the network transparently without stopping it.
[23:02] <calc> ah ok
[23:03] <calc> TheMuso: this is all in theory of course as ubuntu doesn't install any of the support to actually do it (or does it now?)
[23:03] <TheMuso> calc: The volume control applet is supposed to either have it, or be getting it, so far as I know. I could be wrong however.
[23:04] <raof> The "Choose a device for sound output" radio buttons should actually switch (a) the default output for new streams, and (b) all the current streams.  It doesn't do that now.
[23:04] <raof> I presume it will before release, otherwise it's just a big UI lie.
[23:05] <calc> ok
[23:05] <directhex> anyone wanna  buy a hardware-mixed audigy? :p
[23:09]  * TheMuso shudders. Audigy cards have a shocking chip in them.
[23:10] <TheMuso> Yes they can do hardware mixing, but they internally resample to 48KHz.
[23:10] <TheMuso> nick TheMuso
[23:10] <TheMuso> wrong window
[23:12] <directhex> TheMuso, audigy 2, then.
[23:16] <TheMuso> directhex: RIght, I am not sure what chip those cards have.
[23:19] <directhex> TheMuso, ca0102.
[23:19] <TheMuso> Means nothign to me.
[23:19] <TheMuso> nothing