[00:02] asac: some people (myself included) find it much more convenient and less prone to human error [00:03] I don't use it for performance advantages so have no idea whether it provides those [00:03] I don't find that it has any performance disadvantages, and wouldn't expect anything either way really [00:05] human error == forgetting to push? [00:08] 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] hehe [00:09] 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] cjwatson, hmm. good point. what happens if you commit and you have non-head on your disk? [00:10] in a checkout, it refuses and tells you to update [00:10] right. does it smart merging then? [00:11] 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] it's just the same as pulling into a modified working tree [00:11] it'll do a three-way merge if possible and leave you conflicts if it fails [00:13] for a moment i really forgot that you cant have more than one uncommitted change ;) [00:18] mathiaz: ah, I see you've been tracking the changes in the openldap package svn, since you patch applies cleanly... thank you :) [00:22] slangasek: bzr merge FTW [00:22] indeed :) [00:23] 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] slangasek: I don't have a public branch [00:24] slangasek: but I could push one to LP [00:28] that would be nice, then the bzr-heads can get the whole revision history in the tree :) [00:29] slangasek: lp:~mathiaz/openldap/debian-cnconfig [00:29] wooho [00:29] o [00:43] mathiaz: is this a missing merge?: [00:43] - if dpkg --compare-versions "$OLD_VERSION" lt-nl 2.4.7; then [00:43] + if dpkg --compare-versions "$OLD_VERSION" le-nl 2.3.30-6; then [00:44] vorian: hrm, the lemonpos package in NEW appears to be empty. [00:48] 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] slangasek: let me take another look at it [00:50] kees: you can ask for it to be blacklisted preemptively, sure [00:50] kees: you can also comment on the ITP :) [00:50] slangasek: I would like that, yes. standard ubuntu-archive bug? [00:50] kees: yes [00:50] slangasek: not that I know of - It was just to keep the functions to handle a db upgrade around [00:51] slangasek: upgrading from etch and hardy doesn't involve a db transition [00:51] mathiaz: hrm, then where did that line come from in the first place :) [00:52] slangasek: IIRC it comes from dapper -> hardy support [00:52] ah [00:52] slangasek: jmm is all over the ITP already, I just wanted to block it Ubuntu too. :) [00:52] mathiaz: er, that doesn't make sense to me either [00:52] mathiaz: hang on, will investigate [00:52] kees: \o/ [00:52] slangasek: upgrading from dapper (and sarge) required ldbm conversion [00:53] 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] slangasek: that function was used to handle the ldbm -> db transition [00:54] ... er, unnecessary redumps on etch->lenny [00:54] slangasek: yes [00:56] slangasek: as of now, this code won't be called in ubuntu (hardy -> ..) and debian ( etch -> lenny) [00:56] * slangasek nods [00:57] slangasek: however the package can be configured to dump the ldap tree to ldif on every upgrade [00:57] slangasek: so some of the functions need to be kept around [00:57] yes, I'm not disputing that [00:57] I was just trying to figure out why the version number used in the check is different in your tree [00:59] mathiaz: we have a changelog entry here of "- need to dump and reload databases again for the upgrade from 2.3.39." [01:00] no other documentation, but apparently I was convinced of that in December [01:02] mathiaz: indexing issue; http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/2007-December/001819.html [01:02] (at a minimum) [01:03] slangasek: right - so it seems that 2.4.7 should be kept [01:04] * slangasek nods [01:09] ogasawara: can you look at 204423? Since it results in a system reboot it sounds like probably a kernel issue [01:16] pitti: https://launchpad.net/~we-love-pitti big lol! [01:16] :-D [01:16] * slangasek squints at jbossas4. How does a jar have a circular build-dependency? [01:52] ugh several packages need updating for the new libtool still [01:53] 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] calc: I am having to relibtoolize pulseaudio as well, and its getting slightly annoying. [01:59] calc: ITYM "libtool needs fixing to provide libltdl3-dev" [01:59] slangasek: there lis libltdl7 [01:59] yes, I'm aware [01:59] I'm trying to make use of that instead. [01:59] by provide I mean a literal Provides: [01:59] ah ok. [02:00] slangasek: oh is that what needs to be done? then yea someone needs to fix that asap [02:00] slangasek: should i just upload a new version with just that one change? [02:01] calc: well, Keybuk didn't raise any substantive objections, so yes, that's the better way about it [02:01] calc: that would be fine, I think [02:01] ok [02:01] Keybuk: ping (sure you are awake at 4am right?) ;-) [02:01] er 2am [02:01] slangasek: oh was this already discussed elsewhere? [02:01] calc: only here, and not at any great length :) [02:02] 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] calc: he punted on the question [02:02] ok [02:02] well it can be backed out later if needed i'll upload it here in a few min [02:02] I wonder whether packages will still need relibtoolizing then... [02:03] Because if not, I am willing to wait for that change. [02:03] maybe i should fix it up locally see if it helps ooo to build and then decide whether to upload it, heh [02:05] calc: it should be done anyway; if you prefer, I can do the libtool upload here [02:05] TheMuso: libltdl has very little to do with libtoolizing [02:05] slangasek: ok go ahead :) [02:05] slangasek: Hrm ok. [02:06] i'll make the change locally and verify it works ok for OOo [02:06] but it will take several hours to build OOo [02:08] 0 upgraded, 122 newly installed, 0 to remove and 2 not upgraded. [02:08] build-deps ftw [02:08] does apt-get build-dep follow recommends by default now? [02:08] that would be bad [02:09] why does libtool depend on openjdk [02:10] "texi2html texinfo gfortran gcj automake autoconf quilt" - explodes into the world [02:10] * slangasek lets pam and libtool battle for bandwidth [02:11] approx is great at least for repeated use [02:11] of course you still have to wait the first time you have to pull the debs [02:15] I’m using a generic HTTP proxy, polipo to be accurate. Haven’t bothered to use a separate apt cacher. [02:16] 136MB build-depends for libtool (ouch) [02:16] i need better broadband [02:18] Well the change to libltdl7 for pulse means that symbols cannot e found when building, so I'm digging into that. [02:18] So even if libltdl3 was a provides, it may still break things. [02:20] what are the names of the missing symbols? [02:22] slangasek: There is only one that I can see so far, lt_preloaded_symbols [02:22] hmm [02:22] well, that's not a symbol name present in libltdl3 either [02:22] so it's possible that this was a macro in the old version, but is now deprecated [02:22] No I think it actually gets generated by the libtool bits for the package. [02:23] the scripts rather. [02:24] 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] heh [02:29] hmm only 11m6s but it seemed longer than that [02:32] is this right: Provides: libltdl3-dev [02:33] 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] libgphoto2-2-dev: Depends: libltdl3-dev but it is not installable [02:33] that's right; I don't know what issue you're running into [02:34] Does libgphoto2-2-dev have a versioned dep on libltdl3-dev? [02:34] no [02:34] no [02:35] 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] The version of libltdl7-dev I have here doesn't have Provides [02:37] StevenK: i hacked a local copy [02:37] Why does the soname need to be in the -dev package name? :-/ [02:37] http://pastebin.ubuntu.com/31539/ [02:41] StevenK: doesn't [02:41] shouldn't be [02:41] * StevenK gets tempted to fix it. [02:42] to make things even more incompatible with the archive? :) [02:42] slangasek: Well, if the new libltdl-dev Provides: both libltdl7-dev and libltdl3-dev? [02:43] sure; except Debian hasn't done that, so if packages come along with versioned deps on libltdl7-dev, hilarity ensues [02:45] 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] StevenK: yea i installed it directly [02:45] calc: Don't do that. :-) [02:46] huh? [02:46] apt doesn't try to install packages that are already installed [02:46] apt doesn't look at what is installed on your system? [02:46] (or complain about being unable to do so) [02:46] asac: no, that's currently not possible [02:47] asac: (meaning it's not possible to have a graceful fallback if you redefine pcm.default to have a different type) [02:48] StevenK: why isn't that a bug in apt? [02:48] StevenK: shouldn't it be looking at what is on the system to know if it needs to download something? [02:49] 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] calc: it's not a bug in apt because StevenK's comment has no correspondence to reality ;) [02:50] ok [02:50] unless what you did was install libltdl7-dev without *also* installing libltdl7, in which case apt might choose removal first [02:50] Try it? It will either prove me right or wrong [02:51] slangasek: well i rebuilt it without bothering to change the version number [02:51] then just installed the -dev package (the non dev was already installed) [02:52] crimsun: So what is the use of your changes then? [02:52] crimsun: As XFCE/KDE don't use pulse. [02:53] TheMuso: I was asked to draft a solution that doesn't involve a system-wide asoundrc [02:53] 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] maybe so [02:53] TheMuso: I haven't finished hacking alsa-lib to fallback sanely if another type is used [02:53] And therefore doesn't "see" the Provides [02:53] crimsun: Fair enough, but your changes are merged anyway. [02:54] 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] i'll rebuild it with a bumped version number and see if it helps [02:54] 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] 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] StevenK: just get Keybuk to apply your change to Debian ;-) [02:59] 2.2.2-1 is in experimental, and 2.2.4-0ubuntu1 is in Intrepid [03:00] calc: Keybuk seems an unlikely person to do that, since he's not a DD? [03:00] (nor the libtool package maintainer in Debian) [03:01] It's Kurt now [03:04] slangasek: oh he's no longer a DD? [03:04] * calc didn't realize he retired, heh [03:06] years ago [03:06] 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] heh, ok [03:07] * StevenK wins [03:09] so apt is stupid (my opinion of course) ;-) [03:56] is there a tool that can fixup the numbers in a diff? [03:56] The numbers? [03:57] eg @@ -3,107 +3,114 @@ [03:57] rediff (1) - fix offsets and counts of a hand-edited diff [03:57] ok === gaurdro__ is now known as gaurdro === gaurdro is now known as guardro [06:45] Good morning [06:45] pitti! [06:47] emgent: *cough* how embarassing... [06:47] it's a Hobbbbbbbsee! [06:48] * StevenK waves to pitti [06:48] * pitti sends a bunch of cookies to StevenK [06:49] :-) [06:50] * Mithrandir grumbles. [06:52] * pitti gives some to Mithrandir, too [06:52] hey Tollef, how are you? [06:56] feeling grumbly today. A bit too early and moving is an interesting exercise. [06:57] Mithrandir: oh, different city, or just within? [06:57] pitti: it is! [06:57] * Hobbsee freezes [06:58] * pitti started early to still have some hours with moderate temperature [06:58] same city, but a semidetached house (I think that's the term) rather than a flat. [06:58] ah, nice; sounds like an upgrade :) [06:58] absolutely. It's just that moving is a bit of work with loads of planning and packing. [06:58] pitti: Send the "hot" weather here, I'd prefer it to 13 degrees [06:59] 13°C sounds lovely. [06:59] but then, aircondition is also lovely. [07:04] * pitti doesn't like AC [07:58] Who's syncing Conduit? [07:59] And why aren't they testing that it's installable first? [08:04] RAOF: Changed-By: James Westby [08:05] plus addressing in a changed by? [08:05] pwnguin: Thats how it appears in mutt/gnome-terminal. [08:06] In particular, conduit depends on python-gtkmozembed, which is built by debian's gnome-python-extras package, but not ours. [08:16] So, I'm not sure if the correct fix is to merge in gnome-python-extras from Debian or to change conduit. [08:19] Or, alternatively, split out python-gtkmozembed packages from our gnome-python-extras without merging from Debian, I suppose. [08:30] Could a main sponsor please look at https://bugs.edge.launchpad.net/f-spot/+bug/250047 ? Or is main frozen? [08:30] Launchpad bug 250047 in f-spot "f-spot FTBFS in intrepid due to deprecated symbols in libeog" [Wishlist,Confirmed] [08:34] Sikon: Main is not currently frozen no. See topic. [08:35] Why is it Wishlist? === giskard_ is now known as giskard [08:37] Sikon: That's a really odd patch description, too. In what way are you adding missing headers? [08:38] ah, indeed, I should fix the patch description [08:40] reuploaded [09:20] Does anyone here know of any reason why gnome-python-extras hasn't been merged from Debian since Gutsy? [09:20] 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] seb128: Aha! There you are. You seem to have touched gnome-python-extras the most: ^^^ [09:24] 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] seb128: Thanks. Given the 'not trivial', I might file that one away for the weekend. [09:25] You don't think python-gtkmozembed is a good idea? [09:25] Or python-eggtraywhatever it is? [09:26] I'm just not sure there is a real need to split those [09:26] but since debian did it now, we can as well reduce the delta [09:27] Right. [09:27] the fun part will be to do -dbg variants for all of those [09:27] Oh, right. Python. I don't just get dbgsym for free. [09:28] well, ideally those python-dbg should would have been sent to debian some cycles ago and we could just sync now [09:28] but looks like doko have been too busy to send his changes and nobody else picked up on the job either [09:29] Oh, well. A weekend of fun, I bet :). [09:29] btw there is no need to do this merge to have conduit installable [09:29] True. [09:29] Riddell: hi, thanks for your kde4 stuff, what is the package name for the qt4 designer? qt4-designer seems to be gone? [09:30] so why did you said it'll make conduit installable again? [09:30] But other packages will start to move to the new package split,. [09:30] the issue is just a typo which is fixed in -3 that we should sync when it's available [09:30] Because it will? conduit currently depends on python-gtkmozembed [09:30] And that typo, yeah :) [09:30] well, we can easily change the conduit depends too [09:31] Yes. [09:31] or make python-gnome-extra provides the other debian binaries [09:31] 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] hey mvo ;-) [09:32] seb128: Tempting. Are there any downsides to that? [09:32] hey seb128 [09:32] mvo: it is qt4-designer [09:32] the provides are not versionned [09:32] so if any package uses a versionned depends that will not work, otherwise that should not be an issue no [09:32] mvo: the package is qt4-designer, the binary is designer-qt4 [09:33] Riddell: aha, outdated sources.list, thanks! [09:34] Riddell: should i merge your changes if they look good or do you have other things in the queue? [09:34] mvo: go ahead [09:34] mvo: oh well [09:35] mvo: DistUpgradeViewKDE4.py could be renamed back to DistUpgradeViewKDE.py [09:35] Riddell: right [09:35] Riddell: I can take care of the integration, thanks a lot for doing the port! [09:37] Riddell: the new designer looks very nice, much better than the qt3 one [09:47] pitti: where do you keep the extra_conf_options that you pass as an argument to xorg_driver.XorgDriverHandler in Jockey? [10:04] mvo: do the new package description translations have (theoritically) everything merged from Debian's ddtp? [10:04] Mirv: yes [10:05] Mirv: they should, unless there is a bug in the script. the debian import is ~2-3 days old [10:05] mvo: ok, that's great [10:05] 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] Mirv: please do and let me know your findings [10:18] soren: Hi, do you know why libipq_pic.a got dropped from iptables-dev in the last merge? [10:26] how does the network manager talk to the wlan driver [10:26] Are there any plans to have Samba 3.2 in Intrepid? [10:27] !info samba intrepid [10:27] samba (source: samba): a LanManager-like file and printer server for Unix. In component main, is optional. Version 2:3.0.30-2ubuntu3 (intrepid), package size 3795 kB, installed size 9392 kB [10:28] tkamppeter: samba 2:3.2.0-4ubuntu1 is in intrepid but depwaits on libtalloc-dev [10:28] does it use iwconfig? [10:28] wpa_supplicant [10:28] /dev/somethign? [10:28] tkamppeter: and talloc is in universe [10:31] geser, thanks, so it is waiting for the approval of a MIR? [10:33] tkamppeter: it might be also waiting for a MIR to get written [10:36] tseliot: in the concrete subclasses, such as NvidiaHandler [10:37] tseliot: data/handlers/nvidia.py or fglrx.py [10:37] tseliot: (in the ubuntu branch) [10:39] pitti: ah, ok I was looking in the wrong directory. Thanks [10:40] pitti: expect something new for xorg_driver.py soon ;) [10:40] tseliot: what are you working on? [10:40] tseliot: oooh, xkit? [10:40] yay [10:40] pitti: xkit and some deeper logic [10:40] tseliot: could you work on that relative to the trunk branch, not ubuntu? [10:41] tseliot: a lot of xorg.conf scenarios have test cases already, and thus can be conveniently tested just with tests/run [10:41] tseliot: that should provide a good first conformance test for the x-kit switch [10:41] pitti: ok [10:42] tseliot: (well, xorg_handler.py are identical in trunk and ubuntu, so it doesn't matter so much) [10:42] tseliot: many thanks! [10:42] * pitti goes offline again for yet more gdm debugging, bbl [10:42] pitti: ok, my branch will be based on trunk then. [10:43] where's seb128? [10:43] * tseliot goes back to hack on Jockey [10:48] seb128: wb [10:49] pitti: good morning! === persia_ is now known as persia [11:59] If an update is a "no change rebuild", why is Ubuntu offering it to me in the first place? [12:00] (e.g. today's Firefox updates) [12:00] mpt: "no source change rebuild" is what is meant. [12:00] mpt: Because it was to pick up a library soname change or similar. [12:00] mpt: The binary packages will be different, the only source change was adding a changelog entry. [12:00] That would be more useful information [12:01] mpt: More specicially, you need to have the update in order to use the new xul, which was a security fix. [12:01] "This update uses the latest version of which does " [12:01] Well, we don't always know ... [12:01] mpt: Usually, I will have changelog entries like, "No change rebuild for libgpmg1 -> libgpm2 transistion." [12:01] Otherwise, the only effect of showing the Changes in Update Manager will be to *discourage* people from installing it. [12:02] (Which I assume is not what we want.) [12:02] \o\ Heya Everyone /o/ [12:10] <_Angelus_> guys [12:10] <_Angelus_> will someday exist an ubuntu i686? [12:10] <_Angelus_> :p [12:12] _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] _Angelus_: define what you understand as "i686 Ubuntu"? [12:13] _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] _Angelus_: what is the problem you are trying to solve? [12:14] <_Angelus_> like gentoo [12:14] 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] pitti: correct. [12:15] _Angelus_: we have kernel and libc6 optimized for 686, where it matters (well, a bit anyway) [12:15] <_Angelus_> yeah i know [12:15] the rest hardly matters... [12:15] _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] _Angelus_: can you prove that? [12:15] _Angelus_: no, actually, we strongly believe it wouldn't. Please feel free to produce benchmark figures if you disagree. [12:15] maybe some ultra-optimized math libraries, but those can still have special cases [12:16] 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] no it isn't [12:16] 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] changing distribution involves so many other variables, and you've picked just one? :) [12:17] 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] "I've spent all this time compiling software - it must be worthwhile" [12:17] 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] _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] timing isn't a matter of geekness [12:19] _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] 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] 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] that would be a vast, enormous change [12:21] and require a huge amount of additional resources [12:21] _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] you don't have to believe me or understand me, it is simply a fact [12:21] <_Angelus_> i see [12:21] We could make "i686" symlinks to the i386 versions. Then it would still "feel faster", without the need for extra disk space. :-) [12:21] 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] (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] 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] it very likely has nothing to do with CPU optimisationss [12:23] <_Angelus_> nah [12:23] somebody could do that, and then be disappointed when it made little difference, sure :) [12:23] <_Angelus_> i see [12:23] I believe that somebody did in fact try it in the past, and presented benchmarks with very small percentage-point differences [12:24] though I don't have a reference to hand [12:24] 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] forget i386; we actually build for i486 anyway [12:25] _Angelus_: There are many computers being made today that are i586. [12:25] and we investigated this just recently and found that there was still a substantial pre-i686 requirement (e.g. LTSP thin clients) [12:25] _Angelus_: I think that the current moev is to go 64bit [12:25] *move [12:26] 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] who'd want a desktop with less than 8G RAM anyway? [12:28] 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] 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] 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] _Angelus_: we already supply a 64-bit version of Kubuntu [12:30] jdstrand, are you saying that people with both -updates and -security turned on would have received two updates with the same summary? [12:30] oh, stgraber said that [12:31] <_Angelus_> btw [12:31] _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] mpt: it is a standard text that we use in these situations, but it can certainly be improved if warranted [12:31] mpt: I'm saying that if I used '-v' (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] _Angelus_: ia64 is not a supported arch [12:32] <_Angelus_> ah [12:32] with regard to bugs like bug 252037, can any motu upload a fix or is the solely prerogative of backporters? [12:32] Launchpad bug 252037 in sauerbraten "sauerbraten cannot upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/252037 [12:32] jdstrand, why would they have received two updates instead of one in the first place? [12:32] stgraber: ia64 works fine. No reason to deprecate it. [12:32] <_Angelus_> so 64bit intel cpu's are not supported? [12:32] yes, they are [12:33] "amd64" is just the codename (because AMD designed the architecture) but it also supports Intel Xeon-class systems [12:33] 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] cjwatson: more than Xeon, really. Most desktop and laptop CPUs from Intel those days are 64-bit capable. [12:33] 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] _Angelus_: Itanium only, not things like Core 2. Please listen to what I said. [12:34] mpt: so we had to send it through -security too [12:34] <_Angelus_> hmm i see [12:34] _Angelus_: Wikipedia should have a good summary if you want the complicated history [12:34] 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] _Angelus_: furthermore, we document quite clearly that our 64-bit CD images (for example) support Intel systems [12:34] yes. [12:34] <_Angelus_> i understand. [12:35] I think EM64T is the official Intel 64-bit name. [12:35] 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] TheMuso: Not any more. Now they're calling it Intel 64 [12:35] TheMuso: it is. And the gnu arch string is x86_64. And MS and Sun's name for the architecture is x64. [12:35] StevenK: haha great. [12:36] 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] 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] 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] ok [12:38] s/had/hard/ [13:45] 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:45] Launchpad bug 252262 in dpkg "dpkg-source: Ubuntu maintainer check too broad" [Undecided,Incomplete] https://launchpad.net/bugs/252262 [13:50] warp10: replied, thanks [14:15] hi [14:23] 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] pitti: looking [14:24] seb128: (might actually still take 2 minutes until it hits the quue) [14:24] seb128: merci [14:24] ok, grabbing coffee and looking to that next then [14:24] de rien [14:42] pitti: is the "XorgDriverHandler.enabled()" method called when Jockey installs or uninstalls the driver or only in one of these cases? [14:44] tseliot:in both; (if you really mean enabled(), and not enable() ) [14:45] pitti: I mean enabled() [14:45] pitti: ok, thanks [14:48] pitti: oh, and enabled is called before enable() or disable(), right? [15:00] tseliot: yes [15:00] * pitti -> bbl [15:05]