[03:24] <ne78> Does the php5 package of edgy includes pdo supports ? pdo is part of php5.1 and debian still miss it for 206 days (bug 348882)
[03:25] <infinity> ne78: No.  It's on my TODO list.
[03:26] <infinity> ne78: Upstream made it a pain to enable gracefully without building everything as one big static blob, so I've been playing with ways to work around that.
[03:26] <ne78> infinity: http://people.debian.org/~dexter/dists/php5.1/ has it but it uses it's infame build system
[03:27] <infinity> Yeah, I know dexter's done it, though I haven't poked through his patches yet.
[03:27] <ne78> infinity: are you doing both the debian and ubuntu packages or just the ubuntu diff ?
[03:27] <infinity> He's been entirely unwilling to ever actually contribute to the official packages (short of wanting to completely take them over), so it's a mess.
[03:27] <infinity> ne78: I'm one of the Debian maintainers, and the Ubuntu maintainer, yes.
[03:28] <ne78> infinity: yes that's what i understood from the mailing lists
[03:28] <ne78> infinity: but in the mean we (the simple users) suffer :)
[03:28] <infinity> Yeah, I have an apache and php TODO a mile long, but I'll get through it all eventually.
[03:29] <infinity> I only allocate a certain amount of paid time to apache and php, and the rest is "spare time" effort, so it sort of "happens when it happens". :/
[03:29] <ne78> infinity: shipping etch/edgy without PDO would be a grave error
[03:29] <infinity> ne78: I've heard this opinion before.
[03:29] <ne78> infinity: i mean php is a critical package (at least for servers)
[03:29] <infinity> ne78: On the other hand, 3rd party applications RELYING on features only present in PHP 5.1 are broken by design, so I don't think it's as critical as people make out.
[03:30] <ne78> infinity: nope they are not, the api before 5.1 was insane
[03:31] <robertj>   * Start OLPC Edubuntu effort (first Thailand Beta due Jan 1th 2007) <- is Thailand the code name or is there some other tie-in?
[03:32] <ne78> infinity: probably a nice thing would be a PDO wrapper for pre 5.1 i'm wondering if that exists
[03:32] <infinity> ne78: I'm pretty sure it doesn't.  It would be a painful mess of interpreted code.
[03:33] <infinity> ne78: And, sure, the APIs have always been crazy.  PHP is a hobbyist language, IMO, and should never be used for "big apps", but oh well.  It's happened.
[03:33] <ne78> infinity: i heard the same thing about the IBM PC in 1981
[03:33] <infinity> ne78: But distributing an app that doesn't run on, say, RHEL3, Dapper, Sarge, etc, etc, just because you don't like the old API is a bit pointless too.
[03:34] <infinity> ne78: And it's still true of the IBM PC.  Shame that it won. :)
[03:35] <infinity> ne78: Anyhow, PDO's on my TODO, I'll poke at what dexter's doing and cobble something together.
[03:35] <ne78> infinity: that would be great
[03:35] <ne78> infinity: thanks for the attention
[03:35] <infinity> ne78: It also means rethinking and redesigning the Debian/Ubuntu PHP config system a bit to not explode with insanity with a mess of new modules.
[03:35] <infinity> ne78: Which is also on my TODO.
[03:36] <ne78> infinity: is it a mess atm ?
[03:36] <infinity> ne78: It's pretty sketchy and broken right now anyway.  It will just get uglier if I have to ship twice as many module packages, and I'd rather not.
[03:36] <infinity> ne78: I'd rather have mysql/mysqli/mysql_pdo all in one package, for example, and have a sane config system that deals with that.
[03:37] <infinity> ne78: (Which is already planned, just not written)
[03:37] <ne78> infinity: oh yes it would be simpler
[04:07] <bddebian> Howdy
[04:13] <Burgundavia> robertj: that would be the country
[04:18] <robertj> Burgundavia: so is Thailand considering getting software from Canonical for OLPC?
[04:18] <Burgundavia> robertj: I honestly have no idea
[04:19] <Burgundavia> robertj: thailand is one of the countries getting stuff. And technically, it would be Edubuntu, not Canonical
[04:20] <robertj> btw, has there been any talk about pairing down system tray icons & such? Rhythmbox, Ekiga, & Tomboy all need to keep their hands off my tray by default :)
[04:20] <Burgundavia> robertj: if you have a better suggestion, please raise it upstream
[04:20] <slomo> robertj: for tomboy you could use the panel applet instead
[04:21] <bddebian> Heya Burgundavia, slomo
[04:21] <Burgundavia> hey bddebian
[04:21] <slomo> hi bddebian :)
[04:28] <robertj> slomo: I think its more a desktop integration issue, because the panel applets really don't do alot
[04:29] <robertj> slomo: they are great if you use it all the time, if not though, they just take up space
[04:29] <slomo> isn't tomboy something you would want to use all the time or never?
[04:30] <robertj> slomo: maybe, but it's being positioned as a stickynotes fill-in
[04:32] <robertj> slomo: and more to the point, running the application sometimes doesn't open any doucments, it just puts the icon there
[04:32] <robertj> and mom is very confused by that behvavior
[04:55] <bddebian> Burgundavia: You still around?
[05:25] <Kaleo|work> hello rodarvus 
[05:26] <rodarvus> hello Kaleo|work 
[05:26] <Kaleo|work> rodarvus: I posted a comment about the intel driver
[05:26] <rodarvus> (leaving in a few minutes, though)
[05:27] <Kaleo|work> on bug 54858
[05:27] <Ubugtu> Malone bug 54858 in xserver-xorg-video-i810 "3d acceleration broken in Edgy Knot 1" [Medium,Needs info]  https://launchpad.net/bugs/54858
[05:27] <ajmitch> Kaleo|work: having issues with it?
[05:27] <Kaleo|work> yes ajmitch 
[05:27] <Kaleo|work> :)
[05:27] <ajmitch> since it's a different issue now for me
[05:27] <Kaleo|work> rodarvus: it might interest you :)
[05:27] <Kaleo|work> ajmitch: what is it ?
[05:27] <ajmitch> that the DRI driver is not initialising properly, even though it loads
[05:28] <ajmitch> I haven't traced much further than that in the code
[05:28] <ajmitch> pretty much just what you have in the comment
[05:28] <Kaleo|work> ah
[05:28] <Kaleo|work> :)
[05:28] <Kaleo|work> the syncing is in good progress
[05:29] <Kaleo|work> need some polishing...
[05:29] <Kaleo|work> thanks to rodarvus we're getting there !
[05:29] <ajmitch> yep
[05:30] <Kaleo|work> I had some hard time keeping track of the changes because of all these different packages
[05:30] <rodarvus> all in all AIGLX is not really meant to be a supported configuration for X, but I'll try updating Mesa one more time (since it might also make sense for other reasons)
[05:30] <ajmitch> I don't know if patching the expected version is the best option though
[05:30] <rodarvus> (... a supported configuration for X ... on Edgy I mean
[05:30] <Kaleo|work> rodarvus: the DRI does not work, not just AIGLX
[05:31] <Burgundavia> bddebian: am now
[05:31] <bddebian> Burgundavia: You are on the Games team?
[05:32] <Burgundavia> bddebian: as much as a non-MOTU can be, es
[05:32] <Burgundavia> yes
[05:32] <bddebian> You are not an MOTU?
[05:32] <Burgundavia> nope
[05:32] <rodarvus> Kaleo|work: note that it might not even be fault of X. there is a missing point on the "new intel driver" equatation (agpgart module)
[05:33] <bddebian> Burgundavia: Holy crap, I didn't know that
[05:34] <Burgundavia> bddebian: ask your question anyway
[05:34] <Kaleo|work> rodarvus: I just compiled mesa with the sources of the 10th of august
[05:34] <Kaleo|work> +have
[05:34] <Kaleo|work> rodarvus: and it seems to work flawlessly
[05:34] <Kaleo|work> (talking about DRI here)
[05:34] <rodarvus> fixes dri, you mean?
[05:34] <rodarvus> nice.
[05:35] <Kaleo|work> wouch, productive night
[05:35] <ajmitch> Kaleo|work: good work
[05:37] <bddebian> Burgundavia: I was just wondering if someone "leads" that team? :-)
[05:37] <Burgundavia> bddebian: not really. Siretart mostly
[05:37] <bddebian> Hmm, OK
[05:40] <Burgundavia> bddebian: I have not put a concerted effort into games stuff for a wile
[05:45] <bddebian> Burgundavia: Well I have been trying but man, it's ugly out there for decent games :-(
[05:46] <Burgundavia> bddebian: there are some good ones, sadly most of them have serious license issues
[05:46] <Burgundavia> I just had to talk the artists for Galaxy mage out of using CC-nc for their art
[05:50] <bddebian> I had issues with the scourge data files too :-(
[05:51] <Burgundavia> scourge is seriously messed
[05:51] <Burgundavia> somebody needs to thwack them
[05:51] <bddebian> In what way?  You mean the licensing for the data?
[05:52] <Burgundavia> yep
[05:52] <Burgundavia> they have "borrowed" stuff from other people
[05:52] <bddebian> Aye, I e-mailed them :-(
[05:52] <Burgundavia> what did they say?
[05:53] <bddebian> http://pastebin.us/3044
[05:54] <Burgundavia> ok, at least they are considering it
[05:56] <Burgundavia> bddebian: openttd is probably 6 months away from being shippable
[05:59] <bddebian> Well I was just looking for something to sink my teeth into but I suppose that's a lost cause as usual :-(
[06:00] <Burgundavia> bddebian: looking for games to package?
[06:00] <Burgundavia> bddebian: I would start with the pyweek stuff
[06:01] <bddebian> pyweek?
[06:01] <Burgundavia> http://pyweek.org/
[06:03] <bddebian> Uhm
[06:19] <pitti> Good morning
[06:23] <Burgundavia> morning pitti
[06:24] <bddebian> Morning pitt
[06:24] <bddebian> +i
[06:42] <bddebian> Gnight folks
[06:59] <pitti> lifeless: I'm currently updating edgy's bzr to 0.9; do you know about test suite failures in test_external_diff_binary? ('external diff failed with exit code 2')
[07:00] <pitti> lifeless: this happens in both rc1 and the final 0.9
[07:03] <lifeless> there should be no test failures
[07:04] <lifeless> it builds on PQM which is a dapper box, and that rejects the commit if there are test failures
[07:04] <Burgundavia> "there are no test failures"
[07:04] <lifeless> pitti: are you using dato's package from debian ?
[07:04] <pitti> lifeless: yes, I used 0.9~rc1 and updated to the final
[07:04] <pitti> lifeless: i. e. the rc1 that's currently in sid
[07:05] <lifeless> ok. FWIW dato has uploaded 0.9 final himself
[07:05] <pitti> lifeless: the only Debian patch is a documentation typo fix
[07:05] <pitti> lifeless: oh, uploaded where?
[07:05] <lifeless> well, to sid
[07:31] <Hobbsee> how are you doing, pitti?
[07:31] <pitti> pretty fine, and you?
[07:31] <Hobbsee> i have an assignment due in 49 hours :(
[07:32] <Hobbsee> i found out about it about 2 hours ago.
[07:32] <pitti> ouch
[07:33] <pitti> Hobbsee: have a productive night shift then
[07:33] <jdub> :-)
[07:33] <jdub> hey pitti 
[07:33] <pitti> jdub: hey Jeff!
[07:34] <jdub> pitti: so i've tested a backport of edgy trac on dapper - working pretty good
[07:34] <Hobbsee> pitti: no, i have to got to work tonight.  :(
[07:34] <Hobbsee> hi jdub 
[07:34] <jdub> pitti: can i do anything else to encourage a security release of it? :)
[07:34] <jdub> hey Hobbsee 
[07:35] <pitti> jdub: I'm not sure whether we can do official backports ATM (I think we can't)
[07:35] <Hobbsee> i havent heard that we can
[07:35] <pitti> jdub: well, 0.9.6-0ubuntu0.1 would work for me, too, if mdz approves the new upstream version
[07:35] <jdub> pitti: this would be an upstream bumped security release
[07:35] <jdub> ok, so it needs mdz love
[07:35] <pitti> jdub: well, you can :) sending mdz a changelog and asking for approval would be enough encouraging :)
[07:35] <jdub> ok!
[07:35] <pitti> jdub: I can do the actual update myself then
[07:37] <jdub> pitti: best to mail you and mdz, or is there a bug alias i should use?
[07:37] <pitti> jdub: just use security@ubuntu.com
[07:37] <jdub> ok
[07:37] <jdub> thanks
[07:40] <infinity> Does anyone know what Gauvain Pocentek's nick is?
[07:41] <Burgundavia> infinity: he ans seb128 are talking about it
[07:41] <pitti> infinity: Gloubibolka or something like this (I'm sure you saw it before)
[07:41] <infinity> pitti: Ahh, yeah.  Him.  He doesn't seem to be around.
[07:41] <infinity> Burgundavia: "Talking about it" in the "seb's trying to make him revert it, so I should just hold off" sense?
[07:42] <Burgundavia> infinity: there is a thread on -devel about it
[07:42] <Burgundavia> just a sec
[07:42] <Burgundavia> infinity: https://lists.ubuntu.com/archives/ubuntu-devel/2006-August/019957.html
[07:43] <infinity> Hrm, that's pretty inconclusive.
[07:47] <pitti> lifeless: ah, the test failure happens with de_DE.UTF-8, but not with C; I'll file a bug
[07:54] <lifeless> pitti: are you running 'make check' during the pacakge build ?
[07:54] <lifeless> pitti: or 'bzr selftest' ?
[07:54] <pitti> lifeless: the former
[07:54] <lifeless> ok, good.
[07:55] <pitti> lifeless: bug 56307, in case you want to add something
[07:55] <Ubugtu> Malone bug 56307 in bzr "bzrlib.tests.test_diff.TestDiff failure in German locale" [Untriaged,Unconfirmed]  https://launchpad.net/bugs/56307
[08:05] <pitti> infinity: any idea why krb5_1.3.6-1ubuntu0.2_source.changes (hoary-security) is not attempted to be built?
[08:05] <infinity> pitti: Looking...
[08:07] <infinity>   Package             : krb5
[08:07] <infinity>   Version             : 1.3.6-4ubuntu0.1
[08:07] <infinity>   Builder             : buildd+terranova
[08:07] <infinity>   State               : Installed
[08:08] <pitti>       krb5 | 1.3.6-1ubuntu0.1 | http://security.ubuntu.com hoary-security/main Sources
[08:08] <pitti> ^ this is currently in the archive
[08:09] <infinity> Yeah, dude.  You uploaded the breezy-security update to hoary-security.
[08:09] <infinity>  krb5 (1.3.6-4ubuntu0.1) hoary-security; urgency=low
[08:09] <lifeless> whoops
[08:09] <pitti> infinity: argh
[08:10] <infinity> pitti: You can either try to get elmo to UNACCEPT all of those, or you get to fudge version numbers to fix it.
[08:11] <infinity> elmo: Alive?  pitti needs some UNACCEPT love on jackass. :/
[08:11] <pitti> infinity: I'll email him
[08:12] <infinity> pitti: Check.  Make sure to be very specific about which ones need UNACCEPTing, to avoid back and forth. :)
[08:12] <pitti> infinity: I can leave the right hoary one as it is, I assume?
[08:12] <infinity> pitti: krb5_1.3.6-4ubuntu0.1*changes should do it, I guess.
[08:13] <infinity> pitti: Yeah, if you leave the correct hoary one in place, I can fix wanna-build manually after elmo unaccepts the others.
[08:14] <pitti> thanks
[08:14] <pitti> infinity: ah, there is Gloubiboulga
[08:15] <infinity> Err, wait.  Hrm.
[08:15] <infinity> cron.daily no longer runs on jackass, which makes manually fixing wanna-build problematic...
[08:15] <infinity> Well, I can sort that with elmo after the unaccept happens.
[08:16] <jdub> pitti: YAY BZR 0.9!11
[08:18] <pitti> jdub: \o/ the speed improvements were too tempting :)
[08:20] <Gloubiboulga> pitti, infinity, hello, do you need me for something?
[08:23] <pitti> Gloubiboulga: hello; Adam asked for your nick :)
[08:24] <Gloubiboulga> ok :)
[09:26] <pitti> mjg59, Kamion: can you please approve my u-d-a post?
[09:44] <doko> pitti: ping
[09:44] <pitti> doko: Guten Morgen
[09:46] <infinity> Gloubiboulga: *poke*
[10:00] <pitti> hey mvo!
[10:00] <pitti> http://librarian.launchpad.net/3893988/buildlog_ubuntu-edgy-i386.bzr_0.9-0ubuntu1_FAILEDTOBUILD.txt.gz *gulp*
[10:00] <imbrandon> ouch
[10:01] <pitti> lifeless: ^ lots of test suite failures, didn't happen to me locally
[10:01] <infinity> mvo: Hey dude.  What's the story with Gloubiboulga's gksu/nautilus-gksu split?  Have we decided this is definitely the Right Thing to do (ie: should I process the binaries from queue/new), or is this still a point of contention?
[10:01] <seb128> hey pitti
[10:02] <infinity> pitti: Looks like they're all "None" versus "0" breakage..
[10:02] <infinity> pitti: Do you have the latest and greatest python installed, to make sure it's the same as the chroot?
[10:03] <pitti> infinity: yes, fresh after today's dist-upgrade (which only pulled in a new totem)
[10:03] <pitti> infinity: however, the ENOFILE errors might be the cause
[10:03] <mvo> hey pitti, seb128!
[10:03] <seb128> hi mvo
[10:04] <infinity> pitti: Ahh, didn't catch that.
[10:04] <mvo> infinity: the new gksu has a nautilus plugin that makes the package unsuitable for xubuntu, thats why the split
[10:04] <lifeless> bte you TZ=UTC
[10:04] <lifeless> theres a bug open and a fix for it
[10:04] <pitti> oh, cool
[10:04] <infinity> mvo: Right, but the split's okay by you, then?  And doesn't require any migration plan, because that bit's new anyway?
[10:05] <mvo> infinity: yes, nautilus-gksu is new anyway. I looked over the diff and it looks ok
[10:05] <infinity> mvo: Great.  I'll process it, then.  Thanks.
[10:05] <seb128> mvo: using a Recommends or Suggests nautilus without splitting would be possible too no?
[10:05] <infinity> mvo: Err, will it be ending up in ubuntu-desktop (and thus in main), or should I shove it in universe?
[10:06] <infinity> mvo: (And if the former, can you update the seeds?)
[10:06] <infinity> seb128: No, it links to the whole GNOME stack.
[10:07] <seb128> infinity: right, but that doesn't mean we need a Depends ;)
[10:07] <infinity> seb128: Unless you're suggesting not having proper shlibdeps (eek), it needs to be split.
[10:07] <seb128> infinity: yeah, that's what I suggested, we do it for some other packages already
[10:07] <infinity> seb128: IMO, if you ever have to override shlibdeps, you know you're doing something wrong.
[10:07] <seb128> infinity: you can exclude that .so for the shlibs call
[10:07] <mvo> seb128: do we want it in main? 
[10:08] <seb128> infinity: not really, I'm fine with having a nautilus file installed but not used if nautilus is not installed :)
[10:09] <seb128> mvo: main, probably yes, it makes no sense to have a some binary from a main src package to universe, desktop I'm not sure, I think it clutters the context menu
[10:09] <infinity> seb128: Yeah, but if it links to stuff that the rest of the package doesn't, library dependency breakage can occur.
[10:09] <infinity> seb128: The whole point of versioned shlibs is a bit lost if you have binaries that don't declare proper dependencies.
[10:09] <seb128> the point is to the have things working
[10:10] <seb128> having a feature working if nautilus is installed and doing nothing otherwise is sort of working ;)
[10:10] <seb128> anyway I'm fine with the split, my comment on the list is just that I would prefer to have that discussed with the Debian maintainer (who is upstream too) before being done
[10:11] <mvo> seb128: agreed
[10:11] <mvo> seb128: I will mail him
[10:11] <infinity> mvo: If main-but-not-desktop is agreed upon, please update the seeds to put it in supported, and I'll toss it in main.
[10:11] <seb128> mvo: the guy who did the split opened a bug on the BTS with the patch after I asked him to do that :)
[10:12] <mvo> seb128: what bug number?
[10:13] <infinity> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382655
[10:13] <Ubugtu> Debian bug 382655 in gksu "gksu brings the GNOME libs as dependencies" [Unknown,Open]  
[10:13] <seb128> mvo: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382655
[10:13] <seb128> damn, too slow :p
[10:13] <infinity> Hah, I win.
[10:13] <mvo> :)
[10:13] <infinity> At least Ubugtu appears to be smart enough to not be repetitive.  Cute.
[10:14] <seb128> mvo: BTW the package should probably Depends on nautilus too
[10:15] <seb128> infinity: main
[10:15] <mvo> infinity: "main"
[10:15] <infinity> Check.
[10:15] <seb128> supported but not desktop
[10:15] <mvo> *nod*
[10:15] <Gloubiboulga> /me apologize for the gksu thing
[10:15] <mvo> infinity: happy now :) ?
[10:15] <Gloubiboulga> hi mvo, seb128 
[10:15] <mvo> hi Gloubiboulga
[10:15] <infinity> mvo: I'll be happy when you fix the seeds. :P
[10:15] <seb128> Hi Gloubiboulga
[10:15] <infinity> mvo: Anyhow, binaries accepted.
[10:16] <mvo> hi Gloubiboulga, nothing to be sorry about. thanks for taking care for this
[10:16] <mvo> infinity: thanks
[10:16] <seb128> Gloubiboulga: np, just pinging the desktop team before changing something from GNOME is a good idea usually ;) And opening a Debian bug too :p
[10:17] <Gloubiboulga> seb128, agreed :)
[10:24] <pitti> lifeless: okay, I found the suggested patch on the ML and applied it to the package; seems to work fine
[10:25] <pitti> lifeless: thanks for checking
[10:25] <lifeless> np
[10:25] <lifeless> hth
[10:25] <pitti> (it's not yet applied upstream)
[10:34] <mvo> infinity: seed updated too
[10:53] <mantiena> Hi all
[10:54] <mantiena> doko: hi, are you alive ?
[10:56] <pitti> infinity: do you plan to update edgy/sid mysql to 5.0.24? .24 fixes CVE-2006-4031
[11:15] <ogra> pitti, ping
[11:19] <mantiena> doko: hi, are you alive ?
[11:19] <mantiena> doko_: I wanna ask few questions about OpenOffice.org, wich is in dapper-proposed
[11:21] <doko_> there it is.
[11:28] <mantiena> doko: are there any important reasons (e.g. important bugs) why OOo 2.0.3-4dapper2 isn't in dapper-updates or backports ?
[11:29] <mantiena> doko: I just wonder if I can try to use this version on workstations in my office
[11:29] <doko> mantiena: see the filter bug reports
[11:29] <raphink> hi
[11:29] <raphink> I've got a problem with germinate
[11:30] <raphink> the update script in (k)(x)ubuntu-meta packages don't seem to be able to use Germinate.py
[11:30] <raphink> ImportError: No module named Germinate
[11:30] <raphink> although I have installed the germinate package
[11:31] <raphink> (or Germinate.pm maybe)
[11:32] <raphink> germinate.py is present in /usr/lib/germinate/germinate.py though
[11:33] <pitti> ogra: pong
[11:34] <ogra> pitti, how hard would it be to add a --bind option to pmount 
[11:34] <mantiena> doko: filter by wich criteria ?
[11:34] <ogra> (even with a hardcoded dir if you want for secutity reasons)
[11:34] <mantiena> s/wich/which
[11:35] <ogra> s/dir/sourcedir/
[11:35] <pitti> ogra: not that hard code-wise; but it needs to be restricted 
[11:35] <ogra> indeed
[11:35] <pitti> ogra: what should it do?
[11:36] <ogra> pitti, ltspfs mounts in /tmp/.$UID/device now ...
[11:36] <ogra> pitti, to get that on the users desktop i have two options:
[11:36] <ogra> a) put a link on the desktop and make ugly changes to ~/.gtk-bookmarks etc
[11:37] <ogra> b) mount --bind  /tmp/.$UID/device /media/$IP/device 
[11:37] <pitti> ogra: why not have ltspfs mount it to /media/device?
[11:37] <ogra> b makes everything work fine ...
[11:37] <ogra> the prob is that i need root rights to exec mount :)
[11:38] <ogra> thats why i think pmount is the right place
[11:38] <pitti> ogra: so, why can ltspfs mount to /tmp, but not to /media?
[11:38] <ogra> my prob is that ltspfs operates in userscpace
[11:38] <pitti> ah, fuse?
[11:38] <ogra> yep
[11:38] <ogra> nodev 
[11:39] <ogra> so i need a mount proggy that drops privileges but issues mount as root
[11:39] <ogra> aka pmount :)
[11:39] <pitti> it feels a bit like abuse
[11:40] <ogra> hmm
[11:40] <pitti> ogra: so actually the problem is just the displaying on desktop?
[11:41] <pitti> ogra: so actually the problem is just the displaying on desktop?
[11:41] <ogra> grr
[11:41] <ogra> *really
[11:42] <ogra> pitti, well, no
[11:44] <ogra> pitti, its also having the device in the bookmarks list and havong the right icon
[11:45] <ogra> argh i'm going mad here 
 pitti, its also having the device in the bookmarks list and havong the right icon
 and being able to access it from openoffice
