[00:33] kees: is bug #190329 completely resolved on the kernel side? It's been marked 'confirmed' on ntfs-3g, but I don't see anything to suggest it still needs an upload [00:33] Launchpad bug 190329 in ntfs-3g "DAC permissions not correctly enforced" [Undecided,Confirmed] https://launchpad.net/bugs/190329 [00:36] slangasek: I was wondering about that too -- afaiu, it was just a kernel-side issue. [00:37] ok, marking as 'invalid' [00:49] I've got a problem when using pdebuild for i386 on an amd64 host, building kvm (testing prior to PPA upload). In kvm, qemu/configure does a big/little-endian test and as part of that causes /usr/include/gnu/stubs.h to be referenced. That in turn tries to include gnu/stubs-64.h. But since this is building in an i386 environment, libc6-dev doesn't include /usr/include/gnu/stubs-64.h. Is there a solution? === emgent_ is now known as emgent === foka_ is now known as foka [02:49] benc: Btw, anything i could help with to move last-good-boot forward? [02:51] ion_: The only bit left is to check over cking's grub changes to detect a failed boot and default to last-good-boot [02:52] Where are those changes? [03:06] ion_: in my inbox :) [03:06] ion_: want to test them out? [03:06] benc: Sure [03:06] ion_: what's a good addy to send to? [03:07] ion_: sent [03:08] Thanks [03:13] james_w: http://www.gnome.org/~federico/news-2008-07.html#30 [04:11] BenC, do you have some sort of notification flag that gets set to let the user know about the failed previous boot once it comes back up too though? [04:18] <[Relic]> any updates on when the proper coretemp.c file and new lm-sensors will be added to the kernel for 45nm support? [04:22] superm1: that's the whole point of the grub changes :) [04:22] BenC, ah :) [04:23] superm1: it will stop at the boot prompt and tell them the last boot failed and default to last-good-boot being selected [04:24] superm1: I've been looking into a desktop notification to say "You are booted into the last successfully booted system" (which is independent of it actually failing) [04:24] just a general notice so people know where they are [04:24] BenC, yeah that's what i'm sorta thinking here [04:25] it should be a matter of dropping a file in place, and the notification-daemon detects it and shows you [04:25] right, should be easy in the last-good-boot event.d script, I just haven't come up with good verbage for it [04:26] BenC, i want to say i've seen some warnings showing up in the init script when i turn off the splash, about a hard link already existing [04:26] perhaps you want to 2>/dev/null those? [04:38] superm1: actually, that was a real bug...if you update grub, it should go away [04:38] BenC, ah okay [04:38] superm1: old script wasn't removed, so it was being run twice (in parallel) [04:38] my mirror is usually about a day behind, so i'll see any newer grub updates soonish === gaurdro_ is now known as gaurdro [06:05] good morning [06:08] g'morgen [06:09] hi gaurdro [06:09] hello dholbach [06:30] hi dholbach [06:31] dholbach: I was going to suggest you consider structuring your 5-a-day stats so that bzr-search can be useful for you ;P [06:33] hi lifeless [06:33] lifeless: hm? what do you mean? [06:33] well, when I looked at the stats stuff [06:33] it seemed to me a lot of the guts of it was simply counting how often stuff turns up [06:33] hmm, I had this thought the day after you went on leave [06:34] I'm trying to page it in :) [06:48] Good morning === didrocks_ is now known as didrocks [07:05] pitti! [07:05] * Hobbsee throws pitti some gummy bears in greeting [07:05] yummy! /me tosses back some cookies [07:05] * Mithrandir steals them all [07:06] Mithrandir: so you ate the ones with moustache and pepperoni as well? [07:06] erm, mustard [07:07] yup [07:07] moustache is probably worse [07:07] actually, no [07:07] I just stole them. [07:07] Moustache cookies ♥ [07:08] I guess I just invented a new ad video :) [07:08] * Hobbsee looks at pitti strangely [07:08] and weather applet, you lie! [07:08] argh updates to conf files argh [07:09] * lifeless hates [07:31] lol [07:31] fail: [07:31] Searching for GRUB installation directory ... [07:31] No GRUB directory found. To create a template run 'mkdir /boot/grub' first. To install grub, install it manually or try the 'grub-install' command. ### Warning, grub-install is used to change your MBR. ### [07:39] doko: yippie, we can sync tzdata, Aurelien applied the -java patch (slightly differently, but it's ok) === thekorn_ is now known as thekorn [07:48] morning guys [07:48] doko: ping? [07:51] hey fabbione! [07:51] hey pitti [07:51] how is life? [07:58] fabbione: warm :) [07:58] and pretty good, we started to learn diving yesterday [08:01] pitti: yeah it's warm here too.... [08:01] we are melting [08:16] BenC, cjwatson: hm, it just occurred to me that we can just as well remove the linux meta packages which are NBS; they are uninstallable anyway (pointing to hardy kernel still) [08:30] pitti: anything that isn't built by linux-meta anymore can be deleted [08:30] BenC: right, doing so ATM [08:30] BenC: but I guess eventually we'll need at least some of them back/ [08:30] pitti: it will get replaced by linux-ports-meta src pkg [08:30] like the default linux for the ports? [08:30] ah [08:32] BenC: and the unsupported flavors? like openvz and rt? === giskard_ is now known as giskard [08:36] Riddell: kde4bindings source is in main, but most of its binaries are in universe; also, I thought that we're moving away from kde4*? (it is in binary NEW) [08:41] pitti: those will get provided by other packages, if community ends up creating them === tkamppeter_ is now known as tkamppeter [08:46] Anyone here who packages bluez-libs or bluez-utils [08:47] tkamppeter: you could try #ubuntu-mobile [09:01] [09:02] dholbach, thanks for the hint, but neither there nor here someone answers. Seems that no one really cares about Bluetooth. [09:02] Feel free to donate cool bluetooth hardware to me, i'll become interested. :-) [09:03] tkamppeter: it might help if you ask the question you have [09:03] ion_, fix bug 206579 and I try to organize a Bluetooth printer for you. [09:03] Launchpad bug 206579 in bluez-utils "Bluetooth CUPS backend takes very long time on device discovery" [Critical,New] https://launchpad.net/bugs/206579 [09:07] it's often hard to fix a bug that depends on some hardware without access to that hardware; someone donating or lending the hardware would be a great boon to such bug fixing, I'm sure [09:08] tkamppeter: I'm not sure I understand. Does it only take a long time when you don't activate bluetooth on your printer? [09:09] * pitti cuts a huge dent into the NBS list, but it's still alarmingly huge [09:10] ichthux-desktop [09:10] Sigh [09:10] ichthux-desktop is still the cause of a bunch of it [09:11] persia, if a Bluetooth printer is there, all is fine. The backend finds the printer and finishes within 10 seconds. Problem is only if there is no Bluetooth printer. then it never exits. [09:11] StevenK: I killed all of those [09:11] According to the bug it is hanging somehow on DBUS communication. [09:12] That ought be easier then. The bug depends on the *absence* of certain hardware :) [09:12] So fixing the bug must be possible without the hardware. [09:13] well, it's still helpful to test if your fix still works with the hardware, of course, but debugging should be easier, yes [09:13] While testing make sure that the Bluetooth of your cell phone is turned off, as some cell phones get detected as printer. [09:14] Wait, does this only happen when there is *no* local bluetooth environment? [09:14] * persia can usually detect >15 bluetooth devices due to population density [09:16] it can usually be turned off in the BIOS, or just with rmmod [09:18] persia, yes, the bug only occurs if NO Bluetooth devices are present. [09:18] I wonder if someone better versed with Bluetooth could look at bug 211252 [09:18] Launchpad bug 211252 in obex-data-server "Cannot recieve files using bluetooth" [Undecided,Confirmed] https://launchpad.net/bugs/211252 [09:21] persia, a local Bluetooth environment is there, What is needed for the bug to occur is that there is no Bluetooth device. A Bluetooth printer must be turned off. [09:21] tkamppeter: I'll try, but I can't control my neighbours :) [09:23] persia, simply run the bluetooth backend with "time sudo /usr/lib/cups/backend/bluetooth" and see what happens. === sabdf1 is now known as sabdfl [09:23] hello sabdfl [09:24] howdy [09:25] Riddell: there is a digikam-kde4 in source NEW; do we really still want packages with -kde4? [09:33] tkamppeter: I get 10 seconds on hardy. What should I check to see if there was an undesired detection? [09:34] persia, do you have any output? [09:36] tkamppeter: Only the time report. [09:36] Running without time gets no output. [09:36] persia, is there a tool with which I can see whether there are really no Bluetooth devices present here? [09:37] "hcitool scan" should do that [09:38] * persia is finding a MAC and a phone [09:38] liw: till@till-laptop:~/gutenprint/cvs/HEAD/print/src/cups$ hcitool scan [09:38] Scanning ... [09:38] Inquiry failed: Device or resource busy [09:38] till@till-laptop:~/gutenprint/cvs/HEAD/print/src/cups$ [09:38] I think that means your bluetooth stack is not fully working [09:38] or something else is using it or something [09:38] persia, also with the Bluetooth on my cell phone turned on, the bluetooth backend does not exit. [09:40] tkamppeter: Well, I can't replicate that. I've no bluetooth printers detected, and at least two bluetooth devices I cannot disable within range. It takes 10 seconds. === rraphink is now known as raphink [09:45] pitti: yes, in this case it's still beta and upstream don't want us to remove the kde 3 version yet (same as amarok), so universe for it [09:46] Riddell: alrighty [09:46] Riddell, the kde3 version is not installable. [09:47] tkamppeter: yes, it's somewhere on my todo to fix that [09:48] persia, I have rebooted my Intrepid box now and still cannot scan the Bluetooth: [09:48] till@till-laptop:~$ sudo hcitool scan [09:48] [sudo] password for till: [09:48] Scanning ... [09:48] Inquiry failed: Device or resource busy [09:48] till@till-laptop:~$ [09:49] I hope this is not a DoS from a neighbor ... [09:49] tkamppeter: Are you sure your bluetooth device works? [09:50] persia, I have already used a Bluetooth mouse and also Bluetooth printers with this laptop. [09:52] tkamppeter: Hmm. I'm not sure then. I thought "Device or resource busy" meant that there was some issue accessing a local device, rather than a remote device. [09:56] am I the only one getting nightly errors from checksecurity on intrepid? [09:56] StevenK: I can't replicate that with hardy. [09:56] sort: fflush failed: standard output: Broken pipe [10:06] Riddell: can you please have a look at the "source/binary demotion" part of http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt, the KDE stuff? (k*) [10:06] Riddell: kdeaddons, kdebluetooth, etc. are really obsolete? [10:08] doko: hey, I've some python packaging issue, maybe you can help ;-) pygobject not has a /usr/lib/libpyglib.so and I don't how to handle that since it's build against one python version only, one way would be to build pygobject and pygtk for one python version only... [10:08] persia, I have turned on two Bluetooth printers and the backend found them in 20 seconds, then I have turned them off and the backend still found them in 55 sec [10:10] pitti: kdeaddons is [10:11] pitti: kdebluetooth I'm not sure, kdebluetooth4 is ment to be being packaged today by tonio so I guess it'll get updated [10:11] persia, only on Intrepid, on Hardy the backend returned to hanging infinitely. [10:14] tkamppeter: I only tested in hardy. Still 10 second return, other devices present, no bluetooth printer. [10:14] pitti: keep kipi-plugins, konq-plugins, libkdcraw, libkexiv2, libkipi, webkitkde. I'll add them to seeds other kde bits can be demoted [10:15] Riddell: ok, that list plus bluetooth? [10:15] Riddell: thanks [10:15] pitti: yes [10:15] persia, for me it hangs on two laptops [10:16] soren: seems qemu again started to b-dep on gcc-3.4; merge error? [10:18] Riddell: erm, did you mean to keep "keep", or not? [10:18] i. e. was the first word in your sentence a verb or package name? [10:19] pitti: do not keep "keep" [10:19] ok :) [10:20] pitti: qemu had b-d'ed on gcc-3.4 all along. [10:21] pitti: kvm... not so much. [10:21] ah, right [10:21] tkamppeter: I'm guessing it's either device-specific or related to some configuration, as I'd not done any bluetooth things on this machine between install and this test. [10:21] soren: ah, I see now; libvirt0 recommends: qemu and thus qemu wants to go into main, together with its (b)deps [10:21] -> suggests:? [10:22] Quite. I'll make a note of it and see to it when I'm back on Monday. [10:22] soren: thanks [10:22] soren: I can file a bug for you if that helps [10:22] pitti: That would be good, thanks. [10:23] * soren climbs back under his rock [10:24] soren: done, bug 253900; enjoy your holiday! [10:24] Launchpad bug 253900 in libvirt "drop qemu recommends: to suggests:" [Undecided,New] https://launchpad.net/bugs/253900 [10:40] seb128: rb's recommends: gst-plugins-ugly will pull -ugly, a52dec, and other stuff into main; do you think dropping to suggests: is appropriate? I'd think so, given easy-codec-install [10:40] pitti: hum, probably yes, will change that when I do the next upload [10:41] seb128: WDYT about the same problem with python-{coherence,louie}? MIR or drop? [10:41] seb128: oh, I can do the upload, just asking for your opinion [10:41] do we really need to break recommends or promote those? [10:41] I though recommends in universe were handled correctly if universe is not activated [10:42] component-mismatches is horribly big, we need to cut it down to some sanity, otherwise we'll drag it forever; I'm happy to do some uploads [10:42] pitti: well I just uploaded a svn snapshot so make sure to get this one and to verify that the current upload built first ;-) [10:42] seb128: main should be recommends-complete. Not doing that means all sorts of confusion about what is installed. [10:42] seb128: but we install it by default, and we install recommends by default [10:42] so either the recommends is worthless (because apt will not auto-install missing ones), or we should really install it [10:43] seb128: right, I saw that [10:43] pitti: well, python-coherence is useful but it'll not fit on the CD [10:43] that's required to have upnp working [10:43] and that will not easycodec install [10:43] right [10:43] seems we need some similar magic for plugged in hardware [10:43] I don't like to demote it to a suggests much :-- [10:43] :-( [10:44] (well, jockey is on the way to become this magic, but it's not there yet) [10:44] pitti: that's not hardware, that's network devices [10:44] seb128: the question is not so much r: or s:, but rather whether we want to install it by default [10:44] want yes, can is an another question [10:44] if we don't install it by default, the recommends: won't help anyone [10:44] I think I looked at it before hardy [10:45] installing python-coherence is an extra 11meg [10:45] the one CD limitation is starting being really though :-( [10:46] $ sudo apt-get install python-coherence [10:46] After this operation, 5370kB of additional disk space will be used. [10:46] on my intrepid [10:46] and that's not a stock install so I might have some extra things already installed [10:46] pitti: NBS kernel metapackages> I'd been deliberately leaving them there so that we could see what needed to be replaced [10:47] seb128: python-louie is trivial and tiny, though; not sure what it does in RB, but that can easily be added [10:47] pitti: otherwise we'll have upgrade problems [10:47] pitti: no, rhythmbox requires python-coherence to get that working, python-louie will not bring anything [10:48] pitti: debian bug #474733 [10:48] Debian bug 474733 in rhythmbox "rhythmbox: Please suggest python-coherence instead of python-louie" [Normal,Closed] http://bugs.debian.org/474733 [10:49] pitti: well, I guess demote python-coherence to a suggest and remove python-louie if you want to change something [10:50] I don't think we can afford that on the CD [10:50] seb128: right, will do; thanks [10:50] thanks [10:51] did we discuss a way to have "recommends which don't fit on the CD but that people might want to install if they have internet access after the installation"? [10:52] BenC: right now you would be the proudest father on this planet if you had my son.. he learned to say "burger" and goes around asking for it all the time :) [10:52] doko: unping.. problem solved [10:52] cjwatson: I filed bug 253904 about it, FYI [10:52] Launchpad bug 253904 in linux-meta "does not build a lot of metapackages any more" [High,Triaged] https://launchpad.net/bugs/253904 [10:53] fabbione: fine =) [10:53] fabbione: lol; not "spaghetti"? [10:53] oh doko is there [10:53] doko: run! [10:53] doko: did you read my question before? [10:53] pitti: pizza was his first food related word... even before "Daddy" [10:53] * doko ducks and runs [10:53] pitti: pasta come in later.. no spaghetti yet.. too long ;) [10:53] fabbione: "noodles" then [10:54] pitti: will try :) [10:54] pitti: oh, http://bugzilla.gnome.org/show_bug.cgi?id=545828 [10:54] Gnome bug 545828 in plugins "Add apport monitoring" [Enhancement,Unconfirmed] [10:54] seb128: rb built everywhere, FYI; grabbing and uploading [10:54] mvo: ^ did you know about that? [10:54] pitti: excellent ;-) [10:54] seb128: hmm, no, looks like we have to patch to build two versions (like we do e.g. for subversion-svn) [10:55] doko: "2 versions"? then we will have to patch other bindings to use the versionning correctly or something? [10:56] seb128: niice! looks very similat to what we have in update-notifier [10:56] yes, but building just for one version will get us into upgrade hell ... [10:58] doko: do you think you would have some time to look at it? I'm not sure to get what changes are required there, I can hand you the current source package, build breaks because python2.4 and python2.5 builds have this same lib [10:58] seb128: no [10:58] sure, can have a look. [10:59] soren: I get really bad network thorughput with the current kvm in intrepid, do you have any idea about this? its currently in the range of 20kb/s from my local proxy, this used to be more like 2000kb/s or more [10:59] soren: do you have any idea about this or got similar reports? [10:59] mvo: do we need apt-xapian-index in main/on the CD, or can we drop the synaptics recommends: to it? [11:00] soren: could be a local misconfiguraiton of course, but I would like to hear your opinion [11:00] pitti: we don't need it, it would be nice to have it though [11:01] doko: http://people.ubuntu.com/~seb128/pygobject/ [11:02] mvo: 'nice to have' sounds like suggests:, not recommends: :) [11:02] don't get me wrong, I don't really like the new strongness of recommends: in the first place, but now that we have it, we need to be consistent [11:03] pitti: well, its not essential, if available it provides very fast search in the package descriptions (search as you type) with ranking and goodies like this. however if it is not there, then the old search will still work (also that is much slower and does not provide ranking) [11:03] I always have the feeling that recommends: is now exactly like depends:, and suggests: is the new recommends:, and the old suggets: was dropped now [11:04] pitti: so in summary I think we should have the xapian-index if possible (and CD space allows it) [11:04] mvo: answer to 'CD space allows it' is generally "no", I'm afraid [11:05] I'm wondering if this "install recommends by default" makes sense if that just means demote most of the recommends to suggest [11:05] seb128: exactly my thought; it basically seesm that Debian wanted to get rid of recommends entirely [11:06] there might be a perfectly reasonable rationale behind it, I'm just not aware of it ATM [11:07] pitti: the extra space is in the range of ~1mb [11:08] pitti: its a perfect use-case for recommends, it should be installed (apt-xapaina-index) but it can work without [11:08] mvo: we have lot of things which "should be installed" but the one CD limitation is though ... [11:08] pitti: where is that discussed (that debian wants to get rid of them entirely)? [11:09] seb128: I'm fine with that, I will add code that cehcks for it and offers to install it in the ui if it is missing. I'm just explaining that I think its the perfect example for a "recommends" IMO [11:09] pitti> Thanks for moving batik out of multiverse [11:09] fop can follow suit now, should I file a bug for it? [11:10] mvo: right, but since we had not space on the CD before installing recommends by default I'm wondering if installing recommends by default makes sense [11:10] mvo: it basically means we need to drop all the recommends for packages on the CD [11:10] mvo: I don't know; but that's how it feels [11:11] Sikon: same rationale? I can just do it [11:11] well, we could do the CD install without recommends and have something in synaptic telling people about packages they might want to install (all the missing recommends basicly) [11:11] yes, same rationale - its only multiverse dependency was batik and now it's been moved [11:12] mvo: right, that's what I asked before, did we discuss a way to have "recommends which don't fit on the CD but that people might want to install if they have internet access after the installation"? [11:12] I don't have strong feelings about recommends in general, if debian would decides that they are not useful and we should only have "depends" and "suggests" I would not mind, it just needs to be consistent and in the policy [11:13] seb128: oh, I missed that [11:13] they are useful [11:13] and the idea rocks [11:13] it just doesn't fit on the CD [11:13] seb128: I don#'t think we dicussed that, I think that is a nice idea. we could offer something similar to the langpacks, a option to install the missing bits [11:14] seb128: and have a mode in synaptic (or somewhere else) that tells about the missing ones [11:14] that would be cool [11:14] I think especially the bits in the installer (getting the list of not-installed recommends) is really straightforward [11:16] Sikon: moved, thanks [11:17] they'd still need to be in main, thuogh [11:17] we shouldn't in good faith Recommend: a package in universe [11:17] that would be saying "we want it, but then we don't" [11:17] * mvo agrees [11:18] and the "do the post-install huge recommends: install" is both confusing and also user-unfriendly as well [11:18] then we should be straight and rather offer a bigger install media as an alternative, such as the discussed 1 GB USB stick image, or the DVD [11:18] pitti: well, how do you solve things like the xapian index should be installed, or python-coherence so upnp is working? [11:18] pitti: you think so? if it is offered similar to the langpack install in ubiquity? I guess it depends on how big it is [11:19] but it sounds not too bad to me (moving to a bigger media is of course even better :) [11:19] seb128: my opinion is still that a bigger alternative install media is better than to inflict a 300 MB download right after installation [11:20] right, my opinion too [11:20] Maybe a 1GB USB stick? [11:20] but previous times we had this discussion you were opposed to anything bigger than 1 CD [11:20] that's worse than downloading those extra 300 MB beforehand with the install media [11:20] persia: yeah, that's what Scott suggested too already [11:20] seb128: oh, I still love the idea of having a CD [11:20] seb128: but I never opposed to us offering a DVD [11:21] *alternate* media :) [11:21] I'm not sure if its that much of a issue, especially since we force a huge download on people anyway for the secuirty updates etc after the install. it depends on the size, if its 300mb that is a bit much of course, if its 30mb I think that is not too bad [11:21] I love it too, but not if it means that the installed product start degrading because we don't have space to put what we need [11:21] the ubuntu-bells-and-whistles 2 GB images, if you can afford the download [11:22] I'm just opposed to dropping the CD entirely, for two reasons: first, it would encourage us to add bloat without ever cleaning up, and second, with every added 100 MB we'll lose a lot of users who cannot download it any more [11:22] Also, CDs are cheap to hard out to random folk. [11:22] s/hard/hand/ [11:22] right, I'm not suggesting *dropping* the CD [11:22] persia: I don't see a price difference between CD and DVD media here. [11:22] e. g. xapian index is exactly the case how it should not be [11:23] but maybe 1 CD installs should not be the recommended media for desktop installs [11:23] Mithrandir: Really? We still have one here: about the same price for 50 CDs as 20 DVDs (not that it's much, really) [11:23] if we think we are degrading the user experience due to the CD space limitation [11:23] if it works well, and we support it, then we shouldn't have two different apt backends, but just use xapian and nothing else [11:23] Mithrandir: the download size difference matters a lot, though [11:24] pitti: that's not only xapian index, that's upnp not working in rhythmbox for example [11:24] right [11:25] persia: well, it's 59 NOK vs 71 NOK for 25 CDs/DVDs, but then the CDs are noname and the DVDs are Verbatim. [11:25] pitti: I don't understand, how is that "how it should *not* be" ? I could just make a depends and claim that this is now the way to do it (for good reaosns). but instead I decided to provide the added flexbilibty for people with small systems that don't want the extra diskspace. in what way is that bad? [11:25] seb128: that's why I'm so opposed to webkit, for example [11:25] pitti: sure, just saying that I don't think price of media is much of a factor here at least. [11:25] seb128: because webkit doesn't give the user *any* benefit ATM, it just takes CD space [11:25] pitti: well, that's not up to us though [11:25] I know that this isn't exactly our fault [11:26] it's an upstream decision [11:26] but from the user's POV that doesn't matter [11:26] and it makes sense for them [11:26] that's an orthogonal issue anyway [11:27] it's not for the topic of what we use our precious CD space for, IMHO [11:27] there is no "we" there since we don't lead upstream work and have no say in their decisions [11:27] we have no real choice there, either we ship what they do or we fork the code and maintain it [11:28] well, in cases where all the distros say "no", they'd reconsider for sure [11:28] not sure [11:28] but of course if the other distros don't care about how many GBs they dump on the user, we are left alone :( [11:28] and all distros will not say no [11:28] well, that's not a matter of how many gbs [11:29] GNOME use only only webkit [11:29] we are the one who decided to ship firefox and not epiphany-browser [11:29] (but there might be a correlation why millions of people download Ubuntu CDs, and magnitudes fewer download SuSE DVDs) [11:29] -only [11:29] seb128: hm, that's a good point actually [11:30] pitti: ...being left alone is a *unique selling point* [11:30] seb128: replacing ffox by epy by default is something that we could do [11:31] pitti: I wouldn't do it yet there are som major flaws at the moment still :( [11:31] right, but we will not likely due because firefox is known, etc and users will want to use it [11:31] but "mindshare" means that it would not be wise [11:31] plugins is another common reason cited for using ff [11:33] Ubuntu got noticed and used for shipping sane defaults that roughly aligned to what a sizable majority "just wanted". 1 CD, with Firefox, with OpenOffice, with bling and with nekkid people [11:33] A number of plugins work with epiphany-browser in hardy. Does that go away with webkit? [11:33] persia: I'd think so [11:34] well, webkit is not there yet [11:34] pitti: That would be a bug. I'm an epiphany user, but appreciate the current featureset. [11:34] but it's getting there so maybe next cycle [11:35] persia: which brings me back to GNOME prematurely dropping xul support :) [11:35] heh [11:35] persia: they still didn't make epiphany-webkit the default, they expect that to be ready for GNOME 2.26 (intrepid+1) [11:35] pitti: they didn't drop it for epiphany-browser actually [11:35] seb128: even if webkit is epiphany isn't using it to it's greatest advantage yet :( [11:35] seb128: ah, *phew* :) [11:35] but webkit is good for desktop applications [11:35] seb128: So epiphany will ship both epiphany-webkit and epiphany-gecko? [11:36] persia: it does in intrepid yes [11:36] seb128: what happens to gtkhtml, BTW? we still ship that as well [11:36] pitti: going to be remplaced by webkit too [11:36] good [11:37] So webkit doesn't need to be on the CDs for intrepid? [11:37] persia: yelp will likely use it but we can hold back to the current version if we want to [11:38] Let's do that. WIth such a plan we can delay the webkit discussion until upstream has caught up with itself. [11:38] they dropped over 1000 lines of code when switching to webkit, improved the start time and got some thing working which were broken when using gecko [11:38] mvo: my feeling is just that we keep accumulating three different alternatives/libraries/programs to do a job; once, Ubuntu's strong point was to select the best and use just that [11:39] mvo: unfortunately we seldomly have the power to decide that for the entire distro, sure [11:39] but we should still strive to do that [11:39] pitti: again that's an orthogonal issue, we should still be careful on having a clean set of packages and no duplication, etc [11:39] mvo: so in terms of apt, if xapian is the way to go, then let's use it, and use *just* it [11:39] pitti: but that doesn't mean we will make all the feature we need to fit on one CD [11:39] otherwise we have to test and support systems with both alternatives, which doesn't make things easier [11:40] seb128: sure, that's true, but we shuold at least consistently aim for throwing out redundancy, so that we don't waste space [11:40] and wasting space is all too easy if your install media is unlimited [11:40] right, agreed [11:41] I'm regularly amazed how big a Windows installation is, and I wouldn't like to install a complete DVD from SuSE to take some 10, 15 GB [11:42] so, I agree that a CD limit is probably too tight for a really good desktop experience, but a DVD is too big IMHO [11:42] and I'm just afraid that it'd cost us a *lot* of users to just have DVDs [11:42] pitti: I re-installed the vista image from my new laptop recently and it refused to work with less than a 15-20GB partition [11:42] first boot of this laptop (the auto vista install) took 1.5hours. The Ubuntu install took 11minutes [11:43] I figured that 20gb was a bit much to update my phone firmware, and gave up ;) [11:43] sladen: Just boot first with the livecd. Saves time. [11:43] and the Ubuntu install did more out of the box... [11:43] persia: cough. lack of CD drive [11:44] persia: so I wubi'ed it with the lack of anything else to hand to netboot [11:44] (although XP fits fine in 2GB, it has to be said) [11:44] someone (Keybuk?) raised the idea of an 1 GB usb stick image [11:44] I actually quite like that [11:45] a stick image of $size is really a must; the current instructions for how to convert an ISO to a stick image are too convoluted [11:45] pitti: yes, that was Scott [11:45] ubuntu-mobile currently installs off a 500MB USB stick image. Mind you, -desktop needs more space, but it's not that much different than CDs. [11:45] sladen: full ack [11:45] pitti: I would like at least get a media where we don't need to cut too much and where we could have translations installed [11:46] pitti: 1Gb keys would be nice indeed [11:46] There's also a work-in-progress wizard to put a USB image onto the stick, which ought make intrepid. [11:46] persia: yep, ogra uploaded it a week or two ago [11:47] pitti: Yep. Should come back to you next week. === RainCT is now known as RainCT_ [11:51] Hello, any archive admin available for a licensing question ? [11:52] joaopinto: just ask the question, please [11:53] I am packaging game, the source code is distributed under GPL, the artwork is distributed "Free Art License" [11:53] pitti: ok, thanks for explaining that to me. I will make apt-xapian-index a depends then in ubuntu. xapian is the way to go for the frontends, it will just not be part of the stock apt (apt-cache). but I think every frontend should use it (the packagekit apt backend is using it too) [11:54]