[00:01] http://linux-foundation.org/weblogs/openvoices/linus-torvalds-part-i/ [00:02] Running htop I see ~70 console-kit-daemons running... I guess that is due to htop not noticing multithreading. Isen't that a bit excessive? [00:05] slangasek: actually, there's need for one more upload.. openchrome lacks a patch to extract pci-ids in a text file, but fortunately the patch for via applies and works.. [00:15] tjaalton: ok. at least it's now installable, so we can move ahead with test images :) [00:15] sure [00:16] I can put it on hold until tomorrow if needed? [00:18] as long as that's the only change you're making, it doesn't sound like it would disrupt anything, and it would certainly help get better feedback from openchrome users on the alpha [00:18] so please go ahead [00:18] ok, thanks === cprov is now known as cprov-ZzZ === bigon is now known as bigon` [01:54] why is the Gusty installer CD olny working with the pnpacpi=off option as a boot parameter on my machine? [01:54] any ideas? [01:55] without pnpacpi=off i get an error about 8139cp is not right for my RTL-8139C PCI network card and that i should use 8139too instead?? [01:55] Sefram: no idea, but file a bug [01:56] ... on the kernel (linux-source-2.6.22 package) [01:57] what have i to regard while installing when it works only with pnpacpi=off?? [02:00] i got the tip from here: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/22575 seems to be an address ressoure conflict in pci address space... [02:00] Launchpad bug 22575 in linux-source-2.6.15 "ISAPNP grabbing I/O region reserved for PCI device on 2.6.12 (regression from 2.6.10)" [Medium,Confirmed] [02:01] Ubotu: smarty lol [02:01] Sorry, I don't know anything about smarty lol - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi [02:08] Hobbsee: does chrootwait go away automatically? [02:09] calc: not necessarily [02:10] Hobbsee: hmm can you fixup openoffice.org to retry, i think the reason it failed was due to the archive being updated when it tried to build [02:11] unless something really did break the chroot's due to unauthenticated debs? [02:12] calc: given back [02:12] ok [02:13] Hobbsee: thanks :) [02:13] * Hobbsee wonders what the chroot problem actually is [02:18] I wouldn't be surprised if it was just a case of the mirror being in an inconsistent state due to having to futz around with the rsyncing and so forth [02:32] slangasek: Hey, I have a new asc upstream in games SVN if you'd rather upload that? :) [03:24] <_MMA_> Does the package gdm 2.20.2-1ubuntu2 include the changes from upstreams 2.20.3 release? [03:40] Please forgive my being slightly off-topic: How are updates to packages indicated to apt? Is there a datastream which sez "foo-1.2 upgraded to foo-1.3"? Or does apt simply compare the most-recent copy of the package as indicated by Packages.bz to the locally-installed package? [04:44] bddebian: mutter mumble if someone would fix paragui then we could upload asc to Debian and sync it... [04:49] slangasek: What's up with paragui? [04:50] bddebian: it ships a .la file that has references to a crapload of other .la's that it doesn't depend on [04:52] Ah the SDL "team" :) [04:52] bddebian: and indeed, the asc upload FTBFS on all archs because of this, so sure, I'll take a new upstream that I can sync after [04:52] Hmm, 2.0.1 didn't FTBFS on unstable for me === tritium_ is now known as tritium [04:54] asc 2.0.1 that is [04:55] the build failures are entirely paragui's fault [04:55] well - no, the latest one is my fault, because I didn't verify first that directfb-dev still ships a.la [04:56] Which it doesn't [04:58] yes, which is why things Broke [05:01] launchpad died [05:02] bddebian: so where's this asc package that needs sponsorin'? [05:02] * bddebian does another build of asc out of curiosity [05:02] slangasek: I just removed it from mentors [05:05] Damnit, now it's puking trying to pull in libbz2-dev [05:08] I have another issue while my pbuilder updates. I've built a new stormbaancoureur. However, one file (engine.tga) is rendered from a 3D model that the author purchased. He claims he has copyright but is that possible? [05:10] F**k, is libbz2-dev broken now too? [05:11] bddebian: its possible and there is no way to tell; have him assert the appproporiate copyright statement and you're good [05:12] bddebian: it wouldn't ftbfs on unstable because the paragui binaries in unstable were built against a good libsdl, and the ones in hardy were built against a bad libsdl [05:13] libbz2-dev... broken how? [05:13] installed cleanly for me [05:13] uninstallable in my sid pbuilder [05:14] The libsdl in Hardy is bad? [05:17] not anymore [05:17] all about the Timing! [05:18] libparagui is in universe still? [05:19] it should be somewhere else? [05:20] Hmm, and 1.0 or 1.1? :) [05:21] well, 1.0 is the one it's been building against, beyond that I have no idea [05:21] I wonder if 2.0.1 would build against 1.1 [05:25] Gah wtf, libbz2-dev installs fine if I pbuilder-login [05:31] hmm, should the topic be changed for the Alpha 3 freeze? [05:32] E: Failed to fetch http://ftp.debian.org/debian/pool/main/b/bzip2/libbz2-dev_1.0.4-1_i386.deb: 404 Not Found [05:32] E: Unable to correct for unavailable packages [05:32] gaaahh === slangasek changed the topic of #ubuntu-devel to: Archive: main soft-frozen for Hardy Alpha 3 | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs [05:33] LaserJock: yes, thanks :) [05:35] keescook, ping [05:35] slangasek: np ;-) [05:35] emgent: pong [05:36] keescook, wordpress diff 2.1 is ready [05:36] emgent: cool, make a bug report for it and get it attached. nice work. :) [05:37] ok thanks :) [05:39] bddebian: libparagui1.0 fixed, so where did asc go after it was removed from mentors? [05:39] slangasek: I'm throwing it back on mentors as I type [05:40] I can't test build in on unstable though for whatever the fsck is going on with my pbuilder. (I switched the build-deps to libparagui1.1) [05:41] I'm... less likely to sponsor a package with library changes that haven't been tested [05:41] Well I wanted to test it but I can't build it. I can switch it back if we want to get it in [05:45] switching it back would be good if you want me to look at sponsoring it; otherwise I can just get the already-uploaded asc given back on the buildds to take care of the bug I was after [05:47] Let me switch it back. I've been trying to get this in forever [05:49] pabs3: !? [05:49] hi bddebian :) [05:50] Man, I can't hide anywhere anymore :) [05:50] * pabs3 was wondering who to contact about patches.ubuntu.com [05:50] :) [05:51] pabs3: lifeless suggested we might get away with the engine.tga thing in stormbaancoureur if he provides copyright. Would you disagree? [05:52] that'd be offtopic here, perhaps #debian-games is better? [05:53] about patches.ubuntu.com, would it be possible to remove changelog-only patches? for eg http://patches.ubuntu.com/s/synfig/synfig_0.61.07-1build1.patch [05:54] Oh, build1 versions aren't really patches, just rebuilds [05:56] yeah, but they do show up on packages.qa.d.o, which can be annoying when I go to check for a patch and find it only bumps the changelog [05:56] Ah yes, makes sense [06:01] slangasek: http://mentors.debian.net/debian/pool/main/a/asc/asc_2.0.1.0-1.dsc [06:22] bddebian: downloading gradually [06:23] NP, I gotta get my old arse to bed anyhow [06:48] can any one guide me in streaming?? [06:50] how do i search for a file in hardy? [06:50] there are still no contents files? [06:51] i'm getting this error: /usr/include/mono-1.0/mono/metadata/threads.h:17:41: error: mono/metadata/threads-types.h: No such file or directory [06:51] and need to know where that file is [06:52] i am getting RTSP/1.0 461 Unsupported Transport from rtsp server ..????? [06:52] * calc wonders if libmono-dev is just fscking buggy === fabbione is now known as thegodfather [07:00] yep mono is a just buggy [07:01] pochu: ping [07:01] pochu: bug 181422 [07:01] Launchpad bug 181422 in mono "thread-types.h is missing" [High,New] https://launchpad.net/bugs/181422 [07:10] good morning [07:11] i guess no one wanna help me ... ok.. [07:15] sam__: wrong channel for that kind of question, try #ubuntu [07:16] Good morning === asac_ is now known as asac [07:29] pitti, good morning :P === mekius_ is now known as mekius [07:44] hi emgent! === c1|freaky_ is now known as c1|freaky === hunger_t is now known as hunger [08:53] The hardy gcc gets an ICE when building kdeedu her. [09:16] is there anywhere i can get a list of all packages are used for the live cd ? [09:16] calc: pong, looking [09:17] viviersf: http://cdimage.ubuntu.com/daily-live/current/hardy-desktop-i386.manifest [09:19] evand, the manifest is ubuntu-desktop + live cd components [09:19] calc: OO.o FTBFS> "mcs not found" -> missign build dep? [09:19] evand, i need a list of just the stuff thats extra, i can do it manually, i just want to see an easy way [09:20] viviersf: you can look at the 'ship-live' seed, but that does not include dependencies which are pulled in by those and which are not needed by ubuntu-desktop [09:21] pitti, cool, is that a package ? [09:22] http://codebrowse.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.hardy/files [09:23] thanks pitti, that will do [09:27] good morning [09:29] hey geser [09:30] hi geser [09:36] hey guys :) [09:38] Hi seb128, pitti [09:57] calc: I'm merging mono 1.2.6+dfsg-5 from Debian which fixes this (in -4): [09:57] * debian/patches/fix_threads.h.dpatch: [09:57] + Don't include threads-type.h in threads.h and moved functions to the [09:57] correct header, fixes compiling of OpenOffice.org's Mono bridge. [09:57] (taken from upstream SVN revision 91687 + 91817) === Amaranth_ is now known as Amaranth [09:59] pitti: do you know if there is any hardy language pack upload scheduled? [09:59] seb128: the guys are working on it, but I haven't heard a concrete deadline [09:59] carlos: ? [10:00] pitti: let me check it with jeroen... [10:00] I'm wondering if we will ever have a cycle where rosetta is ready and language packs uploaded early ;-) [10:00] apport is all broken here for weeks now and I was waiting for translation updates before investigating [10:02] seb128: oh? what's wrong with apport? [10:02] seb128, pitti: danilo is working on a small problem that affects Slovenian translations since long time ago and that requires to be fixed before opening Hardy [10:03] hi there [10:03] pitti: http://people.ubuntu.com/~seb128/Capture-apport-gtk.png [10:03] is there someone here familiar with gcj/ecj packages except doko ? [10:03] seb128, pitti: He expects to get a script run later today that should fix the data so we are ready to start with imports [10:03] pitti: basically the text is invalid utf8 [10:04] carlos: ok, thanks [10:04] seb128: ah, you mean the translations are broken? ok, since it works just fine here [10:04] carlos: happy new year btw [10:04] pitti: well, I was wondering if that's the translations or the code but was waiting on a language pack update before investigating [10:04] seb128: same for you, did you enjoy your vacations? :-) [10:04] carlos: yes, was nice to spend some time away from the computer ;-) [10:05] :-D [10:05] carlos: how was your honeymoon? [10:05] seb128: 'short' [10:05] * carlos hides [10:05] ahahah, good one ;-) [10:05] the only problem was when we went to Paris, we moved from 30 degrees to -2 degrees.... [10:05] you have been lazy enough, fix rosetta now! [10:05] cold is better, isn't it? ;-) [10:06] seb128: not yet, next month, this month I'm not working in translations :-) [10:06] seb128: not really ;-) [10:06] carlos: reminds me about my transition from vacation in Nice to distro sprint in Oslo (25 -> -12 degrees) [10:06] wow [10:06] that's even worse [10:07] the guys at the airport to Nice wondered why I brought thick sweaters, gloves, scarf, etc :) [10:07] Going from Australian summer (it was 42 the day I left) to -4 is quite bad, I find. [10:27] Hm... Rhythmbox core dumps after 10.6-10.7 seconds. Every time. Very annoying. [10:27] soren: backtrace? [10:27] soren: Regardless of what you've told it to do beforehand? [10:27] Fujitsu: Yup. [10:28] Fujitsu: Regardless of whether or not it's playing anything, too. [10:28] seb128: I'll report it with apport in a bit. [10:28] good [10:29] It works fine for me, though at one stage I did make it segfault on start every time by disabling Cover Art. [10:29] soren: The time is seemingly arbitrary and uniform? [10:30] Fujitsu: Yup. [10:31] Fujitsu: Minimum observed: 0m10.652s, maximum observed: 0m10.702s. [10:31] Fujitsu: I've done it ~10 times. [10:31] soren: maybe it's shocking on a file and is consistent on how long it needs to reach it [10:32] seb128: Could be. However, with 4 GB of RAM and a not too impressive music collection, I doubt it could take as much as 10 seconds to go through it. [10:32] RAM doesn't really matter there [10:32] that's rather IOs [10:32] seb128: WEll, if everything is cached, it does. [10:32] ..and it is. My hard drive is idling. [10:32] it needs to go through the library to know if it changed [10:32] *drives [10:33] weird [10:33] soren: strace isn't useful? [10:33] send the bug using apport that will give us some idea about the crash ;-) [10:33] seb128: I'm trying... It's something like /usr/share/apport/apport-gtk -c /var/crash/_usr_bin_rhythmbox.1000.crash, isn't it? [10:34] seb128: Ah, it's just taking forever to upload, probably. [10:34] soren: double click on the crash in nautilus [10:35] soren: you should get the apport window about the crash before having it sending anything [10:36] seb128: apport -c will do the same, so that's fine [10:36] (double click is just more comfortable :) ) [10:36] seb128: It tells me I should have an up-to-date system before doing anything. I'd better obey. [10:37] pitti: Well, except that you have to fire up nautilus and all that jazz first. [10:37] pitti: If you happen to have nautilus open in /var/crash anyway, then yes :) [10:37] having a parameter to not require the uptodate system would be nice [10:38] I often have whatever package which doesn't matter for the backtrace not uptodate === cprov-ZzZ is now known as cprov [10:58] calc: mono merge ready, but I'll have to wait for slomo to come back unless some else wants to volunteer :) === \sh_away is now known as \sh [11:12] pitti: should pkg_create_dbgsym honour the -X option from dh_strip? [11:13] see bug #180364 [11:13] Launchpad bug 180364 in ocamlnet "ocamlrpcgen no longer works on Gutsy. Probably a wrongly stripped binary" [Undecided,New] https://launchpad.net/bugs/180364 [11:13] geser: I don't think so, why? [11:13] pkg_create_dbgsym does not strip anything off the original binaries [11:14] have you then an explanation for this bug? [11:15] geser: not really; I think it should be tested with a local build of ocaml, both with and without pkg-create-dbgsym installed [11:15] in my pbuilder debian/tmp/usr/bin/ocamlrpcgen works as intended but the one from debian/libocaml-ocaml-bin (or the deb) doesn't [11:15] ah [11:15] geser: does your pbuilder have pkg-create-dbgsym installed? [11:16] when I set NO_PKG_MANGLE or add -Nlibocaml-ocaml-bin to the dh_strip call the one from debian/libocamlnet-ocaml-bin works too [11:16] the only thing p-c-d does to the original binary is adding the .gnu.debuglink section so that gdb can find the separate symbol files [11:16] pitti: it has [11:16] aha, then it seems it is the culprit [11:19] so adding -Nlibocaml-ocaml-bin to the dh_strip call the right fix? [11:19] no, that just sounds like a workaround [11:19] if it works correctly without p-c-d, we should fix the latter [11:23] I checked now where the binary breaks. Adding .gnu_debuglink breaks it. [11:24] ugh [11:24] but.. that's just an innocent extra elf section... *whine* [11:24] geser: ok, does 'file ' say anything special? [11:25] geser: or even better, can you tell that it must not be touched from the readelf -h output? [11:25] ocamlrpcgen.working: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), not stripped [11:25] ok, that's not useful then [11:26] or an 'ocaml_bytecode' section in objdump -x or so? [11:28] geser: I added a p-c-d task to this bug (the ocaml task is for the no-change rebuild then) and added this question [11:32] pitti: objcopy -R .gnu_debuglink ocamlrpcgen seems to be enough to break it [11:33] geser: ok, so we must not do that then [11:33] geser: I think the best fix is to make p-c-d not touch the binary at all if it has ocaml bytecode [11:33] so I just need to get a good test for that [11:34] something objdump -x binary | grep -q '\.ocaml_bytecode' like [11:37] pitti: http://members.ping.de/~mb/tmp/objdump.output === bigon` is now known as bigon [11:38] seb128: The rhythmbox bug was already reported by pochu: bug 179205 [11:38] Bug 179205 on http://launchpad.net/bugs/179205 is private [11:38] geser: thanks; I think I'll go with caml_release_bytecode [11:39] geser: just for final verification: objdump -x binary | grep -qw caml_release_bytecode [11:39] ? [11:39] soren: alright, and it has been fixed upstream already apparently [11:40] seb128: Orly? [11:40] soren: ? [11:40] "orly" = "oh, really" [11:40] :) [11:40] soren: look at the upstream task on the bug [11:40] ah, ok [11:40] geser: is objdump -t enough? [11:41] seb128: Oh, upstream bug of the duped lp bug. Right. [11:42] soren: no, of the non dupped bug (the one which is Fix Commited) [11:42] but right ;-) [11:42] pitti: objdump -t ocamlrpcgen | grep -qw caml_release_bytecode exits with 0 [11:42] seb128: Er.. Um.. Yes, you seem to be right :) [11:42] geser: cool, thanks [11:43] seb128: Do you intend to upload a fix or should I do it? [11:43] soren: you are welcome to do it since you can test the fix ;-) [11:43] seb128: Will do. It's not in bzr or anything, is it? [11:44] soren: no, just grab the patch from svn, copy to debian/patches and upload [11:44] seb128: Alright. [11:44] soren: http://svn.gnome.org/viewvc/ is handy to get diffs for GNOME modules [11:48] anyone running Kubuntu here? does "x-terminal-emulator -e dpkg -l" work, i. e. runs dpkg -l in a new terminal? [11:49] I'm not sure whether the KDE alternative of x-terminal-emulator correctly recognizes -e [11:49] xterm and gnome-terminal do [11:51] pitti: is it intended that "objcopy -R foobar binary" modifies the binary even if the section doesn't exist? because the filesize changes from 1248876 to 269652 [11:51] geser: I'm not sure whether it's intended, but I noticed that a thing like that gets rid of a lot of cruft [11:51] seb128: Oh, I used the bzr import from launchpad instead. Thanks, though. [11:52] at least it has done that for years [11:55] <\sh> pitti: konsole does know about -e [11:55] <\sh> pitti: -e Execute 'command' instead of shell [11:55] calc: do you need mono for alpha-3? [11:56] \sh: so if you do "x-terminal-emulator -e dpkg -l" it opens a Konsole window with dpkg -l output? [11:56] and closes it again when it's finished?) [11:57] <\sh> pitti: well, running gnome right now so I'm on gnome-terminal, but "konsole -e dpkg -l" works like a charm [11:57] <\sh> pitti: kde3 that is [11:57] pitti: works for me [11:57] Riddell, \sh: great, thank you [11:59] <\sh> mvo: pingeling...did you hear about my fatal experience when dist-upgrading from dapper to gutsy via edgy/feisty? === \sh is now known as \sh_away === \sh_away is now known as \sh [12:10] pitti: thinking about the pkg_create_dbgsym bug again: does it make sense to want to add a .gnu_debuglink for binaries which aren't going to be stripped? [12:12] geser: not really, no [12:13] what about passing the -X option from dh_strip to pkg_create_dbgsym to not add those links for the listed binaries as they are stripped anyway later? [12:14] this would fix it for the ocaml problem and any further binaries which don't like to be stripped [12:15] argh, there is a not missing in the first sentence: as they aren't stripped anyway later [12:15] geser: that would work, yes; we already have a flag $nodebuglink which is passed to pkg_create_dbgsym but it only gets enabled if dh_strip builds a -dbg package on its own [12:15] we could extend this to pass down a "don't touch" blacklist [12:19] \sh: no, did you file a bug? [12:19] mvo! [12:19] \sh: I would be very interessted in the logs [12:19] hey jsgotangco [12:23] hmm, tasksel fails on the current daily ... known fact ? [12:23] ah, missing language-pack-en [12:25] hmm [12:25] <\sh> mvo: there are no logs...but evms is the bug [12:26] weird, langauge-pack-en in on the CD [12:26] *is [12:26] i wonder why its not found [12:26] <\sh> mvo: we used a root server from strato, dapper lts installation...and evms is installed by default, but it wasn't running...after upgrading from dapper to edgy to feisty to gutsy, our two swap spaces were not there anymore, but locked by a process, which you don't see even with lsof... [12:27] <\sh> mvo: I was fighting with it several hours, till soren told me to remove evms from the system...after that it worked... [12:27] * Fujitsu got that on a number of systems, and thought the distupgrader was meant to handle that. [12:27] <\sh> mvo: evms on dapper is still being enabled by /etc/init.d/ and now it's got enabled with udev I think...so we need to check what happens with dapper -> hardy directly... [12:29] \sh: could you send me the logs please (if you used the release-upgrader) - it should automatically remove evms on feisty->gutsy [12:29] \sh: logs in /var/log/dist-upgrade/* [12:30] <\sh> mvo: I didn't ;) I used apt-get dist-upgrade [12:30] \sh: aha, ok :) [12:30] <\sh> mvo: but I think many people dealing with debian/ubuntu on servers will not use release-upgrader ,-) [12:32] \sh: we have a text-frontend! [12:32] \sh: probably depends on if they know about it or are using apt-get dist-upgrade because they allways had [12:32] <\sh> torkel: that's what I meant [12:32] \sh: I'm not a expert on the evms stuff, but afack we can not just unconditionally remove it [12:33] \sh: we definitely need to release note it [12:33] * mvo wonders if we have a expert on evms [12:33] anyone has an idea where I can download https://edge.launchpad.net/ubuntu/+source/gcj-4.2/4.2-20070707-1ubuntu2 please ? [12:33] * Mithrandir hides from mvo [12:33] <\sh> mvo: if we can determine if it was in use on dapper or not .. it could help... [12:33] mvo: Release noting and perhaps modifying Dapper's apt to screech if somebody tries to do it directly... [12:33] * mvo catches Mithrandir [12:33] links are dead and since now the package build-depends on itself, this version is the only one I can use to build the package on feisty [12:33] * Mithrandir plays dead [12:34] <\sh> mvo: if evms is being enabled by some magic variable in /etc/default/evms or something ... we could use this info during the update [12:35] \sh: the release upgrader does that, it checks if evms is in use by looking into /proc/mounts and if not, removes it [12:35] <\sh> Fujitsu: well, as canonical explained, that dist-upgrades from lts to lts is working without any problem...it's likely to happen [12:35] * ogra tickles Mithrandir [12:35] * Fujitsu stabs Mithrandir to make sure he isn't just playing dead. [12:35] but I don't know the details, why evms causes this trouble if it is not used [12:35] <\sh> mvo: no other way possible outside dist-upgrader? some magic in udev to determine the state of evms? [12:36] Mithrandir: is there some bugreport about this to figure what the probelm is ? [12:36] \sh: I think if we could solve it at a package level instead of working around it in the release-upgrader, that would be the best course of action [12:36] mvo: the problem is evms tries to grab all discs and partitions whether they're evms volumes or not. [12:37] Tonio_: LP still has the debs; click on the package you need, open the "Published as" portlet, select the architecture you need, download the deb [12:37] And causes much confusion when one tries to work out why only the non-LVM /boot partition won't mount. [12:38] geser: sure but I need to build this on feisty [12:38] geser: that's why I really need the source package... [12:38] Tonio_: The broken links are a bug I filed a couple of weeks back. [12:38] * Fujitsu grabs links. [12:40] <\sh> mvo, Mithrandir: I'll file a bug against emvs...(but I'm not sure if it's a bug in evms) but I wonder why evms is being used when it wasn't running at all... [12:41] Tonio_: Eh? [12:41] Tonio_: The source is right there on the page you linked to? [12:42] soren: librarian doesn't have those files :( [12:42] Fujitsu: AHHHHHHHHHH, great [12:42] persia: Librarian does have those files. kiko's code is dodgy when the packages aren't published anywhere. [12:43] Err. Right. s/:($/At that location./ [12:43] persia: Oh, right. [12:43] # Removed from disk on 2007-07-21. [12:43] \sh: it's being run from the initramfs [12:43] soren: The files are still in Librarian, just not on drescher. [12:44] Fujitsu: You're probably right. [12:44] <\sh> Mithrandir: hmm...more difficult [12:47] * soren lunches [12:50] Tonio_: http://mirror.linux.org.mt/mirror/ubuntu/pool/main/g/gcj-4.2/gcj-4.2_4.2-20070707-1ubuntu2.dsc [12:51] geser: thanks a lot ! [13:22] could someone makes a give-back for gossip (with libloudmouth1-dev >=1.3.3-1) [13:23] bigon: given-back [13:25] Mithrandir: is it safe to ask for give-backs of the packages in CHROOTWAIT? [13:29] geser: in general, they should be given-back automatically. Any in particular? [13:29] <\sh> mvo / Mithrandir: bug #181491 for the evms problem [13:29] Launchpad bug 181491 in evms "dapper -> edgy -> feisty -> gutsy update fails " [Undecided,New] https://launchpad.net/bugs/181491 [13:29] Mithrandir: if they are given-back automatically then I can wait [13:38] Mithrandir: thx [13:54] mvo: if I have an apt.Cache() object, is there a fast method to update it after I installed a package? (for .isInstalled) or do I need to regenerate it from scratch? [13:57] pitti: cache.open() should do [13:59] mvo: hm, that seems to take as long as generating a new apt.Cache() [13:59] I used c.open(None) [14:01] pitti: it needs to generate the binary cache after a install, it should be possible to speed it up a bit (for installs), I can look into that. you may consider showing some progress informration if that is a UI issue [14:01] mvo: ok; no, please don't spend any effort on this, I was just curious [14:02] pitti: ok :) I may still, I got a interessted idea that I would like to test [14:12] pochu: yea there was more wrong with OOo that I uploaded than just the missing header but I ran into that while fixing it on my box [14:13] pochu: i think it is probably too late for alpha-3 at this point :\ [14:16] calc: right now, openoffice.org is uninstallable in hardy; we can't release alpha-3 with it like that [14:16] it needs to be fixed [14:16] (one way or another) [14:18] good morning calc [14:19] did Ubuntu officially evaluate the Liberation Fonts license? [14:19] mjg59: ^^ do you know, maybe? [14:19] Not to the best of my knowledge [14:20] My recollection is that it's free but GPL incompatible [14:20] I heard today OOo upstream added the fonts recently [14:20] mjg59: well, fonts don't need to be GPL compatible, do they? [14:20] Only if embedded in GPLed works [14:20] So, not generally [14:20] I had a chat with aj about it earlier, as the debian-legal thread last May immediately got hijacked by nutcases [14:21] cjwatson: ok i can do the mono merge then upload new OOo that I have on my box [14:21] so there's two exceptions, one is the official FSF-recommended font exception [14:21] the other is some sort of anti-tivoization restriction it seems [14:21] calc: what are the changes in the new OOo? [14:21] Yeah, I told the people involved I wasn't really happy with describing an additional restriction as an exception [14:22] But, still [14:22] cjwatson: very few changes mostly to deal with the way mono was split over the holidays, mono was broken over the holidays as well see bug 181422 [14:22] Launchpad bug 181422 in mono "thread-types.h is missing" [High,In progress] https://launchpad.net/bugs/181422 [14:22] pochu: ping [14:22] seems pochu didn't include his merge work for mono on the bug report :\ [14:22] mjg59: and then there is the strange IP discaimer plus "Title to the Software and any component, or to any copy, modification, or merged portion shall remain with [Red Hat]" [14:23] I don't have a freedom issue with that (others might) [14:23] But it's still weird and potentially unenforceable [14:23] Unless it simply means "We are still copyright holders, even if you modify it", in which case, that's kind of obvious [14:24] But then lawyers often like pointing out the obvious. [14:24] pochu: i need the merge where is it [14:25] well he seems to not be here right now so i can look into remerging mono from debian [14:25] calc: try http://emilio.pozuelo.org/~deb/mono_1.2.6+dfsg-5ubuntu1.dsc [14:26] geser: ah great :) [14:26] that one he asked slomo to sponsor [14:26] mjg59: if I read this right, they own the copyright of the changes I make, even if I don't distribute them; is that something Ubuntu thinks is alright? [14:27] calc: ok, thanks [14:27] cjwatson, pkgsel seems broken as well atm [14:27] ogra: what's up with it? I hadn't heard [14:28] i had a file not found with it ... let me reproduce (my virtualbox just crashed and took the kept error with it, somethig about pre-pkgsel.d being empty) [14:29] hmm, sounds plausible [14:29] pochu: nevermind geser gave me the url above to sponsor :) === freeflyi1g is now known as freeflying [14:30] azeem: The QPL has similar issues, but I'm not sure that's what it means [14:30] azeem: It may well just be "Red Hat are still a copyright holder even if you modify it" [14:31] But clarification might be nice - RH legal are friendly people, IME [14:31] ogra: odd that that would be a fatal error (rather than just syslog noise), though [14:31] i had a proper red screen ... [14:31] install stopped [14:32] i'm in base-install gimme 10 min [14:32] mjg59: do you know a good contact address for that, by chance? [14:32] mjg59: (I thought the QPL was an issue and was mostly ignored cause all important code is bi/tri-licensed to sane licenses) [14:33] azeem: We still ship QPL-only code [14:33] ogra: I'm rsyncing a current image, but it'll be a while [14:33] ok [14:33] i'll get you the syslog [14:33] azeem: Indeed, we *have* to ship Qt under the QPL as well - otherwise only GPL-compatible code can link against it [14:33] its easily reproducable [14:33] hrm, right [14:34] (debian-legal seem to conveniently ignore this) [14:34] however, the QPL doesn't claim to be the GPL+exceptions [14:34] oh well [14:35] mjg59: anyway, thanks [14:35] No problem === \sh is now known as \sh_away [14:45] ogra: can I get syslog? [14:45] my rsync is at 49%, so this is probably faster [14:45] cjwatson, http://paste.ubuntu-nl.org/51357/ [14:45] copying the full log to p.u.c [14:47] ogra: the tasksel failure is the real problem, I think [14:47] cjwatson, http://people.ubuntu.com/~ogra/syslog [14:47]