[00:05] Is there a way to configure xorg in the development version? [00:07] the dpkg-reconfigure xserver-xorg [00:07] seems to be very minimal [00:09] there's displayconfig-gtk [00:10] Which does a good job of consistently breaking your xorg.conf. :-) [00:15] hey, we don't need xorg.conf anymore! :) [00:15] Mostly [00:16] And i wish displayconfig-gtk knew that as well. :-) I admit, i haven’t tried it for months, it may have improved a lot. [00:17] displayconfig-gtk will probably be replaced, see https://code.edge.launchpad.net/~bryceharrington/gnome-control-center/multi-monitor-config [01:48] * Hobbsee waves [01:48] Riddell: done [01:49] hi Hobbsee [01:49] hey zul [02:07] Hi all, I'm not sure if I'm in the right channel for help on making .deb packages? [02:07] hey Hobbsee [02:07] JediMaster: You'd be better off in #ubuntu-motu, probably. [02:07] JediMaster: #ubuntu-motu [02:07] thanks =) [02:08] hi superm1 [02:08] how goes it? [02:08] pretty well. [02:08] and yourself? [02:23] yeah, going OK [02:31] Hobbsee, i lied, i just got a new puppy, so i'm pretty excited :) http://www.flickr.com/photos/23258998@N04/sets/72157603857206524/ [02:32] whooo! [02:32] Puppies! [02:34] Anyone gotten the Ubuntu Certified Professional yet? [03:17] hi, is anyone runnin ubuntu on a dell latitude 830? [03:23] glickster: Support in #ubuntu or #ubuntu+1 [03:23] Very few people here this time of day in any case. [03:23] k thanks [04:07] why are hard drives listed as /dev/sd* on ubuntu even if they are ATA drives? [04:08] Aloha: Because a lot of the IDE controller drivers in the kernel have been ported to use libata. [04:08] because the trend in the Linux kernel has been that all hard drives are being moved into a single subsystem, derived from the SCSI subsystem [04:08] as far as I understand it anyway [04:09] (libata, yes) [04:09] slangasek: Thanks for the better explanation. [04:10] im studying for LPIC-1 so it was kinda confusing because its hda based heh [04:10] Not all drivers have been changed however. [04:10] i was like ... there is no /proc/ide [04:10] The IDE controller in my mac mini still uses hd devices, as well as a highpoint controller driver in another machine. [04:11] TheMuso: Actually, there are new drivers that use libata. [04:11] TheMuso: Which is suspect is a port of the old one. [04:11] TheMuso, so its the naming convention is based on what your hardware uses? [04:11] * StevenK goes back to hiding [04:11] StevenK: Hrm I thought they just hadn't been ported. [04:11] I've never really dug into it however. [04:11] It just works, thats all I care about. [04:12] TheMuso, i.e. my drive shows up as /dev/sda because it was manufactured that way? [04:12] Aloha: It's the controller, not the drive. [04:12] Aloha: I don't know [04:12] StevenK, is the controller part of the drive, or is it a BIOS thing? [04:12] I was just pointing out an observation. [04:13] Aloha: Neither [04:13] StevenK, oh, a kernel thing? [04:13] Not that either [04:13] Aloha: It's a device that hangs off the south bridge [04:13] StevenK, then what kinda thing is it? [04:13] StevenK, south bridge? [04:14] An IDE controller is just another device, like a video card [04:14] StevenK, is it on the motherboard? [04:14] Aloha: In 98% of cases, yup [04:14] Not necessarily, but all modern motherboards incorporate at least one controller. [04:15] Which means it turns into a connector (or more) and a few chips [04:15] StevenK, so its my motherboard thats telling ubuntu that i have a scsi drive? [04:15] Upon researching my new machine, I have seen boards with only one IDE port now. [04:15] I'm looking at an application (scribus) where we take the .desktop strings that get translated and copy them into the .pot file and then add an Ubuntu specific gettext domain to the .desktop. My question is: Does the Debian toolchain support doing it that way, do they not care, would it at least do no harm. [04:15] TheMuso: That started about nine months ago [04:15] TheMuso: When SATA started getting popular [04:15] The looks like the only potential barrier between us and a sync. [04:15] Aloha: Nothing is telling Ubuntu that you've got a scsi drive. [04:15] StevenK: Well I've not really been following [04:15] Aloha: It isn't a SCSI drive, it's just named that way [04:16] Yeah well the board I'm looking at has 8 sata ports. [04:16] Aloha: The kernel is *naming* that drive like a scsi drive because *everything*'s going to be named like a scsi drive. [04:16] TheMuso: That expands out to two SATA controllers [04:16] TheMuso: Wow. More than last I checked. A bunch of those would be fakeraided together, yes? [04:16] StevenK: Yeah, 6 for 1, and 2 for the other I think, from reading specs. [04:17] RAOF, gotcha. is that because canonical wants it that way or because thats how the kernel is set up? [04:17] RAOF: If you choose to use them that way, yes. [04:17] Aloha: It's an upstream kernel decision. Everything's moving from the IDE subsystem to libata, and libata names drives sd? [04:18] RAOF, oh... i get it. so whatever distro's kernel uses libata then that distro will name their drives /dev/sd*, correct? [04:20] Unless they do something crazy, yes. [04:20] AFAIU the goal is that all disk access will be abstracted behind an unified interface. The sd* naming is just a side-effect of that. [04:21] Well, it means you have SCSI and then libata on top [04:23] is there a file for disk geometry like /proc/ide/hda/geometry? [04:25] Probably. Why don't you ferret around inside /proc? :) [04:26] Can't hdparm get that kind of stuff? [04:27] find . -name "*geo*" returned nothing [04:29] oh hdparm -g [04:29] TheMuso, thnx [04:29] Aloha: np [04:31] ibm developerwork LPI tutorials are really good === asac_ is now known as asac [05:03] debian #464170 [05:03] Debian bug 464170 in wordpress "wordpress: security flaw in xml-rpc implementation" [Grave,Fixed] http://bugs.debian.org/464170 === greeneggsnospam is now known as jsgotangco [06:17] Good morning [06:18] ScottK: postgresql-8.3> what was it? [06:19] Riddell: give-backs> seems that Hobbsee beat me to it [06:19] pitti: I sorted it out. It was needing to backport postgres-common too. [06:19] ScottK: ah, backports; yes, you need -common [06:20] pitti: You've got a backport for Feisty/Gutsy waiting for you or whichever archive admin gets to it first. [06:20] ScottK: do I need to bump the dependency to it? [06:20] or what was the trouble? [06:20] (i. e. it didn't work, but it did with a newer -common?) [06:20] It worked with the newer common. [06:21] It won't go back to Dapper though due to cdbs version needs. [06:22] ScottK: right, and due to the python packaging policy [06:22] ScottK: what broke with the current dependency version? [06:22] I didn't get that far. [06:23] It wasn't present in sufficient version and I don't know enough about postgres to really look at if a source backport to Dapper would make sense. [06:24] ScottK: I currently keep a manually maintained backport of 8.2 [06:24] ScottK: it would be no problem to do the same with 8.3 (technically) [06:25] If it's manual, I suspect it might be better to let the 8.3 package get some age on it first. [06:25] I don't guess you'd really want to do two. [06:26] right, one would be better; I maintain 8.2/dapper mainly for Launchpad [06:28] morning pitti. i was wondering if you could tell me why wxformbuilder got rejected? neither myself (the sponsor), or the packager got an email about it [06:29] superm1: was it rejected yesterday? [06:30] superm1: I never saw that package, if it was yesterday I think Riddell examined it [06:30] let me check when. [06:31] yeah it was yesterday [06:31] i'll check with Riddell then when he's back around [06:31] thanks [06:58] zul: on upgrade I get a file conflict on /usr/lib/libblktap.so.3.0.0 which is both in libxen-3.{1,2} [06:58] zul: yay for packages with bad sonames :/ [06:59] zul: I guess this library needs to be split out to its own package if it doesn't follow SONAME bumps, or it needs a forced bump [07:47] good morning [07:51] hi dholbach [07:51] Howdy-ho [07:52] hey ion_, hey emgent === carlos_ is now known as carlos === greeneggsnospam is now known as jsgotangco === hunger_t is now known as hunger [09:17] anybody here with acroread installed? [09:17] pitti: is it reasonable to ask that apport crash files are readable by users? There's a bug open about it [09:17] seb128: _o/ [09:17] tjaalton: https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/183271 [09:17] Launchpad bug 183271 in poppler "evince and kpdf fail to open a pdf which works in Adobe Reader 7" [Low,New] [09:17] tjaalton: can you try to open the file attached there? [09:18] seb128: sure, a sec [09:18] tjaalton: apport files are readable by users at the moment alreadt === Ubulette_ is now known as Ubulette [09:19] seb128: ok, in that case I'll close it as fixed [09:19] seb128: yep, works with acroread [09:20] thanks [09:20] tjaalton: you can read your own crashes, not the one from other users, is that what you expect? [09:20] seb128: that makes sense [09:20] it's bug 72665 [09:20] Launchpad bug 72665 in xorg-server "using "chown" in /var/crash" [Undecided,Incomplete] https://launchpad.net/bugs/72665 [09:21] tjaalton: WDYM with 'readable'? except for the core dump they are just ascii [09:22] pitti: that the user can look at the contents without sudo [09:22] I have a compiz crashdump with mode 0000 [09:22] tjaalton: ah, that meaning of 'readable' :) [09:22] tjaalton: they are usually 000 while the report is still being written [09:23] so that the frontend doesn't try to read a half-written report [09:23] but when apport finishes it chmods it to 0600 [09:23] oh ok [09:23] tjaalton: it sounds like apport crashed in your case [09:23] tjaalton: does the .crash file look complete? do you have an exception in /var/log/apport.log? [09:24] tjaalton: I didn't see that bug, and I went through all apport bugs yesterday; what's the #? [09:26] pitti: which one? bug 72665 was against xorg-server [09:26] Launchpad bug 72665 in xorg-server "using "chown" in /var/crash" [Undecided,Incomplete] https://launchpad.net/bugs/72665 [09:26] so perhaps apport failed in this case as well [09:28] pitti: my apport.log only shows the "executable: /usr/bin/compiz.real (...) entry and nothing else about the crash [09:40] tjaalton: got disconnected; did you say anything after '[10:23] tjaalton| oh ok' ? [09:40] pitti: ah, yes: [09:40] 11:26 < tjaalton> pitti: which one? bug 72665 was against xorg-server [09:40] Launchpad bug 72665 in xorg-server "using "chown" in /var/crash" [Undecided,Incomplete] https://launchpad.net/bugs/72665 [09:40] 11:26 < tjaalton> so perhaps apport failed in this case as well [09:40] 11:28 < tjaalton> pitti: my apport.log only shows the "executable: /usr/bin/compiz.real (...) entry and nothing else about the crash [09:42] tjaalton: that particular bug seems useless, yes [09:42] tjaalton: and it doesn't talk about the permissions being 000, just that it belongs to root (which is correct) [09:43] pitti: yeah, closing [09:44] pitti: so since the process is run as root -> crash file owned by root? [09:44] right [09:46] superm1: https://lists.ubuntu.com/archives/ubuntu-archive/2008-February/015359.html === ogra_ is now known as ogra === greeneggsnospam is now known as jsgotangco === hunger_t is now known as hunger [10:29] anyone have an idea or know how to fix the dot in console mode with an Ubuntu gutsy ? [10:30] under a French keyboard i must use shift for doing a dot with the keypad... [10:32] saispo: what happens when you don't use shift? [10:33] seb128: nothing :/ [10:33] i try a dpkg-reconfigure console-data [10:34] but not working :) [10:34] seb128: have you the same things ? [10:35] saispo: no idea, I'm using my laptop right now and I've no keypad there [10:38] yes, same for me :) === cjwatson_ is now known as cjwatson [10:45] saispo: don't use console-data, it's dead as of edgy [10:45] console-setup <- new world order [10:45] ok, will try [10:47] cjwatson: nothing :) [10:47] saispo: grep XKB /etc/default/console-setup; what's the output? [10:50] doko_: you're the on handling coreutils for ubuntu atm ? [10:51] the same way as every core developer does [10:51] doko_, ah - I was only wondering as you're the last changelog. [10:51] doko_, I dont have access to a debian system at the moment, but I noticed that in ubuntu the /usr/share/locale/*/LC_TIME/coreutils.mo symlinks are all broken [10:52] cjwatson: hmmm query ? [10:52] saispo: sure [10:54] Mez: probably a version mismatch with current langpacks? pitti? [10:55] doko_, no idea - I'm just running a test on my system for broken symlinks [10:58] doko_, Mez: ah, it seems to assume that ../LC_MESSAGES/coreutils.mo exists [10:58] which isn't true with langpacks (it's in /usr/share/locale-langpack, not /usr/share/locale/) [11:01] maybe the langpacks should ship the LC_TIME symlinks [11:02] seems pretty messy to symlink from locale/ll/LC_TIME/coreutils.mo to ../../../locale-langpack/ll/LC_MESSAGES/coreutils.mo [11:05] also found a typo in libsnmp [11:18] cjwatson: I agree [11:26] cjwatson, was thre a decision about putting users into fuse by default with hardy ? [11:27] i think it would make sense to have it in the default groups adduser uses to avoid all these issues [11:28] (instad of having a notification) [11:30] adduser doesn't have default groups; user-setup does [11:31] somebody filed a bug on user-setup asking for that, although they mentioned several other groups in the same bug [11:31] I'm open to opinions - it sounds fairly reasonable to me but I'm interested to hear if anyone has contrary opinions [11:32] should put it on e meeting agenda ? [11:32] what security vulnerabilities, if any, does being in that group open up? [11:32] yeah, that sounds like a good idea actually [11:32] full access to dev fuse .... [11:32] which means you can do all nasty stuff through hacking togther your own fuse userspace tools [11:32] right, I know, but for instance there is presumably a reason why that isn't just open to everyone [11:33] I'm wondering whether this is like group audio or like group disk [11:33] fuse has a lots of power [11:33] the former shouldn't be open to everyone, but it makes complete sense for the default user to have it [11:33] rahe disk i guess [11:33] *raher [11:33] gah [11:33] the latter lets you shoot yourself in the foot and so we do not even give it to the default user [11:34] well, you *can* have full access to any filesystem through a userspace toolou write ourself ... [11:34] grmbl [11:34] * ogra beats his wireless keyboard [11:35] err [11:35] are you saying that fuse lets you read/write to a filesystem that's on a block device not otherwise mounted anywhere that you do not otherwise have permissions to use? [11:36] as opposed to a loop-mounted file in your home directory, for example [11:36] i think thats possible, yes [11:36] or presumably let you create a filesystem as an ordinary user and put a set-id executable on it? [11:36] or does it block set-id? [11:38] no idea, really, that would need more info from a security person who knows a bit more on that level than me, but if i look at scott balneaves playing with ltspfs and sshfs it seems reasonable that you can easily write your own stuff to circumvent low level restrictions through going through fuse [11:38] * Hobbsee wavse [11:38] pitti: yeah. being an australian, that's easier [11:39] hey Hobbsee [11:39] i think you can work around access restrictions in userspace here but thats an unproven statement [11:39] ogra: would you investigate these questions before the meeting, please? for example, for the latter, you could create a filesystem containing a set-id executable as root, and then mount it as an ordinary user and see if you can still escalate privileges using it [11:39] I think we need more information before making a decision here [11:39] good [11:40] ogra: uh, no, it doesn't work that way at all. fuse runs as your user. [11:40] Mithrandir, the module ? [11:41] i know the top level does [11:41] but that gains me access to low level functions i wouldnt be able to use directly [11:41] ogra: the file system itself, at least, yes. I would think that fuse doesn't allow suid by default, anything else would be a gaping hole. [11:41] like what? [11:42] Mithrandir: I think we need to check this :) [11:42] Mithrandir, no idea, disks i couldnt access otherwise :) [11:43] ogra: hmm, that does seem curious; opening the block device ought to be done on the userspace side [11:43] i mean look at ntfs .... ntfs3g does exactly that, no ? [11:44] ogra: ntfs-3g opens the block device from userspace [11:44] (see ntfs_device_unix_io_open) [11:44] : tfheen@xoog ~ > /bin/ntfs-3g /dev/sda3 /mnt [11:44] Error opening partition device: Permission denied [11:44] Failed to mount '/dev/sda3': Permission denied [11:45] so that has to be invoked from a privileged process [11:45] ok [11:45] Mithrandir: what happens if you mount -t ntfs-3g /dev/sda3 /mnt? [11:45] err, possibly fusermount [11:45] mount wont let you :) [11:45] right [11:46] and suid doesn't go across at least sshfs [11:47] that could be just sshfs not implementing it though [11:47] don't get me wrong, I think you're probably right, but I also think it deserves to be checked [11:47] how would it "not implement it"? It's suid from the looks of ls. [11:47] -rwsr-xr-x 1 list tfheen 9066 2008-02-06 12:46 test* [11:47] : tfheen@xoog ~/iphone > ./test [11:47] 1000 [11:47] : tfheen@vuizook ~ > ./test [11:47] 38 [11:48] Mithrandir: sshfs has a method somewhere that returns the permissions set on the file [11:48] it has to figure out what those are on the other end of ssh [11:48] it could easily decide only to care about mode&0777 [11:48] wouldn't then ls not list it as suid? [11:49] http://lists.planet-lab.org/pipermail/devel/2006-November/001831.html <- possibly relevant [11:49] Mithrandir: oh, I thought you meant that that was native ls [11:49] ok [11:49] oh, sorry, it was through sshfs, yes. [11:50] and even with -o suid it's still mounted nosuid,nodev [11:53] (the oops that the poster to planet-lab ran into is fixed in our current kernels) [11:57] that one looks like "fuse might have bugs", which given it's software, it's bound to have. [11:57] right, but do we want it in the default groups with these possible bugs ? [11:58] or do we want to go on to get 10-20 "permissions on /dev/fuse are wrong" bugs every release, from users that didnt grok they have to re-login after adding themselves to fuse [11:58] I'm much less concerned about DoS possibilities (which we need to fix anyway) than about fundamental misdesign [11:58] ogra: the kernel probably has exploitable bugs in various syscalls too. Or sudo. Or any other piece of the stack. [11:59] i'm only concerned about all that bugreports :) [11:59] ogra: if you have a current open master bug about this, please reassign it to user-setup [11:59] cjwatson: agreed, and fuse doesn't seem to have fundamental misdesigns, afaict. [11:59] the actual fix would be "instantly applying group membership" though [11:59] at least not from a security point of view. [11:59] ogra: that's hard, due to how UNIX works. [12:00] Mithrandir, right ... well i have three options: notification afetr fuse-utils is installed, having all users in the fuse group anyway ... change UNIXs design :P [12:02] leave the notification there, but we'll make it go away for the default user [12:02] I think that's a reasonable compromise for hardy [12:02] leave ? you mean add one :) [12:02] I thought there was a notification at the moment [12:03] in that case, I guess add one [12:03] there is nothing atm [12:03] though fuse is installed by default [12:03] so perhaps a notification is unlikely to be all that useful [12:03] we talked about it last week ... and i was looking into the bugs, what made me think about adding all users by default [12:03] I am not comfortable with adding all users by default for hardy [12:04] s/what/that/ [12:04] ok [12:04] i'll add the notification so we cover te upgraders at least [12:04] *the [12:06] would it be useful for the user to get a notification if his groups in the passwd file are different than for, say, gnome-session? [12:06] to me, that looks like something which could (and maybe should) be generalised. [12:08] hmm [12:16] Where can I find the info that used to live in /proc/bus/usb/devices ? [12:17] soren: Some of it is in /sys/bus/usb, and the rest is no longer directly available. [12:17] /sys/bus/usb/device [12:19] soren: The discussion in bug #156085 may provide more information [12:19] Launchpad bug 156085 in qemu "Could not open /proc/bus/usb/devices" [Low,Confirmed] https://launchpad.net/bugs/156085 [12:19] persia: That's the bug I'm working on fixing :) [12:19] heh [12:19] persia: I don't want to reenable usbfs. [12:20] persia: Aw, screw it. I'll teach it how to extract the info from sysfs. That's the sensible thing to do anyway. [12:20] I just wanted to check if it was already available somewhere. [12:21] soren: It wasn't available in November when I last hunted for it upstream. Teaching the tools about /sys/ is likely better anyway. [12:25] asac, i just had a QA tracker notification about a new firefox build to test from mozilla.qa.ubuntu.com, does that differ from our ff-3.0 package in universe ? [12:28] * soren goes to lunch [12:29] ogra: http://www.asoftsite.org/s9y/archives/127-CALL-for-TESTERS-firefox-stabilitysecurity-RC-builds-need-QAfeedback.html [12:29] ogra: was the mail truncated for you? [12:30] http://paste.ubuntu-nl.org/54981/ yup, apparently [12:30] ogra: those are QA builds for security updates of our stable releases ... so yes. they are about 1.5 (dapper) and 2.0 (edgy,feisty,gutsy) [12:30] ah, right [12:30] that info was missing [12:43] dholbach: pitti: i don't understand why the xml entities don't get installed in the same directory :) === cjwatson_ is now known as cjwatson [12:43] i mean even the source has them in the same dir afaict [12:43] pitti: hmmmm? === doko_ is now known as doko [12:43] slytherin, persia: asac seems to have some questions aout the change [12:43] and catalogs are only an sgml standard afaik ... no such thing officially exists for xml [12:44] zul: the hmm refers to what? :) [12:44] if parsers support it ... fine ... but we cannot demand all xml parsers to know about catalogs [12:44] asac: Are you referring to the comment on Debian bug? [12:44] pitti: something about abi and soname? [12:45] zul: well, you can't ship the same library in two different packages which don't Conflicts: to each other [12:45] slytherin: well ... i think the last comment is right. just install the entitites in the same directory as the dtds (the source ships them in the same dir after all) [12:45] zul: and libfooX.Y packages should not conflict to each other [12:46] ill fix that today [12:46] zul: libxen3.{1,2} violate the library packaging standard, because they ship sonames different from 3.{1,2} and thus generate file conflicts [12:46] asac: Yes, I am the one who made that comment. :-) [12:46] zul: what's your feeling how this shuold be fixed? [12:48] pitti: dholbach: slytherin: i think we should install them in the same dir ... and then listen carefully for regressions in packages/software that does expect them in the current locations [12:48] ack [12:48] w3c distributes: http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd + http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent for instance [12:48] so same directory as well [12:49] asac, slytherin: it shouldn't be too hard to check the reverse dependencies; there are only 5 [12:49] pitti: add the conflicts and see about adding sonames or talking to upstream about it [12:49] zul: please don't add Conflicts:, that'll break upgrades [12:50] zul: as a Gross Hack(tm) you could have -3.2 Replaces: -3.1, but eventually this should be fixed properly by splitting out the library into a separate pacakge [12:50] (IMHO) [12:50] slytherin: can you update the debdiff to just use the same location? and fix the catalogs accordingly? [12:51] asac: Ok. Will do. But then I don't have enough time to analyze the regressions [12:51] pitti: ok will have a look ill talk to soren as well [12:51] thanks [12:51] slytherin: thats ok ... i will take a quick look if you bug me afterwards :) [12:51] asac: Might it be OK to ship with symlinks for now, and dig through the possible regressions later? [12:52] asac: I guess if I update catalog also then there shouldn't be much problem. I will keep my fingers crossed. [12:52] persia: but they should be the other way round then (symlinks are in the old place, files in the correct one) [12:52] persia: when? i suspect that most rely on catalog so we most likely won't see regressions. [12:53] i am fine with what pitti says too [12:53] asac: the issue is that some packages FTBFS due to not finding things in the right place. Moving them may result in a different set of packages FTBFS. We don't see this from Debian due to local compile of arch:all. [12:53] pitti: Sounds perfectly sane. [12:55] persia: do we have a list of current FTBFS due to this? [12:55] asac: I only know about lucene2. slytherin was investigating in more depth. [12:56] asac: persia: Even I know only lucene2 as of now. But the problem will be there for any app trying to use DTD directly [12:56] I can only comment about java apps though. Not sure about how C/C++ apps use the DTD [12:57] slytherin: http://paste.ubuntu.com/4246/ ... is that the error you refer to? [12:58] asac: That error is due to lucene2 trying to access DTD on internet. The error when trying to use local DTD is 'File not found' because it can not find entity sets [12:59] hmm ... but it would still fail on that internet access ... or is it a fallback because it couldn't resolve it locally? [12:59] The attempt to access the internet is a fallback from not finding it locally. [13:00] sure? [13:00] asac: persia: No. We are trying to use local DTD as solution to the connection problem on buildd. [13:00] * persia reviews the build log again, somewhat confused [13:00] slytherin: how? [13:01] asac: we patch the lucene2 unit test to make it refer the local DTD and add w3c-dtd-xhtml package as build dep. [13:05] slytherin: hmmm ... have you tried http://xml.apache.org/commons/components/resolver/tips.html ? [13:05] to tell where the catalog is? [13:05] (e.g. patching system ids to refer to absolute local paths isn't much better ;)) [13:06] That solution also needs an additional build-dep (which isn't necessarily bad) [13:07] asac: No I didn't try it. [13:07] no idea if it can work if lucene uses xerces directly (without commons) [13:07] asac: I'm looking at the tracker's log and see that you triggered a bug when adding a new build (at 12:46 and 12:47). Though I'm unable to reproduce, do you know what happened ? [13:08] stgraber: the only thing i know is that the mail got truncated (maybe thats the bug)? [13:09] thought i hit some max letters constraint or something [13:09] stgraber: UTC? [13:09] the bug is happening in the event handling part of the code but it's before the mail is sent [13:09] CET (UTC+1) [13:10] stgraber: hmm ... i added new milestone + new builds ... but i made a mistake when adding new milestone so i had to hide it without adding a build [13:10] maybe that? [13:11] pitti: How will splitting the library into a separate package fix anything? (re: libxen3.[12]) [13:13] asac: btw, you could have just renamed your extra milestone :) [13:13] oh ... yeah. still need to get used to all the tiny tiny things on that page i guess :) [13:15] ok, so you added 3 milestones and then went to the Add build page [13:15] ticked Firefox, entered the version number and added, doing the same for the 3 milestones ? [13:16] more or less. i am not sure when i noticed the wrong milestone (i used the same version for gutsy as for edgy) [13:16] once i noticed it, i hid it and added the correct one [13:17] i didn't see an error page though. hmmm let me think. i think i added a build to a previously hidden milestone once too [13:18] zul: I don't think i understood completely yesterday.. Are libxen3.1 and 3.2 actually ABI incompatible? Doesn't 3.2 just add new stuff, but provides backwards compatibility? [13:18] ok, I tried to reproduce here with the latest changes I did and I'm unable to reproduce so it should have been fixed [13:18] stgraber: good! [13:19] asac: Do you have a link to the mail you sent earlier so I can see what went wrong with it ? [13:19] i try to remember more details on what i did next time :) [13:19] soren: it is backwards compatible I believe [13:19] stgraber: a link? [13:19] asac: yes, or just a copy/paste of the content [13:20] zul: In that case, I think we should build a libxen3 binary rather than a libxen3.2 one. [13:20] stgraber: not 100% the same ... but the content was similar to what i posted here: http://www.asoftsite.org/s9y/archives/127-CALL-for-TESTERS-firefox-stabilitysecurity-RC-builds-need-QAfeedback.html [13:20] pitti: What do you think? [13:22]