[00:02] <cjwatson> asac: some people (myself included) find it much more convenient and less prone to human error
[00:03] <cjwatson> I don't use it for performance advantages so have no idea whether it provides those
[00:03] <cjwatson> I don't find that it has any performance disadvantages, and wouldn't expect anything either way really
[00:05] <asac> human error == forgetting to push?
[00:08] <cjwatson> yes
[00:08]  * cjwatson is rather fed up of the tedious conversations that go "hmm, where's your change?" "I committed it" "did you push?" "oh, no, whoops"
[00:08] <asac> hehe
[00:09] <cjwatson> also checkouts mean you never accidentally commit to non-head and have to merge, so if what you want is a single mainline most of the time, then it's neater
[00:10] <asac> cjwatson, hmm. good point. what happens if you commit and you have non-head on your disk?
[00:10] <cjwatson> in a checkout, it refuses and tells you to update
[00:10] <asac> right. does it smart merging then?
[00:11] <cjwatson> normally neatness isn't a big concern of course, but when the branch is "current thing that's packaged in Ubuntu or next thing to be uploaded" then it's a bit more important
[00:11] <cjwatson> it's just the same as pulling into a modified working tree
[00:11] <cjwatson> it'll do a three-way merge if possible and leave you conflicts if it fails
[00:13] <asac> for a moment i really forgot that you cant have more than one uncommitted change ;)
[00:18] <slangasek> mathiaz: ah, I see you've been tracking the changes in the openldap package svn, since you patch applies cleanly... thank you :)
[00:22] <mathiaz> slangasek: bzr merge FTW
[00:22] <slangasek> indeed :)
[00:23] <slangasek> in fact, did you have a bzr branch published, so that when the time comes I can merge it into the official repo?
[00:24] <mathiaz> slangasek: I don't have a public branch
[00:24] <mathiaz> slangasek: but I could push one to LP
[00:28] <slangasek> that would be nice, then the bzr-heads can get the whole revision history in the tree :)
[00:29] <mathiaz> slangasek: lp:~mathiaz/openldap/debian-cnconfig
[00:29] <slangasek> wooho
[00:29] <slangasek> o
[00:43] <slangasek> mathiaz: is this a missing merge?:
[00:43] <slangasek> -       if dpkg --compare-versions "$OLD_VERSION" lt-nl 2.4.7; then
[00:43] <slangasek> +       if dpkg --compare-versions "$OLD_VERSION" le-nl 2.3.30-6; then
[00:44] <slangasek> vorian: hrm, the lemonpos package in NEW appears to be empty.
[00:48] <kees> Can I add a standing "remove from ubuntu archive" request for "joomla"?  it's itp in debian and really really don't want it in ubuntu given it's terrible security record.
[00:49] <vorian> slangasek: let me take another look at it
[00:50] <slangasek> kees: you can ask for it to be blacklisted preemptively, sure
[00:50] <slangasek> kees: you can also comment on the ITP :)
[00:50] <kees> slangasek: I would like that, yes.  standard ubuntu-archive bug?
[00:50] <slangasek> kees: yes
[00:50] <mathiaz> slangasek: not that I know of - It was just to keep the functions to handle a db upgrade around
[00:51] <mathiaz> slangasek: upgrading from etch and hardy doesn't involve a db transition
[00:51] <slangasek> mathiaz: hrm, then where did that line come from in the first place :)
[00:52] <mathiaz> slangasek: IIRC it comes from dapper -> hardy support
[00:52] <slangasek> ah
[00:52] <kees> slangasek: jmm is all over the ITP already, I just wanted to block it Ubuntu too.  :)
[00:52] <slangasek> mathiaz: er, that doesn't make sense to me either
[00:52] <slangasek> mathiaz: hang on, will investigate
[00:52] <slangasek> kees: \o/
[00:52] <mathiaz> slangasek: upgrading from dapper (and sarge) required ldbm conversion
[00:53] <slangasek> mathiaz: oh, I see; so the transition is already done on both sides, and this change will let us avoid unnecessary redumps on sarge->etch?
[00:53] <mathiaz> slangasek: that function was used to handle the ldbm -> db transition
[00:54] <slangasek> ... er, unnecessary redumps on etch->lenny
[00:54] <mathiaz> slangasek: yes
[00:56] <mathiaz> slangasek: as of now, this code won't be called in ubuntu (hardy -> ..) and debian ( etch -> lenny)
[00:56]  * slangasek nods
[00:57] <mathiaz> slangasek: however the package can be configured to dump the ldap tree to ldif on every upgrade
[00:57] <mathiaz> slangasek: so some of the functions need to be kept around
[00:57] <slangasek> yes, I'm not disputing that
[00:57] <slangasek> I was just trying to figure out why the version number used in the check is different in your tree
[00:59] <slangasek> mathiaz: we have a changelog entry here of "- need to dump and reload databases again for the upgrade from 2.3.39."
[01:00] <slangasek> no other documentation, but apparently I was convinced of that in December
[01:02] <slangasek> mathiaz: indexing issue; http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/2007-December/001819.html
[01:02] <slangasek> (at a minimum)
[01:03] <mathiaz> slangasek: right - so it seems that 2.4.7 should be kept
[01:04]  * slangasek nods
[01:09] <bryce> ogasawara: can you look at 204423?  Since it results in a system reboot it sounds like probably a kernel issue
[01:16] <emgent> pitti: https://launchpad.net/~we-love-pitti big lol!
[01:16] <ion_> :-D
[01:16]  * slangasek squints at jbossas4.  How does a jar have a circular build-dependency?
[01:52] <calc> ugh several packages need updating for the new libtool still
[01:53] <calc> apt-cache showpkg libltdl3-dev
[01:54]  * calc notes this is blocking OOo for the moment
[01:54]  * calc is investigating to see what needs to be done now
[01:58] <TheMuso> calc: I am having to relibtoolize pulseaudio as well, and its getting slightly annoying.
[01:59] <slangasek> calc: ITYM "libtool needs fixing to provide libltdl3-dev"
[01:59] <TheMuso> slangasek: there lis libltdl7
[01:59] <slangasek> yes, I'm aware
[01:59] <TheMuso> I'm trying to make use of that instead.
[01:59] <slangasek> by provide I mean a literal Provides:
[01:59] <TheMuso> ah ok.
[02:00] <calc> slangasek: oh is that what needs to be done? then yea someone needs to fix that asap
[02:00] <calc> slangasek: should i just upload a new version with just that one change?
[02:01] <slangasek> calc: well, Keybuk didn't raise any substantive objections, so yes, that's the better way about it
[02:01] <slangasek> calc: that would be fine, I think
[02:01] <calc> ok
[02:01] <calc> Keybuk: ping (sure you are awake at 4am right?) ;-)
[02:01] <calc> er 2am
[02:01] <calc> slangasek: oh was this already discussed elsewhere?
[02:01] <slangasek> calc: only here, and not at any great length :)
[02:02] <calc> slangasek: but scott is aware of the need to have the provides?
[02:02]  * calc doesn't want to annoy anyone or potentially cause issues
[02:02] <slangasek> calc: he punted on the question
[02:02] <calc> ok
[02:02] <calc> well it can be backed out later if needed i'll upload it here in a few min
[02:02] <TheMuso> I wonder whether packages will still need relibtoolizing then...
[02:03] <TheMuso> Because if not, I am willing to wait for that change.
[02:03] <calc> maybe i should fix it up locally see if it helps ooo to build and then decide whether to upload it, heh
[02:05] <slangasek> calc: it should be done anyway; if you prefer, I can do the libtool upload here
[02:05] <slangasek> TheMuso: libltdl has very little to do with libtoolizing
[02:05] <calc> slangasek: ok go ahead :)
[02:05] <TheMuso> slangasek: Hrm ok.
[02:06] <calc> i'll make the change locally and verify it works ok for OOo
[02:06] <calc> but it will take several hours to build OOo
[02:08] <slangasek> 0 upgraded, 122 newly installed, 0 to remove and 2 not upgraded.
[02:08] <slangasek> build-deps ftw
[02:08] <slangasek> does apt-get build-dep follow recommends by default now?
[02:08] <calc> that would be bad
[02:09] <calc> why does libtool depend on openjdk
[02:10] <calc> "texi2html texinfo gfortran gcj automake autoconf quilt" - explodes into the world
[02:10]  * slangasek lets pam and libtool battle for bandwidth
[02:11] <calc> approx is great at least for repeated use
[02:11] <calc> of course you still have to wait the first time you have to pull the debs
[02:15] <ion_> I’m using a generic HTTP proxy, polipo to be accurate. Haven’t bothered to use a separate apt cacher.
[02:16] <calc> 136MB build-depends for libtool (ouch)
[02:16] <calc> i need better broadband
[02:18] <TheMuso> Well the change to libltdl7 for pulse means that symbols cannot e found when building, so I'm digging into that.
[02:18] <TheMuso> So even if libltdl3 was a provides, it may still break things.
[02:20] <slangasek> what are the names of the missing symbols?
[02:22] <TheMuso> slangasek: There is only one that I can see so far, lt_preloaded_symbols
[02:22] <slangasek> hmm
[02:22] <slangasek> well, that's not a symbol name present in libltdl3 either
[02:22] <slangasek> so it's possible that this was a macro in the old version, but is now deprecated
[02:22] <TheMuso> No I think it actually gets generated by the libtool bits for the package.
[02:23] <TheMuso> the scripts rather.
[02:24] <calc> wow libtool actually has a test suite it runs during build
[02:27]  * calc thinks libtool might take as long to build as OOo
[02:28] <slangasek> heh
[02:29] <calc> hmm only 11m6s but it seemed longer than that
[02:32] <calc> is this right: Provides: libltdl3-dev
[02:33] <calc> even with that its claiming it needs to install the package
[02:33]  * calc is either too tired to see the issue or is doing something wrong
[02:33] <calc>   libgphoto2-2-dev: Depends: libltdl3-dev but it is not installable
[02:33] <slangasek> that's right; I don't know what issue you're running into
[02:34] <StevenK> Does libgphoto2-2-dev have a versioned dep on libltdl3-dev?
[02:34] <calc> no
[02:34] <slangasek> no
[02:35] <calc> is there some sort of don't allow a provides satisfy a depends thing?
[02:36]  * calc has no idea why this isn't working
[02:36] <StevenK> The version of libltdl7-dev I have here doesn't have Provides
[02:37] <calc> StevenK: i hacked a local copy
[02:37] <StevenK> Why does the soname need to be in the -dev package name? :-/
[02:37] <calc> http://pastebin.ubuntu.com/31539/
[02:41] <slangasek> StevenK: doesn't
[02:41] <slangasek> shouldn't be
[02:41]  * StevenK gets tempted to fix it.
[02:42] <slangasek> to make things even more incompatible with the archive? :)
[02:42] <StevenK> slangasek: Well, if the new libltdl-dev Provides: both libltdl7-dev and libltdl3-dev?
[02:43] <slangasek> sure; except Debian hasn't done that, so if packages come along with versioned deps on libltdl7-dev, hilarity ensues
[02:45] <StevenK> calc: Did you just install that package directly? apt is trying to resolve it, and it doesn't tend to check installed packages
[02:45] <calc> StevenK: yea i installed it directly
[02:45] <StevenK> calc: Don't do that. :-)
[02:46] <slangasek> huh?
[02:46] <slangasek> apt doesn't try to install packages that are already installed
[02:46] <calc> apt doesn't look at what is installed on your system?
[02:46] <slangasek> (or complain about being unable to do so)
[02:46] <crimsun> asac: no, that's currently not possible
[02:47] <crimsun> asac: (meaning it's not possible to have a graceful fallback if you redefine pcm.default to have a different type)
[02:48] <calc> StevenK: why isn't that a bug in apt?
[02:48] <calc> StevenK: shouldn't it be looking at what is on the system to know if it needs to download something?
[02:49] <crimsun> asac: for an example of a graceful fallback, you'd have to have something along the lines of what `asoundconf set-default-card foo' does, which means defaults.pcm.card gets redefined but defaults.pcm.device 0 is the fallback [for card 0]
[02:50] <slangasek> calc: it's not a bug in apt because StevenK's comment has no correspondence to reality ;)
[02:50] <calc> ok
[02:50] <slangasek> unless what you did was install libltdl7-dev without *also* installing libltdl7, in which case apt might choose removal first
[02:50] <StevenK> Try it? It will either prove me right or wrong
[02:51] <calc> slangasek: well i rebuilt it without bothering to change the version number
[02:51] <calc> then just installed the -dev package (the non dev was already installed)
[02:52] <TheMuso> crimsun: So what is the use of your changes then?
[02:52] <TheMuso> crimsun: As XFCE/KDE don't use pulse.
[02:53] <crimsun> TheMuso: I was asked to draft a solution that doesn't involve a system-wide asoundrc
[02:53] <StevenK> calc: I think that might be causing the problem. The version isn't different so apt is using what's in Packages file?
[02:53] <calc> maybe so
[02:53] <crimsun> TheMuso: I haven't finished hacking alsa-lib to fallback sanely if another type is used
[02:53] <StevenK> And therefore doesn't "see" the Provides
[02:53] <TheMuso> crimsun: Fair enough, but your changes are merged anyway.
[02:54] <calc> that probably should be considered a bug that it isn't using the dpkg available file first (i guess that is where it should be getting the data?)
[02:54]  * StevenK waits for slangasek to say otherwise again. :-)
[02:54] <calc> i'll rebuild it with a bumped version number and see if it helps
[02:54] <slangasek> StevenK: nah, now you're talking about a corner case I've never tested, then. :)
[02:55]  * calc guesses he should file a bug if this works
[02:55] <calc> its not ideal way to rebuild packages but it should still use what is actually on your system over what is in the archive
[02:55]  * StevenK watches libtool build
[02:59] <calc> StevenK: just get Keybuk to apply your change to Debian ;-)
[02:59] <StevenK> 2.2.2-1 is in experimental, and 2.2.4-0ubuntu1 is in Intrepid
[03:00] <slangasek> calc: Keybuk seems an unlikely person to do that, since he's not a DD?
[03:00] <slangasek> (nor the libtool package maintainer in Debian)
[03:01] <StevenK> It's Kurt now
[03:04] <calc> slangasek: oh he's no longer a DD?
[03:04]  * calc didn't realize he retired, heh
[03:06] <slangasek> years ago
[03:06] <calc> yea that was the problem apt doesn't look at the dpkg info unless it is newer than what is in its own Packages file
[03:07] <slangasek> heh, ok
[03:07]  * StevenK wins
[03:09] <calc> so apt is stupid (my opinion of course) ;-)
[03:56] <calc> is there a tool that can fixup the numbers in a diff?
[03:56] <ion_> The numbers?
[03:57] <calc> eg @@ -3,107 +3,114 @@
[03:57] <ion_> rediff (1)           - fix offsets and counts of a hand-edited diff
[03:57] <calc> ok
[06:45] <pitti> Good morning
[06:45] <Hobbsee> pitti!
[06:47] <pitti> emgent: *cough* how embarassing...
[06:47] <pitti> it's a Hobbbbbbbsee!
[06:48]  * StevenK waves to pitti 
[06:48]  * pitti sends a bunch of cookies to StevenK
[06:49] <StevenK> :-)
[06:50]  * Mithrandir grumbles.
[06:52]  * pitti gives some to Mithrandir, too
[06:52] <pitti> hey Tollef, how are you?
[06:56] <Mithrandir> feeling grumbly today.   A bit too early and moving is an interesting exercise.
[06:57] <pitti> Mithrandir: oh, different city, or just within?
[06:57] <Hobbsee> pitti: it is!
[06:57]  * Hobbsee freezes
[06:58]  * pitti started early to still have some hours with moderate temperature
[06:58] <Mithrandir> same city, but a semidetached house (I think that's the term) rather than a flat.
[06:58] <pitti> ah, nice; sounds like an upgrade :)
[06:58] <Mithrandir> absolutely.  It's just that moving is a bit of work with loads of planning and packing.
[06:58] <StevenK> pitti: Send the "hot" weather here, I'd prefer it to 13 degrees
[06:59] <Mithrandir> 13°C sounds lovely.
[06:59] <Mithrandir> but then, aircondition is also lovely.
[07:04]  * pitti doesn't like AC
[07:58] <RAOF>  Who's syncing Conduit?
[07:59] <RAOF> And why aren't they testing that it's installable first?
[08:04] <TheMuso> RAOF: Changed-By: James Westby <jw+debian@jameswestby.net>
[08:05] <pwnguin> plus addressing in a changed by?
[08:05] <TheMuso> pwnguin: Thats how it appears in mutt/gnome-terminal.
[08:06] <RAOF> In particular, conduit depends on python-gtkmozembed, which is built by debian's gnome-python-extras package, but not ours.
[08:16] <RAOF> So, I'm not sure if the correct fix is to merge in gnome-python-extras from Debian or to change conduit.
[08:19] <RAOF> Or, alternatively, split out python-gtkmozembed packages from our gnome-python-extras without merging from Debian, I suppose.
[08:30] <Sikon> Could a main sponsor please look at https://bugs.edge.launchpad.net/f-spot/+bug/250047 ? Or is main frozen?
[08:34] <TheMuso> Sikon: Main is not currently frozen no. See topic.
[08:35] <wgrant> Why is it Wishlist?
[08:37] <RAOF> Sikon: That's a really odd patch description, too.  In what way are you adding missing headers?
[08:38] <Sikon> ah, indeed, I should fix the patch description
[08:40] <Sikon> reuploaded
[09:20] <RAOF> Does anyone here know of any reason why gnome-python-extras hasn't been merged from Debian since Gutsy?
[09:20] <RAOF> The debian package now builds a couple of extra binary packages; in the intrests minimal divergence I'd like to merge the Debian package.  This should make Conduit installable again.
[09:22] <RAOF> seb128: Aha!  There you are.  You seem to have touched gnome-python-extras the most: ^^^
[09:24] <seb128> RAOF: you are welcome to do the merge if you want, no reason we didn't do it out of the fact that it's not going to be trivial and that I was not convinced by their recent split
[09:25] <RAOF> seb128: Thanks.  Given the 'not trivial', I might file that one away for the weekend.
[09:25] <RAOF> You don't think python-gtkmozembed is a good idea?
[09:25] <RAOF> Or python-eggtraywhatever it is?
[09:26] <seb128> I'm just not sure there is a real need to split those
[09:26] <seb128> but since debian did it now, we can as well reduce the delta
[09:27] <RAOF> Right.
[09:27] <seb128> the fun part will be to do -dbg variants for all of those
[09:27] <RAOF> Oh, right.  Python.  I don't just get dbgsym for free.
[09:28] <seb128> well, ideally those python-dbg should would have been sent to debian some cycles ago and we could just sync now
[09:28] <seb128> but looks like doko have been too busy to send his changes and nobody else picked up on the job either
[09:29] <RAOF> Oh, well.  A weekend of fun, I bet :).
[09:29] <seb128> btw there is no need to do this merge to have conduit installable
[09:29] <RAOF> True.
[09:29] <mvo> Riddell: hi, thanks for your kde4 stuff, what is the package name for the qt4 designer? qt4-designer seems to be gone?
[09:30] <seb128> so why did you said it'll make conduit installable again?
[09:30] <RAOF> But other packages will start to move to the new package split,.
[09:30] <seb128> the issue is just a typo which is fixed in -3 that we should sync when it's available
[09:30] <RAOF> Because it will?  conduit currently depends on python-gtkmozembed
[09:30] <RAOF> And that typo, yeah :)
[09:30] <seb128> well, we can easily change the conduit depends too
[09:31] <RAOF> Yes.
[09:31] <seb128> or make python-gnome-extra provides the other debian binaries
[09:31] <RAOF> But I presume that other packages will start growing dependencies on the split packages.  I think miro may have already.
[09:31]  * mvo grumbles and just edits the .ui xml with emacs
[09:32] <seb128> hey mvo ;-)
[09:32] <RAOF> seb128: Tempting.  Are there any downsides to that?
[09:32] <mvo> hey seb128
[09:32] <Riddell> mvo: it is qt4-designer
[09:32] <seb128> the provides are not versionned
[09:32] <seb128> so if any package uses a versionned depends that will not work, otherwise that should not be an issue no
[09:32] <Riddell> mvo: the package is qt4-designer, the binary is designer-qt4
[09:33] <mvo> Riddell: aha, outdated sources.list, thanks!
[09:34] <mvo> Riddell: should i merge your changes if they look good or do you have other things in the queue?
[09:34] <Riddell> mvo: go ahead
[09:34] <Riddell> mvo: oh well
[09:35] <Riddell> mvo: DistUpgradeViewKDE4.py could be renamed back to DistUpgradeViewKDE.py
[09:35] <mvo> Riddell: right
[09:35] <mvo> Riddell: I can take care of the integration, thanks a lot for doing the port!
[09:37] <mvo> Riddell: the new designer looks very nice, much better than the qt3 one
[09:47] <tseliot> pitti: where do you keep the extra_conf_options that you pass as an argument to xorg_driver.XorgDriverHandler in Jockey?
[10:04] <Mirv> mvo: do the new package description translations have (theoritically) everything merged from Debian's ddtp?
[10:04] <mvo> Mirv: yes
[10:05] <mvo> Mirv: they should, unless there is a bug in the script. the debian import is ~2-3 days old
[10:05] <Mirv> mvo: ok, that's great
[10:05] <Mirv> I have to try to check it. Some descriptions are different in Ubuntu but a good sample of some that have been recently translated in Debian would answer the question well enough.
[10:06] <mvo> Mirv: please do and let me know your findings
[10:18] <geser> soren: Hi, do you know why libipq_pic.a got dropped from iptables-dev in the last merge?
[10:26] <jc-denton> how does the network manager talk to the wlan driver
[10:26] <tkamppeter> Are there any plans to have Samba 3.2 in Intrepid?
[10:27] <geser> !info samba intrepid
[10:28] <geser> tkamppeter: samba 2:3.2.0-4ubuntu1 is in intrepid but depwaits on libtalloc-dev
[10:28] <jc-denton> does it use iwconfig?
[10:28] <jc-denton> wpa_supplicant
[10:28] <jc-denton>  /dev/somethign?
[10:28] <geser> tkamppeter: and talloc is in universe
[10:31] <tkamppeter> geser, thanks, so it is waiting for the approval of a MIR?
[10:33] <geser> tkamppeter: it might be also waiting for a MIR to get written
[10:36] <pitti> tseliot: in the concrete subclasses, such as NvidiaHandler
[10:37] <pitti> tseliot: data/handlers/nvidia.py or fglrx.py
[10:37] <pitti> tseliot: (in the ubuntu branch)
[10:39] <tseliot> ﻿pitti: ah, ok I was looking in the wrong directory. Thanks
[10:40] <tseliot> ﻿pitti: expect something new for xorg_driver.py soon ;)
[10:40] <pitti> tseliot: what are you working on?
[10:40] <pitti> tseliot: oooh, xkit?
[10:40] <pitti> yay
[10:40] <tseliot> pitti: xkit and some deeper logic
[10:40] <pitti> tseliot: could you work on that relative to the trunk branch, not ubuntu?
[10:41] <pitti> tseliot: a lot of xorg.conf scenarios have test cases already, and thus can be conveniently tested just with tests/run
[10:41] <pitti> tseliot: that should provide a good first conformance test for the x-kit switch
[10:41] <tseliot> pitti: ok
[10:42] <pitti> tseliot: (well, xorg_handler.py are identical in trunk and ubuntu, so it doesn't matter so much)
[10:42] <pitti> tseliot: many thanks!
[10:42]  * pitti goes offline again for yet more gdm debugging, bbl
[10:42] <tseliot> ﻿pitti: ok, my branch will be based on trunk then.
[10:43] <pitti> where's seb128?
[10:43]  * tseliot goes back to hack on Jockey
[10:48] <pitti> seb128: wb
[10:49] <seb128> pitti: good morning!
[11:59] <mpt> If an update is a "no change rebuild", why is Ubuntu offering it to me in the first place?
[12:00] <mpt> (e.g. today's Firefox updates)
[12:00] <Mithrandir> mpt: "no source change rebuild" is what is meant.
[12:00] <StevenK> mpt: Because it was to pick up a library soname change or similar.
[12:00] <StevenK> mpt: The binary packages will be different, the only source change was adding a changelog entry.
[12:00] <mpt> That would be more useful information
[12:01] <persia> mpt: More specicially, you need to have the update in order to use the new xul, which was a security fix.
[12:01] <mpt> "This update uses the latest version of <library name> which does <faster/better/stronger>"
[12:01] <persia> Well, we don't always know <faster/better/stronger> ...
[12:01] <StevenK> mpt: Usually, I will have changelog entries like, "No change rebuild for libgpmg1 -> libgpm2 transistion."
[12:01] <mpt> Otherwise, the only effect of showing the Changes in Update Manager will be to *discourage* people from installing it.
[12:02] <mpt> (Which I assume is not what we want.)
[12:02] <cody-somerville> \o\ Heya Everyone /o/
[12:10] <_Angelus_> guys
[12:10] <_Angelus_> will someday exist an ubuntu i686?
[12:10] <_Angelus_> :p
[12:12] <persia> _Angelus_: No.  There are support libraries for i686 in Ubuntu i386.  Alternately, lpia is close to i686.
[12:12] <_Angelus_> so there is no plan of creathing a whole i686 ubuntu for download?
[12:13] <pitti> _Angelus_: define what you understand as "i686 Ubuntu"?
[12:13] <pitti> _Angelus_: if you mean a variant that won't run on real Pentiums or VIAs, or whatever, then "most unlikely"
[12:13] <_Angelus_> every package compiled as i686 instead of i386
[12:14] <Mithrandir> _Angelus_: what is the problem you are trying to solve?
[12:14] <_Angelus_> like gentoo
[12:14] <pitti> why should we? our current compiler already optimizes instruction order for i686, and uses i486 command set (AFAIR; doko, please correct me)
[12:14] <_Angelus_> im not trying to solve problem, im asking because im curious and i wish  for a whole ubuntu compiled as i686 like arch and gentoo
[12:15] <Mithrandir> pitti: correct.
[12:15] <pitti> _Angelus_: we have kernel and libc6 optimized for 686, where it matters (well, a bit anyway)
[12:15] <_Angelus_> yeah i know
[12:15] <pitti> the rest hardly matters...
[12:15] <cjwatson> _Angelus_: the significant extra disk space requirement is not worth the miniscule performance difference (given that, as pitti says, we already tune for i686)
[12:15] <_Angelus_> but every program compiled as i686 would make a speed burst :p
[12:15] <laga> _Angelus_: can you prove that?
[12:15] <cjwatson> _Angelus_: no, actually, we strongly believe it wouldn't. Please feel free to produce benchmark figures if you disagree.
[12:15] <pitti> maybe some ultra-optimized math libraries, but those can still have special cases
[12:16] <cjwatson> and libraries can have variants built for particular processors quite easily
[12:16] <_Angelus_> well i can't really prove it , its a matter  ifyou belive it or not
[12:16] <jcristau> no it isn't
[12:16] <cjwatson> this is a matter of scientific fact
[12:16] <_Angelus_> i just felt my computer going alot faster when i changed grfrom kubuuntu to gentoo
[12:16] <cjwatson> changing distribution involves so many other variables, and you've picked just one? :)
[12:17] <cjwatson> also, there is a psychological effect there
[12:17] <_Angelus_> bot arch and gentoo where faster then kubuntu
[12:17] <_Angelus_> and both are i686
[12:17] <cjwatson> "I've spent all this time compiling software - it must be worthwhile"
[12:17] <cjwatson> anyway, the simple answer is no, we aren't going to produce an i686-optimised variant. Sorry.
[12:17] <_Angelus_> cjwatson: on arch you dont compile, its precompiled i686, and its still alot faster then 1386 at least on my pc
[12:18] <_Angelus_> ok
[12:18] <_Angelus_> ;p
[12:18] <doko> _Angelus_: you have to back your claims. which improvement in which application?
[12:18] <_Angelus_> doko: application opening alot fast, and things like that
[12:19] <_Angelus_> im not a geek so i can't really prove it with geek words, al i can say is what my eyes see
[12:19] <_Angelus_> in normal words
[12:19] <_Angelus_> so sorry if im not being specific
[12:19] <cjwatson> timing isn't a matter of geekness
[12:19] <Mithrandir> _Angelus_: you need to come up with measurements where you've just changed one variable, not everything else.
[12:19] <_Angelus_> dont get me wrong guys im not talking bad about ubuntu or something
[12:20] <_Angelus_> kubuntu is my favorite distro and iv been using it for a year and a half now
[12:20] <cjwatson> we understand, but you're asking for a change that we believe there is no justification for, and we are explaining what justifications would be needed in order to make a change of this enormous magnitude
[12:20] <_Angelus_> but i saw a speed up in programs when i changed tto genoo
[12:20] <cjwatson> it is NOT sufficient to simply point at another distribution and say that it subjectively runs faster
[12:21] <_Angelus_> cjwatson: then dont make a change, leave i386 and make i686 available too, aint that posible to have both version available ?
[12:21] <cjwatson> that would be a vast, enormous change
[12:21] <cjwatson> and require a huge amount of additional resources
[12:21] <stgraber> _Angelus_: that'd take twice the space on the mirrors and twice the testing efforts. Not something we can afford
[12:21] <_Angelus_> hmm
[12:21] <cjwatson> you don't have to believe me or understand me, it is simply a fact
[12:21] <_Angelus_> i see
[12:21] <mpt> We could make "i686" symlinks to the i386 versions. Then it would still "feel faster", without the need for extra disk space. :-)
[12:21] <Mithrandir> we did roughly that for lpia, and it took what?  Four months and a team of three-four people full time for that period?
[12:22] <Mithrandir> (plus maintenance cost)
[12:22] <_Angelus_> i see
[12:22] <_Angelus_> i think its possible dough for example for some to compile the whole kubuntu froom surce and compile i386
[12:22] <_Angelus_> right?
[12:22] <cjwatson> therefore, it is in fact much cheaper to identify why particular applications are running faster, and incorporate particular optimisations
[12:22] <_Angelus_> i mean *i686 sorry
[12:22] <cjwatson> it very likely has nothing to do with CPU optimisationss
[12:23] <_Angelus_> nah
[12:23] <cjwatson> somebody could do that, and then be disappointed when it made little difference, sure :)
[12:23] <_Angelus_> i see
[12:23] <cjwatson> I believe that somebody did in fact try it in the past, and presented benchmarks with very small percentage-point differences
[12:24] <cjwatson> though I don't have a reference to hand
[12:24] <stgraber> it's of course possible to rebuild the whole archive using i686, people are doing that for arm and some other archs IIRC but that'll take you days/weeks to have everything rebuilt
[12:24] <_Angelus_> but i think in future when i386 will not  be need anymoree because all pc's will be compatable with i686, then  i think ubuntu will change right?
[12:25] <cjwatson> forget i386; we actually build for i486 anyway
[12:25] <persia> _Angelus_: There are many computers being made today that are i586.
[12:25] <cjwatson> and we investigated this just recently and found that there was still a substantial pre-i686 requirement (e.g. LTSP thin clients)
[12:25] <stgraber> _Angelus_: I think that the current moev is to go 64bit
[12:25] <stgraber> *move
[12:26] <Mithrandir> stgraber: yeah, I think i386 will just move into the embedded space and amd64 will take over desktops and servers completely.
[12:26] <_Angelus_> hmm
[12:26] <Mithrandir> who'd want a desktop with less than 8G RAM anyway?
[12:28] <jdstrand> mpt: the firefox-3.0/xulrunner-1.9 update for -security was because firefox-3.0 and xulrunner-1.9 had a security fix that went into -updates that had to be rebuilt for people who only have -security enabled. Hence 'no change rebuild for security'.
[12:29] <_Angelus_> so kubuntu will move to 64bit and not to i686
[12:29] <_Angelus_> ?
[12:30] <stgraber> What I meant is that we already have x86_amd64 that's optimized for newer CPUs (at least I'd expect it to be), I don't think spliting i386 or limitating it to >=586 is a good idea.
[12:30] <jdstrand> mpt: I could have used '-v...', but then that would have been confusing for people (a lot more than just -security) that have -updates enabled, as they would have seen the same changelog text twice
[12:30] <_Angelus_> i understand
[12:30] <cjwatson> _Angelus_: we already supply a 64-bit version of Kubuntu
[12:30] <mpt> jdstrand, are you saying that people with both -updates and -security turned on would have received two updates with the same summary?
[12:30] <cjwatson> oh, stgraber said that
[12:31] <_Angelus_> btw
[12:31] <stgraber> _Angelus_: as cjwatson we have some hardware like thin clients that can't run anything >486 and having both 486 and 686 is not an option for space reason, testing reason, ... and all that for (as far as we know) no real speed improvment
[12:31] <jdstrand> mpt: it is a standard text that we use in these situations, but it can certainly be improved if warranted
[12:31] <jdstrand> mpt: I'm saying that if I used '-v<earlier version>' (which I purposely didn't), then yes
[12:31] <_Angelus_> why deos kubuntu only offer 1 64bit version? should there be an amd64 one and an ia64 one ?
[12:32] <stgraber> _Angelus_: ia64 is not a supported arch
[12:32] <_Angelus_> ah
[12:32] <norsetto> with regard to bugs like bug 252037, can any motu upload a fix or is the solely prerogative of backporters?
[12:32] <mpt> jdstrand, why would they have received two updates instead of one in the first place?
[12:32] <persia> stgraber: ia64 works fine.  No reason to deprecate it.
[12:32] <_Angelus_> so 64bit intel cpu's are not supported?
[12:32] <cjwatson> yes, they are
[12:33] <cjwatson> "amd64" is just the codename (because AMD designed the architecture) but it also supports Intel Xeon-class systems
[12:33] <cjwatson> ia64 is Itanium, which is not the same as the 64-bit Intel systems that most people in fact have.
[12:33] <_Angelus_> aint ia64 for intel 64bit cpus?
[12:33] <Mithrandir> cjwatson: more than Xeon, really.  Most desktop and laptop CPUs from Intel those days are 64-bit capable.
[12:33] <jdstrand> mpt: it went into -propsed for more widespread testing, then was mistakenly pocket copied to updates rather than rebuilt in -security. it linked against (and depended on) a newer version of pango that made it uninstallable for people with just -security enabled
[12:33] <cjwatson> _Angelus_: Itanium only, not things like Core 2. Please listen to what I said.
[12:34] <jdstrand> mpt: so we had to send it through -security too
[12:34] <_Angelus_> hmm i see
[12:34] <cjwatson> _Angelus_: Wikipedia should have a good summary if you want the complicated history
[12:34] <Mithrandir> ia64 systems need lots of cooling and are generally not something an end user would ever buy or interface directly with.
[12:34] <_Angelus_> so Core 2 uses the amd64 arch
[12:34] <cjwatson> _Angelus_: furthermore, we document quite clearly that our 64-bit CD images (for example) support Intel systems
[12:34] <cjwatson> yes.
[12:34] <_Angelus_> i  understand.
[12:35] <TheMuso> I think EM64T is the official Intel 64-bit name.
[12:35] <jdstrand> mpt: I say 'mistakenly' here, but it is no one's fault, as there wasn't a clear policy at the time. that has since been adjusted in SecurityUpdateProcedures
[12:35] <StevenK> TheMuso: Not any more. Now they're calling it Intel 64
[12:35] <Mithrandir> TheMuso: it is.  And the gnu arch string is x86_64.  And MS and Sun's name for the architecture is x64.
[12:35] <TheMuso> StevenK: haha great.
[12:36] <cjwatson> names are hopelessly marketing-infected. The solution is not to actually expect users to understand "amd64", but to display a description alongside or instead of the name wherever necessary
[12:36] <mpt> jdstrand, ah, I see. Perhaps it would be more understandable in cases like that for Update Manager to have the same full update description as before, but followed by "This replaces a previous update that did not install on some systems" or something like that.
[12:38] <jdstrand> mpt: had to disagree with that. :) however, with our new procedures, and me talking with all the archive admins personally, hopefully we'll avoid it completely in the future
[12:38] <mpt> ok
[12:38] <jdstrand> s/had/hard/
[13:45] <warp10> pitti: I just subscribed you to bug #252262, since you modified the piece of code involved in that bug in a past revision. I am not sure that one is actually a bug, BTW
[13:50] <pitti> warp10: replied, thanks
[14:15] <skymuss> hi
[14:23] <pitti> seb128, Riddell: any chance one of you could wave gdm-guest-session through source NEW? it's tiny, ubuntu specific, packaged by me, so I hope it won't take more than two minutes
[14:23] <seb128> pitti: looking
[14:24] <pitti> seb128: (might actually still take 2 minutes until it hits the quue)
[14:24] <pitti> seb128: merci
[14:24] <seb128> ok, grabbing coffee and looking to that next then
[14:24] <seb128> de rien
[14:42] <tseliot> pitti: is the "XorgDriverHandler.enabled()" method called when Jockey installs or uninstalls the driver or only in one of these cases?
[14:44] <pitti> tseliot:in both; (if you really mean enabled(), and not enable() )
[14:45] <tseliot> pitti: I mean enabled()
[14:45] <tseliot> pitti: ok, thanks
[14:48] <tseliot> ﻿pitti: oh, and enabled is called before enable() or disable(), right?
[15:00] <pitti> tseliot: yes
[15:00]  * pitti -> bbl
[15:05] <pitti> tseliot: it is called to check whether to enable or disable the driver, or if you specify --enable, whether it already is, and so on
[15:06] <pitti> tseliot: however, API-wise you sholdn't bet on any particular order; why do you want to?
[15:07] <tseliot> ﻿pitti: I was trying not to call the same method twice. Currently enabled() calls it to check the xorg.conf and this other method sets self.devices_to_check
[15:08] <tseliot> pitti: ﻿self.devices_to_check is a list
[15:09] <tseliot> pitti: otherwise I would have to call the other method in both enable() and disable()
[15:09] <pitti> tseliot: you should still do that  then
[15:10] <pitti> tseliot: you shouldn't parse xorg.conf twice; just do it once and then just work with the internal XKit object and modify its state
[15:10] <pitti> and just write() in enable()/disable()
[15:11] <tseliot> ﻿pitti: I don't parse the xorg.conf more than once. I'm talking about calling a quite useful method i.e. check_serverlayouts() twice
[15:13] <tseliot> ﻿pitti: I'll explain you everything as soon as it's complete.
[15:13] <tseliot> pitti: why is there no nvidia.py in data/handlers/ in trunk?
[15:31] <tseliot> pitti: furthermore is it really necessary to override enabled() in nvidia.py? Shouldn't it use the inherited method?
[15:34] <pitti> re
[15:34] <pitti> tseliot: doesn't sounds as if it would be too expensive to do so; mind you, that isn't called 10.000 times a second or so
[15:35] <pitti> tseliot: nvidia.py isn't a supported handler upstream, since it is ubuntu specific
[15:35] <pitti> tseliot: in trunk it is in examples/handlers/
[15:35] <tseliot> ﻿pitti: aah, I see
[15:37] <tseliot> ﻿pitti: I'll work on ﻿examples/handlers/nvidia.py and fglrx.py then
[15:40] <pitti> tseliot: indeed, with the latest trunk fixes, nvidia shouldn't need to overide enabled() any more
[15:41] <tseliot> ﻿pitti: yes, that's why I commented it out
[15:42] <tseliot> ﻿pitti: also, it would be nice if (in the future) you could add a "disable_modules" argument to the superclass
[15:42] <tseliot> so as to disable modules which are enabled by default
[15:43] <tseliot> such as "dri2"
[15:43] <tseliot> and to set something like Disable "dri2" in the Module section of the xorg.conf
[15:44] <pitti> tseliot: right, so far I just have a parameter for modules which shuold be removed
[15:44] <pitti> I hadn't implicitly loaded modules in mind when I wrote that
[15:45] <tseliot> ﻿pitti: adding that argument wouldn't break anything, I guess
[15:45] <tseliot> ﻿if you want, I can deal with it
[15:45] <tseliot> when my changes are stable
[15:50] <pitti> tseliot: if you feel like it, sure
[15:50] <geser> mvo: is it a bug or a feature that "apt-cache unmet -i " also lists Breaks:?
[15:50] <pitti> tseliot: just remember, every new feature needs a corresponding test case :)
[15:50] <tseliot> pitti: yes, of course ;)
[15:53] <mvo> geser: sounds like a bug to me, let me check the bzr history
[15:56] <tseliot> pitti: would it be possible to add a dependency on pciutils to jockey?
[15:56]  * tseliot hides
[16:00] <tseliot> pitti: seriously, I would need it to do hardware detection. Or do you do hardware detection in a way which is different from using lspci?
[16:06] <NCommander> seb128, morning
[16:10] <seb128> hello NCommander
[16:10] <NCommander> seb128, someone already beat me to glibmm :-P
[16:10] <seb128> NCommander: oh?
[16:10] <NCommander> The latest upstream I could find was 2.16.4
[16:10] <NCommander> Which is what's in intrepid
[16:10] <seb128> NCommander: http://download.gnome.org/sources/glibmm/2.17/glibmm-2.17.1.tar.gz
[16:11] <NCommander> It says 2.16 is stable
[16:11] <NCommander> That's under unstable
[16:11] <seb128> yes, but we track glib 2.17
[16:11] <NCommander> Oh
[16:11] <seb128> and GNOME 2.23
[16:11]  * NCommander inserts hit foot in his mouth then ;-)
[16:11] <seb128> intrepid will have GNOME 2.24
[16:11] <seb128> so we package unstable versions along the way until the stable one
[16:12] <NCommander> That makes sense
[16:12]  * NCommander learns more about the desktop team ;-)
[16:12] <NCommander> ls
[16:12] <NCommander> whoops
[16:12] <StevenK> total 0
[16:18] <Keybuk> ?!
[16:19] <Keybuk> how do I have a version of python-2.5 installed that's not in the archive?
[16:20] <Keybuk> seems it came from hardy-proposed, but then vanished
[16:24] <NCommander> seb128, I'm now testing out glibmm2.17; I noted in the changelog the reason we were tracking an unstable release
[16:25] <seb128> NCommander: ok good
[16:29] <pitti> tseliot: pciutils? no, why? IMHO we should read everything from /sys
[16:32] <tseliot> ﻿pitti: I use "lspci" so as to look it up in /usr/share/xserver-xorg/pci/ if no driver is specified in the xorg.conf. In this way I can see what driver Xorg assigned.
[16:33] <tseliot> pitti: and by Xorg I mean Xorg's autodetection
[16:33] <jcristau> tseliot: what happens when /usr/share/xserver-xorg/pci goes away?
[16:34] <tseliot> ﻿jcristau: we replace it with whatever is available
[16:36] <tseliot> ﻿jcristau: but if these files are available we make use of them.
[16:36] <tseliot> a simple "if" block will be enough
[16:36] <jcristau> tseliot: as long as you don't break when they're not, that's good enough for me :)
[16:37] <jcristau> (because 'whatever is available' might well be 'nothing')
[16:38] <tseliot> ﻿jcristau: yes, I know
[16:42] <tseliot> pitti: never mind, I misread the custom handler. Ignore my request.
[17:04] <vadi2> Is there a channel for "﻿application development on Ubuntu" if this isn't it?
[17:06] <ion_> It’s just application development, “on Ubuntu” is irrelevant.
[17:08] <vadi2> Is that a no or a yes?
[17:09] <vadi2> I'd like to find out the proper way of adding a program that requires root privileges to startup.
[17:09] <vadi2> (In ubuntu)
[17:09] <Mithrandir> vadi2: add an init script
[17:10] <ion_> mithrandir: Or an Upstart job.
[17:10] <Mithrandir> that's also an option.
[17:10] <vadi2> Great, thanks. I'll look into that.
[17:10] <rubikcube> hello, I need some help concerning building a working initrd (or so I think).  How can I tell it which modules to load when booting (specifically pata_via)?
[17:11] <cjwatson> rubikcube: add module names to /etc/initramfs-tools/modules; run update-initramfs
[17:11] <cjwatson> (update-initramfs -u, probably)
[17:12] <rubikcube> well, that's what dpkg-reconfigure linux-image-foo should do already, right?
[17:12] <cjwatson> sure, if you want the long way round
[17:13] <cjwatson> that's really only an incidental side-effect. dpkg-reconfigure means "ask me debconf questions again".
[17:14] <rubikcube> anyway, that didn't work :/ I'm trying to solve https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/32123 or something very similar
[17:16] <rubikcube> but if that's all it should take, I'll just retry it :-)
[17:19] <vadi2> Just to confirm... does upstart work for GUI applications?
[17:20] <cjwatson> vadi2: I think you need to be a bit more specific
[17:20] <vadi2> Can it launch a gtk application?
[17:21] <vadi2> The issue that I have is that I'd like to have an application auto-start, but it requries root privileges. If I copy the .desktop to ﻿.config/autostart, it'll start - but it asks the user for root password (right after he already put it in once for login)
[17:27] <bdmurray> pitti: I've found an apport-package report regarding a non-ubuntu package.  Should I open an apport task for it?
[17:27] <cjwatson> upstart doesn't know how to talk to your X display, so is inappropriate for graphical applications
[17:27] <cjwatson> vadi2: remember that a normal gksudo-ed application would do the same thing ...
[17:27] <jcristau> vadi2: you don't put in the root password for login
[17:27] <cjwatson> I think he meant the sudo password, which == the user password
[17:28] <vadi2> Yes.
[17:28] <jcristau> ah. yeah, ignore me :)
[17:28] <vadi2> I find it a bit silly to bug the user for the same password twice. Is there a set policy on this though?
[17:28] <cjwatson> this is a normal property of the Ubuntu desktop. Elevating to root privileges requires additional confirmation.
[17:28] <cjwatson> (otherwise you might as well just run the whole thing as root)
[17:29] <cronholio> hi guys, launchpad user 10111 and i want to work on https://blueprints.launchpad.net/ubuntu/+spec/webcam - we wrote emails to the creator of the blueprint as well as the mentor withiout getting a reply - any ideas or anyone that would mentor us?
[17:29] <vadi2> ﻿cjwatson: alright, thank you.
[17:29] <cjwatson> vadi2: your options include: rewrite application to not require root, or to use PolicyKit, or similar; use a setuid helper to launch the application (and figure out how to make that safe); accept the current situation
[17:30] <vadi2> We were looking into PolicyKit actually before. That can be used not to require the password?
[17:30] <cjwatson> cronholio: that blueprint was created inappropriately by a user who was trying to use it to make a wishlist request. I don't think there's any need for you to treat it as blocking you in any way if you want to work on it
[17:30] <cjwatson> vadi2: it would provide a different experience. Compare e.g. the GNOME system tools
[17:32] <cronholio> cjwatson, yeah but the problem is we have no experience in working for ubuntu, though we have programming experience, and we need to know if the app/feaure is still needed and someone that can provide minimal mentoring to help us integrate the app in ubuntu
[17:32] <cjwatson> if you can't even tell whether it's needed, are you sure you're the best person to work on it? ;-)
[17:32] <vadi2> cjwatson: Okay, thank you for your input!
[17:32] <cjwatson> (no offence) the very first step ought to be caring about it yourself
[17:33] <cjwatson> cronholio: remember, *anyone* can create a blueprint. That wasn't created by anyone on the Ubuntu development team
[17:33] <cronholio> cjwatson: well we both have working webcams but i guess some people do not :-)
[17:33] <vadi2> We do require root to even start (as we can't get the info we need without root). So... looks like password it is.
[17:34] <cjwatson> it's going to be very difficult for you to work on something that doesn't affect you personally. Some experienced people can do that but it takes a lot of work
[17:34] <mvo> vadi2: out of curiosty, what does this app do?
[17:35] <cjwatson> cronholio: it would be better to have made some fairly substantial progress on your own before looking for mentoring, I think; you ought to decide what you're going to do and lay out a design
[17:35] <cjwatson> then you can ask for design review; not many people are going to step up for mentoring in a vacuum, though
[17:35] <vadi2> mvo: manage ufw with buttons. While really, it in no way needs to be auto-started, people still have the idea that if it's not running, the firewall isn't active. And there are some very dangerous "tips" on the web now on how to make it autostart. So we want to implement a "proper" way before these tips get too popular.
[17:36] <cronholio> cjwatson: ok thanks, probably that's a good idea. i checked and found that these webcam drivers are not installed by default so probably this app would make sense to have
[17:37] <cjwatson> cronholio: consider whether they should simply be installed by default rather than creating a complex infrastructure to download them on the fly
[17:37] <mvo> vadi2: if all you need is a read-only view you may write a dbus backend that runs as root and is able to read the values, then you can use policykit to restrict the read to certain groups (e.g. admin). for the enable/disable stuff you can use the same mechanism, just add a confirmation step (like in gnome-system-tools)
[17:37] <cjwatson> cronholio: if the space increase is not too great, that would be a much more normal Ubuntu approach
[17:37] <cronholio> cjwatson: will do, thx again
[17:38] <vadi2> mvo: Thank you! That sounds great. We'll look into it.
[17:39] <ion_> benc: http://heh.fi/tmp/grub_0.97-29ubuntu32.debdiff
[17:43] <johanbr> cronholio: I'm not sure exactly what the blueprint is asking for. The gspca kernel module is already included, and Cheese can record video (although not upload it to youtube).
[17:44] <rubikcube> could someone please tell me if the possible contents of /etc/modprobe.d/blacklist.local are made by ubuntu or if I made them myself?
[17:45] <cjwatson> we don't ship blacklist.local; it's, well, local :)
[17:45] <rubikcube> that's why I was wondering :-)
[17:45] <rubikcube> but I couldn't remember editing it either ;-)
[17:47] <rubikcube> And I was wondering why those modules weren't loaded
[17:49] <cronholio> johanbr, the blueprint is asking for an app that downloads the webcam driver according to the usb device id
[17:49] <cronholio> if the gspca module supports all these then we don't need it at all
[17:50] <johanbr> cronholio: Downloads what, exactly?
[17:50] <cronholio> johanbr, the drivers from http://mxhaard.free.fr/spca5xx.html
[17:51] <johanbr> Again, the gspca driver is a kernel module and already included in the standard ubuntu kernel.
[17:52] <cronholio> johanbr, ok thx, i guess it is not needed then, i will update the info in the blueprint
[18:21] <slangasek> calc: is OOo happier now with libltdl -dev provides?
[18:29] <calc> slangasek: it seems to build ok, the problem was that some of its build-depends required the provides
[18:29]  * slangasek nods
[19:23] <Riddell> tkamppeter: do you know that hal-cups-utils can't be installed?
[19:24] <Riddell> python-usb needs a main inclusion report
[19:25] <tkamppeter> Riddell, thanks for telling me. I will post it. The package looks small for me, should not break the CDs.
[19:27] <BenC> ion_: Uploaded fixed grub, thanks
[19:28] <ion_> benc: Thanks
[19:45] <pitti> bdmurray: please, that's worth investigating; thanks!
[19:48] <bdmurray> pitti: its bug 252734
[19:55] <alex-weej> question
[19:55] <alex-weej> the PC speaker in a macbook pro seems to not be connected
[19:55] <alex-weej> yet ALSA is now exposing a device for it
[19:56] <alex-weej> this needs a fix in... HAL?
[19:57] <alex-weej> it's clearly on the chipset, just not used by the builders
[20:09] <slangasek> fta: is anything happening with bug #218534 for seamonkey?  this has been sitting at the top of the bug list for intrepid for some time now
[20:15] <Keybuk> dear Intrepid,
[20:15] <Keybuk> X server
[20:15] <Keybuk> Useful
[20:15] <Keybuk> Love, Keybuk
[20:17] <BenC> Dear Intrepid,
[20:17] <BenC> Shutdown != Logout
[20:17] <Keybuk> BenC: I can't fix that bug, because the kernel doesn't let me have an X server to start with <g>
[20:17] <ion_> Dear Interpid,
[20:17] <ion_> Please make me some coffee.
[20:18] <Keybuk> BenC: oh, and sound doesn't work either
[20:18] <Keybuk> so the latest kernel has no sound or graphics
[20:18] <Keybuk> keyboard seems to work though ;)
[20:18] <BenC> Keybuk: I thought you knew we enabled CONFIG_KERNEL_REQUIRES_STROKING...you have to tell it nice things for it to work
[20:19] <BenC> Using a goofy baby voice is optional, but reported to help
[20:19] <Keybuk> I tried that
[20:19] <Keybuk> I think that it hates Intel and it hates Dell
[20:19] <mkrufky> ...i havent logged into Launchpad for a few days.... now i did, and the Belmont stuff is all screwed up
[20:19] <mkrufky> i cant find my bugs anymore
[20:20] <mkrufky> and i have no idea how to navigate
[20:20] <mkrufky> wth happened here?
[20:20] <mkrufky> oh, oops... my bad ...
[20:20] <mkrufky> its funny how i find the answer the moment AFTER i complain
[20:24] <slangasek> seb128: is bug #210468 still applicable to intrepid?
[20:24] <seb128> slangasek: yes
[20:24] <slangasek> darn
[20:24] <slangasek> :)
[20:24] <seb128> why?
[20:24] <slangasek> because it's on my List
[20:25] <slangasek> and I was hoping the fix was in intrepid since it was an SRU :)
[20:29] <seb128> slangasek: fix uploaded to intrepid now
[20:30] <calc> OOo is failing in weird ways on me :-\
[20:30]  * calc hopes to have it figured out and uploaded (to ppa) by the end of the night
[20:39] <slangasek> seb128: cheers :)
[20:54] <hachi> morning, this may be a bit offtopic, but in the last week nobody on #ubuntu has had a clue... I'm trying to find how you can specify the filename of the filesystem for casper. I've been reading the startup scripts in the initramfs and just can't make heads or tails of it.
[20:56] <hachi> ahh, forgot the question part. Do any of you happen to know what the options may be, or where this might be documented?
[20:57] <tormod> hachi: documentation for casper? lol
[20:58] <hachi> well, on the upside I finally know that there is no documentation
[20:58] <hachi> though you could have told me without laughing at me
[20:59] <tormod> hachi: :) maybe we are less off-topic in #ubuntu-installer
[21:47] <pitti> Keybuk, BenC: FYI, I updated bug 253076 with my experiences, since you subscribed me
[21:52] <Keybuk> cool
[21:54] <ScottK> pitti: Does your revised regex for ubuntu.com addresses in dpkg allow kubuntu.org addresses?
[22:03] <asac> jdstrand, did you respin ffox 3?
[22:04] <asac> jdong, why?
[22:04] <jdstrand> asac: yes, had too-- the -updates packages pulled in pango that was only in -updates, so it was uninstallable in -security
[22:04] <asac> err, jdstrand
[22:04] <asac> hmm
[22:05] <jdstrand> asac: no change rebuild
[22:05] <jdstrand> (just bumped the version and ran through dak)
[22:05] <asac> yeah. someone complains about font regressions now
[22:05] <asac> jdstrand, can you commit that change to bzr?
[22:05] <asac> e.g. the changelog
[22:06] <jdstrand> asac: sure, can you point me to it?
[22:06] <asac> jdstrand, its in debian/control
[22:06] <asac> ;)
[22:06] <jdstrand> oh, duh
[22:06] <asac> should be lp:~mozillateam/firefox/firefox-3.0.hardy
[22:06] <asac> most likely not in control :-D
[22:07] <asac> jdstrand, let me add you to mozteam then
[22:07] <jdstrand> asac: I had to do the same with xulrunner-1.9
[22:08] <asac> jdstrand, ok. whats your lp id?
[22:08] <jdstrand> asac: jdstrand
[22:08] <asac> jdstrand, xulrunner is lp:~mozillateam/xulrunner/xulrunner-1.9.hardy
[22:08] <asac> ok have to move the conference room
[22:08] <jdstrand> asac: ok
[22:08] <asac> jdstrand, thanks a lot
[22:09] <jdstrand> asac: np
[22:11] <jdstrand> asac: this ff3 update highlighted a number of issues that we can improve on in the future. I have updates SecurityUpdateProcedures and talked to all the archive admins about not pocket copying from -poposed to -updates a package that ultimately needs to go to -security
[22:12] <jdstrand> asac: however, you mentioning the font regression when built against released pango illustrates that the PPA builds need to have -udpdates disabled as well
[22:13] <jdstrand> asac: (in case you didn't know or infer from what happened, people are supposed to be able to get all -security updates without having -updates enabled, therefore the buildds can't have -updates enabled either for anything in -security)
[22:14] <jdstrand> asac: security-in-soyuz will help with all of this, btw
[22:23] <bondolo> hello, how do I make a launchpad bug depend upon another bug? (I'd like to make 154038 and 238977 depend upon 251369)
[22:23] <totopalma> hello
[22:24] <LaserJock> bondolo: I don't think you can, but you can link to other bugs by just doing "bug #251369" in the description/comment
[22:25] <totopalma> Riddell, can you please take a look at bug #39383 ?
[22:26] <cprov> hi guys, do you know from where synaptic downloads the so-called "changelog" information ?
[22:27] <LaserJock> cprov: changelogs.ubuntu.com perhaps?
[22:28] <cprov> LaserJock: yes, good. Do you know how it's built ?
[22:28] <LaserJock> cprov: my guess is from the archive
[22:29] <LaserJock> extracting perhaps from the source package
[22:29] <cprov> LaserJock: right, some apt-ftparchive spell on top of a.u.c
[22:30] <LaserJock> ah, it looks like it's actually extracting from the .debs
[22:32] <LaserJock> at least the .copyrights are per-.deb
[23:34] <emgent> evening
[23:36]  * ion_ ♥ https://wiki.ubuntu.com/DesktopTeam/Specs/Intrepid/GuestAccount
[23:39] <__keybuk> I've been thinking about InitKit again over the last few days
[23:39] <__keybuk> oops, ww
[23:40] <__keybuk> ion_: your message here confused me ;)
[23:40] <ion_> :-)
[23:44] <calc> did mv used to not return an error code if the file was non-existant in hardy timeframe?
[23:45] <slangasek> only if it was buggy..
[23:46] <calc> hmm
[23:46] <calc> i'm getting a failure that should have failed in the past, trying to look at a buildd log now to see why it didn't fail before
[23:49] <calc> oh hmm the file i thought didn't exist actually should so the problem is apparently it doesn't now
[23:55] <calc> slangasek: if i just add a line in rules: ls foo   it will show the dir contents in the build log, right?
[23:56] <slangasek> yes
[23:56] <calc> ok