[11:46] <pitti> ogra: and gnome-vfs does not show stuff in /tmp?
[11:46] <ogra> the ltspfs mount cares for the /tmp dir not being accessible by anyone apart from the user who mounted
[11:46] <pitti> ogra: it seems related to bug 50554
[11:46] <Ubugtu> Malone bug 50554 in gnome-vfs "removable devices should only show up on the desktop of the user who can access them" [High,In progress]  https://launchpad.net/bugs/50554
[11:46] <ogra> well, i'd like to be able to use the exisiting infrastructure
[11:46] <pitti> ogra: i. e. gnome-vfs could also display mounts in !/media
[11:47] <ogra> and g-v-m only picks up real mounts from /media
[11:47] <pitti> g-v-m?
[11:47] <ogra> isnt g-v-m responsible here ? 
[11:47] <ogra> oh, ok
[11:47] <pitti> ogra: g-v-m doesn't display anything, it just mounts
[11:47] <pitti> ogra: i. e. the icons you see on the desktop, panel, etc. are gnome-vfs' responsibility
[11:47] <ogra> ah
[11:48] <pitti> ogra: would it be possible to mount the stuff into the user's ~?
[11:48] <ogra> is theer a config i can tweak to make it pick up /tmp/.$UID/ ?
[11:48] <pitti> well, /tmp/$UID is fine, of course
[11:48] <ogra> if i mount in ~ several people in here will slay me :)
[11:48] <pitti> ogra: I think so, should be configurable with hal FDIs
[11:48] <pitti> ogra: let me play with that a little
[11:49] <pitti> ogra: give me 5 minutes to start off that edgy powerpc install, then I'll look into it
[11:49] <ogra> pitti, wow, cool, thanks for that
[11:49] <pitti> arrgh
[11:50] <pitti> ppc/live's ubiquity immediately dies and the alternate CD does not have kernel modules
[11:50] <ogra> ??
[11:50] <ogra> ouch
[11:50] <pitti> ok, no edgy install today either
[11:54] <pitti> ogra: does that look right for your use case?
[11:54] <pitti> mkdir -p -m 700 /tmp/.1000/cdrom
[11:54] <pitti> sudo mount -o loop,uid=1000,gid=1000 -t iso9660 download/ubuntu/edgy-alternate-powerpc.iso /tmp/.1000/cdrom/
[11:54] <ogra> pitti, how will that work with non gnome desktops btw ? 
[11:54] <ogra> yep
[11:54] <ogra> apart from me not using a privileged user 
[11:55] <pitti> well, structure-wise
[11:55] <pitti> ogra: I cannot answer that for 'non-gnome'; every desktop will have its own method (and things like fvwm don't care about that at all)
[11:56] <ogra> no, but we'll likely ship xfce additionally
[11:56] <ogra> and many users want to use it with kubuntu
[11:58] <ogra> neither uses g-vfs, but all check /media
[11:59] <ogra> pitti, 
 no, but we'll likely ship xfce additionally
 and many users want to use it with kubuntu
 neither uses g-vfs, but all check /media
[12:00] <pitti> I saw that
[12:00] <ogra> ok
[12:00] <ogra> my wlan dies every 2 mis here :(
[12:00] <pitti> ogra: the AE again?
[12:00] <ogra> AE ?
[12:00] <pitti> airport express
[12:00] <ogra> no, another linksys card
[12:01] <ogra> but i usually have no probs with it
[12:01] <ogra> no idea why it dies today :/
[12:02] <pitti> ogra: are these loopback mounts?
[12:03] <pitti> ogra: and, btw, HAL FDIs don't work here :/
[12:03] <pitti>         if (mount->is_loopback ||
[12:03] <pitti>             !(mount->is_user_mountable ||
[12:03] <pitti>               g_str_has_prefix (mount->device_path, "/vol/"))) {
[12:03] <pitti>                 return NULL;
[12:04] <pitti> ^ oh, that's just for the drive, but we want only the volume
[12:05] <pitti> ogra: ok, I located the spot in gnome-vfs which we'll need to patch for this, if we go that route
[12:07] <raphink> ogra: do you have any idea about my germinate issue?
[12:07] <pitti> ogra: ok, I located the spot in gnome-vfs which we'll need to patch for this, if we go that route
[12:11] <ogra> does xfce use gnome-vfs ? 
[12:12] <Gloubiboulga> ogra, xfce doesn't use gnome-vfs
[12:13] <ogra> hmm
[12:44] <StevenK> doko: Do you have any plans of updating python-support in edgy?
[12:44] <doko> StevenK: yes, will need to sync these
[12:45] <StevenK> doko: Excellent, then I can just sync.
[12:45] <doko> StevenK: please wait until these tools are synced
[12:45] <StevenK> doko: Certainly, I wasn't planning on otherwise.
[12:51] <rodarvus> infinity, builds of xorg-server and xserver-xorg-video-i810 failed on powerpc, due to the archive issues of last Friday - these issues appear to be fixed now
[12:51] <rodarvus> could you please retry the build of those two packages on powerpc for me?
[01:09] <iwj> Urgh, my speling is awful today.
[01:17] <pitti> rodarvus: enjoy bzr 0.9 in edgy :)
[01:17] <ogra> grr
[01:17] <ogra> why did they have to call the directory /media
[01:17] <Treenaks> ogra: why not?
[01:18] <ogra> its impossible to find something at google if you search for "gnome-vfs media"
[01:18] <ogra> because it will always refer to the media, not to the dir
[01:18] <rodarvus> pitti, thanks! :)
[01:18] <HiddenWolf> gnome-vfs /media ?
[01:18] <Treenaks> HiddenWolf: google strips non-word chars
[01:18] <ogra> HiddenWolf, same 
[01:19] <rodarvus> all of us will enjoy bzr 0.9 in edgy ;
[01:19] <rodarvus> ;)
[01:19] <ogra> even with quoting etc
[01:20] <iwj> Wow, my X server is doing opaque move in software.
[01:20] <ogra> but i still think we wont get around abusing pmount or writing something equivalent ... if it doesnt work with KDE and XFCE we cant make it an upstream feature, which we must
[01:20] <HiddenWolf> Treenaks: hm, never had any trouble with that.
[01:21] <ogra> HiddenWolf, find me a page then that explains how gnome-vfs uses media and why it does that, there is no trace for a /media in the source
[01:21] <ogra> :)
[01:21] <Riddell> ogra: what's this?
[01:22] <ogra> Riddell, ltspfs
[01:22] <ogra> local devices mounted on your desktop from thin clients
[01:22] <rodarvus> ogra, "gnome-vfs \/media" doesn't works?
[01:22] <ogra> rodarvus, no
[01:22] <Treenaks> rodarvus: I want 0.9 in dapper ;)
[01:22] <rodarvus> Treenaks, ask for a backport ;)
[01:23] <HiddenWolf> ogra: http://developer.gnome.org/doc/guides/platform-overview/platform-overview.html#gnome-vfs guess you'd start there
[01:23] <iwj> ogra: /media is set up by the installer I think.
[01:23] <ogra> Riddell, pitti just wants to modify gnome-vfs to look in /tmp/.$UID (where we do the network mount from the client) but that would exclude KDE and XFCE 
[01:23] <iwj> At least, some of it.
[01:23] <rodarvus> Treenaks, pitti might be able to tell you how hard the package upgrade from 0.8 to 0.9 was, but I guess this is pretty straightforward stuff
[01:23] <ogra> iwj, i want to know how gnome-vfs knows that it should monitor /media 
[01:24] <pitti> ogra, Riddell: I'm happy to further discuss a lower-level solution
[01:24] <pitti> Treenaks: sure, it's data compatible and all that
[01:24] <Treenaks> pitti: ok, cool
[01:25] <ogra> there must be something in the source telling it to do that and i seem not to be able to find it
[01:25] <ogra> HiddenWolf, and that you found via google ? 
[01:27] <HiddenWolf> ogra: pretty much
[01:29] <HiddenWolf> ogra: I pretty much just pasted your question into google. ie: how gnome-vfs uses media. This document is the 5th hit and links to the fd.o spec and the gnome-vfs api docs
[01:30] <ogra> which doesnt help all, i already looked there 
[01:30] <ogra> but thanks for the effort 
[01:30] <HiddenWolf> ogra: can't you ask the maintainer?
[01:31] <ogra> sure, but i dont want to take to much of pittis time and i need to understad the process myself ...
[01:33] <HiddenWolf> ogra: your call, but I guess that asking for a pointer would save you more time that it would cost him. :)
[01:33] <HiddenWolf> Anyway, I have to run, best of luck.
[01:36] <cbx33> ping mjg59 
[01:40] <infinity> pitti: Yeah, should happen.
[02:25] <pygi> sivang, poke?
[02:26] <zul> hey
[02:30] <TheMuso> c
[02:30] <TheMuso> wc
[02:33] <pygi> heno, hey, how is your student doing?
[02:41] <mantiena> doko: Does bug #55874 exist in latest dapper packages from proposed-updates (OOo 2.0.3-4dapper2)  ?
[02:41] <Ubugtu> Malone bug 55874 in openoffice.org "upgrading dapper -> fails as 'ooqstart' is in '-core' and '-gtk'" [Untriaged,Unconfirmed]  https://launchpad.net/bugs/55874
[02:42] <doko> mantiena: yes
[02:45] <mantiena> doko: so, why it's unconfirmed ?
[02:45] <mantiena> ;)
[04:02] <sbalneav> pitti: Ping
[04:02] <pitti> sbalneav: pong
[04:02] <sbalneav> hey pitti, got time for a quick pmount request/discussion?
[04:03] <pitti> sbalneav: about ltspfs mounting? ogra already asked me about this this morning, but go ahead
[04:03] <sbalneav> Ogra's having internet trouble today.  I guess there's 2 problems with a vfs patch:
[04:03] <sbalneav> 1) doesn't fix it for kde/xfce
[04:04] <pitti> right
[04:04] <sbalneav> 2) user can't easily do a file->open in OO.o, and then has to rummage trough /tmp
[04:04] <mantiena> doko: btw, what couses bug #55874 ? it seems debian/rules is ok - it moves qstarter binary to ooo-core package
[04:04] <Ubugtu> Malone bug 55874 in openoffice.org "upgrading dapper -> fails as 'ooqstart' is in '-core' and '-gtk'" [Untriaged,Unconfirmed]  https://launchpad.net/bugs/55874
[04:05] <sbalneav> so a pmount --bind to get us into the /media tree would be preferred.
[04:05] <ogra> sbalneav, we should give pitti a little background info ;) ltsp will merge with our code in edgy+1, so we need to make our stuff upstream compatible ...
[04:05] <pitti> sbalneav: TBH, I'm not a fan of adding random unrelated functionality to pmount, like bind-mounts
[04:05] <ogra> i.e. have a generic solution thats not bound to a DE
[04:05] <sbalneav> oh, sorry, tought you may have done that already.
[04:05] <pitti> sbalneav: however, I do see that using /media is the way to go
[04:06] <sbalneav> Is that a yes, then? :D
[04:06] <pitti> sbalneav: thus, using a setuid wrapper seems to be appropriate, if no appropriate daemon is available
[04:06] <ogra> thats a no to pmount changes :)
[04:06] <zul> does anyone know why the builds are complaining that a dbg package doesnt exist when it should not exist in the first place?
[04:06] <ogra> but a yes to a limited pount clone :=
[04:06] <pitti> sbalneav: however, I would be much happier with a well-defined and small new suid wrapper
[04:06] <ogra> :)
[04:06] <ogra> *pmount
[04:07] <pitti> sbalneav: does it have to be a bind mount, or is a symlink actually enough?
[04:07] <ogra> nope
[04:07] <ogra> symlinks dont work, tried that already
[04:07] <pitti> sbalneav: and why not mount the volumes straight under /media rather than /tmp?
[04:07] <ogra> probably if we add weird virtual hal devices 
[04:07] <ogra> but with a 100 user setup that will make hal crazy i guess
[04:08] <ogra> pitti, because the user has no write access in /mount
[04:08] <ogra> and the mounter runs as user ... not as root
[04:08] <sbalneav> ogra: is a setuid wrapper something we could do?  I could handle it.
[04:08] <ogra> its 100% userspace ... from the filesystem up to the rest ...
[04:08] <pitti> ogra: I mean, if you mount to /tmp because you cannot access /media and then invent a hack to bind /media to /tmp, why not use a cleaner solution to mount straight into /media?
[04:09] <ogra> sbalneav, just take pmount, rip out all normal mount functionallity and et it only do bind mountig
[04:09] <ogra> pitti, indeed
[04:09] <pitti> sbalneav: well, pmount has a *lot* of stuff that's not required for the thing you want to do
[04:09] <ogra> if we need a suid wrapper anyway
[04:10] <ogra> sbalneav, also lets use the surce directory as hardcoded value, that minimizes possible security probs
[04:10] <pitti> sbalneav, ogra: from what I see, the wrapper should just do an mkdir /media/foo, right?
[04:11] <sbalneav> pitti: correct. The mount would happen as the user.
[04:11] <pitti> once the directory exists, you can fuse-mount it just as /tmp/$uid
[04:11] <ogra> no
[04:11] <pitti> sbalneav: so, a small ltsp-related mkdir /media/foo suid wrapper seems safe, contained, and appropriate
[04:11] <ogra> you still need to bind mount ithe dirs
[04:11] <pitti> ogra: why?
[04:11] <ogra> its more tan mkdir
[04:11] <pitti> ogra: bind mount sounds just evil; why do you need it? 
[04:11] <ogra> because the vfs'es wont pick it up as device if its not bind mounted
[04:12] <pitti> ugh?
[04:12] <pitti> well, that's something new :)
[04:12] <ogra> ltspfs isnt seen as device 
[04:12] <ogra> no, i told you this morning that we will need the bind mount :)
[04:12] <pitti> I'd call that a bug in the VFSes
[04:12] <ogra> and that there is no device
[04:12] <pitti> ogra: yep, I assumed it was just for mirroring /tmp to /media
[04:13] <ogra> no :)
[04:13] <pitti> but anyway
[04:13] <pitti> then the suid wrapper needs to mkdir and mount -o bind, okd
[04:13] <pitti> s/d$//
[04:13] <ogra> yep :)
[04:13] <pitti> but that's still not much
[04:13] <ogra> indeed
[04:13] <sbalneav> ogra: ok, we can handle that.
[04:13] <pitti> sbalneav, ogra: I'm happy to audit the code
[04:13] <pitti> that is, if we agree to that solution
[04:14] <ogra> sure
[04:14] <ogra> i'll take everything that works and passes your eagle eyes :)
[04:14] <pitti> so, ltspfsmount and ltspfsumount? :)
[04:14] <sbalneav> pitti: You may audit our code on condition that you let me buy you a beer next conf :)
[04:14] <pitti> sbalneav: hard, but acceptable :-P
[04:15] <ogra> i'd say ltspfsmount {--add,--remove} ;)
[04:15] <Amaranth> that's not very mount-y
[04:15] <ogra> we dont need any mount-y code
[04:15] <sbalneav> ogra: yeah, I like that better.  only 1 suid script to worry about :)
[04:15] <ogra> its only used internally 
[04:15] <ogra> exactly
[04:16] <sbalneav> Mounties?  We have those in Canada.  Red tops, ride the horses, etc/
[04:16] <pitti> sbalneav: heh, I remember them from my trip through Canada :)
[04:16] <pitti> ogra? ogra? hey, where are you? 
[04:16] <pitti> :)
[04:16] <ogra> heh
[04:17] <ogra> i painted my office over the weekend ... probably the orange pugment shields wlans 
[04:17] <ogra> *pigment
[04:18] <sbalneav> you painted your office.... orange? :)
[04:18] <ogra> well, they call it terracotta :)
[04:18] <gnomefreak> with orange walls its gonna be hard to sleep in office ;)
[04:19] <ogra> feels a bit like working in a flowerpot :)
[04:19] <Hobbsee_> ogra: you've tried this, so that you can compare?
[04:19] <ogra> Hobbsee, sleeping in the office ? 
[04:19] <Amaranth> working in a flowerpot
[04:19] <Hobbsee> ogra: or working in a flowerpot.  either way.
[04:20] <ogra> well, i dont fit in any of the flowerpots around here :)
[04:20] <ogra> but i imagine it feels similar
[04:21] <Hobbsee> heh
[04:35] <iwj> Does anyone here know what a .chk file is ?
[04:36] <Treenaks> iwj: can't 'file' tell you?
[04:37] <Treenaks> iwj: (also, chk files are created by chkdisk in dos/windows, like files in lost+found by fsck)
[04:39] <iwj> Treenaks: No, file says `data'.  It's something the Mozilla build system has spewed out and seems to be something to do with libnss.
[04:39] <Treenaks> iwj: hm, maybe test data?
[04:40] <iwj> with modutil'
[04:40] <iwj> Hmm.  You may be right.
[04:40] <iwj> (FIPS 140 requires algorithm self-tests with specific test vectors.)
[04:40] <Treenaks> because the only other references I find are related to 'tomtom' GPS navigation devices
[04:41] <Treenaks> (and I don't think _they_ do FIPS 140 on the voice data...)
[04:43] <iwj> :-)
[04:44] <iwj> I think the reference to FIPS-140 is convincing to me, so that means I know I need to ship it in case some fool turns on the FIPS-140 mode.
[04:54] <ogra> iwj, .chk gets created from windows fsck usually
[04:55] <ogra> usually with a number code as name 
[04:56] <Seveas> ogra, but I find it hard to believe windows chkdsk messes with his firefox builds on Ubuntu ;)
[04:56] <Hobbsee> Sev
[04:56] <Hobbsee> Seveas: you never know :P
[04:58] <iwj> That's definitely not what it is :-).
[04:58] <ogra> Seveas, well, if he runs the windows build in a chrooted vmware setup or something :P
[04:58] <ogra> indeed they shouldnt exist in linux :)
[04:59] <Seveas> ogra, i find it hard to believe that iwj would run windows builds, given that the linux builds are annoying enough already ;)
[04:59] <ogra> indeed ;)
[04:59] <ogra> i wasnt serious 
[04:59] <ogra> but windows is the only place i ever saw .chk files 
[04:59] <Seveas> me neither -- serious mode is gone after trying to cash in a check from pearson today
[05:00] <Seveas> I finally made money with Ubuntu 
[05:03] <sbalneav> Seveas: Kanjii smiley.  Nice.
[05:09] <bmon> sbalneav: isn't that hirigana? (sp?)
[05:10] <iwj> seb128: Sorry about the ff nss breakage.  I think I have a fix and if we're lucky it might make it into the archive today.
[05:11] <zul> heh...thats funny firefox just crashed
[05:11] <BenC> anyone know when a fixed evo is going to be uploaded?
[05:11] <seb128> iwj: np, but could you not upload a new version on friday afternoon without giving a try to other apps concerned or pinging the corresponding maintainers next time? :)
[05:11] <BenC> sweet, iwj answers my question before I even typed it :)
[05:12] <seb128> iwj: the GNOME bug has around 60 dups by know, ie. many users who had no MUA since friday and extra work for upstream
[05:12] <pitti> iwj: since the new libnss or libnspr3 is not compatible with ffox 1.5, and ffox 2.0 does not work with the old library versions, does that warrant a soname bump?
[05:12] <geser> bmon: I think it's U+30C4 KATAKANA LETTER TU
[05:13] <pitti> iwj: or does your fix repair that abi compatiblity as well?
[05:14] <seb128> pitti: how is it not compatible? (just curious)
[05:14] <pitti> seb128: new libs + old ffox: ffox cannot use SSL
[05:14] <pitti> seb128: old libs + new ffox: ffox crashes (according to Keybuk)
[05:14] <seb128> pitti: are you sure that's not the same bug as the evolution one?
[05:14] <bmon> geser: looks like you're right, been too long :)
[05:14] <seb128> pitti: https://launchpad.net/distros/ubuntu/+source/evolution/+bug/56118
[05:14] <Ubugtu> Malone bug 56118 in evolution "Crashes on startup" [Unknown,Confirmed]  
[05:14] <pitti> seb128: might very well be the same incompatiblity
[05:15] <seb128> pitti: look the small example on that bug
[05:17] <seb128> iwj: BTW the totem plugin crasher is because the new firefox doesn't link to libxpcom.so
[05:21] <iwj> I don't know if this change fixes binary compatibility but I doubt it.
[05:21] <iwj> But I'll do some tests.
[05:21] <iwj> seb128: And yes, I'm sorry about making a mess.  I take your points.
[05:22] <seb128> iwj: ok, thank you for considering that next time ;)
[05:22] <iwj> Part of the problem is that there's a bit of libnss in the ff 2.0 beta firefox package.
[05:23] <cbx33> ping Keybuk 
[05:23] <BenC> cool, backing down to dapper's firefox lets me get email again :)
[05:24] <pitti> BenC: LD_LIBRARY_PATH=/usr/lib/firefox evolution
[05:24] <seb128> BenC: you can also use LD_LIBRARY_PATH=/usr/lib/firefox to start evolution
[05:25] <BenC> oh well, I'll stick with this for awhile, thanks though
[05:25] <iwj> Yes, you need that too.  I think it may be compatible the other way around without that.
[05:27] <iwj> seb128: BTW, your nssinit.c program has insecure use of /tmp and shouldn't be run on a multiuser machine ...
[05:28] <seb128> iwj: right, I picked some random path to give it a quick try on my box, I could have changed that before attaching to the bug
[05:29] <iwj> Yes, new ff seems to work with old libnspr so I think it's compatible (no matter what the dependencies say).
[05:29] <Keybuk> cbx33: 'sup?
[05:30] <cbx33> Hi Keybuk , I realise you'r super busy, is there any chance of getting gisomount moved off of NEW and into the universe
[05:30] <cbx33> I didn't realise I was sposed to ask someone once it got to NEW status
[05:31] <cbx33> ogra mentioned that it may be an idea to ask someone
[05:31] <ogra> well, after three weeks *i* would ask someone :)
[05:32] <cbx33> heh :p
[05:32] <Keybuk> cbx33: it'll processed in due course
[05:32] <Keybuk> NEW checking requires a particular mind set
[05:32] <Keybuk> not to mention some time
[05:33] <cbx33> Keybuk, I understand
[05:33] <Keybuk> is there any particular urgency for this?
[05:33] <cbx33> forgive my intrusion
[05:33] <cbx33> Keybuk, my first ubuntu package
[05:33] <cbx33> what can I say :p
[05:33] <cbx33> plus i think it would be useful for people at beta testing time
[05:33] <cbx33> other than that, no
[05:34] <cbx33> pardon my impatience ;) - ogra can vouch for that :p
[05:35] <Zdra> hi, I got a crash just after installing new crash report system... I see that the generated file is 6Mo ! that's far too much for poor upload connections I think.
[05:36] <pitti> Zdra: maybe I should add a button to remove the core dump, which will make it < 10 kB
[05:37] <pitti> Zdra: however, it's a very useful piece of information
[05:37] <cbx33> pitti, could it be optional?
[05:37] <Zdra> pitti: maybe just gzip it ?
[05:37] <cbx33> I was just gonna suggest that
[05:37] <pitti> Zdra: it's already bzip2'ed
[05:37] <mdz> Zdra: it's already compressed, naturally
[05:37] <Zdra> hm
[05:37] <cbx33> hehe, thought so
[05:37] <mdz> pitti: perhaps we should offer two options "send full report" and "send partial report"
[05:37] <pitti> cbx33: as I said, apport-gtk shows the file size, I could add a button to remove the dump
[05:38] <pitti> mdz: apport-gtk does not actually 'send' the report, it just asks to file a bug and attach the file
[05:38] <cbx33> mdz, sounds good, would it be an idea to say why?
[05:38] <cbx33> like slow/connection fast/connection
[05:38] <mdz> cbx33: "send full report (6 mb)" "send partial report (10 kb)"
[05:38] <cbx33> yeh sounds good
[05:39] <Zdra> great :)
[05:39] <pitti> mdz: I could create a temporary file with a reduced report and offer/display this as well
[05:40] <cbx33> hi pygi 
[05:41] <Sp4rKy> hi
[05:41] <Sp4rKy> please when start edgy translation ?
[05:42] <dmg> pitti: I assume the backtrace is already in the report?
[05:43] <seb128> Sp4rKy: ask to carlos on #launchpad
[05:43] <Sp4rKy> seb128, thx
[05:43] <seb128> np
[05:43] <Zdra> pitti: tar -cjf compress the file from 6M to 4M
[05:43] <pitti> dmg: yes, but only the one without debug symbols
[05:44] <pitti> Zdra: ok, worth considering
[05:44] <bddebian> Howdy
[05:47] <iwj> Bah, test build died right at the end.
[05:47] <dmg> pitti: so bzip2 pulls off another 2M.. I thought they were already compressed.  You're using gzip?
[05:48] <pitti> dmg: well, the core is bzip2'ed, but then base64-encoded, and the rest of the info is just plain ascii
[05:48] <dmg> ah, so there is some redundancy to be pulled out afterwards.
[05:48] <pitti> right
[05:50] <dmg> but if the resulting tar file has to be base64 encoded, it's just going to expand again.
[05:51] <pitti> dmg: it doesn't need to be a tar
[05:51] <pitti> dmg: the single file has all information
[05:51] <dmg> pitti: sorry, this was in refernece to zdra's 'tar' comment.
[05:53] <dmg> the only saving there would come from the -j, which re-bzip2's the info, but since the resulting file has to be base64-encoded again it's just going to expand out by whatever the base64 expansion ratio is.
[05:53] <dmg> which is probably what bzip2 managed to pull out of the base64 encoded core file in the first place.
[05:54] <pitti> exactly
[05:54] <pitti> 6/8 :)
[05:54] <pitti> (from the coredump)
[05:54] <pitti> and maybe 50% from the rest
[05:55] <dmg> but if the non-corefile version is only 10k, a saving of 5k on a 4-6M file isn't worth it.
[05:55] <Zdra> ok so compression isn't a solution, I think for low upload 1M is a max
[05:55] <pitti> dmg: launchpad should be able to handle binary data just fine
[05:55] <pitti> dmg: I just made it ascii so that developers can look at the file
[05:56] <pitti> and to keep it in debcontrol format
[05:59] <wasabi__> Something keeps setting LANGUAGE in /etc/environment to en_US:en_GB:en
[06:00] <wasabi__> I'd have expected en_GB to not be in there.
[06:00] <wasabi__> I believe it's causing my trash to be known as a wastebasket. :0
[06:15] <mdz> wasabi__: bug 10822?
[06:15] <Ubugtu> Malone bug 10822 in localechooser "en_US users see en_GB strings all over?" [High,Fix released]  https://launchpad.net/bugs/10822
[06:16] <wasabi__> Yeah looks like it.
[06:17] <mdz> wasabi__: note that it's marked fixed
[06:17] <mdz> since May
[06:17] <wasabi__> Update regenerate /etc/environment?
[06:18] <wasabi__> Could have been sitting there for awhile.
[06:18] <wasabi__> And I just never noticed.
[06:18] <mdz> not automatically, no
[06:18] <mdz> it's possible that the language selector updates it. mvo?
[06:23] <mvo> mdz: looking at the bug now. but it will not update /etc/environment unless explicitely done in the GUI
[06:25] <mdz> mvo: that's what I meant.  I wanted to be sure that even if the user changes settings in the gui, /etc/environment doesn't get the en_GB stuff which resulted in bug 10822
[06:25] <Ubugtu> Malone bug 10822 in localechooser "en_US users see en_GB strings all over?" [High,Fix released]  https://launchpad.net/bugs/10822
[06:26] <mdz> wasabi__: did you check the mtime on /etc/environment?
[06:27] <wasabi__> Naw, I edited it.
[06:28] <wasabi__> Heh. Nice. I added english support in the gnome-language-selector, and it's removing Yelp.
[06:28] <wasabi__> apt sillyness.
[06:28] <wasabi__> Oh. Apparently it was removing a lot more than that, too.
[06:29] <mdz> pitti: upgrading seems to remove bzrtools; is it obsolete or is a newer version needed for the new bzr?
[06:30] <mdz> pitti: ah, looks like the latter
[06:32] <pitti> mdz: I requested a sync for the newer Debian version
[06:33] <mdz> pitti: yes, I just saw bug 56308
[06:33] <Ubugtu> Malone bug 56308 in bzrtools "Please sync bzrtools (main) from unstable" [Untriaged,Confirmed]  https://launchpad.net/bugs/56308
[06:33] <pitti> mdz: however, the old bzrtools and new bzr coexist for me package-wise (just generate a nasty warning)
[06:33] <mdz> pitti: really?  bzrtools depends: bzr (<< 0.9)
[06:33] <mdz> bzr 0.9 won't install without removing the current bzrtools in edgy
[06:33] <pitti> mdz: but not conflicts:
[06:33] <pitti> mdz: is depends << version useful at all?
[06:34] <pitti> oh, hm
[06:34] <pitti> mdz: ignore me, please :)
[06:34] <mdz> it is in apt, at least
[06:34] <pitti> mdz: ah, I just dpkg -i'ed the new bzr package
[06:35] <iwj> seb128 (and anyone else): fixed firefox on its way.
[06:35] <Riddell> carlos: ping
[06:35] <seb128> iwj: cool, thank you
[06:36] <Riddell> carlos: needed in #ubuntu-meeting
[06:36] <carlos> ok
[06:38] <Keybuk> pitti: dpkg doesn't "sanity check" the installation the same way apt does
[06:39] <Keybuk> so it's possible to install something that should break another package's dependencies, provided you don't install that other package in the same run
[06:39] <bddebian> Aye :-(  I've hit that
[06:40] <iwj> This is a bug.
[06:40] <iwj> It should refuse unless you say -B, and then it should deconfigure the other thing.
[06:41] <ogra> how would it know about the other package if thats never been installed ? 
[06:41] <pitti> ogra: it is installed
[06:41] <ogra> ah
[06:42] <pitti> ogra: i. e. I had bzrtools 0.8 installed and then dpkg -i'ed bzr 0.9
[06:42] <pitti> that didn't break
[06:42] <pitti> althought bzrtools 0.8 depends: bzr < 0.9 
[06:42] <ogra> ouch 
[06:42] <pitti> -t
[06:42] <pitti> so I didn't even notice 
[06:42] <ogra> i missed the backlog, sorry
[06:45] <jcole> kernel hackers
[06:47] <jcole> in the "apt-get source linux-source-2.6.15" package, which kernel file do i edit in ./debian/config/i386/ to make my changes?
[06:50] <Keybuk> pitti: Debian #20471 or Debian #170825
[06:51] <Ubugtu> Debian bug 20471 in dpkg "dpkg ignores conflict with unconfigured package" [Unknown,Open]  http://bugs.debian.org/20471
[06:51] <Ubugtu> Debian bug 170825 in exim4-base "dpkg does not respect virtual dependencies when upgrading." [Unknown,Open]  http://bugs.debian.org/170825
[06:51] <trappist> jcole: you copy the config to the root of the kernel source directory and say 'make menuconfig'... or make xconfig for a gui configurator
[06:51] <pitti> Keybuk: ah, thanks
[06:52] <Keybuk> hmm, Ubugtu bug there, it read the original package and subject rather than the current one
[06:54] <wasabi__> Hmm. Nope. It just regenereated /etc/environment with en_GB
[06:54] <jcole> rappist: ah
[06:55] <jcole> ^^ trappist
[06:55] <jcole> trappist: that will update the other configs as well?
[06:55] <trappist> jcole: just realized what channel this was - /join #ubuntu please
[07:26] <sabdfl> iwj: any idea on the firefox https issue i filed last night?
[07:26] <sabdfl> it's blocking any serious work for me right now, w.r.t. bugs or specs or wiki
[07:27] <pitti> sabdfl: ah, it's not working for you and you get an SSL error dialog? You need to upgrade libnspr4 and libnss3 to the latest edgy version (2.0beta)
[07:28] <pitti> sabdfl: this will break evolution, but you can start it with 'LD_LIBRARY_PATH=/usr/lib/firefox evolution'
[07:28] <thom> sabdfl: is your x60 running edgy? if so, does it reboot correctly?
[07:28] <ogra> pitti, he's a thunderbirdie ;)
[07:29] <pitti> ogra: well, I'm a muttie, but still use evo for calendar/contacts/tasks :)
[07:29] <ogra> :)
[07:33] <thom> pitti: muttie heh
[07:34] <Surak> Is there a way to pass a parameter in isolinux to modprobe?
[07:35] <tkup> is there some serious issues with ubuntu's LVM?
[07:35] <tkup> I just can't create vg's at all
[07:37] <sabdfl> thom: it did this morning, should i be nervous of a reboot?
[07:37] <thom> hrm, interesting. previous edgy kernel hasn't rebooted once for me correctly
[07:37] <thom> i've not tried the new one though
[07:38] <sabdfl> what error do you see?
[07:39] <thom> none; it gets to the end of shutdown but never actual powers off or reboots; just sits with a black screen but the status lights on, which smells to me like an acpi oddity
[07:40] <sabdfl> pitti: i'm up to date edgy
[07:40] <sabdfl> libnss3 is version 2:1.firefox1.99+2.0b1+dfsg-1ubuntu1
[07:40] <sabdfl> https does not work with FF
[07:41] <sabdfl> mjg59: what does usplash present a developer with, in terms of graphics API?
[07:42] <sabdfl> if we wanted to hire someone to make nice bootsplash animations, what do we tell them they have handy?
[07:42] <sabdfl> some sort of vesa lib?
[07:43] <sabdfl> ?
[07:43] <sabdfl> spam
[07:43] <desrt> stock spam :p
[07:45] <ogra> you get invest alerts ? 
[07:45] <desrt> like crazy
[07:45] <desrt> they have a higher tendency to make it through the filters than penis spam
[07:45] <ogra> i get "mailtransport failed" with nice zip or scr attachments from "postmasetr@ubuntu.com"
[07:46] <ogra> lots of these
[07:46] <desrt> i'm near the point of putting a block to incoming emails containing .doc/xls/ppt/exe/pif/scr/zip/...
[07:46] <ogra> yeah
[07:46] <desrt> i don't think anything useful has ever been emailed to me in this form
[07:47] <tseng> someone send a dll to the mono list the other day
[07:47] <tseng> and i had to fish it out of the spam box
[07:47] <ogra> heh
[07:47] <desrt> a .dll is an odd one
[07:47] <desrt> most virii don't come like this
[07:48] <tseng> i think it was in my procmail rule though
[07:48] <desrt> i wouldn't have a procmail rule.  too high of a chance that someone might one day send me a .doc and expect that i got it
[07:48] <Robot101> desrt: in postfix I have a rules file that bins stuff like that at SMTP time
[07:48] <Robot101> desrt: meaning people get informative bounces
[07:48] <desrt> i'd rather just reject the receipt
[07:48] <desrt> yes.
[07:49] <desrt> exactly like this.  give 'em a 550
[07:49] <Robot101> ke
[07:49] <Robot101>                   that at SMTP time
[07:49] <Robot101> 18:48 < Robot101> desrt: meaning people get informative bounces
[07:49] <Robot101> 18:48 < desrt> i'd rather just reject the receipt
[07:49] <Robot101> 18:48 < desrt> yes.
[07:49] <Robot101> GARHGAHR
[07:49] <Robot101> http://www.securitysage.com/files/mime_header_checks
[07:49] <tseng> proof X clipboard blows
[07:49] <tseng> and firefox makes it worse
[07:49] <Robot101> why doesn't the terminal fill the primary selection when you right-click and go to copy the URL?
[07:50] <Robot101> I never use the crapping menu for anything else, so I never go to right-click -> paste
[07:50] <desrt> Robot101; i wrote my own rules for this
[07:50] <tseng> because thats the "wrong" clipboard :/
[07:50] <desrt> Robot101; for postfix... but i use sendmail and haven't been assed to switch yet
[07:50] <mdz> slomo: any guess why libiec61883 isn't in Debian?
[07:50] <Robot101> desrt: :-S
[07:50] <desrt> my entire server infra is freebsd
[07:50] <desrt> i'm switching it to ubuntu as soon as xen works properly
[07:51] <Robot101> I just did an install today on etch, so if those patches etc make it into edgy it should be fine
[07:55] <mjg59> sabdfl: The ability to draw boxes, lines and stuff
[07:56] <tseng> desrt: did you manage to convince j5 to fix dbus?
[07:56] <desrt> tseng; i've convinced him that it's a problem
[07:56] <desrt> tseng; they're hashing it on on their list
[07:56] <tseng> cool
[07:56] <desrt> tseng; i imagine it'll be fixed by 1.0
[07:56] <tseng> hot.
[07:57] <tseng> I can't figure how to fix it in last-exit
[07:57] <Keybuk> hmm... animated bootsplash
[07:57] <Keybuk> you could take "MovieOS" too literally that way
[07:57] <desrt> call gnome_vfs_init right inside of main
[07:57] <Keybuk> "CANONICAL LTD"
[07:57] <tseng> I did
[07:57] <desrt> or dbus_g_thread_init
[07:57] <Keybuk> "IN ASSOCIATION WITH THE UBUNTU COMMUNITY PRESENTS"
[07:57] <tseng> and that too
[07:57] <Keybuk> "A MATT ZIMMERMAN DISTRIBUTION"
[07:57] <desrt> you have to call it _right away_
[07:57] <Keybuk> "UBUNTU V - THE EDGY EFT"
[07:57] <desrt> first line
[07:57] <Keybuk> "STARRING FIREFOX 2.0"
[07:57] <tseng> no shit?
[07:57] <tseng> ok
[07:57] <fabbione> "BASED ON A TRUE STORY OF FABBIONE FS'ES"
[07:58] <LaserJock> Keybuk: haha, that's great
[07:58] <HiddenWolf> Keybuk: awesome. :)
[07:59] <Keybuk> when we get around to putting the alsa drivers into the initramfs, you could even have theme music
[08:02] <BenC> Keybuk: "eye of the tiger"
[08:02] <zul> the theme from chariots of fire
[08:02] <LaserJock> BenC: oh yeah
[08:02] <ogra> BenC, ++
[08:02] <LaserJock> zul: maybe a little boring
[08:03] <Keybuk> just when you thought it was safe to boot your PC on April 1st ...
[08:03] <desrt> BenC; at least 4 people now with that weird APIC bug... so i think we can rule out flaky hardware
[08:03] <ompaul> scene one "sabdfl leaves the CC due to FF2 and https" 
[08:03] <LaserJock> zul: that might fit for a 386 boot ;-)
[08:03] <zul> LaserJock: heh...what do i know..:)
[08:03] <tseng> desrt: farking hell, its fixed
[08:04] <tseng> desrt: re, wrong bin
[08:04] <desrt> tseng; told ya :)
[08:04] <tseng> no, wrong binary
[08:04] <tseng> I need to make it sooner
[08:04] <desrt> i mean 'told you that the fix worked' :p
[08:04] <tseng> writing it in liblastexit, binding to C#, calling *first thing in main*
[08:05] <desrt> if -anything- in dbus is touched before you do the call then it's too late
[08:07] <Riddell> ogra: do you have a bzr repository for hwdb-client?
[08:19] <pygi> pitti, poke :)
[08:26] <sabdfl> anybody else have a b0rked /etc/mailcap line 83?
[08:28] <segfault> mine seems to be ok here, no fail when running update-mime
[08:28] <BenC> sabdfl: audio/basic; /usr/lib/mime/playaudio '%s'; description=Basic uLaw Audio; nametemplate=%s.au
[08:29] <BenC> that's what mine looks like
[08:29] <BenC> probably different lines though :)
[08:29] <segfault> mine is gnumeric.
[08:30] <BenC> line numbers are probably pintless there
[08:30] <BenC> pointless even
[08:35] <tseng> desrt: not fixing it
[08:36] <tseng> desrt: this might be a different bug
[08:36] <sabdfl> BenC: application/x-sc is mine
[08:36] <sabdfl> broken line
[08:36] <tseng> desrt: unless iain has done something so evil as to call something before Main()
[08:38] <segfault> sabdfl: true, mine is broken too @ line 103.
[08:39] <icecrash> Kamion: short time for a question?
[08:46] <tseng> how can i turn off this apport business?
[08:48] <sbalneav> ogra: pingity
[08:52] <mvo> anyone here who upgraded his apt already? to 0.6.45ubuntu3? can you /msg me the output of "apt-get install --install-recommends --fix-policy"?
[09:01] <pitti> mvo: upgrading now
[09:01] <mvo> pitti: thanks!
[09:02] <pitti> mvo: ouch, dist-upgrade wants to remove gnome-app-install language-selector synaptic update-manager update-notifier
[09:03] <mvo> pitti: then wait a bit - the stack is not yet rebuild for ppc
[09:04] <pitti> mvo: I'm on amd64
[09:05] <mvo> pitti: does dist-upgrade also wants to remove python-apt?
[09:06] <geser> python-apt gets update here (amd64) together with apt and apt-utils
[09:06] <seb128> ogra: around?
[09:06] <pitti> mvo: no; however, p-apt is held back on a normal upgrade (which I'm doing ATM)
[09:22] <ogra> seb128, only for some minutes, whats up ?
[09:23] <seb128> ogra: 
 seb128: can we discuss gnome-screensaver a little?
[09:23] <seb128>  seb128: is it on purpose that you do not build-depend on GL?
[09:23] <ogra> err ...
[09:23] <ogra> indeed its not if thats the case ...
[09:24] <seb128> ogra: ok :)
[09:24] <seb128> ogra: http://librarian.launchpad.net/3551080/buildlog_ubuntu-edgy-i386.gnome-screensaver_2.15.5-0ubuntu1_FULLYBUILT.txt.gz
[09:24] <seb128> 	GL:                       no
[09:25] <ogra> uild-Depends: cdbs, debhelper (>= 4.1.0), libdbus-glib-1-dev (>= 0.60), libxml2-dev (>= 2.6.0), libgconf2-dev (>= 2.6.1), libgtk2.0-dev (>= 2.7.0), libgnomevfs2-dev (>= 2.6.0), libgnomeui-dev (>= 2.6), libglade2-dev (>= 2.5.0), libpam0g-dev, libgnome-menu-dev (>= 2.11.1), libxau-dev, libxmu-dev, libxss-dev, libxxf86vm-dev, libxml-parser-perl, libexif-dev, libxxf86misc-dev, gnome-pkg-tools
[09:25] <ogra> +Standards-Version: 3.7.2
[09:26] <ogra> looks like a debian bug ... 
[09:26] <ogra> thats the build-deps from the debian 2.14 package 
[09:26] <ogra> i'll fix that asap
[09:26] <ogra> (and file a debian bug ;) )
[09:28] <ogra> bbl
[09:30] <desrt> tseng; some weird constructors or something?
[09:30] <pygi> pitti, when you'll have time for me? :)
[09:30] <pitti> pygi: sorry, I didn't see your ping
[09:30] <pitti> pygi: just ask :)
[09:31] <pygi> pitti, our simple thingy about O_EXCL isn't that trivial as we thought :)
[09:32] <pygi> pitti, btw. I'll need testers for libburn-on-cdrecord layer soon, so if you can find them for me ^_^
[09:32] <pitti> pygi: where's the problem?
[09:33] <pygi> currently, I am thinking of following:
[09:33] <pygi> - O_EXCL locking for systems where this is in use
[09:33] <pygi> - no O_EXCL locking for systems where a O_EXCL rogue is
[09:33] <pygi>   active (if such system can give up locking at all).
[09:33] <pygi> - make libburn stop being an O_EXCL rogue in vanilla
[09:33] <pygi>   operation.
[09:33] <pygi> We have a problem deciding when the drive fds could be closed automatically.
[09:34] <pygi> current idea is to close unused drives by a new
[09:34] <pygi>   API-call issued by the application as soon as it
[09:34] <pygi>   decides to give them all up but one.
[09:34] <pygi>   Afterwards the application would not be allowed to
[09:34] <pygi>   access other drives until libburn is shut down and
[09:34] <pygi>   started again.
[09:34] <pygi> o joy, sorry about this :)
[09:35] <mdz> mvo: apt-get --fix-policy install does nothing for me here; is that expected?
[09:35] <mdz> I expected to have at least one unsatisfied recommends, considering that I install most things with apt-get
[09:36] <mdz> likewise with --fix-policy --install-recommends
[09:42] <cbx33> bzr is broken in edgy :(
[09:42] <cbx33> oh hang on
[09:42] <cbx33> :S
[09:43] <pygi> pitti, so thoughts? :)
[09:43] <pitti> pygi: what is an 'O_EXCL rogue'?
[09:44] <pitti> pygi: 'rogue' -> is that a process that uses O_EXCL to access a file?
[09:54] <pygi> pitti, means it gives us troubles ^_^
[09:54] <pygi> we've been testing with most kernels in existance lately :P
[09:55] <pitti> pygi: hm, I never saw much trouble with O_EXCL in cdrecord; I'm afraid I don't understand the problem
[09:55] <pygi> pitti, ah,oki ^_^
[09:56] <pygi> but you'll be able to test the layer I was talking to you about once it's ready?
[09:56] <pygi> it tricks app by making it think it uses cdrecord, but actually it uses libburn
[09:56] <pitti> yes, I can burn a CD with it
[09:56] <pygi> ok, thanks :)
[09:57] <pygi> preparing something simmilar for mkisofs as well
[09:57] <pygi> basicly, things look good on one side, and bad at other
[09:57] <pygi> but hopefully we'll solve everything one day :)
[10:01] <shackan> pygi, why is libburn better than cdrecord ?
[10:03] <mdz> shackan: it's a library API rather than a command line program (and an unfortunate command line program at that)
[10:03] <shackan> ah, fair enough :)
[10:04] <pygi> shackan, in terms of features it's currently not better, and I am not sure will it ever be
[10:04] <pygi> but we are making baby steps to the goal ^_^
[10:05] <shackan> yes, you already told me :)
[10:06] <pygi> pitti, at least any thoughts on: At what stage the stored drive fds could be closed automatically?
[10:07] <pitti> pygi: in a library you cannot assume anything about the fd passing-around of the app
[10:07] <pitti> pygi: I'd close them on an explicit close()/destructor/whatever function call
[10:08] <pygi> so to close unused drives by a new  API-call issued by the application as soon as it  decides to give them all up but one. ideais any good?
[10:08] <pygi> idea is*
[10:08] <pygi> right ^_^
[10:09] <pitti> pygi: why should the application keep unused FDs?
[10:10] <cbx33> hi guys.  Why in edgy do I have to type the quotes button twice "
[10:10] <cbx33> and when i do I don't get the right quotes mark?
[10:10] <pygi> pitti, Afterwards the application would not be allowed to access other drives until libburn is shut down and started again.
[10:10] <pitti> pygi: hm, this sounds as if your library looks for some ways to circumvent application bugs
[10:11] <seb128> you speak about cd burning?
[10:11] <pygi> seb128, indeed
[10:11] <seb128> is that know that cdrecord doesn't work with user on edgy?
[10:11] <pygi> pitti, :)
[10:12] <pitti> seb128: hah, happens to me, too
[10:12] <pitti> seb128: but apparently not to everyone
[10:12] <pitti> seb128: it's on my list of things to fix
[10:12] <seb128> pitti: we have some bugs about n-c-b and I've noticed cdrecord does the same
[10:12] <pygi> pitti, the thing I just described seemed logical to me, but I am l looking for someone to tell me I am wrong :)
[10:12] <pitti> seb128: some permission error in a sysctl?
[10:12] <seb128> it's on my list of things to look to or find somebody knowing the code to look to :)
[10:13] <seb128> pitti: "cdrecord: Operation not permitted. Cannot send SCSI cmd via ioctl"
[10:13] <pitti> seb128: exactly
[10:14] <seb128> "capset(0x19980330, 0, {CAP_SYS_RAWIO, 0, 0}) = -1 EPERM (Operation not permitted)
[10:14] <seb128> write(2, "Error: Cannot gain SYS_RAWIO cap"..., 99Error: Cannot gain SYS_RAWIO capability.Is cdrecord installed SUID root?
[10:14] <seb128> : Operation not permitted"
[10:14] <pitti> seb128: so far I downgraded to the dapper version, but it gets time to fix it properly
[10:14] <pitti> seb128: that's normal
[10:14] <seb128> ok, I was not sure
[10:14] <seb128> gettimeofday({1155586417, 764389}, NULL) = 0
[10:14] <seb128> ioctl(3, SG_IO, 0xbf8ce52c)             = -1 EPERM (Operation not permitted)
[10:14] <seb128> geteuid32()                             = 1000
[10:14] <seb128> setresuid32(-1, 0, -1)                  = -1 EPERM (Operation not permitted)
[10:14] <seb128> setresuid32(-1, 1000, -1)               = 0
[10:14] <seb128> gettimeofday({1155586417, 764496}, NULL) = 0
[10:14] <seb128> write(2, "cdrecord: Operation not permitte"..., 66cdrecord: Operation not permitted. Cannot send SCSI cmd via ioctl
[10:14] <seb128> ) = 66
[10:15] <pitti> the first one is the culprit apparently
[10:15] <seb128> looks like
[10:15] <seb128> iz linux bog?
[10:15] <pitti> seb128: it's something introduced by the new cdrecord upstream version
[10:15] <pitti> seb128: it wasn't done in the dapper version
[10:16] <seb128> pitti: ah ok, and Debian is not having the issue? or they are going to kick cdrecord out anyway and don't care?
[10:16] <pitti> seb128: I reported it to Debian ages ago (when I did the dapper merge for cdrecord), but it just got lost
[10:16] <pitti> seb128: or, rather, they ignored it as 'worksforme'
[10:16] <pitti> and indeed it works for some people
[10:16] <pitti> seb128: just not for us poor lads :/
[10:16] <seb128> pitti: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=374685
[10:16] <Ubugtu> Debian bug 374685 in nautilus-cd-burner "nautilus-cd-burner: fails to call cdrecord properly" [Grave,Open]  
[10:18] <pitti> seb128: arrgh @ Joerg Schilling
[10:19] <seb128> pitti: bug sort of turned to a "nice discussion" with upstream
[10:19] <Lure> pitti: is this due to http://lwn.net/Articles/193516/
[10:19] <seb128> right :/
[10:19] <pitti> Lure: I doubt it, but possible
[10:20] <pitti> Lure: it works with dapper cdrecord, breaks with edgy cdrecord, both with the very same kernel
[10:20] <seb128> pitti: the debian bug has a "patch" (understand: comment some code)
[10:21] <Lure> pitti: it seems that latest cdrecord uses more SCSI commands than before due to DVD add-ons - would need to dump SCSI CDB to see
[10:21] <pitti> hi zyga
[10:21] <pitti> seb128: yup, I saw that
[10:22] <Lure> and since kernel filters it (even though I though that kernel just "eats" unsupported commands) it fails
[10:22] <pitti> seb128: I'll look into it, but most probably I'll just comment out the added bits from the a03 version
[10:22] <pitti> (those who cause trouble, anyway)
[10:22] <seb128> pitti: ok, thank you
[10:22] <pygi> pitti, anyway I won't bother you much anymore...we have a cdrtools maintainer at debian interested ^_^
[10:23] <pitti> pygi: cool :)
[10:23] <pitti> pygi: still, I'm happy to test
[10:23] <pygi> pitti, ofcourse ^_^
[10:23] <pitti> pygi: as I said, I do not understand why libburn needs to grab all devices and then release some of them again
[10:24] <pygi> pitti, The official method to address a drive with libburn is to call burn_drive_scan() with the consequence that function open() is applied to any device file that could lead to a burner. open() stalls with devices which are ill or busy even if they are no burners or not intended for use with libburn.
[10:25] <pitti> pygi: ouch
[10:25] <pitti> pygi: in a scanning function you should use O_NONBLOCK and never O_EXCL
[10:25] <pygi> pitti, I've got in a patch just today: 
[10:25] <pitti> pygi: and immediately close the fd again
[10:26] <pygi> - Persistent address is the device file address as found in
[10:26] <pygi>     struct burn_drive_info.location .
[10:26] <pygi> - The desired drive address is put into a whitelist.
[10:26] <pygi>     The (currently two) drive enumeration functions of libburn query the whitelist before applying open() to a device. If the whitelist is not empty and if the candidate device is not listed, then open() is skipped and the device gets handled as if it did not offer read-permission. If the whitelist is empty, then all enumerated drives get opened. Thus traditional operation of libburn is not affected as long as the whitelist API function
[10:26] <pygi> s are not used by the application.
[10:26] <pitti> pygi: and then, once you figured out the device, you open it with O_EXCL|O_NONBLOCK and a timeout
[10:26] <zyga> pitti: hello :)
[10:26] <pygi> pitti, read my paste, this is the patch I commited today is all about
[10:27] <pitti> yup, that makes sense
[10:27] <pitti> zyga: congratulations to you and your wife!
[10:27] <zyga> thanks :))
[10:27] <pygi> pitti, really? wow :)
[10:27] <pygi> congrats zyga :)
[10:27] <zyga> I need to get up to speed with edgy, fast
[10:27] <pitti> pygi: but your quote was pretty orthogonal to opening modes :)
[10:28] <pygi> libburn 0.2.1 : zyga's edition, lol:)
[10:28] <pitti> zyga: dist-upgrade! now! break cd burning, firefox, evolution, and get crash reports slammed around your ears! :)
[10:28] <zyga> pygi: ? :)
[10:28] <zyga> pitti: pulling edgy-current now
[10:28] <pygi> zyga, nothing, nothing, ignore me pls :)
[10:28] <zyga> I don't want to break dapper, it's too lovely :)
[10:28] <pitti> pygi: that edgy is, well, not as stable yet as we'd like it to be? :)
[10:29] <pygi> pitti, I meant on: "but your quote was pretty orthogonal to opening modes :)" :)
[10:29] <pygi> zyga, thinking of codename for libburn 0.2.1, hehe :)
[10:30] <pitti> pygi: ah, well, I mean what I said; the whitelist strategy has little to do with open(2) modes
[10:31] <pygi> pitti, right, open will be addressed by another commit/patch :)
[10:32] <pitti> pygi: AFAICS, if the scan function uses O_RDONLY|O_NONBLOCK, it will only stumble over O_EXCL-opened devices (i. e. a currently progressing burning)
[10:32] <pitti> pygi: and if the actual burning uses O_RDWR|O_EXCL|O_NONBLOCK, that should work fine everywhere and be on the safe side
[10:32] <pitti> pygi: so, was your question about the first issue? ('will only stumble over...')
[10:34] <zyga> hey seb128 
[10:34] <seb128> hi zyga
[10:36] <seb128> zyga: what's up?
[10:36] <cbx33> hehe something has gone wrong somewhere  hehehehe my karma:519846
[10:37] <bddebian> Holy crap and I thought mine was high
[10:37] <zyga> seb128: got married, moved, got promoted, have own place to live :)
[10:37] <seb128> a lot :)
[10:37] <zyga> seb128: and I'm back to ubuntu with my free time :)
[10:37] <pitti> cbx33: heh, indeed, I have 1.83M now
[10:37] <seb128> congrats for all that ;)
[10:37] <bddebian> cbx33: Oh, I guess it has:  745229
[10:38] <bddebian> pitti: Nicde
[10:38] <bddebian> -d
[10:38] <pygi> pitti, thanks for the help, I'll look into it more later tonight
[10:38] <seb128> zyga: ah, nice, Ubuntu work is always welcome :p
[10:38] <cbx33> i notice the top contributor has over 5million
[10:38] <pitti> seb128: your karma must be negative by now
[10:38] <pitti> due to int overflow
[10:38] <bddebian> doh
[10:38] <cbx33> seb128, congrats on the marriage :p
[10:38] <seb128> pitti: heh, it was, I'm wondering how many times I did the whole range by now :p
[10:39] <seb128> cbx33: that's not me :/
[10:39] <zyga> cbx33: that's me
[10:39] <cbx33> oh sorry
[10:39] <cbx33> hehe
[10:39] <cbx33> of course
[10:39] <cbx33> I've been stuck in python code all evening...my brain musn't be working
[10:39] <cbx33> congrats zyga 
[10:40] <cbx33> oooh pygi 
[10:41] <cbx33> getting ya hands and feet dirty
[10:41] <pitti> sounds like we all have lots of fun. great! :)
[10:41] <cbx33> hehe indeed
[10:41] <pygi> pitti, I looked at the mkisofs code...that thing is such a mess that I'd never look at it again :P
[10:41] <pitti> pygi: don't :)
[10:42] <cbx33> pygi, you know your cd burner
[10:42] <pygi> cbx33, ahm? :)
[10:42] <cbx33> if you'd like an optional package remember gisomount
[10:43] <pygi> cbx33, what should I do with gismount? (sorry, a bit exhausted with this libburn mess today :P)
[10:43] <cbx33> i dunno
[10:43] <pygi> why you mentioned it then ? :)
[10:43] <cbx33> if they are just creating an iso with it, 
[10:44] <cbx33> then they could use gisomount to mount that iso and browse it, or create md5sum
[10:44] <cbx33> just mentioning it....soz pygi 
[10:44] <pygi> does it burn cds? can it create ISO files?
[10:44] <cbx33> remember my brain is fried too
[10:44] <pygi> no worries :)
[10:44] <cbx33> ahhhh o
[10:44] <cbx33> home
[10:44] <pygi> cbx33, but no really...can it burn cd's or create ISO files?
[10:45] <cbx33> no gisomount can just mount the iso
[10:45] <pygi> hm,oki ^_^
[10:45] <pygi> cbx33, we should have "Burn-ISO-in-one-button" feature :)
[10:46] <cbx33> well you can burn an iso from gisomount
[10:46] <pygi> cbx33, using what?
[10:46] <cbx33> but then you could just right click it and select burn
[10:46] <cbx33> gnome cd record
[10:46] <pygi> ah :P
[10:46] <cbx33> but i could be persuaded to make a modification
[10:46] <cbx33> :p
[10:47] <pygi> cbx33, you'll test the libburn-over-cdrecord one day ^_^
[10:47] <cbx33> heheh
[10:48] <pygi> cbx33, just you laugh :)
[10:55] <lemsx1> hello all
[10:55] <lemsx1> i updated one of my dev boxes to Edgy (from Dapper)
[10:55] <lemsx1> and i have a few (non-support-related) questions
[10:56] <lemsx1> it seems that the new kernel (2.6.17-6-686 in my case) uses ide-scsi to mount drives
[10:56] <lemsx1> that works fine for ext3 and swap filesystems, but for XFS it failed
[10:57] <lemsx1> going back to the "stable" (dapper) kernel worked
[10:57] <lemsx1> did i just hit a (known) bug?
[10:57] <pitti> lemsx1: hm, my xfs partition was automatically transitioned and is mounted correctly
[10:58] <pitti> lemsx1: does the /etc/fstab entry look reasonable?
[10:58] <lemsx1> pitti: you have / as ext3 (or whatever) and some other partition as XFS ?
[10:58] <lemsx1> pitti: yep. the only new thing in /etc/fstab is UUID:.... for /home (my xfs partition)
[10:58] <pitti> lemsx1: yes, / on reiserfs, and my only xfs partition is a non-critical one (/mm)
[10:59] <lemsx1> pitti: the error i was getting was some I/O buffer 
[10:59] <lemsx1> pitti: perhaps is still in some log... let me see
[10:59] <Seveas> lemsx1, sounds like a bug to me
[10:59] <pitti> lemsx1: please file a bug with details (/etc/fstab, log files, dmesg, sudo fdisk -l)
[11:00] <lemsx1> ok. i have XFS partitions on different disks at home, and i also updated that system to edgy. that one rebooted fine. i have to make sure that my partitions were mounted (all LVM stuff)
[11:00] <lemsx1> pitti: ok. let's see if i can get the old dmesg
[11:01] <lemsx1> [17179588.556000]  I/O error in filesystem ("sda3") meta-data dev sda3 block 0x218d6ff       ("xfs_read_buf") error 5 buf count 512
[11:01] <lemsx1> fdisk -l will show as "hda" now. before it was showing under /dev/sda
[11:01] <pitti> lemsx1: hm, you mean the other way round?
[11:01] <pitti> AFAIK it was supposed to be hdX -> sdX (ide-scsi)
[11:01] <lemsx1> pitti: i'm using the old dapper kernel now
[11:02] <pitti> ah
[11:02] <lemsx1> pitti: how can i turn off ide-scsi?
[11:03] <Keybuk> hmm?
[11:03] <gnomefreak> just a notice the latest apt and ff updates broke alot of things :(
[11:03] <pitti> Keybuk: see above, there seems to be a bug in the ide-scsi transition
[11:03] <pitti> Keybuk: for lemsx1 
[11:03] <Keybuk> a bug?
[11:03] <pitti> gnomefreak: known
[11:04] <gnomefreak> ok
[11:04] <Keybuk> that doesn't look like a bug to me
[11:04] <lemsx1> Keybuk: indeed. give me details on how to get debug information for you... i'll open a bug shortly
[11:04] <Keybuk> looks like a duffed filesystem
[11:04] <Keybuk> lemsx1: I'd file the bug with the kernel directly
[11:04] <Keybuk> it's not a transition problem, afaik
[11:04] <lemsx1> Keybuk: ... it works with the old kernel (??)
[11:05] <Keybuk> right, iz kernel bug
[11:05] <Keybuk> btw, we're not using ide-scsi
[11:05] <lemsx1> Keybuk: yeah, kernel. not the ide-scsi stuff. that worked
[11:05] <lemsx1> Keybuk: what's used then?
[11:05] <Keybuk> the kernel in general is dropping the IDE subsystem
[11:05] <lemsx1> Keybuk: i saw sg and other scsi drivers were loaded
[11:05] <Keybuk> and we're using new drivers that expose old "Parallel ATA" disks through the SCSI subsystem
[11:06] <Keybuk> just like "Serial ATA" disks are already
[11:06] <lemsx1> Keybuk: ah, ok. you mean the vanilla kernel,not just ubuntu. right?
[11:06] <Keybuk> right
[11:06] <zyga> oh!
[11:06] <Keybuk> we're just testing it :)
[11:06] <zyga> so no more hda? :)
[11:06] <lemsx1> Keybuk: i see
[11:06] <Keybuk> zyga: keep up ;)
[11:06] <Keybuk> lemsx1: the upgrade should have rewritten your /etc/fstab to have UUID=... instead of the old /dev/hda names
[11:07] <lemsx1> Keybuk: yep. that worked like a charm
[11:07] <zyga> wow :)
[11:07] <Keybuk> so the problem for you isn't that the filesystem isn't mounted
[11:07] <Keybuk> the problem is that the filesystem isn't working through the newer driver
[11:07] <lemsx1> Keybuk: thanks goodness that also works with the old kernel ;-) if not i'd need a live disk to fix it
[11:07] <Keybuk> lemsx1: UUID= works in dapper <g>  we somewhat deliberately did that a release in advance knowing this was happening
[11:07] <lemsx1> Keybuk: you hit the problem right in the head
[11:08] <lemsx1> Keybuk: and i dunno if its' because it's XFS or what
[11:08] <Keybuk> this could be a filesystem problem (ie. on disk, it's bad), it could be a filesystem driver problem (XFS bug) or it could be a driver problem
[11:08] <lemsx1> Keybuk: the other partitions in the same drive worked fine ( / and swap )
[11:08] <lemsx1> Keybuk: if it was a hardware problem, i'd get the same problem with the old kernel (from dapper)
[11:09] <lemsx1> Keybuk: and that's what i'm using now. it works
[11:09] <lemsx1> Keybuk: that leaves XFS driver and whatever other driver that does the SCSI translation
[11:09] <Keybuk> *nods* I'd tend to agree
[11:10] <Keybuk> make sure you attach lsmod output
[11:10] <lemsx1> Keybuk: cool thing you did in dapper... sounds like Apple: shipping features turned off in new versions... way to go
[11:10] <lemsx1> Keybuk: why UUID and not LABEL like redhat?
[11:10] <Keybuk> UUID is supposed to be universally unique
[11:11] <Keybuk> so in theory, two devices can never have the same one
[11:11] <Keybuk> where two disks can quite easily be called "HOME"
[11:11] <lemsx1> Keybuk: ok. i'll have to do some reading about UUID... i remember seeing the code in dapper's initramfs before (i'm the main devel of Splashy. i deal a lot with funky initramfs problems)
[11:11] <Keybuk> part of the reason for the transition is that you'll now be able to use removable USB disks as part of your filesystem
[11:12] <Keybuk> and it won't matter what order you plug them in
[11:12] <pitti> lemsx1, Keybuk: in practice, too; the breezy installer labelled partitions after their mountpoint, with the result that I had three partitions with the label '/' after some time :)
[11:12] <crimsun> lemsx1: do you use quotas?
[11:12] <lemsx1> crimsun: no. no quotas
[11:13] <lemsx1> and no lvm here either (i have lvm at home... i'll check in a few hours)
[11:18] <sabdfl> infinity: ping
[11:39] <mdz> seb128: thanks for fixing totem-mozilla
[11:39] <Keybuk> sabdfl: slightly early for infinity yet, not even 0800 there
[11:39] <seb128> mdz: np ;)
[11:40] <mdz> Keybuk: one never knows with him
[11:40] <tseng> desrt: I have no idea :/
[11:40] <tseng> desrt: but i have a different traceback now than muine I think
[11:40] <ajmitch> mdz: does f-spot fall under the desktop UVF exception, or shall I get one from you?
[11:40] <tseng> desrt: if you're curious enough to see it I could reproduce, forgot to check in my bzr branch at work
[11:41] <mdz> ajmitch: is it part of GNOME releases?
[11:41] <mdz> there is no desktop UVF exception
[11:41] <tseng> desrt: if you're not I am going to leave it to baris, who seems to be the guy who broke it.
[11:41] <ajmitch> mdz: no, tomboy was added, f-spot not
[11:41] <mdz> ajmitch: then it needs an exception, yes
[11:42] <pitti> good night
[11:42] <tseng> cya pitti 
[11:42] <ajmitch> mdz: thanks, I'll ask when the release comes up soon
[11:42] <Lure> latest apt-get update wants to remove adept* and kubuntu-desktop on Kubuntu Edgy: http://paste.ubuntu-nl.org/20593
[11:42] <Lure> is this just temporary or should I file a bug?
[11:42] <mdz> Lure: adept probably needs to be updated for the new apt
[11:43] <mdz> I don't know whether someone is working on it already
[11:43] <trappist> Lure: removing kubuntu-desktop won't have any effect
[11:44] <sabdfl> mdz: any progress on ff2 https for those of us b0rked?
[11:44] <sabdfl> bit of a deal-breaker, that one
[11:44] <cbx33> indeed
[11:44] <cbx33> I was trying to get a branch address from LP ealier and forgot :p
[11:44] <mdz> sabdfl: I have no idea; I've never seen the problem
[11:44] <tseng> sabdfl: have you really upgraded to ff2?
[11:45] <mdz> tseng: it's in edgy
[11:45] <tseng> the only time i saw ssl broken here was when firefox was held back
[11:45] <tseng> and i had new nss with old firefox
[11:45] <cbx33> yup busted in edgy
[11:45] <tseng> or something like this.
[11:45] <mdz> sabdfl: have you tried with a fresh profile?
[11:45] <tseng> if i force ff2 it works for me
[11:45] <mdz> cbx33: not exactly
[11:46] <Keybuk> mdz: there's definitely a bigger problem
[11:46] <Keybuk> if you either
[11:46] <cbx33> mdz, ok, not working at 100%
[11:46] <Keybuk> a) upgrade firefox and don't upgrade libnss/libnspr
[11:46] <mdz> cbx33: not working for 100% of users
[11:46] <Keybuk> b) upgrade firefox and upgrade libnss/libnspr
[11:46] <cbx33> mdz, then we are agreed ;)
[11:46] <Keybuk> c) upgrade libnss/libnspr and don't upgrade firefox
[11:46] <Keybuk> then you're left with a broken machine
[11:46] <Keybuk> a) causes firefox to break
[11:46] <Keybuk> b) causes evolution to break
[11:46] <Keybuk> c) causes firefox to break
[11:46] <mdz> the evolution problem is fixed
[11:47] <mdz> with the latest firefox build
[11:47] <Keybuk> does the latest firefox build not cause the removal of ubuntu-desktop ?
[11:47] <mdz> b) is the correct thing to do, a) and c) are silly (but should be enforced by dependencies)
[11:47] <Keybuk> b) can only be done by removing locales, etc.
[11:47] <mdz> I have no idea what you mean
[11:47] <mdz> oh, you mean language-support
[11:47] <Keybuk> yeah
[11:47] <tseng> forcing firefox removes locale data
[11:47] <mdz> yes, the locales have not yet been updated
[11:48] <Keybuk> and the firefox theme too, iirc
[11:48] <Keybuk> which is a dep of ubuntu-desktop
[11:48] <mdz> the firefox theme doesn't work with new firefox yet
[11:48] <mdz> no it isn't
[11:48] <mdz> it's a dep of firefox
[11:48] <mdz> (and not anymore)
[11:48] <Keybuk> ah, maybe I misread that in aptitude's complaining then
[11:49] <zul> hey
[11:49] <mdz> sabdfl: is that what you did?  held back some packages to avoid removing language-support-en?
[11:49] <mdz> if so, push ahead and you'll be fine
[11:49] <Keybuk> how is losing language support "be fine" ?
[11:49] <tseng> because sabdfl speaks native C
[11:50] <sabdfl> interesting, fixed now, it was jammed on my version of the firefox ubuntu theme
[11:50] <Keybuk> zsh: segmentation fault (core dumped)  dd if=/dev/zero of=/dev/null count=1000
[11:50] <Keybuk> (in other news, really must track down who caused that and beat them to death)
[11:50] <sabdfl> Keybuk: with a damp sponge, so it's really humiliating as well as, err, terminal?
[11:51] <Keybuk> yeah, penalty for breaking dapper
[11:52] <cbx33> For those who were in the CC meeting earlier requesting oggs of the new development ubuntu sounds http://www.progbox.co.uk/finals/
[11:52] <cbx33> please note they are not finished, am looking for feedback on them
[11:52] <mdz> Keybuk: "temporarily removing language-support-en" != "losing language support" by any stretch of the imagination
[11:53] <mdz> cbx33: perhaps you have the same problem as sabdfl then
[11:54] <cbx33> possibly, I can check tomorow, don;t have my vmware machine with me now
[11:54] <Keybuk> mdz: *shrug*  I find it easier to just ignore the problem for a while ... it's only my laptop after all
[11:55] <mdz> Keybuk: please file a bug about the lack of stricter dependencies regarding libnss
[11:55] <Keybuk> mdz: I would, except Launchpad requires SSL <g>
[11:55] <Keybuk> arguably the bug should be that libnss needs a SONAME change
[11:55] <mdz> Keybuk: if it's against your religion to temporarily uninstall a package, then use a live CD
[11:55] <mdz> or a different browser
[11:56] <mdz> or a chroot
[11:56] <mdz> you are resourceful
[11:56] <lemsx1> Bug #56384
[11:56] <Ubugtu> Malone bug 56384 in linux-source-2.6.17 "Can't mount XFS drive after upgrading to Edgy (from dapper)" [Untriaged,Unconfirmed]  https://launchpad.net/bugs/56384
[11:58] <mdz> lemsx1: #ubuntu-bugs is the place where all new bugs filed in Ubuntu are announced
[12:00] <lemsx1> mdz: ok. good to know
[12:04] <pygi> Keybuk, I've been playing with sending movie over Dbus lately :)