[00:00] <Chipzz> asac: probably :)
[00:00] <ogra> well, i'm rather struggling with having flash than not having it in most cases
[00:00] <slangasek> heh :)
[00:00] <ogra> but if you want to block it on your ltsp server it definately makes sense to have it globally
[00:00] <Chipzz> ogra: let's for the sake of argument say flash works ;)
[00:00] <asac> Chipzz: your argument is really far away
[00:01] <asac> Chipzz: if you have cycles and can code mozilla, join #ubuntu-mozillateam :)(
[00:01] <ogra> since you might do that because of company policy or school policy
[00:01] <asac> and join forces in fixing the plugin + extension wizard framework for firefox 3.1
[00:01] <Chipzz> ogra: I'm more thinking along the lines of: a lot of users will want to have this, so from a maintainability pov (ie not having hundreds of (possibly out-dated) copies of the extension in ~/.mozilla)
[00:02] <ogra> right
[00:03] <Chipzz> asac: but you haven't answered my question; ie how would that work? would the plugin get copied in ~/.mozilla ?
[00:03] <asac> Chipzz: that doesnt matter at this stage
[00:03] <asac> Chipzz: and that info wouldnt help you.
[00:03] <asac> Chipzz: whatever is needed needs to be done ;)
[00:03] <asac> most likely it wont be copied in .mozilla
[00:04] <asac> maybe it will ... as long as its auto updated if admin updates the global package ;)
[00:04] <Chipzz> asac: well, like I said, it matters from a maintainability pov
[00:04] <Chipzz> ie possibly out-dated
[00:05] <asac> Chipzz: "... as long as its auto updated if admin updates"
[00:05] <Chipzz> yeah
[00:05] <Chipzz> asac: don't get me wrong, I'm not trying to be annoying or get on your nerves ;)
[00:05] <Chipzz> just considering a possible use case
[00:08] <asac> Chipzz: that use-case is well understood
[00:08] <asac> Chipzz: next step would be to write this as a spec
[00:09] <Chipzz> asac: uhu
[00:09] <Chipzz> but anyway, I'm allmost of to bed :)
[00:10]  * ogra sees Chipzz's whois info and wonders what he did with the former versions ...
[00:12] <Chipzz> ogra: ah yes, some old bullshit :) I should probably nuke that ;)
[00:12] <ogra> heh
[00:12] <Chipzz> has been in there for years :P
[00:13] <Chipzz> that's what you get from keeping the same homedir for over 10 years :P
[00:15] <slangasek> I thought what you get for keeping the same homedir for over 10 years is a self-aware fvwmrc
[00:19] <superm1> slangasek, yeah just throw a url over and should be able to run through it at least once at some point
[00:20] <Chipzz> slangasek: lol :)
[01:42]  * Laney is patching pidgin now
[01:45] <lamont> interesting... alsactl, brltty, umount.hal, vstp, wpa_supplicant all live in /sbin and use libs in /usr/lib... --> fail
[01:45] <lamont> (ok, and {mkfs,fsck}.cramfs too... for completeness)
[01:46] <slangasek> on the bright side, grep didn't start depending on libpcre until it was moved to /lib ;)
[02:12] <lifeless> lamont: Score!
[02:15] <lamont> lifeless: isn't it though
[02:16] <lamont> the cramfs one has been around for a while
[02:16] <lamont> http://bugs.debian.org/338604
[02:16] <lamont> it won't be 3 years old for another 4 months or so
[02:18] <TheMuso> The brltty issue I can see what I can do to get that sorted, as I am in contact with upstream, and the DD responsible for the package as well.
[02:20] <TheMuso> Hrm that may not be easy to solve, since brltty tracks the mouse via gpm.
[02:27]  * Hobbsee sighs at ICQ.
[02:30] <calc> slomo: ping
[02:32] <Hobbsee> slangasek: re: kopete, fwiw, i've pushed patches for that issue direct from upstream kde into the stable releases at the time, with no regressions.
[02:32] <calc> slomo: if you see this can you merge mono 1.9.1+dfsg-2 it has SIGSEGV fix for AMD64 and other fixes that are important
[02:33] <Laney> Debdiff for pidgin in bug #244591 for sponsoring if anyone's interested
[02:35] <slangasek> Hobbsee: patches for the ICQ issue?
[02:37] <Hobbsee> slangasek: the version change #'s, yes.
[02:38] <Hobbsee> it didn't have an autoupdater when i last looked at it, though.
[02:38]  * Hobbsee still has nfi why they keep changing the number required every once in a while, when the protocol doesn't appear to change - or at least, no other changes seem to be required apart from the version string.
[02:39] <StevenK> It probably adds the ability to do other things on the server.
[02:40] <calc> everyone should just switch to gtalk :)
[02:40] <Hobbsee> calc: ?
[02:40] <ScottK> I've heard good things about this thing called IRC.
[02:40] <Hobbsee> sure, but why bump the version number in that case?  it hasn't actually had any changes, so any new code on the server side will work with the older version of pidgin.
[02:40]  * StevenK doesn't know what IRC is
[02:41] <StevenK> Hobbsee: Ah, probably because other clients, like the offical one also support the new messages.
[02:41]  * TheMuso notes that bitlbee never seems to require updates for ICQ...
[02:41] <calc> IRC = i repeat classes
[02:41] <StevenK> You say, on IRC
[02:42] <Hobbsee> TheMuso: now, that's interesting.  i thought it was all clients.
[02:42]  * calc is out of school already :)
[02:42] <Hobbsee> StevenK: probably.
[02:42] <calc> but yea i repeated classes when first finding IRC ;-)
[02:42] <ion_> On an unrelated note, TheMuso’s ICQ contacts have been surprisingly quiet recently. ;-)
[02:42] <TheMuso> Hobbsee: Yeah, I've been using ICQ on bitlbee the last few weeks with no issues.
[02:43] <TheMuso> ion_: True, I idle on it the vast majority of the time, but I am logged in.
[02:43] <StevenK> Ah, so that's TheMuso's secret. He never logs out of ICQ, therefore never gets the oppurunity to get the error message.
[02:44] <LaserJock> people still use ICQ?
[02:44]  * TheMuso tests logging out/in now to see if anything happens.
[02:44] <Hobbsee> LaserJock: ++
 oscar - Logging in: Signon: 18444344
 oscar - Logging in: Connection established, cookie sent
 oscar - Couldn't log in: SNAC threw error: Busted SNAC payload
 oscar - Logging in: Logged in
