[12:35] <pwnguin> if a build fails on ia64 because debhelper wasn't installed, does lp automatically resubmit?
[01:35] <soren> Nafallo: Opal?
[01:37] <soren> Nafallo: Ah, nm.
[02:21] <lamont> and perl is building
[02:21] <lamont> it'll be nice when the buildds can install debhelper again.
[02:21] <lamont> slangasek: sorry
[02:22] <lamont> well, partially
[02:22] <lamont> poor timing on having oo.o, gcc-4.2, and perl all hit together
[02:50] <calc> whee that was fun... ate dinner out got bad enough 'gas' that it caused me to vomit when i got home :-\
[02:50] <bryce_> TMI
[02:50] <calc> heh
[03:43] <zzxc> Are there any plans to implement a binary diff system (eg. debiff) in the apt interface for a future release?
[03:48] <zzxc> For something like that to work with the Ubuntu live cd, the binary diff program would have to patch individual binaries, instead of entire .deb archives, to create the new .deb archive to install.  This would require considerable installation effort, and I am not near familiar with apt to do it, but it would make updating Firefox go from a 7MB download to a 200KB download.
[03:49] <RAOF> zzxc: Debian have such a system rolled out already, I think.
[03:49] <_MMA_> There's also Conary.
[03:50] <RAOF> zzxc: They certainly do for repository information, I'm not sure about actual packages though.
[03:50] <zzxc> RAOF: It works with entire .deb archives, though, if I recall correctly.
[03:50] <zzxc> Yes, repository information is of course synced intelligently, but package syncing is much harder - especially if no .deb files are on the system to begin with.
[03:51] <johanbr> For the mirrors, processing power is often more scarce a resource than bandwidth.
[03:51] <RAOF> There's also at least one project to make apt use zsync, a server-processor-friendly version of rsync.
[03:52] <zzxc> The processing would be done only once; the servers would simply store a binary diff from the last version of the package.
[03:52] <johanbr> And how would that work if your own version is not the latest one?
[03:52] <zzxc> Then you would need an entire download.
[03:53] <zzxc> Alternatively, the versions could be installed one-at-a-time until the latest version is achieved.
[03:53] <johanbr> I'm not sure that going from version N to version N+1 is the most common case for updates.
[03:53] <zzxc> Right now, it's not the most common case.  But for security, it should be.
[03:57] <zzxc> Existing .deb diff software would have to be reworked for this to happen.  For example, the binary diff might be a modified .deb file.  Instead of containing entire binaries, it would contain binary diffs from the last version.  Apt would then have to be modified to require the previous package to be installed, and to properly apply the binary diffs.  If an error occured during package extraction (for example, one of the files that needs
[03:58] <Nafallo> god damn. keescook: any way to check which processes are using openssl and therefor needs a restart?
[03:58] <ajmitch> lsof?
[03:59] <Nafallo> hmm. might actually work...
[04:01] <Nafallo> kewl
[04:01] <RAOF> zzxc: https://blueprints.edge.launchpad.net/ubuntu/+spec/apt-sync might interest you.
[04:01] <Nafallo> thanks aj
[04:01] <Nafallo> ajmitch
[04:02] <Nafallo> ajmitch: hmm... everything :-(
[04:02] <ajmitch> heh
[04:05] <zzxc> RAOF: How close is that to an implementation?
[04:07] <zzxc> RAOF: Actually, it seems that it requires the package file be on the remote system - which is not the case for most end-users.
[04:10] <Nafallo> done :-)
[04:10] <Nafallo> the one affected mostly is probably my ntp :-/
[04:12] <Nafallo> hmm.
[04:12] <Nafallo> I seeded 547GB for the beta. that should be enough damnit :-)
[04:12] <zzxc> I think I might try to investigate the feasibility of a "partial .deb file", and post something to one of the debian mailing lists.  It would be trivial to have a folder on each mirror called "partial" to host partial packages.  This is how Mozilla does it.
[04:14] <zzxc> It's definately a turn-off to a user with a slow connection to realize that 100MB of updates required for security.
[04:14] <desrt> zzxc; best bet, i think, is to have some sort of [something]  that modifies the user's system in-place
[04:14] <desrt> zzxc; including performing the actual changes and modifying the dpkg state to pretend that the new version has been installed
[04:15] <zzxc> desrt: That would seem to be risky, to 'pretend' to install packages while avoiding apt entirely.
[04:16] <desrt> zzxc; in many cases all you'd be doing is bumping the version number of the installed package
[04:16] <desrt> since when security updates occur you have to install all of the binary packages from that given source package and probably only one of them has actually changed
[04:17] <zzxc> desrt: Implementing something like that would seem to be 'reinventing the wheel' with Apt.  In addition, it would have to stay up-to-date with the current apt version to avoid major problems.
[04:18] <desrt> it's actually completely orthogonal to apt
[04:18] <zzxc> I suppose for security updates, where the only change is changes to existing binaries, such a solution would work.
[04:18] <desrt> if you wanted to get really fancy you could do all sorts of neat binary-patching techniques
[04:20] <zzxc> desrt: It would seem to be difficult, however, to have a general tool that would generate these "update instructions" from deb files in the general case.
[04:20] <desrt> this is the fun part :D
[04:21] <desrt> seriously, though: why not just extract the two debs and run diff?
[04:21] <zzxc> Tools for that exist.  However, the old version's .deb doesn't exist on the remote computer.
[04:21] <desrt> who the hell is david portwood?
[04:22] <desrt> i report a problem with the livecd and my bug gets "New => Invalid" with "Compiz package is not from the official Ubuntu repositories, and as such is not supported here."
[04:23] <desrt> have i missed something?
[04:23] <zzxc> A 'partial .deb', on the other hand, would be able to be extracted into a 'full .deb' using existing binaries (such as soffice.bin) on the remote machine.
[04:24] <zzxc> Thus, OOo 2.3.0-><IP_ADDRESS> might be 5MB instead of 100MB.
[04:25] <Burgundavia> zzxc: are you talking about binary diffs?
[04:25] <Burgundavia> google deb binary diffs
[04:30] <zzxc> Burgundavia: Sort of.  I'm talking about a partial deb that *contains* binary diffs being used to update software on a computer in which no existing .deb to patch exists.
[04:37] <mneptok> FWIW, dm-crypt as part of d-i greatly excites my wriggly bits.
[04:38] <mneptok> as well as my full head latex Bruce Schneier mask
[04:38] <realist> zzxc: you can rebuild the .deb from already installed packages, then binary patching that package, you mean?
[04:39] <realist> zzxc: where the archive cache has been previously cleaned?
[04:40] <zzxc> With live cd installs, there never is an archive cache.
[04:41] <realist> I hadn't noticed that, strange.
[04:43] <zzxc> Such a technique would probably not try to rebuild the existing .deb archive.  Rather, it would download a new .deb archive from a mirror that would contain binary diffs instead of entire binaries.  New binaries would be in the .deb file in their entirety, and files that may be edited (such as configuration files) would not be diff'ed either.
[04:44] <zzxc> Some program would then convert the binary diffs inside the .deb file into full binaries, by patching binaries on the user's system.  The user would then have a full .deb file that could be normally installed as normal.
[04:47] <realist> I see, so download binary patches as a .deb, then patch existing installed binaries, _then_ build the new .deb?
[05:15] <pavan> ubuntu (almost) no functional after attempted upgrade to gutsy 7.10 .. can i please get some help.. thanks
[05:15] <RAOF> pavan: Help in #ubuntu+1
[05:16] <RAOF> pavan: Which also has the advantage of having more people in it :)
[05:16] <pavan> thx
[05:22] <minghua> Is there any words about mass build failures on all buildds of different arches?
[05:30] <realist> realist: I think it might be cheaper calculating the binary diffs client side, than storing diffs between every package release on the server
[05:30] <realist> zzxc rather.
[05:31] <realist> Talking to myself again :-)
[05:31] <realist> Then again, Canonical might have the funds for such a trade-off.
[05:32] <zzxc> realist: How could the diff be calculated on the client side?
[05:33] <realist> zzxc: by storing checksums of the package, rather than diffs between releases
[05:33] <zzxc> I'm not sure what you mean.
[05:34] <zzxc> To compute the diff, the computer would need access to both the old and new versions.  Thus, the client computer would be unable to do it.
[05:35] <zzxc> Storing and pushing binary diffs stored as "partial .deb files", as I described earlier, could be done with the exsting mirrors.  There would just be two .deb files for each update, rather than one.
[05:38] <realist> You would need to rsync/zsync the blocks with different checksums
[05:38] <realist> So it's not so much patching, as syncing, the packages
[05:39] <realist> If the original .deb doesn't exist, you could regenerate it from the installed binaries
[05:40] <minghua> realist: Generally speaking you aren't guaranteed to reconstruct a .deb from installed binaries.
[05:42] <realist> minghua: you could just sync the binaries listed in the package meta-data then
[05:44] <minghua> realist: True.  I was not arguing against your "rsync-like update" idea, just pointing out some inaccuracy in your statement.
[05:45] <realist> minghua: fair call.
[05:48] <realist> What would be interesting to see, is this type of patch or sync capability, combined with debtorrent
[05:52] <dongthao> hello
[05:52] <zzxc> realist: Are there not enough ubuntu package mirrors for your liking :)
[05:52] <dongthao> I want to join ubuntu developers, how can I begin?
[05:53] <dongthao> please help me :(
[05:54] <realist> zzxc: I just like the idea of distributed networks, fewer points of failure, etc
[05:54] <RAOF> dongthao: #ubuntu-motu is a better place to start.
[05:54] <RAOF> dongthao: wiki.ubuntu.com/MOTU
[05:54] <RAOF> dongthao: There's all sorts of stuff to do :)
[05:54] <dongthao> I've create launch-pad account
[05:55] <dongthao> but there're too many teams
[05:55] <dongthao> I don't know where to begin
[05:55] <realist> Find something that interests you, for a start
[05:56] <RAOF> dongthao: How do you want to help?  What do you want to do?  Translation, packaging, programming, etc.
[05:56] <dongthao> I want programming :)
[05:57] <pwnguin> excellent
[05:57] <dongthao> I'm learning and working with python
[05:57] <pwnguin> dongthao: do you know what a diff is?
[05:57] <dongthao> I think a little :)
[05:57] <dongthao> I often use it in compare files
[05:57] <dongthao> sometimes in patching
[05:58] <pwnguin> yup
[05:58] <pwnguin> check out that wiki page
[05:58] <pwnguin> and
[05:58] <pwnguin> the MOTU just had a blog about how to get started
[05:58] <RAOF> dongthao: What sort of project might you be interested in?  There are a bunch of Ubuntu python projects, or you could write a gnome-screensaver hack configurator :)
[05:58] <dongthao> ye
[05:59] <dongthao> oh
[05:59] <dongthao> gnome-screensaver
[05:59] <dongthao> it sounds interesting
[05:59] <minghua> RAOF: gnome-screensaver's configuration indeed sucks.
[05:59] <dongthao> I have some hacks in gnome-app-install
[05:59] <pwnguin> http://daniel.holba.ch/blog/?p=54
[05:59] <dongthao> but just for fun in free time
[06:00] <RAOF> dongthao: What that would entail is being able to write .desktop files, it'd be pretty simple.
[06:01] <dongthao> yep
[06:01] <RAOF> dongthao: http://ubuntuforums.org/showthread.php?t=418759 is a forum thread containing some information about that.
[06:01] <dongthao> I modify some source from it
[06:02] <dongthao> mostly in translating and rearrange the columns
[06:02] <pwnguin> if you really want to hack gnome-screensaver
[06:02] <pwnguin> make it accept pam
[06:03] <RAOF> pwnguin: Not hack *on* gnome-screensaver, write a GUI for configuring xscreensaver hacks.
[06:03] <RAOF> pwnguin: Of course, pamifying could be good, too.
[06:03] <fabbione> siretart: next time you modify a postinst please make sure it actually runs.. or at least sh -n it
[06:04] <pwnguin> RAOF: it'd be handy for my fingerprint reader ;)
[06:04] <dongthao> yep
[06:04] <dongthao> I think it's neccesary
[06:04] <dongthao> anyone like that task?
[06:05] <pwnguin> im not sure what task you're thinking of, but it's all yours
[06:05] <RAOF> dongthao: I'll join you in it if you want to start it up.  You'd probably want to create a gnome-screensaver-config project on launchpad, use LP for bzr hosting, and write it in python :)
[06:05] <realist> pamifying gnome-screensaver
[06:06] <dongthao> i'm a very new in ubuntu development
[06:06] <dongthao> event dun know clearly about lauchpad
[06:07] <dongthao> i'm studying on it
[06:07] <RAOF> dongthao: This wouldn't strictly be ubuntu development, but it *would* be very useful :)
[06:07] <dongthao> yep
[06:07] <dongthao> i like it
[06:07] <pwnguin> dongthao: joing #ubuntu-motu, and check out https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=bitesize
[06:07] <dongthao> so anyone start it
[06:07] <dongthao> i'll join with you
[06:07] <pwnguin> dongthao: those are supposed to be good "learning" bugs
[06:07] <dongthao> yep
[06:07] <dongthao> i'll check it now
[06:08] <RAOF> That's if you want to help by packaging, of course :)
[06:08] <dongthao> i'll training experence :D
[06:08] <pwnguin> packaging and dev'ing go hand in hand really
[06:08] <RAOF> pwnguin: No, not really.
[06:08] <dongthao> :)
[06:10] <dongthao> i also think they go hand in hand
[06:10] <pwnguin> i mean, if you want changes into ubuntu, you at least need to know how to get the current source, modify it, and pass it back
[06:10] <RAOF> pwnguin: You may notice that almost all the software we package isn't packaged by the developer(s).
[06:10] <minghua> pwnguin, realist: What exactly does "pam-ifying gnome-screensaver" mean?  Doesn't gnome-screensaver ship /etc/pam.d/gnome-screensaver in Ubuntu?
[06:10] <RAOF> Oh, that.  Yes.
[06:10] <pwnguin> im not saying that upstream should be providing a debian dir
[06:11] <pwnguin> though its handy as a reference
[06:11] <realist> minghua: I don't even use gnome :-)
[06:13] <pwnguin> minghua: it doesn't work with pam_thinkfinger
[06:13] <pwnguin> i havent yet dug into why
[06:14] <RAOF> pwnguin: Added pam_thinkfinger to /etc/pam.d/common-auth ?
[06:14] <minghua> pwnguin: Okay.  Then you should have said "pam_thinkfinger-ifying". ;-)
[06:14] <pwnguin> RAOF: ages ago
[06:14] <RAOF> Fair enough :)
[06:14] <pwnguin> RAOF: skimming some stuff suggested an ACL
[06:14] <pwnguin> i wasnt even aware ext3 had acls
[06:14] <pwnguin> but apparently FC ships with em
[06:15] <RAOF> Yeah. What doesn't?
[06:15] <realist> Even ffs has acls.
[06:15] <pwnguin> ffs?
[06:17] <realist> bsd-ffs
[06:17] <pwnguin> huh
[06:17] <pwnguin> i figured it was just unix permissions
[07:17] <Hobbsee> (in the opposite order0
[07:17] <pwnguin> uh
[07:19] <LaserJock> hi Hobbsee
[07:21] <mneptok> i ...
[07:21] <mneptok> i need to walk away
[07:21] <mneptok> just ... walk away
[07:21] <Hobbsee> hi LaserJock
[07:22] <Hobbsee> mneptok: yes, you do.  go drown yourself in some beer.
[07:22] <pwnguin> mneptok: maybe a first class ticket to Australia is in order :D
[07:26] <LaserJock> anybody here got any experience with vcs imports?
[07:26] <Burgundavia> Hobbsee: ouch, all I can say is ouch
[07:26] <Hobbsee> Burgundavia: heh.
[07:29] <kylem> mneptok, pfft, quoting yourself on /Quotes is discouraged. ;-)
[07:32] <mneptok> kylem: dude. i know the pressure i just absorbed. i get a back-pat.
[07:32] <mneptok> you know it, too.
[07:32] <kylem> ha.
[07:33] <mneptok> you know how difficult that was yor me.
[07:33] <mneptok> *for
[07:33] <mneptok> i'm still kinda shaking.
[07:43] <pwnguin> heh
[07:48] <ajmitch> hello Hobbsee
[07:48] <Hobbsee> hi ajmitch
[07:48] <ajmitch> nice to see you
[07:48] <Hobbsee> hi ogra
[07:48] <ogra> hey he
[07:48] <ogra> y
[07:48] <Hobbsee> hm
[07:52] <ajmitch> Treenaks: some breakage ahead?
[07:53] <Treenaks> ajmitch: tip of the day: don't run apt-get -y dist-upgrade
[07:53] <pwnguin> heh
[07:53] <Treenaks> it tried to deinstall perl.. and everything depending on it
[07:53] <ajmitch> oh, noone would be silly enough to do that
[07:53] <pwnguin> yes
[07:53] <Treenaks> which is pretty much everything
[07:54] <LaserJock> yeah, it seems like perl is important for some reason
[07:54] <pwnguin> perl seems to have broken most of the buildqueues as well
[07:54] <ajmitch> can we punt perl to universe?
[07:56] <LaserJock> sounds sane ;-)
[07:56] <Treenaks> well, only ntp and console-setup seem to depend on it :)
[07:57] <ajmitch> it shouldn't take long to rewrite debhelper in python
[08:02] <Treenaks> yay for remove vs purge.. system fixed :)
[08:09] <calc> anyone else notice apt-get being buggy on dist-upgrade lately?
[08:10] <calc> bug 146614
[08:10] <ubotu> Launchpad bug 146614 in apt "apt-get dist-upgrade fails due to bogus(?) unmet dependencies" [Undecided,New]  https://launchpad.net/bugs/146614
[08:10] <slangasek> sorry, I've only noticed that you broke ooo installability. :)
[08:10] <ogra> lol
[08:10] <calc> heh it installed fine for me :)
[08:11] <calc> wrt apt-get issue apt-get upgrade works fine for me but apt-get dist-upgrade complains of installed packages not being installed and that they won't be installed since obviously they already are
[08:11] <frostburn> mines complaining about perl and a dep that isn't in the repo
[08:12] <calc> frostburn: hmm shouldn't that just cause it to hold perl?
[08:12] <calc> apt-get upgrade held several packages on my system
[08:12] <calc> The following packages have been kept back: gnome-cards-data gnome-games-data libperl5.8 perl perl-base tracker tracker-search-tool
[08:12] <calc> 0 upgraded, 0 newly installed, 0 to remove and 7 not upgraded.
[08:13] <frostburn> you can install the rest of them
[08:13] <frostburn> individually
[08:13] <frostburn> except perl stuff
[08:13] <calc> ok
[08:14] <calc> i guess dselect upgrade calls the same code as apt-get dist-upgrade because it doesn't work either with the same output
[08:18] <frostburn> calc you on amd64?
[08:18] <calc> frostburn: yes
[08:19] <frostburn> luckyone, you, and me all have the same prob =]
[08:19] <calc> frostburn: follow up to 146614 noting you have the same problem ;)
[08:19] <luckyone> interesting
[08:20] <calc> cjwatson: you were the last to touch apt, any idea if what you changed could have caused the issue?
[08:21] <calc> idle 10hr, he'll be back soon maybe ;)
[08:21] <slangasek> why do you suppose it's a bug in apt, rather than simply a normal side-effect of uninstallable packages in the archive?
[08:21] <calc> slangasek: er shouldn't it tell us what is uninstallable then?
[08:22] <slangasek> never has before
[08:22] <frostburn> apt is fine
[08:22] <calc> slangasek: i thought it used to complain about the packages that were actually uninstallable
[08:22] <slangasek> you only get told about which packages are uninstallable if you request packages to be installed by name
[08:23] <calc> so it is normal for apt to complain about packages that are perfectly fine and installed when it can't install some other random package, and not mention that package at all?
[08:23] <calc> i haven't had dselect->upgrade break me in so long i can't remember the last time it did
[08:23] <calc> er for me
[08:24] <calc> eg in this case it complains about xbase-client, xclock, xfd, xlogo, xorg, xterm all of which are installed and don't have new versions
[08:24] <TheMuso> calc: have you managed to look at bug 140673 yet? I know its not a priority for you, but if you could look into it, it would be great for helping us get deacent accessibility for screen reader users for the final release.
[08:24] <ubotu> Launchpad bug 140673 in espeak "Espeak + portaudio v19 causes undesirable lock-ups." [Medium,Confirmed]  https://launchpad.net/bugs/140673
[08:25] <calc> TheMuso: looking
[08:26] <calc> TheMuso: i can drop portaudio dep from ooo completely if that is agreeable, esp since it seems to cause problems in this case
[08:26] <calc> TheMuso: i just recently added it anyway so its not a big deal
[08:27] <TheMuso> calc: I'm convinced, but I'm probably not the one needing convincing.
[08:27] <TheMuso> calc: If you could leave a comment, and I think pitti should be good with it/. I can then get an upload for espeak done. Thanks a lot.
[08:29] <calc> yea i added a comment just now
[08:30] <TheMuso> calc: Thanks again.
[08:30] <calc> no problem :)
[08:33] <luckyone> anything I can help with to fix the dependencies issue with xorg and xbase-clients
[08:33] <calc> luckyone: it appears it may just be apt is a pos issue and complains about the wrong thing
[08:33] <calc> luckyone: apt-get upgrade should work for you, it is probably perl being broken that caused the weird apt error message
[08:34] <nb-au> any idea when perl-modules will be updated anyone?
[08:34] <luckyone> huh, is there a link I can follow up with this on?
[08:34] <luckyone> I *need* to head to bed
[08:34] <luckyone> but *need* to fix this... tomorrow
[08:34] <calc> luckyone: just run apt-get upgrade and go to bed, perl will probably be fixed tomorrow
[08:35] <Hobbsee> calc: or monday.  it is a saturday todya.
[08:35] <calc> luckyone: apt-get dist-upgrade will probably be broken until perl is fixed
[08:35] <calc> luckyone: see what Hobbsee said
[08:35] <luckyone> yeah, doesn't work
[08:35] <calc> luckyone: er apt-get upgrade worked for me
[08:35] <calc> luckyone: it was apt-get dist-upgrade that failed on my box
[08:36] <luckyone> I concur
[08:36] <luckyone> good to know that upgrade still works
[08:36] <luckyone> I was afraid I wouldn't be able to install packages
[08:36] <calc> ok, so just don't use dist-upgrade until perl is fixed :)
[08:36] <luckyone> wahoo
[08:37] <calc> and hopefully someone can beat apt up enough that it complains about the actual broken packages in the future
[08:38] <calc> oh i know what is different about the perl thing wrt dselect->upgrade
[08:38] <luckyone> I also have a stupid question about media players that can leverage dual core processors
[08:38] <Hobbsee> oh yay, breakage.
[08:38] <calc> usually dselect determines something is fubar and doesn't try to upgrade it, but didn't figure out how to do it correctly in this case
[08:38] <luckyone> does such a program exist?
[08:38] <calc> so it passed it on to apt which choked on perl
[08:40] <calc> Hobbsee: 8-P
[08:41] <frostburn> luckyone, what do you mean?
[08:41] <Hobbsee> calc: http://rafb.net/p/Brxzd428.html
[08:42] <calc> Hobbsee: how recently did you try that?
[08:42] <Hobbsee> calc: just now
[08:42] <calc> Hobbsee: it may be that your openoffice.org-l10n-* is out of date still
[08:43] <calc> Hobbsee: check to see if you see 1:2.3.0-1ubuntu2 versions available for them as well
[08:43] <Hobbsee> calc: *eyebrow raise*
[08:43] <calc> Hobbsee: they are on the main mirror already but maybe not in au
[08:44] <calc> the output you showed there showed that openoffice.org-common had not been updated but wasn't in the list to up date either afaict
[08:44] <Hobbsee> calc: dude, did you even *look* at the error log?
[08:44] <Hobbsee> oh wait,
[08:44] <calc> Hobbsee: yea :P
[08:44] <Hobbsee> why do i have openoffice.org-l10n-en-za:installed?
[08:44] <calc> because its pulled in by language-support-en probably
[08:45] <Hobbsee> oh, langsupporten
[08:45] <calc> and if the mirror you are using doesn't have up to date version of that it might be holding back ooo
[08:45] <calc> though its already on some of the mirrors at least
[08:45] <nb-au> calc, for me i had to force  OO then lang support would install
[08:45] <Hobbsee> whether i missed a mirror pulse in the last ~15 mins is an interesting question, though
[08:46] <Hobbsee> calc: i don tleave myself only on the au mirror.  in fact, i use a different au mirror, and a.u.c
[08:46] <Hobbsee> because it's not worth having the packages ~12+ hours out of date
[08:46] <calc> it finished building 5 hours ago, not sure when it hit the mirrors
[08:46] <calc> nb-au: oh
[08:46] <Hobbsee> oh, so this one built :P
[08:46] <calc> of course ;)
[08:46] <calc> it builds at least some of the time ;)
[08:47] <ajmitch> Hobbsee: you sound like a born sceptic
[08:47] <Hobbsee> oh, here we are
[08:47] <Hobbsee> yes, force installing it works.
[08:47] <Hobbsee> ajmitch: i must have done too much RM stuff.
[08:47] <nb-au> hehe
[08:48] <nb-au> you should be able to slowly work your way down to the perl files by messing around in apt
[08:48] <calc> if you use dselect you can just put the perl files on hold and it will automatically get the rest
[08:49] <nb-au> hehe, ive already manually half installed them :/
[08:49] <nb-au> Hobbsee, its default
[08:50] <calc> nb-au: alternatively you can use dpkg --set-selections to put them on hold if you don't like dselect ;)
[08:50] <Hobbsee> oh, yes i do.
[08:50] <Hobbsee> i didnt get perl falling over and dying, though
[08:50] <nb-au> calc, i mean i somehow got perl to half upgrade to 7ubuntu3
[08:50] <nb-au> before i realised it was mssing packages
[08:50] <nb-au> lol
[08:50] <Hobbsee> oh, only ubuntu2 on my mirror
[08:50] <calc> nb-au: oh ok
[08:50] <Hobbsee> and a.u.c, it looks like
[08:51] <nb-au> im on main
[08:51] <calc> Hobbsee: 1ubuntu2 is the current ooo packages
[08:51] <calc> Hobbsee: they should install fine if they are all there, it worked for me off of a.u.c
[08:51] <Hobbsee> calc: i meant of perl
[08:51] <calc> Hobbsee: oh ok, nm
[08:51] <calc> time for me to go to bed, 2am
[08:52] <Kstrings> Hrm...  What am I doing wrong here.  apt-get source <package> pbuilder build <package> dpkg -i <package>  then synaptic tells me that I need to update <package> to the same version.
[08:52] <nb-au> so i ihave perl and perlbase as u3, with lib-perl as u2 but with upgrade avail, and perl-modules at u2 with no upgrade available, and im waiting for that upgrade
[08:52] <calc> Kstrings: you probably should set it to hold after installing the manual version unless you want the one from the archive
[09:06] <nb-au> looks like some stuff have been updated (namedly perl)
[09:07] <nb-au> give it a go :)
[09:09] <nb-au> hmm seems not, have to go manual
[09:11] <nb-au> HOLY CRAP
[09:11] <nb-au> FIXED
[09:11] <nb-au> woot
[09:35] <frostburn> do i have to recompile kaffeine/totem to get dvd playback
[09:36] <siretart> fabbione: oooops - sorry. willdo next time :(
[09:37] <nb-au> frostburn, shouldnt
[09:37] <nb-au> should work with dvdcss
[09:38] <frostburn> aye, it's installed already
[09:39] <nb-au> strange
[09:39] <nb-au> i watched 2 dvds back in tribe 3
[09:39] <frostburn> yeah it was working in 7.04
[09:39] <frostburn> i'll keep plugging at it
[09:41] <nb-au> tried mplayer?
[09:41] <nb-au> if it doesnt play it that something is badly amiss
[09:42] <nb-au> or maybe u dont have codecs
[09:43] <frostburn> yeah
[10:01] <Kstrings> Does anyone know why aptitude thinks you need to update packages compiled from source (pbuilder) when they are the same version?
[10:03] <Hobbsee> sounds like a #ubuntu+1 type question
[10:04] <Hobbsee> but, it's because you probably compiled the same version as what's in the repos - and iirc, it will usually try to use the repo version, not your own.
[10:04] <Hobbsee> due to apt priorities
[10:04] <Treenaks> it will
[10:05] <Treenaks> but I usually fix that either by setting the package status to 'hold', or setting the version a bit higher (but not as high as an update would set it)
[10:06] <ajmitch> which is where ~ in versions comes in handy
[10:07] <Kstrings> The ~ is?
[10:09] <Hobbsee> hm, will keybuk eat me for uploading udev?
[10:09] <ajmitch> Hobbsee: yes, fabbione already uploaded a new version
[10:09] <Treenaks> Hobbsee: he might, depends on how buggy you made it ;)
[10:10] <Hobbsee> ajmitch: awesome.  that was the one.
[10:10] <ajmitch> Kstrings: it's used to denote that a version is less than another, eg 1.2.3-1ubuntu1~ppa1
[10:10] <ajmitch> Hobbsee: yeah, good thing fabbione uploaded it first, otherwise I would have done uploaded my fix :)
[10:10] <Hobbsee> :)
[10:12] <ajmitch> the only problem is that it failed to build on !i386, and is in the build queue for i386
[10:14] <Hobbsee> oh dear
[10:14] <ajmitch> yeah
[10:14] <ajmitch> one of those days...
[10:27] <Mez> and now my DVD drive / HDD#'s show as s * not h* meaning I cant watch DVDs on my PC (shdparm -d wont work)
[10:36] <ajmitch> Mithrandir: I think that there'll be a large number of packages uploaded recently that will need given back on !i386 due to a perl upload - perl was made uninstallable by perl-modules on !i386 until it was built on i386
[10:37] <pwnguin> heh
[10:37] <ajmitch> one important one to give back is udev, for a typo fix
[10:41] <Mithrandir> ajmitch,Hobbsee : I'll give-back what's failed.
[10:41] <ajmitch> thanks :)
[10:41] <Hobbsee> thanks Mithrandir
[11:06] <Kopfgeldjaeger> hey
[11:10] <Mithrandir> there, stuff given back.
[11:11] <Hobbsee> thanks Mithrandir
[11:28] <slytherin> I had sent a mail to ubuntu-devel-discuss team about theora beta 1 poackages. Should I wait for some testing feedback or just go ahead and file a freeze exception bug?
[11:33] <RAOF> slytherin: If you're prepared to follow the freeze exception process, there's a compelling reason for theora beta 1, and it doesn't break anything, I'd say file a freeze exception bug.  There's been someone looking at this in here before.  Was that you?
[11:34] <slytherin> RAOF: If that was yesterday then it was me.
[11:34] <RAOF> There was someone before yesterday, too, but I can't remember who it was.
[11:35] <slytherin> RAOF: Till now I have tested totem, mplayer, and ffmpeg2theora and no breakage found. But there are too many rdepends, so dholbach suggested me to send mail.
[11:38] <Kmos> bug 146666
[11:38] <ubotu> Launchpad bug 146666 in ubuntu "Installation Break on ASUS P5K SE" [Undecided,New]  https://launchpad.net/bugs/146666
[11:38] <Kmos> i think this is kernel related
[11:38] <RAOF> slytherin: Ah, fair enough.  Then maybe wait for replies on -devel-discuss.  It is the weekend, after all.
[12:17] <Whoopie> mjg59: Hi, could you have a look at bug 109151? I re-added usplash support to uswsusp. but the acpi-support package also needs a change.
[12:17] <ubotu> Launchpad bug 109151 in uswsusp "no hibernate with uswsusp installed" [Undecided,Confirmed]  https://launchpad.net/bugs/109151
[12:18] <mjg59> Whoopie: How did you handle the resolution information?
[12:19] <Whoopie> mjg59: I added a -x and -y command line parameter to suspend.c and resume.c
[12:19] <Whoopie> and these values are read from /etc/usplash.conf in /etc/acpi/hibernate.sh
[12:21] <mjg59> Whoopie: Ah, ok. And the swap device is auto-chosen?
[12:21] <Whoopie> mjg59: it's in /etc/uswsusp.conf. And this was added during install. debconf??
[12:22] <mjg59> Hm. Not entirely ideal, but fair enough.
[12:22] <mjg59> Ok, I'll try to upload that later
[12:22] <bluekuja> mjg59: I was following Whoopie on it, if that patch is ok, I can move to upload that
[12:23] <bluekuja> mjg59: just wanted to hear your opinion about it
[12:23] <Whoopie> mjg59: problem for me is that it hangs on resume. It doesn't switch back to X, but the laptop is still responsive so that I can poweroff it by pressing the power button.
[12:23] <Whoopie> really don't know if it's usplash or my laptop.
[12:40] <Whoopie> mjg59: and if you are on the acpi-support package, could you add the 0 to /etc/acpi/events/asus-brightness-{up,down}? it's bug 76593. thanks!
[12:40] <ubotu> Launchpad bug 76593 in acpi-support "asus brightness hotkeys" [Wishlist,Confirmed]  https://launchpad.net/bugs/76593
[01:41] <salty-horse> hi. is there a way to hurry up a build? there was a small bug in udev that prevented it from being installed, and I fear to restart my machine after a gutsy upgrade without it working: https://launchpad.net/ubuntu/+source/udev/113-0ubuntu14
[01:46] <Hobbsee> if there are buildd admins around, yes
[01:46] <Hobbsee> otherwise, no
[01:46] <salty-horse> Hobbsee, I'm installing an older version: https://launchpad.net/ubuntu/+source/udev/113-0ubuntu12/+build/398871
[01:47] <Hobbsee> you could just fix the script, so it installs - the bug tells you how to, iirc.
[01:48] <salty-horse> I'm not an expert at .deb packaging -- rather not mess with it
[03:48] <glatzor_> hello Riddell, the latest ati drivers in Ubuntu do no longer support xinerama. So I prepared a patch to disable dualhead in guidance for ati cards.
[03:51] <AnAnt> Hello, a latex package (package here means set of macros, not debian package) has this file in the fonts/ directory 'Uqnskh.fd', does anyone know where the *.fd files should be installed in latex system ?
[05:29] <attunix> Where can I download the new "Elephant" wallpaper available in Gutsy? I'm on Feisty.
[05:31] <ryu> attunix, here are some: https://wiki.ubuntu.com/Artwork/Incoming/GutsyIdeas
[05:31] <ryu> or you could fetch the gutsy packe from packages.ubuntu.com and extract it
[05:32] <attunix> ryu: without the logo? ;)
[05:37] <ryu> then you should pick the second way i mentioned...
[05:38] <attunix> ryu: how do I do that? :)
[05:39] <ryu> attunix, http://mirrors.kernel.org/ubuntu/pool/main/g/gutsy-wallpapers/gutsy-wallpapers_0.16_all.deb
[05:39] <attunix> cool; thanks :)
[05:39] <ryu> you can take a file-roller oder similar programms to extract it...
[05:40] <cjwatson_> calc: certainly nothing to do with my change; have a look at the diff, it's trivial
[05:41] <Hobbsee> greetings, cjwatson
[05:41] <cjwatson> hello, briefly
[05:42] <cjwatson> must walk dog, do laundry, do washing up, do everything else. argh.
[05:42] <Hobbsee> hehe
[05:42] <Hobbsee> find a robot.
[05:42] <cjwatson> on the upside I think I nearly have oem-config i18nised
[05:42] <kylem> tollef's too busy.
[06:45] <keescook> mornin'
[06:45] <Hobbsee> hiya keescook!
[06:45] <keescook> hi!
[06:45] <keescook> thanks for the kdebase upload.  There are a few more CVE fixes still to go into it, though.  Got any time for that?
[06:46] <Hobbsee> keescook: for main packages?
[06:46] <keescook> yup. konqueror.
[06:46] <Hobbsee> urgle.
[06:46] <keescook> let me find the bug #
[06:47] <Hobbsee> keescook: btw, do you know if that csh shell thing was correct?  i saw you un-securified it
[06:47] <keescook> hurm?  where?
[06:47] <Hobbsee> i'ts in kdebase buglist
[06:48] <keescook> checking
[06:49] <keescook> afaik, the xsession is running as the user (not root), so if csh blows up, it is certainly a bug, but not a security issue.
[06:49] <keescook> (137946)
[06:50] <Hobbsee> keescook: i'm  more wondering fi the fix is correct
[06:52] <keescook> Hobbsee: hmm, yeah, it looks okay.  It feels like there would be a cleaner way to handle it though.
[06:53] <Hobbsee> keescook: right
[06:54] <keescook> I'd almost be tempted to try things like   $SHELL -c "(if (-f /etc/csh.login) source /etc/csh.login; if (-f ~/.login) source ~/.login) >/dev/null; /bin/sh -c export" > $xsess_tmp
[06:55] <Hobbsee> hm
[06:55] <keescook> (or whatever the csh redirection looks like)
[07:03] <keescook> Hobbsee: bugs #140707 and #146870   are the qt-x11-free, qt4-x11, kdebase, and kdelibs CVE issues.
[07:03] <ubotu> Launchpad bug 140707 in qt-x11-free "[Qt 3, Qt 4]  Potential vulnerability in QUtf8Decoder" [High,Fix released]  https://launchpad.net/bugs/140707
[07:03] <ubotu> Launchpad bug 146870 in kdelibs "konqueror URL bar spoofing" [Medium,Triaged]  https://launchpad.net/bugs/146870
[07:04] <keescook> since those are bzr'd what's the best way for me to prepare patches for kde uploaders to take/upload ?
[07:05] <keescook> Hobbsee: also, do you have archive powers to take-back a build?  Something broke in openssl for amd64 (that I can't reproduce locally) and was hoping it was just a temp failure.
[07:06] <Hobbsee> keescook: i dont have any archive powers at all.  i dont work for canonical.
[07:06] <Hobbsee> keescook: sometimes i wish i did
[07:07] <keescook> oh, ow
[07:07] <keescook> Setting up linux-restricted-modules-2.6.22-12-generic (<IP_ADDRESS>-12.4) ...
[07:07] <keescook> Segmentation fault (core dumped)
[07:07] <Hobbsee> keescook: can you email me about those bugs?  i'm really tired
[07:08] <Hobbsee> urgh.
[07:08] <keescook> Hobbsee: sure, sending.
[07:08] <Hobbsee> (it's after 3am)
[07:08] <Hobbsee> thanks a million
[07:08] <mjg59> keescook: Sweet.
[07:08] <keescook> yeow, yeah, I thought it was late for you.  :)
[07:08] <mjg59> keescook: Got an oops in dmesg?
[07:08] <keescook> mjg59: seems depmod faulted.  but then my computer has hated me lately, so I bet it's my filesystem or something stupid.
[07:10] <ion_> jamiemcc: Btw, is it intentional that tracker returns zero results until everything has been indexed? Id rather already get results for the already indexed entries, with perhaps a warning that the initial indexing is still going on.
[07:19] <jamiemcc> ion_: 0.6.3 caches more in RAM so search results may not be avilable til its finished - we will amend the UI to warn about that
[07:21] <ion_> jamiemcc: file-meta.db already contains some of the files im testing with, but tracker-search doesnt return any results for them.
[07:22] <jamiemcc> ion_ index is stored in file-index.db
[07:23] <ion_> jamiemcc: Ah, ok. It doesnt contain any data about files. Couldnt it be updated every once in a while *during* the indexing?
[07:23] <jamiemcc> ion_: it is when 16mb cache is full - it flushes to index
[07:25] <ion_> jamiemcc: Would it perhaps be better to mmap files and let the kernel do all the RAM caching and flushing?
[07:25] <jamiemcc> ion_ no can do - mmap is not supported in qdbm or sqlite
[07:25] <jamiemcc> ion_: mmap does not work on fuse as well
[07:26] <ion_> I see.
[07:26] <jamiemcc> ion_: also mmap takes memeory away from disk cache
[07:26] <jamiemcc> if you have 1gb index it would eat 1g ram from disk cacje
[07:27] <lamont> pool/universe/o/openoffice.org-l10n/openoffice.org-help-km_2.3.0-1ubuntu2_all.deb
[07:27] <lamont> do we not love Comoros then?
[07:28] <ion_> The whole mmapped area is kept in RAM? If that is the case, id say the kernels implementation is faulty. Id expect the kernel to flush pages that have been unused for a while to the disk and free the memory when RAM is needed for something else.
[07:28] <lamont> pool/universe/o/openoffice.org-l10n/openoffice.org-l10n-uz_2.3.0-1ubuntu2_all.deb
[07:28] <lamont> and lets not forget Uzbekistan
[07:28] <ion_> Of course, i could be missing something important. :-)
[07:29] <jamiemcc> ion_ it gets flushed when memory is low or you call unmap
[07:32] <ion_> So, someone should implement a way to tell the kernel in this mmapped file, pages that have been unused for a while are not as important as disk cache? :-)
[07:33] <jamiemcc> ion_: dunno - mmap is used for either sharing memory pages or agressive read pages into ram
[07:33] <desrt> ion_; madvise()
[07:33] <desrt> specifically, MADV_DONTNEED
[07:33] <jamiemcc> desrt: we use posix_fadvise all over tarcker
[07:34] <desrt> jamiemcc; tracker _destroys_ my laptop
[07:34] <ion_> desrt: 0.8.3?
[07:34] <desrt> i had to kill it off.  no offense to you or anything
[07:34] <jamiemcc> desrt: latest 0.6.3 version?
[07:34] <desrt> gutsy beta as of last night
[07:34] <ion_> Whoops, typo.
[07:34] <jamiemcc> its not in beta
[07:34] <jamiemcc> its post beta
[07:34] <desrt> well.. right... updated as of last night :p
[07:35] <desrt> i was downloading and tracker was doing its think on the downloading file
[07:35] <desrt> and every time vim went to save its .swp file the editor would hang for a good 10 seconds
[07:35] <jamiemcc> desrt: that sounds like o.6.2 version
[07:36] <desrt> when the update comes i'll try again
[07:36] <jamiemcc> desrt: what file were you downloading?
[07:36] <desrt> openoffice
[07:36] <desrt> it's a biggie :)
[07:36] <jamiemcc> desrt: I will try and replicate to be sure
[07:36] <desrt> it may interest you that i'm not running ubuntu kernels these days
[07:36] <jamiemcc> desrt: lol
[07:39] <jamiemcc> desrt: anyway latest tracker 0.6.3 updates in chunks with intermittent fsync to prevent disk hogging for more than a sec or two
[07:40] <desrt> why do you call fsync()?
[07:40] <jamiemcc> cause pdflush will hog disk if I dont
[07:40] <desrt> it must be fun to fight the kernel's cleverness
[07:41] <desrt> why is it that the kernel is (more or less) ok with every other workload on earth but things like beagle and tracker always bring it to its knees?
[07:41] <jamiemcc> pdflush!
[07:42] <jamiemcc> its a high priority kernel thread
[07:42] <jamiemcc> and can starve other apps of disk
[07:42] <jamiemcc> desrt: its really bad on ext3 causeits write performance is terrible
[07:43] <desrt> i'd expect that a download does more disk writing than tracker should during a download
[07:43] <desrt> and yet doing two downloads doesn't wedge my system
[07:43] <jamiemcc> tracker does seek read seek write for each word
[07:43] <desrt> what do you mean "word"?
[07:44] <jamiemcc> an indexed word
[07:44] <mjg59> jamiemcc: The write depends on the read?
[07:44] <jamiemcc> mjg59: of course its a has - you have to read where to write it
[07:44] <mjg59> Yeah. There's no way the kernel can reorder that, then.
[07:45] <desrt> not true
[07:45] <desrt> you could read a bunch of offsets in one go
[07:45] <jamiemcc> desrt: right
[07:45] <desrt> so you're only consulting the index once
[07:45] <jamiemcc> the reads should all be cache hits
[07:45] <jamiemcc> if index is small
[07:45] <desrt> fair enough
[07:45] <mjg59> jamiemcc: Yeah.
[07:45] <desrt> unless the index is being continuously pushed out by the insane amount of writing
[07:46] <mjg59> With a small index file, it's fine (and I guess the index merging fixes this to a large extent)
[07:46] <jamiemcc> with 30mb index is slows to crawl which means i suspect kernel
[07:46] <jamiemcc> mjg59: yes index merging eliminates it untuil merge process
[07:46] <desrt> jamiemcc; i have a suggestion
[07:46] <jamiemcc> shoot
[07:46] <desrt> jamiemcc; write a root-run helper program that opens the user's index and locks it into memory
[07:46] <desrt> see if it impacts performance
[07:47] <desrt> just as a test
[07:47] <jamiemcc> how?
[07:47] <desrt> mmap() the entire file
[07:47] <desrt> and then run mlock() on that address you get
[07:47] <jamiemcc> qdbm does not use mmap though
[07:47] <desrt> doesn't matter.  this will keep it in the kernel's page cache
[07:47] <desrt> make sure you do a shared mapping
[07:47] <jamiemcc> ok will it be able to write it?
[07:47] <desrt> yes
[07:48] <Nafallo> hmm
[07:48] <jamiemcc> I will have to do that with 0.6.2 version
[07:48] <desrt> i guess it either writes with pwrite() or lseek()/write()?
[07:48] <Nafallo> my brightness changed by itself...
[07:48] <jamiemcc> lseek/write i think
[07:48] <desrt> this is just a cute little test utility
[07:48] <desrt> it's a 10-liner in C
[07:48] <jamiemcc> yeah
[07:49] <desrt> where is the tracker index, btw?  i wonder how big mine is.
[07:49] <jamiemcc> home/.cache/tracker/ index*
[07:49] <jamiemcc> meta is the metadata
[07:49] <desrt> hmm
[07:49] <desrt> email stuff is a few KB
[07:50] <jamiemcc> you dont use evolution then
[07:50] <desrt> file-content is 54M, file-index 73MB, file-index-journal 15M, file-meta 19M
[07:50] <desrt> i do use evo
[07:50] <desrt> just with imap
[07:50] <jamiemcc> thats 0.6.2 version!
[07:50] <jamiemcc> in 0.6.3 its file-contents.db
[07:51] <desrt> i probably just didn't turn it back on after i upgraded :p
[07:51] <jamiemcc> yes - it will auto reindex when you do
[07:51] <jamiemcc> 0.6.2 really sux!
[07:51] <desrt> totally awesome that you shipped it with the beta :p
[07:52] <mjg59> desrt: Released after beta freeze
[07:52] <jamiemcc> well i had 0.6.3 ready on monday
[07:52] <jamiemcc> but they waitied til now
[07:52] <desrt> nod.
[07:52] <ion_> jamiemcc: Btw, are there plans to have a local tracker process indexing shared directories on a networked drive and having clients trackerds proxy queries to it over the network?
[07:52] <jamiemcc> 0.6.3 indexes 250mb of linux source in 8 minutes and no slow downs
[07:53] <desrt> jamiemcc; "8 minutes" on a good harddrive or on my laptop? :p
[07:53] <jamiemcc> ion_: network searches are on the long term todo
[07:53] <jamiemcc> desrt: a reasonable hard disk
[07:53] <jamiemcc> a slow one might take a few minutes more
[07:53] <jamiemcc> 0.6.2 would take hours to indesx that due to IO choking
[07:53] <mjg59> So far, 0.6.3 seems a great deal better at avoiding IO issues
[07:54] <desrt> there is a really really big difference between compiling a kernel on my laptop and on my desktop
[07:54] <jamiemcc> mjg59: yeah its as good as we can make it
[07:54] <desrt> jamiemcc; lies :)
[07:54] <ion_> 0.6.3 is indexing my entire ~ on a 500 MHz P3 box right now, and i dont notice it at all, except for the HDD led blinking steadily.
[07:54] <mjg59> jamiemcc: It's a great improvement. Thanks very much for working on this.
[07:55] <jamiemcc> mjg59: no problem - we want to be the best :)
[07:55] <desrt> jamiemcc; i'm sure you'll find something more to tweak for 0.6.4 :)
[07:55] <jamiemcc> desrt: thats due on monday
[07:55] <desrt> oh
[07:55] <desrt> maybe 0.6.5 then
[07:56] <jamiemcc> 0.7 more like we are branching to do xesam next
[07:56] <desrt> mjg59; it has this new policy timeout feature
[07:56] <pwnguin> as long as it isn't dimming the screen after like 20 seconds
[07:56] <mjg59> Ok, restarting hal seems to have made it happer
[07:57] <desrt> if events occur too soon after the event that preceeded them then it assumes that you have a buggy acpi and ignores them
[07:57] <mjg59> Tch. Only seems to be autochanging brightness when I open the preferences.
[07:58] <desrt> are you using non-g-p-m methods of changing brightness?
[07:58] <mjg59> jamiemcc: tracker isn't obviously pausing when I switch to battery, but it's possible that things are just generally broken right now
[07:58] <mjg59> desrt: No
[07:58] <desrt> mjg59; that's odd indeed, then
[07:59] <desrt> my gutsy bitchlist is rapidly shrinking
[07:59] <jamiemcc> mjg59: yeah - battery pausing was well tested
[07:59] <jamiemcc> it uses hal so hal must be working
[07:59] <desrt> now all i gotta do is find out why networkmanager randomly crashes coming back from suspend
[07:59] <ion_> jamiemcc: Perhaps the index should be updated after either the 16 MiB cache has been filled *or* e.g. 5 minutes have passed since the last update.
[08:00] <jamiemcc> ion_: we dont work like that anymore - each flushis to a sepoarate mini index (approx 16mb)
[08:00] <jamiemcc> once indexing is finished we stuch them all up into one index
[08:01] <ion_> jamiemcc: Tracker has been running for 45 minutes and still returns no results. That is slightly annoying.
[08:02] <desrt> does tracker do the filesystem or just ~?
[08:02] <jamiemcc> by default just home
[08:03] <jamiemcc> desrt: it plays nice wth source - tracker puases itself when compiling or checking out source
[08:04] <desrt> cute.
[08:05] <desrt> in any case, my homedir on my laptop is about 1GB
[08:05] <desrt> 900MB of that is source
[08:05] <desrt> so i'm just making tracker's job easier :)
[08:05] <jamiemcc> desrt:  :)
[08:06] <jamiemcc> desrt: tracker only pauses if it detects writes on its inotify watches
[08:06] <jamiemcc> so if excluded from watching it wont pause
[08:06] <desrt> jamiemcc; tracker wakes up once every 2 seconds to read /proc/acpi/ac_adapter/ADP1/state
[08:07] <desrt> jamiemcc; you're better to watch the system dbus for state change notifications
[08:07] <jamiemcc> desrt: yeah -  I have to figure out how to use hal dbus
[08:07] <calc> cjwatson_: ok np
[08:07] <desrt> you just dbus_add_match on the signals
[08:08] <desrt> *bus_add_match, rather
[08:08] <jamiemcc> I know that but I dont know hal api
[08:08] <jamiemcc> hal is not very friendly in that regard
[08:08] <desrt> about 5 seconds with dbus-monitor --system and a yank of a laptop power cord will tell you that :)
[08:08] <jamiemcc> desrt: good idea!
[08:08] <desrt> i think for something like this it would be better to just use dbus directly
[08:09] <jamiemcc> yeah we are tivkless everywhere else
[08:09] <desrt> i recently ported some code of mine from using libhal to using libdbus.  it was just easier.
[08:09] <jamiemcc> tickless
[08:09] <desrt> signal sender=:1.3 -> dest=(null destination) path=/org/freedesktop/Hal/devices/acpi_ADP1; interface=org.freedesktop.Hal.Device; member=PropertyModified
[08:09] <desrt>          string "ac_adapter.present"
[08:09] <desrt>          boolean false
[08:09] <desrt>          boolean false
[08:10] <jamiemcc> desrt: that acpi_ADP1 is hardware specific though
[08:10] <desrt> seems pretty straight-forward
[08:10] <desrt> it is true.
[08:10] <desrt> "ac_adapter.present" is not :)
[08:10] <jamiemcc> so I need to discover ac_adaptors first
[08:10] <desrt> ...or watch for PropertyModified on all devices... :/
[08:10] <desrt> the format of this signal is obnoxious....
[08:11] <desrt> if it sent "ac_adaptor.present" as a toplevel argument of the signal you could even match on that
[08:11] <jamiemcc> yeah I had a peek at api - it sux big time
[08:11] <desrt> there is code in the gnome applets for this
[08:11] <desrt> i wrote it.. you're free to use it under whatever license tracker is
[08:11] <jamiemcc> tracke ris gpl
[08:12] <desrt> oh.  that's fine then :p
[08:12] <desrt> anyway.. it uses libhal to maintain a list of all of the batteries and AC adaptors in the system
[08:12] <jamiemcc> desrt: I will have a hunt
[08:12] <ion_> defcon: Good choice for username. :-)
[08:12] <defcon> hehe
[08:12] <defcon> ion, ive used that nick for yrs as well
[08:12] <defcon> ionstorm
[08:13] <defcon> thnx
[08:13] <desrt> http://svn.gnome.org/viewcvs/gnome-applets/trunk/battstat/battstat-hal.c?revision=9981&view=markup
[08:14] <desrt> see the adaptor_update_property() function... this is the thing that will get called when you get an ac_adaptor.present change event
[08:14] <jamiemcc> desrt: thx
[08:16] <defcon> who handles xorg drivers
[08:16] <defcon> new bug for i810
[08:16] <defcon> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-driver-i810/+bug/146728
[08:16] <ubotu> Launchpad bug 146728 in xorg "[Gutsy Beta]  Dots on 16bit Video i810" [Undecided,New]
[08:36] <fabbione> hmmm
[08:36] <fabbione> interesting FTBFS on udev... not my fault
[09:03] <defcon> i have a problem with my video since butsy beta on 16bit, I have little "dots" all over my video on my intel i810 82865G
[09:04] <defcon> what could be doing this?
[09:12] <Nafallo> change to gutsy ;-)
[10:49] <sivang> hi all
[10:49] <sivang> congrets for the beta, pretty impressive list of improvements
[10:53] <lameiro_> hi. Straw 0.27 is released since May, but Debian maintainer still didn't package it.  is it possible to have it packaged for Gutsy?
[10:55] <_MMA_> lameiro_: This late in the game I would think not.
[10:58] <lameiro_> _MMA_: alright, thank you. maybe I should ask this in #ubuntu-motu? right?
[10:59] <_MMA_> lameiro_: If its a Universe packages yes but its the same situation.
[10:59] <_MMA_> Its very close to release and we are past our freeze dates.
[11:01] <lameiro_> _MMA_: ouch. alright... thank you.
[11:01] <_MMA_> np
[11:07] <Riddell> keescook: I did say I'd take care of the kde/qt security issues :)
[11:07] <Riddell> but let me know the current status please
[11:07] <Riddell> (there's no way to revert an upload once it's in the archives)
[11:43] <pochu> lameiro: although if it's a bug fix release, an exception for it might be approved...
[11:44] <lameiro> pochu: unfortunately no, it is a new version with new functionality, new strings... :(
[11:45] <geser> does it fix some important bugs found it the current version in gutsy?
[11:45] <geser> (if they exist)
[11:45] <pochu> Then I guess not.
[11:45] <pochu> You can backport bug fixes, though.
[11:46] <asisak> Hey geser, pochu
[11:46] <geser> Hi asisak
[11:47] <lameiro> geser: no, just little fixes here and there and some new features, no critical bug fixes. thank you :)
[11:48] <pochu> heya asisak
[11:48] <geser> then you only chance it to bribe two motu-uvf members :)
[12:15] <keescook> Riddell: I saw that Hobbsee uploaded one of the fixes, so I wanted to point out the others to her in case she was still working on them.
[12:15] <keescook> Riddell: afaik, 140707 and 146870 contain all the missing issues.
[12:17] <ion_> A script i use to handle integration between keychain and libpam-ssh. http://johan.kiviniemi.name/software/keychain.shellrc


