[01:09] <amikrop> How is the icon most upper-left icon, set?
[01:09] <amikrop> The icon left to the "Applications" menu. The Ubuntu logo in Ubuntu, and the GNOME foot, in Debian or Gentoo, by default.
[01:12] <amikrop> ?
[05:41] <Lancao> hi
[05:43]  * Hobbsee waves
[05:45] <Treenaks> hi Hobbsee
[05:46] <Hobbsee> hey Treenaks!
[05:47]  * Treenaks is trying to wake up, but it's not working
[05:48] <Hobbsee> heh
[05:48]  * Hobbsee offers a bucket of ice?
[05:48]  * Hobbsee is fighting gtk
[05:48]  * Treenaks runs away from the ice
[05:48] <Treenaks> Hobbsee: what's the problem with gtk?
[05:49] <Hobbsee> Treenaks: well, apart from a nutcase user who insists on subscribing ubuntu-core-dev to bugs, i'm looking at the "update manager keeps stealing focus & setting urgency hints while it doesn't require user input" bug
[05:52] <Treenaks> Hobbsee: I think he might mean the 'updating..' window
[05:52] <Treenaks> that used to do that, don't know if it still does it (no updates, so can't reproduce ;)
[05:52] <Hobbsee> it does
[05:52] <Hobbsee> or at least, sometimes does
[05:57] <Treenaks> Hobbsee: 'sometimes' bugs are the worst
[05:57] <Hobbsee> wlel, it may always do it.  i tend to minimise it, so don't see it
[06:03] <Lancao> I need help on the sound when XP on the ubuntu
[06:04] <Hobbsee> Lancao: #ubuntu for support, please.
[06:26] <dholbach> good morning
[08:44] <jeswhy> :P
[09:50] <lancao> hello
[10:08] <lool> slangasek: Re: #291582 you're saying this is also pushed to intrepid-proposed??
[10:09] <lool> we have no intrepid psb drivers right now
[10:09] <lool> (well we just got access to them, but they weren't pushed anywhere)
[10:21] <lool> slangasek: Hmm given that I see no linux intrepid uploads, I guess it was an EBUGNUMBER
[12:51] <hwilde> how can I send my hostname to dns with a static IP
[12:54] <RainCT> hwilde: what do you mean?
[12:58] <hwilde> i mean dhclient is what sends the hostname out and registers with dns right
[12:58] <hwilde> /etc/dhcp3/dhclient.conf   send host-name "";
[12:59] <hwilde> what if I'm using a static IP not dhclient, and I want to just send that host-name to DNS
[13:06] <maxb> hwilde: to *what* DNS?
[13:06] <hwilde> the dns server in /etc/resolv.conf ?
[13:08] <maxb> It's sounding you don't understand how DNS works. You don't "send hostnames to DNS" (except in the special case of dynamic DNS, which is very much a special case, not the norm.)
[13:12] <hwilde> so what does this do:      /etc/dhcp3/dhclient.conf   send host-name "";
[13:12] <ogra> can you take that to a support channel ?
[13:12] <hwilde> yeah they don't know over there
[13:12] <ogra> that doesnt justify anything
[13:13] <ogra> see /topic
[13:13] <ogra> seb128, would you kill me if i dropped -Werror from metacity ?
[13:14] <seb128> ogra: I don't care, I don't work on that one
[13:14] <ogra> seb128, at least ntil upstream shows some recation on gnome bug 562106 ? so it builds on armel
[13:14] <seb128> ogra: tarballs should not have Werror set, that's an upstream bug
[13:15] <ogra> well, its helpful during development, so i understand why they do it
[13:15] <seb128> the rules is usually that svn has it set but not tarballs
[13:16] <ogra> ah, i didnt know gnome had a rule for that
[13:16] <seb128> not sure that's a rules but that's how it's done usually
[13:16] <ogra> i foungth endless wars with gnome-powermanager upstream about that
[13:16] <ogra> and he insisted it had to stay
[13:16] <seb128> the svn is used to do hacking work, tarballs are for users and should be buildable easily
[13:16] <ogra> right
[13:17] <seb128> don't bother in any case just do the change and upload to jaunty
[13:17] <ogra> will do, gracias :)
[13:21] <hwilde> dhclient does send the host-name to dns tho
[13:22]  * hwilde stares at maxb 
[13:23] <wgrant> hwilde: No, it sends it to the DHCP server. Now back to userland with you.
[13:24] <hwilde> well ok then the dhcp server sends it to dns, that's not the point
[13:24] <hwilde> is there any way to do that while using a static IP
[13:25] <hwilde> just send the hostname, not actually request dhcp
[13:48]  * ogra doesnt get why libcanberra 0.6-0ubuntu3 still shows up on jaunty_probs
[13:48] <ogra> should be superseded since weeks
[13:53] <ScottK> ogra: Any rdepends left?
[13:53] <ScottK> IIRC NBS still needs to be run manually so it'll hang around until someone does.
[13:54] <ogra> ScottK, not that i'm aware of ... there is libcanberra-gnome which is nonexisting in 0.10, but there are proper conflicts/replaces lines
[13:55] <ScottK> Maybe just waiting to get NBS'ed away.
[14:31] <asac> ScottK: http://bazaar.launchpad.net/~mozillateam/firefox/firefox-3.0.head/revision/380 ... cheers.
[14:37] <ScottK> asac: Thank you.  That will be welcome news to a lot of Kubuntu users.
[14:58] <asac> heh
[14:58] <asac> i hope so ;)
[16:21] <tseliot1> slangasek: can you do an upload for me (SRU) or are you too busy today?
[16:40] <pqangel> hi,
[16:40] <pqangel> i have a lil question anyone care to help me out?
[16:42] <RainCT> hi pqangel
[16:42] <RainCT> !ask
[16:48] <ogra> meh, what happened to ubuntu-desktop ?
[16:48] <ogra> ogra@osiris:~/Devel/packages/rpm-4.6.0-rc2$ apt-cache show ubuntu-desktop|grep Version
[16:48] <ogra> Version: 1.124
[16:49] <ogra> 1.126 was uploaded last thursday
[16:52] <gnomefreak> ogra: i have 1.126
[16:53] <ogra> gnomefreak, yeah, seems i was cheated by myself ... using jaunty for deb-src but intrepid for deb :)
[16:53] <gnomefreak> ogra: ;)
[16:54] <ogra> though i still dont get why libcanberra-gnome doesnt go away
[16:54] <ogra> evil sticky thing
[16:54] <gnomefreak> its been held back for a while now
[16:55] <ogra> held back ? libcanberra build a week ago ...
[16:55] <ogra> libcanberra-gnome doesnt exist in the new package
[16:55] <gnomefreak> ogra: its replaved with -gtk
[16:55] <ogra> and ubuntu-desktop shouldnt depend on it anymore
[16:55] <ogra> right
[16:56] <ogra> so i dont get why it still shows up on jaunty_probs ... it should have gone since a while
[16:56] <gnomefreak> ogra: i dont see it as a depends of u-d
[16:57] <ogra> me neither
[16:57] <ogra> so whats keeping it there  ? :)
[16:58] <gnomefreak> if you install it instead of upgrade it installs and removed -gnome but as to why apt isnt upgrading it im not sure
[16:59]  * gnomefreak blames apt
[16:59] <ogra> heh
[16:59] <ogra> so easy to blame :)
[17:00] <gnomefreak> pulse has almost same issue
[17:00] <gnomefreak> thats why i blame apt :)
[17:01] <ogra> hmm
[17:02] <gnomefreak> ogra: seems any name change isnt being handled properly with apt sox is same way it removes libsox0a and installs libsox1
[17:03] <ogra> i would expect that to be handled through conflicts/replaces actually
[17:04] <gnomefreak> ogra: sox is right on depends
[17:04] <gnomefreak> but no conflicts
[17:04]  * ogra wonders  ... 
[17:04] <ogra> Package: libcanberra-gtk0
[17:04] <ogra> Architecture: any
[17:04] <ogra> Depends: ${shlibs:Depends}, ${misc:Depends}
[17:04] <ogra> Recommends: libcanberra-gtk-module
[17:04] <ogra> Conflicts: libcanberra-gnome (<< 0.10-1)
[17:04] <ogra> Replaces: libcanberra-gnome (<< 0.10-1)
[17:05] <ogra> adding a provides might solve it i guess
[17:05] <ogra> that would superseded the existing libcanberra-gnome
[17:05] <gnomefreak> if it replaces/conflicts it should be handled properly
[17:05] <ogra> *supersede
[17:05] <ogra> not for the archive apparently
[17:06] <gnomefreak> i see it
[17:06] <ogra> else jaunty_probs wouldnt show libcanberra-gnome (which it can only find in v0.6)
[17:06] <gnomefreak> ogra: 0.6-0ubuntu3 is >> not <<
[17:06] <gnomefreak> << 0.10*1 should be >> maybe?
[17:07] <ogra> <= ?
[17:07] <ogra> hmm, no
[17:07] <ogra> << is ok
[17:07] <gnomefreak> as of now it conflicts/replaces << 0.10-1 but 0.6 is > than 0.10
[17:09] <ogra> ogra@osiris:~/Devel/packages/rpm-4.6.0-rc2$ dpkg --compare-versions 0.10 gt 0.6||echo false
[17:09] <ogra> ogra@osiris:~/Devel/packages/rpm-4.6.0-rc2$
[17:09] <gnomefreak> hmm
[17:12] <gnomefreak> it seems all held back packages can be installed but not upgraded
[17:23] <EtienneG> I have a stupid question here ... can we build chroot of later release using debootstrap?
[17:23] <EtienneG> ie, building intrepid/jaunty chroot on hardy?
[17:23] <ogra> EtienneG, yes
[17:24] <ogra> you usually need the backported debootstrap though
[17:24] <EtienneG> ogra, I guess I need to get the script somewhere and drop them in /usr/share/debootstrap/scripts ?
[17:24] <ogra> or install the latest debootstrap from the latest distro
[17:24] <EtienneG> ogra, thanks, will look in backport then
[17:24] <ogra> debootstrap is usually just installable
[17:25]  * ogra always just takes the one from next release and installs it
[17:25] <EtienneG> 'k
[17:25] <EtienneG> ogra, shouldn't you be on a a plane already?  ;)
[17:25] <ogra> tomoroow morning :)
[17:26] <EtienneG> he
[17:26] <ogra> EtienneG, and yourself ?
[17:26] <EtienneG> I am going too, first one since Seville
[17:26] <ogra> cool, looking forward to meet you
[17:26] <EtienneG> ogra, same here, we will have a beer
[17:26] <EtienneG> we will probably have to settle for a creepy hotel bar, but he
[17:27] <EtienneG> as long as it not a dating nights or anything
[17:27] <ogra> as long as its better than the wild palms bar we had last time in mountainview all is fine :)
[17:27] <ogra> they closed at 6:30pm
[17:27] <EtienneG> no shit!
[17:28] <ogra> no :)
[17:28] <EtienneG> now, that *is* bad!
[17:28] <ogra> and the bus from google only started at 6pm
[17:28] <EtienneG> ARRRRR!
[17:28] <ogra> so we always came in for exactly one beer until they closed ...
[17:29] <ogra> but they left the room open and teher was a liqor store nearby
[17:29] <EtienneG> ha
[17:30] <EtienneG> nonetheless, i prefer drinking in bar ... the context is just better
[17:30] <ogra> yeah, lets see how the new hotel is
[17:30] <ogra> though i think its the same chain
[17:30] <EtienneG> there, it works with the debootstrap in backports, thanks ogra
[17:31] <EtienneG> bars closing so early is kinda weird, it is
[17:31] <EtienneG> Califoria after all
[17:31] <ogra> well, its sunnyvale after all ...
[17:32] <ogra> middle of nowhere village :)
[17:32] <EtienneG> indeed
[17:32] <EtienneG> too bad, i guess it will be more productive!
[17:32] <ogra> heh, by nature
[17:33] <ogra> since we are locked in at google during worktime
[18:04] <slangasek> lool: not EBUGNUMBER, EWRONGINVOCATIONOF"sru-accept" I think
[18:05] <slangasek> lool: I should've used the "-s hardy" argument when sending my autogenerated messages :/
[18:06] <slangasek> tseliot1: I can do an SRU upload, but usually the SRU team are the last people you want to have sponsoring the actual uploads? :)
[18:08] <tseliot1> slangasek: ah, ok, I'll keep that in mind in the future. If you're available I would be glad if you could upload the sources listed in this file to intrepid-proposed:
[18:08] <tseliot1> http://albertomilone.com/ubuntu/newlrm/pitti/destination.txt
[18:09] <tseliot1> this is the SRU: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/297543
[18:50] <slangasek> tseliot1: changelogs for SRUs need to reference the LP bug #s for any bugs they're fixing.  Do you want to fix this and feed me new source packages, or should I take care o it here?
[18:50] <slangasek> +f
[18:51] <slangasek> tseliot1: also, bug #297543 doesn't currently mention -96 or -173
[18:59] <tseliot1> slangasek: right, I mentioned them here: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/297543/comments/36
[18:59] <slangasek> tseliot1: well, there should be tasks open for each package that's being SRUed (either on this bug or another), so that we can track the status
[19:00] <slangasek> in this case, separate bugs might be better since I guess each package needs to have SRU verification / regression testing separately?
[19:01] <tseliot1> slangasek: not in this case since the changes to those packages are trivial and are related compatibility with the new driver
[19:01] <tseliot1> so that installing one driver removes the other
[19:01] <tseliot1> etc.
[19:02] <slangasek> ok
[19:02] <slangasek> then please open tasks for the other packages being SRUed
[19:02] <tseliot1> ok
[19:04] <slangasek> tseliot1: 173.14.12-1-0ubuntu7 -- wrong version number, you need to use a version number that sorts earlier than the version in jaunty, not later
[19:04] <slangasek> e.g. 5.1 << 6
[19:06] <tseliot1> slangasek: I was told that I couldn't use the same version which is in Jaunty, therefore I bumped the version in intrepid. Would it help if I bumped the version in Jaunty instead?
[19:07] <slangasek> no, use 5.1 as the version number
[19:07] <slangasek> there's no reason to do another upload to jaunty for this
[19:07] <tseliot1> slangasek: aah, ubuntu5.1
[19:07] <slangasek> yep
[19:07] <tseliot1> ok
[19:08] <slangasek> https://wiki.ubuntu.com/SecurityUpdateProcedures includes the best guide to package versioning in SRUs
[19:09] <ogra> "make it a dolby surround version" ?
[19:09] <tseliot1> thanks for the link
[19:10] <tseliot1> ogra: yep 5.1
[19:10] <ogra> :)
[19:21] <doko> lool: was there any outcome about the arm double/qreal discussion?
[19:25] <slangasek> tseliot1: I'll wait for you to post new packages with fixed version numbers and changelog bug references, then
[19:25] <tseliot1> slangasek: ok, let's see if I got it right this time: 96.43.09-0ubuntu1.1 , 173.14.12-1-0ubuntu5.1, 177.82-0ubuntu1.1 , 180.11-0ubuntu0.1
[19:27] <slangasek> tseliot1: should -177 be 177.82-0ubuntu0.1?  there doesn't seem to have been an -0ubuntu1 in intrepid
[19:27] <slangasek> in terms of sorting with what's currently in the archive, though, all of those are fine
[19:29] <tseliot1> slangasek: 177.82-0ubuntu1 was available in jaunty but now it has been superseeded by ubuntu2. I guess I can use ubuntu1 then
[19:29] <slangasek> no, you can't use ubuntu1
[19:29] <slangasek> you can never reuse version numbers
[19:29] <slangasek> but 0ubuntu0.1 is more correct than 0ubuntu1.1, because it sorts earlier than every version that's ever been in jaunty
[19:29] <tseliot1> so I was right before
[19:30] <tseliot1> ah, good
[19:33] <tseliot1> ok, let me upload the sources again
[19:37] <tseliot1> slangasek: ok, here you go: http://albertomilone.com/ubuntu/newlrm/pitti/destination.txt
[19:50] <slangasek> tseliot1: so in the preinst diff, I see that -96 tries to remove its own diversions, is that intentional or a copy/paste error?
[19:53] <tseliot1> slangasek: it's intentional (because of previous versions)
[19:53] <tseliot1> it shouldn't cause problems anyway
[19:53] <tseliot1> since it's in the preinst
[19:54] <slangasek> this reasoning escapes me
[19:55] <slangasek> tseliot1: I'm not sure this dkms switch is appropriate in an SRU; is there discussion of that change somewhere in LP?
[19:57] <tseliot1> slangasek: the dkms switch is not such a big change. It reuses the same directories and lets DKMS apply the patches instead of patching things in advance
[19:57] <slangasek> tseliot1: how would I confirm that dkms would do the patch applying?
[19:58] <slangasek> I'm unfamiliar with dkms details
[19:58] <tseliot1> it is written in the dkms.conf.in
[19:58] <tseliot1> I'll make an example
[19:59] <slangasek> nothing there specifically mentions patches; should I just trust that the directory you're copying these into is the directory that dkms looks for patches in?
[19:59] <tseliot1> slangasek: if I add the following lines to dkms.conf.in: PATCH[0]="NVIDIA-177.82_2.6.28.patch"
[19:59] <tseliot1> PATCH_MATCH[0]="^2.6.2[8]"
[19:59] <tseliot1> then the patch is applied only if kernel 2.6.28 is in use
[19:59] <slangasek> ah - in practice this isn't an issue for 96 because the patch set is empty ;)
[19:59] <tseliot1> yep
[20:01] <tseliot1> if you're interested, you can do a "man dkms" and get to where it says PATCH[#]
[20:02] <tseliot1> for example it says that dkms looks for patches in /usr/src/<module>-<module-version>/patches/
[20:02] <tseliot1> and currently I copy patches from debian.binary/patches to what will be installed in /usr/src/<module>-<module-version>/patches/
[20:04] <tseliot1> this will make things a lot easier as I can use the same sources for intrepid, jaunty, etc. just by adding new patches (in theory) and telling dkms when it should apply each patch
[20:05] <tseliot1> e.g. PATCH_MATCH[0]="^2.6.2[8-9]" means apply patch[0] only if 2.6.28 <= kernel <= 2.6.29
[20:05] <superm1> it also helps if someone is regressing a problem in a kernel by grabbing the kernel from release+1
[20:06]  * tseliot1 nods
[20:31] <lool> doko: Concerning kdebase-workspace or kde4bindings?
[20:31] <lool> doko: kdebase-workspace was patched, but the new kde4bindings doesn't build anymore because of the new kdelibs
[20:32] <lool> doko: On #kde-devel, people commented that kdelibs should be patched to move to qreal, but that this should be discussed on kde-core-devel@ or some similar list to make sure nobody has something to raise about the abi change on arm/wince
[20:32] <lool> doko: NCommander said he would Cc: me when he mails the proposed patch there
[20:32]  * lool offline now &
[22:09] <ScottK-laptop> If a package needs a config file to run, but it's not provided (except as examples) and the init just prints a warning to stdout is that a policy violation or merely in poor taste?
[22:09] <directhex> where are the examples stored?
[22:12] <ScottK-laptop> In /usr/share/doc/$PACKAGENAME
[22:36] <slangasek> ScottK-laptop: poor taste, I think; there are cases in which you legitimately want a package to not do anything by default, and I don't see a way to distinguish between those cases and the one you dsecribe, at a policy level
[22:37] <ScottK-laptop> slangasek: OK.  How about writing to stdout in the init is the only warning you get?
[22:38] <slangasek> sounds to me these are all bugs, just not policy violatios :)
[22:38] <slangasek> n
[22:39] <ScottK-laptop> OK.
[22:39] <ScottK-laptop> If it was policy it'd be easier to know if it's RC or not (this affects Debian too).
[22:41] <tseliot1> slangasek: let me know if you see other problems with my source code (for the upload)
[22:41] <slangasek> tseliot1: sure.  I have two of them uploaded so far, moving on to 177 now
[22:41] <tseliot1> slangasek: thanks a lot
[22:41] <slangasek> tseliot1: was there discussion of whether 180 belongs as an SRU, given that it's a new package, vs. backports?
[22:42] <tseliot1> I talked to superm1 about this. The new driver won't be suggested by Jockey unless the modalias package is installed
[22:43] <tseliot1> I think it's safe to put it in updates
[22:43] <tseliot1> instead of backports
[22:48] <superm1> the converse to that though, considering it's a beta driver, it might make more sense to regularly update it via backports until the stable driver is released in the 180 series
[22:49] <superm1> rather than always filing SRU's for such things