[00:27] <NCommander> StevenK, ping?
[00:30] <ScottK> NCommander: Would you please have a look at http://launchpadlibrarian.net/18240816/buildlog_ubuntu-intrepid-hppa.openexr_1.6.1-3_FAILEDTOBUILD.txt.gz
[00:30] <ScottK> NCommander: lamont fixed glib2.0.
[00:30] <NCommander> Wow, how?
[00:31] <NCommander> ScottK, your not a DD, are you?
[00:31] <ScottK> No
[00:31] <ScottK> Need to find time to work on T&S.
[00:31] <NCommander> Argh
[00:31] <NCommander> I need a DD to help update my packages
[00:32] <ScottK> Should be no rush unless you've got RC bug fixes for Lenny.
[00:35] <NCommander> ScottK, more approaching the end of my NM process, and some of my packages have had outstanding patches for awhile
[00:35] <NCommander> After three failed RFS attempts, I gave up
[00:35] <NCommander> (the patches were rolled into Ubuntu however after I became active here)
[00:50] <ScottK> Right.  How about openexr?
[01:05] <LaserJock> we're just under FF right? no need to get every upload approved yet
[01:05] <ScottK> Right.
[01:08] <ion_> I wonder how to debug LP #278188?
[01:26] <ion_> benc: You seem to have made some commits to nsc-ircc. Any thoughts?
[01:41] <StevenK> NCommander: Pong
[02:01] <dinx> morning
[02:02] <Hobbsee> morning dinx
[02:04] <dinx> :)
[06:20] <pitti> Good morning
[06:22] <pitti> Hobbsee: 277419 seems to have been sorted out, thanks tseliot
[06:22] <Hobbsee> pitti: ah, cool!
[06:27] <NCommander> wgrant, poke
[07:12] <StevenK> doko: I worked on cacao, can you look over what I did?
[07:19] <doko> StevenK: nice, what should I look at?
[07:19] <StevenK> doko: Just want a second pair of eyes on it. http://people.ubuntu.com/~stevenk/cacao/
[07:21] <doko> StevenK: do have debdiff with just the debian part and a dokg -c of the source package?
[07:21] <doko> avoiding to type
[07:21] <StevenK> doko: From the last package in Ubuntu (0.98-2) or Debian (0.99~rc5) ?
[07:26] <doko> StevenK: the last one in Ubuntu should be ok
[07:29] <StevenK> doko: http://people.ubuntu.com/~stevenk/cacao/cacao_0.99.3-0ubuntu1.debdiff
[07:34] <doko> StevenK: hmm, I asszme this is the patched version in the source, isn't it?
[07:34] <StevenK> doko: There's a patch needed?
[07:36] <doko> ahh, ok, there are no patches
[07:42] <doko> StevenK: looks fine, now you could update to the head of the 1.0.x branch ...
[07:42]  * doko ducks
[07:44] <doko> (http://mips.complang.tuwien.ac.at/hg/cacao/)
[07:45] <sleepster> I would like to add a package to the ubuntu repository.. does it take a long time?
[07:50] <doko> StevenK: preparing a source package
[07:55] <doko> StevenK: http://people.ubuntu.com/~doko/tmp/cacao_0.9.4~20081006.orig.tar.gz
[07:55] <lukehasnoname> ping pitti
[08:00] <StevenK> doko: How is that cacao related to the 0.99.3 I downloaded?
[08:00] <doko> taken from the 1.0.x branch (which will become 0.99.4)
[08:01] <StevenK> Oh, so it should be 0.99.4~20081006, rather than 0.9.4
[08:08] <pitti> pinging me and then disappearing?
[08:09] <StevenK> doko: You'd rather use the 1.0.x branch than 0.99.3?
[08:11] <lool> pitti: The trigger is committed in upstream hal
[08:11] <pitti> lool: \o/ thanks, I'll merge that
[08:15] <doko> StevenK: yes, as seen in the cacao-oj6 package. there will be a 0.99.4 release next week
[08:16] <StevenK> doko: Can you repack the tarball? It ought to be 0.99.4... rather than 0.9.4
[08:16] <doko> oops
[08:20] <doko> StevenK: done
[08:21] <lool> pitti: Eh it's the work of Michael, not mine
[08:29] <pitti> cjwatson_: what was the  component again which is responsible for copying the jockey installed packages to the installed system?
[08:32] <cjwatson> pitti: err ... jockey (debian/jockey.ubiquity)
[08:32] <pitti> cjwatson: *headdesk* thanks
[08:33] <pitti> cjwatson: my current woe is bug 258486
[08:33] <pitti> cjwatson: in short, we copy nvidia-* from the live system, but not /var/lib/dkms/
[08:34] <pitti> thus after booting the installed system, there are no nvidia.ko modules, and DKMS doesn't even know about them since they aren't registered
[08:34] <pitti> cjwatson: so I wondered whether I should just copy /var/lib/dkms/ to the target system
[08:35] <pitti> cjwatson: can I just use file copying to /target/, or is there a special command for this, like apt-install?
[08:37] <pitti> if that's too messy, we can alternatively completely disable jockey on the live system again
[08:47] <tkamppeter> pitti, have you seen my new CUPS BZR upload for Debian and Ubuntu? Can you put it into Debian and Intrepid? Thanks-
[08:48] <pitti> tkamppeter: I got your mail, yes
[08:49] <tseliot> pitti: have a look at the last 2 commits of my jockey-generic branch when you have the time
[08:49] <pitti> hey tseliot, good mornign
[08:50] <tseliot> morning
[08:53] <pitti> tseliot: great work!
[08:54] <pitti> tseliot: clicking on the details button raises AttributeError: 'KDEUI' object has no attribute 'current_driver_name'
[08:54] <tseliot> pitti: do we have a test for this?
[08:54] <pitti> tseliot: unfortunately not
[08:55] <tseliot> pitti: maybe it's better if we discuss this in private (so as not to flood the ubuntu-devel
[08:55] <pitti> right
[08:55] <NCommander> pitti, I got a question you can answer
[08:55] <NCommander> pitti, is it possible to retroactively bump something up to main?
[08:56] <pitti> NCommander: sure, we do that all the time (called "main inclusion request"), https://wiki.ubuntu.com/MainInclusionProcess
[08:56] <NCommander> For something already released?
[08:56] <NCommander> (this needs a promotion in dapper, fiesty, and gutsy)
[08:56] <StevenK> Hmmm
[08:56] <StevenK> Not sure we can/will do that
[08:57] <pitti> NCommander: nope, we won't do that
[08:57] <NCommander> Argh
[08:57] <NCommander> Any ideas how to fix this problem then?
[08:58] <lukehasnoname> I have to say
[08:58] <lukehasnoname> no, I don't have to say.. let me think about what I was going to say before I say it.
[08:59] <NCommander> pitti, I personally don't care too much about it being broken in feisty or gutsy, but dapper still has two years of support left, it would be nice if we could get it fixed there ... :-/
[09:00] <pitti> NCommander: well, what *is* the problem?
[09:00] <NCommander> xfprintf requires a2ps to actually print
[09:00] <NCommander> THis broken in gutsy
[09:00] <NCommander> (obvious Xubuntu users don't print)
[09:02] <NCommander> pitti, now there is only one or two apps that actually use xfprint4, so its not a huge issue but ...
[09:03] <pitti> NCommander: oh argh, xubuntu-meta is in main for dapper/feisty/gutsy, so we can't even pull it in there
[09:03] <pitti> hmm
[09:03] <NCommander> The problem fixed itself when we got bumped to universe
[09:03] <NCommander> (and someone added a2ps to the Depends)
[09:04] <NCommander> Now correct me if I"m wrong, but a promotion to main won't break things since main will always be enabled. Is there any way we could possibly get an exception to the no old release promotion rule?
[09:05] <NCommander> ^- pitti
[09:06] <NCommander> (a2ps is pretty deeply wrapped around xfprint4, it would be a major PITA to fix that)
[09:06] <pitti> NCommander: I don't want to decide that on the spot; that has to be discussed with the soyuz guys (whether it's possible in the first place), and with some more archive admins
[09:06] <NCommander> Right, no, that I understand, but I just want to know if at all its a possibility, or I should give up hope via this method, and look for some other way to resolve it :-)
[09:06] <StevenK> pitti: It starts a dangerous precedent
[09:07] <NCommander> StevenK, how often would a package need to be bumped to main to fix a bug in an SRU?
[09:07] <StevenK> doko: Right, 0.99.4~20081006 builds
[09:08] <StevenK> doko: So, I hit up pitti to approve it, or now what? :-)
[09:08] <asac> hmm ... are there use-cases for not having "lo" iface upped?
[09:08] <StevenK> asac: No, stuff breaks if it isn't
[09:09] <pitti> asac: it might happen if you don't have any network support compiled into your kernel, perhaps? (for really small embedded devices)
[09:09] <asac> yeah ... i wonder if there might be corner cases ;)
[09:09] <pitti> asac: but I can't imagine it on anything which also uses network-manager
[09:09] <asac> pitti: ok. but if there is network support, and "lo" interface can be upped, it should be upped i guess :)
[09:09] <pitti> oh, yes
[09:10] <ion_> Could someone please sponsor http://launchpadlibrarian.net/18250664/iconv.debdiff to fix LP #278195? Thanks.
[09:10] <asac> is sudo ifconfig lo up always the right thing to do?
[09:10] <cjwatson> pitti: copying files to /target is fine if it's necessary
[09:11] <cjwatson> pitti: (how come /var/lib/dkms doesn't get generated when installing those packages, the same way as it does normally?)
[09:11] <cjwatson> NCommander: it could be done if there were a newer version of the package in -updates
[09:12] <cjwatson> NCommander: I'm not even sure how it would be represented otherwise, or if Soyuz can technically do it without a newer version
[09:12] <NCommander> It seems Soyuz can't
[09:12]  * NCommander just asked
[09:12] <pitti> cjwatson: I need to find that out; currently exploring options, but I haven't reproduced it yet
[09:12] <doko> StevenK: I thought he did approve it before?
[09:12] <NCommander> cjwatson, so could we upload a X.1 of a2ps which can be bumped to main, and then simply add the depends?
[09:13] <cjwatson> NCommander: in theory
[09:13] <pitti> cjwatson: apt-install will do a full install, including postinst, I assume
[09:13] <cjwatson> pitti: yes
[09:14] <cjwatson> pitti: note that it uses DEBIAN_FRONTEND=noninteractive though
[09:14] <pitti> that should be ok, nvidia-glx-* don't use debconf
[09:14] <NCommander> cjwatson, I'm asking now to see if thats a possibility
[09:14] <pitti> tseliot: any idea about bug 258486 ?
[09:14] <StevenK> pitti: So, can I beg you to look at a new upstream Cacao?
[09:15] <pitti> StevenK: new features? if so, please attach a changelog to the bug
[09:15] <pitti> tseliot: it seems that after copying nvidia-glx-*, the target system doesn't get the modules built (presumably because they aren't registered to dkms)
[09:15] <tseliot> pitti: I have added a comment there. Without a log and some other details I can't see what failed
[09:15] <NCommander> cjwatson, they say in theory its possible, although bigjools wasn't sure if archive admins could do the necessary promotion
[09:15] <NCommander> (i.e., it might require some black magic)
[09:15] <pitti> tseliot: ok; I'll try to fake it in a VM
[09:16] <cjwatson> NCommander: pretty sure we can
[09:16] <StevenK> pitti: Looking at the NEWS file, it's mostly bug fixes
[09:17] <StevenK> pitti: Do you want NEWS or ChangeLog, or both in a bug report? Keeping in mind I'm doing this for NBSage, and 0.98-2 FTBFS
[09:17] <NCommander> cjwatson, so now that the techinical part of the promotion is sorta resolved, whats the next step? I assume a post to -devel to discuss it?
[09:17] <tseliot> pitti: I guess that the system doesn't copy what was built by DKMS (/var/lib/dkms, the symlinks, etc.)
[09:17] <cjwatson> NCommander: I suppose so
[09:17] <tseliot> pitti: s/system/installer/
[09:17] <cjwatson> tseliot: but why aren't those regenerated when the package is installed in /target?
[09:18] <cjwatson> tseliot: the hook that does this doesn't copy files, it calls apt-get install (eventually)
[09:18] <tseliot> cjwatson: yes, they are rebuilt if the driver is in the dkms tree in /var/lib/dkms
[09:19] <cjwatson> tseliot: the driver gets there in the first place by installing a package
[09:19] <tseliot> cjwatson: ok, I'll try to reproduce the problem here
[09:19] <cjwatson> tseliot: why doesn't installing the package in /target work?
[09:19] <tseliot> cjwatson: it should work. I'll see if I can track down the problem
[09:20] <cjwatson> thanks
[09:22] <liw> on Thursday and Friday last week, I tried upgrading my desktop machine from hardy to intrepid; both times it crashed hard, and from syslog and other things it seemed that the fglrx kernel module was the problem; last night, I restored the original state, removed the restricted kernel modules and restricted from sources.list, ran the upgrade again, and now it worked
[09:23] <liw> I should file a bug about that, but... any other suggestion?
[09:25] <pitti> StevenK: whatever is detailled enough to list/describe all the relevant new features
[09:25] <pitti> StevenK: and I'd like to have doko's "OK" for that update, he's the expert
[09:26] <doko> pitti: ok (I asked fot it =) )
[09:27] <doko> will let us drop the cacao copy from cacao-oj6
[09:32] <StevenK> pitti, doko: Bug 278957
[09:35] <pitti> StevenK: thanks; bug updated
[09:36] <NCommander> StevenK, here's the proof of concept https://dogfood.launchpad.net/ubuntu/+source/basket - its possible to promote in a pocket
[09:36] <NCommander> ^_ pitti
[09:36] <pitti> NCommander: ah, nice
[09:36] <NCommander> We're waiting on dogfood's backend to generate apt files
[09:36] <NCommander> Still need to make sure nothing nasty breaks
[09:37] <NCommander> But from first glance, it can be done
[09:37] <StevenK> I figured it could be made to work
[09:37] <NCommander> We knew it was possible
[09:37] <StevenK> NCommander: Now you get to prepare uploads to -proposed
[09:37] <NCommander> StevenK, and you get to upload them :-)
[09:37] <NCommander> The thing I was worried about if your promote a pocket it might affect the main archive
[09:37] <StevenK> NCommander: Do I? :-P
[09:38] <NCommander> (i.e., if I promote something in release, then backports and updates get prompted automagicially)
[09:38] <NCommander> er promoted
[09:41] <tseliot> cjwatson: does the Ubuntu installer dump a log anywhere?
[09:45] <NCommander> pitti & StevenK: I got confirmation that publisher does the right thing w.r.t. to promotion in a pocket
[09:46] <cjwatson> tseliot: /var/log/installer/syslog
[09:46] <tseliot> cjwatson: ok, thanks
[09:57] <tkamppeter> pitti, can you fix bug 271286 in Intrepid, otherwise driver auto-download is nearly non-functional.
[09:57] <pitti> tkamppeter: it's on my list, yes
[10:08] <Adri2000> pitti: how often does the -sru team check main sru bug reports?
[10:08] <pitti> Adri2000: I check the upload queue every few days, and read the bug mail
[10:10] <wgrant> NCommander: Hi. Did #launchpad solve your issue?
[10:11] <Adri2000> pitti: if few days < 1 week, you probably missed vsftpd :)
[10:11] <NCommander> wgrant, yes, it proved that promotion in a pocket will not cause the archive to self-destruct
[10:11] <wgrant> NCommander: So I read.
[10:11] <NCommander> (a pity ... *shot*)
[10:17] <StevenK> pitti: Mind binary NEWing cacao-source? I don't think I should do it since I prepared it
[10:18] <pitti> StevenK: it was just a sync, wasn't it? so don't worry about it, but I'll do it now
[10:18] <pitti> hmm
[10:18] <pitti> cocoplum.ubuntu.com: forward host lookup failed: Unknown host
[10:18] <slangasek> .c.c
[10:18] <pitti> wasn't that the new drescher?
[10:18] <pitti> ah
[10:19] <slangasek> but you could just pass it off to the guy on archive duty today :)
[10:19] <pitti> oh yeah, this "delegate" thing; admittedly I'm bad at that
[10:20] <liw> delete, delegate, do... the GTD mantra :)
[10:20] <liw> there's a defer there somewhere too... I need to re-read the book
[10:20] <pitti> StevenK: looks ok, accepted
[10:21] <StevenK> pitti: It wasn't a sync, though
[10:35] <cjwatson> pitti: cocoplum.canonical.com
[10:35] <cjwatson> oh, slangasek said, only more coded
[10:35] <directhex> can a core dev please decline the release nomination on https://bugs.launchpad.net/ubuntu/+source/mono/+bug/278946 ?
[10:35] <pitti> cjwatson: yep, got it from slangasek; thanks
[10:36] <Hobbsee> directhex: declined.
[10:36] <directhex> thanks Hobbsee.
[10:36] <Hobbsee> directhex: you're welcome
[10:38] <directhex> Hobbsee, it's a big sexy new upstream release, but it's tens of thousands of commits newer, and an upstream which needs a lot of patching..... and it's already october
[10:38] <Hobbsee> directhex: indeed.
[10:38] <StevenK> Heh
[10:39] <NCommander> directhex, I'd run in horror if there was a FFe on that
[10:39] <directhex> NCommander, so would i, and i'm the mono guy
[10:40] <directhex> NCommander, trust in pkg-mono. even if i don't know what i'm doing, slomo and meebey do :p
[10:40] <NCommander> directhex, I know enough that I should be a mono guy, I fixed evolution-sharp
[10:41] <NCommander> remember that one :-)?
[10:41] <directhex> oh, grand announcement: the final obstacle to syncing mono (build-dep on libgda2) should now be gone, it ought to be syncable for jaunty once 2.0 packages land
[10:44] <directhex> jaunty will have a nice mono stack. more syncing, mono 2.0+, moonlight, mono-basic
[10:44] <pitti> directhex: great work!
[10:46] <wgrant> Is there a good reason for the NM connection editor to not be in System->Preferences?
[10:46] <sebner> pitti: what do you think, granting all FFe for mono 2.2 (March) :P
[10:46] <pitti> ...
[10:47] <directhex> sebner, i'm laughing because it's true :). seriously though, we've spoken to upstream & they should now be MUCH more approachable when it comes to concerns over upstream releases versus distro freezes
[10:47] <sebner> directhex: hrhr :)
[10:48] <directhex> they're generally being a much better-behaved upstream, we even have our own packagers mailing list now to discuss things like downstream patches
[10:49] <sebner> directhex: great to hear. hope they stick to the roadmap though
[10:51] <directhex> sebner, the fewer patches we need to apply, the more likely we are to be able to even consider FFes (for minor versions only, of course). making sure they're warned *in advance* of freezes lets them know which versions will be installed on thousands of machines
[10:52] <sebner> directhex: hehe
[10:52] <directhex> e.g. "1.2.6" means "ubuntu 8.04", "1.2.2.1" means "debian etch", "1.2.2" means "SLES10"
[10:54] <sebner> directhex: let's hope for 2.2 means ubuntu 9.04 :P
[10:55] <directhex> sebner, well, whatever. the important thing from our perspective is, first and foremost, the best platform for desktop apps like f-spot and tomboy. cool new upstreams is a secondary concern
[10:55] <sebner> directhex: of course
[11:02] <slangasek> pitti: wow, still 8 distinct crasher bugs in console-kit-daemon?
[11:03] <pitti> slangasek: on my triage rave on Friday I identified about three (of which one should be fixed in the latest version, and the other was the double close()), and some less frequent ones
[11:04] <pitti> the one in the creation of its gazillion threads doesn't seem fully fixed yet, though
[11:09] <tseliot> cjwatson, pitti: for some strange reason no nvidia-glx-VER package was installed after the installation of Ubuntu. Any ideas?
[11:09] <pitti> tseliot: you enabled the nvidia driver on the live system and then installed?
[11:09] <pitti> tseliot: in the bug report the reporter said that the package itself was installed, thuogh
[11:10] <tseliot> pitti: yep. And the modified xorg.conf is still there
[11:11] <tseliot> pitti: maybe he was referring to the modalias files?
[11:11] <pitti> tseliot: that's possible, yes
[11:12] <tseliot> pitti: after all they are named nvidia-177-modaliases, etc. and nvidia-common too might be misleading
[11:12] <pitti> tseliot: after installing the driver under the live system, they should appear in /var/cache/jockey/installed_packages; maybe something was missing there?
[11:13] <tseliot> pitti: there's nothing there but maybe the cache was emptied
[11:13] <pitti> tseliot: I mean *in* the live system
[11:14] <pitti> (the cache dir isn't copied to the installed system)
[11:14] <tseliot> pitti: I am sure that the driver was installed and the the module was built because when this happens you can hear the login sound and network manager says that it disconnected and reconnected to the internet
[11:14] <tseliot> pitti: too late, I have installed Ubuntu in Virtualbox. I can try the livecd again
[11:15]  * tseliot tries the livecd again
[11:17] <tkamppeter> pitti, I have uploaded an new system-config-printer package. Can you start this version and do the following:
[11:20] <tkamppeter> pitti, click "New Printer", select an arbitrary detected printer, Forward, "Search for a printer driver to download", Make and Model: "HP LaserJet 3390", Search, Forward,
[11:22] <tkamppeter> pitti, then you see on the next screen a description of the downloadable PPD for the HP LaserJet 3390. Can you make Jockey providing the same info when it has found a printer driver?
[11:22] <pitti> tkamppeter: can you please put that information into a bug report? I'll look into it
[11:23] <tkamppeter> pitti, there is already a bug report, I could add there that I implemented rthe display of the info in s-c-p.
[11:23] <pitti> tkamppeter: that works, too
[11:26] <slangasek>   dpkg --compare-versions $2 lt 3.1-pre11-1 || return 0
[11:26] <slangasek> [...]
[11:26] <slangasek>   dpkg --compare-versions $2 lt 3.2-pre9-4 || return 0
[11:26]  * slangasek coughs
[11:27] <cjwatson> I hope that code is only run in cases where $2 may not be empty
[11:27] <slangasek> yes
[11:28] <slangasek> it's still broken, though :)
[11:28] <cjwatson> well, yes :)
[11:29] <siretart> slangasek: in case you're processing the NEW right now, the 'ffmpeg' package is targeted for multiverse (whereas 'ffmpeg-debian' should stay in main)
[11:29] <tseliot> pitti: /var/cache/jockey/installed_packages contains only nvidia-glx-177 (which is ok, I guess)
[11:29] <pitti> tseliot: ah, I just fixed the boilerplate text in the KDE window if no driver is available
[11:29] <slangasek> siretart: I saw ffmpeg in the new queue and started sobbing into my beer
[11:29] <pitti> tseliot: that sounds fine
[11:29] <pitti> tseliot: that list should get installed into the target system
[11:30] <siretart> slangasek: if you have any question about that package, I'm happy to answer them
[11:30] <pitti> tseliot: by /usr/lib/ubiquity/target-config/31jockey_pkgs (shipped by jockey-common)
[11:30] <siretart> slangasek: as for potential or maybe patent problems, we have far worse examples already in multiverse, so I wouldn't expect THAT to be a problem
[11:30] <tseliot> pitti, cjwatson: is it possible that the cache is wiped before ubiquity takes that list?
[11:32] <tseliot> pitti: shouldn't that file say "apt-get install" ?
[11:32] <pitti> tseliot: no, apt-install is a d-i command
[11:32] <tseliot> pitti: ok, I just wanted to be sure
[11:33] <tseliot> pitti: I thought I had fixed the problem with the KDE ui when no handlers are available
[11:33] <slangasek> siretart: I'm primarily bothered by the code duplication.  So, all 6 of these libraries have to be rebuilt to enable the fuzzy stuff?
[11:34] <pitti> tseliot: the crash, yes, but not the boilerplate elements like License: (license)
[11:34] <pitti> tseliot: oh, maybe in your branch, indeed
[11:34] <pitti> tseliot: I noticed it in GTK, too, and just fixed it in both
[11:34] <tseliot> pitti: aah, that
[11:34] <pitti> tseliot: anyway, I'll merge from your's again now
[11:34] <tseliot> pitti: ok
[11:38] <siretart> slangasek: I'm aware of the code duplication and I already have a plan to avoid that, or at least to make it managable. For intrepid this is the best solution I've come up with. for jaunty I promise to have a better solution
[11:39] <siretart> I have sketched that plan on the pkg-multimedia mailing list, however alioth seems down, so I cannot give you the reference right now
[11:39] <cjwatson> tseliot: which cache?
[11:39] <slangasek> siretart: ok.  the new queue is behind freeze exceptions on my todo list, but I won't run screaming from it then :)
[11:39] <siretart> thanks!
[11:39] <tseliot> cjwatson: /var/cache
[11:40] <cjwatson> tseliot: any particular bit of it?
[11:40] <tseliot> cjwatson: /var/cache/jockey/installed_packages
[11:40] <cjwatson> tseliot: ubiquity doesn't wipe /var/cache, in general
[11:40] <tseliot> cjwatson: that's created by jockey (even in the livecd) when you install a driver
[11:41] <pitti> so the file is created in the live system,but a following ubiquity install doesn't install the packages it mentions?
[11:41] <tseliot> cjwatson: I'm not blaming it on ubiquity, I'm just trying to figure out what might have gone wrong in the installation process
[11:41] <cjwatson> if /var/cache/jockey/installed_packages exists, I don't see any reason that code shouldn't work
[11:41] <cjwatson> tseliot: I would like to see the installation log though
[11:45] <tseliot> cjwatson: http://pastebin.com/m1afbdb4c
[11:46] <pitti> should the script appear there? or anything like "target-config"?
[11:47] <pitti> should the script appear there? or anything like "target-config"?
[11:49] <cjwatson> tseliot: I have a suspicion that this only works if the packages in question are on the CD
[11:50] <tseliot> cjwatson: if the DVD installer is available I can try it and see if I can reproduce the problem with it too
[11:50] <cjwatson> I'm not quite sure though
[11:50] <cjwatson> tseliot: it would be worth putting set -x at the top of the script so that we get a shell execution trace
[11:51] <cjwatson> actually, no, the above comment (packages in question on the CD) ought to be false
[11:51] <cjwatson> can you check /var/lib/ubiquity/apt-installed please?
[11:52] <tseliot> cjwatson: there's no such directory in my system
[11:53] <cjwatson> tseliot: even after the installer has run?
[11:54] <tseliot> cjwatson: I'm using the installed system. Shall I boot into the installer, install again and see if I can find that file?
[11:54] <cjwatson> tseliot: please
[11:54] <tseliot> ok
[11:55] <tkamppeter> pitti, bug 269454 updated
[11:57] <pitti> tkamppeter: danke
[12:15] <liw> I'd like to get system-cleaner in intrepid updated to a bug-fixed version (274715, 274717, 275034); should I discuss this with release managers before asking for a sponsor to upload?
[12:17] <slangasek> tseliot: on bug #220563, why do we not simply promote screen-resolution-extra to be a dependency of gnome-control-center?
[12:18] <slangasek> tseliot: given that it's already a recommends and therefore installed by default
[12:19] <tseliot> slangasek: of course I have no objections on this. I would like to know what seb128 or bryce_ think of it
[12:19] <seb128> tseliot: about what?
[12:19] <slangasek> seb128: gnome-control-center Depends: screen-resolution-extra, instead of adding extra code to g-c-c to handle s-r-e being absent
[12:20] <slangasek> it's not a difference in CD size at all, we'd just be promoting a Recommends to a Depends
[12:20] <seb128> right, that would work for me too
[12:20] <tseliot> oh, and BTW s/objections on/objection to/
[12:21] <seb128> but there is no real point to do that
[12:21] <seb128> it should be a recommends
[12:22] <slangasek> the point would be to not write extra code and add additional UI strings just to keep it as a recommends
[12:22] <seb128> recommends are installed by default, they just give the flexibility to users who don't want those to uninstall
[12:22] <slangasek> (well, the code is written; but we wouldn't have to include it)
[12:22] <seb128> what changing to a depends would bring?
[12:23] <slangasek> seb128: it would solve the error condition in bug #220563
[12:23] <tseliot> seb128, slangasek:  this is the link to the FFE: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/275977
[12:24] <seb128> slangasek: I would say it's a minor issue and can be delayed to next cycle, it's only a bug for people who don't install recommends
[12:24] <tseliot> slangasek: aah, the extra strings are the problem
[12:24] <slangasek> tseliot: eh, you also subscribed ubuntu-release to bug #220563 and sent a debdiff there...
[12:25] <tseliot> slangasek: yes, I was suggested to do so but at that point I couldn't unsubscribe ubuntu-release from the 1st bug report
[12:28] <tseliot> cjwatson: the installation process is not complete yet, however I can see both apt-installed (which contains also nvidia-glx-177) and the jockey_installed filed in /var/cache/jockey/
[12:29] <tseliot> cjwatson: would you like to see the full apt-installed file? Or is there any other file  you would like to have a look at?
[12:32] <cjwatson> tseliot: the former - apt-installed should be short
[12:32] <cjwatson> I have to take the dog out now, but will follow up when I get back
[12:33] <cjwatson> tseliot: is the nvidia-glx-177 package installed in /target?
[12:33] <tseliot> cjwatson: let me check
[12:34] <tseliot> cjwatson: if I do ls /target/var/lib/dpkg/info | grep nvidia
[12:35] <pitti> tseliot: you can sudo chroot /target and use dpkg -s, dpkg -L , etc.
[12:35] <slangasek> ummm.  why does firefox want to use 'bazaar' as a handler for diffs?
[12:36] <tseliot> cjwatson: only nvidia-common and the nvidia-VER-modaliases files show up. No trace of nvidia-glx-177 or nvidia-177-kernel-source
[12:37] <Keybuk> soren: since updating desktop to Intrepid Beta, NFS mounts aren't mounted anymore on boot?
[12:37] <liw> Keybuk, they are for me (but I have two default routes, which messes other things up)
[12:38] <tseliot> pitti: right
[12:40] <tseliot> cjwatson, pitti: dpkg --list | grep nvidia confirms that the package wasn't installed
[12:41] <pitti> tseliot: would be interesting to check whether /usr/lib/ubiquity/target-config/31jockey_pkgs was actually run; sth. like "set -x" and "exec 2>/tmp/jockey.txt
[12:44] <tseliot> pitti: shall I reinstall Ubuntu?
[12:45] <pitti> tseliot: maybe cjwatson will have additional ideas when he returns; but for now we don't even know whether the script doesn't run, or whether apt-install fails, right?
[12:45] <pitti> tseliot: so yeah, if it doesn't cause you trouble, changing the script that way and reattempting the installation would be interesting
[12:46] <tseliot> pitti: yes. I find it a bit weird that the package is in apt-installed though
[12:46] <pitti> tseliot: oh!
[12:46] <pitti> tseliot: ok, then I'm pretty sure that the script itself ran
[12:51] <soren> Keybuk: Oh dear. Soething you could look into? I've started paternity leave today..
[12:52] <pitti> soren: oooh! congratulations, and good luck! *hug*
[12:56] <kwwii> seb128: I guess we should talk sometime about the gnome-themes package...bascially, we need to remove everything except the high-contrast themes
[12:57] <seb128> kwwii: could you mail the ubuntu desktop list? I don't like how things are being decided without public discussions there
[12:58] <wtgee> Hola all...I am trying to become an ubentero and gpg doesn't seem to be sending the keys or doing anything...pilot error?
[12:58] <kwwii> erm, ok but mark wanted me to report to him on wendesday about how far we are with this :-)
[12:59] <slangasek> seb128: is it your opinion that f-spot should not be updated for intrepid?  I'm likely to refuse this FFe request unless someone on the desktop team speaks up on behalf of it
[12:59] <cjwatson> pitti: right, if it's in apt-installed then the target-config script ran; that was the point of that test
[12:59] <seb128> kwwii: you can tell him that such changes should be discussed somewhere so the community doesn't feel excluded etc
[13:00] <Hobbsee> kwwii: is that dreary wallpaper *really* the final one?
[13:00] <cjwatson> pitti: so that suggests to me that install_extras is busted, *again* - sigh
[13:00] <Hobbsee> (speaking of changes not being discussed in public)
[13:00] <seb128> slangasek: no, I think it should be upgraded but I'm not wanting to do the upgrade ;-)
[13:00] <kwwii> Hobbsee: no
[13:00] <slangasek> seb128: ah, heh :)
[13:01] <Hobbsee> kwwii: oh thank goodness.  What's the new one like?
[13:01] <Hobbsee> kwwii: and when will it land?
[13:01] <kwwii> Hobbsee: it is one that everybody loves :p
[13:01] <Hobbsee> oh, bah.
[13:01] <kwwii> Hobbsee: asap
[13:01] <seb128> kwwii: the change is an half an hour work so there is no issue to do it, I would just like a public mail about the suggested changes and the rational before doing that so we don't have "what the heck are you doing" bugs and comments
[13:01] <Hobbsee> kwwii: hope you haven't seen brainstorm then.  or the forums :P
[13:01] <Hobbsee> kwwii: excellent!  Where can we see it?  :)
[13:01] <pitti> cjwatson: ok, I'll add the current findings to bug 258486
[13:02] <pitti> cjwatson: should that be ubiquity, or some d-i component?
[13:02] <stgraber> slangasek: bug 278399 and bug 278425 for LTSP
[13:02] <cjwatson> pitti: ubiquity
[13:02] <kwwii> Hobbsee: I am going to use one of the pics on the wiki, either one from rico or thorsten
[13:04] <ogra> stgraber, you should probably mention that the "cosmetic change" in ldm fixes a regression
[13:04] <Hobbsee> kwwii: i look forward to seeing it, as there are many pics on the wiki.
[13:04] <seb128> slangasek: upstream seems to expect the new f-spot version being shipped in the distros coming and blogged about that, and I would argue that f-spot is buggy enough anyway so new versions are not a stability issue anyway
[13:04] <stgraber> ogra: oh ? I didn't know :)
[13:04] <kwwii> Hobbsee: something like https://wiki.ubuntu.com/Artwork/Incoming/Intrepid/Earthenibex_wallpaper
[13:05] <slangasek> seb128: ok; I don't see that anyone currently on that bug is offering to prepare the package, though
[13:05] <wgrant> kwwii: That's nice, but it'd need to be scaled down a bit to make the desktop usable.
[13:05] <ogra> stgraber, the password entry moved to the side with a patch early in the dev cycle, that patch centers it again
[13:06] <Hobbsee> kwwii: nice
[13:06] <seb128> slangasek: right, I'll try to see if some of the active desktop team contributors is wanting to do it in the next days
[13:07] <ogra> stgraber, oh, and we should probably also get a fix for bug 277331 in
[13:08] <ogra> i think the "--copy-sourceslist" fix is the best way to go
[13:08] <ogra> (i.e. using that as default option if not on CD)
[13:11] <kwwii> wgrant: yeah, that was my thoughts as well
[13:11] <ogra> meh, does anyone else see errors when trying to install devscripts ?
[13:11] <ogra> http://paste.ubuntu.com/54610/
[13:11] <stgraber> ogra: hmm right, that may break ltsp-cluster though
[13:11] <stgraber> ogra: as I add a PPA to the sources.list, not sure if that will be overwritten or not
[13:11] <kwwii> http://bazaar.launchpad.net/~t-w-/ubuntu-artwork/thorwils_backgrounds/annotate/32?file_id=rsc_ibex_woodblock.j-20080927154856-l2xo5c38l0j5uun8-6 might be better in that regards
[13:12] <ogra> stgraber, add it after the copy-sourceslist plugin ran then
[13:12] <stgraber> ogra: anyway, for now best is to get both packages uploaded, the remaining bugs can be fixed without changes to upstream release (they are Ubuntu specific)
[13:12] <ogra> yeah
[13:13] <Hobbsee> ogra: i *do* hope that pastebin, if linked to the line above, wasn't a serious question.
[13:13] <ogra> Hobbsee, it was, the recomends of devscripts are *insane*
[13:13] <Hobbsee> ogra: i'm aware of that.  But you didn't give the error from above.
[13:14] <ogra> Hobbsee, it tires to install an MTA, isnt that error enough ?
[13:15] <Hobbsee> ogra: surely, then, that's a bug about "devscripts wants to install a MTA".  Saying that there are "errors when installing devscripts" implies a packaging error, and packaging uninstallability.
[13:15] <ogra> Hobbsee, additionally all of these packages run invoke-rc.d inside a chroot ..
[13:16] <liw> ogra, invoke-rc.d is supposed to be run
[13:16] <liw> ogra, invoke-rc.d then calls policy-rc.d to see if it should do anything
[13:16] <Hobbsee> which is a fix someone will probably want to delve in quickly, rather than the longer process of figuring out which ones can be removed, and dealing with any mailing list complaints because of your changes.
[13:16] <mok0> ogra: the application "gamgi" is in ubuntu universe for ii. You may want to include it in your edubuntu seed
[13:16] <ogra> liw, all of them *require* proc to be mounted for invoke-rc.d
[13:17] <ogra> thas not really kosher for chroots imho (beyond the fact that i dont want an mta just because i unpack and resign a source package)
[13:18] <liw> ogra, hm, how do they require /proc in a way that no other packages require?
[13:18] <ogra> devscripts pulls in a massive amount of extra crap through its recommends
[13:18] <Keybuk> soren: I'm not home that much between now and release :-/
[13:18] <ogra> it used to be a slim thing
[13:19]  * ogra doesnt get why he would need x-www-browser in a chroot for example 
[13:20] <jcristau> it's ok, you don't need devscripts in a chroot either
[13:21] <ogra> liw, no, but they simply require /proc ... which wasnt the case before ... when installing devscripts in hardy you get a small set of packages for manually fiddling with packages, when installing it in intrepid i get 100M more or so
[13:21] <ogra> which is just a waste
[13:21] <ogra> jcristau, if i work on packages for lpia i *need* a chroot with devscripts
[13:23] <Keybuk> err
[13:24] <Keybuk> why is there a discussion about /proc being required or not? :p
[13:24] <Keybuk> /proc is always mounted
[13:24] <ogra> Keybuk, my discussion point isnt /proc (though i dont like to have it required now) my point is that i dont want my chroots to explode by 100s of megabytes to silly recommends
[13:25] <Keybuk> it's required
[13:25] <ogra> its never been mounted in my chroots up to now
[13:25] <Keybuk> so many things break if it's not there
[13:25] <Keybuk> like ps, pidof, killall, etc.
[13:25] <ogra> and if we *require* it chroot should be patched to mount it yutomatically
[13:25] <ogra> *automatically
[13:25] <Keybuk> that's not a bad idea (well, dchroot)
[13:26] <Keybuk> I'm actually strongly considering having Upstart hard-coded to mount /proc and /sys
[13:26] <jcristau> schroot already does that afaik
[13:26] <Keybuk> since the overhead of /bin/mount is faintly ridiculous for a single syscall
[13:27] <ogra> anyway, i dont see why i should need to buy bigger disks for the ten chroots i use for development for different purposes because they suddenly require a gig more on disk together
[13:27] <Keybuk> jcristau: you appear to be correct
[13:27] <liw> I don't see big differences in the Depends of devscripts in hardy vs intrepid
[13:27] <Keybuk> ogra: use schroot ;)
[13:27] <ogra> liw, we didnt use any recommends of them
[13:27] <ogra> look at the recommends
[13:27] <liw> ogra, sure, but you don't _have_ to install recommends
[13:28] <ogra> we should have a devscripts-light or some such then
[13:28] <liw> ogra, how do you install devscripts?
[13:28] <ogra> apt-get install devscript
[13:29] <ogra> (and yes, i'm aware of the apt option)
[13:30] <ogra> my point is that people wont expect that and that there are others that even have scripts that keep their chroots up to date automatically ... havng a chroot filled with 100s of MB of crap isnt a good idea imho
[13:30] <Keybuk> do you mean MB or MiB?
[13:30] <cjwatson> I'm amazed you've managed to get by for so long without /proc mounted in your chroots; I've been mounting it in my development chroots for years
[13:30] <ogra> especially with stuff that totally isnt needed for ubuntu package development
[13:30] <cjwatson> ogra: you could just use apt-get --no-install-recommends install devscripts
[13:31] <ogra> Keybuk, that think with the M in the beginning :P
[13:31] <cjwatson> if you don't like them, that is the proper answer
[13:31] <liw> Keybuk, that was lame. You owe me an explanation of why I get two default routes under intrepid (when using bridging).
[13:31] <slangasek> or you could configure your chroot to always use --no-install-recommends
[13:31] <ogra> cjwatson, yes, i said i'm aware of that above
[13:31] <Keybuk> liw: nuffin' t'do wi' me guvna
[13:31] <slangasek> which is sorta the sensible thing to do anyway
[13:31] <cjwatson> ogra: the option is there for people like you :-)
[13:31] <ogra> slangasek, no, because i want the recommends for the other packages
[13:31] <slangasek> ogra: in a dev chroot?  I assert that you do not :)
[13:32] <cjwatson> ogra: if everyone demands that their use case needs to be the default, we will never be able to satisfy everyone
[13:32] <ogra> i might test installability :)
[13:32] <liw> would anyone be willing to sponsor an upload of system-cleaner from REVU for me? 1.10 in REVU fixes several bad problems that are in the 1.8 version in intrepid
[13:32] <slangasek> recommends-by-default gives wrong results for any sort of build-dep checking
[13:32] <ogra> cjwatson, i just dont want it to regress so badly
[13:32] <Keybuk> . o O { why does blogs.msdn.com need to use such a small font? }
[13:32] <cjwatson> ogra: for most people, I assert that it's an improvement
[13:32] <Keybuk> cjwatson: my use case should be the default, and so should yours ;)  everyone else can customise <g>
[13:33] <ogra> having exim in a chroot is an improvement ?
[13:33] <doko> tkamppeter: when did hplip-gui introduce the dependency on python-reportlab?
[13:33] <slangasek> liw: why is it on REVU, rather than an LP bug + ubuntu-universe-sponsors?
[13:33] <ogra> or subversion ?
[13:33] <Keybuk> (the fact that we completely disagree on everything makes that a humorous statement)
[13:33] <slangasek> liw: I thought REVU was only used for new packages
[13:33] <cjwatson> ogra: not having scripts installed that won't run is an improvement
[13:33] <liw> slangasek, I thought REVU was supposed to be used for all uploads
[13:33] <cjwatson> ogra: you're microfocusing on the problem you see rather than the reasons behind it
[13:33] <ogra> ... or www-browser
[13:34] <cjwatson> Keybuk: :-)
[13:34] <ogra> cjwatson, well, that microfcusing results in several 100M per chroot on my disk :)
[13:35] <cjwatson> ogra: only because you're stubbornly refusing to use the option to make it not do so ...
[13:35] <cjwatson> www-browser is a little silly; bts only needs sensible-browser
[13:35] <cjwatson> and works fine with w3m
[13:35] <slangasek> liw: in my experience, it's only used for new packages; I don't know if using the ubuntu-universe-sponsors queue will get it uploaded faster in practice, but it improves the chances of me looking at it personally, given that I would have to look up where REVU is located :)
[13:36] <liw> slangasek, right. I'm now looking for the next elusive wiki page to describe this :)
[13:36] <ogra> well, i see i wont convince anyone here  ...
[13:36] <liw> slangasek, it's as if all development docs were distributed in a maze of small hypertext pages, all alike
[13:36] <cjwatson> ogra: I agree that there are problems, but it would be much better to address them calmly rather than railing against recommends (which were always supposed to be installed along with the package in normal situations, per policy) and throwing around big numbers
[13:36] <slangasek> liw: https://wiki.ubuntu.com/SponsorshipProcess
[13:36] <ogra> even though it feels like adding mono to build-essential ... i guess i'll have to live with it
[13:36] <cjwatson> no, you could use the option
[13:36] <slangasek> liw: feel free to link to that from whatever page failed to inform you of it :)
[13:37] <cjwatson> you don't have to live with it
[13:37] <ogra> thats whyt i mean by live with it
[13:37] <ogra> though i would prefer to have the old devscripts behavior back and just have a "devscripts-full" for the recommends
[13:38] <cjwatson> there is no point to --no-install-recommends if we're just going to take every package with recommends and split it into foo and foo-full
[13:38] <liw> ogra, to get that done, you probably want to talk this over with devscript maintainers in Debian
[13:38] <cjwatson> (I know you didn't say that, but it's the logical conclusion)
[13:39] <liw> (it's unlikely to happen, but that'd be the right place)
[13:39] <ogra> yeah, i get that
[13:39] <tseliot> cjwatson: is there any other file (in the live system) you would like to have a look at or can I shut down virtualbox?
[13:39] <cjwatson> tseliot: /target/etc/apt/sources.list and a listing of the files in /target/var/lib/apt/lists/ would be nice
[13:40] <cjwatson> (I was just getting back to you ...)
[13:40] <slangasek> pitti: it appears we still don't have a viable set of packages for ekiga 3.0? :( (#274085)
[13:43] <soren> pitti: Thanks! :)
[13:43] <soren> Keybuk: Ok. I'll try to look into it. Is there are bug report about it?
[13:43] <Keybuk> soren: I wouldn't know what to put in one other than "FAIL"
[13:44] <cjwatson> pitti,tseliot: it does look as if *no* packages are being installed by install_extras
[13:53] <soren> Keybuk: Can I see your /etc/network/interfaces, please?
[13:54] <Keybuk> soren:
[13:54] <Keybuk> auto lo
[13:54] <Keybuk> iface lo inet loopback
[13:54] <Keybuk> --
[13:55] <ogra> do we still maintain a blacklist for compiz ?
[13:55] <ogra> it appears that compiz it used by default on geode systems, that doesnt work
[13:55] <ogra> hmm, ENOMVO
[13:56] <Keybuk> ogra: /usr/bin/compiz is still a shell script
[13:56] <Keybuk> and it still has a driver _whitelist_
[13:56] <ogra> weird ...
[13:56] <Keybuk> what driver are you using?
[13:56] <ogra> i have reports from someone using ubuntu-mobile on a geode based system
[13:57] <tseliot> cjwatson: did you get the links to the sources.list and the other files or shall I post them again? (I've noticed that you were disconnected)
[13:57] <ogra> and he complains about the massively slow effects
[13:57] <ogra> apparentl its a AMD Geode LX800
[13:57] <ogra> should use the nsc driver iirc
[13:58] <ogra> which definately isnt in that whitelist
[13:58] <cjwatson> tseliot: I wasn't disconnected - it was a netsplit that we were on opposite sides of
[13:58] <soren> Keybuk: That's it? Nothing commented out or anything?
[13:58] <Keybuk> soren: the wired card is brought up by NM
[13:58] <cjwatson> tseliot: I didn't get them, but please put them in the bug
[13:58] <tseliot> cjwatson: ok
[13:58] <soren> Keybuk: Yeah, I guessed.
[14:01] <jcristau> ogra: compiz wouldn't even start on a geode, afaik
[14:01] <Keybuk> soren: logs suggest Network Manager brought up the wired during the boot as usual; and didn't wait for login
[14:01] <ogra> jcristau, hmm, i wonder why he complains about slow effects then, od we default to have composite on in metacity now ?
[14:01] <ogra> *do
[14:02] <Keybuk> ogra: apt-get source metacity
[14:02] <Keybuk> ogra: apt-get install less
[14:02] <ogra> :P
[14:04] <cjwatson> Keybuk: miaow
[14:04] <mok0> ogra, did you see my shout ~45 minutes ago?
[14:06] <soren> Keybuk: You never responded to this: 12:58:24 < soren> Keybuk: That's it? Nothing commented out or anything?
[14:09] <tkamppeter> doko, I think hplip-gui always depended on python-reportlab. What is the problem?
[14:09] <Keybuk> soren: that's it, nothing commented out
[14:09] <Keybuk> sorry, I thought that was implied by "NM brings the interface up"
[14:11] <soren> Keybuk: I just wasn't sure if that was a response to that since you only took two seconds to see my question, think up a response, and then type it :)
[14:11]  * soren bows to Keybuk's mad typing skillz
[14:11] <ogra-n800> grr, so a simple killall firefox killed my laptop now
[14:11] <ogra-n800> oh fun and after reboot i have no graphics output at all
[14:11] <ogra-n800> hmm, second reboot works... at least i see usplash
[14:12]  * ogra checks for upgrades
[14:12] <Keybuk> did you have /proc mounted? :p
[14:12] <ogra> pfft
[14:13] <ogra> ok, i'm behing on kernel ... that might be it
[14:13] <Keybuk> I actually ask, because killall defaults to killing *all* processes if you don't <g>
[14:13] <ogra> well, there was clearly somethng wrong with the graphics after rebooting
[14:14] <Hobbsee> wubi pops up a dialog when you put an ubuntu cd into a windows machine, asking if you want to install it, doesn't it?
[14:14] <ogra> i probably forgot to unmount proc in the chroot i used before though :P
[14:15] <evand> Hobbsee: umenu does.  Wubi is an option in umenu.
[14:15] <Hobbsee> evand: cool :)
[14:15]  * Hobbsee edits brainstorm more
[14:15] <liw> soren, do you happen to know about network configs? my desktop is using a setup copied from KVM's wiki page and under intrepid I'm now getting double routes (which means packets go nowhere in some cases)
[14:17] <soren> Keybuk: Hypothesis: Before I "fixed" mountnfs, do you think it might have tried to mount the nfs mounts straight away (like say when it brought up lo), and then only actually finished mounting it when the network came up?
[14:18] <soren> liw: I'd blame NetworkManager. :)
[14:18] <liw> soren, hmm, I can try removing that
[14:19] <soren> liw: Either that, or try commenting out the nic's in /e/n/i.
[14:19] <liw> soren, which nic? eth0?
[14:19] <soren> liw: the one that gets configured twice.
[14:19] <Keybuk> soren: it looped waiting for a network device to come up I thought :p
[14:20] <ogra> soren, err
[14:20] <ogra> we use that in ltsp ... please dont break it
[14:20] <soren> Keybuk: A cursory galnce at the code at least suggests that it'd bail unless it was configuring the final interface marked "auto".
[14:21] <ogra> (assuming you talk about the one in initramfs-tools)
[14:21] <soren> ogra: I'm not.
[14:21] <ogra> phew, ok
[14:21] <ogra> then ignore me :)
[14:21] <soren> ogra: I'm talking about /etc/network/if-up.d/mountnfs
[14:21] <ogra> ah
[14:22] <soren> Keybuk: ...but to be perfectly honest, I've not read all the code. I just saw the very clearly wrong path in there, fixed it, saw that it removed an error message, and thought all was good.
[14:23] <soren> Keybuk: I'm kind of wondering why it worked before. :/
[14:24] <liw> soren, hmm, right, if I disable NM (/etc/init.d/NetworkManager stop), then the double route doesn't happen, so now I need to figure out how to tell NM to not touch eth0 (the rules of which seem to have changed again)
[14:24] <ogra> liw, it should manage eth0
[14:24] <liw> ogra, why?
[14:25] <ogra> liw, it has a handler for /e/n/i now, but thats buggy, afaik asac is working on a fix
[14:25] <ogra> liw, because thats the central point for handling interfaces now ... it's supposed to handle all of them centrally
[14:26] <ogra> even on commandline systems
[14:26] <asac> ogra: i enabled it now
[14:26] <liw> ogra, I don't understand you at all now; NM has had a handler for /e/n/i for a long time now, and NM most certainly has no business at all touching eth0 on my desktop
[14:26] <asac> ogra: will send a mail to -devel after lunch
[14:26] <ogra> good
[14:26] <asac> liw: upgrade to latest NM ... default is "unmanaged" mode
[14:27] <liw> asac, define latest? this is upgraded today
[14:27] <asac> liw: so if you do nothing NM should stop managing devices in eni
[14:27] <asac> liw: the present is: network-manager 0.7~~svn20081004t225044-0ubuntu1 ... everything else is the "past"
[14:27] <asac> :)
[14:28] <liw> asac, is that a very recent upload?
[14:28] <asac> liw: uploaded 1h ago? :-P
[14:29] <liw> no wonder it isn't on my local mirror, then :)
[14:30] <asac> liw: < liw> ogra, I don't understand you at all now; NM has had a handler for /e/n/i for a long time now, and NM most certainly has no  business at all touching eth0 on my desktop
[14:30] <asac> liw: in intrepid LP: #< liw> ogra, I don't understand you at all now; NM has had a handler for /e/n/i for a long time now, and NM most certainly has no  business at all touching eth0 on my desktop
[14:30] <asac> oops
[14:30] <asac> liw: LP: #256054
[14:30] <asac> ;)
[14:31] <Keybuk> soren: before, the boot used to mount nfs mounts in an /etc/network/if-up.d script
[14:31] <Keybuk> I wonder
[14:31] <Keybuk> asac: NM still runs those, right? :)
[14:31] <soren> Keybuk: Right. That's what I touched.
[14:31] <soren> I was just about to ask that.
[14:31] <soren> I don't see networkmanagerdispatcher anymore.
[14:32] <asac> Keybuk: yes. thats the idea
[14:33] <Keybuk> asac: how are they run?
[14:33] <asac> soren: its a dbus action now
[14:33] <asac> /usr/lib/NetworkManager/nm-dispatcher.action
[14:33] <asac> Keybuk: ^^
[14:33] <Keybuk> what's a "D-Bus Action" ?
[14:34] <asac> Keybuk: /usr/share/dbus-1/system-services/org.freedesktop.nm_dispatcher.service
[14:34] <asac> so service ;)
[14:34] <Keybuk> err
[14:34] <Keybuk> so what causes that to be executed?
[14:34] <Keybuk> because it's so not running here
[14:34] <asac> dbus activation?
[14:34] <Keybuk> but that used to listen to D-Bus signals before
[14:35] <Keybuk> did someone replace the D-Bus signals with method calls on the dispatcher?
[14:35] <asac> Keybuk: yes. now its auto activated and shuts down when finished
[14:35] <Keybuk> and what does the dispatcher do now?
[14:35]  * ogra reboots
[14:35] <asac> Keybuk: same as before. running /etc/NetworkManager/dispatcher.d/
[14:36] <guysoft42> hey all, i seem to have the following error in my repository when running $ reprepro check:Internal error of the underlying BerkleyDB database:  Within packages.db subtable hardy|main|i386 at c_get(DB_NEXT): DB_PAGE_NOTFOUND: Requested page not found . what to do?
[14:37] <Keybuk> asac: ok
[14:37] <Keybuk> need to reboot after a kernel update, so let me see if it actually runs that
[14:37] <asac> soren: Keybuk: if you see particular issues, let me know
[14:37] <doko> tkamppeter: could you check the cover generation with this package (new upstream version): https://edge.launchpad.net/ubuntu/intrepid/+queue?queue_state=1&queue_text=python-reportlab
[14:37] <asac> didnt test for the last month or so, but last time i looked it worked quite well
[14:39] <ogra> shriek
[14:39] <ogra> starting virtualbox turned all my gtk into QT !!!!
[14:39] <soren> Keybuk: I see the script running.
[14:40] <soren> Keybuk: I put a "echo foo > /tmp/ping" at the top of mountnfs, and that worked.
[14:40] <soren> Keybuk: (just tested it for my gprs connection)
[14:40] <ogra> ah, no, it just made gnome-settings daemon crash
[14:41] <asac> ogra: so you mean s/QT/plain GTK theme/ :)
[14:42] <ogra> :)
[14:43] <soren> Keybuk: I'm in a hospital room right now with nothing but a gprs connection, so it's kind of hard to debug much right now. I'll take a peek when I get home and find some free time.
[14:43]  * Keybuk hugs dkms
[14:43] <Keybuk> now it works, I like it
[14:43] <ogra> ah, better
[14:43] <madduck> how are the chances of intrepid being released before 20 october?
[14:43] <ogra> so now, why cant i enable compiz
[14:45] <slangasek> madduck: ... zero?
[14:45] <ogra> heh
[14:45]  * madduck is trying to schedule a study involving ubuntu people so as to not conflict with the final sprint...
[14:45] <slangasek> madduck: https://wiki.ubuntu.com/IntrepidReleaseSchedule
[14:45] <ogra> even before oct 30th according to the schedule
[14:45] <Keybuk> madduck: Intrepid is released on the _30th_ of October
[14:46] <madduck> ah, i didn't know about that page
[14:47] <Keybuk> slangasek: temped to make a https://wiki.ubuntu.com/JauntyReleaseSchedule with just "WHEN IT'S READY HA HA HA" on it :p
[14:47] <Keybuk> asac, soren: ok machine came back after reboot
[14:47] <Keybuk> so NM is definitely bringing up the interface before login
[14:47] <madduck> Keybuk: that would not be an acceptable answer to my question in this case, funny person you! :)
[14:47] <Keybuk> nm-dispatcher did call 01ifupdown, which did a run-parts on /etc/network/if-up.d
[14:48] <Keybuk> soren: mountnfs was called for eth0, but appears to have not done anything
[14:48] <Keybuk> ah, my bad
[14:48] <Keybuk> let's try another reboot
[14:49] <slangasek> superm1: blah, why are the packages in the bluetooth ppa not using ppa version numbers? (evolution, totem)
[14:50] <Keybuk> madduck: could you not schedule your thingy to co-incide with UDS?
[14:51] <madduck> Keybuk: my study will run for several weeks (although the individual involvement totals at a few hours)
[14:51] <Keybuk> soren: interesting ...
[14:51] <madduck> Keybuk: what would be the benefit of making it happen in sync with UDS?
[14:52] <Keybuk> mountnfs never called mount
[14:52] <Keybuk> madduck: ease of participation from ubuntu people?
[14:52] <madduck> Keybuk: i'd say that UDS might actually make it harder for people to work on my study, just judging from my own summit/conference experience.
[14:52] <ogra> Keybuk, ogra@osiris:~$ compiz --replace
[14:52] <ogra> Checking for Xgl: not present.
[14:52] <ogra> Detected PCI ID for VGA:
[14:52] <ogra> Checking for texture_from_pixmap: Segmentation fault
[14:52] <ogra> not present.
[14:52] <ogra> thats on a i965
[14:52] <madduck> Keybuk: so you think UDS would make it easier for people to participate?
[14:52] <Keybuk> madduck: well, they'd be already there?
[14:53] <Keybuk> I don't know what you're asking them to participate in?
[14:53] <ogra> i assume its shouldnt really segfault
[14:53] <madduck> an email discussion; you should have gotten a message about it, didn't you?
[14:53] <madduck> Keybuk: ^
[14:53] <madduck> Keybuk: <20080926143635.305A34524@piper.oerlikon.madduck.net>
[14:53] <Keybuk> oh, is that what that is?
[14:53] <madduck> yes
[14:53] <Keybuk> I confess that is sitting unread in my inbox
[14:54] <madduck> I confess it's rather lengthy and scary. :)
[14:54] <tseliot> ogra: does glxinfo segfault too?
[14:54] <ogra> yes
[14:54] <Keybuk> soren: ooooh, I have a *fun* bug report to write
[14:54] <Keybuk> something, during the upgrade process, must have edited /etc/fstab
[14:54] <Keybuk> and left it without a final newline
[14:54] <madduck> Keybuk: but it's a very cool method, I think, you might get a chance to look at it still. I did extend the deadline till Thursday...
[14:54] <Keybuk> it appears that mountnfs ignores the last line if it doesn't have a final newline
[14:54] <slangasek> that's the email that says "I'd like to take 5 minutes of your time" and then includes 10 minutes worth of text with a request at the end? ;)
[14:54] <tseliot> ogra: and what card model do you use?
[14:54] <Keybuk> so it ignored my nfs mount :p
[14:54] <madduck> anyway, sorry for the OT and thanks for all the help.
[14:55] <madduck> I will consider UDS when making scheduling plans too.
[14:55] <tseliot> ogra: and what driver?
[14:55] <ogra> tseliot, i965GM/GL960
[14:55] <ogra> intel i guess
[14:55] <ogra> i have no xorg.conf
[14:55] <Keybuk> (see also: why parsing fstab in shell a hundred times during boot is *BAD*
[14:55] <ogra> yep, Xorg.0.log says intel
[14:55] <Keybuk>  in fact, why parsing fstab at all and not using getfsent() is *BAD*)
[14:56] <tseliot> ogra: can I see the Xorg.0.log?
[14:57] <ogra> tseliot, http://paste.ubuntu.com/54643/
[14:57]  * ogra has a conf call now ... back soon
[14:58] <jcristau> heh. '(II) NVIDIA GLX Module  173.14.12'
[14:58] <tseliot> ogra: type sudo apt-get remove nvidia-173-kernel-source
[14:59] <tseliot> jcristau: right
[15:00] <superm1> slangasek, oops.  wasn't really estimating how long this whole process would be taking, i'll delete/readd those packages then
[15:00] <ogra> tseliot, oh, where di that come from ?
[15:00] <ogra> i surely didnt instal it manually
[15:01] <slangasek> superm1: ok :)
[15:01]  * ogra purges 
[15:01] <tseliot> ogra: it might be a Recommends of some package you have installed
[15:02] <slangasek> superm1: so will the 4.x stuff magically fix my inability to connect with gnome-phone-manager, or to run btsco, both of which worked in hardy and are basically the only bluetooth things I have that need to work?
[15:03] <ogra> for me only one out of four devices works :(
[15:03] <superm1> slangasek, well what did you use btsco for?
[15:03] <superm1> slangasek, and what did you do with gnome phone manager?
[15:03] <slangasek> superm1: er, I used gnome-phone-manager for connecting to my phone, and now it doesn't work
[15:04] <slangasek> superm1: and I used btsco to get a device that ekiga could talk to, and now btsco doesn't work
[15:04] <slangasek> (with the packages currently in intrepid)
[15:04] <superm1> slangasek, connecting to your phone and sending address books, or which?
[15:04] <superm1> ah
[15:04] <slangasek> gnome-phone-manager> dialing, actually
[15:05] <superm1> oh it provided a handsfree profile?
[15:05] <superm1> that's pretty interesting..
[15:05] <slangasek> I haven't tested the address book syncing yet, I guess I should test that too
[15:05] <slangasek> yes, g-p-m integrates with evolution address book even
[15:05] <azeem> out of curiousity, what is g-p-m using for sync?
[15:05] <Keybuk>             os.rename("/etc/fstab.intrepid","/etc/fstab")
[15:05] <Keybuk> ...
[15:06] <Keybuk> for 10 points, spot the obvious error
[15:06] <tseliot> superm1: did you have a look at my nvidia-xconfig?
[15:06] <superm1> as for the sco stuff, if we end up with the latest pulseaudio it can enumerate bluetooth devices, but i'm not sure we will end up with it
[15:06] <slangasek> but I don't use it all that much, I haven't settled on a workflow that doesn't make me hate computers
[15:06] <Keybuk> err
[15:06] <slangasek> azeem: it doesn't do syncing
[15:06] <Keybuk> the less obvious error than me pasting the wrong line ;)
[15:06] <Keybuk>             open("/etc/fstab.intrepid","w").write("\n".join(lines))
[15:06] <Keybuk> ^ that line
[15:06] <azeem> slangasek: ah, k
[15:06] <superm1> tseliot, i glanced at it but didn't check it yet
[15:07] <tseliot> superm1: ok, no problem
[15:07] <slangasek> Keybuk: missing trailing newline?
[15:07] <liw> Keybuk, you mean the error of overwriting a sysadmin's manually created file?
[15:07] <superm1> slangasek, oh also regarding an earlier ping, i dont think that list is exhaustive of all cards that are transitioned over
[15:07] <Keybuk> liw: "fixing" a file is a perfectly valid upgrade case ;)
[15:07] <liw> (that was the obvious one for me... the newline problem I had to think about)
[15:07] <Keybuk> slangasek: exactly
[15:07] <liw> Keybuk, overwriting /etc/fstab.intrepid is not valid :)
[15:07] <Keybuk> slangasek: where do we file bugs on the magic dist upgrader tarball?
[15:07] <slangasek> Keybuk: against project 'mvo', innit?
[15:08] <slangasek> or update-manager, maybe :)
[15:08] <Keybuk> slangasek: he's on holiday
[15:08] <Hobbsee> slangasek: you can't file bugs against people.  I've long considered this a bug.
[15:08] <ScottK> Hobbsee: They'd need a significantly bigget DB server if that was allowed.
[15:08] <ScottK> bigget/bigger
[15:11] <cjwatson> it's been update-manager in the past, yes
[15:12] <Keybuk> slangasek: bug #279093
[15:13] <pitti> cjwatson: ah, tzdata 2008g-1 just hit incoming; shall I sync that to intrepid?
[15:13] <liw> slangasek, incidentally: unless it's PEBKAC, #278963 may need some bug fixing attention before release
[15:13] <pitti> cjwatson: (that should fix Argentinia, too, I'll double-check that)
[15:13] <cjwatson> pitti: oh, yes please if it fixes the argentina thing
[15:14] <liw> Argentina has messed up their time zone again?
[15:14] <slangasek> superm1: right, upgraded; and bluetooth-applet gives me the option to 'set up a new device', but doesn't show any devices and gives me no option to refresh the list...
[15:14] <pitti> cjwatson: (there first was a 2008f-2 for argentinia, and then 2008g shortly afterwards)
[15:14] <cjwatson> liw: yes, basically the government missed their deadline ...
[15:14] <liw> cjwatson, they should just switch to utc like all sensible people...
[15:14] <superm1> slangasek, the refresh should be constantly happening
[15:15] <superm1> if it's not showing anything for your device, are you sure the device doesn't require a reset quirk (as a lot of bluetooth devices do); did it need to be reset in the past for magic to happen?
[15:15] <slangasek> superm1: ah, I suppose it's not going to show my bluetooth headset because I didn't have it in pairing mode, meh
[15:16] <liw> . o O (BT could have been such a wonderful technology...)
[15:17] <slangasek> superm1: ok, the upgrade and a re-pairing through the wizard lets me get g-p-m connected to my phone; so far that's an improvement
[15:18] <slangasek> but, er, previous versions of g-p-m allowed initiating calls, this one only seems to implement SMS
[15:18] <pitti> cjwatson: confirmed, 2008g fixes it
[15:18] <slangasek> (that, or I'm thinking of one of the 12 other bluetooth things I tested to try to find something that works, but I don't think so)
[15:20] <pitti> cjwatson: synced, intrepid task closed
[15:20] <slangasek> superm1: who do I hurt for these new buttons in GNOME preferences dialogs that consist of icons with no tooltips?
[15:21] <slangasek> like this lovely "i" in a circle, the universal symbol for "information", which I know from previous bluez-gnome versions actually means "trusted device" :P
[15:21] <rom1v> hi
[15:21] <superm1> slangasek, that would be upstream.  slytherin offered to write a patch to put in tooltips though
[15:22] <rom1v> when ubuntu starts, where is the call to "compiz" (to launch compiz)?
[15:22] <slangasek> superm1: who upstream?  I've not noticed GNOME upstream as a whole to be afflicted with this particular brand of insanity in the past
[15:22] <superm1> slangasek, upstream bluez, they're the ones that author this
[15:23] <slangasek> superm1: as in, Marcel?  Hmm, that doesn't explain why things like unlabelled +/- buttons also appear in the keyboard prefs dialog
[15:23] <superm1> slangasek, yeah as in marcel
[15:23] <slangasek> welp, btsco still fails
[15:24]  * liw is hit by boot-time fsck. again.
[15:24] <soren> Keybuk: Interesting. Something completely knackered my /etc/hosts recently as well.
[15:25] <Keybuk> "completely knackered" ?
[15:25]  * liw hopes it wasn't python-fstab
[15:25] <soren> Keybuk: When I opened it today, I found 7-8 identical lines reading: "# Do not remove the folliwing line...blahblahblah... 127.0.0.1 something something" I forget what it read exactly, but something along those lines.
[15:26] <soren> ...and nothing else.
[15:26] <superm1> slangasek, i'm pretty sure upstream is much more preferable to using the native sco support in bluez anyhow.. btsco is a third party universe project isn't it?
[15:26] <Keybuk> soren: mine appears to have
[15:26] <Keybuk> ~30 blank lines added to the end
[15:27] <slangasek> superm1: I know upstream doesn't *want* me to use btsco, but that opinion is worth bupkis when the apps I'm trying to use aren't compatible with bluetooth alsa virtual devices
[15:27] <soren> Keybuk: Very odd. I have 8 blank lines at the end now.
[15:27] <soren> :$
[15:28] <superm1> slangasek, well we'll see if TheMuso ends up setting up  the latest pulseaudio -  which includes bluetooth support.  if nothing else, that part should be better by jaunty..
[15:28] <liw> asac, upgrading to the current version of network-manager did fix my double route problem, thanks
[15:28] <rom1v> could someone help me?
[15:29] <asac> liw: do you use bridging?
[15:29] <liw> asac, yes
[15:29] <asac> ok
[15:29] <slangasek> superm1: well, I should at least do some testing of audio output, here; if I can remember how to configure gstreamer for bluetooth, either...
[15:30] <superm1> i had a changer script for that; it's on another comp though.  mterry might have it handy
[15:31] <pitti> tkamppeter: that means that the pdftoraster workaround in 1.3.8-11ubuntu1 is obsolete now and can be overridden by trunk, right?
[15:32] <ogra> yay, compiz love
[15:33] <tseliot> \o/
[15:33]  * ogra hugs tseliot ... thanks a lot 
[15:34] <tseliot> ogra: you're welcome. Knowing what installed the nvidia driver would be nice too
[15:35] <cjwatson> rom1v: init reads /etc/event.d/rc2 which tells it to run /etc/init.d/rc which calls /etc/rc2.d/S30gdm which starts gdm which reads /etc/gdm/gdm.conf which tells it to run /etc/gdm/Xsession which calls /etc/X11/Xsession.d/50x11-common_determine-startup which reads /usr/share/gnome/autostart/gnome-wm.desktop which tells it to run /usr/bin/gnome-wm which decides which window manager to run, possibly compiz
[15:35] <cjwatson> rom1v: HTH, but next time please don't ask support questions on a developer channel :)
[15:35] <rom1v> great answer ! thank you :)
[15:35] <rom1v> I need that because I think in a future realease, ubuntu should call "nvidia-settings -l" just before launching compiz
[15:35] <ogra> tseliot, well, /var/log/apt/ only has info about the removal, so it must have been theer since a while
[15:36] <Nafallo> cjwatson: wow :-)
[15:36] <rom1v> if graphical card is nvidia
[15:36] <cjwatson> rom1v: similarly, bug reports => bug tracking system
[15:36] <rom1v> (else nvidia settings are not used by compiz)
[15:36] <asac> soren: Keybuk: those empty lines are a bug in NM ... shouldnt happen that frequently anymore after latest upgrade though (except when you change the hostname)
[15:36] <cjwatson> err, I missed out gnome-session running between /etc/X11/Xsession.d/50x11-common_determine-startup and reading /usr/share/gnome/autostart/gnome-wm.desktop, though
[15:36] <rom1v> I already reported that, but I will add this line "nvidia-settings -l" where it should be, then propose a patch
[15:37] <ogra> oh, less isnt autodetecting .gz files anymore ?
[15:37] <Keybuk> asac: ?! why is NM even _writing_ to /etc/hosts?
[15:37]  * ogra was used to that 
[15:37] <tjaalton> are hald/gdm startup priorities going to change for intrepid? there are bugs where people don't have a working keyboard/mouse before restarting X
[15:37] <asac> Keybuk: it doesnt do that anymore ... except when you change the hostname ;)
[15:37] <tseliot> ogra: ok. Let me know if that happens again.
[15:37] <Keybuk> asac: oh, change the hostname in NM?
[15:37] <Keybuk> I noticed something deleted my custom bits from there
[15:37] <ogra> tseliot, will do
[15:37] <Keybuk> and I now appear to have the machine's hostname twice
[15:37] <asac> Keybuk: yeah ... now you can do: echo newname > /etc/hostname ... or send a dbus-send ... to change it through NM
[15:37] <Keybuk> once on 127.0.0.1 where it should be
[15:38] <Keybuk> and another time on 127.0.1.1 ?!
[15:38] <ogra> 127.0.0.1 should only be localhost, no ?
[15:38] <Keybuk> ogra: no?
[15:38] <ogra> while 127.0.1.1 should be the actual hostnale
[15:38] <ogra> *name
[15:38] <Keybuk> that's just bogus
[15:38] <Nafallo> ogra: yes
[15:38] <Keybuk> I got rid of 127.0.1.1
[15:38] <Keybuk> and it's come back
[15:38] <liw> asac, I'm now ready to install nm with my phone and gprs, over a cable (after I have a bite to eat); is it useful to do that before I flash the phone to a current (only two years old) firmware?
[15:38] <liw> asac, or should I flash the phone first?
[15:39] <Keybuk> ogra: why can't 127.0.0.1 be the hostname? :)
[15:39] <asac> liw: what phone is that? we should at least try to do it without firmware upgrade imo
[15:39] <ogra> Keybuk, no idea, i just noticed it is like that when i installed this laptop with hardy
[15:39] <liw> asac, nokia e61; I will flash the phone first then, no worries
[15:40] <asac> liw: why flash first?
[15:40] <Keybuk> 127.0.1.1 isn't even _valid_
[15:40] <ogra> thogh checking now it apparently has changed
[15:40] <ogra> ogra@osiris:~$ cat /etc/hosts
[15:40] <ogra> 127.0.0.1	osiris	localhost.localdomain	localhost
[15:40] <ogra> 127.0.1.1	osiris
[15:40] <liw> asac, er, sorry, I misread
[15:40] <Keybuk> it just happens to work because of a freak of the way that Linux implements the loopback network device
[15:40] <asac> liw: lots of users will most likely not flash their phone ;) ... so lets try unmodified if possible
[15:40] <ogra> i know in hardy there was only "localhost.localdomain localhost" for 127.0.0.1
[15:40] <Keybuk> asac: is NM setting the hostname to be 127.0.0.1 or 127.0.1.1? :?p
[15:40] <cjwatson>    127.0.0.0/8 - This block is assigned for use as the Internet host
[15:40] <cjwatson>    loopback address.
[15:40] <cjwatson> RFC3330
[15:41] <liw> asac, lots of people with that firmware version _will_ flash their phone, since it has bugs that make one assume Nokia has never, ever made a phone before... things like the red phone button not hanging up on a call
[15:41] <ogra> and 127.0.1.1 had the hostname ...
[15:41] <asac> Keybuk: would have to look. maybe both?
[15:41] <Nafallo> exactly. 127.0.0.0/8 is valid.
[15:41] <rom1v> cjwatson: in gnome-wm, don't you think the special case handling for dapper upgrades should be removed?
[15:41] <asac> Keybuk: whats the difference of 127.0.1.1 and 127.0.0.1?
[15:41] <cjwatson> rom1v: not my code
[15:41] <Keybuk> cjwatson: that's quite new? RFC1700 only ever allowed 127.0.0.1/32 ?
[15:41] <cjwatson> rom1v: file a bug if you want it changed
[15:41] <rom1v> yes, I imagine :)
[15:41] <asac> why would anyone not want either?
[15:41] <liw> asac, so yeah, I'll try first without flashing, I'll report any problems/patches later
[15:41] <rom1v> ok, I will (not for that problem, but for nvidia problem)
[15:41] <ogra> Keybuk, i think windows did it since ages like that
[15:42] <ogra> cant be *that* new
[15:42] <asac> liw: right. first step: 1. does NM detect your phone. if not -> patch hal-info  :)
[15:42] <asac> then it becomes interesting i guess
[15:42] <cjwatson> Keybuk: RFC1700 says:
[15:42] <cjwatson>       (g)   {127, <any>}
[15:42] <cjwatson>          Internal host loopback address.  Should never appear outside
[15:42] <cjwatson>          a host.
[15:42] <Keybuk> cjwatson: why do Debian set the hostname to a different IP though?
[15:42] <cjwatson> Keybuk: Debian bug 316099
[15:43] <cjwatson> it's to work around other problems
[15:43] <Keybuk> so the reverse of the hostname is the hostname?
[15:43] <Nafallo> Keybuk: Sept. 2002 by the looks of it.
[15:43] <cjwatson> http://lists.debian.org/debian-boot/2005/06/msg00639.html is the root of the thread
[15:44] <Keybuk> the thread doesn't really specify any problems though
[15:44] <cjwatson> there is something wrong with the setup, but I don't think just reverting that netcfg change is the right answer; we'll just get a different set of problems
[15:45] <Keybuk> the thread starts with a "should always" assertion
[15:45] <cjwatson> I'm afraid I don't have the references to hand, but I remember that thread coming after an enormous series of problems due to hostname reversal problems
[15:45] <Keybuk> but that seems to be the only thing made true by the way it's set up
[15:45] <cjwatson> the netcfg change replaced those problems with a smaller set of problems
[15:46] <Keybuk> well, normally you'd have
[15:46] <Keybuk> IP  FQDN  HOSTNAME
[15:46] <Keybuk> so a lookup of "IP" or "HOSTNAME" replies "FQDN"
[15:46] <Keybuk> e.g.
[15:46] <Keybuk> 87.194.19.205  quest.netsplit.com quest
[15:47] <Keybuk> but if doing DHCP, there's an adversion to putting the hostname in that file
[15:47] <Keybuk> since the IP could be anything
[15:47] <cjwatson> the desired properties were (a) reverse(127.0.0.1) == localhost (b) reverse(forward(system hostname)) == system hostname
[15:47] <Keybuk> in theory, you should never have the hostname in that file ;)
[15:47] <cjwatson> that makes forward(system hostname) == 127.0.0.1 impossible
[15:47] <Keybuk> but I guess there are(were?) things that relied on it being there?
[15:47] <cjwatson> yes
[15:48] <cjwatson> still are; I believe sudo is one
[15:48] <rom1v> cjwatson: https://bugs.launchpad.net/ubuntu/+bug/215876 (my last comment)
[15:48] <StevenK> sudo only warns now, I think
[15:48] <Keybuk> I can't think of any problem that would actually caused by the lookup look resolving to localhost or 127.0.0.1
[15:48] <Keybuk> other than someone's aesthetics being offended
[15:48] <cjwatson> rom1v: I would appreciate no longer being part of this conversation; it is not my area
[15:48] <rom1v> ok, sorry
[15:49] <cjwatson> Keybuk: so what is the problem it's causing now?
[15:49] <cjwatson> other than your aesthetics, that is :)
[15:49] <Keybuk> cjwatson: well, now, something is sticking it back in my hosts file
[15:49] <ogra> heh
[15:49] <Keybuk> which means it's got two different IPs
[15:49] <Keybuk> and now local traffic is actually going to 127.0.0.1 not the real IP
[15:49] <Keybuk> which broke my apache virtual setup :p
[15:49] <cjwatson> ok, that's entirely separate from the installer doing it to start with
[15:49] <Keybuk> yeah, I'm only wondering why it got added twice
[15:49] <cjwatson> maybe update-manager is being overenthusiastic or something
[15:49] <Keybuk> cjwatson: NM apparently?
[15:50] <Keybuk> I can't find it in update-manager
[15:50] <ogra> likely nm
[15:50] <Keybuk> I didn't have it in /etc/hosts at all
[15:50] <ogra> with its new setting of hostnames philosophy
[15:50] <Keybuk> now it's come back twice
[15:51] <Keybuk> (and annoyingly removed my own custom entries)
[15:54] <ogra> Keybuk, yep, its definately NM, booting without usplash even tells you it sets the hostname
[15:54] <ogra> and it just mangled my 127.0.0.1 line in /etc/hosts
[15:55] <ogra> adding the hostname on front of "localhost.localdomain   localhost"
[15:55] <ogra> instead of just setting 127.0.1.1 only
[15:55] <asac> ogra: have you tried the latest NM?
[15:55] <ogra> the one that hasnt built yet ?
[15:55] <ogra> no
[15:55] <asac> ogra: it has ;)
[15:56] <ogra> i upgraded 1h ago
[15:57] <ogra> ah, there it is
[15:57]  * ogra installs
[15:57] <asac> ogra: be sure you restarted NM and killall nm-system-settings
[15:58] <ogra> i'll reboot after changing the 127.0.0.1 line in /etc/hosts
[16:01] <ogra> asac, erm
[16:01] <ogra> ogra@osiris:~$ wc -l /etc/hosts
[16:01] <ogra> 42 /etc/hosts
[16:02] <ogra> it changed the 127.0.0.1 line again *and* added 31 newlines to the end of the file
[16:02] <asac> ogra: was it 41 before you rebooted? or 31?
[16:02] <ogra> it was 11 lines
[16:03] <asac> ogra: ok
[16:03] <asac> so 127.0.1.1 is what debian uses as loopback address?
[16:03] <ogra> and only one empty one in the middle
[16:03] <ogra> (between ipv4 and v6 settings)
[16:03] <ogra> the 31 empty ones got appemded apparently
[16:03] <ogra> *appended
[16:04] <asac> ogra: are you 100% sure that those got appended in this reboot?
[16:04] <ogra> pretty, yes, my vim had a tilde after the last line while editing
[16:04] <asac> ogra: ok. so you did what? remove 127.0.0.1 line from hosts?
[16:04] <ogra> no
[16:04] <ivoks> ogra: you are lucky... my /etc/hosts has 310 lines; most of them empty :)
[16:05] <ogra> i changed:
[16:05] <ogra> 127.0.0.1   osiris  localhost.localdomain   localhost
[16:05] <ara> if any one is interested in testing infrastructure, cr3 is giving now a session at #ubuntu-classroom
[16:05] <ogra> to:
[16:05] <ogra> 127.0.0.1   localhost.localdomain   localhost
[16:05] <ogra> then rebooted
[16:05] <asac> ok let me try
[16:05] <ogra> and have: 127.0.0.1   osiris  localhost.localdomain   localhost
[16:05] <ogra> plus the empty lines
[16:06] <ivoks> asac ogra i can confirm this; same thing happens to me
[16:06] <davmor2> ﻿if any one is interested in testing infrastructure, cr3 is giving now a session at #ubuntu-classroom
[16:07] <kirkland> Riddell: hi, are you around?  Can I get you to promote musica to the universe archive?  It's in the queue.
[16:07] <asac> ogra: is ifupdown enabled in /etc/NetworkManager/nm-system-settings.conf ?
[16:07] <ogra> [main]
[16:07] <ogra> plugins=ifupdown,keyfile
[16:07] <ogra> [ifupdown]
[16:07] <ogra> managed=false
[16:07] <ogra> never touched it
[16:07] <asac> yeah
[16:07] <asac> thats fine
[16:08] <Ng> hmm, is showing avahi network printers still off by default in intrepid?
[16:08] <asac> i cannot reproduce by restarting NM and nm-system-settings
[16:08] <asac> i will look in code now
[16:08] <Riddell> kirkland: let me look
[16:08] <Ng> where by "avahi" I probably don't mean avahi, I mean whatever broadcasting cups does
[16:08] <asac> ogra: is your /etc/hostname updated through some other mean during startup?
[16:08] <kirkland> Riddell: thanks!
[16:08] <ogra> i didnt manually restart them, but rebooted, probably it behaves differently in that case
[16:08] <ogra> asac, not on purpose at least
[16:08] <kirkland> Riddell: slangasek asked me to ask someone else; he was swamped ;-)
[16:09] <kirkland> Riddell: and you helped me with update-motd last time
[16:09] <soren> Keybuk: I haven't followed the discussion (kind of in the middle of something here).. Is the mountnfs thing sorted, or do I still need to look into it?
[16:09] <Riddell> siretart: ffmpeg in queue?
[16:09] <Keybuk> soren: I've blamed dist-upgrader
[16:10] <Keybuk> soren: the shell code in mountnfs is buggy in so many ways
[16:10] <Keybuk> so there's no point even trying to mitigate the problem there
[16:10] <asac> ogra: yeah. only reason i could see that it behaves differently is when hostname isnt set at all at the time NM starts
[16:10] <kirkland> soren: Keybuk: nfs mounts not happening on boot?
[16:10] <asac> ogra: but i am looking at code now
[16:10] <ogra> asac, well, /etc/init.d/hostname.sh sets it
[16:10] <Keybuk> kirkland: yes
[16:10] <kirkland> soren: Keybuk: i saw this just last night on my mythfrontend upgrade from hardy to intrepid
[16:10] <asac> ogra: can you please paste your /etc/hosts?
[16:10] <ogra> though it doesnt change the file, but calls hostname
[16:10] <soren> Keybuk: Ok.
[16:10] <Keybuk> ogra: that only writes to /proc/hostname
[16:10] <Keybuk> kirkland: can you ssh to it?
[16:10] <ogra> Keybuk, yeah
[16:11] <kirkland> Keybuk: yes
[16:11] <asac> most likely calls hostname based on what currently is in /etc/hostname ?
[16:11] <Keybuk> kirkland: do you have a final newline in /etc/fstab ?
[16:11] <ogra> asac, http://paste.ubuntu.com/54665/
[16:12] <Keybuk> asac: needlessly more complicated than that, but yes
[16:12] <ogra> pastebin cuts off the empty lines
[16:12] <siretart> Riddell: yes
[16:12] <kirkland> Keybuk: i did, but I deleted it
[16:12] <siretart> Riddell: it is targeted for multiverse
[16:12] <Keybuk> kirkland: you deleted it?!
[16:12] <Keybuk> kirkland: the newline or fstab? :p
[16:12] <Riddell> siretart: don't we already have an ffmpeg?
[16:12] <siretart> Riddell: 'ffmpeg-debian' should stay in main, however
[16:12] <kirkland> Keybuk: the trailing newline :-)
[16:13] <Keybuk> why did you delete it?
[16:13] <siretart> Riddell: 'ffmpeg' contains 'replacements' libraries with the excluded encoders in, plus linking to some other stuff in multiverse
[16:13] <Keybuk> anyway, that file won't work if it doesn't have a trailing newline :)
[16:13] <kirkland> Keybuk: because i have a vimrc that highlights in bright red trailing whitespace of any kind and i tend to prune things like that
[16:13] <asac> ogra: ok. so the problem comes up  when you remove the "osiris" from the first line?
[16:13] <siretart> Riddell: that's basically the implementation of the plan I crafted some months ago
[16:13] <ogra> asac, right, it gets re-added
[16:15] <soren> kirkland: When you say it had a trailing newline, do you mean that you had an empty line at the end?
[16:15] <siretart> Riddell: are you currently processing it?
[16:16]  * soren is not even sure how he'd get vim to save a file without a trailing newline..
[16:16] <cjwatson> :set binary noeol
[16:16] <soren> cjwatson: That's handy. Thank you.
[16:16] <rom1v> cjwatson: thank you very much for your help, I know it's not your piece of code, but the information you gave me allowed me to fix the problem :)
[16:16] <cjwatson> I've never heard of vim highlighting a trailing newline though
[16:16] <cjwatson> rom1v: no problem
[16:17] <cjwatson> because, err, it isn't really trailing whitespace on a line :)
[16:17] <rom1v> but I imagine, no chance that the fix will be included in intrepid?
[16:17] <Keybuk> indeed, vim tends to vaguely mention if you *don't* have a trailing newline
[16:18] <Keybuk> [noeol] in the buffer
[16:18] <Riddell> kirkland: the licencing is incomplete.  there's no GPL included.  index.php suggests its GPL 3 and CC2.5 but debian/copyright says GPL2+ with no mention of CC2.5
[16:18] <asac> so the debian way of doing things is to have the hostname mapped to 127.0.1.1 ?
[16:18] <Keybuk> and when you save it, puts one in anyway :p
[16:18] <kirkland> Riddell: ah, right, icons are CC2.5
[16:18] <asac> and 127.0.0.1 only mapping to localhost and localhost.localdomain?
[16:18] <Keybuk> asac: no localhost.localdomain iirc
[16:18] <Keybuk> 127.0.0.1 localhost
[16:18] <Keybuk> 127.0.1.1 hostname
[16:18] <Keybuk> BUT ONLY if 127.0.1.1 exists
[16:18] <kirkland> Riddell: i'm not sure how that happen, i'll clean it up immediately.
[16:18] <Keybuk> if 127.0.1.1 does not exist, do not add it
[16:18] <soren> Keybuk: It does indeed. Quite annoying if you've been editing binary files (%!xxd + %!xxd -r style).
[16:19]  * ogra had localhost.localdomain in a fresh hardy install
[16:19] <asac> Keybuk: ok.
[16:19] <Riddell> kirkland: rejecting.  please [have upstream] add full licence texts to the upstream tar, and ensure debian/copyright matches
[16:19] <asac> i remember that debian systems had localhost.localdomain as well
[16:19] <kirkland> Riddell: thanks.
[16:19] <Keybuk> ogra: my hardy and intrepid installs don't have it - my pre-hardy does; so I assumed that it's gone
[16:19] <Keybuk> I vaguely remember someone saying that it was invalid
[16:19] <Keybuk> cjwatson: ?
[16:20] <asac> yeah. i remember a bug about that. but i think it was a reverse lookup order thing
[16:24] <Riddell> pitti: any sign of a new langpack upload?
[16:24] <pitti> ArneGoetje: ^ we do have a newer base export and a delta tarball; can you please prepare an upload?
[16:25] <cjwatson> Keybuk: I don't think it's changed recently
[16:25] <cjwatson> Keybuk: what was your pre-hardy install originally?
[16:26] <Keybuk> cjwatson: err, warty I think :p
[16:26] <ogra> heh
[16:26] <Keybuk> that one _has_ localhost.localdomain
[16:26] <cjwatson> Keybuk: right, I think it went away in dapper
[16:26] <Keybuk> I knew it had gone away at some point ;)
[16:26] <cjwatson> Thomas Hood's change was Nov 2005
[16:26] <cjwatson> (and there are dapper changes just above it in the changelog)
[16:28] <cjwatson> asac: ubiquity/scripts/install.py line 1479+ has current rules
[16:28] <Keybuk> why is NM doing this anyway?
[16:28] <cjwatson> asac: or netcfg/netcfg-common.c:netcfg_write_common
[16:29] <Keybuk> this is a bit "aha! I see you changed a file! I shall go do more stuff that you were about do do anyway, so when you edit the file, you'll be slightly puzzled"
[16:29] <cjwatson> (the former is a transcription of the latter really)
[16:29]  * ogra confirms in a freshly installed hardy vm there is only localhost, no trace of localdomain
[16:30] <asac> ok
[16:30] <Keybuk> there is no localdomain, only zul
[16:30] <ogra> i think fedora uses localhost.localdomain still
[16:30] <asac> and suse as well
[16:30]  * ogra guesses it comes from there
[16:31] <Keybuk> asac: so what, exactly, is NM doing?
[16:31] <Keybuk> it's watching you edit /etc/hostname (or setting /proc/hostname ?) and editing /etc/hosts to match?
[16:31] <asac> Keybuk: do you want the code?
[16:31] <ogra> intrestingly my hardy /etc/hosts has: "127.0.1.1 ubuntu.local ubuntu"
[16:31] <Keybuk> ogra: that's wrong on so many levels
[16:31] <Keybuk> ogra: having .local in there may actually break things :p
[16:31] <ogra> smells like avahi addition
[16:31] <ogra> Keybuk, its a fresh install
[16:32] <Keybuk> oh dear :)
[16:32] <ogra> my hardy reference VM
[16:32] <asac> Keybuk: it watches /etc/hostname and changes done there are propagated to /etc/hosts ... yes.
[16:32] <Keybuk> asac: "why" ?
[16:32] <asac> Keybuk: all this landed to support dynamic updated hostnames
[16:32] <ogra> Keybuk, so you can change the hostname from NM
[16:32] <asac> e.g. from dhcp and ppp and so on
[16:32] <ogra> on the fly
[16:33] <Keybuk> ogra: no, if it was doing that, it wouldn't _need_ to watch /etc/hostname ;)
[16:33] <ogra> which gets funnny if done from a running X session
[16:33] <Keybuk> asac: but doesn't changing the hostname underneath running things break them?
[16:33] <Keybuk> sudo springs to mind
[16:34] <asac> Keybuk: it breaks Xauth ... but thts a bug in how we start local x sessions
[16:34] <cjwatson> ogra: the only way the installer could do that is if you (or something) told it your domain was "local"
[16:34] <Keybuk> here's a better question
[16:34] <Keybuk> it watches /etc/hostname ...
[16:34] <ogra> cjwatson, i didnt
[16:34] <Keybuk> does it actually look to see if you *set* that as the hostname? :p
[16:34] <cjwatson> "or something"
[16:34] <asac> Keybuk: at best join #nm ;)
[16:34] <ogra> its a plain alternate install
[16:34] <asac> thats the best place to get input from the master ;)
[16:35] <Keybuk> asac: I just don't see what it's fixing here
[16:35] <Keybuk> while seeing a lot of breaking
[16:35] <asac> Keybuk: there might be glitches here and there. especially since debian does it different
[16:36] <Keybuk> if you get a DHCP response with a hostname, why would you edit /etc/hostname?
[16:36] <Keybuk> you'd just set /proc/hostname directly
[16:36] <asac> Keybuk: assume hosts is properly rewritten and xauth is fixed. what other breakage is left?
[16:36] <Keybuk> and since you're on an active network, there's no need to put that in /etc/hosts
[16:36] <asac> Keybuk: no
[16:36] <Keybuk> why no?
[16:36] <asac> Keybuk: we dont edit /etc/hostname
[16:36] <soren> Why is it that we want the hostname to change based on dhcp, by the way?
[16:36] <asac> when you get dhcp response
[16:36] <cjwatson> ogra: I'm just describing the behaviour of netcfg. I'm not saying you're not seeing what you're seeing, but I don't see anything in the installer that could possibly do that so I'm suggesting that perhaps the cause is something else
[16:36] <Keybuk> asac: exactly
[16:36] <Keybuk> so what is NM watching again? :P
[16:37] <Keybuk> you said NM was watching for /etc/hostname changes ...
[16:37] <Keybuk> but we *don't* edit /etc/hostname
[16:37] <asac> Keybuk: NM edits /etc/hostname for instance ... or you do that in vi
[16:37] <ogra> cjwatson, yeah, i didnt mean to argue with you about that :)
[16:37] <Keybuk> but why would NM edit /etc/hostname?
[16:37] <Keybuk> that's just wrong
[16:38] <Keybuk> tbh, it's not entirely clear to me why you even need to change the system hostname
[16:38] <Keybuk> but I can appreciate that it would be nice in some situations
[16:38] <asac> Keybuk: so: NM applet gets a widget "hostname" where you can change your hostname
[16:38] <Keybuk> at most, dynamic hostname is a change to the *current* hostname
[16:38] <Keybuk> (ie. set /proc/hostname)
[16:38] <asac> Keybuk: that gets sent to NM daemon, which propagates that request to the system integration plugin ... which then updates hostname
[16:38] <soren> I don't even want it to do that.
[16:38] <Keybuk> you don't need to put that in /etc/hostname, since you can guarantee it's not permanent
[16:38] <Keybuk> and you don't need to put that in /etc/hosts either
[16:39] <Keybuk> asac: sure, that makes sense as a method
[16:39] <Keybuk> but you said it was watching the system and doing this itself automatically as well?
[16:39] <soren> I dont' see the point, really. It messes up samba url's, .local hostnames, etc., etc.
[16:39] <asac> Keybuk: right. so. given that nothing touches /etc/hostname exept NM through that dbus method or you through "vi", i dont see that the "watching" is a issue on its own
[16:39] <Keybuk> asac: but other things will touch /etc/hostname
[16:40] <Keybuk> like the sysadmin
[16:40] <Keybuk> and NM should not be going and mucking around on its own
[16:40] <asac> Keybuk: what you complain about is that the hosts rewrite is buggy atm ;)
[16:40] <Keybuk> hell, I can touch /etc/hostname by using bzr :)
[16:40] <Keybuk> no, I'm complaining that it does it at all
[16:40] <Keybuk> if *I* change /etc/hostname, *I* will change /etc/hosts
[16:40] <Keybuk> I don't need NM being smart
[16:40] <cjwatson> I agree that a sysadmin intentionally editing /etc/hostname and /etc/hosts in sequence is going to get desperately confused by something doing the latter for him
[16:40] <Keybuk> especially since it could break things in the process
[16:40] <cjwatson> we definitely shouldn't be applying inotify watches to files in /etc like this
[16:40] <Keybuk> cjwatson: not to mention the sysadmin is likely racing NM
[16:40] <cjwatson> yes
[16:41] <cjwatson> it doesn't matter how correct the file rewrite is
[16:41] <Keybuk> it's valid for NM to apply a change to /etc/hostname and /etc/hosts because it was *told* to by method call
[16:41] <Keybuk> I cannot understand a scenario where NM would be told to do this by anything other than a "Change Hostname" button
[16:41] <Keybuk> and I cannot understand any scenario where NM would apply the change automatically because of something else it saw happen
[16:42] <asac> Keybuk: so why do you touch /etc/hostname using bzr? without wanting your hostname to be like that?
[16:42] <Keybuk> asac: I frequently fiddle in /etc yes
[16:42] <Keybuk> and even better
[16:42] <Keybuk> I often deliberately change a hostname
[16:42] <asac> Keybuk: but if you change /etc/hostname you probably want your hostname to be like that
[16:42] <Keybuk> and *DO NOT WANT IT APPLIED UNTIL THE NEXT REBOOT THANKS*
[16:43] <Keybuk> asac: and I know to edit /etc/hosts as well
[16:43] <Keybuk> because I'm clearly clever enough to know about /etc
[16:43] <cjwatson> asac: turn it around: what justification does network-manager have for this surprising behaviour?
[16:43] <cjwatson> network-manager is the thing that's changing here, and therefore it has the burden of proof
[16:45] <cjwatson> it sounds like a "because it can" justification, and really, it's not useful to the sorts of people it's trying to "help"
[16:45] <asac> the idea is to keep /etc/hostname in sync. i have no strong opinion on whether it should automatically apply the changes or not.
[16:45] <Nafallo> the hostname are set during install. stop messing with it. kthxbai.
[16:46] <Keybuk> this is also a good example of "it's best to get bogus behaviour right on the first try, otherwise people notice it" :-)
[16:46] <ogra> not true
[16:46] <asac> Nafallo: this is about something else. not about messing with hostname ;)
[16:46] <ogra> yu can set hostnames by dhcp :P
[16:46] <Keybuk> ogra: but you would never apply that to the disk
[16:46] <Keybuk> the whole point of a DHCP hostname is that it's _dynamic_
[16:46] <ogra> nah, to /proc
[16:46] <Keybuk> you don't need it to hit the disk
[16:46] <Keybuk> just set /proc/hostname and carry on
[16:46] <Keybuk> it doesn't even need to be /etc/hosts - because the best bit is that it's only active all the time you're on that network anyway
[16:47] <asac> Keybuk: again, dhcp hostname will not write to /etc/hostname :)
[16:47] <stgraber> but it'll updated /etc/hosts right ?
[16:48] <cjwatson> asac: that's what Keybuk is saying too
[16:49] <asac> yeah, wasnt 100% sure if he said "DHCP doesnt need to do that - but NM is wrong" or "NM doesnt do that right now" :)
[16:49] <Keybuk> you were justifying NM's strange behaviour as being for dynamic hostnames
 Keybuk: all this landed to support dynamic updated hostnames