[14:21] <OvenWerk1> cub ping
[14:22] <OvenWerk1> cub re: languages.... c c++ python  would be my guesses
[14:23] <OvenWerk1> it depends on the lib the dev wishes to use
[14:23] <OvenWerk1> gtk is c and qt is c++
[14:25] <OvenWerk1> we were trying to avoid kde apps for a while but that was to ship less libs.
[14:25] <OvenWerk1> in the end we want the best or most used apps to be included.
[14:29] <cub> ah, I'm trying to convince a friend who is a developer to participate in ubuntu studio
[14:29] <cub> I think he mostly work with c and c++
[14:29] <OvenWerk1> we don't do that much coding ourselves.
[14:30] <cub> no but it would not hurt to have someone who knows some about it?
[14:30] <OvenWerk1> Most of what we do is with script like python or perl
[14:30] <OvenWerk1> The big use we would have fopeople who know code is bug fixing.
[14:30] <cub> yeah
[14:31] <cub> but we'll see, he's quite busy with work, family and music...as most of us so he wasn't sure he would have the time
[14:32] <OvenWerk1> Our direction seems to be changing some. The focus seems to be moving towards making the workflow metas really good.
[14:32] <OvenWerk1> Once in a while work is good too. as you have probably seen there are no real dead lines
[14:36] <zequence> cub: There's perhaps only one project that might need C/C++ coding - a workflow manager, most likely in the form of a panel. It's a loose concept that has not been deeply developed yet
[14:36] <zequence> Our other applications, the installer, and ubuntustudio-controls could both be coded in any language with either GTK or QT
[14:37] <zequence> currently, -installer is in perl? and -controls is python/GTK
[14:38] <zequence> We do have deadlines. But, we don't get serious consequences in not making them, as we are not a business.
[14:48] <cub> I was looking at the work flow page last week, but unsure on how to proceed
[14:48] <cub> it feels like april 2014 is quite soon. :P
[14:49] <cub> this one: https://wiki.ubuntu.com/UbuntuStudio/PackageListSaucy
[14:51] <zequence> cub: categories needs to be established, and then, each application needs to be put into a category
[14:51] <zequence> It would be good to add all that data to a searchable database
[14:51] <zequence> We don't need to do it all over again for each release either
[14:51] <zequence> Just update it
[14:53] <zequence> The categories should follow existing freedesktop and Debian categories as much as possible
[14:53] <zequence> That means, one needs to understand what those are first
[14:53] <zequence> well, Debian has sections. Not sure about the details myself, actually
[14:56] <zequence> Sorry, packages need to be tagges with one or more categories. Not applications, as that is not the same thing
[14:58] <cub> the current list, is that everything that is available or is it what's actually included in an default installation?
[14:59] <cub> hm should be all available, as I understand it
[15:07] <zequence> all available under the "sound" section of Ubuntu
[15:08] <zequence> not nessecarily all that should be included under the audio workflow, since there might be non-"sound" packages that belong there too
[15:08] <cub> yup
[15:09] <zequence> perhaps we should use a calc document for this?
[15:09] <zequence> one that we can share and use as basis for a searchable database
[15:10] <zequence> or what's the term, calc sheet?
[15:19] <cub> spread sheet
[15:19] <cub> but most people sadly call it "Excel sheet"
[15:20] <cub> what's a good way to share it? Ubuntu One?
[15:36] <zequence> Sure
[15:37] <knome> zequence, spreadsheet
[15:37] <zequence> it's nice if the data can easily be transferred to other form of databases easily. I suppose there's a way to save in a common format
[15:37] <knome> well CSV usually works
[15:38] <knome> oh, heh, didn't notice cub already said that ;)