[02:45] <LaserJock> I just can't get Jabber to work with pidgin, couldn't care less about ICQ ;-)
[02:55] <saivann> Can a GNOME developer take a look at patches in this bug report : https://bugs.edge.launchpad.net/ubuntu/+source/gnome-panel/+bug/187540
[02:55] <saivann> I tested the patches and it works correctly in my case
[02:59] <Laney> Bug #244591 awaits SRU approval :)
[03:07] <lamont> so how much pain is it to get a broadcom NIC working under hardy?
[03:07] <lamont> compaq box with BCM94311MCG
[03:07]  * lamont waits for the flamage
[03:30] <calc> wow i can refuse to fix people's computers now on not wanting to violate a law
[03:30] <calc> apparently we have some really stupid well bribed people here in texas :-\
[03:31] <calc> if you fix a computer or ask to have a computer fixed by a non private investigator you can be sent to jail for 1yr
[03:32] <StevenK> You now need to be a private investigator to fix a computer?
[03:32] <brandonperry> yeah
[03:32] <brandonperry> it is retarded
[03:32]  * brandonperry used to be a computer technician
[03:36] <lifeless> wtf
[03:36] <ion_> calc: :-D
[03:36] <lifeless> URL ?
[03:36] <persia> Is this law related to some disclosure statute, or just gratuitous?
[03:48] <persia> Bah.  It's interpretive.  http://www.legis.state.tx.us/tlodocs/80R/billtext/html/HB02833F.htm allows retailers to service on-site, and allows lots of other exceptions if security is not the primary area of business for the affected person.  Plus, employees of a firm with any of a PI, law, or accounting license are exempt.
[05:21] <YokoZar> cjwatson: ping
[05:22] <YokoZar> cjwatson: Could you please take a look at https://bugs.edge.launchpad.net/hardy-backports/+bug/240755 if you haven't already?  Just a small update that you might of missed since I reopened the bug weirdly rather than filing a new one.
[05:29] <ScottK> YokoZar: I approved a big stack of backports (cleared out the Hardy backlog) on Sunday.  Not sure what order they'll get done in.
[05:34] <calc> anyone know how to properly branch a bzr repo, i need to branch one from bzr.debian.org into launchpad
[05:36] <RAOF> calc: Do you want it mirrored, or a one-off branch?
[05:36] <RAOF> calc: Because if you want it mirrored you can register it on launchpad and LP will mirror it for you.
[05:36] <calc> hmm, what is the difference?
[05:36] <calc> i need to commit stuff to the lp one as well
[05:36] <calc> so i guess not just mirrored
[05:37] <calc> its for OOo 3.0 packaging
[05:37] <RAOF> Right.  So, you'd just bzr branch $REMOTE, then bzr push lp:wherever-it-should-go.
[05:37] <calc> so $REMOTE equals my full bzr+ssh path?
[05:38] <RAOF> Yes.
[05:38] <calc> hmm actually i need the other bzr repo to be a subdir of the new one
[05:38] <calc> is that possible?
[05:38] <RAOF> I'm not sure what you mean.
[05:39] <calc> eg debian has the top level dir be the debian dir i need it to be the package dir so i can have a ubuntu dir beside the debian one (same level hierarchy)
[05:39] <calc> eg ooo-3.0/debian and ooo-3.0/ubuntu
[05:39] <calc> and the debian bzr has the top level bzr as just the debian dir
[05:39] <RAOF> That's just naming the branch, though?
[05:40] <bliZZardz> cjwatson, reg DBus - how is it different from messaging solutions? (i could not find this in the wiki)
[05:40] <calc> i don't think so?
[05:40] <calc> instead of top of the bzr branch being debian it needs to be ooo-3.0
[05:40] <calc> that isn't just naming at least aiui
[05:41] <calc> because in the ubuntu version i need to also have a ubuntu dir as well which means my top level needs to be one dir higher than how it is setup on bzr.debian.org
[05:41] <RAOF> Why do you need both the Ubuntu and Debian debian/ dirs in your branch?
[05:41] <calc> i have to modify the debian dir for ubuntu and some of the ubuntu specific stuff is under the ubuntu dir as well
[05:42] <RAOF> Isn't the idea to take Debian's debian/, make the Ubuntu changes, and commit that?
[05:42] <calc> well yea, but we have other files such as artwork, etc that is version controlled for ubuntu and it is under ubuntu dir instead
[05:42] <calc> i guess to be able to branch it cleanly i would need to move all of that under the debian dir?
[05:42] <RAOF> calc: Wait - we've got both a debian/ and ubuntu/ dir in the package?
[05:43] <calc> yes
[05:43] <calc> is there a way to branch into an already existing repo
[05:43] <RAOF> No, not yet.
[05:43] <calc> ok
[05:43] <lifeless> RAOF: what do you mean?
[05:43] <calc> some other way to cause my branch to be a subdir of a new repo?
[05:43] <lifeless> RAOF: by 'not'
[05:44] <RAOF> lifeless: You can't attach branches to arbitrary subtrees?
[05:44] <lifeless> do you mean 'bzr join' ?
[05:44] <lifeless> RAOF: or do you mean 'partial checkout' ?
[05:45] <lifeless> also, if you consider teh proposed best practice, we want a single tree with the packaging & patches in a loom, not disjoin versioned data
[05:45] <RAOF> lifeless: Wow.  bzr help join looks like fun.
[05:46] <calc> lifeless: so its possible to do that then?
[05:47] <lifeless> calc: well I still don't understand the question
[05:47] <lifeless> calc: you asked about repositories, and they -exist- to have many branches within them.
[05:47] <lifeless> RAOF: seems to be suggesting you didn't mean repository
[05:47] <calc> lifeless: i need to somehow branch the openoffice packaging bzr from bzr.d.o into a subdir of my bzr for OOo 3.0 packaging
[05:48] <lifeless> calc: are they currently related?
[05:48] <calc> lifeless: for < 3.0 i was just copying the data over so i want to do it right for 3.0
[05:48] <calc> and i don't know enough about how bzr works to actually set it up right
[05:48] <lifeless> calc: I advise doing what you were doing while james_w bring up the toolchain
[05:49] <lifeless> calc: and send him a mail saying what you were wanting to do :P
[05:49] <calc> in the past i just hand merged from debian's bzr
[05:49] <calc> with no history, etc
[05:49] <lifeless> calc: if they are not related, that will be easiest
[05:49] <calc> i'm confused
[05:49] <calc> what is this about related? :)
[05:50] <lifeless> calc: did the bzr packaging start as a branch off your oo branch?
[05:50] <lifeless> calc: or vice verca?
[05:50] <lifeless> calc: or neither
[05:50] <calc> neither
[05:50] <lifeless> so, 'bzr merge' doesn't know what to do, or how things should be connected
[05:50] <lifeless> https://code.edge.launchpad.net/~bzr/bzr-merge-into/trunk
[05:50] <calc> but for the future i was hoping to try to branch it off from debian if possible to keep history with them
[05:51] <calc> i don't even know how to begin to make it work
[05:51] <lifeless> calc: right, and we're trying to do that for 13K branches
[05:51] <calc> since the top level dirs aren't the same
[05:51] <lifeless> which is why I'm saying *don't* special case it yet, just pester james_w with your use case
[05:51] <calc> oh
[05:52] <lifeless> if we're writing a toolchain to set it up automatically/trivially it isn't a great use of your time to scale the learning curve for one package right now
[05:52] <calc> ok
[05:52] <lifeless> IMO of course. If you want to do it regardless - the bzr-merge-into plugin is what you'll need to join the two branches together.
[05:53] <calc> his email is jamesw@ubuntu.com ?
[05:53] <lifeless> check the directory
[05:53] <lifeless> I don't recall offhand
[05:54] <calc> ok
[05:58] <StevenK> Aww, bzr join no worky for me
[05:59] <RAOF> But bzr split works!  Funky.  bzr-mirror.gnome.org just got a lot more awesome.
[06:03] <lifeless> RAOF: happy to please
[06:03] <TheMuso> Hrm. Something in the hardy-proposed/updates jungle is broken. http://www.pastebin.ca/1060232
[06:14] <kahrytan> When is Ubuntu going to start using gfxboot  with grub? openSUSE and Linux Mint have the right idea. grub in ubuntu is ugly. and makes ubuntu look unpolished.
[06:18] <StevenK> Yay for a drive-by feature request
[06:18] <RAOF> Wasn't that one of those many apps that won't work on !x86?
[06:19] <Hobbsee> StevenK: yeah, 'ive had the misfortune of watching that.
[06:19] <StevenK> I thought it also rendered some machines unbootable
[06:19] <RAOF> Well, if it failed then presumably the bootloader does, too.
[06:25] <TheMuso> RAOF: But non-x86 architectures use different boot loaders.
[06:26] <RAOF> TheMuso: I was sure grub supported more than x86.  Doesn't it?
[06:26] <TheMuso> RAOF: Grub2 des i think, but I am not sure about grub that Ubuntu uses.
[06:26] <TheMuso> s/des/does/
[06:27] <RAOF> The vagries of boot loaders.  Hm.
[06:31] <dholbach> good morning
[06:32] <dholbach> bdmurray: can you merge thekorn's fix for making the HTML connector work again or did you find any problems with it?
[06:32] <Hobbsee> hey dholbach
[06:32] <dholbach> hi Hobbsee
[06:42] <cody-somerville> Good Morning folks :)
[06:47] <nxvl> damn cheap connection
[06:48] <Hobbsee> nxvl: find a better one?
[06:49] <nxvl> Hobbsee: there is no better one
[06:49] <nxvl> just 1 ISP
[06:49] <Hobbsee> nxvl: where are you?
[06:49] <nxvl> Lima Peru
[06:49] <Hobbsee> ahhh, drat.
[06:50] <nxvl> the governmet sign a contract with Telefonica giving them the monopoly for several years
[06:50] <Hobbsee> ugh
[06:50] <jpds> nxvl: I feel your pain.
[06:50] <nxvl> and it has just expire so the 1st ISPs are shoing up, but they don't have good coverage
[06:50] <nxvl> 1sts*
[06:51] <nxvl> jpds: where are you from?
[06:51] <nxvl> Hobbsee: can you belive that they sell you a bandwith but they only ensure the 10% of it?
[06:52] <jpds> nxvl: Right now I'm in Spain with Telefonica as ISP (cos they're the only ones who reach here).
[06:52] <nxvl> heh
[06:52] <nxvl> :D
[06:52] <Hobbsee> heh
[06:52] <slangasek> on the bright side, it could be worse
[06:53] <slangasek> it could be Telstrafonica
[06:53]  * StevenK shivers
[06:53] <nxvl> here we call them timofonica, timo = swindle
[07:01] <pitti> Good morning
[07:01] <StevenK> Morning pitti
[07:02] <nxvl> morning!
[07:02] <pitti> ogra: versioned sysv-rc dependency> no, it's not needed any more
[07:03] <TheMuso> slangasek: Even Telstra doesn't give it as badly as what those guys have to experience.
[07:03] <nxvl> i just love when upstream projects take care of your suggestions/patches
[07:03] <slangasek> TheMuso: Telstrafonica would be a merger that adopts the worst practices of each, standard operating procedure for corporate mergers :)
[07:04] <pitti> BenC: I'll get to MIRs today, yes
[07:04] <TheMuso> slangasek: This is true.
[07:04] <nxvl> well
[07:04] <slangasek> pitti: morning
[07:04] <nxvl> when i call them for techincal support i end up giving them technical support
[07:05] <pitti> superm1: modaliases> first, the standard kernel one, then /usr/share/jockey/modaliases/, then /usr/share/linux-restricted-modules/<kver>/modules.alias.override/
[07:05] <nxvl> one time a technical comes here because my bandwith was the half or less than i really have, and he said it was a problem on my router!
[07:06] <Hobbsee> hey pitti!
[07:06] <pitti> fabbione, ogra: I didn't try dvb-t drivers on intrepid yet, sorry; I'm still on hardy; if there is a patch I should apply to my driver package, I can do that, of course
[07:08] <pitti> Riddell: right, looks ok
[07:09] <pitti> Riddell: accepted
[07:10] <pitti> hey slangasek, hi Hobbsee, moin StevenK
[07:16] <superm1> pitti, so for the purposes of nvidia/fglrx, where do you think you would like to see it placed?  Probably the second one.
[07:16] <superm1> it's sole purpose is for the jockey enablement
[07:20] <pitti> superm1: the third path was meant for that actually
[07:21] <pitti> superm1: oh, for dkms packaging?
[07:21] <superm1> pitti, but the kernel version isn't known
[07:21] <pitti> superm1: yes, then the second one
[07:21] <superm1> okay.  i'll upload a fix sometime tomorrow then to use that second one
[07:22] <bliZZardz> pitti : i was searching for you over the last couple of days.
[07:22] <pitti> bliZZardz: I was on holiday
[07:23] <bliZZardz> pitti : yea - your status said that you were away for 4 days. welcome back :)
[07:23] <bliZZardz> pitti : I wanted to know some internals of Dbus and how it is being used in Gnome
[07:23] <pitti> bliZZardz: not sure how much I can be of help there, but what's your q?
[07:25] <bliZZardz> pitti : (1) Does dbus use sockets for communication?if not, which is the IPC mechanism? (2) how id dbus different from a typical message queue? (3) How it is being 'actually' used across applications? - as in , is this like a callback mechanism for across-applications?
[07:26] <pitti> (1) yes, it uses standard Unix sockets
[07:26] <pitti> bliZZardz: (2) what is a 'typical message queue'?
[07:27] <pitti> bliZZardz: d-bus' complexity is somewhat in between a socket and corba
[07:27] <pitti> bliZZardz: d-bus has signals, method calls, callbacks, and data type marshalling/handling
[07:27] <lifeless> closing in on corba daily
[07:28] <pitti> bliZZardz: (3) there are two classes of use cases: (1) session bus, where programs on the session bus communicate with each other; e. g. totem tells gnome-screensaver to disable while a video is playing
[07:29] <nxvl> heh
[07:29] <pitti> and the system bus, where programs from the user session access system-wide functionality (usually access restricted); e. g. nautilus gets aware of a new USB drive by HAL, and then issues a mount
[07:29] <nxvl> pitti can always help on anything, no matter what he says
[07:29] <nxvl> :D
[07:29] <nxvl> that's why we love pitti
[07:29] <pitti> bliZZardz: callback> something similar; programs can 'subscribe' to signals, which indicate status changes
[07:30] <bliZZardz> nxvl : you bet ;)
[07:30]  * pitti hugs nxvl
[07:30]  * nxvl HUGS pitti back
[07:30] <bliZZardz> pitti : callbacks more like 'intra-process' communication
[07:30] <pitti> nxvl: well, with "d-bus internals" I was afraid of something like marshalling formats :)
[07:30]  * bliZZardz hugs everyone...provided you smell good and of opp gender ;)
[07:30] <bliZZardz> pitti : that was my next Q :)
[07:31]  * pitti tries to estimate the probability of hugging a girl when picking a random member of #ubuntu-devel
[07:31]  * bliZZardz concludes probability = ZERO
[07:31] <pitti> bliZZardz: not true
[07:31] <nxvl> ugh, launchpad is broken
[07:32] <bliZZardz> nxvl : ??
[07:32] <nxvl> bliZZardz: i'm looking for some bugs and i only get error messages
[07:34]  * jussi01 hugs Hobbsee
[07:34] <bliZZardz> nxvl : interesting. what did you search ;) ?
[07:35] <nxvl> i first get it going to b.e.lp.n/ubuntu
[07:35] <nxvl> which is really odd
[07:35]  * Hobbsee hugs jussi01 back :)
[07:35] <Hobbsee> pitti: almost 0, yeah.
[07:36] <jussi01> better chances in #kubuntu-devel
[07:41] <fabbione> pitti: nah.. i was just trying to figure out if my driver is broken or the kernel subsystem. Not sure .26 needs new userland
[07:42] <bliZZardz> pitti : will it be possible to do a code-walkthrough of Dbus? (i get confused when i look at it; or can you point me to some tutorials which would be of some help)
[07:47] <pitti> bliZZardz: that's where it becomes internal; I read very little of the d-bus code myself
[07:47] <pitti> bliZZardz: what kind of tutorial? http://dbus.freedesktop.org/doc/dbus-tutorial.html is a nice one for programmers
[07:50] <fabbione> pitti: btw... what drivers do you have in your ppa? or is it only userland stuff?
[07:50] <fabbione> because i can reproduce this problem using latest mercurial from linux-dvb
[07:50] <pitti> fabbione: it's a pretty recent snapshot of the upstream dvb-t hg tree, DKMSified
[07:50] <fabbione> and it's basically the same as in .26-rc8
[07:50] <fabbione> or whatever is the current git from linus
[07:51] <fabbione> ok so it's pretty much the same crack
[07:51] <fabbione> pitti: do you use dvb-t?
[07:51] <pitti> fabbione: yes, I have a card
[07:51] <fabbione> ok
[07:51] <pitti> I don't *actually* watch TV, I just bought it for playing around
[07:51] <fabbione> ehhehe
[07:52] <pitti> fabbione: the soccer championship was the first time I actually watched TV :)
[07:52] <fabbione> ROFL
[07:52] <bliZZardz> nxvl : LP is sick , i guess .. i went on to file a bug , and saw one more bug in the process :)
[07:54] <dholbach> slomo: do you have an idea about bug 197763 - somebody pinged me about it
[08:00] <fabbione> hmmmmmmmmmmmm
[08:00] <fabbione> pitti: looks like downgrading the kernel doesn't solve the problem.....
[08:01]  * fabbione tries to go back to a known working version
[08:01] <pitti> fabbione: what is the problem?
[08:01] <pitti> fabbione: I noticed that if I build the tree, some modules from l-u-m break (especially the alsa related)
[08:01] <fabbione> when i try to scan for channels, it timeouts
[08:01] <pitti> I tried to build linux-dvb against the l-u-m headers as well, but that didn't seem to have worked :(
[08:02] <pitti> oh
[08:02] <fabbione> scan -n /usr/share/doc/dvb-utils/examples/scan/dvb-t/dk-All
[08:02] <fabbione> WARNING: filter timeout pid 0x0011
[08:02] <fabbione> etc.
[08:02] <fabbione> this used to work
[08:02] <fabbione> pitti: all the header stuff is a very well known packaging issue but i thought it was addressed
[08:15] <pitti> BenC: makedumpfile promoted, and bug 244780 tossed towards you
[08:16] <fabbione> pitti: this smells like userland brekage
[08:16] <pitti> warp10: did you get my reply wrt. gbemol? I didn't get an updated package, and debomatic.linuxdc.it times out
[08:16] <fabbione> pitti: somewhere that is not even related to dvb-utils
[08:17] <warp10> pitti: I just sent you an email. BTW, I uploaded gbemol on mentors.debian.net
[08:17] <pitti> fabbione: oh, good to know; hm, but where else then? maybe a slight change in glibc 2.8?
[08:17] <pitti> warp10: ah, good
[08:18] <pitti> warp10: I still have tons of email to dig through after my vac, but I'll get to it
[08:18] <warp10> pitti: no problem, take your time, and thank you for sponsoring! :)
[08:19] <pitti> heno, slangasek: many thanks for https://wiki.ubuntu.com/RCBugTargetting; finally some guidelines \o/
[08:19] <fabbione> pitti: dunno yet... there are so many places where it might be broken
[08:20] <pitti> fabbione: do you see a long hang in strace?
[08:20] <fabbione> pitti: i can see the ioctl timing out...
[08:22] <fabbione> ok this is going to take a fair amount of time..
[08:23] <fabbione> pitti: i will give you a head up once i get somewhere more solid
[08:41] <pitti> fabbione: good luck! thanks
[09:12] <dholbach> thekorn: hiya - did bdmurray say anything about merging your intrepid.merge branch?
[09:14] <dholbach> thekorn: it'd be nice to have it in .main - http://people.ubuntu.com/~dholbach/sponsoring/ is broken without it :)
[09:15] <thekorn> dholbach: hi, definitely. I think I will do the merge when I'm back home later today
[09:15]  * dholbach hugs thekorn
[09:15] <dholbach> thekorn: you ROCK :)
[09:15] <dholbach> there are no other words for it... you rock! :)
[09:18]  * thekorn hugs dholbach
[09:22] <fabbione> pitti: found the problem... kernel bug
[09:22] <pitti> hah
[09:25] <Hobbsee> asac: when's nm 0.7 planned to go into intrepid?
[09:25] <Hobbsee> my 0.6 version is not behaving at all, yet the hardy version does.
[09:25] <fabbione> and once again udev dropped the vbi symlink patch
[09:25]  * fabbione sighs
[09:26] <ogra> fabbione, waht chipset is that ? wht driver are you using ?
[09:27] <fabbione> HVR3000
[09:27] <fabbione> cx88-dvb
[09:28] <ogra> hmm
[09:29] <fabbione> ogra: http://www.fabbione.net/hvr3000-fix-init.diff
[09:29] <fabbione> easy fix
[09:29] <ogra> i'm using dvb-usb-umt-010 and know there is one special fix i need
[09:30] <ogra> oh, wow, thas bigger then the one i need :) mine is only changing a 20 to a 10 i the defines ....
[09:30] <ogra> run it though timg, he'll surely commit it asap
[09:32] <ogra> s/tmg/rtg/
[09:38] <heno> pitti: np
[09:39] <asac> Hobbsee: consider to test the 0.7 packages in  ~network-manager PPA
[09:40] <fabbione> ogra: well.. my original patch is here: http://dev.kewl.org/hauppauge/mfe-7285.diff
[09:40] <fabbione> ogra: but that's to support dvb-t + dvb-s at the same time
[09:40] <Hobbsee> asac: right, will try tomorrow
[09:40] <ogra> your card can do thyt ?
[09:40] <ogra> *that
[09:40]  * ogra is impressed ....
[09:41] <fabbione> ogra: yes.. mine can do dvb-t dvb-s analog tv, radio and usual RGB/s-video stuff
[09:41] <ogra> i have two separate cards for that (and dont actualy use either :P )
[09:41] <fabbione> well i also have other dvb-s cards.. but no extra dvb-t
[09:42] <ogra> the program selection for dvb-t in the area where i live sucks anyway, so i'm not really after it ... i sometimes use it if my GF wants to look somethig i dont so i go upstaris and whatch in my office :)
[09:42] <ogra> but thats very rare
[09:42] <fabbione> ogra: i have 3 channels here from -t
[09:44] <ogra> well, i have 7 or so .. but the content isnt really great :) they dont allow private stations into the dvb net ....
[09:44] <ogra> s/dvb/dvb-t/
[09:44] <fabbione> gotcha
[09:45] <gnomefreak> was nvidia-glx-new pulled from repos in last day or so?
[09:45] <gnomefreak> the 2.6.26 version
[09:46] <ogra> i dont think it ever entered
[09:46] <gnomefreak> the drivers were working before i reinstalled now they are not
[09:46] <ogra> as far as i heard the closed driver stuff is being reworked atm
[09:46] <gnomefreak> this happened on sunday IIRC
[09:47] <ogra> so it would surprise me if the old nvidia stuff even enters itrepid
[09:47] <gnomefreak> ah ok thanks i will boot 2.6.24 than
[09:47] <seb128> pitti: I'm already building those pidgin updates, just to let you know so you don't duplicate work there
[09:47] <seb128> pitti: got the intltool errors?
[09:48] <pitti> seb128: oh, thanks; I was just doing the same and wondered about the intltool FTBFS
[09:48] <seb128> pitti: that's a classic one, either intltoolize needs to be run or intltool not to be installed
[09:48] <seb128> that's a bug in the package but not new
[09:48] <pitti> but intltool is a build dep
[09:48] <seb128> ok, so that's not it
[09:49] <seb128> it doesn't happen in a pbuilder or on the buildd
[09:49] <pitti> Global symbol "@INTLTOOL_ICONV" requires explicit package name at ../../intltool-merge line 96.
[09:49] <seb128> but happens on my boxes if I don't run intltoolize
[09:49] <seb128> dunno why, I never bothered debugging it
[09:49] <pitti> it looks like some .in file was copied instead of macro-processed?
[09:49] <seb128> but that's buggy this way since before hardy
[09:49] <pitti> seb128: ok, so you are building test packages in a pbuilder?
[09:50]  * pitti hugs seb128, thanks for taking care about this
[09:50] <Ng> asac: ppa nm is working pretty well, modulo its odd new behaviours. I don't seem to be having to kill wpa_supplicant either :)
[09:50] <seb128> yes, or just run intltoolize -c -f for the intrepid build
[09:50]  * seb128 hugs pitti
[09:51] <mvo> asac: yep, works well for me too, good work!
[09:53] <Ng> asac: I am getting some syslog entries about security policies preventing it acquiring "the NetworkManagerSystemSettings service" though
[09:53] <asac> Ng: so no two instances running after resume?
[09:54] <asac> Ng: do you have /usr/share/dbus-1/system-services/org.freedesktop.NetworkManagerSystemSettings.service ?
[09:55]  * ogra points asac and Ng to d-feet ... awesome dbus debugger 
[09:56] <asac> ogra: i think we are not yet there, but thanks ;)
[09:57] <mvo> ogra++
[09:58] <heno> *** Hardy.1 candidate images are now up at http://iso.qa.ubuntu.com/qatracker/build/all Please help test! ***
[09:59] <slangasek> heno: fwiw, I unfortunately have one more respin of the desktop images to do (excluding kubuntu/kubuntu-kde4, which are done)
[09:59] <slangasek> I should have done it earlier, but I was fighting with the larger archive problem :/
[10:00] <ogra> slangasek, but alternate are ready to test ?
[10:00] <slangasek> yes
[10:00] <heno> slangasek: ok, good thing I've been focusing on alternate then :)
[10:00] <seb128> pitti: the pidgin build issue is due to automake1.10 apparently, the patches probably change some timestamp and the build system decided to run the autotools-1.10, if they are not available the build works correctly, if they are available somebody gets screwed
[10:01] <ogra> ogra@osiris:~/Isos/hardy$ rsync -az --progress rsync://cdimage.ubuntu.com/cdimage/daily/20080701/hardy-alternate-i386.iso hardy-alternate-i386.iso
[10:01] <ogra> receiving file list ...
[10:01] <ogra> rsync: link_stat "/daily/20080701/hardy-alternate-i386.iso" (in cdimage) failed: No such file or directory (2)
[10:01] <ogra> hmm
[10:01]  * ogra checks the link
[10:02] <james_w> ogra: you're missing a /hardy/
[10:02] <slangasek> see the notes at the bottom
[10:02] <pitti> seb128: ah, ok; that's not a build dep, thus explains the issue
[10:02] <james_w> rsync://cdimage.ubuntu.com/cdimage/hardy/daily/current/hardy-alternate-i386.iso
[10:02] <ogra> james_w, i copy pasted the link from the iso tracker
[10:02] <slangasek> er, at the top
[10:02] <slangasek> Note: The download links for Hardy images are not correct. Please use http://cdimage.ubuntu.com directly.
[10:03] <ogra> ah, http://iso.qa.ubuntu.com/qatracker/info/1708 doesnt have that note ...
[10:03] <seb128> s/somebody/something too ;-)
[10:03] <ogra> i missed that on the former page :)
[10:07] <asac> Ng: ok, i uploaded a new package revision to PPA which should have the missing policy files
[10:09] <Ng> asac: cool :)
[10:09] <Ng> asac: in answer to your question, I do have that dbus service file
[10:11] <asac> Ng: yeah. found that i forgot two policy files. lets see if you need to kill the supplicant in turn ;)
[10:11] <Ng> aha
[10:12] <Ng> asac: I was chatting to someone in #nm yesterday about the weird new multiple-network-connections behaviour. I really hope they allow that to be disabled ;)
[10:12] <asac> Ng: once you dont get that message anymore you can test system-configuration that in theory starts up your wiki connection without logging in as user
[10:12]  * ogra grins about pitti "unless we will throw all of rc?.d/ away anyway in favor of some upstart scripts." ... high hopes :)
[10:12] <asac> Ng: yeah. the applet will get a redesign
[10:12] <Ng> asac: will do
[10:12] <asac> s/wiki/wifi/ :)
[10:16] <cjwatson> YokoZar: done. BTW, was it intentional that debian/patches/fix-system-tray.patch was dropped without a changelog entry to that effect?
[10:24] <asac> smurf: my ubuntu-l10n-de membership is about to expire.
[11:00] <james_w> is there a list of packages which are blacklisted from syncing anywhere?
[11:01] <james_w> I'm interested in the ones where we have the package but never want to sync it. I believe udev falls in to this category.
[11:01] <wgrant> james_w: http://people.ubuntu.com/~ubuntu-archive/sync-blacklist.txt
[11:01] <james_w> great, thanks
[11:06] <YokoZar> cjwatson: oh, the patch was dropped in an earlier release (it's part of 1.0 upstream now), I think I wrote that in an earlier changelog but didn't actually delete it
[11:06] <cjwatson> ok
[11:10] <YokoZar> cjwatson: anyway, thank you
[11:11] <slomo> dholbach: no idea, sorry
[11:13] <dholbach> slomo: OK :/
[11:18] <dholbach> thekorn: does http://paste.ubuntu.com/24437 look OK to you?
[11:19] <dholbach> thekorn: I'd be interested to know if that's all I'd need to change to get the new fiveaday out into the open :)
[11:24] <thekorn> dholbach: looking a the code, it changed a bit since I looked at it the last time ;)
[11:25] <dholbach> thekorn: be sure to pull the latest
[11:25] <dholbach> thekorn: I replaced some embarassing code with something hopefully saner
[11:36] <thekorn> dholbach: i think it looks good,
[11:36] <dholbach> ROCK
[11:36] <dholbach> I'll get it uploaded soon :)
[11:36] <thekorn> ROCK!
[11:38]  * dholbach hugs thekorn
[12:02] <asac> Hobbsee: what kind of probs do you see with nm 0.6 in intrepid?
[12:10] <wgrant> asac: Are we getting NM0.7 at some point?
[12:11] <asac> wgrant: now can the answer be no? :-D
[12:11] <asac> wgrant: are you on hardy still?
[12:11] <wgrant> asac: I'm running Intrepid.
[12:11] <asac> wgrant: then you are out of luck. have to make it compile there
[12:11] <asac> wgrant: if you want to help, go ahead ;)
[12:15] <seb128> dholbach: why did you subscribe me to bug #244591?
[12:16] <ln-> clearly not a critical bug, no need to be fixed.
[12:16] <dholbach> seb128: sponsoring?
[12:17] <seb128> dholbach: I did sponsor the hardy update some hours ago and I don't see something else to sponsor?
[12:17] <seb128> dholbach: just wondering if I missed something
[12:17] <dholbach> oh ok - if it's all done that's fine then
[12:17] <dholbach> ROCK
[12:17] <seb128> should I unsubscribe the sponsoring team in this case?
[12:17] <dholbach> yeah, that sounds good
[12:17] <dholbach> thanks seb
[12:17] <seb128> cool
[12:17]  * seb128 hugs dholbach
[12:19] <cjwatson> ln-: err, there's a critical task on that bug
[12:19] <cjwatson> ln-: and brief observation would reveal that it's being fixed
[12:20] <ln-> so i notice.
[12:21] <pitti> seb128: btw, does the patch apply to dapper/feisty/gutsy as well?
[12:21] <dholbach> thekorn: new 5-a-day uploaded :)
[12:21] <pitti> seb128: and there's also an intrepid fix; do you want me to upload that one, or are you preparing it already?
[12:21] <dholbach> let's see how it works out :-)
[12:22] <seb128> pitti: as commented on the bug I've an intrepid upload ready, I'm just waiting because upstream has no tar.gz and I would like to avoid having a different orig.tar.gz than debian
[12:23] <pitti> ah, nice
[12:23]  * pitti hugs seb128
[12:23] <seb128> pitti: I didn't look at dapper to gutsy yet, and I've no install to test those easily
[12:23]  * seb128 hugs pitti
[12:30] <seb128> pitti: the pidgin patch applies to the gutsy version
[12:31] <seb128> pitti: I've no gutsy box to test the build and run the update though and I would like to avoid having to install gutsy only for that
[12:32] <thekorn> dholbach: ok, super, will test it later today
[12:32] <dholbach> ROCK :)
[12:34] <thekorn> :)
[12:38] <Laney> seb128: I'm testing it now
[12:38] <seb128> Laney: the gutsy version?
[12:38] <Laney> seb128: Yes
[12:38] <seb128> cool, thanks
[12:39] <Laney> When gmail's imap decides to start working again...
[13:00] <pitti> seb128: I have chroots and can test it there if you want me
[13:01] <Laney> seb128, pitti: Works fine, uploading debdiff now
[13:04] <pitti> Laney: many thanks
[13:05] <Laney> pitti: No probs, it's up now
[13:05] <mvo> seb128: I have a gutsy VM if needed
[13:10] <fabbione> oh boys.. this is so painful
[13:10] <pitti> fabbione: still kernel fighting?
[13:11] <fabbione> pitti: so the problem is in the driver, the init code does something wrong and different if the card is cold booted or warm booted. The latter doesn't re-init the card properly so if a previous version of the driver was messing things up, you keep the mess as long as you don't poweroff
[13:11] <fabbione> pitti: yeah.. trying to fix this
[13:11] <cody-somerville> pitti, could you accept xubuntu-default-settings in hardy-proposed queue? It is an important SRU that I'd like to try and squeeze into .1
[13:11] <pitti> cody-somerville: sorry, you have to coordinate that with slangasek
[13:12] <cody-somerville> pitti, oh. Is -proposed frozen for .1 or something?
[13:12] <ScottK> cody-somerville: It is.
[13:12] <pitti> cody-somerville: yes, .1 will be released tomorrow, and is being tested now
[13:19] <gnomefreak> has anyone seen the grep -i bug?
[13:19] <gnomefreak> bug 243717 it seems everyone is complaining about it at this time
[13:54] <pitti> Keybuk: any ETA on the intrepid spec approval?
[13:55] <Keybuk> pitti: am reading through them today, as it happens
[13:55] <pitti> ah, sweet, thansk
[13:57] <ScottK> pitti: Thanks for the stack of MIR approvals.
[13:57] <pitti> ScottK: thanks go to doko this time
[13:58] <ScottK> pitti: I have an amavisd-new upload to do in the next few days, so it would be efficient if the Sendmail MIR was done so I could unsplit the package at the same time.
[13:58] <ScottK> doko: Thanks for doing all the heavy lifting on my stack of MIR.
[13:58] <pitti> ScottK: ok, I can do that alongside hardy.1 CD testing
[13:59] <ScottK> Great.
[14:00] <ScottK> doko: Did you see the python-central patch I posted earlier in the week?
[14:00]  * pitti thinks that the "sensible-mda" package built by sendmail is just slightly exaggerated
[14:00]  * ScottK agrees.
[14:01] <ion_> :-D
[14:01] <pitti> well, admittedly it's by the same definition of "sensible" that goes for the vim default of sensible-editor :-P
[14:02] <ion_> vim and emacs both. :-)
[14:02] <pitti> . o O { we need to split sensible-editor into dwim-editor and nerd-editor }
[14:03] <ion_> Oh, btw, nowadays sensible-editor seems to ask the user to pick one and saves that as a per-user default.
[14:05] <pitti> right
[14:12] <pitti> ScottK: done
[14:13] <ScottK> pitti: Thanks.
[14:14] <ogra> pitti, https://launchpad.net/vigedit we should just default to gedit and default to that :)
[14:14] <ScottK> Hopefully my amavisd-new NMU will get sponsored today too and I can upload an unsplit package with DKIM enabled (the spec goal) tomorrow.
[14:14]  * BenC hugs pitti
[14:15] <ion_> vigedit, huh? What’s wrong with plain gvim? :-)
[14:15] <ogra> gvfs/gnome-vfs suport for example
[14:16] <ogra> apart from the fact that every editor should have a vi mode anyway, else its not a real editor :)
[14:16] <ion_> That could be added to vim-gnome, i reckon.
[14:16]  * ogra hides
[14:19] <seb128> pitti: I've sponsored the pidgin gutsy update, the patch is similar to the hardy version and Laney has tested it on gutsy
[14:24] <cjwatson> pitti,doko: any objection to me promoting libelf1 as obvious (for makedumpfile)? I can't see an ELF library causing a problem
[14:25] <pitti> cjwatson: I asked BenC to use libelf1g-dev instead
[14:25] <pitti> cjwatson: we already have libelf in main, so I'd rather use that
[14:25] <cjwatson> oh, really? why? it's older
[14:25] <cjwatson> (you mean libelfg0-dev, I think)
[14:25] <pitti> no particular reason, I think, it's just the status quo
[14:25] <pitti> right, sorry
[14:26] <cjwatson> or at least I think it's older
[14:26] <cjwatson> OK, fair enough
[14:26] <cjwatson> do they have remotely similar APIs?
[14:28] <pitti> I had a look at the header files, and they seemed very similar
[14:29] <pitti> and I remember switching a package from one to the other without effort in the past
[14:29] <seb128> for bug-buddy we just changed the build-depends I think, there was no code change required
[14:30] <pitti> it's just bug-buddy and ltrace, so if we want libelf instead, we can probably convert those two easily
[14:30] <seb128> right, bug-buddy was initially using the other one
[14:30] <seb128> we just switched because the other lib was already in main
[14:31] <seb128> changing back should be no issue
[14:32] <BenC> pitti: I don't think libelfg0 has the dwarf stuff that makedumpfile needs, but I'll recheck
[14:33] <pitti> BenC: ok; I test ltrace against libelf now
[14:34]  * ogra shakes his head about elfs providing dwarfs
[14:38] <BenC> pitti: yeah, there's not one dwarf thing in libelfg0-dev
[14:46] <sistpoty|work> seb128: do you want bug #193791 back in totem, or do you think it should rather go to l-r-m (it's certainly no xserver-xorg-video-nv, that's not being used there at all)?
[14:47] <seb128> sistpoty|work: why should to go back to totem?
[14:48] <sistpoty|work> seb128: due to the last comment? (I wouldn't ask if I new what's to blame ;))
[14:48] <seb128> sistpoty|work: the previous comments indicate other player have a similar issue, I would reassing to the closed source driver
[14:49] <sistpoty|work> seb128: ok, will do so, thanks
[14:49] <PecisDarbs> hi people, why importing po again in Launchpad is soooo slow? :) Third day already going
[14:51] <seb128> PecisDarbs: better to ask on #launchpad, that's not really an ubuntu thing
[14:58] <PecisDarbs> seb128: sure thing, thanks for pointing out
[15:04] <pitti> BenC: hm, ltrace doesn't build OOTB against libelf-dev, but that seems to be a bug in libelf-dev itself, not ltrace, or a compatibility problem
[15:05] <pitti> gelf.h needs off64_t without including/defining it)
[15:05] <pitti> BenC: I'll poke it harder, but for now, I think we can go with elfutils
[15:07] <pitti> cjwatson: ^ FYI
[15:07] <BenC> pitti: that means you need -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
[15:08] <cjwatson> pitti: ok, will you promote it or will I?
[15:08] <pitti> BenC: ah, I already added the latter, but not the former
[15:08] <BenC> pitti: _FILE_OFFSET_BITS=64 just changes existing off_t to 64-bits
[15:08] <pitti> cjwatson: still busy with hardy, so please go ahead if you are at it
[15:08] <BenC> pitti: I can do ltrace if you are busy
[15:09] <pitti> BenC: if you can, that would be nice; thanks!
[15:09] <cjwatson> lool: I fixed component-mismatches-mobile to at least be non-empty, but it'll be wrong - need to rewrite it a bit to use the mobile seeds
[15:09] <cjwatson> lool: so ignore it for now
[15:11] <ogra> cjwatson, is it not generated by anastcia nymore ? i was trying locate o chinstarp and rookery but that didnt show anything
[15:11] <ogra> s/o/on/
[15:11] <cjwatson> pitti,BenC: done; hit retry on the linux builds in maybe 1.5 hours or so
[15:11] <cjwatson> ogra: it is, but anastacia was never on either of those systems; it's on drescher
[15:12] <ogra> ah !
[15:12] <ogra> well, it was in mdz's homedir on rookery ages ago :)
[15:12] <cjwatson> the problem was that it was raising a python exception because the mobile seed had gone
[15:12] <pitti> seb128: ok, then please drop the libelf change in bug-buddy on the next occasion; I demoted libelf to remind us
[15:12] <cjwatson> ogra: the output was, but I don't think the script itself was?
[15:12] <seb128> pitti: alright
[15:12] <cjwatson> ogra: unless I'm misremembering, which is possible of course :)
[15:13] <ogra> ah, that might be ... i thought the script was there as well
[15:13] <cjwatson> I think mdz just mirrored it from jackass way back when
[15:13] <ogra> but the output was also called anastacia ... so its indeed confusing ... :)
[15:16] <lool> cjwatson: Thanks; I noticed it wasn't empty this morning after the STRUCTURE issue discussion
[15:17] <lool> cjwatson: Perhaps you shouldn't spend time on it and I should?
[15:18] <doko> cjwatson: just the binary, are all binaries?
[15:19] <lool> cjwatson: You might recall I once complained that ./update completed successfully despite some Packages.gz not having been fetched?  I discovered when looking at the other scripts you handed me that urllib didn't throw an exception in some cases and used urllib2 instead; I see you did the same change early June in germinate which probably fixes the old issue I saw
[15:19] <lool> cjwatson: So ... thanks!
[15:20] <cjwatson> doko: elfutils source + libdw-dev libelf-dev libelf1 binaries
[15:20] <cjwatson> lool: ah, right, er, you're welcome ;-)
[15:21] <cjwatson> lool: though I did it in June 2006 ...
[15:21] <doko> cjwatson: that should be fine
[15:21] <lool> cjwatson: Ah then it was probably another issue, unless this just landed
[15:21] <cjwatson> lool: component-mismatches-mobile> I don't think you have access to do it
[15:21] <cjwatson> at least not on drescher - leave it with me, I'll get back to you
[15:21] <lool> cjwatson: I don't; I'm happy to bzr branch and try running locally, or ask for access if ultimately it saves you time
[15:21] <lool> cjwatson: Ok; thanks
[15:25] <norsetto> asac: just sent you an email with links to gnome-mplayer/gecko-mediaplayer 0.6.3
[15:27] <asac> norsetto: i didnt get it :)
[15:27] <asac> norsetto: just kidding ;) all is fine
[15:27] <asac> thanks!
[15:27] <norsetto> asac: of course :-D
[15:35] <pitti> cjwatson, Keybuk: hm, who should I set as approver of https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-abi-package-handling ?
[15:36] <BenC> pitti: me if you want
[15:36] <pitti> BenC: ok, will do
[15:36] <pitti> oh, Keybuk just added something to the whiteboard, but no details
[15:36] <Keybuk> pitti: talk to mvo more ;)
[15:38] <pitti> mvo: you know what "doesn't address various things" expands to?
[15:39] <mvo> pitti: sorry, essentially the bits that I mentioned in the last meeting, aptitude support and smart support and coordination with debian. that makes me feel a bit uneasy about it
[15:39] <pitti> hm, so what can I do to advance this?
[15:39] <mvo> pitti: I have no better plan currently to offer, that is the problem and this is why I was not outspoken about it
[15:40] <pitti> mvo: I can start a discussion on debian-devel@
[15:41] <mvo> pitti: how about this: I explain the problem on the apt development list and CC daniel burrows explicitely and ask if he would be willing to implemnt it in aptitude too
[15:41] <mvo> pitti: hm, debian-devel might be a good place too
[15:41] <pitti> mvo: right, that's more specific than d-devel@
[15:41] <seb128> what is the discussion about?
[15:41] <pitti> mvo: can you keep me in CC:, just in case? I won't be able to judge about the apt internals, but I can contribute use cases and the intention
[15:42] <pitti> seb128: https://wiki.ubuntu.com/DesktopTeam/Specs/KernelAbiPackageHandling
[15:42] <seb128> ah ok
[15:42] <mvo> pitti: don't get me wrong, I definitely want to solve this problem too, I just don't want to spent a lot of time impleneting it and then not getting it over to debian
[15:42] <pitti> mvo: absolutely, we shuold implement it 'upstream'
[15:43] <mvo> pitti: great, thanks. I will draft the mail right away and give it to you for review?
[15:43] <pitti> mvo: excellent!
[15:43] <pitti> mvo: I'm almost done with beating on the hardy.1 CDs, so I'll be able to review it today still
[15:43] <jamiejackson> ﻿i see an update coming in that says: "Version 2.6.24.13-19.44:   * Just ditch bcmwl from nic-restricted udeb." (in the restricted modules package) <-- where can i read more info on this update?
[15:44] <mvo> pitti: ok, thanks
[15:47] <seb128> pitti: maybe you could approve the pidgin gutsy sru?
[15:50] <pitti> seb128: done
[15:50] <seb128> pitti: danke
[15:53] <calc> i'm going to need to reinstall my laptop back to base hardy, since june 26 it has been crashing (goes off immediately) every 1 to 2 days
[15:54] <calc> anyone else hear of a problem like this? i am not sure if it is a hardware problem or kernel crash or something like that
[15:56] <mvo> pitti: on the bright side I started with a dbus/policykit backend for language-selector that seems to be working ok-ish already. so that we can drop another one of the gksu use-cases
[15:56] <pitti> mvo: you mean packagekit?
[15:56] <mvo> pitti:  policykit to set stuff like the global default langauge
[15:56] <pitti> oh, sweet!
[15:56] <mvo> pitti: or the default fontconfig configuration
[15:57] <pitti> mvo: took me a while to get polkit working with python...
[15:57] <mvo> pitti: its in the dbus branch
[15:58] <mvo> pitti: yeah, I found the lack of error messge not great - but the stuff from murrayc helped me go get accross it and then I discovered jockey uses it too
[15:58] <mvo> pitti: it was not working for me because I had upper case charackters in the action_id first
[15:58] <pitti> mvo: yes, I added some fairly generic server and client functions to jockey trunk
[15:58] <pitti> mvo: hah, that confused me as well; polkit-policy-file-validate kept barfing at me due to this :)
[15:59] <mvo> pitti: yeah, I was pretty puzzled by this :) I wonder why this restriction was added
[16:00] <mvo> pitti: maybe we should create a python package for this until policykit-gnome gets a python port (this is in the works as I understand it but not finsihed yet?)
[16:00] <pitti> mvo: there's a first version of pypolkit, but only for the client side
[16:20] <BenC> pitti: ltrace done, tested and uploaded
[16:20] <pitti> BenC: just saw it on -changes; many thanks!
[16:20] <BenC> pitti: bug-buddy takes too many build-deps...are you handling that? :)
[16:20] <pitti> BenC: don't worry about that one, seb128 and I will figure it out
[16:21] <BenC> ok, great
[16:37] <guysoft42> hello all, i seem to be having a problem to exacting the following line in C:  fp = popen("dmidecode", "r"); . it works fine in debian. the error i get is a stack trace. also, using ls works fine.. what could be worng?
[16:38] <bdmurray> dholbach: merge with which branch?
[16:40] <dholbach> bdmurray: thekorn's intrepid.merge into .main
[16:40] <dholbach> bdmurray: it has the fix to make the HTML connector work again
[16:40] <dholbach> it seems to be in PPA already
[16:42] <bdmurray> dholbach: I just need it sponsored
[16:42] <dholbach> bdmurray: oh, I was merely talking about the branches
[16:42] <bdmurray> dholbach: okay, I'll push it then
[16:42] <dholbach> thanks
[17:08] <BenC> pitti: looks like makedumpfile/elfutils/ltrace have all successfully made their way to main (and built against libelf-dev in ltraces case)
[17:09] <pitti> yay
[17:09] <pitti> BenC: so, time for a linux give-back?
[17:09] <Keybuk> pitti: so I'm having an interesting bug at the moment
[17:09] <BenC> pitti: doing it now (retry button rocks)
[17:09] <Keybuk> since about Friday
[17:09] <pitti> BenC: done
[17:09] <Keybuk> my laptop suspends as normal
[17:09] <BenC> pitti: thanks
[17:09] <Keybuk> but pressing the power button makes it boot up again, not resume
[17:09] <pitti> BenC: ok, you already do, sorry
[17:09] <pitti> BenC: please go ahead then, my script seems to have broken again (403: Forbidden)
[17:10] <BenC> ok
[17:10] <pitti> Keybuk: does /etc/initramfs-tools/conf.d/resume look reasonable?
[17:10] <Keybuk> pitti: that's not involved in suspend?
[17:10] <pitti> Keybuk: i. e. did you reformat your swap partition or something?
[17:10] <pitti> Keybuk: oh, -to-ram; hmm
[17:11] <Keybuk> the laptop definitely thinks its in ram sleep
[17:11] <Keybuk> since the power light pulses
[17:11] <Keybuk> which is its way of saying in standby
[17:11] <pitti> right, I have the same laptop :) (almost)
[17:11] <Keybuk> in hibernate, the power light is simply off
[17:11] <Keybuk> I assume that the power button hasn't been set to be a wakeup device
[17:11] <BenC> Keybuk: wonder if the kernel is putting the laptop in a bad sleep state
[17:11] <pitti> Keybuk: I just wonder where the heck the OS would have an influence on that?
[17:12] <Keybuk> pitti: cat /proc/acpi/wakeup
[17:12] <Keybuk> PBTN  S4  *enabled
[17:12] <pitti> Keybuk: i. e. if you press it, you see the BIOS message right away? or some flickering which would be linux resuming and immediately rebooting?
[17:12] <Keybuk> should that not be S3 ?
[17:12] <Keybuk> pitti: bios right away
[17:12] <pitti> Keybuk: let me boot mine and look
[17:13] <pitti> Keybuk: oh, intrepid or hardy?
[17:13] <Keybuk> intrepid
[17:15] <pitti> Keybuk: "PBTN S4 *enabled"
[17:15] <pitti> it just woke up from hibernate
[17:15] <pitti> now, suspending
[17:16] <pitti> no change
[17:16] <pitti> Keybuk: I have "LID S3 *enabled", though
[17:16] <pitti> neither change if I use the lid or the power button
[17:17] <Keybuk> on intrepid, if you stand by, then press the power button, it resumes ?
[17:17] <pitti> that's all hardy
[17:17] <pitti> I don't have an intrepid installation on real iron yet
[17:17] <Keybuk> hardy it worked fine
[17:17] <pitti> right, I was just comparing
[17:17] <Keybuk> this is a very recent intrepid breakage for me
[17:17] <pitti> so the S4 in /proc/acpi/wakeup seems unrelated
[17:18] <Keybuk> agree
[17:18] <Keybuk> as soon as I've done this upload, I'll test what the lid does
[17:21] <dholbach> bdmurray, thekorn_: it seems the right fix is not in .main yet
[17:21] <dholbach> I still have trouble getting the summary of a bug with the HTML connector
[17:22] <Bravewolf> Is 8.04.1 sheduled for tomorrow?
[17:23] <bdmurray> dholbach: I merged the fix for bug 244452 what bug are you talking about?
[17:24]  * calc tries to decide whether to wait for his to crash again in 2 days or reinstall hardy today without any updates
[17:24] <dholbach> bdmurray, thekorn_: http://paste.ubuntu.com/24508/
[17:25] <calc> anyone been having problems with spontaneous reboots on up to date hardy?
[17:26] <cjwatson> Bravewolf: yes
[17:27] <Keybuk> BenC, pitti: closing and opening the lid also makes it simply boot, rather than resume from standby
[17:27] <bdmurray> dholbach: okay, I've recreated it and will work on it
[17:28] <dholbach> bdmurray: seems that thekorn_ already fixed it in his branch
[17:29] <bdmurray> dholbach: however, it does work with the txt interface which is much less fragile
[17:29] <dholbach> right, I use the HTML connector because of the activity thing
[17:29] <dholbach> other than that I use the text connector wherever I can
[17:36] <thekorn_> dholbach, bdmurray this is fixed in intrepid.merge, I plan to do the merge later today
[17:48] <BenC> Keybuk: that's either kernel or hardware
[17:48] <Keybuk> BenC: since it works on hardy, that implies kernel ;)
[17:49] <BenC> Keybuk: damn you and your proper regression testing :P
[17:49] <Keybuk> heh
[17:49] <Keybuk> I have hardy-proposed and intrepid on different partitions ;)
[17:49] <Keybuk> that's not regression testing
[17:50] <Keybuk> that's "development release sometimes gets very broken and I need to be able to work" :p
[17:53] <BenC> Keybuk: hardy kernel on intrepid userspace would make me feel better (though it's kernel team problem either way...just want to rule out pm-utils)
[17:54] <Keybuk> let me try that
[17:57] <Keybuk> BenC: hardy kernel works fine on intrepid userspace
[17:59] <BenC> Keybuk: Ok, then my next request will be to try the 2.6.26-3-generic kernel that is currently building (thanks)
[18:03] <decriptor> does anyone know who takes care of mono packaging?
[18:11] <BenC> decriptor: obviously it's only one guy
[18:16] <pochu> doko: would it be reasonably and possible to move the libpython2.5.so symlink from python2.5-dev to python2.5? See bug 44704 and Debian bug 488760
[18:16] <decriptor> BenC: the sky is blue
[18:18] <cjwatson> decriptor: https://launchpad.net/~mono
[18:18] <decriptor> cjwatson: thanks
[18:25]  * BenC assumes his poor attempt at a joke was lost
[18:30] <Keybuk> kees: gotta love people who see something, and file a bug about it, without actually verifying the planet-sized assumption about what they saw
[18:31] <kees> Keybuk: heh, yeah
[18:34] <decriptor> BenC: sorry, last time (about a year ago), I got a crappy/no answer so faulted to misreading it
[18:34] <decriptor> BenC: now that you mean it, that was a pretty good one :P
[18:37] <decriptor> BenC: errrr..... I should reread my posts, not that I've reread it and understand it, that was pretty funny
[18:37] <decriptor> s/not/now/
[18:41] <BenC> decriptor: thanks you, I'll be here all week...you've restored my comedic confidence :)
[18:43] <decriptor> BenC: lol
[18:43] <decriptor> BenC: I've looked at mono and associated with monkey (spanish meaning) that mono in english has changed its meaning :)
[19:14] <slangasek> cody-somerville: yes, hardy-proposed is currently frozen for .1; it doesn't look to me that the xubuntu-default-settings fix is important enough that we would want to respin the CD images for it?
[19:15] <slangasek> cody-somerville: also, we need to have feedback in bug #232364 that the fix works so we can copy it to hardy-updates
[19:39] <slangasek> cody-somerville: oh, 232364 has feedback now, right then \o/
[19:46] <mario_limonciell> slangasek, what has been the current bottleneck in daily-live disks for intrepid?
[19:47] <mario_limonciell> looking at http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/livecd-base/intrepid/livecd-base-20080702.log it's not clear what is actually happening
[19:48] <slangasek> mario_limonciell: ubiquity wasn't in a working state in time for alpha1, IIRC mostly due to needing to catch up with d-i changes; I don't know if it's caught up now, I've been in point-release-lala-land
[19:48] <mario_limonciell> slangasek, ah
[19:48] <mario_limonciell> evand, has ubiquity caught up?
[19:48] <slangasek> mario_limonciell: I think that log you pointed at shows that it can't find a lives image
[19:48] <slangasek> livefs
[19:49] <slangasek> er, no, it doesn't
[19:49] <evand> mario_limonciell: negative, working on it.
[19:49] <mario_limonciell> evand, okie dokie
[19:49] <slangasek> actually, I'm not sure that particular log shows any errors
[19:50] <mario_limonciell> ah yeah this is the log to be looking at http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/intrepid/ubuntu/20080702/livecd-20080702-i386.out
[19:50] <mario_limonciell> and it's apparmor causing havok
[20:13] <mario_limonciell> kees, wrg to apparmor stuff, are you going to filing MIR's for libapparmor-perl and libterm-readline-gnu-perl?  those are both universe pieces (Depends and Recommends ) that are keeping livedisks from building at all currently
[20:13] <kees> mario_limonciell: yeah, I need to do that.
[20:13] <kees> I had actually forgotten about the libapparmor-perl bit
[20:13] <kees> do we need to promote things in Recommends now?
[20:14] <mario_limonciell> kees, there was some chatter about it on ubuntu-devel ML
[20:14] <kees> mario_limonciell: yeah, I was waiting for a conclusion.  ;)
[20:16] <mario_limonciell> kees, it looked like to me that was the conclusion.  you should be able to get the same result from a CD install as you would a network install
[20:16] <kees> hmpf.  what's the point of recommends vs depends then, if they both need to be in main and are installed by default?  :P
[20:17] <norsetto> kees: you can get rid of recommends ;-)
[20:17] <mario_limonciell> yeah
[20:17] <mario_limonciell> kinda like a "weak depends"
[20:18] <kees> norsetto: heh, yeah, I guess so.  :P
[20:22] <kees> cjwatson, pitti: do I need a full MIR for libapparmor-perl since it is just swig bindings to libapparmor1 which is already in main?
[20:32] <mkrufky> is there a way to install an i386 deb on a lpia machine?  ...or is that just a bad idea
[20:33] <kees> mario_limonciell: actually, which is depending on libapparmor-perl currently?
[20:34] <kees> mario_limonciell: oh, nm, -utils is in main
[20:36] <directhex> is it possible for a source package in universe with only build dependencies on main & universe to construct a binary package for multiverse (amongst others)?
[20:37] <mkrufky> i swear, on one of my ubuntu mailing lists somebody mentioned a way to install i386 packages under a lpia kernel, and i cant seem to find it :-9
[20:38] <mkrufky> :-(
[20:38] <directhex> dpkg -i --force-architecture foo.deb
[20:38] <mkrufky> thank you very much, directhex
[20:39] <directhex> mkrufky, got used to it in the early days running amd64
[20:39] <mkrufky> ah
[20:40] <mario_limonciell> mkrufky, depending on what it is though, that's not always a smart idea
[20:41] <mario_limonciell> so just be cognoscente of that
[20:45] <directhex> mario_limonciell, --force-foo is always a great idea!
[20:46] <mkrufky> i was afk
[20:47] <mkrufky> anyway, its working :-D
[20:53] <maix> ping ScottK
[20:54] <ScottK> Hello.
[20:54] <maix> hi
[20:54] <maix> > So far it's not been requested. It would have to be requested (use also
[20:54] <maix> > affects to add gutsy-backports) and them tested on gutsy.
[20:54] <maix> (https://bugs.launchpad.net/ubuntu/+source/mercurial/+bug/223789)
[20:54] <maix> i cannot find such a link/option there
[20:55] <ScottK> See where it says "Also affects project" right under mercurial(ubuntu)?
[20:55] <ScottK> Click on that.
[20:55] <maix> yes?
[20:55] <maix> (i've tried that but it did not seem to be the right thing to me :)
[20:56] <ScottK> Yes.  Actually you need to do that from https://bugs.launchpad.net/hardy-backports/+bug/223789
[20:57] <ScottK> Then when it asks you about the affected project say gutsy-backports.
[20:58] <ScottK> maix: Does that work better?
[20:58] <maix> yes
[20:59] <ScottK> Feel free to discuss the user-friendly U/I in #launchpad.  My thoughts on the matter are well known.
[20:59] <maix> but that's very confusing, why are there completely different options if i access the same bug by a different url
[20:59] <ScottK> That's a good question to ask in #launchpad.
[21:00] <maix> ok then i can guess what your thougts are :)
[21:00] <ScottK> I've been told my opinions on the Launchpad U/I aren't credible because I don't think it's getting better.
[21:01] <maix> hm i'll complain too, maybe they will change something when more people complain :)
[21:02] <maix> and ScottK may you set importance to wishlist, i am not allowed to
[21:02] <imbrandon> ugh, anyone elses crontab just stop executing jobs ?
[21:02] <ScottK> Sure.
[21:02] <maix> thx
[21:06] <maix> ok done ranting :)
[21:11] <Riddell> jdstrand, kees: poke.  libzip.  poke.
[21:12] <kees> Riddell: oh, thanks for the reminder.  do you have the bug# handy still?
[21:12] <Riddell> kees: https://bugs.edge.launchpad.net/ubuntu/+source/libzip/+bug/238883
[21:42] <cjwatson> kees: libapparmor-perl doesn't need an MIR since it's
[21:42] <cjwatson> kees: ... part of a source package already in main
[21:44] <kees> cjwatson: okay, that's what I suspected.  I opened a bug report for it.
[21:44] <cjwatson> you can close it again ;-)
[21:44] <cjwatson> (libapparmor-perl promoted)
[22:13] <doko> pochu: well, it belongs to the -dev package
[22:52] <pochu> doko: so do you know whether there is any other solution than for python-nautilus to depend on python-dev, or for the current patch which opens the .so.X (and needs to be manually updated whenever the soname changes) ?
[22:52] <doko> pochu: the soname will never change
[22:53] <doko> only when moving to a new python version
[23:19] <Caesar> slangasek: what is the current ETA for 8.04.1?
[23:27] <slangasek> Caesar: tomorrow
[23:27] <slangasek> Caesar: probably late in the day, Pacific time
[23:27] <Caesar> slangasek: thanks
[23:56] <kees> 0Uhmm... is quilt broken in intrepid?
[23:56] <kees> it's not following my QUILT_PATCHES env var any more.