[00:05] <dn4> Is there a way to configure xorg in the development version?
[00:07] <dn4> the dpkg-reconfigure xserver-xorg
[00:07] <dn4> seems to be very minimal
[00:09] <pochu> there's displayconfig-gtk
[00:10] <ion_> Which does a good job of consistently breaking your xorg.conf. :-)
[00:15] <pochu> hey, we don't need xorg.conf anymore! :)
[00:15] <ion_> Mostly
[00:16] <ion_> 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] <tormod> 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] <Hobbsee> Riddell: done
[01:49] <zul> hi Hobbsee
[01:49] <Hobbsee> hey zul
[02:07] <JediMaster> Hi all, I'm not sure if I'm in the right channel for help on making .deb packages?
[02:07] <superm1> hey Hobbsee
[02:07] <RAOF> JediMaster: You'd be better off in #ubuntu-motu, probably.
[02:07] <TheMuso> JediMaster: #ubuntu-motu
[02:07] <JediMaster> thanks =)
[02:08] <Hobbsee> hi superm1
[02:08] <Hobbsee> how goes it?
[02:08] <superm1> pretty well.
[02:08] <superm1> and yourself?
[02:23] <Hobbsee> yeah, going OK
[02:31] <superm1> 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] <Hobbsee> whooo!
[02:32] <RAOF> Puppies!
[02:34] <tjgillies> Anyone gotten the Ubuntu Certified Professional yet?
[03:17] <glickster> hi, is anyone runnin ubuntu on a dell latitude 830?
[03:23] <ScottK> glickster: Support in #ubuntu or #ubuntu+1
[03:23] <ScottK> Very few people here this time of day in any case.
[03:23] <glickster> k thanks
[04:07] <Aloha> why are hard drives listed as /dev/sd* on ubuntu even if they are ATA drives?
[04:08] <TheMuso> Aloha: Because a lot of the IDE controller drivers in the kernel have been ported to use libata.
[04:08] <slangasek> 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] <TheMuso> as far as I understand it anyway
[04:09] <slangasek> (libata, yes)
[04:09] <TheMuso> slangasek: Thanks for the better explanation.
[04:10] <Aloha> im studying for LPIC-1 so it was kinda confusing because its hda based heh
[04:10] <TheMuso> Not all drivers have been changed however.
[04:10] <Aloha> i was like ... there is no /proc/ide
[04:10] <TheMuso> The IDE controller in my mac mini still uses hd devices, as well as a highpoint controller driver in another machine.
[04:11] <StevenK> TheMuso: Actually, there are new drivers that use libata.
[04:11] <StevenK> TheMuso: Which is suspect is a port of the old one.
[04:11] <Aloha> TheMuso, so its the naming convention is based on what your hardware uses?
[04:11]  * StevenK goes back to hiding
[04:11] <TheMuso> StevenK: Hrm I thought they just hadn't been ported.
[04:11] <TheMuso> I've never really dug into it however.
[04:11] <TheMuso> It just works, thats all I care about.
[04:12] <Aloha> TheMuso, i.e. my drive shows up as /dev/sda because it was manufactured that way?
[04:12] <StevenK> Aloha: It's the controller, not the drive.
[04:12] <TheMuso> Aloha: I don't know
[04:12] <Aloha> StevenK, is the controller part of the drive, or is it a BIOS thing?
[04:12] <TheMuso> I was just pointing out an observation.
[04:13] <StevenK> Aloha: Neither
[04:13] <Aloha> StevenK, oh, a kernel thing?
[04:13] <StevenK> Not that either
[04:13] <StevenK> Aloha: It's a device that hangs off the south bridge
[04:13] <Aloha> StevenK, then what kinda thing is it?
[04:13] <Aloha> StevenK, south bridge?
[04:14] <StevenK> An IDE controller is just another device, like a video card
[04:14] <Aloha> StevenK, is it on the motherboard?
[04:14] <StevenK> Aloha: In 98% of cases, yup
[04:14] <RAOF> Not necessarily, but all modern motherboards incorporate at least one controller.
[04:15] <StevenK> Which means it turns into a connector (or more) and a few chips
[04:15] <Aloha> StevenK, so its my motherboard thats telling ubuntu that i have a scsi drive?
[04:15] <TheMuso> Upon researching my new machine, I have seen boards with only one IDE port now.
[04:15] <ScottK> 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] <StevenK> TheMuso: That started about nine months ago
[04:15] <StevenK> TheMuso: When SATA started getting popular
[04:15] <ScottK> The looks like the only potential barrier between us and a sync.
[04:15] <RAOF> Aloha: Nothing is telling Ubuntu that you've got a scsi drive.
[04:15] <TheMuso> StevenK: Well I've not really been following
[04:15] <StevenK> Aloha: It isn't a SCSI drive, it's just named that way
[04:16] <TheMuso> Yeah well the board I'm looking at has 8 sata ports.
[04:16] <RAOF> Aloha: The kernel is *naming* that drive like a scsi drive because *everything*'s going to be named like a scsi drive.
[04:16] <StevenK> TheMuso: That expands out to two SATA controllers
[04:16] <RAOF> TheMuso: Wow.  More than last I checked.  A bunch of those would be fakeraided together, yes?
[04:16] <TheMuso> StevenK: Yeah, 6 for 1, and 2 for the other I think, from reading specs.
[04:17] <Aloha> RAOF, gotcha. is that because canonical wants it that way or because thats how the kernel is set up?
[04:17] <TheMuso> RAOF: If you choose to use them that way, yes.
[04:17] <RAOF> Aloha: It's an upstream kernel decision.  Everything's moving from the IDE subsystem to libata, and libata names drives sd?
[04:18] <Aloha> RAOF, oh... i get it. so whatever distro's kernel uses libata then that distro will name their drives /dev/sd*, correct?
[04:20] <RAOF> Unless they do something crazy, yes.
[04:20] <ion_> 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] <StevenK> Well, it means you have SCSI and then libata on top
[04:23] <Aloha> is there a file for disk geometry like /proc/ide/hda/geometry?
[04:25] <RAOF> Probably.  Why don't you ferret around inside /proc? :)
[04:26] <TheMuso> Can't hdparm get that kind of stuff?
[04:27] <Aloha> find . -name "*geo*" returned nothing
[04:29] <Aloha> oh hdparm -g
[04:29] <Aloha> TheMuso, thnx
[04:29] <TheMuso> Aloha: np
[04:31] <Aloha> ibm developerwork LPI tutorials are really good
[05:03] <emgent> debian #464170
[05:03] <ubotu> Debian bug 464170 in wordpress "wordpress: security flaw in xml-rpc implementation" [Grave,Fixed] http://bugs.debian.org/464170
[06:17] <pitti> Good morning
[06:18] <pitti> ScottK: postgresql-8.3> what was it?
[06:19] <pitti> Riddell: give-backs> seems that Hobbsee beat me to it
[06:19] <ScottK> pitti: I sorted it out.  It was needing to backport postgres-common too.
[06:19] <pitti> ScottK: ah, backports; yes, you need -common
[06:20] <ScottK> pitti: You've got a backport for Feisty/Gutsy waiting for you or whichever archive admin gets to it first.
[06:20] <pitti> ScottK: do I need to bump the dependency to it?
[06:20] <pitti> or what was the trouble?
[06:20] <pitti> (i. e. it didn't work, but it did with a newer -common?)
[06:20] <ScottK> It worked with the newer common.
[06:21] <ScottK> It won't go back to Dapper though due to cdbs version needs.
[06:22] <pitti> ScottK: right, and due to the python packaging policy
[06:22] <pitti> ScottK: what broke with the current dependency version?
[06:22] <ScottK> I didn't get that far.
[06:23] <ScottK> 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] <pitti> ScottK: I currently keep a manually maintained backport of 8.2
[06:24] <pitti> ScottK: it would be no problem to do the same with 8.3 (technically)
[06:25] <ScottK> If it's manual, I suspect it might be better to let the 8.3 package get some age on it first.
[06:25] <ScottK> I don't guess you'd really want to do two.
[06:26] <pitti> right, one would be better; I maintain 8.2/dapper mainly for Launchpad
[06:28] <superm1> 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] <pitti> superm1: was it rejected yesterday?
[06:30] <pitti> superm1: I never saw that package, if it was yesterday I think Riddell examined it
[06:30] <superm1> let me check when.
[06:31] <superm1> yeah it was yesterday
[06:31] <superm1> i'll check with Riddell then when he's back around
[06:31] <superm1> thanks
[06:58] <pitti> 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] <pitti> zul: yay for packages with bad sonames :/
[06:59] <pitti> 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] <dholbach> good morning
[07:51] <emgent> hi dholbach
[07:51] <ion_> Howdy-ho
[07:52] <dholbach> hey ion_, hey emgent
[09:17] <seb128> anybody here with acroread installed?
[09:17] <tjaalton> pitti: is it reasonable to ask that apport crash files are readable by users? There's a bug open about it
[09:17] <tjaalton> seb128: _o/
[09:17] <seb128> tjaalton: https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/183271
[09:17] <ubotu> Launchpad bug 183271 in poppler "evince and kpdf fail to open a pdf which works in Adobe Reader 7" [Low,New]
[09:17] <seb128> tjaalton: can you try to open the file attached there?
[09:18] <tjaalton> seb128: sure, a sec
[09:18] <seb128> tjaalton: apport files are readable by users at the moment alreadt
[09:19] <tjaalton> seb128: ok, in that case I'll close it as fixed
[09:19] <tjaalton> seb128: yep, works with acroread
[09:20] <seb128> thanks
[09:20] <seb128> tjaalton: you can read your own crashes, not the one from other users, is that what you expect?
[09:20] <tjaalton> seb128: that makes sense
[09:20] <tjaalton> it's bug 72665
[09:20] <ubotu> Launchpad bug 72665 in xorg-server "using "chown" in /var/crash" [Undecided,Incomplete] https://launchpad.net/bugs/72665
[09:21] <pitti> tjaalton: WDYM with 'readable'? except for the core dump they are just ascii
[09:22] <tjaalton> pitti: that the user can look at the contents without sudo
[09:22] <tjaalton> I have a compiz crashdump with mode 0000
[09:22] <pitti> tjaalton: ah, that meaning of 'readable' :)
[09:22] <pitti> tjaalton: they are usually 000 while the report is still being written
[09:23] <pitti> so that the frontend doesn't try to read a half-written report
[09:23] <pitti> but when apport finishes it chmods it to 0600
[09:23] <tjaalton> oh ok
[09:23] <pitti> tjaalton: it sounds like apport crashed in your case
[09:23] <pitti> tjaalton: does the .crash file look complete? do you have an exception in /var/log/apport.log?
[09:24] <pitti> tjaalton: I didn't see that bug, and I went through all apport bugs yesterday; what's the #?
[09:26] <tjaalton> pitti: which one? bug 72665 was against xorg-server
[09:26] <ubotu> Launchpad bug 72665 in xorg-server "using "chown" in /var/crash" [Undecided,Incomplete] https://launchpad.net/bugs/72665
[09:26] <tjaalton> so perhaps apport failed in this case as well
[09:28] <tjaalton> pitti: my apport.log only shows the "executable: /usr/bin/compiz.real (...) entry and nothing else about the crash
[09:40] <pitti> tjaalton: got disconnected; did you say anything after '[10:23]  tjaalton| oh ok' ?
[09:40] <tjaalton> pitti: ah, yes:
[09:40] <tjaalton> 11:26 < tjaalton> pitti: which one? bug 72665 was against xorg-server
[09:40] <ubotu> Launchpad bug 72665 in xorg-server "using "chown" in /var/crash" [Undecided,Incomplete] https://launchpad.net/bugs/72665
[09:40] <tjaalton> 11:26 < tjaalton> so perhaps apport failed in this case as well
[09:40] <tjaalton> 11:28 < tjaalton> pitti: my apport.log only shows the "executable: /usr/bin/compiz.real (...) entry and nothing else about the crash
[09:42] <pitti> tjaalton: that particular bug seems useless, yes
[09:42] <pitti> tjaalton: and it doesn't talk about the permissions being 000, just that it belongs to root (which is correct)
[09:43] <tjaalton> pitti: yeah, closing
[09:44] <tjaalton> pitti: so since the process is run as root -> crash file owned by root?
[09:44] <pitti> right
[09:46] <Riddell> superm1: https://lists.ubuntu.com/archives/ubuntu-archive/2008-February/015359.html
[10:29] <saispo> anyone have an idea or know how to fix the dot in console mode with an Ubuntu gutsy ?
[10:30] <saispo> under a French keyboard i must use shift for doing a dot with the keypad...
[10:32] <seb128> saispo: what happens when you don't use shift?
[10:33] <saispo> seb128: nothing :/
[10:33] <saispo> i try a dpkg-reconfigure console-data
[10:34] <saispo> but not working :)
[10:34] <saispo> seb128: have you the same things ?
[10:35] <seb128> saispo: no idea, I'm using my laptop right now and I've no keypad there
[10:38] <saispo> yes, same for me :)
[10:45] <cjwatson> saispo: don't use console-data, it's dead as of edgy
[10:45] <cjwatson> console-setup <- new world order
[10:45] <saispo> ok, will try
[10:47] <saispo> cjwatson: nothing :)
[10:47] <cjwatson> saispo: grep XKB /etc/default/console-setup; what's the output?
[10:50] <Mez> doko_: you're the on handling coreutils for ubuntu atm ?
[10:51] <doko_> the same way as every core developer does
[10:51] <Mez> doko_, ah - I was only wondering as you're the last changelog.
[10:51] <Mez> 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] <saispo> cjwatson: hmmm query ?
[10:52] <cjwatson> saispo: sure
[10:54] <doko_> Mez: probably a version mismatch with current langpacks? pitti?
[10:55] <Mez> doko_, no idea - I'm just running a test on my system for broken symlinks
[10:58] <pitti> doko_, Mez: ah, it seems to assume that ../LC_MESSAGES/coreutils.mo exists
[10:58] <pitti> which isn't true with langpacks (it's in /usr/share/locale-langpack, not /usr/share/locale/)
[11:01] <cjwatson> maybe the langpacks should ship the LC_TIME symlinks
[11:02] <cjwatson> seems pretty messy to symlink from locale/ll/LC_TIME/coreutils.mo to ../../../locale-langpack/ll/LC_MESSAGES/coreutils.mo
[11:05] <Mez> also found a typo in libsnmp
[11:18] <pitti> cjwatson: I agree
[11:26] <ogra> cjwatson, was thre a decision about putting users into fuse by default with hardy ?
[11:27] <ogra> i think it would make sense to have it in the default groups adduser uses to avoid all these issues
[11:28] <ogra> (instad of having a notification)
[11:30] <cjwatson> adduser doesn't have default groups; user-setup does
[11:31] <cjwatson> somebody filed a bug on user-setup asking for that, although they mentioned several other groups in the same bug
[11:31] <cjwatson> I'm open to opinions - it sounds fairly reasonable to me but I'm interested to hear if anyone has contrary opinions
[11:32] <ogra> should put it on e meeting agenda ?
[11:32] <cjwatson> what security vulnerabilities, if any, does being in that group open up?
[11:32] <cjwatson> yeah, that sounds like a good idea actually
[11:32] <ogra> full access to dev fuse ....
[11:32] <ogra> which means you can do all nasty stuff through hacking togther your own fuse userspace tools
[11:32] <cjwatson> right, I know, but for instance there is presumably a reason why that isn't just open to everyone
[11:33] <cjwatson> I'm wondering whether this is like group audio or like group disk
[11:33] <ogra> fuse has a lots of power
[11:33] <cjwatson> the former shouldn't be open to everyone, but it makes complete sense for the default user to have it
[11:33] <ogra> rahe disk i guess
[11:33] <ogra> *raher
[11:33] <ogra> gah
[11:33] <cjwatson> the latter lets you shoot yourself in the foot and so we do not even give it to the default user
[11:34] <ogra> well, you *can* have full access to any filesystem through a userspace toolou write ourself ...
[11:34] <ogra> grmbl
[11:34]  * ogra beats his wireless keyboard
[11:35] <cjwatson> err
[11:35] <cjwatson> 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] <cjwatson> as opposed to a loop-mounted file in your home directory, for example
[11:36] <ogra> i think thats possible, yes
[11:36] <cjwatson> or presumably let you create a filesystem as an ordinary user and put a set-id executable on it?
[11:36] <cjwatson> or does it block set-id?
[11:38] <ogra> 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] <Hobbsee> pitti: yeah.  being an australian, that's easier
[11:39] <pitti> hey Hobbsee
[11:39] <ogra> i think you can work around access restrictions in userspace here but thats an unproven statement
[11:39] <cjwatson> 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] <cjwatson> I think we need more information before making a decision here
[11:39] <ogra> good
[11:40] <Mithrandir> ogra: uh, no, it doesn't work that way at all.  fuse runs as your user.
[11:40] <ogra> Mithrandir, the module ?
[11:41] <ogra> i know the top level does
[11:41] <ogra> but that gains me access to low level functions i wouldnt be able to use directly
[11:41] <Mithrandir> 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] <Mithrandir> like what?
[11:42] <cjwatson> Mithrandir: I think we need to check this :)
[11:42] <ogra> Mithrandir, no idea, disks i couldnt access otherwise :)
[11:43] <cjwatson> ogra: hmm, that does seem curious; opening the block device ought to be done on the userspace side
[11:43] <ogra> i mean look at ntfs .... ntfs3g does exactly that, no ?
[11:44] <cjwatson> ogra: ntfs-3g opens the block device from userspace
[11:44] <cjwatson> (see ntfs_device_unix_io_open)
[11:44] <Mithrandir> : tfheen@xoog ~ > /bin/ntfs-3g /dev/sda3 /mnt
[11:44] <Mithrandir> Error opening partition device: Permission denied
[11:44] <Mithrandir> Failed to mount '/dev/sda3': Permission denied
[11:45] <Mithrandir> so that has to be invoked from a privileged process
[11:45] <ogra> ok
[11:45] <cjwatson> Mithrandir: what happens if you mount -t ntfs-3g /dev/sda3 /mnt?
[11:45] <cjwatson> err, possibly fusermount
[11:45] <ogra> mount wont let you :)
[11:45] <ogra> right
[11:46] <Mithrandir> and suid doesn't go across at least sshfs
[11:47] <cjwatson> that could be just sshfs not implementing it though
[11:47] <cjwatson> don't get me wrong, I think you're probably right, but I also think it deserves to be checked
[11:47] <Mithrandir> how would it "not implement it"?  It's suid from the looks of ls.
[11:47] <Mithrandir> -rwsr-xr-x 1 list tfheen 9066 2008-02-06 12:46 test*
[11:47] <Mithrandir> : tfheen@xoog ~/iphone > ./test
[11:47] <Mithrandir> 1000
[11:47] <Mithrandir> : tfheen@vuizook ~ > ./test
[11:47] <Mithrandir> 38
[11:48] <cjwatson> Mithrandir: sshfs has a method somewhere that returns the permissions set on the file
[11:48] <cjwatson> it has to figure out what those are on the other end of ssh
[11:48] <cjwatson> it could easily decide only to care about mode&0777
[11:48] <Mithrandir> wouldn't then ls not list it as suid?
[11:49] <cjwatson> http://lists.planet-lab.org/pipermail/devel/2006-November/001831.html <- possibly relevant
[11:49] <cjwatson> Mithrandir: oh, I thought you meant that that was native ls
[11:49] <cjwatson> ok
[11:49] <Mithrandir> oh, sorry, it was through sshfs, yes.
[11:50] <Mithrandir> and even with -o suid it's still mounted nosuid,nodev
[11:53] <cjwatson> (the oops that the poster to planet-lab ran into is fixed in our current kernels)
[11:57] <Mithrandir> that one looks like "fuse might have bugs", which given it's software, it's bound to have.
[11:57] <ogra> right, but do we want it in the default groups with these possible bugs ?
[11:58] <ogra> 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] <cjwatson> I'm much less concerned about DoS possibilities (which we need to fix anyway) than about fundamental misdesign
[11:58] <Mithrandir> ogra: the kernel probably has exploitable bugs in various syscalls too.  Or sudo.  Or any other piece of the stack.
[11:59] <ogra> i'm only concerned about all that bugreports :)
[11:59] <cjwatson> ogra: if you have a current open master bug about this, please reassign it to user-setup
[11:59] <Mithrandir> cjwatson: agreed, and fuse doesn't seem to have fundamental misdesigns, afaict.
[11:59] <ogra> the actual fix would be "instantly applying group membership" though
[11:59] <Mithrandir> at least not from a security point of view.
[11:59] <Mithrandir> ogra: that's hard, due to how UNIX works.
[12:00] <ogra> 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] <cjwatson> leave the notification there, but we'll make it go away for the default user
[12:02] <cjwatson> I think that's a reasonable compromise for hardy
[12:02] <ogra> leave ? you mean add one :)
[12:02] <cjwatson> I thought there was a notification at the moment
[12:03] <cjwatson> in that case, I guess add one
[12:03] <ogra> there is nothing atm
[12:03] <cjwatson> though fuse is installed by default
[12:03] <cjwatson> so perhaps a notification is unlikely to be all that useful
[12:03] <ogra> 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] <cjwatson> I am not comfortable with adding all users by default for hardy
[12:04] <ogra> s/what/that/
[12:04] <ogra> ok
[12:04] <ogra> i'll add the notification so we cover te upgraders at least
[12:04] <ogra> *the
[12:06] <Mithrandir> 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] <Mithrandir> to me, that looks like something which could (and maybe should) be generalised.
[12:08] <ogra> hmm
[12:16] <soren> Where can I find the info that used to live in /proc/bus/usb/devices ?
[12:17] <persia> soren: Some of it is in /sys/bus/usb, and the rest is no longer directly available.
[12:17] <ogra>  /sys/bus/usb/device
[12:19] <persia> soren: The discussion in bug #156085 may provide more information
[12:19] <ubotu> Launchpad bug 156085 in qemu "Could not open /proc/bus/usb/devices" [Low,Confirmed] https://launchpad.net/bugs/156085
[12:19] <soren> persia: That's the bug I'm working on fixing :)
[12:19] <persia> heh
[12:19] <soren> persia: I don't want to reenable usbfs.
[12:20] <soren> 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] <soren> I just wanted to check if it was already available somewhere.
[12:21] <persia> 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] <ogra> 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] <asac> ogra: http://www.asoftsite.org/s9y/archives/127-CALL-for-TESTERS-firefox-stabilitysecurity-RC-builds-need-QAfeedback.html
[12:29] <asac> ogra: was the mail truncated for you?
[12:30] <ogra> http://paste.ubuntu-nl.org/54981/ yup, apparently
[12:30] <asac> 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] <ogra> ah, right
[12:30] <ogra> that info was missing
[12:43] <asac> dholbach: pitti: i don't understand why the xml entities don't get installed in the same directory :)
[12:43] <asac> i mean even the source has them in the same dir afaict
[12:43] <zul> pitti: hmmmm?
[12:43] <dholbach> slytherin, persia: asac seems to have some questions aout the change
[12:43] <asac> and catalogs are only an sgml standard afaik ... no such thing officially exists for xml
[12:44] <pitti> zul: the hmm refers to what? :)
[12:44] <asac> if parsers support it ... fine ... but we cannot demand all xml parsers to know about catalogs
[12:44] <slytherin> asac: Are you referring to the comment on Debian bug?
[12:44] <zul> pitti: something about abi and soname?
[12:45] <pitti> zul: well, you can't ship the same library in two different packages which don't Conflicts: to each other
[12:45] <asac> 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] <pitti> zul: and libfooX.Y packages should not conflict to each other
[12:46] <zul> ill fix that today
[12:46] <pitti> 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] <slytherin> asac: Yes, I am the one who made that comment. :-)
[12:46] <pitti> zul: what's your feeling how this shuold be fixed?
[12:48] <asac> 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] <pitti> ack
[12:48] <asac> 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] <asac> so same directory as well
[12:49] <pitti> asac, slytherin: it shouldn't be too hard to check the reverse dependencies; there are only 5
[12:49] <zul> pitti: add the conflicts and see about adding sonames or talking to upstream about it
[12:49] <pitti> zul: please don't add Conflicts:, that'll break upgrades
[12:50] <pitti> 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] <pitti> (IMHO)
[12:50] <asac> slytherin: can you update the debdiff to just use the same location? and fix the catalogs accordingly?
[12:51] <slytherin> asac: Ok. Will do. But then I don't have enough time to analyze the regressions
[12:51] <zul> pitti: ok will have a look ill talk to soren as well
[12:51] <pitti> thanks
[12:51] <asac> slytherin: thats ok ... i will take a quick look if you bug me afterwards :)
[12:51] <persia> asac: Might it be OK to ship with symlinks for now, and dig through the possible regressions later?
[12:52] <slytherin> asac: I guess if I update catalog also then there shouldn't be much problem. I will keep my fingers crossed.
[12:52] <pitti> persia: but they should be the other way round then (symlinks are in the old place, files in the correct one)
[12:52] <asac> persia: when? i suspect that most rely on catalog so we most likely won't see regressions.
[12:53] <asac> i am fine with what pitti says too
[12:53] <persia> 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] <persia> pitti: Sounds perfectly sane.
[12:55] <asac> persia: do we have a list of current FTBFS due to this?
[12:55] <persia> asac: I only know about lucene2.  slytherin was investigating in more depth.
[12:56] <slytherin> 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] <slytherin> I can only comment about java apps though. Not sure about how C/C++ apps use the DTD
[12:57] <asac> slytherin: http://paste.ubuntu.com/4246/ ... is that the error you refer to?
[12:58] <slytherin> 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] <asac> hmm ... but it would still fail on that internet access ... or is it a fallback because it couldn't resolve it locally?
[12:59] <persia> The attempt to access the internet is a fallback from not finding it locally.
[13:00] <asac> sure?
[13:00] <slytherin> 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] <asac> slytherin: how?
[13:01] <slytherin> 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] <asac> slytherin: hmmm ... have you tried http://xml.apache.org/commons/components/resolver/tips.html ?
[13:05] <asac> to tell where the catalog is?
[13:05] <asac> (e.g. patching system ids to refer to absolute local paths isn't much better ;))
[13:06] <persia> That solution also needs an additional build-dep (which isn't necessarily bad)
[13:07] <slytherin> asac: No I didn't try it.
[13:07] <asac> no idea if it can work if lucene uses xerces directly (without commons)
[13:07] <stgraber> 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] <asac> stgraber: the only thing i know is that the mail got truncated (maybe thats the bug)?
[13:09] <asac> thought i hit some max letters constraint or something
[13:09] <asac> stgraber: UTC?
[13:09] <stgraber> the bug is happening in the event handling part of the code but it's before the mail is sent
[13:09] <stgraber> CET (UTC+1)
[13:10] <asac> 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] <asac> maybe that?
[13:11] <soren> pitti: How will splitting the library into a separate package fix anything? (re: libxen3.[12])
[13:13] <stgraber> asac: btw, you could have just renamed your extra milestone :)
[13:13] <asac> oh ... yeah. still need to get used to all the tiny tiny things on that page i guess :)
[13:15] <stgraber> ok, so you added 3 milestones and then went to the Add build page
[13:15] <stgraber> ticked Firefox, entered the version number and added, doing the same for the 3 milestones ?
[13:16] <asac> 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] <asac> once i noticed it, i hid it and added the correct one
[13:17] <asac> 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] <soren> 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] <stgraber> 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] <asac> stgraber: good!
[13:19] <stgraber> asac: Do you have a link to the mail you sent earlier so I can see what went wrong with it ?
[13:19] <asac> i try to remember more details on what i did next time :)
[13:19] <zul> soren: it is backwards compatible I believe
[13:19] <asac> stgraber: a link?
[13:19] <stgraber> asac: yes, or just a copy/paste of the content
[13:20] <soren> zul: In that case, I think we should build a libxen3 binary rather than a libxen3.2 one.
[13:20] <asac> 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] <soren> pitti: What do you think?
[13:22] <asac> stgraber: i did manual line breaks though
[13:22] <stgraber> asac: Do you remember if the preview was correct ? (a preview of the mail is shown before it's actually sent)
[13:23] <asac> stgraber: yes the preview was correct
[13:23] <asac> thats why i had to do manual line breaks ;)
[13:25] <asac> stgraber: i now see that it got chopped at the first |"|
[13:25] <geser> could an build admin please give back: shogun. Thanks.
[13:25] <asac> most likely an escaping issue i guess
[13:25] <asac> stgraber: e.g. f you don’t have time to do the full “testplan from https://wiki.ubuntu.com/MozillaTeam/QA” ... it truncated after "full"
[13:27] <asac> the letter count and line count doesn't look suspicious so maybe its indeed the "
[13:28] <stgraber> asac: ok, reproduced, it's indeed the "
[13:28] <asac> great ... always happy to hit corner cases ;)
[13:29] <stgraber> asac: I now have to find how I'm supposed to handle escaping with php's mail() function (I doubt I can use the same escaping as for the SQL)
[13:30] <jwendell> seb128, Hi. The mouse scroll in touchpad is not working in Hardy. Is this an know issue? (Also the mouse capplet doen't have touchpad tab anymore)
[13:30] <seb128> jwendell: no idea, that doesn't look like a GNOME bug and I don't know about xorg etc
[13:31] <persia> jwendell: bug #173411
[13:31] <ubotu> Launchpad bug 173411 in xorg "[Hardy][Regression] Touchpad vertical scroll does not work" [Medium,Confirmed] https://launchpad.net/bugs/173411
[13:31] <jwendell> thanks, persia
[13:31] <persia> Also, #ubuntu-bugs is a good place to ask about known bugs.
[13:31] <jwendell> wow 12 duplicates :)
[13:32] <asac> stgraber: why do you need to escape sql? do you concat strings? instead of using placeholders and setting the values (i presume that those two approaches exist for php as well)
[13:34] <Mithrandir> geser: given-back
[13:34] <asac> stgraber: like http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.apdv.php.doc/doc/t0023150.htm
[13:35] <asac> stgraber: or http://www.petefreitag.com/item/356.cfm
[13:36] <pitti> soren, zul: building libxen3 instead of 3.x> that sounds great (plus replaces:/provides/conflicts)
[13:37] <soren> pitti: R/P/C of course. Business as usual :)
[13:37] <pitti> soren: that's by far the best solution indeed, great
[13:38] <soren> pitti: Cool. Thanks for your input.
[13:38] <stgraber> asac: those are not the standard mysql functions you have in PHP (the first is object oriented and the second is about some db2 functions I don't have with mysql)
[13:39] <asac> stgraber: you mean the second is object oriented and the first is db2 :)
[13:39] <slytherin> asac: pitti: persia: FYI ... updated debdiff attached to bug 183164
[13:39] <ubotu> Launchpad bug 183164 in w3c-dtd-xhtml "Wrong path for entity sets" [Undecided,Confirmed] https://launchpad.net/bugs/183164
[13:39] <asac> stgraber: what is bad about using OO in php for prepared statements?
[13:40] <stgraber> asac: yes, I haven't opened them in the order you gave them :)
[13:40] <asac> :)
[13:40] <stgraber> asac: we are using Drupal as backend and it's code is done using the standard mysql functions + some wrapper
[13:41] <stgraber> so I'm basically using some db_* functions which then access the DB server (now postgresql, it used to be mysql)
[13:41] <stgraber> so we'll use object-oriented as soon as Drupal also does
[13:41] <asac> thanks for clarifying
[13:43] <asac> slytherin: ok looks good ... have you tested that it fixes the build failure?
[13:44] <slytherin> asac: Let me do it. I guess I will have to install it locally in pbuilder right?
[13:44] <asac> slytherin: yes ... to be safe tear down your network during the build :)
[13:45] <asac> let me know if the build succeeds. i would then upload
[13:45] <asac> slytherin: i think just testing a build in your normal system without network should be sufficient as well (if you don't want to deal with pbuilder)
[13:46] <slytherin> asac: I am patching the unit test to use local DTD. I don't think I need to disconnect from network.
[13:46] <asac> slytherin: yes, thats why i said "to be safe" :)
[13:47] <slytherin> asac: Ok. Let me install build deps first
[13:53] <slytherin> I will be back. :-)
[13:54] <gaspa> someone's going to fosdem, this month?
[13:55] <stgraber> asac: problem found and fixed, the fix will be on-line with the next code update (probably today)
[13:58] <geser> shogun FTBFS because it build-depends on python-numpy-dev which is provided by python-numpy and still a real package but NBS. apt tries to install the real one but python-numpy conflicts with it and apt reports broken deps. What the better solution: drop the build-depends or kill python-numpy-dev from the archive?
[14:00] <asac> stgraber: rock!
[14:03] <stgraber> asac: Ng just did the sync, so it's fixed on qa.ubuntu.com now
[14:14] <slytherin> asac, lucene2 builds fine. :-)
[14:19] <asac> slytherin: ok uploading
[14:24] <superm1> thanks Riddell.  I'll make sure that gets taken care of.  sorry for the oversights
[14:49] <zul> seb128: ping
[14:50] <Iulian> Hi
[14:50] <seb128> zul: no context ping no reply
[14:50] <seb128> hey Iulian
[14:50] <zul> seb128: sorry its yor archive admin day today correct?
[14:50] <seb128> zul: yes
[14:51] <zul> seb128: we need to get rid of all the xen related packages out of main except for libxen what is the process of doing that?
[14:51] <seb128> zul: open bugs and subscribe ubuntu-archive
[14:52] <zul> seb128: ok thanks..
[14:52] <seb128> you are welcome
[14:52] <seb128> or one bug with the list of packages to demote
[14:53] <_MMA_> seb128: Hello. I was wondering if you updated the gdmplay issue? With it not being executable.
[14:54] <seb128> hey _MMA_
[14:54] <seb128> _MMA_: ah, right, let me fix that right now
[14:54] <_MMA_> Awesome. Thanx.
[14:54] <seb128> you are welcome
[14:58] <Mez> what kind of database does dpkg use?
[14:59] <Mez> (for dependencies)
[14:59] <soren> Mez: I'm curious... why?
[14:59] <Mez> soren, thinking about making lil playthings to query the database etc etc
[15:00] <soren> Mez: I recommend you use the existing tools for that. It's a simple rfc822-ish text file, though.
[15:00] <Mez> soren, more stats stuff
[15:00] <Mez> soren, just curious about playing around
[15:00] <Mez> soren, location?
[15:01] <soren> Mez: /var/lib/dpkg
[15:01] <Mez> yep, theres a lot of files in there
[15:01] <Mez> I'm looking specifically for the deps stff
[15:01] <soren> Mez: It depends on what you're looking for specifically.
[15:01] <Mez> soren, dependencys
[15:01] <Mez> s/y.ie/
[15:01] <Mez> s/\./\//
[15:01] <soren> Mez: You might want to look at the output from apt-cache dumpavail.
[15:02] <Mez> soren, but where does that get it's info from?
[15:02] <soren> Mez: /etc/apt/sources.list, /var/lib/apt/lists/
[15:03] <Mez> so it reads directly from the cached packages files for all the dependency stuff?
[15:03] <Mez> I thought it'd read from some sort of database...
[15:03] <Mez> hmmles
[15:04] <soren> apt-cache dumpavail reads from the cached PAckages files.
[15:04] <geser> pitti, Mithrandir: shogun FTBFS because it build-depends on python-numpy-dev which is provided by python-numpy and still a real package but NBS. apt tries to install the real one but python-numpy conflicts with it and apt reports broken deps. What the better solution: drop the build-depends or kill python-numpy-dev from the archive?
[15:05] <Mez> soren, when apt resolves dependencies (when you try to install it and it says "but I need this and this and this and this"
[15:05] <Mez> that gets it from the cached packages too ?
[15:05] <soren> Mez: Yes.
[15:06] <soren> Mez: There is no binary database of any sort, if that's what you're looking for.
[15:06] <Mez> soren - I see... I can forsee me having fun making it use a database ;)
[15:06] <Mez> soren, I just think it might be faster and less resource intensive to query a database
[15:17] <pochu> Has anyone noticed a slowdown on bootup with the 2.6.24 kernel (vs 2.6.22) for usplash to ask for the key?
[15:23] <asac> calc: on?
[15:27] <charles_> jamiemcc: ping
[15:28] <jamiemcc> hi charles_
[15:28] <charles_> hi
[15:28] <charles_> jdong asked me to talk to you about https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/189439
[15:28] <ubotu> Launchpad bug 189439 in transmission "Transmission should use a temp-dir to exclude from indexing" [Wishlist,Incomplete]
[15:29] <charles_> the basic problem is that downloading huge binaries somewhere under the users' home directory seems to mix poorly with indexing :)
[15:29] <Vadi> Imo, that's the trackers problems. It even indexes .part files.
[15:29] <jamiemcc> charles_: yeah we are working on auto blacklisting files that change frequently
[15:29] <charles_> the recommendation in that ticket is to download to a tmp dir instead, but I'm not sure storing downloads in a tmp dir is a good idea :)
[15:30] <jamiemcc> charles_: we should be able to detect stuff thats chaniging too often in the next version
[15:30] <charles_> cool
[15:30] <charles_> how far away is the next version?
[15:31] <jamiemcc> charles_: we are aiming for feb 14th - the ubuntu feature freeze
[15:31] <charles_> oh, that's great news
[15:31] <charles_> I'll annotate the ticket with that information
[15:31] <jamiemcc> charles_: ok thx
[15:31] <charles_> thanks
[15:33] <jdong> jamiemcc: what would be the "cost" of such detection and does it work against slowly trickling torrents?
[15:34] <jdong> jamiemcc: for example, a torrent with 10 700MB files, all are preallocated at the beginning, then maybe only 2 or 3 are actively downloading at a time
[15:34] <jdong> jamiemcc: does that mean tracker will detect 6 unchanged 600MB blank files and try to index them?
[15:35] <jamiemcc> jdong: yes unless we can ignore them
[15:35] <jdong> jamiemcc: is there currently an API/command for an application to tell tracker to ignore a certain path, then later unignore it?
[15:35] <jamiemcc> jdong: not at the moment - but it is a good idea
[15:35] <Vadi> While we're on this, can it ignore .part files? Those that are being downloaded. It makes tracker get stuck on them.
[15:35] <jdong> jamiemcc: I mean, the modification exclusion is a good thing (tm) but an API like this will be more useful for P2P and other harder to detect corner cases
[15:36] <jamiemcc> Vadi: sure - thats a good idea too
[15:36] <jamiemcc> jdong: I agree
[15:36] <charles_> jamiemcc: the API call to say "ignore this directory" is essentially what Transmission does for Time Machine on OS X
[15:36] <jamiemcc> charles_: I will see if i have time to squeeze that in before feature freeze
[15:37] <jdong> jamiemcc: in addition to ignore this directory (recursively), it'd be nice if it also accepts "ignore this file"
[15:37] <jdong> though of course that adds a design question as to how the unignore command should work
[15:37] <jamiemcc> jdong: yes agree
[15:38] <charles_> I like the idea of trackerd auto-detecting better though...  fewer ways for the clients to screw things up
[15:39] <jamiemcc> charles_: yes thats the plan - if you know any file patterns that should always be ignored then let me know
[15:40] <jdong> charles_: well autodetecting is a good initial barrier and should be used but it cannot be expected to detect ALL cases to ignore indexing
[15:40] <jamiemcc> charles_:  jdong: i have to shoot off for an hour - email me<EMAIL_ADDRESS>any toughts
[15:41] <jdong> charles_: which is why an API is a nice option for applications that can slip by :)
[15:41] <calc> asac: yea
[15:42] <calc> asac: whats up?
[15:43] <asac> calc: openoffice.org -> xulrunner-1.9
[15:43] <Vadi> Does Ubuntu 6.06 use the 2.4 or the 2.6 kernel?
[15:43] <asac> calc: how is firefox-dev used atm during build?
[15:44] <asac> calc: could you take a look and give me pointers so i can drop some brief instructions on how to switch build-depends?
[15:46] <calc> asac: ok, looking
[15:46] <asac> calc: i see that rule defines --with-system-mozilla=firefox ... but couldn't see how the build system makes use of it
[15:47] <calc> its done a bit differently
[15:47] <calc> i'll privmsg it to you since its about 10 lines
[15:47] <asac> calc: paste please :)
[15:47] <asac> http://paste.ubuntu.com
[15:47] <calc> asac: oh oops did it already
[15:47] <calc> i'll put it up on paste as well
[15:47] <asac> calc: didn't get any pmsgs
[15:48] <calc> http://paste.ubuntu.com/4256/
[15:48] <pochu> calc: you need to be identified to be able to /msg people :)
[15:48] <asac> well ... i know that ... but still i don't know where the build system makes use of it
[15:48] <calc> ah somehow freenode forgot i was identified
[15:48] <calc> i hate freenode
[15:48] <calc> it always forgets i am identified for whatever reason
[15:49] <calc> asac: oh that, i'll have to look to see if i can find out where, the build system is a bit complicated
[15:49] <asac> calc: at best just move it to xulrunner-1.9-dev while you are at it ;)
[15:50] <asac> if you have specific issues i can tell you how, but you are more used to building ooo then i am i guess
[15:51] <calc> ok yea i'll see what happens if i just change it over to xulrunner-1.9-dev
[15:51] <asac> calc: it won't work ... if it works, you have done something wrong :) ... or the build-depends/depends are not needed (which would be even better i guess)
[15:52] <asac> for instance the .pc files are named differently (at least some)
[15:54] <calc> asac: ah ok, i will look into how it is used then first :)
[15:55] <asac> right
[15:55] <asac> i'll prod you later today ;)
[15:58] <calc> so if the pc files changed is it even api compatible?
[16:00] <calc> evand: had any time to look at the partition issue? ;-)
[16:01] <evand> calc: probably not until FF at this point :/.  Lots of spec work.
[16:01] <calc> evand: ok
[16:14] <davmor2> guys libxen3.2 seems to be broken this is the error report in synaptic.  E: /var/cache/apt/archives/libxen3.2_3.2.0-0ubuntu3_i386.deb: trying to overwrite `/usr/lib/libblktap.so.3.0.0', which is also in package libxen3.1
[16:15] <cjwatson> known
[16:16] <cjwatson> (zul and pitti were talking about that earlier)
[16:16] <davmor2> cjwatson: cool
[16:53] <tjaalton> damn, the -intel driver I just uploaded is broken (hangs on xserver start at least on i965), could it be put on hold until a fix is released?
[16:55] <tjaalton> hmm, actually, the patch I got works after all..
[16:56] <tjaalton> so I'll just upload that
[17:01] <asac> calc: api compatible - depends on what kind of api ooo uses
[17:02] <Lutin> pitti: can you give-back kdenlive please ?
[17:02] <asac> calc: figure that out and i can give you more info :)
[17:05] <pitti> Lutin: done
[17:05] <Lutin> pitti: thanks
[17:06] <calc> asac: ok
[17:10] <geser> pitti: have you seen my question about the shogun FTBFS?
[17:37] <pitti> geser: no, I don't think I did
[17:39] <geser> pitti: shogun FTBFS because it build-depends on python-numpy-dev which is provided by python-numpy and still a real package but NBS. apt tries to install the real one but python-numpy conflicts with it and apt reports broken deps. What the better solution: drop the build-depends or kill python-numpy-dev from the archive?
[18:13] <pitti> geser: if it's NBS, then I'd drop it in any case
[18:13] <pitti> geser: but fixing the build dep would still be good
[18:14] <warp10> Good evening
[18:14] <pitti> hi warp10
[18:15] <pitti> geser: I removed it
[18:15] <warp10> hey pitti :-)
[18:15] <geser> pitti: thanks, will do an upload later
[18:17] <pitti> geser: oh, I just see that we don't have a delta yet
[18:17] <pitti> geser: I'd say, don't worry about it; I'll just give it back tomorrow morning
[18:17] <alex-weej> the archives are very slow...
[18:18] <alex-weej> at least the UK one is
[18:18] <alex-weej> 10 kb/s :(
[18:18] <alex-weej> vs. well over 1 Mbit on other routes
[18:18] <asac> doko: my local icedtea build works for me in ffox on amd64 ...
[18:18] <asac> ?
[18:19] <geser> pitti: ok, thanks
[20:37] <doko> asac: hardy?
[20:37] <doko> nice!
[20:40] <ogra_cmpc> doko: many people on that bug colin pointed out said the same ...
[20:40] <ogra_cmpc> i think the last commenter even suspected a discrepancy between soyuz and pbuilder
[20:55] <doko> ogra_cmpc: hardy != gutsy
[20:55] <ogra_cmpc> oh, right, sorry
[21:04] <asac> ogra_cmpc: i have used pbuilder with buildd flavour ... no idea if that comes close to our soyuz though
[21:04] <asac> but most likely it was a temporary bustage in some lib/compiler ;)
[21:06] <ogra_cmpc> i'll send a test call out to the edubuntu ML tomorrow ... even though i think most of my users use 32bit FF on theior 64 bit servers