[08:42] <sou> Hey good people, I am trying to enable TLS for openstack endpoints. For this purpose I am using vault as the CA, and trying to use https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-certificate-management.html . But signing the CSR step is confusing. It does not say how to generate .pem file. Do we have any other
[08:42] <sou> document which I can use to setup TLS for keystone using vault as the CA!
[08:42] <sou> Appreciate any tips/steps/documents.
[08:42] <sou> Thanks!
[08:43] <wallyworld> sou: you will most likely have more luck asking in #openstack
[08:49] <sou> Thanks wallyworld. As the document mentions charms, I added my concern here. Let me check in #openstack!
[08:52] <wallyworld> sou: yes, fair call. the folks who write the openstack charms tend not to hang out here so much. if you dn't get any luck in @openstack, there's a discourse forum you can try (i'd need to look up the address)
[08:54] <sou> Sure.  I'm now not getting "ubuntu", I'm getting ubuntu with stuff that I have to horse around with to get me to a more stock ubuntu
[10:45] <stickupkid> that's my main issue... caching is a github issue, not a user one
[11:20] <manadart> stickupkid achilleasa: This is patch I have been discussing at standup: https://github.com/juju/juju/pull/11921
[11:20] <stickupkid> manadart, will look
[11:30] <stickupkid> manadart, ho? got questions
[11:32] <manadart> stickupkid: Yep, gimme a couple.
[14:07] <stickupkid> manadart, Q&A went well, although slow
[14:07] <stickupkid> manadart, another question though
[14:07] <manadart> stickupkid: Yup?
[14:08] <stickupkid> in the database I'm looking at and the PR description, there is now a "type", is this an migration step, or do we not care?
[14:08] <stickupkid> ah no wait, I'm blind
[14:09] <stickupkid> manadart, tick
[14:10] <manadart> stickupkid: Ta.
[15:42] <achilleasa> stickupkid: or hml quick CR for a help text change? https://github.com/juju/juju/pull/11922
[15:42] <hml> achilleasa:  looking
[15:48] <hml> achilleasa:  one suggestion for the change.
[16:10] <achilleasa> hml: It was easier to just rewrite the help text. Can you take another look?
[16:11] <hml> achilleasa:  sure
[16:12] <hml> stickupkid: review please: https://github.com/juju/juju/pull/11923. it’s not really 1k lines, there are mock files and json schema changes.
[16:12] <stickupkid> hml, k
[16:13] <hml> stickupkid: I’ll do the TODO once i get the whole thing wired up
[16:13] <hml> in the next pr
[16:14] <hml> achilleasa:  I like the new write up,  any concerns that this does not follow the other help msgs with a specific examples section?
[16:16] <stickupkid> hml, do we need Resolve for charm hub?
[16:16] <hml> stickupkid: we will, need to figure out where to put it and what it should contain.  that’s my next step
[16:17] <hml> i’m thinking just the charmhub package
[16:18] <stickupkid> hml, done
[16:20] <hml> stickupkid: ho?
[16:20] <stickupkid> sure
[16:22] <achilleasa> hml: no idea :D
[16:23] <achilleasa> petevg: ^^^ thoughts on https://github.com/juju/juju/pull/11922 re: Heather's comment?
[16:24] <achilleasa> hml: actually I should change the redis example and use apache2 everywhere
[16:34] <stickupkid> esp. because redis isn't even updated