[16:49] <asac> Keybuk: yeah. that was the root cause why hostname support landed ;)
[16:49] <Keybuk> and I was illustrating that none of this is necessary for that
[16:50] <Keybuk> so all of this complex and error-prone editing of files is entirely unecessary
[16:50] <Keybuk> and indeed potentially really quite dangerous
[16:50] <Keybuk> consider a sysadmin doing a "bzr update" of their /etc
[16:50] <Keybuk> bzr applies a diff to /etc/hostname
[16:50] <Keybuk> and then to /etc/hosts
[16:50] <Keybuk> MEANWHILE NM starts dicking around with it
[16:50] <asac> Keybuk: yeah. NM approach is that you always get dynamic behaviour unless your system integration plugin says something different ;)
[16:51] <asac> Keybuk: thats why the ifupdown plugin provides a hostname (fixed hostname)
[16:51] <Keybuk> all that's going to happen is pain and misery
[16:51] <Keybuk> asac: ???
[16:51] <asac> Keybuk: also ifupdown provides write support so you can set your hostname through UI or dbus
[16:51] <Keybuk> asac: I have no problem with that code
[16:51] <Keybuk> asac: *what* is watching /etc/hostname for changes?
[16:51] <asac> Keybuk: the inotify thing was a request by upstream. i dont mind to make it a configure option
[16:52] <asac> configure - runtime config option
[16:52] <Keybuk> if we can turn that off, I would feel much happier
[16:52] <Keybuk> I don't think we want that on
[16:52] <asac> Keybuk: thats not a problem at all. and i never said that your request is unreasonable. i just wanted to understand why users dont want the hostname to be updated if /etc/hostname changes
[16:53] <asac> and if users dont want that if its really something that mainstream users dont want :/
[16:54] <cjwatson> the hypothetical mainstream user won't care either way - if we're doing our job right they'll never hit this case
[16:54] <Keybuk> asac: I think that the kind of user who is updating /etc/hostname knows about /etc/hosts
[16:54] <cjwatson> the only users that care are non-mainstream
[16:54] <asac> Keybuk: only reason i currently see for keeping inotify thing on is when some third party tool updates /etc/hostname and runs sethostname on its own while NM is running, that NM internal state about hostname might gets out of sync and _might_ (not sure) cause wierd behaviour.
[16:54] <Keybuk> asac: the users that don't just want a button that says "Change Hostname"
[16:55] <Keybuk> asac: it can update NM's state - that's fine -- it shouldn't go and rewrite /etc/hosts though (!!)
[16:55] <Keybuk> because the third party tool could be *also* doing that
[16:55] <Keybuk> hell, if they're on XFS, they could end up with null bytes where their /etc/hosts used to be <g>
[16:55] <asac> Keybuk: ok. but then it becomes difficult. for dhcp/dynamic host updates NM probably has to update /etc/hosts
[16:55] <Keybuk> asac: no it doesn't
[16:55] <Keybuk> think about it
[16:55] <Keybuk> it doesn't need to *touch* /etc/hostname *or* /etc/hosts
[16:56] <Keybuk> they can stay as they were
[16:56] <Keybuk> if it's a dhcp/dynamic hostname, it's only valid as long as the dhcp lease
[16:56] <Keybuk> thus only ever needs to be set as the system hostname
[16:57] <Keybuk> when the dhcp lease expires, you simply set the hostname back to whatever is in /etc/hostname
[16:57] <Keybuk> and because that hostname is only valid all the time there's a network connection
[16:57] <Keybuk> it _does_not_ need to be in /etc/hosts
[16:57] <asac> Keybuk: and how does the reveser lookup work when dhcp lease is active?
[16:57] <Keybuk> the hostname is only in /etc/hosts so you can lookup the hostname while there's no network connection
[16:57] <Keybuk> asac: using this wonderful invention called "DNS"
[16:57] <asac> ok.
[16:58] <Keybuk> iirc. dynamic hostname over DHCP actually involves a DNS lookup anyway, so you know that works
[16:58] <Keybuk> in fact, in most situations with dynamic hostname - the daemon doing dhcp also happens to be doing dns :)
[16:58] <Keybuk> (dnsmasq or something)
[16:59] <Keybuk> example
[16:59] <Keybuk> your behaviour
[16:59] <Keybuk> I have a hostname "laptop"
[16:59] <liw> is /proc/hostname really /proc/hostname or /proc/sys/kernel/hostname?
[16:59] <Keybuk> I boot up, my machine is called "laptop"
[16:59] <Keybuk> liw: the latter, I was shortening
[16:59] <Keybuk> I log onto a network
[17:00] <Keybuk> I'm given the hostname guest-2341
[17:00] <Keybuk> that's ok, I guess
[17:00] <Keybuk> my laptop battery runs out
[17:00] <liw> (fwiw, I fully agree with Keybuk about /etc/hosts and /etc/hostname handling: NM has no business touching them)
[17:00] <asac> Keybuk: right. all agreed. so only thing that might be confusing (though definitly a corner case) is when some external tool updates /etc/hostname, and user/admin wants to change hostname in nm-applet and doesnt see the actual hostname ;)
[17:00] <Keybuk> when I boot again, my machine is now called guest-2341 and hardcoded as such everywhere (!!)
[17:00] <asac> but that is neglectable i think ;)
[17:00] <Keybuk> my way:
[17:00] <Keybuk> my machine is called "laptop"
[17:00] <asac> (or fixable through some other mechanism)
[17:00] <Keybuk> I log onto a network, and am given guest-2341
[17:00]  * liw also doesn't want his hostname to change, ever, and will be cross at anything that changes it, thank you very much
[17:00] <Keybuk> but this time, since neither /etc/hostname or /etc/hosts was touched - it's just changed online
[17:01] <Keybuk> if I run out of power, and boot again
[17:01] <Keybuk> my machine is _still_ called "laptop"
[17:01] <Keybuk> asac: like I said, it's ok if NM updates its own internal data
[17:01] <Keybuk> but arguably if it's showing the current hostname by reading /etc/hostname, it's broken anyway
[17:01] <Keybuk> it should be just calling gethostname() :P
[17:02] <asac> Keybuk: well. the current way would work too ... e.g. dhcp will only update /etc/hosts, but when you bootup /etc/hostname gives you "laptop" again so /etc/hosts is rewritten to "laptop" :)
[17:02] <asac> but i dont want to argue that
[17:02] <asac> i am not really a friend of inotify to update system configs on the fly
[17:02] <asac> its what upstream doesn and i implemented it that way. i can make that an option for sure
[17:02] <jcristau> /etc/hosts shouldn't be rewritten at all...
[17:03] <liw> asac, please do disable any editing of /etc/hosts by default, thanks :) I'll buy you a beer :)
[17:03] <asac> jcristau: i will carry that to NM maintainer. its always hard to stand in for something that isnt my idea ;)
[17:03] <asac> at best join #nm which even allows flames according to /topic :)
[17:03] <stgraber> hmm, let's just keep the good old (and well working) behavior at least for Intrepid, right ? :)
[17:05] <liw> asac, and I appreciate your being in between two difficult parties, your colleagues on the one hand and NM upstream on the other
[17:11] <TuniX12> who is responsible for artwork in ubuntu?
[17:11] <Pici> The artwork team.
[17:11] <Keybuk> TuniX12: please ask questions in #ubuntu-art
[17:11] <Pici> #ubuntu-art
[17:12] <TuniX12> the new theme and specially wallpapers are realyy horrible and unprofessional
[17:12] <Keybuk> TuniX12: so is your spelling, and your asking of the question in this channel even when you've been asked not to
[17:14] <TuniX12> keybuk: sorry english is not my native language can you speak french you i dont think so!
[17:14] <Keybuk> oui ;)
[17:14] <TuniX12> oO
[17:14] <cody-somerville> Qui ne peut pas parler ces jours au français ?
[17:15] <Keybuk> maintenant, posez votre question dans #ubuntu-art s'il vous plait
[17:19] <Keybuk> kwwii: clearly, a fan
[17:19] <ogra> Keybuk, hey, this is an english speaking channel :)
[17:21] <mathiaz> mdz_: how long does the TB meeting last usually? 1 hour or 2 hours?
[17:21] <ogra> tjaalton, i got contacted by a guy working on touchscreen support upstream at freedesktop, apparently he is trying to unify all tablet and touchscreen drivers into evdev
[17:22] <ogra> tjaalton, he is willing to work closely with us in jaunty
[17:23] <mathiaz> mdz_: because tomorrow's TB meeting is scheduled from 14:00 to 16:00 UTC (on the fridge) and the Server Team meeting is scheduled to start at 15:00 UTC.
[17:23] <mathiaz> mdz_: So I'd like to know if the Server Team should start one hour later (16:00 UTC)
[17:24] <slangasek> superm1: well, from what I've been able to track down, there's a regression in bluetooth audio support in 2.6.27... alsa fails with "BT_SETCONFIGURATION failed : Input/output error(5)"
[17:25] <cjwatson> seb128: any objection to me just reverting the problematic change in intltool (bug 275795)? there's been no response from upstream yet ...
[17:25] <superm1> slangasek, so nothing to do with bluez 4.x however
[17:25] <superm1> slangasek, perhaps within the transition from hci_usb to btusb in 2.6.27
[17:25] <slangasek> superm1: right, it just means that I can't test it either way
[17:25] <slangasek> without doing kernel archaeology
[17:26] <superm1> was that 2.6.27rc8 or rc7?
[17:26] <superm1> i know btusb had some delta to rc8
[17:26] <slangasek> it was 2.6.27-4-generic :-P
[17:26] <superm1> okay so that's rc7
[17:26] <seb128> cjwatson: did it break any other build? did you workaround that in ubiquity? I would prefer waiting for upstream comment if there is nothing which push us to revert the change
[17:26] <slangasek> superm1: ok, I can try later with 2.6.27-5-generic then
[17:28] <cjwatson> seb128: I worked around it by reverting the change on my laptop, but that's no good as soon as somebody else needs to regenerate ubiquity's autotools
[17:28] <cjwatson> seb128: at least oem-config would suffer the same problem; I don't maintain enough other intltoolish stuff to know
[17:28] <seb128> cjwatson: I pinged upstream on IRC about the bug, what about reverting tomorrow if he doesn't reply?
[17:28] <cjwatson> seb128: sure, that would be fine
[17:28] <seb128> ok, let's do that then
[17:29] <cjwatson> thanks
[17:29] <seb128> cjwatson: <dobey> seb128: i'll fix it and make a release today.
[17:30] <cjwatson> seb128: hooray
[17:31] <cjwatson> found a new code drop of the totem BBC plugin in my spam-bin :-( so I'll be uploading that shortly once I've tested it a bit
[17:32] <liw> asac, regarding my phone: I connect USB cable, tell phone to use USB for "IP through traffic" ("IP läpivienti" in Finnish, I don't know what the phone says in English), NM notices it, starts doing dhcp on it, but never gets a response
[17:32] <liw> asac, so now I don't know what to do next :)
[17:36] <cjwatson> gar, running autoconf in totem produces a 30000+-line diff to 70_autotools.patch. (Running autoreconf is more like 70000+ lines.) What on earth were people using to autoconfiscate this?
[17:37] <Keybuk> if you look at the original files, you should be able to tell
[17:38] <cjwatson> it seems to be more reordering than actual changes
[17:38] <Keybuk> I was more thinking of the great big version stamp ;)
[17:38] <Keybuk> which would /directly/ answer your question, if perhaps not /helpfully/
[17:38] <asac> liw: ok. did you use the wizard to configure your connection?
[17:38] <cjwatson> seb128: is there a standard tool that people use to update autotools patches in desktop packages? the intuitive (to me) autoreconf -fi; quilt refresh produces lots of diffs that indicate people weren't using quilt to do it
[17:38] <liw> asac, nope, it started doing dhcp on its own
[17:38] <Keybuk> cjwatson: don't use -f ...
[17:39] <cjwatson> Keybuk: ok, but irrelevant to my question
[17:39] <Keybuk> but </broken record that people are long since past ignoring>
[17:39] <cjwatson> -diff -Nurb totem-2.24.1/bindings/Makefile.in totem-2.24.1.new/bindings/Makefile.in
[17:39] <cjwatson> ---- totem-2.24.1/bindings/Makefile.in  2008-10-01 16:00:53.000000000 +0200
[17:39] <cjwatson> -+++ totem-2.24.1.new/bindings/Makefile.in      2008-10-02 00:16:29.000000000 +0200
[17:39] <cjwatson> +Index: bindings/Makefile.in
[17:39] <cjwatson> +[17:39] <cjwatson> +--- bindings/Makefile.in.orig
[17:39] <seb128> cjwatson: the totem autotools patch is only a configure update, usually we only run autoconf for those and aclocal too when required
[17:39] <cjwatson> ++++ bindings/Makefile.in
[17:39] <cjwatson> I'm talking about diffs like these
[17:39] <cjwatson> seb128: what do you use to generate the patch file though? it doesn't look like quilt refresh
[17:39] <asac> liw: so you ran into the "recommends dont get installed on upgrade bug" :) ... please see if installing libmbca0 and then creating a new connection helps
[17:40] <asac> (selecting your proper provider in the wizard)
[17:40] <cjwatson> (you plural)
[17:40] <seb128> cjwatson: I tend to use cdbs-edit-patch because I dislike quilt (sometime that requires commenting the debian/rules quilt line though)
[17:41] <seb128> cjwatson: but the other debian pkg-gnome guys use quilt
[17:41] <liw> asac, it was already installed
[17:41] <ogra> pitti, superm1 did any of forget you adjust my samsung Q1U patch to the new hal-info upload ? seems the samsung keyboard stuff now ended up in the toshiba area ...
[17:41] <cjwatson> this was done by norsetto by the looks of things
[17:41] <liw> asac, version 0.0.3~bzr42-0ubuntu2
[17:41] <asac> liw: which applet version?
[17:41] <asac> network-manager-gnome
[17:41] <ogra> *any of you
[17:42] <seb128> cjwatson: dunno how he did it then, but using quilt should work correctly
[17:42] <liw> asac, 0.7~~svn20081005t082522-0ubuntu1
[17:42] <asac> ok. all restarted i assume?
[17:42] <liw> asac, rebooted and everything
[17:42] <asac> liw: anyway. please go to connection editor and create a new connection. then you should see a wizard?
[17:42] <asac> (new mobile broadband)
[17:43] <nxvl> cjwatson: you already fix this issue, right? ->https://bugs.edge.launchpad.net/ubuntu/+source/debian-installer/+bug/279127
[17:43] <liw> asac, what is the connection editor called in Finnish? (I don't understand nm-applet's UI...)
[17:43] <cjwatson> seb128: it works, it's just ugly :-) I like to produce minimal debdiffs when working on other people's packages
[17:43] <nxvl> i remember to see a patch somewhere but i can't find the bug
[17:43] <liw> asac, or rather, where is it in the menu?
[17:43] <cjwatson> nxvl: I did?
[17:43] <BenHoltz> Hey guys, Question...  How far our of RC1 would you guys say we are?
[17:43] <BenHoltz> out*
[17:43] <cjwatson> BenHoltz: http://wiki.ubuntu.com/IntrepidReleaseSchedule
[17:43] <superm1> ogra, i've only touched one fdi file with my upload, you'll have to see if pitti did anything though
[17:43] <nxvl> cjwatson: i remember to see a patch when i was fixing the partman-ext3 issue, i think it was from you
[17:43] <liw> asac, right mouse button menu, third item?
[17:43] <asac> liw: right click on applet ... edito connections
[17:44] <asac> yeah
[17:44] <asac> liw: there is amobile broadband tab and you can create new connections there
[17:44] <ogra> superm1, well, was it 30-keymap-misc.fdi ?
[17:44] <nxvl> cjwatson: but i can be wrong
[17:44] <superm1> ogra, no :)
[17:44] <BenHoltz> ﻿cjwatson: I guess a better question would be is it worth my time to do the upgrade now, or are there still Major holes left
[17:44] <cjwatson> nxvl: oh, Dustin fixed that, bug 277153
[17:44] <cjwatson> nxvl: (feel free to dup)
[17:44] <ogra> superm1, then it was pittis fault i guess :)
[17:44] <nxvl> cjwatson: thank you!
[17:44] <liw> asac, ok, done that, now I have one for my operator, and it say "ei koskaan" ("never" in Finnish)
[17:45] <nxvl> i knew i saw a patch
[17:45] <asac> liw: yeah. thats ok. (it tells you when you last used that connection)
[17:45] <seb128> cjwatson: that's a good intend but don't bother about the autoconf patches format just use whatever tool is easier for you
[17:45] <asac> liw: try to connect to it in the applet (the connection should be there)
[17:46] <cjwatson> BenHoltz: from beta onwards we generally say that reasonably competent users can give it a go and report problems to us; there are of course still problems
[17:46] <liw> asac, the UI doesn't make it at all clear what the "never" thing is... but that's less important than getting this to work
[17:46] <cjwatson> seb128: ok, thanks
[17:46] <liw> asac, I don't see any connection in the applet, should I disable the non-NM-managed networking first?
[17:47] <BenHoltz> ﻿cjwatson: Thank you sir! I will give it a go and let you know when I find anything that's not in the bug tracking.
[17:47] <BenHoltz> and open a new bug along with it.. ;)
[17:47] <cjwatson> well, don't let me know personally, I don't want to be a clearing-house for all bugs :)
[17:47] <asac> liw: hmm. maybe try that. after changing the config you can sudo killall nm-system-settings to reread it
[17:47] <BenHoltz> hahaha
[17:48] <BenHoltz> thanks again...
[17:48] <asac> liw: do you have ppp0 or something configured in /etc/network/interfaces?
[17:48]  * BenHoltz disappears so productive work can go on without his pesky interruptions.
[17:48] <liw> asac, I only have lo, eth0, and br0 in /e/n/i
[17:49] <liw> asac, after the sudo killall, NM is again trying to do dhcp on eth1, which seems to be the phone
[17:49] <asac> liw: ok. try to disable it. but unless its a bad applet bug it appears that NM just doesnt see your device at all
[17:49] <asac> liw: eth1 is your phone?
[17:50] <liw> asac, eth1 appears when I attach the phone and disappears when I detach it
[17:50] <asac> liw: i doubt it ... also dhcp is not run on 3G ... thats ppp that doing the IP shuffleing
[17:50] <asac> liw: wow
[17:50] <liw> asac, disable it? disable what? how?
[17:50] <asac> liw: /etc/NetworkManager/nm-system-settings.conf ... managed=true
[17:50] <asac> liw: then killall like above
[17:51] <liw> asac, perhaps I am choosing the wrong option in the phone, when I connect the usb cable?
[17:51] <asac> liw: what options are available?
[17:51] <liw> asac, should I use "PC suite" or "data transfer" or "ip tunnel" (I think tunnel is a better translation)?
[17:52] <asac> try PC suite
[17:52] <asac> that sounds familiar ;)
[17:53] <liw> asac, now I get... in syslog, from the kernel, things like "usb 1-2: bad CDC descriptors" and "cdc_acm 1-2:1.10: ttyACM0: USB ACM device"
[17:53] <liw> and more
[17:54] <asac> liw: ok. and NM doesnt see your phone?
[17:54] <liw> asac, correct, it does not see my phone
[17:54] <asac> liw: do you get a result by: hal-find-by-capability --capability modem
[17:54] <asac> ?
[17:55] <liw> asac, yes
[17:55] <mathiaz> cjwatson: I've udpated the description of some tasks used in the server install (tomcat, samba and virtualization). Should a new version of taskel be uploaded ?
[17:55] <asac> liw: could you paste please
[17:55] <asac> liw: also the tail of syslog when plugging the phone in would be helpful
[17:55] <ogra> liw, that looks like a prob with the driver rather than NMs fault
[17:55] <liw> asac, copying by hand, since the machine has no network... /org/freedesktop/Hal/devices/usb_device_421_44d_noserial_if0_0_serial_unknown_0
[17:55] <ogra> "usb 1-2: bad CDC descriptors" is definately a driver message
[17:55] <asac> liw: i need the complete output ;)
[17:56] <liw> asac, just a minute, I'll put it back online
[17:57] <liw> asac, http://paste.ubuntu.com/54694/
[17:58] <asac> liw: ok. and the capability output?
[17:58] <liw> asac, what's that?
[17:58] <asac> 18:54 < asac> liw: do you get a result by: hal-find-by-capability --capability modem
[17:58] <asac> liw: oh sorry ;)
[17:59] <asac> lshal -u `hal-find-by-capability --capability modem`
[17:59] <asac> liw: ^^
[17:59] <liw> asac, just a minute
[18:00] <cjwatson> mathiaz: ok, I'll do that soon
[18:01] <liw> asac, http://paste.ubuntu.com/54696/
[18:01] <asac> liw: yeah ok. you need to adjust modem fdi
[18:01] <asac> liw: edit /usr/share/hal/fdi/information/10freedesktop/10-modem.fdi
[18:01] <asac> search for nokia
[18:02] <asac> and add your product_id there
[18:03] <ogra> hmm
[18:03] <liw> asac, do I need to restart hal or something before I try again?
[18:03] <kirkland> Riddell: hey, i've cleaned up the licensing inconsistency, new version pushed onto the queue
[18:03] <asac> i think restart is enough.
[18:04] <ogra> madwifi needs a SUSPEND_MODULES="ath_pci" andtry for pm-utils ... does anyone have an idea in which package to put that ? l-r-m or pm-utils rather ?
[18:04] <seb128> cjwatson: oh, I noticed that my totem local source was outdated that's why I said we usually run only autoconf, you need the automake update for the new plugin, I just run autoreconf (using no argument) in those cases, I noticed that you have Makefile.in changes in the bbc patch, we usually prefer to split source changes and autotools updates, it makes easier to do update (the source changes usually apply easily and we can regenerate the autot
[18:04] <seb128> ools changes)
[18:04] <ogra> *entry
[18:04] <asac> liw: ^^ you should be able to see the result in the lshal above: GSM should be in the command_sets (in addition to V.250 which you already had)
[18:04] <mathiaz> cjwatson: great - thanks !
[18:05] <superm1> ogra, that sounds like a regression wrg to needing to remove the module prior to suspend.  i thought it was suspend safe in the past?
[18:05] <Riddell> kirkland: accepted
[18:05] <ogra> superm1, no idea i didnt use it before
[18:05] <kirkland> Riddell: outstanding, thanks so much
[18:06] <ogra> superm1, the prob is that ath5k gets loaded even if its blacklisted ... so on resume ath5k replaces ath_pci
[18:06] <ogra> which results in non working wlan on devices that dont work with ath5k
[18:06] <superm1> ogra, oh that's quite an interesting problem with ath5k loading
[18:07] <liw> asac, whee! now it works
[18:07] <superm1> ogra, did you bug the kernel guys about that yet?
[18:07] <ogra> superm1, yeah, especially that it doesnt respect blacklisting
[18:07] <liw> asac, should I file a bug with a patch? network-manager?
[18:07] <ogra> not yet, it was low on my todo
[18:07] <liw> asac, or rather: hal-info ?
[18:08]  * ogra takes that over to -kernel
[18:08] <asac> liw: yeah please against hal-info
[18:08] <asac> liw: pitti will apply that upstrem and in our package
[18:08] <asac> liw: thanks for testing ;)
[18:08] <asac> liw: ip tunnel is definilty iteresting though :)
[18:08] <liw> asac, I assume it is related to wifi on the phone
[18:08] <asac> liw: if you understand what that does  let me know ,)
[18:08] <liw> now that I think abou tit
[18:09] <asac> liw: yeah. if you get it working that would be cool :) ... if its just dhcp that doesnt work you could also create a connection with static IP
[18:09] <asac> liw: you know where the connection editor is ;) in case you want to play a bit with it
[18:09] <liw> asac, the phone has no wifi to connect to...
[18:10] <asac> liw: oh ok :)
[18:10]  * asac has to run bbl
[18:10] <liw> asac, the phone has some kind of "connection editor" inside it, too... which is a) way confusing and b) crashes
[18:12] <james_w> liw: hey, is your system-cleaner update bugfix-only?
[18:13] <liw> james_w, yes
[18:13] <liw> james_w, in my opinion, anyway
[18:13] <james_w> hmm, I spy displaying the version number at startup, sounds like a feature to me :-)
[18:14] <liw> james_w, that's a bug fix, it prevents people from claiming they have updated to a new version when they haven't :)
[18:14] <james_w> liw: looks like it to me. Size of diff isn't so important, just makes review harder. I'm looking at it now.
[18:14] <james_w> liw: that argument works for me :-)
[18:17] <liw> asac, https://bugs.launchpad.net/ubuntu/+source/hal-info/+bug/279182
[18:23] <jcastro> kees: Is this the only bug for tracking getting webcams to work? https://bugs.edge.launchpad.net/ubuntu/+bug/260918/
[18:24] <jcastro> kees: wrt. your post to -devel a month ago
[18:25] <Ng> does firefox have any gvfs support?
[18:25] <kees> jcastro: afaik, yes.  pgraner was looking into it as well
[18:27] <jcastro> kees: ok, I was just checking the calendar. :D
[18:28] <kees> jcastro: yeah, it's making me nervous
[18:28] <jcastro> especially since stemp had it in his ppa for about a month
[18:28] <jcastro> maybe at UDS we need to discuss PPA->distro workflow smoothage or something
[18:29] <cjwatson> seb128: OK, I'll try to unpick those
[18:33] <kirkland> tkamppeter: ping
[18:33] <kirkland> tkamppeter: got your message in the bug, i can pull the data you want, right quick, if you're around
[18:35] <kirkland> Keybuk: okay, sorry distracted...  I added a trailing carriage return to my /etc/fstab, nfs mounts still not happening automatically on boot
[18:35] <kirkland> Keybuk: was that supposed to 'solve' the problem?
[18:36] <lukehasnoname> In Intrepid 64 bit, how can I rid myself of the error caused by bug #273833
[18:37] <lukehasnoname> First, can I get around it and boot, and second, how can I fix it? Booting up to a terribly loud system error beep at 4am does not make the roommate happy.
[18:39] <Keybuk> kirkland: it solved my bug
[18:39] <Keybuk> you obviously may have a different bug :-)
[18:39] <kirkland> Keybuk: looks so
[18:40] <kirkland> Keybuk: i'll dig, this one is bothering me ;-)
[18:40] <tkamppeter> kirkland, yes, I am here.
[18:40] <Keybuk> I debugged by added
[18:40] <Keybuk> exec 2>/var/run/nfsmount.$IFACE
[18:40] <Keybuk> set -x
[18:40] <Keybuk> to the top of the script in /etc/network/if-up.d
[18:40] <cjwatson> lukehasnoname: as far as I know, the bug as described is mainly cosmetic. If you're getting an error beep, have you considered the possibility that you in fact have a different bug (even if the output above is the last thing you see on the console)?
[18:41] <cjwatson> lukehasnoname: pretty much everyone running intrepid experiences bug 273833, and most of us can boot
[18:41] <kirkland> tkamppeter: http://pastebin.ubuntu.com/54711/
[18:42] <lukehasnoname> Something simple that I didn't try: Can I just hit "Enter" and move past the error?
[18:42] <lukehasnoname> and point taken about the "different bug"
[18:42] <cjwatson> lukehasnoname: since you're probably encountering something different and as yet undetermined, it's hard to say ...
[18:42] <lukehasnoname> hm
[18:42] <cjwatson> one easy way to find out ;-)
[18:42] <lukehasnoname> Well, I'm already installing hardy because I got pissed
[18:43] <lukehasnoname> >_>
[18:43] <lukehasnoname> but I might try again with the beta, depending on my mood when I get home
[18:43] <cjwatson> well, intrepid is for people eager to find out the reasons behind problems ;-)
[18:43] <tkamppeter> kirkland, foomatic-rip generates temporary files with names foomatic-sdfhjsfg, but why are they created in /dev/shm? What is /dev/shm good for?
[18:44] <slytherin> hi all, is there any workaround for bug #276349? I am not able to use the alternate CD image for daily upgrade.
[18:45] <cjwatson> slytherin: I don't think so at present
[18:45] <lukehasnoname> cjwatson: I'm aware. I'll consider what's been said, though assuming my hardy install isn't broken, I'll probably stick with that at least until the 30th.
[18:45] <siretart> \o/ ffmpeg accepted! thanks for that!
[18:45] <lukehasnoname> thanks
[18:45] <cjwatson> lukehasnoname: the risk is that it may be a problem nobody else is encountering, and so won't get fixed :-(
[18:46] <lukehasnoname> damnit, don't guilt me into testing....
[18:46] <kirkland> tkamppeter: /dev/shm is a tmpfs filesystem in memory
[18:46] <lukehasnoname> UGH
[18:46] <kirkland> tkamppeter: high speed, not written to disk
[18:46] <kirkland> tkamppeter: i symlink my /tmp to /dev/shm
[18:46] <kirkland> tkamppeter: shm = shared memory
[18:47] <lukehasnoname> I'll be back on later, class is over.
[18:48] <kirkland> tkamppeter: perms on /dev/shm are drwxrwxrwt
[18:48] <tkamppeter> kirkland, then you manual deviation of the standatd config causes the bug, probably all programs which use an added security architecture, like AppArmor or SELinux would break on your system, as long as you do not manually correct all the config files for these architectures.
[18:49] <kirkland> tkamppeter: i should be able to add the appropriate label or something /dev/shm, no?
[18:49] <tkamppeter> kirkland, but CUPS is AppArmor-protected, it can only write to locations which AppArmor allows via the /etc/apparmor.d/usr.sbin.cupsd file.
[18:50] <mdz_> mathiaz: it lasts anywhere from 30 minutes to 2 hours depending on the agenda
[18:50] <tkamppeter> You must edit this file to get your printing working again.
[18:50] <mdz_> mathiaz: if you are only available for the first part of the scheduled time, then just let us know and we should be able to accomodate you by ordering the agenda accordingly
[18:50] <tkamppeter> kitkland and Intrepid has a lot of files in /etc/apparmor.d, you probably also need to edit the files of other programs, too.
[18:51] <jdstrand> kirkland: fyi, symlinks are 'normalized' to the actual path in apparmor (by design)
[18:52] <kirkland> jdstrand: should /dev/shm be added to some swath of profiles?
[18:52] <mathiaz> mdz_: well - I'm not planning to attend the TB meeting. I'm interested to know if the Server meeting shoudl be moved one hour later.
[18:52] <kirkland> jdstrand: i didn't think my linking /tmp -> /dev/shm was all that unusual
[18:52] <jdstrand> kirkland: I only caught the tail end of this...
[18:52] <kirkland> jdstrand: cups/printing stopped working for me last week
[18:52] <tkamppeter> kirkland, the new foomatic-rip solves the problem by checking several temporary file locations, including /var/spool/cups/tmp, so installing the new foomatic-rip should also solve the problem.
[18:53] <kirkland> jdstrand: with tkamppeter's help, i think we've narrow the problem to the fact that my /tmp is a symlink to /dev/shm
[18:53] <kirkland> tkamppeter: cool, thanks.
[18:53] <kirkland> jdstrand: i'm just wondering if we might see any other problems creep up
[18:54] <jdstrand> kirkland: it may not be unusual, but it is non-standard, and off-hand, I am uncomfortable giving that access by default
[18:54] <jdstrand> kirkland: but you should see all the errors in /var/log/kern.log if it is indeed part of the problem
[18:54] <mdz_> mathiaz: the average meeting is <=1 hour, so there will only be a conflict for especially long-running meetings
[18:54] <mdz_> mathiaz: i.e. I don't think it's necessary to move it
[18:55] <kirkland> jdstrand: okay, i'll beware
[18:55] <mdz_> mathiaz: it has always been at this time. so if you haven't noticed a problem, that's not expected to change
[18:55] <mathiaz> mdz_: ok.
[18:56]  * ogra curses once more about quilt
[18:59] <radix> when upgrading using update-manager or do-release-upgrade, does it upgrade including -updates from the new distribution?
[19:01] <geser> Hi, is a core-dev around who has some time to sponsor bug #264554?
[19:01] <zul> geser: ill do it right now
[19:01] <geser> zul: thanks
[19:10] <slytherin> radix: -updates have packages only after the new release is made. It is of no use for development release.
[19:11] <ogra> radix, while slytherin is right, ${next release}-updates lines are by default in sources.list after a dist upgrade (even in development releases)
[19:12] <radix> ogra: thank you
[19:26] <slytherin> cjwatson: am I correct to assume that it is you who implemented 'last good boot' feature?
[19:26] <ogra> slytherin, that was BenC iirc
[19:27] <cjwatson> slytherin: no; what led you to that conclusion?
[19:27] <slytherin> cjwatson: I was confused probably.
[19:29] <cjwatson> (ogra is correct)
[19:31] <slytherin> ogra: cjwatson: any idea what all changes did it involve? I am using grub2 currently and the entries are not added to menu.
[19:32] <ogra> slytherin, there were docs about it on the wiki and there was a blueprint for it
[19:32] <ogra> (dont ask for URLs though)
[19:32]  * slytherin searches
[19:35]  * cody-somerville hides.
[19:47] <tjaalton> ogra: søren hauberg? cool, wonder if it would replace wacom_drv though, but likely evtouch at least
[19:47] <ogra> tjaalton, yeah, soren
[19:48] <ogra> well, he wasnt aware that there are six drivers we'll go over them in jaunty
[19:49] <ogra> evtouch is only one
[20:08] <slytherin> ogra: not able to find anything related to last-good-boot in wiki or blueprints. Didn't even find any link on BenC's blog. :-(
[20:15] <ogra> https://wiki.ubuntu.com/KernelTeam/removing-old-kernels
[20:18] <slytherin> ogra: thanks, I will see if I can modify grub2 to include the feature.
[20:18] <ogra> best tal to BenC
[20:18] <ogra> *talk
[20:18] <slytherin> sure
[20:19] <kirkland> tkamppeter: thanks, fix verified, printer works with foomatic-rip updates!
[20:20] <slytherin> is any archive admin around? I am waiting for some java libs to be moved to universe to work on their rdepends/reverse-build-depends.
[21:18] <ahasenack> jibel: nice call on #278518, that was bugging me a while. We have others which I can now trace to the root cause
[21:18] <ahasenack> jibel: thanks
[21:21] <jibel> ahasenack: you're welcome
[21:29] <Laney> asac: Is this FF bug reported? Seeing this when downloading things: http://orangesquash.org.uk/~laney/ff
[21:34] <asac> Laney: locale?
[21:34] <Laney> asac: en-gb
[21:35] <Laney> asac: Hmm, getting it on the about dialog too
[21:43] <james_w> Laney: have you updated today?
[21:43] <Laney> james_w: Yep
[21:43] <Laney> I didn't restart though.
[21:44] <james_w> I'm seeing that too, and it often happens when firefox updates and you don't restart
[21:44] <Laney> Strange, I've never had it before
[21:45] <Laney> Oh, restarting did fix it ;)
[21:45] <Laney> asac: Never mind.
[21:45] <Laney> thanks james_w
[21:45] <james_w> which-pkg-broke isn't hinting at anything mozilla related updating for me today though
[21:45] <james_w> and there wasn't a firefox restart notification, but there was a system one.
[21:46] <Laney> No there wasn't a firefox one, hence why I didn't restart it
[21:47] <sebner> james_w: new kernel update ;)
[21:47] <Laney> Grr, this PA bug is irritating
[21:59] <asac> Laney: from which version did you upgrade and are you using ubufox?
[22:00] <Laney> asac: FF didn't update today, and yes I am
[22:05] <asac> Laney: ok. could you look in /var/log/apt/term.log to see if you got language pack updates today?
[22:05] <asac> or maybe extension packages
[22:11] <james_w> asac: I got language-packs, and totem-mozilla
[22:12] <asac> james_w: so you had the same issue?
[22:12] <asac> (today)
[22:12] <james_w> asac: yeah, it sounds like it
[22:13] <james_w> e.g. view source gives XML parsing error: undefined entity
[22:13] <Laney> asac: I got language-pack-en updates if that's what you're after
[22:13] <Laney> can't see anything else
[22:13] <Laney> language-support-translations-en
[22:14] <Laney> Oh no, ignore that last one, that was later
[22:22] <TheMuso> sbeattie: I am well aware of that bug. It doesn't always occur, and there are other symptoms and behaviors, as it is a race condition. I will be looking at it today.
[22:29] <RAOF> TheMuso: Have you heard anyone else complain that the alsa->pulseaudio routing breaks skype on x86-64?
[22:35] <BenHoltz> hey guys, are there known issues with compiz?
[22:35] <cjwatson> err, yes - https://bugs.launchpad.net/ubuntu/+source/compiz/+bugs
[22:35]  * BenHoltz asked a dumb question..
[22:36] <cjwatson> I suspect you wanted to ask a more specific question
[22:36] <BenHoltz> haha
[22:36]  * ScottK suspects wanting a more specific answer.
[22:36] <desrt> +1 colin's jerkpoints :)
[22:36] <BenHoltz> I'll go ask in #ubuntu+1
[22:37]  * BenHoltz just read topic and is leaving disgracefully...
[22:41] <wgrant> Which fruit is replacing vostok?
[22:41] <cjwatson> desrt: I wasn't actually trying to be a jerk, I figured I might as well give him a useful link as well as gently suggesting that he might want to be more specific :)
[22:43] <spm> wgrant: crowberry
[22:43] <wgrant> spm: Aha.
[22:43] <Laney> What should that link be?
[22:46] <james_w> Laney: HelpingWithBugs I believe
[22:47] <Laney> Works for me
[22:53] <cjwatson> just saving a few characters ...
[22:53] <wgrant> Poor Edgy. Always forgotten.
[22:54] <RAOF> Heh.
[22:54] <ajmitch> is it EOL?
[22:54] <cjwatson> might have something to do with it being EOL, yes :)
[22:54] <cjwatson> don't think the fine distinction is worth precious topic space, though
[22:54] <wgrant> I assumed so.
[22:54] <wgrant> Probably.
[22:55] <ajmitch> next you'll be complaining that we don't answer questions about warty in here
[22:55] <RAOF> wgrant: Any luck with Mouse->Touchpad tab?
[22:55] <wgrant> I saw somebody complaining about Hoary's repos vanishing when they finally purged the archive of the old distroseries last year.
[22:56] <wgrant> RAOF: tjaalton is working on a new backport of XI property stuff to our xserver, which will hopefully help to fix it.
[22:57] <RAOF> Cool.
[23:00] <dx9s_work> anybody here working on bug 191027
[23:02]  * wgrant fixed that locally by changing to PulseAudio in gstreamer-properties.
[23:04] <dx9s_work> it's weird.. seen several "work-arounds" ... mine was the most recent...  'asoundconf set-pulseaudio' .. and that solved it for me .. no changing anything else . no alsa updates (outside what is available on the dev branch for intrepid) ...
[23:06] <dx9s_work> was curious as to pulseaudio and when it is starts during an xsession... the first work around was to stop and restart the user-space pulseaudio server... the 'asoundconf set-pulseaudio' doesn't require restarting the first pulseaudio server (however it starts during logging into machine via gdm/ start of X session)
[23:09] <dx9s_work> also, another thing to note. reguardless if 'asoundconf set-pulseaudio' or removing the .asoundrc* from homedir ... when openning 'alsamixer' it shows the pulseaudio "master" volume... so in either case, alsa somehow defaults to forwarding non-specific sound hardware to the pulseaudio server... an 'alsamixer -c 0' will bring up the REAL hardware mixer ...  where as 'alsamixer' will default to pulseaudio .. (with OR without the 'asoundconf set-pu
[23:09] <dx9s_work> lseaudio')
[23:10] <dx9s_work> wgrant, does any of this make sense?
[23:10] <asac> Laney: ok thx
[23:20] <TheMuso> grrr latest updates have broken my MacBook Pro backlight control. I saw a hal update, will have to dig further.
[23:24] <bryce_> TheMuso: the hal change that just now went in was for dell studio systems only
[23:27] <TheMuso> bryce_: the last hal change I have is the latest merge from Debian.
[23:27] <bryce_> TheMuso: ah okay nevermind, then that is suspicious
[23:27] <bryce_> TheMuso: and actually the hal change I sponsored was to hal-info, not hal.
[23:28] <TheMuso> bryce_: Right, I am referring to pitti's upload.
[23:28] <TheMuso> I'll dig deeper.
[23:56] <bruce89> #159996