[00:00] <kees> ryanakca: check with kirkland -- it should be trivial to get update-motd to include it.
[00:01] <cdE|Woozy> according to the manpage of update-motd, this behaviour is intended
[00:02] <XCP> yes, but you can disable it. the question is, why is Ubuntu running needless services in the background?
[00:02] <XCP> by default, that is.
[00:05] <XCP> you could of course argue that someone might need the motd to be updated, but then he can activate update-motd manually. the same way you don't run apache by default on every machine just because *some* are going to host a website.
[00:05] <persia> Running the service has some value.  Running every 10 minutes by default might be a bit agressive.  I'd suggest filing a (wishlist) bug, and building some discussion about the best frequency.
[00:05] <XCP> hmm ok.
[00:07] <persia> XCP, I'd argue that running it at least daily makes sense (and there's plenty of stuff that runs out of cron.daily.)
[00:07] <persia> For me, hourly is borderline, and 10 minutes is insane.  For others, the values may be different.
[00:13] <virtuald> why should it be in motd and not bashrc?
[00:33] <TheMuso> .c
[00:46] <slangasek> superm1: do we have folks to test the mythbuntu alpha-2 candidates?
[01:09] <ebroder> Anybody with main upload bits willing to take a look at bug #362691?
[01:10] <ebroder> (The actual patch is in comment 37)
[01:11] <StevenK> Not until alpha 2 releases
[01:12] <ebroder> "Topic changed to Archive: open | karmic alpha-2 released"
[01:12]  * StevenK shakes his fist at slangasek 
[01:12] <StevenK> :-P
[01:12] <ebroder> Haha
[01:13] <slangasek> StevenK: it's ok, you can go ahead and pretend I didn't say that if you wish :)
[01:13]  * StevenK grins
[01:14] <StevenK> asac: So, can you help me look at a xulrunner induced build failure?
[02:16] <calc> anyone used dircproxy or bip before?
[02:18] <StevenK> I'm using bip now
[02:18] <directhex> bip bip bip bip
[02:19] <directhex> -directhex- VERSION bip-0.7.4
[02:19] <calc> ok that settles it, two crazy people on bip, so me too ;-)
[02:20] <calc> any gotchas in setting it up?
[02:20] <StevenK> directhex is the crazy one.
[02:20] <calc> StevenK: heh :)
[02:20] <holoway> calc: I've used znc for a while
[02:21] <directhex> calc, only gotcha is the auto-scrollback feature is intensely annoying when applied to /msg, as the behaviour of it varies depending on irc client and internet speed
[02:22] <calc> ok
[02:23] <calc> i'll have to see how it goes
[02:23]  * calc primarily needs a way to have regular irc client plus privmsgs that show up as alerts somehow, probably pidgin
[02:24] <superm1> slangasek, i'll send some pings out
[02:24]  * calc hopes he can get pidgin to work without having 500 windows open for all the channels i am on
[02:33] <calc> directhex: do you know if it works well to always get the channels in the same order in eg irssi?
[02:36]  * TheMuso uses bip also.
[02:42]  * Hobbsee shakes fist at karmic xorg.
[02:43]  * Hobbsee is getting bored of it locking up her machine at random.
[02:43] <superm1> bored? isn't aggravated a better description?
[02:44] <lifeless> Hobbsee: runnong edgers?
[02:44] <Hobbsee> lifeless: nope.  I'm thinking that might be a good idea, as it might be more stable.
[02:44] <superm1> calc, bip bip bip. if you still need help i can point a reference config
[02:44] <lifeless> Hobbsee: cworth blogged a couple of days ago
[02:44] <lifeless> Hobbsee: you need the latest kernel release for many of the bugfixes.
[02:45] <calc> superm1: i copied it out of usr/share/doc and working on it now
[02:45]  * calc notes this netbook's broken spacebar is really annoying, only the left side works
[02:45] <superm1> calc, cool. i got mine from kirkland initially. i think he started convincing a lot of people to use it
[02:46] <Hobbsee> lifeless: looking for it
[02:46] <calc> superm1: ah
[02:47] <lifeless> http://www.google.com/reader/shared/03159273885318971096
[02:47] <lifeless> Hobbsee: ^
[02:47] <lifeless> third post
[02:49] <Hobbsee> lifeless: oh, i was looking on the wrorng planet.  Thanks :)
[02:51] <lool> pitti, tkamppeter_: Right, I'm in SF still; travelling back tomorrow but will be jetlagged and tired; I can make some tim to push poppler 0.11.x to experimental if noone can do it
[03:00]  * calc goes back to using his laptop
[03:08]  * Hobbsee takes the plunge, and reboots
[03:09] <Hobbsee> if you see an explosion down south, you'll know what it was....
[03:12] <Hobbsee> hm, no explosion.
[03:13] <TheMuso> heh
[03:52] <robert_ancell> TheMuso: lifeless: Do you know who manages ubuntu-dev-tools?  I've found a trivial bug, who has commit access? (I'd like to avoid filing bugs and commit directly)
[03:55] <Hobbsee> robert_ancell: it's in bzr
[03:55] <Hobbsee> so i presume you can do a merge (i think the branch is owned by ~ubuntu-dev)
[03:56] <StevenK> And if you don't, you can push to a branch you own and request a merge using LP
[03:56] <robert_ancell> Hobbsee: I think I'm not in ubuntu-dev, any idea how to become?
[03:57] <robert_ancell> StevenK: yeah, I'm trying to avoid that :)
[03:57] <StevenK> But that's the Proper Way if you can't commit directly?
[03:57] <Hobbsee> robert_ancell: what StevenK said
[03:58] <robert_ancell> yeah, I'm just too lazy though :)
[03:58] <StevenK> Don't make us go over there
[03:58] <StevenK> :-P
[03:59] <robert_ancell> But it's a one character fix!  Someone will find it eventually...
[03:59]  * robert_ancell attempts to annoy everyone until they commit it themselves or give me ubuntu-dev membership :)
[03:59]  * StevenK searches for his checkout
[04:00] <StevenK> robert_ancell: Good, then I won't feel bad when I beat you up :-)
[04:00]  * TheMuso can put his hands on a checkout now if StevenK can't.
[04:00] <robert_ancell> StevenK: Such violence! Won't someone think of the children?
[04:00] <StevenK> Whose children?
[04:01] <robert_ancell> TheMuso: Add the missing % on line 56 of lp-set-dup :)
[04:01]  * StevenK continues to wait for bzr pull
[04:03]  * TheMuso has to pull the latest changes also
[04:04] <robert_ancell> ASDL not so good away from the CBD?
[04:04]  * StevenK kicks robert_ancell 
[04:04] <TheMuso> robert_ancell: my python is not great, I don't see where a % sign is needed...
[04:05] <robert_ancell> needs a percent after the closing quote
[04:05] <robert_ancell> i.e. substitute these variables into the string %=substitute operator
[04:05]  * StevenK can't see lp-set-dup in his u-d-t pull
[04:06] <TheMuso> robert_ancell: does there need to b e a space between the quote and the %?
[04:06] <robert_ancell> TheMuso: Not required, but I'd put one there to match the others
[04:06] <TheMuso> ok
[04:07] <robert_ancell> TheMuso: thanks
[04:07] <TheMuso> got it
[04:07] <robert_ancell> StevenK: what do you have checked out?
[04:07] <robert_ancell> laziness was the winner on the day
[04:08]  * robert_ancell returns to his soul crushing attempts at rationalizing the 600+ compiz bug reports
[04:08] <TheMuso> heh
[04:09] <TheMuso> ok pushed.
[04:57] <sanket> this is regarding APT, I wish to discuss an idea I have in mind
[04:58] <persia> sanket, Have you written up your idea for review?
[05:00] <sanket> Nopes, where to do that ?
[05:00] <persia> Well, there's a few options.
[05:01] <persia> brainstorm.ubuntu.com is a handy resource to get initial discussion of an idea and refine it a bit.
[05:01] <persia> Once there's some understanding of how one might do it, one might write it up in more detail on the wiki.
[05:01] <persia> Then it's easy to point to a URL on IRC or in a mailing list post to invite discussion and criticism.
[05:02] <persia> Of course, if it's a small idea, a bug works nearly as well.  And if it's really small, just asking on IRC can be enough :)
[05:03] <sanket> the idea relates to developing a tool to help automate the process of building custom( maybe partial ) mirrors for custom distro's supporting APT tool kit.
[05:04] <persia> That's complex enough that I'd recommend outlining it on a wiki, at least.  Depending on how deeply you're familiar with apt and mirroring, you may even want to use brainstorm to help refine it first.
[05:05] <sanket> just to make sure, such an idea is not impl or in progress... else i wud rather contribute :)
[05:07] <sanket> does such project already exist ?
[05:07] <persia> I don't happen to know of anything, but I'm just one person.  Documenting the outline of which sort of tool you're talking about would help others to determine if it matches some existing tool.
[05:08] <sanket> cool enough, i will file the idea asap
[05:10] <superm1> slangasek, from the feedback i'm hearing, it seems a bunch of those mesa bugs that i spent eons fixing in 9.04 have returned for nvidia and intel hardware, i'm trying to get the guys to register the stuff on isotracker, but it's sounding like we might have to skip a2 since these are kinda big things
[05:21] <tjaalton> superm1: mesa and nvidia? they shouldn't have anything in common
[05:38] <superm1> tjaalton, well this is the exact symptoms we were seeing in 9.04
[05:38] <superm1> -nv driver using swrast
[05:38] <superm1> and only getting stencil output with mythtv
[05:39] <tjaalton> oh, that
[05:40] <superm1> did some patch get dropped?
[05:40] <superm1> or some upstream change that you know about that went on causing this?
[05:44] <tjaalton> uh oh, yes
[05:44] <tjaalton> I don't exactly know why
[05:44] <tjaalton> let me check the git logs
[05:49] <tjaalton> superm1: wait, it's still there
[05:49] <tjaalton> 105_glXWaitX_segfaults.patch
[05:49] <superm1> there was that one and one more
[05:49] <superm1> 104_swrast_fbconfigs.patch
[05:49] <superm1> are we sure it was applied upstream?
[05:51] <tjaalton> it wasn't in jaunty
[05:51] <superm1> hm. i'll have to dig up some nvidia hardware and look if things work with the jaunty mesa or where things are messed up then
[05:54] <tjaalton> patch 104 was dropped late March, since it was included upstream
[05:55] <superm1> hmm then
[06:16] <slangasek> superm1: ah, doh
[06:17] <superm1> took long to get "functional" live disks in the first place, so didnt leave much time to look at this stuff
[06:17] <superm1> little installer gaf's earlier on and what not
[06:18] <dholbach> good morning
[06:31] <calc> hmm the way pidgin interacts with bip isn't exactly optimal but i suppose it works good enough for the moment
[06:31] <calc> if i close the irc window it quits all of the channels on my proxy for me as a 'feature' apparently
[06:32] <lifeless> \o/
[06:32] <persia> calc, bip works well with xchat and irssi, although I'm not sure either of those interfaces work for you.
[06:32] <lifeless> kill -9 ?
[06:32] <calc> and with lots of channels always open in pidgin it makes it fairly hard to see when people private message me
[06:33] <calc> persia: i need something to work with pidgin due to management request
[06:34] <lifeless> calc: you hasve to use pidgin?
[06:34] <calc> lifeless: i need something that will prod me about private messages immediately
[06:34] <persia> calc, patch pidgin to not close windows when disconnecting?
[06:34] <calc> persia: that might work assuming pidgin doesn't actually alert me about every message in every channel
[06:35] <persia> xchat can be configured to provide various sorts of notifications, including audible notification.
[06:35] <lifeless> calc: ah. I tell folk to SMS me if they ever want an 'immediate' guarantee, cause I close IRC and email and all notifications when focusing on stuff
[06:36] <persia> calc, My memory is that pidgin has a notifications plugin that lets you configure when to provide notifications, and when to shut up.
[06:36] <calc> ah hmm i'll have to look at it closer then
[07:41] <TheMuso> c/
[09:03] <pitti> Good morning
[09:03] <pitti> tkamppeter: right, sounds like a plan; the cups recommends alone should also pull it in on upgrades
[09:03] <pitti> lool: hi! poppler> I'm happy to prepare a package if you want
[09:05] <\sh> moins pitti
[09:22] <jamesh> pitti: hi.  Thanks for the help with the erlang related packages.
[09:23] <jamesh> pitti: the couchdb package that got uploaded misses some dependencies though -- I only discovered this yesterday.
[09:24] <pitti> jamesh: I saw; I'll upload your corrections; thanks for following up with Debian
[09:25] <dholbach> jamesh: do you think you could forward the dependency changes of rabbitmq-server to Debian too?
[09:25] <dholbach> the rabbitmq folks were keen to have the same versions in ubuntu and debian
[09:25] <jamesh> dholbach: sure.
[09:26] <dholbach> nice  thanks muchly
[09:37] <tkamppeter> pitti, hi
[09:38] <tkamppeter> pitti, I have made all CUPS Raster drivers depend on ghostscript-cups and also prepared a debdiff for the lsb package to depend on ghostscript-cups, as CUPS Raster is an LSB requirement.
[09:39] <tkamppeter> pitti, see bug 385606
[09:44] <Ng> so in this brave new world where hal is being deprecated, where should I poke a bug about my suspend hotkey (Fn-F4) not working while the screen is locked? (my argument being that a hotkey like that should always work, and I'm pretty sure it used to)
[09:51] <ogra> Ng, if it isnt already, it should be handled by devicekit-power afaik
[09:57] <Ng> hmm
[10:06] <persia> sladen, A long long time ago you commented on bug #109446.  Do you have any further thoughts on the policy decision you mentioned then?
[10:16] <pitti> Ng: sounds like gnome-power-manager
[10:21] <Ng> pitti: ok, ta
[10:27] <asac> StevenK: still there?
[10:30] <slytherin> does anyone know of any way for requesting a package to be rebuild on Debian buildds just to see if it has same FTBFS as Ubuntu.
[10:30] <seb128> if it has been built nobody will do a rebuild just to see that
[10:30] <cjwatson> slytherin: if you're talking about texlive-base/powerpc I *seriously* doubt it's buildd-specific. I know you can't reproduce it on your hardware but that's not the same thing
[10:31] <cjwatson> slytherin: last time somebody claimed a problem was buildd-specific I bet against it and won 10 euro off them, so be warned :-)
[10:31] <slytherin> cjwatson: no, this is different package
[10:31] <cjwatson> ok, nevertheless you quit before I could reply to you yesterday
[10:31] <slytherin> cjwatson: laptop battery was down and no electricity at home.
[10:33] <slytherin> seb128: the package in question is arch:all, so it was uploaded with binaries. There is no build on Debian buildd.
[10:33] <seb128> well debian do binary uploads ...
[10:34] <directhex> boo @ binary uploads
[10:35] <cjwatson> just try it in a chroot.
[10:35] <slytherin> seb128: yes, and I have been fixing problem like this in Ubuntu fore more than 1 year. :-)
[10:36] <slytherin> The reason for build failure is that the build process can not get internet connection. AFAIK, such problems do not occur in local chroot.
[10:37] <slytherin> cjwatson: by the way, if there are more than one packages failing because of texlive-base, then does that mean it is buildd problem?
[10:38] <cjwatson> uh? we know it's failing consistently *on the buildd*; that doesn't mean it's a buildd problem
[10:38] <cjwatson> "buildd problem" means a problem that's exclusive to the buildd, something to do with the specialised software it runs
[10:39] <slytherin> cjwatson: I am sorry. I meant chroot problem.
[10:39] <cjwatson> I'm not sure how that's significantly different
[10:39] <cjwatson> you mean that the stock chroot unpacked at the start of each build on the buildd might be wrong?
[10:40] <cjwatson> I suppose that's possible; I might be in a position to check that
[10:40] <slytherin> No. I mean that may be manual intervention will solve the problem. Like login into the chroot and see why texlive-base setup is failing consistently.
[10:42] <cjwatson> if the chroot is actually broken then that might be the case, yes
[10:43]  * cjwatson attempts to drive manage-chroot.py
[10:45] <cjwatson> I don't see anything *obviously* wrong with the chroot
[10:45] <cjwatson> there are no triggers awaiting processing AFAICS
[10:45] <cjwatson> texlive-base isn't installed, of course
[10:49] <slytherin> hmm
[10:50] <slytherin> there are more than one packages failing for same reason on powerpc. But I have no idea why it is failing.
[10:50] <cjwatson> anything you can think of that might be an observable reason for that failure?
[10:51] <cjwatson> I have the chroot unpacked in front of me, although not on a powerpc machine
[10:51] <persia> I have a powerpc machine if the chroot is transportable.
[10:51] <slytherin> nothing, except it is same error everywhere.
[10:51] <cjwatson> should be
[10:52] <slytherin> can the chroot be recreated?
[10:52] <cjwatson> http://people.ubuntu.com/~cjwatson/tmp/karmic-powerpc.tar.bz2
[10:52] <cjwatson> 57.6MB
[10:53] <slytherin> soren pointed to bug ﻿198421 yesterday. Not sure how relevant it is.
[10:53] <cjwatson> don't let me stop you, of course, but looking at the code it didn't look so much like a chroot problem, more like a libc problem specific to that particular class of hardware
[10:53] <cjwatson> but that was just a guess
[10:53] <cjwatson> 198421 is unrelated
[10:54] <cjwatson> installing packages in the buildd chroot doesn't use dpkg-reconfigure
[10:54] <nutz> hi everybody
[10:55] <nutz> is someone in here really familiar with the alsa-setup in ubuntu?
[10:55] <persia> nutz, A few people, but this isn't really a channel for support.  Why do you ask?
[10:55] <slytherin> nutz: user questions in #ubuntu please.
[10:56] <nutz> i'm trying to set up alsa with S/PDIF  on another distro, but i couldnt find any changes between the working ubuntu-setup and the not so well working gentoo setup. now i was wondering if there were patches in the alsa-drivers in ubuntu
[10:57] <slytherin> cjwatson: So only two options remain 1. try using chroot somewhere else. 2. recreate the chroot. Am I right?
[10:57] <nutz> it's not really support i'm after, i just want to know if there were patches to have passthrough work better
[11:01] <cjwatson> slytherin: I don't see a reason to recreate the chroot unless it's demonstrated that that's where the problem lies
[11:01] <cjwatson> slytherin: 1) seems like a useful thing to do
[11:04]  * persia is performing #1 currently, with limited success (the chroot is *very* minimal, so needs help to be able to talk to apt)
[11:04] <slytherin> persia: thanks for that. If you can not make it work, I will try it over weekend.
[11:05] <persia> slytherin, The issue is that it breaks trying to install texlive-base, right?
[11:05] <slytherin> persia: right
[11:05] <nutz> more precisely: in the alsamixer in ubuntu all i had to do was unmute "IEC958". however in gentoo i don't get sound (from a regular signal, not talking about hwdts or hwac3 which works fine) until i put something like this: pcm.!default " plug:iec958"  in my alsarc
[11:05] <nutz> neither of those distros have a /etc/asound.conf in the beginning
[11:06] <slytherin> you can try building tuxguitar if you wish because I know for sure that it succeeded in my own chroot
[11:07] <persia> `apt-get install texlive-base` didn't work, which is enough to be interesting.
[11:09] <persia> slytherin, Can you point me at a specific build log?
[11:09] <slytherin> persia: https://edge.launchpad.net/ubuntu/+source/tuxguitar/1.1-1/+build/997760/+files/buildlog_ubuntu-karmic-powerpc.tuxguitar_1.1-1_FAILEDTOBUILD.txt.gz
[11:11] <persia> Hrm.  I got a different error.  I suspect I didn't do enough tweaks to make it work in my environment.
[11:11]  * persia tries again.
[11:14] <nutz> WTF... okay... i sort of "fixed it"
[11:14] <nutz> if anybody cares: i just installed vanilla-sources-2.6.29.4  instead of the previously tested 2.6.30. now it works JUST like in ubuntu.
[11:15] <nutz> no config-files etc.   so it's an alsa-version thing
[11:15] <nutz> oki - have a nice one. bye
[11:16] <TheMuso> I can have a look at the powerpc chroot/texlive stuff tomorrow if persia doesn't track anything down, about to go and enjoy some DVDs for the evening...
[11:17] <TheMuso> so don't want to do it right now. :)
[11:18] <persia> OK. `apt-get install texlive-base` worked.  Resetting, and trying `apt-get build-dep tuxguitar`
[11:21] <amitk> soren: got time for a few stupid kvm questions?
[11:23] <amitk> soren: how do I tell if kvm is running fully virtualised? On upgrading to karmic, my kvm windows-xp image is taking 100% cpu.
[11:23]  * persia points at #ubuntu-virt
[11:24] <amitk> thanks
[11:33] <liw> is there an easy way to see how much security updates there are for an LTS release? my best approach would be to install one in the VM, and then see how much apt would download, but perhaps there's a faster way
[11:33] <liw> I'm interested in the number of megabytes to be downloaded, and an approximation is fine
[11:33] <persia> liw you could just check the contents of the hardy-security archive.
[11:34] <persia> Packages.gz there might even have all the information you need.
[11:34] <cjwatson> yeah, that plus grep-dctrl plus numsum
[11:34] <slytherin> liw: or if you have access to the LTS installation, just to apt-get upgrade and it will tell you how much MB it is going to download.
[11:35] <cjwatson> slytherin: I think that's what liw said
[11:35] <cjwatson> "my best approach would be to install one in the VM, and then see how much apt would download, but perhaps there's a faster way"
[11:35] <liw> oh, d'oh, that was silly of me: I only remembered the Installed-Size
[11:35] <persia> which grep-dctrl+numsum is.
[11:35] <slytherin> Oh. I thought he was actually planning to download everything.
[11:35] <ion_> cjwatson: numsum, huh? Thanks, i hadn’t stumbled upon num-utils before.
[11:36] <cjwatson> it superseded the 'total' shell script I previously had
[11:36] <cjwatson> (which is pretty trivial: 'total=0; for num in $(cat); do total="$(($total + $num))"; done; echo "$total"')
[11:36] <liw> numsum could do with some manual page love
[11:37] <liw> "numsum - numsum program file" is not a good NAME section :)
[11:37] <ion_> :-)
[11:38] <liw> hmm, Size is in bytes, not kilobytes
[11:38] <persia> TheMuso, It's all yours.  I can't replicate in my environment: I get a successful install.  My process was untar chroot, edit sources.list & resolv.conf, bind-mount /dev and /proc, chroot, apt-get update, apt-get install texlive-base | apt-get build-dep tuxguitar.
[11:39] <liw> I get about 1.7 *gigabytes* of security updates for hardy
[11:40] <persia> liw, You may want to do your comparisons on a per-flavour basis, just to reduce the totals.
[11:40] <liw> nah, I'm happy with a big number :)
[11:40] <ion_> :-)
[11:50] <StevenK> asac: Am now
[11:51] <asac> StevenK: you wanted some input on xul?
[11:52] <StevenK> asac: It's broken!
[11:52] <StevenK> asac: Or something :-P
[11:53] <asac> StevenK: i guess i need some background on what you are doing and what is broken
[11:53] <StevenK> asac: http://paste.ubuntu.com/194242/
[11:57] <asac> StevenK: which package is that?
[11:58] <ion_> liw: Any thoughts about my comments yet? :-)
[11:58] <StevenK> asac: kazehakase
[11:58] <StevenK> asac: No-change rebuild from what's in the archive.
[11:58] <liw> ion_, I'm processing the wiki page now
[12:00] <asac> StevenK: when was the last build?
[12:04] <StevenK> asac: Heh, intrepid
[12:05] <StevenK> asac: I daresay it probably does require source changes, but I have no idea what.
[12:06] <asac> StevenK: http://paste.ubuntu.com/194255/
[12:06] <asac> g++-4.4
[12:06] <asac> vs 4.3
[12:06] <ogra> hmm, i'm sure i had glade3 installed in jaunty ...
[12:06]  * ogra wonders where that went
[12:06] <asac> StevenK: just do export CXX=g++4.3 in debian/rules ;)
[12:06] <asac> and build depend on it ;)
[12:07] <StevenK> Oh, argh
[12:07] <StevenK> asac: So xulrunner doesn't like 4.4? :-P
[12:07] <asac> well. we build a bunch of stuff against it with 4.4
[12:07] <liw> ion_, dpkg-repack: it should be used, I think apt-sync already does; zsync looking into gzipped data: of course; apt method to support unpacked debs: interesting idea, we should discuss that for the next phase
[12:07] <asac> more likely the way kaze uses it
[12:08] <asac> StevenK: i am checking if its better with xulrunner-1.9.1-dev now
[12:09] <ion_> liw: What’s the benefit of using dpkg-repack? It seems to have a 4×–10× time overhead over plain tar c.
[12:10] <liw> ion_, dpkg-repack should be used to construct a .deb for zsync to work on, if the user does not have a .deb already
[12:10] <ion_> liw: Mostly due to gzipping, but there’s also overhead over tar c | gzip
[12:11] <ion_> liw: zsync could just as well get a tar as an inputfile, since it contains almost entirely the same data as a deb in an unpacked form.
[12:12] <persia> liw, Do we preserve enough metainformation for dpkg-repack to be likely to have similar (compessed) binary chunks to a new .deb?
[12:12] <liw> ion_, I'm mainly interested in optimizing the actual transfer, since that's the big bottleneck; further optimizations can happen later
[12:13] <liw> persia, ask me again after I have done some benchmarks, but basically, zsync should be able to handle things well enough
[12:14] <ion_> How about the idea under “How method 0 could be implemented”?
[12:14] <asac> StevenK: so it builds with 1.9.1 ;)
[12:15] <asac> but it crashes :(
[12:15] <liw> ion_, it would seem to require fairly big changes to how .debs are generated, and that's not an option at this stage
[12:16] <liw> and now I need to go see someone, back later
[12:16] <ion_> At the very end of https://wiki.ubuntu.com/AptSyncInKarmicSpec in case anyone else wants to see my insane ramblings as well. :-P
[12:16] <persia> liw, I expect if you can teach zsync about ar, it won't matter: mostly just a magic number thing.
[12:17] <liw> ion_, damn, I just overwrote that
[12:17] <liw> persia, yes, that is the plan
[12:17] <ion_> No problem, https://wiki.ubuntu.com/AptSyncInKarmicSpec?action=recall&rev=12
[12:18] <liw> ion_, sorry about that, but I need the spec to be useful for this cycle, and your ideas, while good, are too early for this cycle, but if this experiment goes well, then next cycle we can start doing more adventurous stuff
[12:19] <ion_> “How method 0 could be implemented” – there would be no overhead of 0) dpkg-repack gzipping an inputfile, 1) zsync gunzipping the combination of the fetched data and inputfile, 2) zsync gzipping the resulting deb, 3) apt-get gunzipping that.
[12:20] <ion_> gzip takes a *loooong* time.
[12:20] <ion_> But it’s alright, i can wait for a later cycle. :-)
[12:20] <ion_> Just thought that might as well make it right from the beginning.
[12:22] <cjwatson> persia: why would zsync need to be taught about ar explicitly? ar is very little more than cat with a few header bits
[12:22] <cjwatson> persia: the overhead of syncing the extra control data will be pretty small
[12:23] <ion_> cjwatson: zsync would look inside the gzip within tar, so it needs to find the tar.gz within the ar archive.
[12:23] <cjwatson> liw: thing to remember, you'll need to know which compression method the .deb you're syncing uses for its data.tar
[12:23] <ion_> inside the tar within gzip
[12:23] <cjwatson> ion_: ah
[12:23] <cjwatson> ok, if you're going to uncompress it anyway it probably doesn't matter
[12:23] <ion_> But with my idea, you wouldn’t need to teach zsync about ar. Just put tars inside ar and gzip the deb. :-P
[12:24] <ion_> The client wouldn’t need to gzip anything, just do a single gunzip pass.
[12:24] <XCP> do Ubuntu developers actually work on the kernel/application/driver code or do they just collect and package all the applications?
[12:26] <ion_> When using zsync in the look-inside-gzip-inside-ar mode, there’s also the problem that when zsync re-gzips the deb for apt, *it might not get the gzip right* and the checksum wouldn’t match. My idea wouldn’t have that issue either.
[12:31] <ion_> xargs -d'\n' tar c -C / --no-recursion </var/lib/dpkg/info/"$package".list >inputfile.tar; zsync -i inputfile.tar http://archive/.../foo.deb.zsync would fetch parts of http://archive/.../foo.deb.gz, gunzip the data and pass apt a deb that contains debian-binary, control.tar, data.tar within ar. (dpkg already seems to support that format)
[12:31] <cjwatson> XCP: both
[12:32] <persia> ion_, That would require a deep change, and possibly a rebuild of all the apps.  Basically passing something like -9fn as unconditional arguments to gzip.
[12:32] <persia> (during .deb creation)
[12:32]  * ogra wonders if there is a way to make debootstrap more verbose during "Installing core packages..." in stage2
[12:33] <ogra> ... without actually hacking debootstrap ...
[12:33] <ion_> A rebuild wouldn’t be needed. The initial fetch would either just download the entire deb.gz because the inputfile ar contains tar.gz, not tar, or you could detect that the old package in cache contains tar.gzs and force the creation of the inputfile from installed files.
[12:34] <ion_> The initial fetch of a newly packaged deb.gz, that is.
[12:34] <ion_> s/packaged/built/
[12:36] <persia> I don't really like the idea of .deb.gz files, but it's about whether the compression result has a consistent checksum
[12:37] <persia> Passing -nf to gzip enforces this.  Not passing it makes it a matter of luck, in many ways.
[12:37] <persia> Specifying a compression level just avoids issues if two environments have different default compression levels.
[12:37] <StevenK> asac: I'll build it with 4.3, thanks.
[12:37] <persia> (note that this doesn't address differently compressed data tars)
[12:38] <maxb> Why is -f mentioned here, surely the -9n are the options that matter
[12:38] <cjwatson> why not adapt pristine-tar to cope with adjusting things like timestamp if necessary?
[12:39] <cjwatson> seems a hell of a lot easier - we certainly aren't going to change the archive to have all .debs uncompressed there
[12:39] <ion_> Making sure every single deb is always built with gzip --rsyncable -9nf, you could use zsync with a do-not-look-inside-gzip mode, get the major benefits, and the client would only need to gzip data if there’s no older version in cache.
[12:40] <ion_> You’d *always* get the right deb with the right checksum.
[12:40] <cjwatson> dpkg-deb always uses -9, but currently never --rsyncable. If you want that, you'd need to get dpkg changed, preferably upstream.
[12:41] <cjwatson> you don't need to worry about the possibility of .debs not built using dpkg-deb
[12:43] <ion_> Whatever the implementation is, i’d really prefer not having to have the client do a gzip pass on every single deb being updated. It’s so slow.
[12:43] <persia> maxb, Because it's conceivable that different gzips might make different choices on what needs to be compressed or not without -f.
[12:45] <SiDi> Hey people. Has Ekiga been removed from karmic's default installs ?
[12:45] <ion_> (See the gzip/dpkg-repack time overhead table under the title “Some benchmarking” at https://wiki.ubuntu.com/AptSyncInKarmicSpec?action=recall&rev=12)
[12:48] <slytherin> SiDi: Why do you think so?
[12:48] <SiDi> slytherin: i heard it'd be removed from the ISO to save some space. And it takes me some time to download it and check, so i thought i'd ask
[12:49] <slytherin> SiDi: I heard? Where?
[12:49] <ogra> it was removed from the seeds, yes
[12:50] <SiDi> ogra: so no more SIP app by default ?
[12:50] <asac> StevenK: thanks. we will port it to 1.9.1 or drop the -gecko part during karmic cycle anyway. so dont put much work into it ;)
[12:50] <ogra> SiDi, no idea, i just saw it being removed, i guess emapthy will replace it
[12:51] <slytherin> But does empathy have full audio/video support for SIP?
[12:51] <slytherin> and does it have the long range of codec support as ekiga?
[12:52] <slytherin> codec as in audio codecs (gsm, speex etc)
[13:00] <SiDi> i actually think ekiga is a very important app as it is the most mature alternative to the proprietary skype. I'd be sad to see it disappear
[13:01] <seb128> SiDi: why would it disappear?
[13:02] <directhex> from the default install, presumably
[13:02] <directhex> i've been promised by a friend at collabora that epiphany's audio/video UI is VASTLY improved in the next version, so there's some convergence there
[13:02] <directhex> personally i never got ekiga working
[13:02] <seb128> directhex: thanks but I guessed that, the question was rethorical for SiDi not for other people to jump in to add random comments
[13:03] <seb128> directhex: you probably mean empathy there?
[13:03] <directhex> erm, yes
[13:03]  * directhex should sleep more
[13:04] <seb128> still it's not a sip solution, doesn't have all the codecs from libopal etc and doesn't have an UI optimized for softphoning
[13:24] <kenvandine> pitti: that telepathy-glib bug should be fixed today and included in today's upstream release
[13:39] <\sh> cjwatson: hmmm...if I change on an installed ubuntu system some new debconf db entries for console-setup, and do a dpkg-reconfigure -f noninteractive console-setup, /etc/default/console-setup is not properly regenerated with the new debconf values
[13:40] <cjwatson> the canonical source for configuration is the filesystem, not debconf
[13:40] <cjwatson> if they differ the filesystem wins
[13:40] <cjwatson> just change the configuration file directly
[13:42] <\sh> cjwatson: well...I just deleted the console-setup and the postinst script creates a new one ... I wasn't sure if that behaviour is intended or if it was just a hickup
[13:43] <cjwatson> yes, it does ensure that one exists at the end
[13:43] <cjwatson> but in that case there's no configuration in the filesystem, so it can't win
[13:44] <\sh> cjwatson: my plan was to update those files with new values from debconf...anyways..problem solved...thx :)
[13:44] <cjwatson> change debconf + dpkg-reconfigure -f noninteractive is just not the correct way to change console-setup's configuration, though. Either dpkg-reconfigure (interactively) or edit /etc/default/console-setup directly
[13:45] <cjwatson> the behaviour you're asking for would have the problem that an administrator who changed /etc/default/console-setup in the most straightforward and obvious way would be surprised when a later upgrade overwrote their changes
[13:47] <\sh> cjwatson: well...idea behind that was: install some system with non-tweaked default values, and push later a new debconf db and dpkg-reconfigure -a -f noninteractive to regenerate all the config files with the new values...
[13:48] <cjwatson> \sh: not going to work in general I'm afraid
[13:49] <cjwatson> debconf is not a registry (tm)
[13:49] <\sh> hehe for sure :)
[13:50] <\sh> cjwatson: thx for the heads-up
[13:55] <amitk> hmm.. why does my apport "Report Problem" button not work?
[13:56] <ogra> because you have no problems ?
[13:56] <ogra> (apport is so clever ;) )
[13:59] <maxb> wgrant: Are you planning to upload your en-PPA-ed changes to xserver-xorg-input-synaptics soon, ooi? Do you need further testing
[14:00] <wgrant> maxb: I should probably prepare an upload and find a sponsor, yes... I'll do that tomorrow.
[14:00] <pitti> kenvandine: great to hear
[14:01] <amitk> ogra: apport popped up in the first place when nautilus crashed :-/
[14:01] <ogra> ouch
[14:19] <Pici> Regarding the note on the Alpha2 testing page, is HAL being completely depreciated, or only for power management?
[14:21] <persia> I heard it was dead upstream, but it's probably incremental to pull it out (hopefully within karmic)
[14:31] <evand1> devicekit-disks is in place as well, so it's already more than just power management.
[15:12] <calc> which is better xchat or xchat-gnome (they seem to be forked?)
[15:18] <Ampelbein> !best | calc
[15:26] <LaserJock> calc: xchat-gnome is from devil ;-)
[15:29] <NCommander> LaserJock, I thought the devil ran xchat-win32
[15:30] <calc> is it possible to join multiple bip connections through a single xchat?
[15:31]  * calc thinks it would look to xchat like just trying to connect to the same irc server multiple times
[15:35] <robbiew> slangasek: ping
[15:51] <directhex> calc, it would indeed look like that
[15:51] <directhex> calc, you just configure multiple duplicate irc servers to join, and have a different connection string configured on each
[15:52] <mterry> robbiew: Heads up that I probably don't have the right raid hardware after all.  I don't have any non-netbook or non-laptop machines, so the only thing way I can get two identical hard drives is with thumb drives, but I don't believe they work with dmraid (though apparently you can use them with mdadm)
[15:52] <robbiew> mterry: hmm...okay
[15:52] <robbiew> dendrobates: around?
[15:52] <mterry> robbiew: I'm confirming with Luke
[15:55] <slangasek> robbiew: pong
[15:55] <robbiew> slangasek: I can't make the first hour (perf review)...and Colin needs to leave early, so could Foundations move up the queue?
[15:56] <slangasek> ok
[15:56] <robbiew> thanks
[15:56] <robbiew> cjwatson: ^^
[15:57] <tkamppeter> Anyone around who can help on a package dependency problem?
[15:58] <tkamppeter> See bug 141641
[15:59] <tkamppeter> The package lsb depends on mail-transport-agent and mail-transport-agent is provided by very many packages, including postfix and ssmtp. Currently the heavy daemon-loaded postfix gets autro-installed. How I can change priorities so that ssmtp gets auto-installed by default?
[16:00] <cjwatson> slangasek: cheers
[16:00] <\sh> tkamppeter: lsb-core needs mailx, and mailx needs bsd-mailx and bsd-mailx depends on postfix|mail-transport-agent...so correct...without a MTA mailx would be useless ;)
[16:01] <tkamppeter> \sh, I have successfull replaced postfix by ssmtp.
[16:02] <tkamppeter> \sh, what I want now is that ssmtp gets chosen in the first place.
[16:02] <sebner> \sh: it's funny, is it just me or are you more often online than *before* the baby was born *ehehe* ;-P
[16:02] <\sh> tkamppeter: right..the problem is, if no MTA is installed...it will choose postfix as prio 1 but if something else providing mail-transport-agent is installed, it won't install postfix
[16:03] <tkamppeter> \sh, can I make ssmtp the one being automatically chosen if no MTA is there?
[16:04] <\sh> sebner: I'm always on..but depending on workload and interesst I'm active or not ;)
[16:04] <sebner> ehehe
[16:05] <LaserJock> tkamppeter: I've got a printing question for you. Do you know of any bugs where printing large pdfs cause the printing dialogs to freeze up?
[16:06] <\sh> tkamppeter: that's a foundation thing...postfix is the default MTA for ubuntu...I don't know if there is a plan for desktops to install a lightweight replacement, cjwatson or whoever is the right person
[16:07] <tkamppeter> cjwatson, ping
[16:07] <cjwatson> meeting
[16:07] <cjwatson> lsb should probably depend on default-mta | mail-transport-agent as documented on ubuntu-devel recently rather than explicitly on postfix
[16:07] <cjwatson> I don't think we should change default-mta to ssmtp
[16:08] <\sh> cjwatson: bsd-mailx is the bugger, which is pulled in by mailx (a dep of lsb-core)
[16:09] <tkamppeter> LaserJock: No, did not know about large PDFs freezing the printing dialog (they can perhaps freeze the filter chain), but I have an idea: evince (at least as of Jaunty and older) produces rather huge print output. So for long PDFs with many pictures the transfer of a job from evince to CUPS can take very long.
[16:10] <LaserJock> tkamppeter: well, what happens is in acroread or evince when I hit the Print menu item the dialog box never really comes up or takes forever
[16:11] <LaserJock> tkamppeter: so before it actually gets to the actual "send it to the printer" bit I think
[16:12] <LaserJock> I'm having to print my dissertation from OS X presently because I haven't been able to in Jaunty :/
[16:12] <tkamppeter> cjwatson, \sh: I want to avoid the problem that if a user installs a distro-independent package (LSB-packages) that a daemon (postfix) gets automatically installed. Especially this should not happen on desktop systems.
[16:14] <tkamppeter> cjwatson, \sh: Especially we will have many manufacturer-supplied printer drivers in the form of LSB packages. It would be very bad to get an MTA daemon only to make the printer working.
[16:16] <tkamppeter> LaserJock: This looks like bugs in the applications, as at that point the printing system is only asked for available printers and this does not depend on the job size.
[16:17] <LaserJock> tkamppeter: ok, thanks, that gives me something to hunt for
[16:18] <cjwatson> tkamppeter: I don't see why that's "very bad".
[16:23] <tkamppeter> cjwatson, adding a daemon is once a potential security problem and second takes resources. Typical LSB-packaged applications and printer drivers do not need a mail server on the local box.
[16:24] <\sh> tkamppeter: postfix by default listens only on 127.0.0.1 and on the ipv6 equivalent of localhost
[16:24] <cjwatson> what he said.
[16:24] <\sh> tkamppeter: there is no harm when there is postfix installed on desktops
[16:25] <tkamppeter> \sh, but it is still taking resources and when one installs postfix the user is asked which type of mail server he wants, not very nice for users who have connected a new printer to their box.
[16:26] <cjwatson> I don't think IRC is the right place for this discussion; it's too complicated. It belongs on the mailing list
[16:26] <cjwatson> and you're saying "must" a lot; please stop, there's more to the question of what default-mta is than this specific requirement
[16:26] <tkamppeter> pitti (or any security expert), WDYT about a printer driver installation pulling postfix?
[16:27] <cjwatson> Martin has already commented on the bug
[16:27] <cjwatson> really, it's not obvious that fixing this specifically in Ubuntu rather than in LSB upstream is the right thing to do
[16:28] <cjwatson> see the upstream bug
[16:28] <pitti> it's a pretty br**** LSB requirement with no obvious solution right now, except for fixing LSB
[16:28] <cjwatson> ssmtp is not going to be any good for the basic requirement of sending status mail which is apparently why sendmail was included in the LSB in the first place
[16:28] <pitti> or vendors not depending on lsb, but on e. g. lsb-printing
[16:28] <cjwatson> lsb-printing depends: lsb-core depends: postfix | mail-transport-agent
[16:29] <pitti> oh, it's even in -core now? darn
[16:30] <pitti> so this seems FUBAR to me :(
[16:30] <tkamppeter> pitti, cjwatson: Are the lsb-... subpackages standardized in the LSB? Or is this Ubuntu-specific?
[16:30] <cjwatson> all I'm saying is that the place to start with this is not "how do we get ssmtp made the default". You need to back up a bit.
[16:30] <cjwatson> LSB Core is an upstream concept
[16:31] <cjwatson> as are the other modules
[16:31] <pitti> tkamppeter: a good place to argue for this is the upstream bug IMHO
[16:31] <pitti> it didn't get much traction yet :(
[16:37] <tkamppeter> cjwatson, pitti, can one perhaps make the situation of Karmic at least a little bit more user-friendly, for example letting postfix automatically install with a default configuration, without asking the user anything?
[16:39] <cjwatson> ask lamont, but I'd support that
[16:39] <pitti> tkamppeter: it's not a problem in karmic per se, just with third-party packages
[16:39] <tkamppeter> lamont, ping
[16:57] <mpt> asac, hi
[16:58] <mpt> asac, I've just been asked: "mpt, if I want Ubuntu to get the wireless driver issues to be sorted out; where would the best place be to donate money?"
[16:58] <mpt> and I have no idea what to answer :-)
[17:01] <asac> mpt: its probably not the "where to donate money", but "where to not spend money" :)
[17:05] <mpt> asac, I found the answer, <http://madwifi-project.org/wiki/Donations>
[17:06] <azeem> mpt: euh
[17:08] <asac> mpt: err. thats madwifi ;)
[17:09] <mpt> asac, I know hardly anything about wireless drivers, so whatever you're implying, it's going over my head with a whoosh
[17:10] <asac> mpt: i say that donating there wont help to resolve general driver issues on linux ;)
[17:10] <asac> mpt: i might be wrong, but are trying to get a away from madwifi drivers
[17:11] <mpt> asac, so is there a human-readable summary somewhere of what people should and shouldn't spend money on?
[17:14] <johanbr> mpt: http://linuxwireless.org/en/users/Devices
[17:24] <mpt> johanbr, thanks, I was hoping for something a little easier to understand :-)
[17:25] <mpt> but that looks fairly comprehensive
[17:26] <johanbr> unfortunately manufacturers change chipsets without changing the name of their devices
[17:26] <johanbr> so you pretty much have to know the PCI id to tell whether a given device will work, that's why it gets a bit complicated
[17:28] <mpt> http://linuxwireless.org/CertificationIdeas looks nifty
[18:38] <al-maisan> hello james_w, re. the merged ibus package .. the "[Control+space]" localisation strings were commented out in the more recent debian debian package
[18:39] <al-maisan> the ubuntu patch brings them back in
[18:39] <james_w> hi al-maisan
[18:39] <james_w> do you know why they were commented?
[18:40] <al-maisan> hello james_w, no, I don't.
[18:40] <al-maisan> Let me dig around a little bit.
[18:40] <james_w> thanks
[18:41] <james_w> we could ask LI Daobing of course
[18:41] <al-maisan> james_w: yes, his comment is just "* new upstream release."
[18:42] <al-maisan> james_w: I can email him and ask; is that a good course of action?
[18:42] <james_w> I'd be tempted to just wait until Monday morning and see if they are around
[18:42] <james_w> or email, yes
[18:42] <al-maisan> OK, great, will do that then and see how far that gets us :)
[18:43] <james_w> cool, thansk
[19:41] <maxb> kirkland: Hi, I just noticed screen-profiles has re-entered Karmic from Debian. I've reopened bug 374162 - if you're around perhaps you could add (or not) your core-dev ack that archive admins will presumably want to see
[19:42] <kirkland> maxb: yeah, will do ... screen-profiles should not be added to karmic as a functional package
[19:42] <kirkland> maxb: though a meta depends on byobu or something might make sense
[19:43] <maxb> Transitional packages built out of the byobu source package, possibly?
[19:43]  * maxb doesn't know if apt is clever enough to migrate based on replaces/provides/conflicts etc. alone
[19:44] <kirkland> maxb: let's try pinging mvo
[19:44] <kirkland> (who isn't around atm)
[19:44] <kirkland> maxb: i'll subscribe him to the bug
[19:45] <maxb> A different bug, perhaps, since the archive admins will close that one after processing it?
[19:46] <Amaranth> maxb: apt will not automatically fetch a package that Replaces a package on the system already
[19:46] <Amaranth> maxb: You'll have to make your new package provide a transitional package
[19:48] <maxb> ah, of course - /me not thinking clearly
[20:07] <slangasek> pitti: hmm, so in light of bug #384511, I guess we should drop hotkey-setup straightaway
[20:37] <ion_> liw: How about this? pe143956 < ion_> Making sure every single deb is always built with gzip --rsyncable -9nf, you could use zsync with a do-not-look-inside-gzip mode, get the major benefits, and the client would only need to gzip data if there’s no older version in cache.
[20:39] <liw> ion_, see the spec as I last edited it; I will run benchmarks comparing various ways of compressing .debs and see what the results are; I'm not really interested in debating which options would be best until I've done the benchmarks
[20:42] <ion_> liw: In my benchmark (in my comments), using --rsyncable and zsync in raw data mode, there only was a 3% transfer overhead for a 454k change in a 30M file. Having to do even a single gzip pass for every single package that’s being updated seems to cause a huge difference in processing time. With --rsyncable and raw data mode, that could be avoided for every package that already exists in apt cache.
[20:42] <ion_> liw: 3% against the look-inside-gzip mode and no --rsyncable.
[20:44] <ion_> liw: But yeah, better do more extensive benchmarking.
[20:46] <ion_> liw: That just seems like the next best choice (mostly great speed *and* almost the same benefit in fetch size), and it should be without major infrastructure changes – just make dpkg-deb use gzip --rsyncable -9nf.
[20:51] <ion_> liw: Oh, and importantly: with zsync in raw data mode, there’s a 100% certainity that the checksum matches (without additional processing), because no re-gzipping is involved in clientside. It’s certainly possible to make the client-side gzip launched by zsync do precisely the same thing as dpkg-deb in the builder, though.
[21:39] <rish> Dell Studio, Jaunty, No sound coming. Touchpad Acting Wierd. Anyone can help??
[21:39] <maxb> rish: Hi, this is a channel for Ubuntu development. For support, try #ubuntu
[21:40] <rish> means people here r open source developers/
[21:41] <rish> how to become an ubuntu developer?
[21:42] <Aquina> Hy! Can one of you lovely geeks tell me please why "SUBDOMAIN_MODULE_PANIC" is set to "XXX" in /etc/apparmor/subdomain.conf?
[21:43] <Aquina> Shouldn't it at least be set wo "warn" or "build"?
[22:12] <Madkiss> hi folks.
[22:13] <Madkiss> If ivoks comes back online, please tell him I didn't mean to be rude by not answering. I was just not in front of my computer :)
[22:20] <Viper550> okay, can ubuntu's installer resize ntfs partitions?
[23:12] <ScottK> Viper550: Yes.
[23:13] <Viper550> oh cool