| slangasek | 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 |
|---|---|---|
| ubottu | Launchpad bug 190329 in ntfs-3g "DAC permissions not correctly enforced" [Undecided,Confirmed] https://launchpad.net/bugs/190329 | 00:33 |
| kees | slangasek: I was wondering about that too -- afaiu, it was just a kernel-side issue. | 00:36 |
| slangasek | ok, marking as 'invalid' | 00:37 |
| IntuitiveNipple | 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? | 00:49 |
| === emgent_ is now known as emgent | ||
| === foka_ is now known as foka | ||
| ion_ | benc: Btw, anything i could help with to move last-good-boot forward? | 02:49 |
| BenC | 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:51 |
| ion_ | Where are those changes? | 02:52 |
| BenC | ion_: in my inbox :) | 03:06 |
| BenC | ion_: want to test them out? | 03:06 |
| ion_ | benc: Sure | 03:06 |
| BenC | ion_: what's a good addy to send to? | 03:06 |
| BenC | ion_: sent | 03:07 |
| ion_ | Thanks | 03:08 |
| lifeless | james_w: http://www.gnome.org/~federico/news-2008-07.html#30 | 03:13 |
| superm1 | 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:11 |
| [Relic] | any updates on when the proper coretemp.c file and new lm-sensors will be added to the kernel for 45nm support? | 04:18 |
| BenC | superm1: that's the whole point of the grub changes :) | 04:22 |
| superm1 | BenC, ah :) | 04:22 |
| BenC | superm1: it will stop at the boot prompt and tell them the last boot failed and default to last-good-boot being selected | 04:23 |
| BenC | 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 |
| BenC | just a general notice so people know where they are | 04:24 |
| superm1 | BenC, yeah that's what i'm sorta thinking here | 04:24 |
| superm1 | it should be a matter of dropping a file in place, and the notification-daemon detects it and shows you | 04:25 |
| BenC | right, should be easy in the last-good-boot event.d script, I just haven't come up with good verbage for it | 04:25 |
| superm1 | 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 |
| superm1 | perhaps you want to 2>/dev/null those? | 04:26 |
| BenC | superm1: actually, that was a real bug...if you update grub, it should go away | 04:38 |
| superm1 | BenC, ah okay | 04:38 |
| BenC | superm1: old script wasn't removed, so it was being run twice (in parallel) | 04:38 |
| superm1 | my mirror is usually about a day behind, so i'll see any newer grub updates soonish | 04:38 |
| === gaurdro_ is now known as gaurdro | ||
| dholbach | good morning | 06:05 |
| gaurdro | g'morgen | 06:08 |
| dholbach | hi gaurdro | 06:09 |
| gaurdro | hello dholbach | 06:09 |
| lifeless | hi dholbach | 06:30 |
| lifeless | 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:31 |
| dholbach | hi lifeless | 06:33 |
| dholbach | lifeless: hm? what do you mean? | 06:33 |
| lifeless | well, when I looked at the stats stuff | 06:33 |
| lifeless | it seemed to me a lot of the guts of it was simply counting how often stuff turns up | 06:33 |
| lifeless | hmm, I had this thought the day after you went on leave | 06:33 |
| lifeless | I'm trying to page it in :) | 06:34 |
| pitti | Good morning | 06:48 |
| === didrocks_ is now known as didrocks | ||
| Hobbsee | pitti! | 07:05 |
| * Hobbsee throws pitti some gummy bears in greeting | 07:05 | |
| pitti | yummy! /me tosses back some cookies | 07:05 |
| * Mithrandir steals them all | 07:05 | |
| pitti | Mithrandir: so you ate the ones with moustache and pepperoni as well? | 07:06 |
| pitti | erm, mustard | 07:06 |
| Mithrandir | yup | 07:07 |
| pwnguin | moustache is probably worse | 07:07 |
| Mithrandir | actually, no | 07:07 |
| Mithrandir | I just stole them. | 07:07 |
| ion_ | Moustache cookies ♥ | 07:07 |
| pitti | I guess I just invented a new ad video :) | 07:08 |
| * Hobbsee looks at pitti strangely | 07:08 | |
| Hobbsee | and weather applet, you lie! | 07:08 |
| lifeless | argh updates to conf files argh | 07:08 |
| * lifeless hates | 07:09 | |
| lifeless | lol | 07:31 |
| lifeless | fail: | 07:31 |
| lifeless | Searching for GRUB installation directory ... | 07:31 |
| lifeless | 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:31 |
| pitti | doko: yippie, we can sync tzdata, Aurelien applied the -java patch (slightly differently, but it's ok) | 07:39 |
| === thekorn_ is now known as thekorn | ||
| fabbione | morning guys | 07:48 |
| fabbione | doko: ping? | 07:48 |
| pitti | hey fabbione! | 07:51 |
| fabbione | hey pitti | 07:51 |
| fabbione | how is life? | 07:51 |
| pitti | fabbione: warm :) | 07:58 |
| pitti | and pretty good, we started to learn diving yesterday | 07:58 |
| fabbione | pitti: yeah it's warm here too.... | 08:01 |
| fabbione | we are melting | 08:01 |
| pitti | 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:16 |
| BenC | pitti: anything that isn't built by linux-meta anymore can be deleted | 08:30 |
| pitti | BenC: right, doing so ATM | 08:30 |
| pitti | BenC: but I guess eventually we'll need at least some of them back/ | 08:30 |
| BenC | pitti: it will get replaced by linux-ports-meta src pkg | 08:30 |
| pitti | like the default linux for the ports? | 08:30 |
| pitti | ah | 08:30 |
| pitti | BenC: and the unsupported flavors? like openvz and rt? | 08:32 |
| === giskard_ is now known as giskard | ||
| pitti | 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:36 |
| BenC | pitti: those will get provided by other packages, if community ends up creating them | 08:41 |
| === tkamppeter_ is now known as tkamppeter | ||
| tkamppeter | Anyone here who packages bluez-libs or bluez-utils | 08:46 |
| dholbach | tkamppeter: you could try #ubuntu-mobile | 08:47 |
| tkamppeter | <dholbach> | 09:01 |
| tkamppeter | dholbach, thanks for the hint, but neither there nor here someone answers. Seems that no one really cares about Bluetooth. | 09:02 |
| ion_ | Feel free to donate cool bluetooth hardware to me, i'll become interested. :-) | 09:02 |
| dholbach | tkamppeter: it might help if you ask the question you have | 09:03 |
| tkamppeter | ion_, fix bug 206579 and I try to organize a Bluetooth printer for you. | 09:03 |
| ubottu | Launchpad bug 206579 in bluez-utils "Bluetooth CUPS backend takes very long time on device discovery" [Critical,New] https://launchpad.net/bugs/206579 | 09:03 |
| liw | 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:07 |
| persia | tkamppeter: I'm not sure I understand. Does it only take a long time when you don't activate bluetooth on your printer? | 09:08 |
| * pitti cuts a huge dent into the NBS list, but it's still alarmingly huge | 09:09 | |
| StevenK | ichthux-desktop | 09:10 |
| StevenK | Sigh | 09:10 |
| StevenK | ichthux-desktop is still the cause of a bunch of it | 09:10 |
| tkamppeter | 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 |
| pitti | StevenK: I killed all of those | 09:11 |
| tkamppeter | According to the bug it is hanging somehow on DBUS communication. | 09:11 |
| persia | That ought be easier then. The bug depends on the *absence* of certain hardware :) | 09:12 |
| tkamppeter | So fixing the bug must be possible without the hardware. | 09:12 |
| pitti | 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 |
| tkamppeter | While testing make sure that the Bluetooth of your cell phone is turned off, as some cell phones get detected as printer. | 09:13 |
| persia | 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:14 | |
| pitti | it can usually be turned off in the BIOS, or just with rmmod | 09:16 |
| tkamppeter | persia, yes, the bug only occurs if NO Bluetooth devices are present. | 09:18 |
| StevenK | I wonder if someone better versed with Bluetooth could look at bug 211252 | 09:18 |
| ubottu | Launchpad bug 211252 in obex-data-server "Cannot recieve files using bluetooth" [Undecided,Confirmed] https://launchpad.net/bugs/211252 | 09:18 |
| tkamppeter | 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 |
| persia | tkamppeter: I'll try, but I can't control my neighbours :) | 09:21 |
| tkamppeter | persia, simply run the bluetooth backend with "time sudo /usr/lib/cups/backend/bluetooth" and see what happens. | 09:23 |
| === sabdf1 is now known as sabdfl | ||
| pitti | hello sabdfl | 09:23 |
| sabdfl | howdy | 09:24 |
| pitti | Riddell: there is a digikam-kde4 in source NEW; do we really still want packages with -kde4? | 09:25 |
| persia | tkamppeter: I get 10 seconds on hardy. What should I check to see if there was an undesired detection? | 09:33 |
| tkamppeter | persia, do you have any output? | 09:34 |
| persia | tkamppeter: Only the time report. | 09:36 |
| persia | Running without time gets no output. | 09:36 |
| tkamppeter | persia, is there a tool with which I can see whether there are really no Bluetooth devices present here? | 09:36 |
| liw | "hcitool scan" should do that | 09:37 |
| * persia is finding a MAC and a phone | 09:38 | |
| tkamppeter | liw: till@till-laptop:~/gutenprint/cvs/HEAD/print/src/cups$ hcitool scan | 09:38 |
| tkamppeter | Scanning ... | 09:38 |
| tkamppeter | Inquiry failed: Device or resource busy | 09:38 |
| tkamppeter | till@till-laptop:~/gutenprint/cvs/HEAD/print/src/cups$ | 09:38 |
| liw | I think that means your bluetooth stack is not fully working | 09:38 |
| liw | or something else is using it or something | 09:38 |
| tkamppeter | persia, also with the Bluetooth on my cell phone turned on, the bluetooth backend does not exit. | 09:38 |
| persia | 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. | 09:40 |
| === rraphink is now known as raphink | ||
| Riddell | 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:45 |
| pitti | Riddell: alrighty | 09:46 |
| tkamppeter | Riddell, the kde3 version is not installable. | 09:46 |
| Riddell | tkamppeter: yes, it's somewhere on my todo to fix that | 09:47 |
| tkamppeter | persia, I have rebooted my Intrepid box now and still cannot scan the Bluetooth: | 09:48 |
| tkamppeter | till@till-laptop:~$ sudo hcitool scan | 09:48 |
| tkamppeter | [sudo] password for till: | 09:48 |
| tkamppeter | Scanning ... | 09:48 |
| tkamppeter | Inquiry failed: Device or resource busy | 09:48 |
| tkamppeter | till@till-laptop:~$ | 09:48 |
| tkamppeter | I hope this is not a DoS from a neighbor ... | 09:49 |
| persia | tkamppeter: Are you sure your bluetooth device works? | 09:49 |
| tkamppeter | persia, I have already used a Bluetooth mouse and also Bluetooth printers with this laptop. | 09:50 |
| persia | 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:52 |
| mdz | am I the only one getting nightly errors from checksecurity on intrepid? | 09:56 |
| persia | StevenK: I can't replicate that with hardy. | 09:56 |
| mdz | sort: fflush failed: standard output: Broken pipe | 09:56 |
| pitti | 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 |
| pitti | Riddell: kdeaddons, kdebluetooth, etc. are really obsolete? | 10:06 |
| seb128 | 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 |
| tkamppeter | 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:08 |
| Riddell | pitti: kdeaddons is | 10:10 |
| Riddell | 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 |
| tkamppeter | persia, only on Intrepid, on Hardy the backend returned to hanging infinitely. | 10:11 |
| persia | tkamppeter: I only tested in hardy. Still 10 second return, other devices present, no bluetooth printer. | 10:14 |
| Riddell | pitti: keep kipi-plugins, konq-plugins, libkdcraw, libkexiv2, libkipi, webkitkde. I'll add them to seeds other kde bits can be demoted | 10:14 |
| pitti | Riddell: ok, that list plus bluetooth? | 10:15 |
| pitti | Riddell: thanks | 10:15 |
| Riddell | pitti: yes | 10:15 |
| tkamppeter | persia, for me it hangs on two laptops | 10:15 |
| pitti | soren: seems qemu again started to b-dep on gcc-3.4; merge error? | 10:16 |
| pitti | Riddell: erm, did you mean to keep "keep", or not? | 10:18 |
| pitti | i. e. was the first word in your sentence a verb or package name? | 10:18 |
| Riddell | pitti: do not keep "keep" | 10:19 |
| pitti | ok :) | 10:19 |
| soren | pitti: qemu had b-d'ed on gcc-3.4 all along. | 10:20 |
| soren | pitti: kvm... not so much. | 10:21 |
| pitti | ah, right | 10:21 |
| persia | 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 |
| pitti | soren: ah, I see now; libvirt0 recommends: qemu and thus qemu wants to go into main, together with its (b)deps | 10:21 |
| pitti | -> suggests:? | 10:21 |
| soren | Quite. I'll make a note of it and see to it when I'm back on Monday. | 10:22 |
| pitti | soren: thanks | 10:22 |
| pitti | soren: I can file a bug for you if that helps | 10:22 |
| soren | pitti: That would be good, thanks. | 10:22 |
| * soren climbs back under his rock | 10:23 | |
| pitti | soren: done, bug 253900; enjoy your holiday! | 10:24 |
| ubottu | Launchpad bug 253900 in libvirt "drop qemu recommends: to suggests:" [Undecided,New] https://launchpad.net/bugs/253900 | 10:24 |
| pitti | 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 |
| seb128 | pitti: hum, probably yes, will change that when I do the next upload | 10:40 |
| pitti | seb128: WDYT about the same problem with python-{coherence,louie}? MIR or drop? | 10:41 |
| pitti | seb128: oh, I can do the upload, just asking for your opinion | 10:41 |
| seb128 | do we really need to break recommends or promote those? | 10:41 |
| seb128 | I though recommends in universe were handled correctly if universe is not activated | 10:41 |
| pitti | 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 |
| seb128 | 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 |
| persia | seb128: main should be recommends-complete. Not doing that means all sorts of confusion about what is installed. | 10:42 |
| pitti | seb128: but we install it by default, and we install recommends by default | 10:42 |
| pitti | so either the recommends is worthless (because apt will not auto-install missing ones), or we should really install it | 10:42 |
| pitti | seb128: right, I saw that | 10:43 |
| seb128 | pitti: well, python-coherence is useful but it'll not fit on the CD | 10:43 |
| seb128 | that's required to have upnp working | 10:43 |
| seb128 | and that will not easycodec install | 10:43 |
| pitti | right | 10:43 |
| pitti | seems we need some similar magic for plugged in hardware | 10:43 |
| seb128 | I don't like to demote it to a suggests much :-- | 10:43 |
| seb128 | :-( | 10:43 |
| pitti | (well, jockey is on the way to become this magic, but it's not there yet) | 10:44 |
| seb128 | pitti: that's not hardware, that's network devices | 10:44 |
| pitti | seb128: the question is not so much r: or s:, but rather whether we want to install it by default | 10:44 |
| seb128 | want yes, can is an another question | 10:44 |
| pitti | if we don't install it by default, the recommends: won't help anyone | 10:44 |
| seb128 | I think I looked at it before hardy | 10:44 |
| seb128 | installing python-coherence is an extra 11meg | 10:45 |
| seb128 | the one CD limitation is starting being really though :-( | 10:45 |
| seb128 | $ sudo apt-get install python-coherence | 10:46 |
| seb128 | After this operation, 5370kB of additional disk space will be used. | 10:46 |
| seb128 | on my intrepid | 10:46 |
| seb128 | and that's not a stock install so I might have some extra things already installed | 10:46 |
| cjwatson | pitti: NBS kernel metapackages> I'd been deliberately leaving them there so that we could see what needed to be replaced | 10:46 |
| pitti | seb128: python-louie is trivial and tiny, though; not sure what it does in RB, but that can easily be added | 10:47 |
| cjwatson | pitti: otherwise we'll have upgrade problems | 10:47 |
| seb128 | pitti: no, rhythmbox requires python-coherence to get that working, python-louie will not bring anything | 10:47 |
| seb128 | pitti: debian bug #474733 | 10:48 |
| ubottu | Debian bug 474733 in rhythmbox "rhythmbox: Please suggest python-coherence instead of python-louie" [Normal,Closed] http://bugs.debian.org/474733 | 10:48 |
| seb128 | pitti: well, I guess demote python-coherence to a suggest and remove python-louie if you want to change something | 10:49 |
| seb128 | I don't think we can afford that on the CD | 10:50 |
| pitti | seb128: right, will do; thanks | 10:50 |
| seb128 | thanks | 10:50 |
| seb128 | 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:51 |
| fabbione | 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 |
| fabbione | doko: unping.. problem solved | 10:52 |
| pitti | cjwatson: I filed bug 253904 about it, FYI | 10:52 |
| ubottu | Launchpad bug 253904 in linux-meta "does not build a lot of metapackages any more" [High,Triaged] https://launchpad.net/bugs/253904 | 10:52 |
| doko | fabbione: fine =) | 10:53 |
| pitti | fabbione: lol; not "spaghetti"? | 10:53 |
| seb128 | oh doko is there | 10:53 |
| pitti | doko: run! | 10:53 |
| seb128 | doko: did you read my question before? | 10:53 |
| fabbione | pitti: pizza was his first food related word... even before "Daddy" | 10:53 |
| * doko ducks and runs | 10:53 | |
| fabbione | pitti: pasta come in later.. no spaghetti yet.. too long ;) | 10:53 |
| pitti | fabbione: "noodles" then | 10:53 |
| fabbione | pitti: will try :) | 10:54 |
| seb128 | pitti: oh, http://bugzilla.gnome.org/show_bug.cgi?id=545828 | 10:54 |
| ubottu | Gnome bug 545828 in plugins "Add apport monitoring" [Enhancement,Unconfirmed] | 10:54 |
| pitti | seb128: rb built everywhere, FYI; grabbing and uploading | 10:54 |
| seb128 | mvo: ^ did you know about that? | 10:54 |
| seb128 | pitti: excellent ;-) | 10:54 |
| doko | seb128: hmm, no, looks like we have to patch to build two versions (like we do e.g. for subversion-svn) | 10:54 |
| seb128 | doko: "2 versions"? then we will have to patch other bindings to use the versionning correctly or something? | 10:55 |
| pitti | seb128: niice! looks very similat to what we have in update-notifier | 10:56 |
| doko | yes, but building just for one version will get us into upgrade hell ... | 10:56 |
| seb128 | 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 |
| mvo | seb128: no | 10:58 |
| doko | sure, can have a look. | 10:58 |
| mvo | 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 |
| mvo | soren: do you have any idea about this or got similar reports? | 10:59 |
| pitti | mvo: do we need apt-xapian-index in main/on the CD, or can we drop the synaptics recommends: to it? | 10:59 |
| mvo | soren: could be a local misconfiguraiton of course, but I would like to hear your opinion | 11:00 |
| mvo | pitti: we don't need it, it would be nice to have it though | 11:00 |
| seb128 | doko: http://people.ubuntu.com/~seb128/pygobject/ | 11:01 |
| pitti | mvo: 'nice to have' sounds like suggests:, not recommends: :) | 11:02 |
| pitti | 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:02 |
| mvo | 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 |
| pitti | 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:03 |
| mvo | pitti: so in summary I think we should have the xapian-index if possible (and CD space allows it) | 11:04 |
| pitti | mvo: answer to 'CD space allows it' is generally "no", I'm afraid | 11:04 |
| seb128 | I'm wondering if this "install recommends by default" makes sense if that just means demote most of the recommends to suggest | 11:05 |
| pitti | seb128: exactly my thought; it basically seesm that Debian wanted to get rid of recommends entirely | 11:05 |
| pitti | there might be a perfectly reasonable rationale behind it, I'm just not aware of it ATM | 11:06 |
| mvo | pitti: the extra space is in the range of ~1mb | 11:07 |
| mvo | pitti: its a perfect use-case for recommends, it should be installed (apt-xapaina-index) but it can work without | 11:08 |
| seb128 | mvo: we have lot of things which "should be installed" but the one CD limitation is though ... | 11:08 |
| mvo | pitti: where is that discussed (that debian wants to get rid of them entirely)? | 11:08 |
| mvo | 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 |
| Sikon | pitti> Thanks for moving batik out of multiverse | 11:09 |
| Sikon | fop can follow suit now, should I file a bug for it? | 11:09 |
| seb128 | 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 |
| seb128 | mvo: it basically means we need to drop all the recommends for packages on the CD | 11:10 |
| pitti | mvo: I don't know; but that's how it feels | 11:10 |
| pitti | Sikon: same rationale? I can just do it | 11:11 |
| mvo | 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 |
| Sikon | yes, same rationale - its only multiverse dependency was batik and now it's been moved | 11:11 |
| seb128 | mvo: right, that's what I asked before, <seb128> 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 |
| mvo | 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:12 |
| mvo | seb128: oh, I missed that | 11:13 |
| seb128 | they are useful | 11:13 |
| seb128 | and the idea rocks | 11:13 |
| seb128 | it just doesn't fit on the CD | 11:13 |
| mvo | 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:13 |
| mvo | seb128: and have a mode in synaptic (or somewhere else) that tells about the missing ones | 11:14 |
| seb128 | that would be cool | 11:14 |
| mvo | I think especially the bits in the installer (getting the list of not-installed recommends) is really straightforward | 11:14 |
| pitti | Sikon: moved, thanks | 11:16 |
| pitti | they'd still need to be in main, thuogh | 11:17 |
| pitti | we shouldn't in good faith Recommend: a package in universe | 11:17 |
| pitti | that would be saying "we want it, but then we don't" | 11:17 |
| * mvo agrees | 11:17 | |
| pitti | and the "do the post-install huge recommends: install" is both confusing and also user-unfriendly as well | 11:18 |
| pitti | 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 |
| seb128 | pitti: well, how do you solve things like the xapian index should be installed, or python-coherence so upnp is working? | 11:18 |
| mvo | 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:18 |
| mvo | but it sounds not too bad to me (moving to a bigger media is of course even better :) | 11:19 |
| pitti | seb128: my opinion is still that a bigger alternative install media is better than to inflict a 300 MB download right after installation | 11:19 |
| seb128 | right, my opinion too | 11:20 |
| persia | Maybe a 1GB USB stick? | 11:20 |
| seb128 | but previous times we had this discussion you were opposed to anything bigger than 1 CD | 11:20 |
| pitti | that's worse than downloading those extra 300 MB beforehand with the install media | 11:20 |
| seb128 | persia: yeah, that's what Scott suggested too already | 11:20 |
| pitti | seb128: oh, I still love the idea of having a CD | 11:20 |
| pitti | seb128: but I never opposed to us offering a DVD | 11:20 |
| pitti | *alternate* media :) | 11:21 |
| mvo | 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 |
| seb128 | 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 |
| pitti | the ubuntu-bells-and-whistles 2 GB images, if you can afford the download | 11:21 |
| pitti | 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 |
| persia | Also, CDs are cheap to hard out to random folk. | 11:22 |
| persia | s/hard/hand/ | 11:22 |
| seb128 | right, I'm not suggesting *dropping* the CD | 11:22 |
| Mithrandir | persia: I don't see a price difference between CD and DVD media here. | 11:22 |
| pitti | e. g. xapian index is exactly the case how it should not be | 11:22 |
| seb128 | but maybe 1 CD installs should not be the recommended media for desktop installs | 11:23 |
| persia | 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 |
| seb128 | if we think we are degrading the user experience due to the CD space limitation | 11:23 |
| pitti | 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 |
| pitti | Mithrandir: the download size difference matters a lot, though | 11:23 |
| seb128 | pitti: that's not only xapian index, that's upnp not working in rhythmbox for example | 11:24 |
| pitti | right | 11:24 |
| Mithrandir | 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 |
| mvo | 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 |
| pitti | seb128: that's why I'm so opposed to webkit, for example | 11:25 |
| Mithrandir | pitti: sure, just saying that I don't think price of media is much of a factor here at least. | 11:25 |
| pitti | seb128: because webkit doesn't give the user *any* benefit ATM, it just takes CD space | 11:25 |
| seb128 | pitti: well, that's not up to us though | 11:25 |
| pitti | I know that this isn't exactly our fault | 11:25 |
| pitti | it's an upstream decision | 11:26 |
| pitti | but from the user's POV that doesn't matter | 11:26 |
| seb128 | and it makes sense for them | 11:26 |
| seb128 | that's an orthogonal issue anyway | 11:26 |
| pitti | it's not for the topic of what we use our precious CD space for, IMHO | 11:27 |
| seb128 | there is no "we" there since we don't lead upstream work and have no say in their decisions | 11:27 |
| seb128 | we have no real choice there, either we ship what they do or we fork the code and maintain it | 11:27 |
| pitti | well, in cases where all the distros say "no", they'd reconsider for sure | 11:28 |
| seb128 | not sure | 11:28 |
| pitti | 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 |
| seb128 | and all distros will not say no | 11:28 |
| seb128 | well, that's not a matter of how many gbs | 11:28 |
| seb128 | GNOME use only only webkit | 11:29 |
| seb128 | we are the one who decided to ship firefox and not epiphany-browser | 11:29 |
| pitti | (but there might be a correlation why millions of people download Ubuntu CDs, and magnitudes fewer download SuSE DVDs) | 11:29 |
| seb128 | -only | 11:29 |
| pitti | seb128: hm, that's a good point actually | 11:29 |
| sladen | pitti: ...being left alone is a *unique selling point* | 11:30 |
| pitti | seb128: replacing ffox by epy by default is something that we could do | 11:30 |
| davmor2 | pitti: I wouldn't do it yet there are som major flaws at the moment still :( | 11:31 |
| seb128 | right, but we will not likely due because firefox is known, etc and users will want to use it | 11:31 |
| sladen | but "mindshare" means that it would not be wise | 11:31 |
| mvo | plugins is another common reason cited for using ff | 11:31 |
| sladen | 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 |
| persia | A number of plugins work with epiphany-browser in hardy. Does that go away with webkit? | 11:33 |
| pitti | persia: I'd think so | 11:33 |
| seb128 | well, webkit is not there yet | 11:34 |
| persia | pitti: That would be a bug. I'm an epiphany user, but appreciate the current featureset. | 11:34 |
| seb128 | but it's getting there so maybe next cycle | 11:34 |
| pitti | persia: which brings me back to GNOME prematurely dropping xul support :) | 11:35 |
| persia | heh | 11:35 |
| seb128 | persia: they still didn't make epiphany-webkit the default, they expect that to be ready for GNOME 2.26 (intrepid+1) | 11:35 |
| seb128 | pitti: they didn't drop it for epiphany-browser actually | 11:35 |
| davmor2 | seb128: even if webkit is epiphany isn't using it to it's greatest advantage yet :( | 11:35 |
| pitti | seb128: ah, *phew* :) | 11:35 |
| seb128 | but webkit is good for desktop applications | 11:35 |
| persia | seb128: So epiphany will ship both epiphany-webkit and epiphany-gecko? | 11:35 |
| seb128 | persia: it does in intrepid yes | 11:36 |
| pitti | seb128: what happens to gtkhtml, BTW? we still ship that as well | 11:36 |
| seb128 | pitti: going to be remplaced by webkit too | 11:36 |
| pitti | good | 11:36 |
| persia | So webkit doesn't need to be on the CDs for intrepid? | 11:37 |
| seb128 | persia: yelp will likely use it but we can hold back to the current version if we want to | 11:37 |
| persia | Let's do that. WIth such a plan we can delay the webkit discussion until upstream has caught up with itself. | 11:38 |
| seb128 | 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 |
| pitti | 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:38 |
| pitti | mvo: unfortunately we seldomly have the power to decide that for the entire distro, sure | 11:39 |
| pitti | but we should still strive to do that | 11:39 |
| seb128 | 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 |
| pitti | mvo: so in terms of apt, if xapian is the way to go, then let's use it, and use *just* it | 11:39 |
| seb128 | pitti: but that doesn't mean we will make all the feature we need to fit on one CD | 11:39 |
| pitti | otherwise we have to test and support systems with both alternatives, which doesn't make things easier | 11:39 |
| pitti | 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 |
| pitti | and wasting space is all too easy if your install media is unlimited | 11:40 |
| seb128 | right, agreed | 11:40 |
| pitti | 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:41 |
| pitti | 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 |
| pitti | and I'm just afraid that it'd cost us a *lot* of users to just have DVDs | 11:42 |
| Ng | 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 |
| sladen | first boot of this laptop (the auto vista install) took 1.5hours. The Ubuntu install took 11minutes | 11:42 |
| Ng | I figured that 20gb was a bit much to update my phone firmware, and gave up ;) | 11:43 |
| persia | sladen: Just boot first with the livecd. Saves time. | 11:43 |
| sladen | and the Ubuntu install did more out of the box... | 11:43 |
| sladen | persia: cough. lack of CD drive | 11:43 |
| sladen | persia: so I wubi'ed it with the lack of anything else to hand to netboot | 11:44 |
| Ng | (although XP fits fine in 2GB, it has to be said) | 11:44 |
| pitti | someone (Keybuk?) raised the idea of an 1 GB usb stick image | 11:44 |
| pitti | I actually quite like that | 11:44 |
| sladen | 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 |
| seb128 | pitti: yes, that was Scott | 11:45 |
| persia | 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 |
| pitti | sladen: full ack | 11:45 |
| seb128 | 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:45 |
| seb128 | pitti: 1Gb keys would be nice indeed | 11:46 |
| persia | There's also a work-in-progress wizard to put a USB image onto the stick, which ought make intrepid. | 11:46 |
| pitti | persia: yep, ogra uploaded it a week or two ago | 11:46 |
| persia | pitti: Yep. Should come back to you next week. | 11:47 |
| === RainCT is now known as RainCT_ | ||
| joaopinto | Hello, any archive admin available for a licensing question ? | 11:51 |
| pitti | joaopinto: just ask the question, please | 11:52 |
| joaopinto | I am packaging game, the source code is distributed under GPL, the artwork is distributed "Free Art License" | 11:53 |
| mvo | 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:53 |
| pitti | mvo: well, "explain" -> that's just my feeling | 11:54 |
| pwnguin | joaopinto: the guidelines we use are often called "DFSG" | 11:55 |
| * pitti apologizes for being in such an argumentative mood today and hugs seb128 and mvo | 11:55 | |
| * seb128 hugs pitti, nothing to apologize about, that's a good discussion to have | 11:56 | |
| pitti | mvo: why not for apt-cache then? wouldn't that still mean to have two backends to care about? | 11:56 |
| pitti | mvo: e. g. the normal apt cache and the xapian db? | 11:56 |
| joaopinto | pwnguin, I have read the FAL license, it seems fine except for the GPL incompatibility (as per GNU's assessment), does the DFSG addresses license compatibility ? | 11:57 |
| pitti | mvo: out of interest, what would that speed up in particular? | 11:57 |
| mvo | pitti: I don't think that would go well in debian to force it on people, apt-xapian-index creates a index that is roughtly equal in size to the package lists (unpacked) and it takes ~1-2min to build the index. as far as maintainace costs are concerned, that is not too bad, the xapaian code is small and all the heavy lifting is done by the libxapian. so I think that is ok | 11:58 |
| mvo | pitti: it makes the full text search over name and description fast. if you run synaptic and do a search for name+descrption that takes a couple of seonds (its not too bad) | 11:58 |
| pitti | mvo: well, but then you have that huge index *and* the other apt cache... | 11:58 |
| mvo | pitti: if you install the apt-xapian-index, then the result are there instantly | 11:59 |
| pwnguin | joaopinto: im browsing debian-legal's archives now. GNU's incompatibility may or may not matter, but there's a question of whether FAL discriminates against business or corporate use | 11:59 |
| pitti | mvo: hm, apt-cache search only takes < 2 seconds, too? | 11:59 |
| mvo | pitti: right, the other apt cache is not primarely concerned with name+description, it contians the dependency information (that is the primary aim for it) | 11:59 |
| mvo | pitti: right, apt-cache is pretty fast, however for search-as-you-type it is not fast enough | 12:00 |
| mvo | pitti: again, its a "nice-to-have", we certainly do not need search-as-you-type, we could do without just fine | 12:00 |
| pitti | right (especially since you don't usually install ten packages every day) | 12:00 |
| pwnguin | joaopinto: if this game isnt brand new, there may already be a conversation about it on debian-legal. however i believe that ubuntu does choose to adopt some things debian does not, so don't give up hope! | 12:02 |
| pitti | so that again seems to be the inconsistency between "we don't want to force it to all people, but then again everyone should have it" | 12:02 |
| mvo | pitti: agreed, I have no particularly strong opinion on this, I'm fine with demoting it if we don't want to trade this feature for the cd space | 12:02 |
| joaopinto | pwnguin, there is no such restriction, in fact it's own compatibility requirements includes the ability to distribute for comercial purposes | 12:02 |
| pwnguin | joaopinto: the FAL uses phrases that could be construed as anti corporate, but not anticommercial | 12:03 |
| pitti | joaopinto: GPL/FAL incompatibility shouldn't matter for things like code/artwork, since they are not linked together (in the .so lib sense); unless it's .xpms, of course | 12:03 |
| mvo | pitti: I don't see a inconsitency here. from my upstream perspective it is something I want everybody to use because it is cool and makes a good impression and is useful. however I understand from the distro perspective that we need to balance space and features | 12:03 |
| mvo | (or maybe I misunderstoof it?) | 12:04 |
| pitti | mvo: you meant that you wouldn't put it into Debian by default, and rather maintain two backends instead of one, and then install both? that's the bit that seems inconsistent to me | 12:07 |
| pitti | if xapian rocks, then let's get rid of the huge /var/lib/apt/lists/ dir and just use the xapian db everywhere | 12:08 |
| pitti | and if it doesn't rock, then we shouldn't install it by default | 12:08 |
| mvo | pitti: debian will have synaptic: recommends. apt-xapaian-index and that will get installed by default | 12:08 |
| mvo | pitti: xapian is only about text search, the lists/ dir is still required for the building of the cache information | 12:08 |
| pitti | mvo: ah, and that can't be put into the xapian db? | 12:09 |
| mvo | pitti: no, xapian is really only a text-indexer/searcher, its not a general purpose db | 12:09 |
| pitti | (fulldisclosure: I have no idea what xapian does exactly) | 12:09 |
| mvo | :) | 12:09 |
| mvo | maybe the "xapaian is just a text-indexer" was the missing bit then :) | 12:10 |
| mvo | ok, so for cd space reason we don't add the fast search for now? | 12:12 |
| pitti | if we can free up some space, and it is generally considered a good feature, we should by all means discuss it, but personally I'm inclined to say no because it doesn't seem to be the most urgent thing | 12:15 |
| * pitti stops sobbing at http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt and toddles off to lunch | 12:16 | |
| pitti | which is always a good approach to hopeless problems which take a manweek to sort out :) | 12:16 |
| mvo | hmm, luch. a good idea :) | 12:16 |
| mvo | just as a data point for the discussion, the currnet live-cd (with universe enabled) requires additional 20mb of download if recommends are enabled | 12:20 |
| mvo | some of those can be trimmed down (e.g. synaptic recommends deborphan which it really shouldn't anymore) | 12:21 |
| pitti | yeah, it was already heavily trimmed down | 12:22 |
| pitti | mvo: and we can substract gst-plugins-{bad,ugly} in good faith, too, because of easy-codec-install | 12:22 |
| lifeless | james_w: see my link in backlog ? | 12:24 |
| james_w | lifeless: yeah, thanks. | 12:24 |
| james_w | I've spoken to Federico about something similar before, interesting to see where he went with it. I haven't looked at the code though | 12:25 |
| pitti | TheMuso: do you think denemo should stay in main? if so, it needs MIRs for lilypond, csound, and aubio | 12:26 |
| pitti | TheMuso: I'm asking because I'm not 100% sure whether ubuntustudio is built from universe or just main | 12:26 |
| persia | pitti: From universe | 12:28 |
| persia | Unless something outside studio needs it, no need to stay in main | 12:28 |
| pitti | oh, seens that edubuntu-desktop depends on it, too | 12:28 |
| pitti | ogra: ^ that's built from main, right? | 12:29 |
| persia | pitti: Yes, edubuntu is main | 12:29 |
| ogra | yup | 12:29 |
| ogra | mainly fo writing musical annotation though, i dnt know why it now depends on the sequencer stuff | 12:30 |
| pitti | ogra: so, if you can/want to afford the space, they don't seem too bad for main (haven't looked in detail, but sound quite harmless) | 12:32 |
| persia | ogra: Recommends. It likes lilypond as a front-end, and that gets csound (for reasons I don't understand). I'm not sure about aubio | 12:32 |
| ogra | pitti, i have 400M fee, feel free to drop anything on me you like ;) | 12:32 |
| ogra | *free | 12:33 |
| pitti | ogra: heh | 12:33 |
| ogra | pitti, btw, ltsp will need sshfs, anythin you could think of that would block it from main fom the top of your head ? | 12:33 |
| ogra | (and from the CD indeed) | 12:34 |
| pitti | ogra: that's the fuse layer over ssh, right? | 12:34 |
| ogra | yep | 12:34 |
| ogra | the new localdev implementation we developed last week will need it | 12:34 |
| pitti | ogra: if the gvfs ssh backend doesn't work for you at all, it doesn't sound too crazy | 12:35 |
| ogra | no gvfs on the clients ... to heavy deps | 12:35 |
| pitti | if you want to own it? | 12:35 |
| ogra | i can, yes | 12:35 |
| pitti | should not take a lot of maintenance; if it works for you, fine | 12:36 |
| ogra | great, i'll file a MIR during the day | 12:36 |
| pitti | fta: do you think the "Recommends: cvs, mercurial" recommends of mozilla-devscripts can become suggests:? they aren't needed for using m-d as a build dependency, and mercurial would need a MIR; also, a developer will notice pretty fast that he needs to install mercurial (command-not-found helps there, too) | 12:48 |
| fta | pitti, hm, sure. no problem | 12:50 |
| pitti | fta: thanks; (sorry, I can't commit to the branch, it's owned by ~mozillateam | 12:51 |
| fta | i will do it | 12:51 |
| pitti | fta: but I'm happy to check it out and sponsor the upload for you, if you want | 12:51 |
| fta | ok, i will let you know if i need a sponsor (depends on what else is in the pipe and if asac is responsive) | 12:52 |
| === thekorn_ is now known as thekorn | ||
| === pbn_ is now known as pbn | ||
| TheMuso | pitti: Ubuntustudio is built from universe, I wasn't the one who requested denemo be in main. | 14:02 |
| pitti | TheMuso: ok, thanks | 14:02 |
| tkamppeter | pitti, I did not find it by the search function of Synaptic, which package do I need to install to get the German locale? | 14:06 |
| pitti | tkamppeter: if you *just* need the locale, you can "sudo locale-gen de_DE.UTF-8" | 14:06 |
| pitti | tkamppeter: but usually you would install language-pack-gnome-de | 14:06 |
| pitti | tkamppeter: and a real GUI lover would use system -> admin -> languages and click on "German" :) | 14:07 |
| tkamppeter | pitti, thanks. | 14:07 |
| tkamppeter | pitti, and now the more difficult question: | 14:07 |
| tkamppeter | I want to build Gutenprint with I18ned PPDs. Upstream tells me that I need the locale for every language supported by Gutenprint (~20 languages). | 14:08 |
| tkamppeter | How do I proceed there? | 14:09 |
| tkamppeter | Especially to avoid installing language-pack-gnome-?? into a pbuilder chroot. | 14:09 |
| tkamppeter | I cannot put "sudo locale-gen ??_??.UTF-8" into the Build Dependencies. | 14:10 |
| ogra | tkamppeter, there is a "language-pack-base" it could probably go into that one instead | 14:11 |
| pitti | ogra: no, that's still per-language | 14:12 |
| ogra | pitti, ah, you want to have it completely independent | 14:12 |
| pitti | tkamppeter: why do you need locales for using gettext/whatever for translating PPDs? | 14:12 |
| pitti | tkamppeter: anyway, you could create them locally into a temporary directory by iterating over /usr/share/i18n/SUPPORTED | 14:13 |
| pitti | tkamppeter: ah, for having correct representations of number formats, and so on? | 14:13 |
| tkamppeter | pitti, I do not know the internals of the build system of Gutenprint ... | 14:14 |
| ogra | seb128, i had some complaints from intrepid ltsp users that things in /media/$USER/device dont get catched by gvfs anymore, did anything change in there wrt monitoring /media ? | 14:15 |
| seb128 | ogra: "catched"? | 14:15 |
| ogra | well, they dont show up on the desktop/in places and dont open a nautilus window | 14:16 |
| ogra | but are mounted in /media/$USER/<device> as before | 14:17 |
| pitti | hm, for me it's the other way around | 14:18 |
| pitti | I get two icons and nautilus windows, plus an error message, for each device I plug in | 14:18 |
| ogra | you dont mount in subdirs though | 14:18 |
| ogra | ltspfs is always been kind of special here dur t being multi user | 14:19 |
| ogra | *due to | 14:19 |
| seb128 | pitti: that's bug #251991 and fixed in svn | 14:20 |
| ubottu | Launchpad bug 251991 in gvfs "Mounted USB harddrive showes twice on the desktop - right click one of the icons and choose "Unmount Volume" results in error "DBus error org.gtk.Private.RemoteVolumeMonitor.NotFound: The given mount was not found"" [High,Fix committed] https://launchpad.net/bugs/251991 | 14:20 |
| pitti | seb128: nice, thanks | 14:20 |
| seb128 | ogra: no, no idea but there is too much to track at the moment for me so I might just not have read about it yet | 14:20 |
| ogra | seb128, i was assuming its still to much in flux ... i'll ping you later in the cycle if it still happens then | 14:21 |
| seb128 | ogra: alright, thank you | 14:21 |
| ogra | stgraber, ^^^^ | 14:21 |
| seb128 | the current gvfs is known to have issues, cf the bug I pointed to pitti, they just did changes to the monitor process and the gphoto create conflicts | 14:22 |
| seb128 | the next version which is due next week should fix some issues | 14:22 |
| ogra | i'm just worried they drop the subdir monitoring .... | 14:23 |
| ogra | that was a big advantage beyond other ways (thunar, KDE) for ltsp | 14:23 |
| ogra | but we'll see what they'll do ... | 14:24 |
| seb128 | there is no "subdir" monitoring | 14:26 |
| seb128 | gvfs does the mounting when devices are plugged and watch /proc/mounts otherwise | 14:26 |
| ogra | it did monitor /media before | 14:27 |
| ogra | additionlly to the above | 14:27 |
| seb128 | ogra: monitor to do what? | 14:27 |
| ogra | if i created a dir there it showed up as device | 14:27 |
| seb128 | mounts are listed in /proc/mounts | 14:27 |
| seb128 | it never added a location because I did a "mkdir /media/something" | 14:27 |
| seb128 | no | 14:27 |
| pitti | mvo: rejecting your libgksu SRU upload, there's no bug in the changelog | 14:27 |
| ogra | no, but if we did a bind mount to /media | 14:27 |
| norsetto | ouch, that hurts :-) | 14:28 |
| ogra | or a subdir | 14:28 |
| ogra | as well as move mounts | 14:28 |
| seb128 | ogra: are you sure those are not listed in /proc/mounts? | 14:28 |
| ogra | (we switched ltspfs between gutsy and hardy from bind to move mounts) | 14:28 |
| ogra | no, i'm not | 14:28 |
| ogra | i'll check that | 14:29 |
| seb128 | anyway gio and gvfs didn't drop anything that I know in intrepid | 14:29 |
| ogra | fact is that the current implementation doesnt pick them up | 14:29 |
| seb128 | but I doubt they were monitoring subdir in media | 14:29 |
| ogra | but lets postpone the discussion until upstrem is evolved further :) | 14:30 |
| ogra | i dont want to waste your time on something upstream hasnt made ready yet | 14:31 |
| seb128 | ogra: _g_get_unix_mounts () basically uses setmntent () getmntent () to go through the mounts | 14:31 |
| seb128 | alright | 14:31 |
| mvo | pitti: meh, sorry :( there will be a day when I learn it I hope | 14:41 |
| mvo | pitti: I upload a new version :) | 14:41 |
| pitti | mvo: danke | 14:41 |
| Riddell | mvo: app-install-data doesn't seem to have KDE apps any more, probably it needs the changes done for hardy removed | 14:51 |
| mvo | Riddell: oh? let me check. I did some kde/kde4 changes | 14:52 |
| mvo | Riddell: it seems that all of kde4 is here in gnome-app-install, I'm not sure about kde3 | 14:55 |
| Riddell | mvo: hmm, so it is, never mind me then, I'll look into why it's not appearing | 14:59 |
| Riddell | mvo: able to look at gdebi at some point? | 14:59 |
| mvo | Riddell: is it in adept? | 14:59 |
| Riddell | mvo: adept 3 (of which new alpha just appeared in mornfall's PPA) | 15:00 |
| mvo | Riddell: yes, it looks good (gdebi-kde), I want to do some more testing before I merge it | 15:00 |
| Riddell | it's not appearing though | 15:00 |
| mvo | Riddell: ok | 15:00 |
| === RainCT_ is now known as RainCT | ||
| seb128 | doko: did you look at the pygobject update? | 15:19 |
| doko | seb128: working on it. you basically need to have a different soname for each library and install these separately | 15:20 |
| seb128 | ok, I see | 15:21 |
| seb128 | thanks for working on that, we will need it to update some GNOME components to the current versions | 15:21 |
| doko | but automake doesn't allow macros in these lib_ macros, and libtool ignores my own -Wl option :-( | 15:23 |
| alex-weej | mvo: something up with notification-daemon? standard became the default theme with my last update i think | 15:49 |
| norsetto | anybody knows if asac is on holidays? | 15:51 |
| seb128 | alex-weej: are you sure you didn't switch themes the appareance capplet? | 15:52 |
| seb128 | norsetto: yes until monday | 15:52 |
| alex-weej | seb128: not 100% -- does that now affect the notification theme?! | 15:52 |
| norsetto | seb128: ah ok, guess I can wait then, thx | 15:52 |
| seb128 | alex-weej: the appareance capplet has notification themes support now, it seems some themes set that to GNOME but we didn't update the ubuntu theme to list a notification theme yet | 15:53 |
| seb128 | alex-weej: so the key might have been switched and not switched back there | 15:53 |
| alex-weej | seb128: yes that is correct | 15:53 |
| alex-weej | i forgot how ugly the standard theme was | 15:54 |
| seb128 | alex-weej: set /apps/notification-daemon/theme to "ubuntu" | 15:54 |
| alex-weej | yeah got it | 15:54 |
| mvo | alex-weej: oh? that should not be the case, let me check | 15:54 |
| alex-weej | mvo: see above! | 15:54 |
| mvo | alex-weej: aha, ok | 15:55 |
| mvo | thanks seb | 15:55 |
| mvo | thanks seb128 | 15:55 |
| seb128 | np ;-) | 15:56 |
| seb128 | mvo: you are welcome to update human-theme to add the "NotificationTheme=ubuntu" line though ;-) | 16:17 |
| mib_bfeqw2 | tseliot: around? :) I'm sebner. already time to look at my xorg.log? | 16:23 |
| tseliot | mib_bfeqw2: no, sorry I'm working on other stuff. I'll get back to you ASAP | 16:29 |
| mib_bfeqw2 | tseliot: kk, thx | 16:31 |
| jdstrand | mvo: hi! | 16:43 |
| kirkland | pitti: hi there- i was wondering if you might take another look at the MIR for ecryptfs-utils again soon? | 16:43 |
| jdstrand | mvo: so I was installing an intrepid schroot the other day, and apt didn't get installed. So then I copied apt to /tmp, and dpkg -i'd it, and thought things were ok, until today, I see: | 16:43 |
| jdstrand | debconf: delaying package configuration, since apt-utils is not installed | 16:44 |
| jdstrand | dpkg: syntax error: unknown group `Debian-exim' in statoverride file | 16:44 |
| jdstrand | E: Sub-process /usr/bin/dpkg returned an error code (2) | 16:44 |
| jdstrand | mvo: so I try to install apt-utils, but get the same error. what is the best way to get apt-utils installed? (I didn't see an option to dpkg that was applicable, but maybe I'm blind) | 16:45 |
| tseliot | pitti: xkit 0.3.1 is available (revision 17) in my bzr branch. The ParseException is back (and a sensible sanity check is performed now) but I haven't had the time to plan the migration to x-kit of some of the code in Jockey. | 16:45 |
| doko | seb128: http://people.ubuntu.com/~doko/tmp/pygobject.debdiff ugly, I know. have to run now. but the idea should be clear. didn't figure out why it's rebuilt all the time ... | 17:04 |
| kirkland | pitti: i see it's been approved, thanks! | 17:04 |
| seb128 | doko: thanks! | 17:05 |
| === krusaf|bnc is now known as krusaf | ||
| === fta_ is now known as fta | ||
| mathiaz | slangasek: so what's your pov about openldap 2.4.11 ? | 18:11 |
| mathiaz | slangasek: IIUC it won't happen in lenny | 18:12 |
| sebner | tseliot: mail sent :) | 18:43 |
| warren | ogra: around? | 18:55 |
| slangasek | mathiaz: well, it's not definite that it won't happen in lenny; there's at least one important bugfix we should still get for lenny | 18:56 |
| slangasek | so depending on how much else there is, it may be easier to just push the new upstream version in | 18:57 |
| slangasek | mathiaz: but I also don't think we need to wait for it to be accepted into Debian before revving in Ubuntu, under the circumstances | 18:57 |
| mathiaz | slangasek: I've talked with dendrobates about this - it seems that we'll diverge from debian within the intrepid timeframe | 18:59 |
| ogra | warren, yeps | 18:59 |
| slangasek | mathiaz: most likely, yes | 18:59 |
| warren | ogra: so upstream nspuginwrapper has failed for a long time now to create an upstream devel list | 18:59 |
| warren | ogra: making it impossible for developers to collaborate around it | 18:59 |
| mathiaz | slangasek: there is some code in the cn=config branch that I could drop for intrepid that is still needed in debian | 18:59 |
| warren | ogra: so I'm just going to create one | 18:59 |
| warren | ogra: would your nspluginwrapper maintainer be averse to joining my list? | 19:00 |
| ogra | warren, make sure to invite asac then | 19:00 |
| mvo | jdstrand: sorry, I missed your ealier question. it seems like for some reason your have a incorrect /var/lib/dpkg/statoverride entry in your schroot | 19:00 |
| mathiaz | slangasek: so I may just move on in intrepid and we'll sync again once lenny/intrepid are released | 19:00 |
| ogra | warren, i'm sure he wouldnt | 19:00 |
| slangasek | mathiaz: hmm, I'm skeptical of whether dropping code that we don't need, but Debian does, is worthwhile from a maintenance POV :) | 19:00 |
| mvo | jdstrand: could you please open that file and check for a line with "Debian-exim" there? | 19:00 |
| mathiaz | slangasek: aggreed - however that could would be dropped once lenny is released anyway | 19:01 |
| mathiaz | slangasek: that *code* | 19:01 |
| ogra | warren, but as i said, he's at the mozilla conf this week ... Alexander Sack <asac at ubuntu dot com> | 19:01 |
| ogra | warren, he was in #ltsp for a while when we poked at the pulse bugs ... you met already | 19:02 |
| mathiaz | slangasek: or do you think that keep supporting slapd.conf in debian is an option ? | 19:02 |
| warren | nod | 19:02 |
| slangasek | mathiaz: I don't think so, but I need to wait for my comaintainers to come around to the same opinion on their own :) | 19:02 |
| slangasek | and if they take too long, we might slip past the window for doing this in lenny | 19:03 |
| slangasek | (which would be unfortunate, indeed | 19:03 |
| slangasek | ) | 19:03 |
| jdstrand | mvo: it's the only line in there | 19:04 |
| jdstrand | root Debian-exim 0640 /etc/exim4/passwd.client | 19:04 |
| mathiaz | slangasek: hm - so my current plan for intrepid is to upload 2.4.11 *and* enable the cn=config migration | 19:05 |
| mvo | jdstrand: could you try deleting that line and see if that cures the issue? I have no idea how this line came into that file though :) | 19:05 |
| mvo | jdstrand: is exim4 installed in the chroot? | 19:06 |
| jdstrand | mvo: yes-- it was a brand new schroot built with mk-sbuild-lv that ended up without apt | 19:07 |
| mvo | jdstrand: ok, I know now that the exim4 pakcage installs that line | 19:07 |
| mathiaz | slangasek: do you have another opinion/suggestion on that subject ? | 19:07 |
| jdstrand | mvo: that did solve the problem, and I sould install apt-utils | 19:07 |
| mvo | jdstrand: does your /etc/group contain Debian-exim (I guess not)? | 19:07 |
| jdstrand | mvo: no | 19:07 |
| slangasek | mathiaz: nope; that seems to be the correct course of action | 19:08 |
| slangasek | mathiaz: are we converged on what we think cn=config migration should look like, now? i.e., we've addressed any concerns about being able to re-sync after lenny/intrepid? | 19:09 |
| mathiaz | slangasek: I've sent my latest patch | 19:09 |
| mathiaz | slangasek: there are some issue you've raised wrt to new templates questions | 19:09 |
| jdstrand | mvo: do you think this might have prevented apt from being installed in the first place? (I've long lost the log) | 19:10 |
| slangasek | yes, I haven't read in enough depth yet to see if there's anything significant that you disagree with me on :) | 19:10 |
| mvo | jdstrand: is exim4 still installed in the chroot? the exim4-config postinst creates both the Debian-exim group and the statoverride | 19:10 |
| mathiaz | slangasek: I think we should explictely ask for the cn=config password as it's a big change | 19:10 |
| mathiaz | slangasek: so that users know that their installation has been migrated | 19:11 |
| mvo | jdstrand: that is something strange for sure (that apt did not get installed). do you have some setup where getent passwd DEbian-exim would return "true" in your chroot? nis/ldap or somesuch? | 19:11 |
| mathiaz | slangasek: I don't think that trying to extract the admin password from an existing database is worth the trouble | 19:11 |
| slangasek | mathiaz: oh, that was one point I was going to respond on - I really don't see the use of a separate debconf question for the /crypted/ admin password, since we're only ever storing one crypted password in debconf at a time | 19:11 |
| mvo | jdstrand: that might explain it, there is a check if the group needs to be added or if it is there already in the exim4-config postinst | 19:11 |
| jdstrand | mvo: it is, I just dpkg-reconfigure'd it and it was added | 19:12 |
| jdstrand | mvo: needless to say, I don't have a lot of faith in this chroot ;) | 19:12 |
| mathiaz | slangasek: well - there are two scenarios to be supported: new installs, in which case the debconf question is asked only once and the password is used both in cn=config and the default directory | 19:13 |
| mvo | jdstrand: heh :) I can understand that | 19:13 |
| mathiaz | slangasek: the second scenario is on upgrades | 19:13 |
| mathiaz | slangasek: you'd suggest to use the same question in that case ? | 19:13 |
| jdstrand | mvo: I'm going to try to see if the latest intrepid happened to fix this, to see if it is transient of not. | 19:13 |
| slangasek | mathiaz: the same question for the /crypted/ password, yes; rather than having two separate internal questions, when we only ever use one at a time | 19:14 |
| jdstrand | mvo: I can say it was repeatable on the day I tried to set it up | 19:14 |
| mvo | jdstrand: ok, let me know your findings, that is definitely a strange problem | 19:14 |
| slangasek | mathiaz: it's a minor point, but it will simplify a little; and if there's no reason conceptually that we want these two passwords to be different, I think it's cleaner | 19:14 |
| jdstrand | mvo: agreed. thanks! :) | 19:14 |
| mathiaz | slangasek: aggreed -so the goal would be to get rid of cfgadminpasswd | 19:15 |
| slangasek | mathiaz: slapd/internal/cfgadminpw, yes | 19:15 |
| mathiaz | slangasek: however, we still need to have an internal template to keep track that we've asked for the admin password when migrating on upgrade | 19:15 |
| mathiaz | slangasek: I've tried to use on adminpw and then I was asked three times to enter the password | 19:16 |
| mathiaz | slangasek: adminpw wipes the password, but the seen flags needs to be reset to false on upgrade | 19:16 |
| mathiaz | slangasek: but that has to be done only once | 19:16 |
| slangasek | hmm, I don't understand how that would happen; can you show me the code? | 19:17 |
| jcristau | mvo: maybe schroot copies /etc/{group,passwd,...} from the host? | 19:17 |
| mathiaz | slangasek: let me search for the code | 19:17 |
| jcristau | mvo: so if exim isn't installed there, the group doesn't exist, and dpkg goes boom | 19:18 |
| jdstrand | jcristau: I would expect it to go boom on all my schroots then-- I recreated dapper-intrepid on that day, and only intrepid failed | 19:19 |
| jcristau | jdstrand: does exim install the statoverride in other versions too? | 19:19 |
| jcristau | hrm, looks like it does | 19:20 |
| jdstrand | jcristau: dapper didn't | 19:20 |
| jdstrand | hardy didn't | 19:21 |
| jdstrand | I wonder if this has to do with pulling in Recommends automatically... | 19:21 |
| jdstrand | none of the others have exim | 19:21 |
| askand | Where is it defined what folders should be in the homefolder on instal? | 19:22 |
| jdstrand | mvo, jcristau: new intrepid schroot is still broken | 19:22 |
| jdstrand | mvo: interesting-- there is no 'I: Retrieving apt' line | 19:23 |
| mathiaz | slangasek: http://bazaar.launchpad.net/%7Emathiaz/openldap/debian-cnconfig/annotate/224?file_id=877%40dce93848-5eb8-0310-a98f-f2b027ff39d8%3Aopenldap%252Ftags%252Ftrunk-2.3%3Adebian%252Fslapd.config | 19:24 |
| jdstrand | mvo: http://paste.ubuntu.com/33072/ | 19:24 |
| mathiaz | slangasek: http://tinyurl.com/6hdvl2 | 19:25 |
| mathiaz | slangasek: that's the version of slapd.config I ended up with before I introduce cfgadminpwd | 19:25 |
| jdstrand | mvo: there there is no Debian-exim statoverride entry. so I must have done something when I added apt before (I don't know what though) | 19:27 |
| jdstrand | mvo: that's it-- debootstrap 1.0.10 doesn't install apt | 19:33 |
| jdstrand | (for intrepid) | 19:34 |
| slangasek | mathiaz: hmm, maybe I'm not explaining myself clearly, then | 19:34 |
| slangasek | mathiaz: here's what I'm thinking: | 19:34 |
| slangasek | mathiaz: keep a separate debconf question (with different text, etc.) to use for prompting the user for a password | 19:34 |
| slangasek | mathiaz: but when /encrypting/ the password, use the same internal question to store it | 19:35 |
| slangasek | I think that avoids the issue you were having before? | 19:35 |
| mathiaz | slangasek: I think so | 19:35 |
| jdstrand | mvo: eg $ sudo debootstrap --variant=buildd --arch i386 intrepid ./intrepid http://127.0.0.1/ubuntu/ -> no apt | 19:37 |
| jdstrand | sid and hardy work | 19:37 |
| jdstrand | and it's just with --variant=buildd on intrepid | 19:38 |
| jdstrand | mvo: I just filed bug #254042, but seems it is more of a dependency problem with Build-Essential | 19:46 |
| ubottu | Launchpad bug 254042 in debootstrap "debootstrap does not install apt with --variant=buildd for intrepid chroot" [Undecided,New] https://launchpad.net/bugs/254042 | 19:46 |
| mvo | jdstrand: thanks, I check it out | 19:50 |
| kees | mvo: say, can you update the libcap library in debian? 2.12 is current, I think. | 19:54 |
| mvo | kees: there is a libcap2 package that has 2.11 | 20:01 |
| kees | mvo: oh. heh. yeah, that works. :P | 20:01 |
| mvo | I need to check if we can not just drop the libcap1 stuff | 20:02 |
| kees | mvo: one of the cap upstreams is in #ubuntu-hardened (hallyn) if you have any questions. | 20:04 |
| mvo | kees: cool, thanks. good to know | 20:05 |
| mvo | blueyed: hello! good to see you :) have you seen my question regarding the crash of update-manager with the virtualbox-ose package? | 20:05 |
| blueyed | mvo: just answered. | 20:05 |
| mvo | blueyed: cool, thanks! | 20:06 |
| blueyed | mvo: hope it helps.. I'm not really sure, since the traceback seems to be in python libs only..?! | 20:06 |
| mvo | blueyed: only the "hardy: Fatal IO error 9 (Bad file descriptor) on X server :0.0." ? but that was reproducable for you? | 20:08 |
| blueyed | mvo: not sure.. (I've tried to find a bug that I might have submitted for reference and marked as dupe, but could not find it). I'm quite sure though, that answering "no" to the "abort"-question in vbox-ose once caused two crashes (update-manager and virtualbox-ose). | 20:13 |
| mvo | blueyed: ok, thanks. I will try to reproduce it here, thanks for looking into that | 20:13 |
| === ConnorImes is now known as Rocket2DMn | ||
| slangasek | hrm; OOo now depends on ttf-liberation, which isn't in main and has no MIR open? | 21:32 |
| mathiaz | kirkland: I'd more enclined to put ecryptfs-utils in the supported seed rather than the server-ship seed | 23:43 |
| kirkland | mathiaz: okay | 23:43 |
| mathiaz | kirkland: if adduser depends on ecryptfs-utils, it will go on the -alternate iso also | 23:43 |
| kirkland | mathiaz: okay, shall i make that change in my branch? | 23:44 |
| kirkland | mathiaz: supported looks like a strange place to put it, looking at the other things in there | 23:45 |
| mathiaz | kirkland: probably dvd then | 23:45 |
| mathiaz | slangasek: do you have a suggestion on where to put ecryptfs-utils now that it's MIR has been accepted ? | 23:45 |
| slangasek | mathiaz: seed-wise, you mean? | 23:49 |
| mathiaz | slangasek: yes | 23:49 |
| slangasek | if the plan is to use it as a dependency, it doesn't need seeded directly at all | 23:50 |
| mathiaz | slangasek: well - that's the plan - but it hasn't been accepted yet | 23:50 |
| kirkland | slangasek: okay, i'm hoping to have adduser depend on it, eventually | 23:50 |
| mathiaz | slangasek: so if the adduser doesn't make it for intrepid, we still need to seed ecryptfs-main somewhere | 23:51 |
| slangasek | ok. I have no opinion on server-ship vs. supported, that's entirely a question of whether you guys want it on the CD right now, I think | 23:51 |
| mathiaz | kirkland: ok - so I don't think we need it on the CD | 23:54 |
| kirkland | mathiaz: okay | 23:54 |
| kirkland | mathiaz: i'll try and get my adduser work done sson | 23:54 |
| kirkland | soon | 23:54 |
| mathiaz | kirkland: I'm looking at the platform.intrepid branch | 23:56 |
| mathiaz | kirkland: we could add ecryptfs-utils to the supported-sysadmin seed | 23:57 |
| mathiaz | kirkland: https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.intrepid | 23:57 |
| kirkland | mathiaz: okay | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!