[00:33] <crimsun> somerville32: thanks for helping clean up the menu clutter
[00:33] <somerville32> crimsun, :)
[00:38] <Seveas> the menu is empty now? :)
[00:40] <crimsun> as far as PulseAudio apps in Applications>Sound & Video, it's much cleaner.
[00:56] <pochu> doko: is there any chance we can get in the patch from http://bugs.python.org/issue1583 ? That will allow us to get http://bugzilla.gnome.org/show_bug.cgi?id=481569 fixed in Hardy.
[00:56] <ubotu> Gnome bug 481569 in gtk "Calling gobject.threads_init() causes a lot of wakeups" [Normal,Resolved: fixed]
[01:18] <Vad1> Is an experienced coder needed anywhere? One is willing to help - http://ubuntuforums.org/showpost.php?p=4130846&postcount=30. But I don't know where to direct him.
[01:19] <ScottK2> Vad1: How about #ubuntu-motu.
[01:19] <Vad1> ScottK2: Mk.
[01:20] <crimsun> the most apropos one is in the topic of this channel.
[01:20] <crimsun> --> http://wiki.ubuntu.com/UbuntuDevelopment
[01:20] <ScottK2> That too
[03:21] <mjg59> keescook: The currently shipping version of libdisasm (which seems to date from 2004) is Artistic License 1.0, which isn't GPL compatible. The CVS on Sourceforge doesn't seem to have been touched since then. Is there another version you were talking about?
[03:23] <mjg59> keescook: And the 0.22 tarball doesn't seem to have a license file at all :)
[04:38] <emgent> Nafallo, ping
[05:22]  * calc wishes he could resume on amd64 arch
[05:23] <calc> i upgraded to 4gb ram and ~ 700MB is missing on i386
[05:23] <RAOF> calc: Sucks that you can't resume.  I can.
[05:24] <calc> i have 965 video and it won't resume :(
[05:24] <calc> hmm i wonder if upgrading my bios would help
[05:24] <calc> i saw a new one is out
[05:24] <calc> that would be nice if it does
[05:28] <calc> wow vista is actually responsive after upgrading from 1gb -> 4gb of ram :)
[05:41] <calc> grr i still lose 700MB in x86_64 for whatever reason
[05:41] <calc> probably bios is too dumb to relocate the pci stuff
[05:43] <calc> and still no resume from sleep on x86_64 :-\
[05:43] <calc> so back to i386 again
[05:50] <persia> calc: Just stop sleeping :)
[05:58] <ScottK> Sleep is for the weak.
[05:59]  * RAOF thought sleep was a WoW game mechanic
[06:09] <pitti> Good morning
[06:10] <ScottK> Good morning.
[06:10] <StevenK> Morning pitti
[06:10] <pitti> hey guys!
[06:15] <emgent> morning *
[06:17] <dholbach> good morning
[06:18] <ScottK> Heya dholbach
[06:18] <dholbach> hey scottK
[06:18] <emgent> heya dholbach :)
[06:19] <dholbach> hey emgent
[06:19] <dholbach> hey thekorn
[06:19] <dholbach> how are y'all doing?
[06:19]  * pitti hugs dholbach
[06:19] <emgent> lol
[06:20]  * dholbach hugs pitti back
[06:20] <dholbach> man... some people have been very busy over the weekend...
[06:20]  * dholbach dives head-first into his inbox
[06:21]  * emgent working to desktop look
[06:23] <thekorn> good morning dholbach
[06:24] <ion_> Hi all
[06:24] <ion_> I slept 20 hours last ”night”. :-)
[06:24] <dholbach> ion_: congratulations... my dog kept me up most of last night *yawn*
[06:26] <ScottK> infinity: Ping - I was wondering how the sbuild problem with virtual versioned provided was going ...
[06:33] <Burgundavia> ugh, I wish LP did browser agent sniffing to tell us which version of Ubuntu bug reporters used
[06:34] <Burgundavia> with three supported and one development distro, figuring out which they are reporting their bug against is very difficult
[06:34] <StevenK> Burgundavia: 4 supported.
[06:35] <Burgundavia> dapper, feisty and gutsy
[06:35] <Burgundavia> is edgy still?
[06:35] <Burgundavia> right, it is
[06:35] <StevenK> So, four
[06:36] <Burgundavia> yay
[06:37] <Burgundavia> anyway, I need to sleep
[07:10] <Tonio_> hello to all
[07:15] <dholbach> hiya Tonio_ - hey persia
[07:17] <persia> good day dholbach
[08:34] <geser> good morning
[08:34] <mdke> morning all
[08:36] <dholbach> hey geser
[08:37] <geser> hi dholbach
[10:11] <Mithrandir> slangasek: do you know if kerberos has any concept of .local support?  it might be interesting to have some integration there for hosts where you can't be asked to set up DNS (because it's a home network with five machines and so using .local is convenient, but that loses you kerberos support)
[10:24] <geser> is there an "inofficial" limit for packages in the archive? will a 700 MB source package building an arch:all data package (probably the same size) get accepted?
[10:25] <tjaalton> geser: just curious, what package?-)
[10:26] <geser> tjaalton: urbanterror-data on revu (data files for the urbanterror game)
[10:27] <tjaalton> that's big :)
[10:30] <persia> geser: I asked the archive admin ML about inclusion of a 100MB file currently externally hosted a few months ago, and have yet to get a response, which leads me to the belief that it's currently handled by the NEW processor of the day.
[10:31] <cjwatson> 700MB> I think it would have to be pretty important
[10:31] <pitti> Richte libflickrnet2.1.5-cil ein (25277-6) ...
[10:31] <pitti> * Installing 1 assembly from libflickrnet2.1.5-cil into Mono
[10:31] <pitti> ! Assembly /usr/share/cli-common/policies.d/libflickrnet2.1.5-cil/policy.2.1.FlickrNet.dll does not exist
[10:31] <pitti> is this a known bug?
[10:32] <cjwatson> I wouldn't be happy about accepting a package that big
[10:32] <Mithrandir> pitti: I see it too, at least.
[10:32] <seb128> pitti: it was supposed to be fixed in -6
[10:32] <persia> pitti: There was discussion about it in the last 24 hours.  There's some issue with how mono handles alternatives that was last thought to be the culprit.
[10:32] <cjwatson> bug 182130
[10:32] <ubotu> Launchpad bug 182130 in libflickrnet "package libflickrnet2.1.5-cil 25277-5 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [Undecided,In progress] https://launchpad.net/bugs/182130
[10:32] <pitti> ok, thanks
[10:32] <Mithrandir> doko: how hard would it be to build icedtea for lpia for gutsy?
[10:33] <doko> Mithrandir: the current one?
[10:33] <Mithrandir> doko: yes
[10:33] <Mithrandir> (in a PPA)
[10:34] <doko> it should build out of the box; let me have a look at the b-d's.
[10:34] <Mithrandir> thanks
[10:56] <doko> ion_: ruby1.9 is universe, isn't it? Does Debian build with -g now?
[10:57] <ion_> doko: Yes, and Debian has the 1.9.0.0 release, whereas Ubuntu has a pre-1.9.0.0 snapshot.
[10:59] <ion_> (As in yes, it builds with -g)
[11:03] <bigon> could someone have a look at bug 182509 ?
[11:03] <ubotu> Launchpad bug 182509 in mono "Correctly install alternatives" [High,New] https://launchpad.net/bugs/182509
[11:03] <bigon> this is needed to fix bug 182130
[11:03] <ubotu> Launchpad bug 182130 in libflickrnet "package libflickrnet2.1.5-cil 25277-5 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [Undecided,In progress] https://launchpad.net/bugs/182130
[11:07] <doko> pochu: can you test the patch for python2.5?
[11:20] <pochu> doko: sure, I'll patch it and see the results in pygtk applications and make a bug report if that's fine.
[11:20] <cohonen> hey guys
[11:21] <cohonen> how do i get qt-4.4 installed
[11:21] <cohonen> ?
[11:21] <doko> pochu: thanks
[11:26] <cohonen> anyone
[11:28] <cjwatson> cohonen: please see the topic
[11:30] <ogra> cjwatson, do you think its possible to get an entry for "Install a thin client server" on the alternate CD ? UI space should suffice for another entry and i'd like to have it easier than "add ltsp-client-builder/run=true to your bootoptions" ...
[11:31]  * ogra grumbles about broken mono deps on the daily
[11:32] <cjwatson> ogra: need to do the planned reorganisation of the whole menu first, I think ...
[11:32] <cjwatson> (which is on the hardy list)
[11:32] <cjwatson> would that be ok? I'd rather do it that way round if possible
[11:32] <ogra> oh, i wasnt aware there was more planned ...
[11:33] <ogra> sure
[11:34] <ogra> for testing i can give my users instructions on preseeding its not *that* hard :) i just want it to be easy in the final CD
[11:47] <Mithrandir> doko: icedtea seems to ftbfs with genCharsetProvider.sh: 51: addNotices.sh: not found
[12:30] <ogra> pitti, SHRIEK !!!! bug #182262
[12:30] <ubotu> Launchpad bug 182262 in gnome-screensaver "gnome-screensaver-gl-helper crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/182262
[12:32] <ogra> looks like apport triggered 650 retraces, one every 4 min over the whole weekend
[12:32] <seb128> nice ;-)
[12:33] <seb128> ogra: you got mails? ;-)
[12:33] <ogra> i didnt have the balls to even open my bugs folder until now sicne it showed over 800 bugs suddenly
[12:34] <seb128> heh ;-)
[12:34] <ogra> yeah, tons
[12:35] <seb128> ogra: you are lucky, the i386 retracer crasher yesterday apparently ;-)
[12:35] <StevenK> Haha
[12:35] <seb128> ogra: I'll wait on pitti before restarting it
[12:35] <ogra> wow, thats like wining the lottery \o/
[12:36] <pitti> ogra: eww
[12:37] <seb128> no, in fact that's the gutsy retracer which crasher
[12:37] <seb128> pitti: where are the hardy retracers running?
[12:37] <pitti> seb128: hm, 2007-09-21 02:06 retracer-amd64.log
[12:37] <pitti> that's quite outdated
[12:37] <pitti> seb128: seems we don't have a current log for amd64
[12:38] <pitti> and I can't find that bug in the log
[12:38] <seb128> me neither
[12:38] <pitti> seb128: it's the very same
[12:39] <pitti> seb128: crash-digger seems a bug, parses the release out of it and uses the corresponding chroot
[12:39] <pitti> seb128: I restarted the i386 one, I'll watch it for a bit
[12:39] <seb128> ok
[12:39] <pitti> seems it has troubles with removing the tag or so
[12:39] <pitti> "Consolidating duplicate database...", will take a while
[12:39] <seb128> why?
[12:40] <emgent> pitti, can you sponsorize my security patch in universe ?
[12:40] <emgent> (gutsy, Feisty)
[12:40] <pitti> seb128: it updates its internal duplication db against the real LP to see which bugs have been fixed, to do the appropriate action on duplication
[12:41] <pitti> ogra: sorry for the mess
[12:41] <ogra> pitti, ah, well it was a relief to see they are all on one bug, easily solved by selecting and "mark as read" :)
[12:42] <geser> ogra: be happy that it didn't happen over the christmas vacation :)
[12:42] <ogra> geser, i am !
[12:42] <ogra> i hade over 4000 mails anyway after that ....
[12:43] <pitti> seb128: log files fixed; amd64 was using the i386 one, and i386 didn't have a log
[12:43] <pitti> so, I can't find out what happened before
[12:44] <seb128> ok
[12:49] <pitti> ogra, seb128: I wrote an apology to the submitter
[12:49] <seb128> pitti: good idea
[12:50] <seb128> pitti: did you figure what was wrong with the retracer?
[12:50] <pitti> still consolidating
[12:50] <pitti> I should have started it without -i
[13:38] <Ng> does suspend/resume stuff in hardy use acpi-support or pm-utils at the moment?
[13:42] <pitti> Ng: pm-utils
[13:42] <Ng> okidoki, thanks :)
[13:52] <pitti> Ng: suspend to ram broken for you as well?
[13:53] <Ng> pitti: the suspend end works, but on resume my graphics get very confused and I wanted to check if I should be trying quirk things or acpi-support things
[13:53] <pitti> Ng: right, same here (Intel GMA950, dell laptop)
[13:54] <Ng> pitti: I filed the thing I'm seeing as #182791
[14:04] <Kmos> geser: you already talk to some lp admin about the package checkstyle problem when moving to universe?
[14:04] <geser> Kmos: yes, cprov fixed it already
[14:06] <Kmos> nice :) thanks
[14:28] <gpocentek> Could an archive admin get the goffice binaries out of new (soname bump)? thanks
[14:28]  * Hobbsee hides
[14:29] <Kmos> gpocentek: you need to slangasek wake up :)
[14:29] <Hobbsee> ooh, it's in main.  i could even do it
[14:30] <seb128> Hobbsee: are you doing it then?
[14:30] <Hobbsee> seb128: no, go ahead.
[14:30]  * Hobbsee doesn't like doing libraries
[14:30] <geser> Hobbsee: is there a reason why you wouldn't do it if it were in universe?
[14:30] <seb128> Hobbsee: why?
[14:30] <seb128> Hobbsee: it's binary new for a soname change
[14:30] <Hobbsee> geser: yeah - because i'd have to get an archive admin to go and new it.
[14:30] <Hobbsee> seb128: this is true.  which is why i was even considering it.
[14:31] <seb128> Hobbsee: you do it ;-)
[14:31] <Hobbsee> seb128: i'm unsure of whether i'd actually pick the required stuff to change, with a soname change though.
[14:31] <Hobbsee> geser: er, s/new/move/
[14:31] <pitti> Hobbsee: cannot override to universe using the web ui
[14:31] <pitti> s/://
[14:32] <seb128> Hobbsee: the soname change comes from Debian it should be alright, just new it
[14:32] <Hobbsee> right
[14:34] <geser> could someone NEW libdom4j-java (dom4j)? some builds are waiting for it
[14:34] <Kmos> the same for package mythbuntu-common :)
[14:36]  * Hobbsee does it then
[14:36]  * seb128 hugs Hobbsee
[14:39]  * Mithrandir kicks gnome-keyring-daemon
[14:40] <seb128> Mithrandir: hanging?
[14:40] <Mithrandir> seb128: overwriting SSH_AUTH_SOCK which breaks my ssh agent.
[14:41] <seb128> ah, right
[14:41] <seb128> there is a bug open about that
[14:41] <seb128> any reason you don't want to use the keyring agent?
[14:41] <Mithrandir> it doesn't talk to my smart card reader, I believe?
[14:42] <Mithrandir> if I can get it to do that, then that's fine.
[14:42] <Hobbsee> seb128: please shove mythbuntu-common back to universe
[14:44] <pitti> argh, f-spot-import doesn't even allow me to select a directory now, nor any layout
[14:44] <Hobbsee> or pitti, etc
[14:44] <Keybuk> pitti: if I want to get HAL to stop trying to automount a partition on a specific SD card (because it fails because it mounts the entire disk), I need a custom FDI for that, right?
[14:44] <seb128> Mithrandir: you can put your keyring on a stick yes
[14:44] <pitti> Keybuk: I'm afraid so, yes
[14:44] <Keybuk> pitti: where do they go?
[14:45] <Mithrandir> seb128: uh, no.  My key is on a smart card, similar to a banking card, it's not on a disk at all
[14:45] <pitti> Keybuk: you can add it to /etc/hal/fdi/policy/preferences.fdi
[14:45] <pitti> or create a new one in that dir
[14:45] <seb128> Mithrandir: ah, dunno about that
[14:45] <Keybuk> there's no ~/.config or anything?
[14:45] <pitti> Keybuk: there's an enabled example about not mounting internal drives; you need to match on a different property of course, such as a label or UUID
[14:46] <Mithrandir> seb128: so if it advertises PCSC support or something like that, there's a chance for it working, but otherwise, it probably won't work.
[14:46] <pitti> Keybuk: there could be something gconfish that gnome-mount reads (like in the volume/drive properties dialog), but there isn't ATM
[14:46] <Hobbsee> evand: if it was you who unmoderated the falcon stuff, be aware that it's already gone thru the motu list, and the motu-council list, and probably doesn't need to go thru -devel as well
[14:47] <Mithrandir> seb128: is upstream working on fixing the overwriting of the variable or would you accept a patch fixing it?  It should be simple (if (getenv("SSH_AUTH_SOCK" == NULL) { putenv(...);} )
[14:47] <seb128> Mithrandir: it's probably not, no, there is a gnome-keyring-daemon command line argument to not use the ssh-agent but since the code to launch it is hardcoded in gnome-session there is no way to use it at the moment
[14:47] <seb128> Mithrandir: they are working on it and it'll be fixed before hardy
[14:47] <evand> Hobbsee: ah damn, sorry about that
[14:48] <Mithrandir> seb128: ah, sounds good
[14:49] <evand> I'll be sure to reject future attempts to continue the discussion on ubuntu-devel, though.
[14:49] <Hobbsee> evand: no problem.  you don't read all lists :)
[14:53] <Hobbsee> newqueue--
[14:53] <Keybuk> pitti: do HAL matches automatically check the parent too?
[14:53] <Hobbsee> dholbach: is it worth rejecting falcon until you guys figure out your naming?
[14:54] <pitti> Keybuk: you have to explicitly match on it
[14:54] <dholbach> Hobbsee: reject what?
[14:54] <pitti> <match key="@storage.originating_device:@info.parent:usb_device.product" contains="Motorola Phone (V3i)">
[14:54] <Hobbsee> dholbach: falcon.  motu ML
[14:54] <pitti> for example
[14:54] <dholbach> Hobbsee: is there a falcon still in the queue?
[14:54] <Hobbsee> dholbach: yes
[14:54] <bigon> nobody for reviewing (and uploading) the patch in bug 182509 ?
[14:54] <ubotu> Launchpad bug 182509 in mono "Correctly install alternatives" [High,New] https://launchpad.net/bugs/182509
[14:54] <Hobbsee> dholbach: the repo creator
[14:55] <dholbach> Hobbsee: it's already in the archive, isn't it?
[14:55] <Hobbsee> dholbach: binary new
[14:55] <dholbach> Hobbsee: I really wished this would have been discussed with the archive admins before :-
[14:55] <dholbach> :-(
[14:55] <Hobbsee> yeah, well...
[14:55]  * Hobbsee notes that she's not on any archive admin list
[14:56] <dholbach> if the programming language could rename source and binary to falconpl and the other falcon (repo-package) would rename /usr/bin/falcon to something else, I feel we'd be all set
[14:56] <dholbach> soren proposed this solution
[14:57] <cjwatson> Hobbsee: you're not on ubuntu-archive@lists?
[14:57] <Hobbsee> cjwatson: it seems not.
[14:57] <Hobbsee> cjwatson: i looked thru it once, but never subscribed.
[14:57] <Hobbsee> it also occurs to me that we have no release team list
[14:57] <soren> dholbach: Er.. no.
[14:57] <soren> dholbach: I did not.
[14:57] <cjwatson> Hobbsee: we do as of quite recently; ubuntu-release@lists
[14:58] <Hobbsee> cjwatson: excellent.  looks like i have some subscribing to do then
[14:58] <soren> dholbach: I proposed leaving the programming language as /usr/bin/falcon and renaming the repository thing to something else.
[14:58] <cjwatson> though nobody's ever posted to it
[14:59] <dholbach> soren: right... and in another part of the thread the package name "falconpl" was discussed (as it's the name of the home page, etc) already
[14:59] <soren> dholbach: Yes, renaming the source package to falconpl seems completely sensible to me.
[14:59] <dholbach> both steps together seem to me to be a technical solution to the problem
[14:59] <_MMA_> https://lists.ubuntu.com/archives/ubuntu-motu/2008-January/003034.html
[15:00] <soren> _MMA_: Thanks :)
[15:00] <_MMA_> ;)
[15:00] <soren> dholbach: Oh... NOw I see, what you're saying.
[15:00] <dholbach> soren: does it make sense? :)
[15:00] <soren> dholbach: When you said source and binary, you meant "source package and binary package" and not "source package and the binary file".
[15:01] <dholbach> soren: yeah, sorry
[15:01] <soren> dholbach: ...with that in mind, yes, it makes perfect sense :)
[15:02] <dholbach> if we can all agree to doing that now and discuss things with archive admins earlier next time I feel it's all good - there should be no need for dispute because of this
[15:02] <soren> Agreed.
[15:06] <Hobbsee> cjwatson: right, now i have no excuse to be behind on things
[15:09] <Hobbsee> or at least, i don't after you approve that
[15:10] <Keybuk> aha! storage.no_partitions_hint, that sounds exactly like what I want :)
[15:11] <cjwatson> Hobbsee: done. er, twice, apparently
[15:11] <Hobbsee> cjwatson: yeah.
[15:11] <Hobbsee> cjwatson: there is a reason.
[15:12] <cjwatson> I'll take your word for it
[15:12] <Hobbsee> it's not a good one
[15:13] <pitti> Keybuk: btw, I tested f-spot now, reported some bugs about why it is not working at all for me, and updated https://wiki.ubuntu.com/DesktopTeam/Experiences/ManagingPhotos; I guess I can't convince you to rethink the switching of the default :), but you asked me a while back to update that page
[15:14] <Keybuk> pitti: your bugs are about people who already have photo collections though, right?
[15:14]  * pitti flips the default now, *shrug*
[15:14] <pitti> Keybuk: yes
[15:14] <Keybuk> so those people already have Ubuntu installations
[15:14] <Keybuk> the default only affects people with new installations, and assumedly, new photo collections
[15:14] <pitti> Keybuk: bug 182852 affects other people, too
[15:14] <ubotu> Launchpad bug 182852 in f-spot "photo directory should default to XDG user dir setting, not ~/Photos" [Low,Triaged] https://launchpad.net/bugs/182852
[15:14] <pitti> but at least that's a relatively easy one to fix
[15:15] <pitti> Keybuk: well, installing Ubuntu != using a computer the first time
[15:15] <seb128> pitti: you know about "f-spot -view directory" right?
[15:15] <Keybuk> pitti: sure, but usually after installing a new OS, you still need to import your photos again
[15:15] <pitti> seb128: no, I don't; I used View -> Arrange -> By directory, but that doesn't work
[15:16] <pitti> Keybuk: so far I didn't have to; in Windows, Debian, and Ubuntu I could just continue to use my existing collection on my /mm VFAT partition
[15:16] <pitti> Keybuk: well, I'm not saying that I'm the average user :)
[15:16] <seb128> pitti: you can continue doing that, browse with nautilus, double click and eog is used
[15:16] <Keybuk> you can still open those folders in nautilus to browse the thumbnails, and double-click on one to bring it up larger, and then use next/previous arrows to browse the collection
[15:16] <pitti> it just feels weird to me to copy the entire photo collection again, and edit that, and suddenly find that your original photos haven't been changed
[15:17] <seb128> pitti: I'm not sure what else you need to browse your collections
[15:17] <pitti> seb128: right, I should try that
[15:17] <seb128> pitti: that's like you don't start rhythmbox to listed to a file on your desktop, you double click on it and totem is used
[15:18] <pitti> seb128: I see, that works; I wonder why it doesn't work when I select it in the UI
[15:19] <seb128> right, it's broken here as well
[15:19] <pitti> seb128: nautilus> that only gives me a single picture, though, no prev/next
[15:19] <pitti> (or 'parent', etc.)
[15:19] <pitti> so, viewing works fine
[15:19] <pitti> browsing only when called on CLI
[15:20] <pitti> and no directory navigation whatsoever
[15:20] <seb128> pitti: press F9
[15:20] <pitti> well, that could be left to eog, I figure
[15:20] <pitti> seb128: got that, but it only has a single photo
[15:20] <seb128> right
[15:21] <seb128> not sure what is your standard usecase
[15:21] <seb128> I've those scenario
[15:21] <seb128> - plug an usb key with some photo to show those, nautilus is open, I double click on the first one and click on next in eog to show the photos
[15:22] <pitti> seb128: use case: "parents come in, I want to show them some of my photos" :)
[15:22] <seb128> - want to browse my photo collection and do some changes, I start fspot
[15:22] <pitti> seb128: right, eog is great, no complaints there
[15:22] <pitti> I just thought we wanted to consolidate to use just one photo app for everything
[15:22] <Keybuk> pitti: we're not getting rid of nautilus/eog
[15:22] <seb128> as said before that's like trying to use rhythmbox to listed to a sound file from an usb key
[15:22] <pitti> well, except that eog and f-spot are totally incompatible wrt. browsing, file locations, UI, etc.
[15:23] <seb128> my understanding is that we want to keep eog as a viewer and fspot to manage a photo collection
[15:23] <Keybuk> why incompatible?
[15:23] <Keybuk> I can browse the f-spot managed folders in nautilus and use eog on the files :)
[15:23] <pitti> f-spot is 'object'-based, while eog/nautilus are file-based
[15:23] <pitti> Keybuk: c'mon, you'll never find the one you are looking for in nautilus
[15:23] <Keybuk> I don't know what you mean by "object" based here
[15:23] <seb128> well, the issue is that f-spot should work from a directory library
[15:23] <seb128> like rhythmbox do
[15:23] <pitti> I see the idea of f-spot about abstracting away from files
[15:23] <seb128> rather than reimporting everything
[15:23] <pitti> just like rb abstracts away from files, too
[15:23] <Keybuk> seb128: it does?
[15:24] <seb128> Keybuk: no it doesn't
[15:24] <Keybuk> like rb, it just has an index file of that directory
[15:24] <pitti> but unlike RB, f-spot owns my photos, while rb just creates an index from my music
[15:24] <seb128> Keybuk: it creates this layout using directory by year, etc and copy photos there
[15:24] <pitti> so I can still keep my existing music colletion without rearranging everything
[15:24] <pitti> I think RB got the concept really well (I love it)
[15:24] <Keybuk> pitti: rb owns it too
[15:24] <Keybuk> I have to import the music into my library
[15:25] <Keybuk> and then it makes up filenames, etc. under that library
[15:25] <pitti> Keybuk: but it's not requiring the files to be in any particular directory and layout
[15:25] <seb128> Keybuk: rb monitors a directory on the disk without touching the files
[15:25] <Keybuk> (arguably they should both just use tracker <g>)
[15:25] <pitti> f-spot copies them around and hides them with unintelligible names and directories instead of leaving them alone wherever they are
[15:25] <Hobbsee> Keybuk: you're just asking to be clubbed in the head.
[15:25] <pitti> which is ok if you never use anything else than f-spot
[15:26] <Keybuk> Hobbsee: I'm entirely serious
[15:26] <seb128> let's not start on the tracker discussion now
[15:26] <Keybuk> if they both used tracker, it wouldn't matter where the photos/music were, what filenames, etc.
[15:26] <seb128> it's not going to happen for hardy
[15:26] <pitti> Keybuk: object-based> abstracting away from the close-to-the-metal files and directories
[15:26] <Keybuk> pitti: this is a good thing, no?
[15:26] <Hobbsee> Keybuk: if tracker wasn't such a performance hit, etc, then sure.
[15:26] <pitti> Keybuk: by itself, yes
[15:27] <seb128> Keybuk: the thing is that f-spot should monitor a directory you give him without touching anything there, like rhythmbox do, it doesn't right now though
[15:27] <pitti> Keybuk: but the rest of our desktop, including nautilus, is still by and large file/directory based
[15:27] <pitti> so it's confusing once you leave the domain of f-spot
[15:27] <Keybuk> seb128: how do you make rhythmbox do that?
[15:27] <pitti> Keybuk: import directory/file, done
[15:27] <seb128> Keybuk: I don't import music using rhythmbox
[15:27] <pitti> there's nothing else
[15:27] <Keybuk> seb128: cause I can't
[15:27] <pitti> Keybuk: RB just creates an index
[15:28] <Keybuk> pitti: of it's own directory
[15:28] <seb128> Keybuk: by default it monitors Music, copy any song there, watch inotify notice it and rhythmbox list it
[15:28] <Keybuk> not any others
[15:28] <Keybuk> if you import any others, it copies them into its own directory
[15:28] <pitti> ~/.gnome2/rhythmbox/rhythmdb.xml
[15:28] <Keybuk> seb128: right, but isn't that just what f-spot does with ~/Photos ?
[15:28] <pitti> Keybuk: how do you mean? ("own directory")
[15:28] <seb128> Keybuk: well, there is no way to tell to f-spot "use that directory", it wants to create its own layout and import everything
[15:28] <pitti> Keybuk: you can add arbitrary directories to RB's collection
[15:28] <Keybuk> seb128: it's in Preferences
[15:28] <seb128> or I don't know how
[15:28]  * seb128 tries
[15:28] <Keybuk> pitti: yes, and it copies them into ~/Music
[15:29] <Keybuk> organising them itself
[15:29] <pitti> Keybuk: no, not for me
[15:29] <Amaranth> since when did rhythmbox do that?
[15:29] <Amaranth> i wish it did that
[15:29] <seb128> Amaranth: do what?
[15:29] <Keybuk> it's entirely possible I'm wrong, but I've always found rb very difficult to use because of the way its library works
[15:30] <Amaranth> move music to ~/Music and organize it automatically
[15:30] <seb128> Keybuk: it doesn't do anything, it just list everything which is in the directory he has been pointed to
[15:30] <pitti> Keybuk: hm; I love how it works; seems people do have different ideas how to organize stuff :)
[15:30] <seb128> which means you can download things directly there
[15:30] <seb128> create directories as you like
[15:30] <seb128> etc
[15:30] <seb128> let sound-juicer create albums
[15:30] <Keybuk> ok
[15:31] <Keybuk> in f-spot I just did
[15:31] <Keybuk> 1) made a tree of photos under ~/My Photos
[15:31] <Keybuk> 2) opened f-spot
[15:31] <Keybuk> 3) unchecked "Copy into Photos directory"
[15:31] <Keybuk> 4) selected ~/My Photos
[15:31] <Keybuk> 5) clicked Import
[15:31] <Keybuk> now my photos appear in f-spot
[15:31] <Keybuk> with the original filenames and tree
[15:31] <pitti> just tried it in RB and confirmed that it doesn't copy a foreign directory; it just indexes it
[15:32] <pitti> and notices that stuff has gone from it, etc.
[15:32] <Keybuk> pitti: with Music -> Import Folder ?
[15:32] <pitti> Keybuk: yes
[15:32] <pitti> Keybuk: that checkbox for f-spot doesn't exist in the import dialog
[15:32] <pitti> Keybuk: the camera one, I mean (f-spot-import)
[15:32] <Keybuk> ?!
[15:33] <pitti> f-spot-import is the program I'll set in gnome-volume-manager
[15:33] <pitti> as reaction to plugging in a photo cam
[15:33] <Keybuk> http://people.ubuntu.com/~scott/Screenshot-Import.png
[15:33] <Keybuk> it's the first one
[15:34] <Keybuk> right, but that's now what you're talking about
[15:34] <Keybuk> you have an existing photo collection you want f-spot to look at without rearranging it
[15:34] <Keybuk> adding new photos, why not let f-spot name them?
[15:34] <pitti> and obeying my existing structure when importing new ones, too, of course
[15:34] <Keybuk> how's it supposed to divine your existing structure? :p
[15:34] <pitti> Keybuk: because I still want to be able to find them without f-spot :)
[15:35] <Keybuk> ~/Photos/Auntie Maud/Birthday/eating cake.jpg
[15:35] <tjaalton> is it the libnss-db update that makes ssh output "/var/lib/misc/services.db: No such file or directory"?
[15:35] <Keybuk> it sounds like you just don't want f-spot
[15:35] <tjaalton> I'm getting that a lot
[15:35] <pitti> Keybuk: just giving me the ability to download them into a particular directory would be enough
[15:35] <Keybuk> and want to just continue making directories and managing them that way
[15:35] <pitti> right, because it's compatible with the rest of the world
[15:35] <pitti> as I said, f-spot makes sense if you use it and only it
[15:35] <Keybuk> so just click "Open Folder" instead of "Import" ?
[15:36] <pitti> but as soon as you start swapping photos with other people, the object-based approach gets in your wya
[15:36] <Keybuk> I don't see how
[15:36] <Keybuk> I find it *so* much easier to find photos in f-spot
[15:36] <pitti> I think it could be as easy as allowing me to select a target directory in f-spot-import
[15:36]  * Keybuk double clicks on the "pitti" tag
[15:37] <pitti> Keybuk: i'm lost there, since I don't have a spare month to tag all my photos
[15:37] <Keybuk> my albums were originally in the folder-per-album format
[15:37] <Keybuk> so I just imported them one at a time, with a tag as I did it
[15:37] <seb128> Keybuk: does f-spot monitors the directory for you?
[15:37] <Keybuk> seb128: no idea on that one
[15:38] <Keybuk> it should, obviously
[15:38] <seb128> Keybuk: if I copy a new directory with photos in the library there it's not picked by fspot
[15:38] <seb128> library = the photo directory
[15:38] <Keybuk> seb128: then it doesn't
[15:38] <seb128> neither after a restart
[15:38] <seb128> which means it expect you do get everything imported from the f-spot interface
[15:38] <Keybuk> that doesn't surprise me
[15:40] <seb128> well, that's my main issue with it
[15:40] <seb128> it forces you to import your collection
[15:40] <seb128> rather that taking a directory as rhythmbox do and inotify it
[15:40] <Keybuk> sure
[15:41] <Keybuk> as I've said before, I think both should just use tracker and not try and have their own magic directories
[15:41] <Keybuk> that's just obvious
[15:41] <pitti> Keybuk, seb128: AFAIR, seed changes were: -serpentine, +brasero, -gthumb, change g-v-m photo import to f-spot-import, right?
[15:42] <Keybuk> rb already has a tracker plugin now, right?
[15:42] <seb128> not that I know
[15:42] <seb128> pitti: -gnome-btdownload +transmission-gtk
[15:42] <pitti> seb128: ah, thanks
[15:43] <pitti> oh, transmission is universe
[15:43] <pitti> seb128: we can demote gnome-btdownload then, right?
[15:43] <seb128> pitti: +vinagre (-xvncviewer)?
[15:43] <seb128> pitti: afaik yes
[15:44] <Keybuk> pitti: hmm, any time I have the match file in, HAL ignores my device entirely! :-(
[15:44] <pitti> Keybuk: what did you set, storage.automount_enabled_hint=False?
[15:45] <pitti> seb128: xvncviewer is already in universe
[15:45] <Keybuk> pitti: storage.no_partitions_hint = true
[15:45] <pitti> seb128: you mean remove tsclient?
[15:45] <pitti> Keybuk: for suppressing automount?
[15:46] <pitti> oh, I remember
[15:46] <pitti> you want to work around that raw device *and* first partition bug
[15:46] <Keybuk> pitti: right
[15:46] <seb128> pitti: no, maybe nothing to remove there then, didn't we have a vnc client in the default installation?
[15:46] <pitti> seb128: I thought tsclient coudl do vnc? at least it says so in the selector
[15:46] <pitti>  tsclient also supports:
[15:46] <pitti>    * VNC clients (*vncviewer)
[15:47] <Keybuk> pitti: it doesn't seem to matter what I set
[15:47] <seb128> pitti: right, I though it was using a vnc viewer though
[15:47] <pitti> Suggests: vnc-viewer
[15:47] <pitti> ah
[15:47] <Keybuk> the minute I set *anything*, HAL starts ignoring the card altoghet
[15:47] <pitti> seb128: so yeah, seems we don't install any by default ATM
[15:47] <seb128> desktop: * xvnc4viewer      # needed by tsclient
[15:47] <seb128> in gutsy
[15:47] <seb128> did we change that?
[15:47] <pitti> seb128: ah, '4'
[15:47] <pitti> seb128: I checked xvncviewer
[15:47] <pitti> seb128: alrighty
[15:48] <seb128> me too, I just grepped the seed to look what vnc client we had
[15:49] <pitti> seb128: we can't drop sound-juicer yet, can we? or should we move that to rb?
[15:49] <Keybuk> pitti: sound juicer is the only decent ripper/player right now, no?
[15:49] <seb128> no we can't
[15:49] <pitti> right, that's what I thought
[15:50] <_MMA_> Keybuk: Grip and abcde. ;)
[15:50] <seb128> the rhythmbox UI is too confusing and has no proper preferences to set the format of the directories to use, etc
[15:50] <seb128> we could change the CD playing command to "rhyhmbox device" though
[15:50] <seb128> that works nowadays
[15:51] <pitti> seb128: right, would be nice to have the CD as just another music source in the left bar
[15:51] <seb128> pitti: that's the case
[15:52] <seb128> pitti: and "rhythmbox device" switch to the source and start playing nowadays
[15:52] <pitti> hmm; I should have kept one audio CD in my desk for testing; I banned them all into the attic months ago
[15:55] <SWAT> I'm using gnome-main-menu and when I click on it (I have two of them, dualscreen, seperate x session setup) on my 2nd screen, it opens on my 1st screen. Is this a Gnome or rather an X.org issue?
[15:56] <pitti> mvo: will update-manager install new *-desktop Recommends: by default? i. e. if I add seeds as recommends to the metapacakges, will that actually have an effect on upgrades?
[15:56] <Amaranth> SWAT: #ubuntu
[15:57] <Hobbsee> pitti: it hasn't previously, afaik
[15:58] <seb128> SWAT: a gnome-main-menu one
[15:59] <pitti> ogra, cjwatson: hm, ltsp-client-builder went into the ubuntu installer seed recently; is that supposed to be merged to {go,e,k,x}ubuntu as well?
[16:02] <Hobbsee> cjwatson: when will the new seeds stuff happen?
[16:05] <Riddell> pitti: I just merged it to kubuntu
[16:09] <pitti> Riddell: ah, you just merged seeds? thanks, one merge less :
[16:09] <pitti> )
[16:10] <Keybuk> pitti: how do you test new FDI rules?
[16:11] <pitti> Keybuk: mostly they Just Work (TM) after replugging
[16:11] <pitti> but you might be required to restart hal
[16:11] <Keybuk> they're never working for me
[16:11] <pitti> Keybuk: anyway, you should be able to see the changed properties in lshal
[16:11] <Keybuk> in fact, the device entirely disappears from HAL if the rules aren't commented out
[16:11] <pitti> hm; sounds like they have a syntax error or so?
[16:12] <Keybuk> how would I know?
[16:12] <pitti> Keybuk: you can run hal in debugging mode
[16:12] <pitti> sudo killall hald
[16:12] <pitti> sudo hald --verbose=yes --daemon=no
[16:12] <pitti> then let it settle, then insert the device
[16:12] <pitti> FDI errors usually appear there
[16:13] <Keybuk> ok
[16:15] <Keybuk> restarting hal breaks gnome-volume-manager, right?
[16:15] <pitti> no, it shouldn't
[16:15] <pitti> just restarting dbus will
[16:16] <pitti> ok, all seeds changed; now I wait for the publisher to get my promotions committed, then I can rebuild *-meta
[16:17] <Hobbsee> pitti: can you demote mythbuntu-common binary to universe please?
[16:17] <pitti> Hobbsee: done
[16:17] <Keybuk> pitti: http://rafb.net/p/SGOWib17.html
[16:18] <Hobbsee> pitti: thanks muchly.
[16:18] <seb128> pitti: do you have any idea who cups would not be able to listen on 631 when nothing else is using it according to netcat?
[16:19] <seb128> pitti: we are discussing bug #135832 on #ubuntu-bugs
[16:19] <ubotu> Launchpad bug 135832 in gtk+2.0 "evince: libgtkprint support is broken" [Low,New] https://launchpad.net/bugs/135832
[16:19] <seb128> the cups error log has "E [14/Jan/2008:16:58:50 +0100] Unable to bind socket for address 127.0.0.1:631 - Cannot assign requested address."
[16:20] <pitti> ugh, no idea; is that gutsy?
[16:20] <seb128> that's stock gutsy alternate install
[16:20] <seb128> could apparmor do something like that?
[16:20] <pitti> Keybuk: "parent_bus is NULL - wrong parent?
[16:20] <pitti> "
[16:20] <pitti> ugh
[16:21] <pitti> Keybuk: I have no off-hand idea about that one, I'm afraid; that looks like a genuine bug
[16:26] <Keybuk> pitti: how do I stop it auto-mounting just one partition btw?
[16:26] <pitti> Keybuk: you can set volume.ignore=True
[16:26] <Keybuk> ah, do I <merge> that?
[16:27] <Keybuk> (there's not a volume.ignore in the usual list)
[16:27] <pitti> that will not display that partition anywhere (which is what you want, I think)
[16:27] <pitti> Keybuk: yes
[16:27] <Keybuk> yeah
[16:27] <\sh> moins
[16:27] <Keybuk> the GPS formats the SD card verrry weirdly
[16:27] <Keybuk> weird enough to make the disk itself look like a FAT volume
[16:27] <Keybuk> and with three illegal entries in the partition tables
[16:27] <Keybuk> need it to just mount p1 and ignore everything else
[16:28] <Keybuk> how do I anti-match?
[16:33] <ogra> pitti, xubuntu has ltsp already, edubuntu will go away and kubuntu is up to Riddell
[16:33] <pitti> ogra: I just merged it to xubuntu
[16:33] <ogra> they have a dedicated ltsp seed
[16:34] <ogra> the same as edubuntu
[16:34] <ogra> (not sure if that was dropped in gutsy though, i had no test reports for it)
[16:35] <Keybuk> pitti: got it working now :-)  thanks for the help
[16:35] <pitti> Keybuk: ah, good; I'm still looking for an URL to the hal spec
[16:35] <Keybuk> I just started reading others and worked it out from there
[16:36] <ogra> is anyone working on the fspot breakage ?
[16:37] <pitti> ogra: yes, I just made the breakage the default now :-P
[16:37] <pitti> ogra: seriously, what do you mean?
[16:37] <ogra> there is a broken dep
[16:37] <ogra> it breakes the dailies
[16:37] <ogra> libflickrnet2.1.5-cil ....
[16:38] <ogra> i had to remove it today to make my dist-upgrade finish ...
[16:38] <ogra> Richte libflickrnet2.1.5-cil ein (25277-6) ...
[16:38] <ogra> * Installing 1 assembly from libflickrnet2.1.5-cil into Mono
[16:38] <ogra> ! Assembly /usr/share/cli-common/policies.d/libflickrnet2.1.5-cil/policy.2.1.FlickrNet.dll does not exist
[16:38] <ogra> dpkg: Fehler beim Bearbeiten von libflickrnet2.1.5-cil (--configure):
[16:38] <ogra>  Unterprozess post-installation script gab den Fehlerwert 1 zurück
[16:38] <pitti> ah
[16:39] <Hobbsee> ogra: known, bigon's been asking for a sponsorship of that
[16:39] <ogra> ah, good
[16:39] <seb128> ogra: apparently nobody did sponsor the upload though
[16:39]  * ogra would love installable dailies to test the ltsp changes ...
[16:39] <seb128> ogra: sponsor the update? ;-)
[16:40] <ogra> bug # ?
[16:40] <calc> if i already have 4GB of ram on i386 does having swap make any difference (iow can linux address the swap as well)?
[16:40] <Hobbsee> ogra: [01:54] <ubotu> Launchpad bug 182509 in mono "Correctly install alternatives" [High,New] https://launchpad.net/bugs/182509
[16:40] <ubotu> Launchpad bug 182509 in mono "Correctly install alternatives" [High,New] https://launchpad.net/bugs/182509
[16:40] <ubotu> Launchpad bug 182509 in mono "Correctly install alternatives" [High,New]
[16:40] <mjg59> calc: Yes, Linux can address the swap
[16:40] <calc> ok
[16:41] <calc> mjg59: thanks for the help :)
[16:41]  * ogra hugs Hobbsee 
[16:41]  * Hobbsee hugs ogra back ;)
[16:49] <Amaranth> mjg59: What was the bit you were talking about with 0x80 io port and random lockups?
[16:49] <Amaranth> in your blog
[16:49] <mjg59> Amaranth: In what way?
[16:51] <Amaranth> mjg59: You said HP laptops had this problem, was just wondering what that was
[16:51] <Amaranth> I'd love to blame my random lockups on something other than nvidia+compiz ;)
[16:51] <mjg59> Oh - Linux uses port 0x80 to delay certain io writes, on the assumption that there'll be nothing there and it'll trigger a bus abort
[16:52] <mjg59> Some HP systems (mostly the dv6xxx series) have a piece of hardware there
[16:52] <Amaranth> ah
[16:52] <mjg59> Which then becomes upset if it's fed a large number of writes
[16:52] <Amaranth> So I probably don't have that problem, I've got a dv8000
[16:53] <mjg59> Could still be the case
[16:53] <mjg59> You can hack the kernel to use 0xed instead
[16:53] <Amaranth> Well, what are the symptoms? Other than "random lockups"
[16:54] <Amaranth> Is there something that will trigger it easily?
[16:54] <mjg59> A tight loop reading from /dev/nvram
[16:54] <Amaranth> I don't have /dev/nvram :)
[16:54]  * pitti blinks; https://code.edge.launchpad.net/python-distutils-extra -> the autogenerated header really says "distuils" (note the missing "t"); how can that happen?
[16:55] <mjg59> modprobe nvram
[16:55] <Keybuk> pitti: did the libpam-foreground problem get fixed?
[16:56] <pitti> Keybuk: you mean problem == it exists?
[16:56] <pitti> Keybuk: I ported dbus over to consolekit yesterday, yes
[16:56] <pitti> or rather, I taught CK how to create libpam_console compatible tag files and dbus to use them
[16:56] <pitti> thus libpam-foreground is in universe now
[16:56] <mjg59> pitti: Sweet
[16:56] <Keybuk> ah, cool
[16:57] <mjg59> I'm glad that's going away
[16:57] <Keybuk> apt wanted to remove it
[16:57] <pitti> I hope the CK upstream will accept the patch
[16:57] <Seveas> pitti, I don't see "disutils" anywhere
[16:57] <pitti> but oh well, eventually we'll get rid of "at_console" dbus policies, I guess
[16:57] <pitti> Seveas: distuils
[16:58] <Seveas> pitti, but you said you saw the text disutils :)
[16:58] <pitti> Seveas: no, I didn't
[16:58] <pitti> but it seems it's not just me and LP who is confsued abotu speling :)
[16:58] <\sh> mvo, ping cdrkit, will you add some Provides: and some symlinks to the cdrtools binary app names, as discusson on u-d-d, or should I change the package and provide u-m-s with a debdiff?
[16:59] <Seveas> pitti, hmm, the t shifted in my head :)
[16:59] <pitti> Seveas: you clearly drink the wrong kind of tea
[16:59] <Amaranth> mjg59: ok i guess i don't have that problem then
[16:59] <Seveas> actually, I drank coffee today for the first time since months
[16:59] <Seveas> must be it :)
[17:00]  * soren is about to upload a new dpkg and sweats uncontrollably
[17:00]  * Amaranth remembers not to update
[17:00] <\sh> soren, go go go :)
[17:00] <mvo> \sh: a debdiff would be nice, not sure if I manage to look at it today
[17:01] <Amaranth> Ah, so I guess I shouldn't start transitioning things to cdrkit?
[17:01] <cjwatson> pitti: a project's ID isn't necessarily identical to its display name
[17:01] <cjwatson> the latter is probably misspelled
[17:02] <pitti> aah
[17:02] <\sh> mvo, ok..I'll create one (hopefully this evening) just to be sure that we don't have any broken packages in our archives :)
[17:02] <\sh> Amaranth, nope...no need, when we add some symlinks and provides to cdrkit ...
[17:02] <mvo> \sh:  thanks
[17:02] <Amaranth> ok, i already did lsongs
[17:03] <Amaranth> Guess I should switch that back. Although I'll probably wait for a new upstream release
[17:03] <mvo> pitti: update-manager should install new recommends to u-desktop (or any package in "metapackages") automatically. if not that is a bug
[17:03] <pitti> mvo: splendid, thanks
[17:03] <\sh> Amaranth, just wait for the new paclage to arrive :) first I need to check galculator and then cdrkit :)
[17:04] <glatzor> bryce: hello
[17:04] <soren> Here goes nothing..
[17:05] <Amaranth> \sh: I already uploaded it along with a bunch of changes from the new upstream :P
[17:06] <Amaranth> But the upstream situation there is kind of confused so I've got some time :)
[17:08] <Keybuk> soren: but it's the wrong day for dpkg uploads
[17:08] <Keybuk> dpkg should always be uploaded on friday, just before you get on a plane
[17:09] <pitti> (don't forget: right before the beta release)
[17:10] <Keybuk> beta?
[17:10] <Keybuk> final!
[17:11] <soren> Keybuk: I'll remember that the next time. :)
[17:39] <_MMA_> seb128: So I have a clean install of Ubuntu Studio here. We switched to PA like ubuntu. Testing the sound through the "Sound Preferences" dialog works but playing the sounds themselves on the "Sounds" tab does not. Playing the files directly with Totem works fine. I get nothing on startup/down either.
[17:39] <seb128> _MMA_: could you open a bug on launchpad, I'll have a look later
[17:39] <_MMA_> np
[17:40] <_MMA_> Ill test another install of Ubutnu as well.
[17:42] <pitti> Keybuk: for the record, default apps changes are now done
[17:44] <keescook> can an archive admin sync "hardening-wrapper" from Debian?  (and then shove it through NEW?)
[17:45] <Keybuk> pitti: cool, thanks!
[17:49] <pitti> doko: gdb merge> BTW, b-dep'ing on type-handling is ok now, it's in main and harmless
[17:50] <doko> pitti: who did let it in?
[17:50] <pitti> doko: me
[17:50] <doko> elmo: ^^^ ;-p
[17:50] <pitti> doko: it's just some collection of Provides: nowadays, nothing bad
[17:50] <pitti> no more control rewriting or other insanities
[17:51]  * keescook <3 linux-image-2.6.24-4-generic
[17:51] <Kmos> pitti: how about to demote tuxtype package to universe. it needs libsdl-pango-dev.
[17:55] <Kmos> and also demote planner package to universe. it needs libgda2-dev
[17:57] <pitti> Kmos: that's for ogra to decide; it's seeded in edubuntu
[17:58] <Kmos> ogra: ping
[17:58] <pitti> keescook: what's new in linux?
[17:58] <Kmos> :)
[17:58] <Kmos> pitti: the planner also seeded ?
[17:59] <keescook> pitti: ASLR of text.  :)
[17:59] <pitti> keescook: w00t
[18:00] <calc> how do you determine the uuid for a fs?
[18:00] <superm1> pitti, there are two uploads for mpeg4ip.  after discussing with jdong a little, you can reject the one without dfsg in the title right off the bat.  it was repacked and the license improved on the second.
[18:00] <geser> Kmos: what about check if planner builds with libgda3-dev which is in main?
[18:00] <pitti> keescook: hardening-wrapper synced/NEWed
[18:00] <pitti> calc: vol_id /dev/foo
[18:01] <keescook> pitti: great! thanks.  :)
[18:01] <keescook> pitti: aslr> http://paste.ubuntu-nl.org/51907/
[18:01] <calc> pitti: thanks :)
[18:01] <pitti> superm1: done
[18:01] <superm1> thanks pitti
[18:02] <jdong> superm1: I passed our agreed debian/copyright and a heads-up about repacking to Christian... I feel sorry for how much spam he's gotten from us two!
[18:02] <superm1> jdong, :)
[18:02] <pitti> Kmos: yes, but to supported only, and no reverse depends in main
[18:02] <Kmos> geser: that's a good idea :) thanks
[18:02] <superm1> jdong, if we convince him to build depend on the libavcodeccvs | libavcodec  etc, we might be able to get it to the point that we can just sync in the future :)
[18:03] <Kmos> pitti: we need to check first if it builds fine with libgda3-dev, thanks
[18:06] <jdong> superm1: that all depends on if we can get the guy to agree to repacking. My gut feeling is that he could care less about the issue and would rather have the convenience of directly pulling upstream tarballs
[18:17] <superm1> jdong, could always write a get-orig-source that does this for debian/rules
[18:18] <superm1> i've done that in the past for repacked tarballs that i didn't want to have to deal with having to do manually every time
[18:21] <\sh>  mvo bug #182934
[18:21] <ubotu> Launchpad bug 182934 in cdrkit "cdrkit update for cdrtools removal" [Undecided,New] https://launchpad.net/bugs/182934
[18:21] <Mithrandir> calc: what's up with ooo ftbfs-ing on amd64?
[18:24] <calc> Mithrandir: it appears gcj uses huge amounts of ram (< 2GB though) and causes it to fail on the buildd
[18:24] <calc> Mithrandir: it works fine on my home pc that isn't doing other things with 2GB ram available
[18:25] <calc> Mithrandir: gcj fails for what looks like the same reason on lpia (runs out of memory)
[18:25] <Mithrandir> calc: why do you think it runs out of memory?
[18:26] <keescook> doko: libxml2 on hardy FTBFS for some not-obvious-to-me reason
[18:26] <calc> it says it does on lpia and the type of fault someone mentioned isn't normal and was likely due to memory on amd64 as well (i don't recall who mentioned that)
[18:26] <calc> Mithrandir: and it builds fine with same source on my amd64 box
[18:28]  * calc looks at the amd64 build log again
[18:29] <calc> Mithrandir: the ppc failure is easy to fix, the sparc failure i am not sure about it seems to nearly always ICE on sparc
[18:30] <calc> oh yea the other thing about amd64/lpia build is it fails in the same spot on both, lpia runs out of ram and amd64 ICEs (well the first time) looks like it retried and just timed out the last time
[18:31] <bryce> heya glatzor, how goes?
[18:31] <calc> the previous build failure for amd64 on that code was an ICE of some sort
[18:33] <glatzor> bryce: looking at the new xorg.conf style not so well :)
[18:34] <Mithrandir> calc: the amd64 is it timing out, not ICE-ing, which is why I'm asking about why you think running out of memory has anything to do with it.
[18:38] <calc> Mithrandir: that is the second failure on the same upload
[18:38] <calc> Mithrandir: the first time it ICEd the second time it timed out
[18:38] <calc> Mithrandir: both failures are in the same spot that on lpia it ran out of memory
[18:39] <calc> and i was able to build it fine on my amd64 with the same upload that failed twice on the amd64 buildds
[18:39] <calc> amd64 is my local arch i build on before uploading
[18:39] <Mithrandir> using sbuild?
[18:39] <calc> /usr/bin/gcj-4.2 -c -g -O2 -fPIC -findirect-dispatch -fjni unoil.jar.1.jar -o unoil.jar.1.o
[18:39] <calc> jc1: out of memory allocating 4064 bytes after a total of 934146048 bytes
[18:40] <calc> Mithrandir: not using sbuild but a clean chroot that is generated for each new upload
[18:40] <calc> Mithrandir: and this type of problem has been around for a while with gcj, i just need to talk to doko about it when he is back (if he is back from vacation yet)
[18:40] <calc> doko: ping
[18:41] <Mithrandir> he was around earlier today
[18:41] <calc> oh ok
[18:42] <doko> calc: around (still in vacation). please check with gcj-4.3 from the ubuntu-toolchain ppa (and/or send me the unoil.jar.1.jar file)
[18:42] <bryce> glatzor: yes most  of xorg.conf is gone now
[18:42] <calc> doko: ok i can send you the jar file it builds fine for me on amd64 already so i doubt my testing of gcj-4.3 would show much
[18:43] <calc> doko: i think i cleaned out the build already but i will regenerate it and copy the file out
[18:44] <calc> doko: how is the progress of icedtea coming?
[18:45] <bryce> glatzor: perhaps we ought to re-look at how we do GUI xorg configuration
[18:45] <bryce> glatzor: I suspect the way xorg.conf is going, it may be invalidating some of displayconfig-gtk's core assumptions
[18:46] <glatzor> bryce: indeed.
[18:46] <glatzor> bryce: perhaps we could talk about this tomorrow
[18:50] <bryce> glatzor: sounds good
[18:51] <superm1> bryce, is there a proper way to query drivers in use and such when they aren't explicitly listed in xorg.conf then?
[18:52] <slangasek> Mithrandir: I've never heard of anything being done with Kerberos and mDNS, no.  you can put .local names /in/ Kerberos as principals, but.
[18:53] <bryce> superm1: the only authoritative way is to parse from Xorg.0.log
[18:53] <superm1> whew yuck.
[18:53] <bryce> superm1: yeah I know
[18:53] <superm1> especially if you end up starting on a different display
[18:54] <superm1> i'm surprised there are no bindings out there to query the x server and ask such things
[18:54] <bryce> in my dreams where I have ample extra time, I fantasize about adding an API to X for querying these sorts of things
[18:54] <bryce> I've dug through the source code and there aren't even hooks to do it though - it'd be a significant infrastructure task
[18:55] <bryce> yeah, you'd think xrandr or xdpyinfo would have something like that
[18:56] <bryce> but no, you'd need to build up an API call in the X server, and probably have to extend the X protocol (dunno what's involved there), then add the calls to whatever X clients need it
[18:57] <bryce> I talked with a couple people at XDC about it, but they didn't see the use of exposing this info to users.  Their opinion was that xserver should autoconfigure itself, and so that info shouldn't be needed at all.
[18:57] <bryce> so I just nodded and walked away slowly.
[18:57] <superm1> how very unfortunate.
[18:58] <superm1> maybe a good proposal for a google summer of code project this next summer
[18:58] <bryce> well, I think they'd be open to being sent a patch, but it didn't sound like it'd be anywhere on their radar
[18:58] <superm1> considering the amount of work that will be necessary
[18:58] <bryce> oh yeah, that could be
[18:58] <bdmurray> Riddell: I'm looking at the SRU verification for bug 162233 and I'm not certain how long of a username I need to recreate the bug.
[18:58] <ubotu> Launchpad bug 162233 in kdelibs "KIO FTP is shortening the URL" [Undecided,Fix committed] https://launchpad.net/bugs/162233
[18:58] <Keybuk> call it the XWTF extension
[18:59] <bryce> Keybuk: :-)
[19:02] <Kmos> slangasek: please accept (dom4j) package in NEW.
[19:06] <Amaranth> superm1: our compiz shell script does this
[19:06] <Amaranth> superm1: you can discover the log used for the server you're running on so that's no problem
[19:06] <Riddell> bdmurray: I don't know the exact length I'm afraid, it might even be dependent on the width of your location text field
[19:07] <bdmurray> Riddell: hmm, I'll experiment a bit more then
[19:09] <slangasek> Kmos: all in good time
[19:09] <Kmos> slangasek: ok =) thx
[19:13] <Riddell> bdmurray: it might get truncated in the popup username/password dialogue, so try entering an ftp url without a username or password and having a small window there
[19:44] <nxvl_work> i need a given back for bioperl
[19:44] <nxvl_work> can someone?
[19:47] <Mithrandir> nxvl_work: given-back
[19:48] <nxvl_work> Mithrandir: that
[19:48] <nxvl_work> :P
[19:53] <calc> yea compiling unoil.jar.1.jar even on my system is a bear, it makes it nearly unnresponsinve
[19:54] <geser> nxvl_work: a rebuild won't help for bioperl until bug #178536 gets fixed
[19:54] <ubotu> Launchpad bug 178536 in sbuild "Preinstalled Build-Depends not properly detected" [Undecided,New] https://launchpad.net/bugs/178536
[19:55] <nxvl_work> geser: here it builds on hardy
[20:05] <calc> Mithrandir: so it works on my box but uses so much ram/swap that i could easily see why it times out on the buildd
[20:05] <calc> Mithrandir: i can't get any other apps to respond while it is compiling that bit of code
[20:30] <geser> nxvl_work: it's a bug in sbuild used on the buildds
[20:44] <choudesh> I need a bit of help here. I am customizing the liveCD, trying to add the dist/pool folders. It seems when I add these folders, sqaushfs just hangs on boot up
[21:14] <Ng> mjg59: any idea how much the pm-utils quirks are likely to vary over the various X40 models? I noticed the hal fdi file matches against the product number, but there are a bunch of them, so maybe matching X4* would make more sense?
[21:15] <Ng> (at least, mine isn't matched, although at the moment resuming is broken with or without seemingly any of the quirks ;)
[21:21]  * emgent hi
[21:41] <calc> doko: unoil.jar.?.jar are uploading to chinstrap:~/incoming right now
[22:18] <mwolson> could I get someone to upload my changes to emacs22 as per LP #172389?
[22:18] <mwolson> <== maintainer of emacs22 package
[22:18] <ubotu> Launchpad bug 172389 in emacs22 "Please upload emacs22 22.1-0ubuntu10" [Undecided,Fix committed] https://launchpad.net/bugs/172389
[22:18] <mwolson> it's in main
[22:19] <mwolson> it fixes about 5-6 different launchpad bugs
[22:20] <mwolson> if a .diff.gz file is preferred to a debdiff, i can accommodate that
[22:54] <azeem> mwolson: ok just curious - I totally see the point that the emacs22 documentation should be present by default, but wouldn't this also be achieved by just depending on emacs22-non-dfsg or are there further user-visable issues with the documentation then?
[22:54] <mwolson> azeem: have you read https://wiki.ubuntu.com/MichaelOlson/WhyDifferentEmacs yet?
[22:55] <azeem> yes
[22:58] <mwolson> mainly the moral aspect of it.  i'll add some additional details to that page to address this question
[23:00] <azeem> I see.
[23:16] <Kmos> slangasek: got more time to accept dom4j in NEW? a lot of packages are FTBFS because of it..
[23:19] <slangasek> Kmos: still several packages ahead of it in the queue; we'll get there
[23:20] <Kmos> slangasek: thanks. You forgot some backports on U-A and one sync.
[23:20] <Kmos> :)
[23:20] <Kmos> just to remind
[23:23] <slangasek> Kmos: I didn't forget any backports; I have no idea why ~u-a is subscribed to those at all, the archive admins aren't responsible for /doing/ the backports.
[23:25] <Kmos> slangasek: no? lol.. since I remember, the archive admins do that..
[23:25] <Kmos> slangasek: you need to ask pitti about that =) if motu's can do it, it's really better..
[23:26] <jdong> slangasek: you guys are responsible for doing the backports :)
[23:26] <slangasek> jdong: er?  but backports are sourceful uploads with changed version numbers, surely?
[23:26] <jdong> slangasek: no those are source-change backports
[23:26] <jdong> slangasek: non source change (normal) backports are done automatically via some sort of script on your end
[23:26]  * slangasek goes to refer to his manual
[23:26] <jdong> similar to a sync
[23:27] <slangasek> well, fair enough
[23:27] <slangasek> ok, if I get through NEW and have some time left, I'll have a look
[23:27] <slangasek> otherwise someone else can take them later :)
[23:27] <jdong> slangasek: sure; I think I've got a thing or two in NEW that needs loving too, so I'm happy.
[23:28] <mwolson> azeem: I've updated that page to list three reasons why I don't want to just Depend on emacs22-common-non-dfsg
[23:49] <mwolson> are ubuntu-main-sponsors the right group to subscribe when I want to upload a new emacs22 package?  it usually takes a few weeks to get a new package uploaded, so I'm wondering if I'm subscribing the right people/group
[23:49] <Kmos> mwolson: yes, it's the correct group
[23:49] <Kmos> because the package is in main
[23:50] <mwolson> Kmos: thanks