[03:00] <NCommander> Man, Freenode been glitchy
[03:01] <ScottK> You say that like it's news.
[03:05] <NCommander> ScottK, I remember freenode when it was steady as a rock
[03:06] <ScottK> NCommander: Do you have some time to try and verify a security patch for me (It's C, so I'm hopeless)?
[03:06] <jdong> NCommander: yeah yeah and you walked in 15 feet of snow uphill and downhill everyday to school in the next city....
[03:07] <ScottK> jdong: You got it wrong, "Up hill both ways".
[03:07] <NCommander> jdong, no, I took a bus
[03:07] <NCommander> ScottK, define verify
[03:07] <jdong> NCommander: verify (v. trans. InfoSec): "Yeah, I think most of ~/ is still there AFAICT..."
[03:07] <jdong> *ducks*
[03:07] <ScottK> NCommander: Upstream produced a new upstream release that has both a working exploit test and a very invasive fix.
[03:08] <NCommander> Ok
[03:08] <ScottK> NCommander: Upstream gave a hint on how to shortcut avoiding the problem in a less invasive way
[03:08] <ScottK> NCommander: Debian maintainer has produced a patch that he thinks is good, but upstream doesn't have time to deal with confirming it works.
[03:09] <ScottK> I'm looking for some independent verification.
[03:09] <NCommander> So, why not install package, run verification test?
[03:09] <ScottK> You've looked at the code before so I thought of you.
[03:09] <ScottK> I'd have to understand Perl to run the test.
[03:10] <ScottK> That and I'm currently busy trying to understand why cmake seems broken in Jaunty.
[03:18] <ScottK> I guess that's a no then.
[03:18] <ScottK> Tries again.
[03:18] <ScottK> I guess that's a no then.
[03:20] <NCommander> ScottK, sorry, my laptop froze
[03:20] <NCommander> ScottK, sure, I can be convinced to test it
[03:20] <ScottK> OK.  I'll email you some stuff.  You'll want libspf2 from Jaunty and Hardy.  What address.
[03:22] <ScottK> NCommander: ^^
[03:23] <NCommander> sonicmctails@gmail.com
[03:24] <ScottK> NCommander: Forwarded you the upstream hint and the proposed patch.
[03:24] <NCommander> is the patch in jaunty or the new upstream?
[03:25] <ScottK> The patch is against 1.2.5 (in Dapper -> Hardy).
[03:25] <ScottK> The new upstream is in Jaunty/Intrepid-security.
[03:25] <ScottK> The test is in the new upstream.
[03:25]  * NCommander grabs the jaunty source package
[03:26] <ScottK> If the package is vulnerable, the test will cause a segfault.
[03:26] <ScottK> NCommander: Be sure to grab the -security version.
[03:26] <NCommander> ScottK,   libspf2-2: Depends: glibc-private but it is not installable
[03:26] <ScottK> That adds the patch that made it possible to get to this problem (fix one vulnerability and expose another latent one |o/)
[03:26] <NCommander> *ahem*
[03:27] <ScottK> ?
[03:27] <NCommander> Trying to install on jaunty
[03:27] <NCommander> Package is broken
[03:28] <ScottK> Weird.  Installs on Intrepid.
[03:28] <ScottK> Same package.
[03:28] <NCommander> :-P
[03:28] <NCommander> Yeah
[03:28] <NCommander> its broken on jaunty
[03:28] <ScottK> OK.  Separate issue.  I'll look at that.
[03:29] <NCommander> ok, I figured out how to run the test suite against various versions of the package :-)
[03:29] <ScottK> Great.
[03:29] <NCommander> I'll test the jaunty package (assuming it compiles)
[03:29] <ScottK> Try the hardy-security version against it and see.
[03:30] <NCommander> I need to have a known working negetive
[03:30] <ScottK> Right.
[03:30] <NCommander> argh
[03:30] <NCommander> damn it
[03:30] <NCommander> I actually have to install the library
[03:30]  * NCommander breaks pbuilder out
[03:31] <NCommander> argh
[03:31] <NCommander> the test suite needs a non-packaged perl module it seems
[03:34] <ScottK> Upstream runs Gentoo, so who knows.
[03:34]  * NCommander whacks head
[03:34] <NCommander> bah
[03:34] <NCommander> Getting this test suite to run is a ****
[03:35]  * NCommander upgrades perl base
[03:35] <NCommander> ok
[03:35] <NCommander> confirmed that the version in jaunty does not suffer the buffer overflow
[03:38] <NCommander> argh
[03:40] <NCommander> t/11_overflows.......dubious
[03:40] <NCommander> 	Test returned status 0 (wstat 11, 0xb)
[03:40] <NCommander> DIED. FAILED tests 3-5
[03:40] <NCommander> 	Failed 3/5 tests, 40.00% okay
[03:41] <NCommander> ScottK, ^
[03:41] <NCommander> (that being said, the test suite might be a false postive, I had to kick it to actually compile )
[03:41] <ScottK> That's Jaunty?
[03:41] <NCommander> Hardy security
[03:42] <ScottK> OK.  I'm fairly certain that one isn't vulnerable.  More than one person who knows the code verified that.
[03:42] <ScottK> Ah.  Hardy Security.  Sorry
[03:42] <NCommander> yeah
[03:42] <NCommander> it segfaulted
[03:43] <ScottK> I'd expect Hardy Security to fail.
[03:43] <ScottK> That's the indication it's vulnerable.
[03:43] <NCommander> it got through 2/3 tests however
[03:44] <ScottK> The patch in Hardy security I think is tested for in that same test.
[03:45] <NCommander> root@blacksteel:~/libspf2-1.2.5.dfsg/perl# perl t/11_overflows.t
[03:45] <NCommander> 1..5
[03:45] <NCommander> ok 1 - use Mail::SPF_XS;
[03:45] <NCommander> ok 2 - parse_cidr did not run off start of data
[03:45] <NCommander> Segmentation fault
[03:46] <ScottK> I think that's right.  I suspect the one in hardy-release would fail 2
[03:48] <NCommander> so now what?
[03:48] <NCommander> libspf has two rdepends
[03:48] <NCommander> It might just be worth doing a backport
[03:50] <ScottK> So the question is does the patch I emailed you fix it?
[03:50] <NCommander> oh
[03:50] <NCommander> I thought the patch was applied already
[03:52] <ScottK> No.
[03:52] <ScottK> I emailed you patch #2 that hopefully finishes fixing it.
[03:52] <NCommander> Lets find out
[03:53] <NCommander> t/11_overflows.......ok
[03:53] <NCommander> WOOOO!
[03:53] <cody-somerville> NCommander, chillax :P
[03:53] <NCommander> chillax?
[03:55] <ScottK> NCommander: So it works.  Would you view it as sane?
[03:56] <NCommander> Yes, expect it makes a blank patch file as well
[03:56] <NCommander> 51_actually-keep-track-of-max_var_len.dpatch - empty
[03:56] <NCommander> 52 - has the real patch
[03:57] <ScottK> expect/except?
[03:57] <NCommander> *except :-P
[03:58] <ScottK> OK.
[03:58] <ScottK> NCommander: Thanks.  I'll work on -security debdiffs then.
[03:58] <NCommander> \o/
[03:58] <ScottK> NCommander: Any thoughts on where glibc-private in Jaunty comes from?
[03:59] <NCommander> no idea
[03:59] <NCommander> it might just need a binary rebuild
[03:59] <ScottK> Tried that.  No luck.
[03:59] <ScottK> It picks that up from somewhere.
[04:01] <NCommander> apt-cache doesn't know what it is
[04:01] <ScottK> It doesn't exist.
[04:01] <NCommander> its in none of the shlibs files I have
[04:03]  * NCommander pokes LP
[04:18] <NCommander> ScottK, I'm semi-stumped
[04:18] <ScottK> NCommander: I dunno the relevancy, but glibc in Intrepid defines a large number of symbols in GLIBC_PRIVATE that seem to be gone in Jaunty.
[04:18] <NCommander> bug in glibc?
[04:19]  * NCommander debates downgrading to intrepid
[04:20] <ScottK> NCommander: I was thinking more planned change we need to figure out how to work with.
[04:20] <NCommander> ??
[04:21] <ScottK> Looking at debian/changelog this symbol thing was on purpose.
[04:21] <ScottK> Not sure if it's relevant to the problem at hand or not.
[04:21] <NCommander> where is doko when you need him
[05:19] <glaksmono> hello
[05:38] <ScottK> NCommander: Thanks.  -security debdiffs are done.
[05:38] <NCommander> yay
[05:38]  * ScottK goes and sleeps.
[06:23] <\sh> moins
[06:24] <\sh> NCommander: welcome on board of the MOTU ship :)
[06:24] <NCommander> \sh, thanks :-)
[06:24] <NCommander> \sh, do you know who the resident grub guy is on Ubuntu?
[06:25] <\sh> NCommander: nope...sorry...
[06:57] <NCommander> cjwatson, I'd like to talk to you on adding splash images for grub
[07:05] <wgrant> NCommander: Not by default, I hope.
[07:06] <NCommander> wgrant, ?
[07:07] <wgrant> NCommander: It was, I believe, decided that yet another mode change wasn't necessary.
[07:07] <pitti> Good morning
[07:07] <NCommander> wgrant, mode change?
[07:07]  * NCommander notes our current grub does properly support splashimages, and those work just fine
[07:08] <wgrant> NCommander: Splash image == graphical mode == mode switch == flickering == baaad
[07:08] <wgrant> Morning pitti.
[07:08] <NCommander> fair enough
[07:08] <NCommander> morning Pici
[07:08]  * NCommander hit head
[07:08] <NCommander> pitti,
[07:08] <wgrant> Flickering and slowness and other stuff, probably.
[07:08] <pitti> wgrant: pong
[07:08] <wgrant> It's not accidental that we lack a splash image, at any rate.
[07:08] <wgrant> pitti: See bug #293318/
[07:08] <wgrant> I think it's that one.
[07:08] <wgrant> Yes it is.
[07:09] <tjaalton> fedora removed their grub splash image
[07:09] <NCommander> They did?
[07:09] <tjaalton> for the same reason
[07:09]  * NCommander notes Debian still has one
[07:09] <pitti> wgrant: I got the bug mail, yes
[07:09] <NCommander> wgrant, I can find that leak
[07:09] <wgrant> NCommander: Huh?
[07:09] <tjaalton> now they don't even show the menu anymore, unless there's another boot option available (like windows)
[07:09] <NCommander> the memory leak
[07:09] <wgrant> tjaalton: That's what we do, isn't it?
[07:09] <tjaalton> wgrant: yes
[07:09] <wgrant> NCommander: I've even fixed it upstream...
[07:09] <NCommander> oh
[07:10] <NCommander> nm
[07:10]  * NCommander hadn't finished reading the bug :-)
[07:11] <wgrant> NCommander: Why do you want a GRUB splash?
[07:11] <NCommander> Brainstorm #21, and my mom freaked when she saw it when I installed Ubuntu on her PC
[07:12] <wgrant> Surely it's no more scary than watching a POST.
[07:12] <NCommander> At least no computer I've owned in a few years shows a text based PoST
[07:12] <NCommander> ... PSOT
[07:12] <NCommander> ... POST!
[07:12] <NCommander> on mine, I get Sony VIAO -> grub -> usplash
[07:12] <tjaalton> just get rid of windows and you're saved
[07:13]  * NCommander gets the grub countdown
[07:13] <tjaalton> no grub menu anymore
[07:13] <NCommander> yes, I know
[07:13] <Treenaks> On my eee I get grub (very short) -> usplash
[07:13] <Treenaks> \o/ bios quickboot
[07:14] <tjaalton> NCommander: oh, yet another "idea" I can close?-)
[07:15] <NCommander> tjaalton, if you must ;-)
[07:19] <tjaalton> ah, fedora didn't actually remove the splash, but it's not shown unless the menu is
[07:21]  * NCommander notes thats how itlled is on Ubuntu as well if a splash is insta
[07:22] <pitti> wgrant: did you sent the two g-s-d input patches upstream? There aren't any patch headers or gnome bz refs
[07:22] <wgrant> pitti: The upstream-relevant parts are upstream.
[07:22] <pitti> wgrant: ah, nice; thanks
[07:22] <wgrant> I didn't add patch headers because the patches were already there.
[07:24] <pitti> wgrant: I added the bug ref for 293318 to the changelog; does 08_extra_touchpad_options.patch correspond to a bug report, too?
[07:25] <wgrant> pitti: They're both for that bug, though 08_extra_touchpad_options.patch is more of an additional defense.
[07:25] <pitti> ok, thanks!
[07:26] <wgrant> No, thank you.
[07:26] <wgrant> tjaalton: Are any other distros going to be sharing our pain in the immediate future?
[07:26] <pitti> fedora isn't yet?
[07:27] <pitti> wgrant: I assume "pain" == "input hotplug"? :-)
[07:27] <wgrant> pitti: Input hotplug for everything, yes.
[07:30] <dholbach> good morning
[07:31] <tjaalton> wgrant: fedora is
[07:31] <tjaalton> at least
[07:31] <tjaalton> and when lenny is released I bet debian will follow
[07:31] <wgrant> tjaalton: Hmm, I wonder how they dealt with g-s-d...
[07:32] <wgrant> From what I could see they hadn't.
[07:32] <pitti> wgrant: nothing on http://daniel.holba.ch/harvest/handler.py?pkg=gnome-settings-daemon ?
[07:33] <tjaalton> wgrant: what in particular?
[07:34] <wgrant> pitti: No...
[07:34] <wgrant> tjaalton: Mouse settings (most annoyingly right/left-handedness) don't persist when you hotplug devices.
[07:34] <wgrant> Some keyboard stuff doesn't work at all, but that's another less important story.
[07:36] <tjaalton> wgrant: okei
[07:36] <tjaalton> uh
[07:36] <tjaalton> "okay"
[07:44] <pitti> slangasek: did you see the response in bug 236830? seems there is still a bug there?
[08:10] <SYDN> 谁知道有64的JAVA 那里下载
[08:11] <RAOF> Indeed.
[08:12] <SYDN> where
[08:13] <wgrant> I agree with RAOF.
[08:14] <RAOF> Aha.  Sorry.
[08:14] <RAOF> Google tells me that you want to download Java.
[08:15] <RAOF> SYDN: You want the "sun-java6-jre" package.
[08:16] <SYDN> oh
[08:17] <iulian> There is a #ubuntu-cn channel though.
[08:17]  * iulian wonders why he didn't join there.
[08:42] <pitti> mvo: good morning
[08:42] <pitti> mvo: I checked the hardy SRUs, and it seems that bug 220890 is the only one which holds up -updates propagation of 3 hardy-proposed uploads
[08:42] <pitti> mvo: anything we can do about it? or is it not a regression, and we can copy and keep the bug open?
[08:45] <mvo> pitti: I look into it now, sorry that it got put on hold during intrepid
[08:47] <NCommander> Ugh, that one
[08:47]  * NCommander puts that on the Ports todo tracker
[08:50] <slangasek> superm1: ok, changed in bzr, thanks
[08:51] <slangasek> pitti: 236830> the only issue I see at the end of the bug log was user error, which EtienneG addressed?
[08:52] <pitti> slangasek: ahh, I read it as "that's what the package should ship"
[08:52] <mvo> NCommander: what is the url for this?
[08:52] <pitti> slangasek: ok, so that's basically "didn't get any feedback" then
[08:52] <NCommander> mvo, right now, I'm just going to note it on the kernelportspage
[08:52]  * NCommander kicks the spacebar
[08:53] <slangasek> pitti: ah, so it is; I guess we should kick people for testing :/
[08:53] <NCommander> But at least w.r.t. to powerpc, I've been working w/ a bunch of other people to make sure PowerPC is a top-notch port again
[08:55] <emgent> good morning
[08:57] <NCommander> mvo, I think I can probably fix this bug in Jaunty
[08:57] <NCommander> (the ports one)
[08:59] <mvo> NCommander: I check it out now and let you know what I find, I thought I fixed it already :/
[09:00] <NCommander> I thought it was broken on Intrepid
[09:00] <NCommander> mvo, are you a ports user?
[09:00] <mvo> no, that i part of the problem
[09:00] <NCommander> install lpia on something w/ a CD then
[09:01] <NCommander> Its considered a port on LP
[09:02] <mvo> right, good idea
[09:02] <NCommander> I have those occasionally :-)
[09:03] <pitti> mvo: I'm ready to accept update-manager for intrepid-proposed, unless you have some more changes stacked up?
[09:05] <mvo> pitti: is the other one in -updates now?
[09:05] <pitti> mvo: yes, I copied it this morning
[09:06] <mvo> excellent!
[09:06] <mvo> nothing pending currently
[09:06] <pitti> mvo: good; accepted then
[09:07] <kirkland> mvo: pitti: I have a debdiff coming shortly for update-notifier for Jaunty;  adds an update-motd hook such that update notifications are appended to the MOTD
[09:07] <NCommander> pitti, what is binary NEWed?
[09:09] <mvo> kirkland: nice, I will merge it when its ready
[09:11] <soren> Is anyone else unfortunate enough to have to deal with the wl wifi driver?
[09:12] <NCommander> soren, yes, I have
[09:12] <soren> I find there's a huuuuge difference between the latency of my network connections when I use that and when I use ndiswrapper (which used to be my only option).
[09:13] <NCommander> pitti, https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/mtd-utils/+bug/294428
[09:13]  * soren runs a simple benchmark
[09:14] <soren> NCommander: Is it horribly laggy for you as well?
[09:19] <pitti> NCommander: a package which hasn't been built before must be checked by the archive admins, and is held in a queue for that before being published to the archive
[09:19] <NCommander> soren, my current machine doesn't have wl, but in my experience, yes
[09:20] <NCommander> pitti, ah, I see. I enabled proposed on my intrepid box, and checked it, so now what :-)?
[09:21] <pitti> NCommander: if it works, then it's good for copying to intrepid-updates, and closing the bug
[09:21] <geser> pitti: Hi. Please give-back vim on i386. Thanks.
[09:21] <NCommander> It works to the extent I can test it (I don't have anythign attached to this PC I can forgot jffs2, but the tools, and the help for the tools work)
[09:22] <soren> NCommander: http://people.ubuntu.com/~soren/wlstats.txt <---- No fun at all
[09:22] <pitti> geser: it's built already
[09:23] <geser> pitti: https://launchpad.net/ubuntu/jaunty/+source/vim/+builds shows a FTBFS for i386
[09:24] <pitti> geser: indeed, seems my script is broken
[09:25]  * pitti fixes it for s/intrepid/jaunty/
[09:25] <pitti> given back
[09:25]  * soren wonders why he didn't see the e-mail about that build failure... :/
[09:36] <wgrant> How does one get posting privileges revoked from -devel-discuss?
[09:37] <slangasek> mail -devel-discuss-owner, I guess?
[09:37] <cody-somerville> wgrant, is there a particular reason you ask? :P
[09:38] <wgrant> They're not doing a very good job of making developers want to read it.
[09:42] <ogra> that's why it's called -discuss :)
[09:42] <ogra> for actual development there is ubuntu-devel
[09:43] <wgrant> I mean, I thought I directed some serious torrents of hate at Launchpad, but that just doesn't compare...
[10:02] <Hobbsee> wgrant: hmm, I wonder who has powers over that list
[10:03] <Hobbsee> oh, wow.  It's getting even better.
[10:04] <NCommander> What list?
[10:04] <wgrant> -devel-discuss
[10:05] <Hobbsee> NCommander: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-November/006221.html and that general thread (and other useless wastes of bytes on that list)
[10:05] <Hobbsee> NCommander: oh, and those sorts of posts are normal for that guy, too.
[10:05] <NCommander> WTF is the difference between devel-discuss and -devel
[10:05] <wgrant> One has ******** on it.
[10:05] <Hobbsee> NCommander: devel == sane.  has developers on it, and is moderated so you don't get that kind of rubbish.
[10:05] <liw> NCommander, one is discussion about developement, one is discussion about discussion about development?
[10:06] <NCommander> Hobbsee, semi-moderated, developers are whitelisted
[10:06] <Hobbsee> NCommander: -devel-discuss: users speaking to developers...Or, now, as the case may be, lots of hate mail, which most people ignore, and occasional developer discussions, which a few people follow.
[10:06] <NCommander> who do I get in contact if I want a mailing list
[10:06] <Hobbsee> NCommander: well, yeah.  But the developers aren't expected to behave badly.
[10:06] <Hobbsee> NCommander: depends.  What for?
[10:06]  * NCommander would like an ubuntu-ports list <g>
[10:06] <Hobbsee> NCommander: do you want to use listadmin on it?
[10:06] <NCommander> listadmin?
[10:07]  * NCommander knows listsrv, but not listadmin
[10:07] <Hobbsee> NCommander: http://debaday.debian.net/2007/09/12/listadmin-command-line-mailman-moderator-queue-manipulation/
[10:07] <NCommander> Probably
[10:07]  * NCommander would whitelist developers of course
[10:07] <Hobbsee> NCommander: if you do, you can't use the launchpad lists, you'll need to get a list on lists.ubuntu.com (and I think you'll need to speak to jcastro about it)
[10:08] <NCommander> jcastro, ^
[10:08] <Heller_Barde> what program is this volume OSD of ubuntu part of?
[10:08] <liw> it's probably night for jcastro
[10:09] <wgrant> Heller_Barde: gnome-settings-daemon, I believe.
[10:09] <Heller_Barde> ah. and where can i find out how the shortcut is bound to it?
[10:10] <wgrant> Heller_Barde: What do you mean?
[10:10] <Heller_Barde> or does gnome-settings-daemon capture shortcuts itself?
[10:10] <wgrant> It does.
[10:10] <Heller_Barde> ah
[10:10] <Heller_Barde> i don't use gnome and actually dont want to but nothing else is able to look appropriately aesthetic :(
[10:11] <Heller_Barde> oh well
[10:12] <hyperair> bah the two-stage rsync mirroring script from ubuntu is useless on slow internet connections
[10:13] <hyperair> rsync the debs first, then the indexes. sounds like the perfect idea. but then it takes so goddamn long to rsync the debs that the indexes have updated by then =.=
[10:13] <wgrant> hyperair: You're not meant to mirror the archive on dialup.
[10:13] <hyperair> wgrant: i'm not on dialup damnit
[10:14] <hyperair> wgrant: this is a university connection
[10:18] <mvo> pitti: I looked into #220890 and AFAICT the remaining issue is that source code is not recognized as "offical" on powerpc but binary deb lines are. so it should be ok for -update (and I will push another one afterwards that fixes the source lines)
[10:31] <pitti> mvo: ok, thank you
[10:32] <sebner> pitti: is your list for coping stuff from -proposed to -updated already empty (for intrepid)?
[10:32] <pitti> sebner: yes; see http://people.ubuntu.com/~ubuntu-archive/pending-sru.html
[10:33] <sebner> pitti: intrepid has 2 packages with 7 days ;D
[10:33] <pitti> sebner: but not verified one
[10:33] <pitti> s
[10:34] <sebner> pitti: what has to happen to make it verified?
[10:34] <pitti> sebner: test that the package in -proposed still works as usual, and that it fixes the bug, and give written confirmation of that in the bug
[10:35] <sebner> pitti: my package (audacious) has over 5 users can confirm that the update in -proposed fixes the issue ;)
[10:35] <pitti> sebner: ah, then nobody from motu-sru set the verification-done tag apparently; please do so then
[10:37] <sebner> pitti: done
[10:37] <pitti> thanks
[10:37] <sebner> pitti: np, thank you your copying then :D
[10:40] <tkamppeter> pitti, hi
[10:41] <tkamppeter> what is missing to get the CUPS SRU released?
[10:41] <pitti> tkamppeter: testing and being 7 days in -proposed
[10:49] <tkamppeter> pitti, did not know that there is a "minimum 7 days" condition. All bugs related to pstopdf are answered and the answers suggest that the problems which I have addressed with pstopdf are really solved.
[10:49] <pitti> tkamppeter: right, except for the 'prints garbage on samsung' for splix
[10:49] <pitti> but we can keep that open and still move to -updates
[10:50]  * ogra grumbles at asac ... my mobile phone is suddenly not detected as USB HDD anymore ... grrr
[10:51]  * mvo thinks that asac probably sneaked int ogra house just to play that trick on him
[10:51]  * ogra tries to get the pictures off the camera with bluetooth instead
[10:52] <ogra> mvo, he doesnt go that far south for playing tricks i bet :)
[10:52] <liw> ogra, perhaps he has agents everywhere?
[10:52] <ogra> haha
[10:52] <liw> he is, after all, a manager ;)
[10:53] <mvo> ogra: you never know, he is on vac, maybe that is part of his vacationfun ;)
[10:53]  * mvo stops being silly
[10:53] <tkamppeter> pitti, and the AppArmor thingy with the network protocols I can confirm. The problem appears (I have 6 network printers) on the machine where I did not update to -proposed and does not appear with the -proposed package.
[10:54] <pitti> tkamppeter: can you please say so in the bug, for having a written track of testing?
[10:56] <tkamppeter> pitti, done.
[11:02] <tkamppeter> pitti, the garbarge printing which you observer with SpliX now is most probably a problem of SpliX itself. Therefore I need you to do tests with the LSB packages from OpenPrinting. The test on 2.0.0rc2 can reveal whether there is perhaps a bug in the Ubuntu packaging. The test of the 1.1.1 version can show whether the 2.x generation of SpliX introduced a new bug.
[11:02] <pitti> tkamppeter: ah, ok; I'll do that
[11:03] <tkamppeter> pitti, I have modified the OpenPrinting packaging last week so that these drivers can coexist with the ones coming from the distros.
[11:03] <tkamppeter> So you do not need to uninstall any package.
[11:20] <wgrant> mvo: Does do-release-upgrade do the xorg.conf inputdevice mangling too?
[11:21] <ogra> wgrant, what mangling ?
[11:22] <wgrant> ogra: We comment out inputdevices on upgrades to let input-hotplug work its magic.
[11:22] <ogra> xorg will ignore keyboard and mose settings from the file if not forced
[11:22] <wgrant> No it won't...
[11:22] <ogra> thats inside xorg afaik
[11:22] <wgrant> Really new xservers will ignore kbd and mouse entries, as evdev needs to grab them.
[11:23] <ogra> there was a setting i dont remember you have to add to the xorg.conf to make it use these entries
[11:23] <wgrant> AutoAddDevices, yes.
[11:23] <ogra> right
[11:23] <wgrant> But that's not what I'm talking about here.
[11:23] <ogra> else it will use evdev by default
[11:23] <ogra> and ignore the xorg.conf entries for keyboard and mouse
[11:24] <wgrant> I know, but this is somewhat separate.
[11:24] <ogra> for other input devices it depends on the driever ...
[11:25] <ogra> i.e. wacom will only use hal if yu copy the .fdi in place, else xorg.conf should be used
[11:25] <wgrant> And lots of them will break horribly, which is why we now comment them out on upgrades.
[11:25] <ogra> really?
[11:25]  * ogra wasnt aware we touch xorg.conf at all
[11:25] <wgrant> As of late Intrepid we do.
[11:26] <ogra> hmm
[11:31] <tkamppeter> pitti, I have investigated bug 293883 now and it is an evince bug, so it does not block the SRU release of CUPS. pstopdf was not the culprit there.
[11:38] <cjwatson> NCommander: we tried it before and it broke some people's hardware, so I'm not all that interested in trying it again TBH
[11:39] <NCommander> Works for me
[11:39]  * NCommander deletes the idea from his brain
[11:39] <mok0> rm -rf /sys/brain/idea
[11:39] <mvo> wgrant: yes
[11:39] <NCommander> mok0, file not found
[11:39] <wgrant> mvo: Hmm, OK, I have a report from somebody that it didn't.
[11:40] <mok0> hehe
[11:40] <wgrant> But perhaps not fully trustworthy.
[11:40] <mvo> wgrant: it writes out a log what its doing
[11:40] <mvo> wgrant: please ask the reporter about the stuff in /var/log/dist-uprade/*
[11:40] <mvo> wgrant: is there a LP bug for it?
[11:40] <wgrant> mvo: There isn't. I'll ask for logs.
[11:40] <mvo> thanks
[11:42] <hyperair> late intrepid touches xorg.conf?
[11:42] <wgrant> hyperair: Since late in the Intrepid release cycle, the dist-upgrader touches xorg.conf.
[11:42] <hyperair> oh
[11:42] <hyperair> what does it do
[11:43] <wgrant> Comments out inputdevices.
[12:00] <pitti> slangasek: I ported your hal patch 99_new-kernel-rfkill-interface.patch as best as I could to new hal upstream; but since I don't get any observable lshal change when flipping the killswitch either with your old nor with my ported patch, I can't really test it; can you?
[12:04] <slangasek> pitti: I guess that's for jaunty?  I'm afraid I can't test that very easily; but the main point would be whether NM detects the status change, I guess?
[12:05] <pitti> slangasek: yes, for jaunty
[12:05] <pitti> slangasek: well, NM doesn't do anything if I change the killswitch
[12:05] <slangasek> hmm
[12:05] <slangasek> not with either version?
[12:05] <pitti> but didn't do that in intrepid either
[12:05] <pitti> that's why I can't test the ported patch
[12:05] <slangasek> hrm
[12:05] <StevenK> slangasek: Bit early, isn't it?
[12:05] <slangasek> pitti: this is on a system with Intel wireless?
[12:05] <slangasek> StevenK: ?
[12:06] <StevenK> slangasek: It's 4am in LA
[12:06] <pitti> slangasek: yes, iwl3945 with dell killswitch
[12:06] <slangasek> pitti: do you have /sys/class/net/$dev/device/rfkill?
[12:06] <slangasek> StevenK: yep, right in the middle of my Monday shift
[12:07] <slangasek> pitti: (you're running the Intrepid kernel, right?)
[12:08] <pitti> slangasek: intrepid kernel> yes
[12:08] <pitti> slangasek: /sys/class/net/wlan0/device/rfkill/rfkill0/state
[12:09] <pitti> slangasek: I can put the new consolekit and hal into my intrepid PPA, if that would help you
[12:09] <slangasek> pitti: that would be better
[12:09] <slangasek> I'm still puzzled that it doesn't work for you, though
[12:09] <slangasek> for me, the nm-applet icon reflects the state change within a few seconds
[12:10] <pitti> well, the killswitch itself works
[12:10] <pitti> in the sense of that it blocks wifi
[12:10] <pitti> but NM doesn't react to that
[12:11] <slangasek> hmm
[12:11] <slangasek> then I guess my patch is screwed up somehow, even though IWFM :/
[12:11] <pitti> slangasek: someone else on the upstream bug confirmed that it works
[12:11] <pitti> seems hw specific
[12:11] <slangasek> yeah, I saw
[12:12] <slangasek> but I don't understand /why/ i would be hw-specific
[12:14] <pitti> slangasek: if you change the killswitch, do you see something in lshal flip state?
[12:21] <pitti> slangasek: both uploaded and building now
[12:23] <slangasek> pitti: lshal changes> no; though apparently if I'm lucky, I can hard-lock my laptop in the process
[12:24] <slangasek> pitti: but I guess calling 'hal-ystem-killswitch-get-power' directly should show the output?
[12:24] <slangasek> +s
[12:25] <pitti> w$ sudo ./hal-system-killswitch-get-power
[12:25] <pitti> .: 10: hal-functions: not found
[12:25] <pitti> bah
[12:25] <slangasek> doh
[12:25] <pitti> but it's there... ?!?
[12:33] <Nafallo> anyone know if we have support for Intel 4500MHD?
[12:33] <Treenaks> Nafallo: what is it?
[12:33] <Treenaks> Nafallo: a CPU?
[12:33] <Nafallo> Treenaks: some kind of new graphics thing.
[12:34] <Nafallo> I think :-P
[12:34] <Nafallo> Intel Graphics Media Accelerator 4500MHD DVMT (Dynamic Video Memory Technology)
[12:34] <Nafallo> yea. new GMA.
[13:00] <asac> ogra: so you want to use your phone as HDD and not 3G device ;)?
[13:01] <ogra> asac, well, it used to show up as HDD when i plugged it in with cable ...
[13:01] <ogra> but BT works fine for pulling off files
[13:02] <ogra> my phone has a 2G micro SD card i use as data storage from time to time
[13:02] <asac> ogra: when did USB stopp working?
[13:02] <ogra> no idea, i just pluged it in for the first time after an aeon
[13:02] <ogra> i dont think i even tried it in intrepid at all before
[13:03] <ogra> it used to show up as HDD in hardy iirc
[13:03] <asac> ogok
[13:03] <ogra> ogok ?
[13:03] <liw> I wouldn't mind using my phone as a storage device, too, in order to move files to the memory card
[13:03] <asac> ogra: do you have different modes?
[13:03] <asac> (on the phone)
[13:03] <ogra> its in usb storage mode by default ...
[13:04] <liw> (but I'm happy to shuffle the memory card around for now)
[13:04] <ogra> one sec, doorbell, brb
[13:04] <asac> ogra: maybe it was the airprime driver?
[13:05] <asac> (that one was dumbed in intrepid afaik)
[13:10] <mvo> cjwatson: do you happen to know if we use the wget udeb still these days? it got added by fabio in the feisty days and I was wondering if we should keep this change around or not
[13:15] <cjwatson> mvo: I think Fabio might have wanted it for system-integrity-check maybe? nothing in d-i itself uses it
[13:17] <mvo> cjwatson: yes, that looks right
[13:17] <mvo> thanks!
[13:17] <cjwatson> mvo: that said, I don't see anything in system-integrity-check that relies on it
[13:17] <cjwatson> oh, no, Depends: wget-udeb. WTF
[13:18] <cjwatson> fabbione: why was busybox's wget not good enough?
[13:18] <cjwatson> fabbione: it doesn't seem as if system-integrity-check uses any features not in busybox's wget
[13:31]  * NCommander laughs evilly
[13:32] <slangasek> jordi: yuck, why is there a lib64asound2-plugins?  Is there really a use case for 64-bit alsa support on 32-bit installs?
[13:32] <directhex> NCommander, evil laughter? that can only mean added mono! ;)
[13:33] <NCommander> slangasek, offhand, I'm going to guess for compiler biarch sanity
[13:33] <slangasek> huh?
[13:33]  * NCommander shakes head
[13:33] <NCommander> Wow, I'm loosing it
[13:33] <NCommander> just ignore me
[13:34] <NCommander> directhex, actually, debhelper 7 was backported (thank you slangasek)
[13:34] <NCommander> That unblocks at least 10, maybe more backports
[13:34] <directhex> NCommander, version?
[13:34] <NCommander> hardy-backports
[13:35] <directhex> i meant actual package ver
[13:37] <NCommander> directhex, the one from intrepid, 7.0.13ubuntu1
[13:40] <pitti> StevenK: what's the rationale for your pilot-link patch 30_3_arg_open.dpatch? no patch headers, no bug refs, no rationale in changelog :(
[13:41] <fabbione> cjwatson: at the time, it was not good for https. We started doing all the stuff to https and the whole thing was stalled on lack of time
[13:41] <cjwatson> oh, right
[13:41] <pitti> StevenK: oh, nevermind, got it
[13:42] <cjwatson> mvo: ^- above is still the case
[13:42] <fabbione> cjwatson: not sure if wget in busybox does https now.. nor if ubuntu cares about s-i-c. I gave it to the server team a while ago.. no idea if they have done anything about it
[13:43] <cjwatson> I don't think anyone cares very much about s-i-c any more, but wget doesn't do https and that seems like a valid use case
[13:43] <cjwatson> busybox wget that is
[13:44] <fabbione> cjwatson: ok. I personally don't think i care nor i have time to do s-i-c. Might worth discussing it again with the server team and free resources at the datacenter since there is a server side for it
[13:44] <pitti> StevenK: did you send it to an upstream ML? I don't find an upstream bug tracker
[13:44] <fabbione> cjwatson: the code is still in bzr somewhere public I believe. anyway the last releae in the archive had everything that was in bzr anyway
[13:52] <mvo> cjwatson, fabbione: right, thanks
[14:02] <fabbione> mvo: no worries :)
[14:04] <Keybuk> cjwatson: still trying to figure this udev bzr packaging case out
[14:04] <Keybuk> hit another problem; the udev git repository doesn't contain (as you'd expect) configure, Makefile.in, etc.
[14:04] <Keybuk> which means merging with "bzr pull" isn't going to produce something like the orig.tar.gz
[14:05] <Keybuk> the diff.gz will always end up with autoconf changes
[14:06] <Mithrandir> not if you nuke them in the clean target
[14:06] <Mithrandir> (and build-depend on auto*)
[14:08] <pitti> Keybuk: what's wrong with having autogenerated autofoo stuff in the diff.gz?
[14:08] <pitti> it might not be nice, but well, it's just noise
[14:09] <Keybuk> pitti: well, fwics, I have two options
[14:09] <Keybuk> clean bzr packaging, based off a git import, with merges and changes done with bzr nicely - but messy resultant traditional source package
[14:09] <Keybuk> or a clean source package, created by lots of by-hand heavy lifting with bzr/git
[14:10] <Keybuk> also wouldn't it break colin's "what you checkout from bzr must be buildable" requirement?
[14:11] <pitti> james_w: do you care about backuppc? You did the last merge, but it's currently on my plate since I did a last-minute dependency fix
[14:11] <pitti> Keybuk: can't speak for others, but for e. g. jockey I don't care about messy diff.gz if the ubuntu package is a direct branch of upstream trunk
[14:12] <james_w> pitti: I did the last merge as it was DIF and unmerged I believe.
[14:12] <james_w> pitti: I don't mind merging again if you want it off your plate
[14:12] <Keybuk> pitti: but then debcheckout doesn't give you anything buildable?
[14:12] <pitti> Keybuk: since you aren't going to use patch systems or MoM for those, messy diff doesn't really hurt IMHO
[14:12] <pitti> Keybuk: it should be buildable, of course
[14:12] <pitti> Keybuk: debian/rules could just call autogen.sh?
[14:12] <Keybuk> how do you make it buildable?
[14:12] <Keybuk> but then the package has to depend on auto*
[14:13] <pitti> lots of packages do
[14:13] <Keybuk> please nuke autogen.sh ;)
[14:13] <pitti> (yes, I repeatedly argued against it in the past, for packages which update autofoo on build)
[14:13] <cjwatson> Keybuk: james_w may have technology to generate the tarball branch (i.e. git + configure/etc.) automatically
[14:13] <pitti> Keybuk: or autoreconf -v, or whatever :)
[14:13] <james_w> lies!
[14:14] <cjwatson> autogen.sh> still useful when you're doing things that autoreconf doesn't do :P
[14:14] <pitti> james_w: ok, nevermind then; I just wondered if you were actually using it and could test it or so, but seems not :)
[14:14] <james_w> though it might be possible thinking about it
[14:15] <Keybuk> it'd have to be a Build-Depend-Indep on auto*, right?
[14:15] <cjwatson> james_w: the only hard bit is identifying the revision from which the tarball was produced; after that you just unpack and blat the changes into the archive
[14:15] <Keybuk> or is it only build-depends?
[14:15] <cjwatson> Build-Depends is stronger than Build-Depends-Indep in practice
[14:15] <cjwatson> policy is extremely confusing on this
[14:15] <Keybuk> yeah, I've never really understood it
[14:16] <Keybuk> at one point I thought -Indep was for "things needed to make the source package"
[14:16] <Keybuk> but it appears policy disagrees on that now
[14:16] <cjwatson> basically I only use Build-Depends-Indep if either (a) I have an explicit build-indep rule and the dependency is only used there and/or (b) it's only used in binary-indep
[14:16] <cjwatson> I don't think policy ever said anything like that
[14:16] <pitti> Keybuk: the way I understood it, you don't need -indep when building with -B
[14:16] <pitti> such as the !i386 buildds
[14:16] <NCommander> I was under the impression that Build-Dep-Indep is anything the independent build-deps needed explicately
[14:16] <Keybuk> cjwatson: it's entirely likely it didn't ;)
[14:16] <cjwatson> oh, it might have had confusing language about clean at some point
[14:16] <Keybuk> thought of the day: we should have an autoreconf meta package :p
[14:17]  * pitti generally just ignores B-D-I, too confusing to think about
[14:17] <cjwatson> yeah, that's usually the right answer
[14:18] <cjwatson> there are a small number of cases where it is important and/or useful
[14:18] <pitti> that the !i386 buildds use -B is really just an implementation detail packagers shouldn't really care about, FWIW
[14:18] <pitti> cjwatson: oh? so there's more to it than just buildds?
[14:19] <cjwatson> pitti: no, I didn't say that :)
[14:19] <cjwatson> pitti: I just meant that it is usually reasonable to default to sticking everything in B-D, and only think about B-D-I if you find you need to
[14:19] <pitti> ah, right
[14:20] <siretart> a common case is running doxygen to create an libfoo-doc package. doxygen can go to B-D-I then
[14:20] <ScottK> I'm looking at a package that has gone uninstallable in Jaunty because it believes it needs to depend on a non-existant package called glibc-private.  Rebuilding produces the same result.  Package builds and produces an installable binary on Intrepid.  Any suggestions about where to look?
[14:21] <pitti> ScottK: sounds like a bad .shlibs file?
[14:21] <siretart> ScottK: bad shlib.local file in the package?
[14:21] <pitti> ScottK: if local build does the same, grep /var/lib/dpkg/info/*.shlibs for glibc-private?
[14:21] <cjwatson> ScottK: that means that the package is relying on private glibc symbols and it shouldn't be
[14:21] <cjwatson> ScottK: it's basically glibc arranging for the package to blow up
[14:21] <pitti> oh, magic
[14:21] <siretart> sweet
[14:21] <ScottK> Argh.  OK.  Thanks for the hints.
[14:22] <ScottK> Yes.  Does the same thing on local builds, so I'll look.
[14:22] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462444
[14:22] <ScottK> Thanks.
[14:23] <cjwatson> I think you can pass -xglibc-private to dpkg-shlibdeps to skip it if you know what you're doing
[14:23] <cjwatson> but it's probably worth investigating first
[14:24] <ScottK> OK.  I'm definitely in an area where "know what I'm doing" doesn't apply.
[14:25] <ScottK> Which is, of course, half the fun.
[14:28] <Keybuk> cjwatson: did you autosync contrib or non-free?
[14:32]  * ogra wonders if MoM is broken 
[14:32] <ogra> or probably she simply forgot i exist
[14:34] <pitti> ogra: curious
[14:34] <ogra> i only seem to have one package in universe
[14:34] <pitti> ogra: you've got stuff on http://merges.ubuntu.com/universe.html, thoug
[14:34] <mvo> ogra: generally it seems to be running quite happily
[14:35]  * mvo just checked the logs 
[14:35] <ogra> which additionally is better off to be merged by LaserJock
[14:35] <cjwatson> Keybuk: not yet
[14:35] <cjwatson> Keybuk: doing so now
[14:36] <pwnguin> Hobbsee: looking at the record thus far, I don't think the recent post by Vincenzo is "normal" in tone or language. it also doesn't reflect my own interactions with him.
[14:40] <siretart> Mithrandir: did you have the chance yet to look into the pkg-config issue slomo and I asked you about?
[14:40] <Mithrandir> siretart: I didn't, no. :-/
[14:41] <pwnguin> It does reflect somewhat my own frustration with the status quo, but I'm not about to write angry letters over it
[14:41] <hyperair> what pkg-config issue?
[14:42] <Keybuk> ogra: ;)
[14:42] <ogra> :)
[14:42] <Keybuk> I suspect it's because you've got your "you touched it last" list down to almost zero
[14:43] <ogra> seems like
[14:43] <ogra> which is weird
[14:43] <siretart> hyperair: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504220
[14:43] <ogra> i thought i touched a good bunch
[14:43] <Keybuk> not really, you tend to touch things in universe more than main
[14:43] <ogra> but i'll pick up leftovers
[14:44] <Keybuk> and universe has a high "fix after freeze" ratio
[14:44] <hyperair> hm ubottu handles debian bugs too?
[14:44] <hyperair> i never knew
[14:44] <ogra> yeah, since i'm in mobile i touch a lot of universe
[14:46] <Mithrandir> siretart: you need to depend on the -dev packages.
[14:47] <siretart> Mithrandir: but isn't that insane? why do depending packages need to care about whether libavcodec-dev links against libtheora or not?
[14:48] <Mithrandir> siretart: if it is in "Requires.private", then it not only links with it, but also needs the headers from it.
[14:48] <Mithrandir> like gtk exposes glib types in its headers.
[14:48] <siretart> Mithrandir: libavcodec does not TTBOMK expose any libtheora internals
[14:48] <Mithrandir> if it just links with it without exposing any of libtheora's types, using libs.private should be fine.
[14:49] <siretart> okay. is there any documentation or any document I could point upstream at to get that fixed?
[14:49] <Mithrandir> once I get around to writing it. :-/
[14:49] <siretart> may I quote this irc conversation?
[14:53] <Mithrandir> sure.
[15:02] <tkamppeter> pitti, did you do the test for bug 292690, I have also added another possibility to test.
[15:08] <fta> dear archive admins, please, consider opening the ppa gates to jaunty.
[15:09] <cjwatson> is it our decision?
[15:09] <cjwatson> I thought that was an LP thing
[15:09] <fta> i asked there 1st => <cprov> fta: the decision belongs to the archive-admins at this point, so #ubuntu-devel might be a better place to discuss it.
[15:09] <cjwatson> cprov: do it
[15:09] <cjwatson> I don't think we have the lever; if we do then please tell me
[15:10] <cprov> cjwatson: okay, I will organise the opening
[15:10] <cjwatson> cprov: I can't think of any reason why we wouldn't want to open a distroseries for PPAs at the same time as we open it for regular uploads. Do you know why it is done separately?
[15:12] <cprov> cjwatson: those decisions are still orthogonal in the DB. We open a new distroseries by change its status from frozen to development
[15:12] <cprov> cjwatson: PPA archs are enabled per distroarchseries base.
[15:13] <cjwatson> cprov: OK, I'll edit our NewReleaseCycleProcess to say we need to notify you to enable PPAs
[15:14] <cprov> cjwatson: right, if you think it's appropriate, we could try to glue those decisions in a single form.
[15:14] <cprov> https://launchpad.net/ubuntu/jaunty/{i386, amd64, lpia}/+admin
[15:14] <cjwatson> cprov: I don't mind as long as it gets done; a note in NewReleaseCycleProcess should be good enough
[15:15] <cjwatson> cprov: yeah, I don't have access to that
[15:15] <cjwatson> see also: why can't distro drivers administer distroseries, eh?
[15:15] <cprov> cjwatson: me neither, I will ask kiko.
[15:16] <fta> cprov, cjwatson: wonderful, thanks guys :)
[15:21] <jordi> slangasek: I assumed it is as useful as lib64asound2
[15:25] <cprov> cjwatson: fta: jaunty PPAs are supported.
[15:26] <fta> great
[15:28] <cjwatson> thanks!
[15:29] <siretart> cprov: when exactly did you enable jaunty PPAs?
[15:30] <cprov> siretart: few minutes ago.
[15:30] <siretart> ah, ok. I tried this morning and got my upload rejected
[15:31] <hyperair> ...what happens when someone uploads a html file that redirects to a virus site to launchpad? =.=
[15:31] <hyperair> https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695
[15:31] <hyperair> see the last comment
[15:35] <ScottK> hyperair: You should take that up in #launchpad.
[15:35] <hyperair> lol
[15:37] <tkamppeter> pitti, ping
[15:40] <ScottK> hyperair: Why is that funnny?  They're the only ones that can do anything about it.
[15:41] <hyperair> yesy es
[15:41] <hyperair> well, i'm the kind of person who laughs when yet another windows user gets struck by a virus
[15:41] <hyperair> i'm evil like that
[15:42] <hyperair> anyway i've alerted the guys at #launchpad
[15:47] <pitti> tkamppeter: hi
[15:48] <pitti> tkamppeter: btw, I can't configure the lsb splix2 packgage; s-c-p doesn't find it, and if I select the PPD manually, I just get an internal cups error
[15:48] <directhex> mono 2.0-1 very soon, apparently
[15:51] <pitti> tkamppeter: oh, nevermind, it didn't get configured (lsb dependency isn't installed)
[15:52] <pitti> tkamppeter: yep, works now
[16:07] <pitti> tkamppeter: new filter tested now, too
[16:21] <evand> Anyone have a 4GB USB disk, a recent Apple computer, and a free moment to test something for me?
[16:23] <liw> evand, I'm lacking all three, but just for clarification: do you need exactly 4 gigs or at least 4?
[16:23] <evand> at least
[16:24] <evand> (I have an image to dd to such a disk, so the other requirement would be a disk that you don't care about :)
[16:27] <pitti> pedro_, sbeattie: any chance to give gparted in hardy-proposed a test, for bug 37768? I was the uploader, so I need a second tester
[16:31] <mvo> kirkland: hello! how often is update-motd run ?
[16:31] <kirkland> mvo: every 10 minutes;  i'm putting a delayer in the script i'm working on to ensure that the update-notifier bit wouldn't run more frequently than once per hour
[16:32] <mvo> kirkland: the update-notifier bit is to pick up notification from user.d/ ?
[16:33] <kirkland> mvo: actually, i meant: /usr/lib/update-notifier/apt-check
[16:33] <kirkland> mvo: i propose something like this: http://pastebin.ubuntu.com/70058/
[16:33] <kirkland> mvo: call it "notify-updates-available"
[16:33] <mvo> kirkland: aha, ok - I'm adding support for new release upgrade notification into update-manager-core right now (just fyi) - and it should ideally be only once a day
[16:34] <kirkland> mvo: similar to "notify-reboot-required"
[16:34] <kirkland> mvo: cool, what i'd really like is just a number dumped into /var/run/updates-available
[16:35] <kirkland> mvo: also, i find it really, really odd that /usr/lib/update-notifier/apt-check puts the number of updates available on STDERR ... why's that?
[16:35] <mvo> kirkland: would it make sense to have a /etc/update-motd.d{.daily/,.hourly, etc} ?
[16:35] <kirkland> mvo: yes, i'm working on that, as update-motd's upstream
[16:35] <kirkland> mvo: i intend to do that very soon
[16:35] <mvo> kirkland: its a workaround because sometimes other stuff gets spit onto stdout
[16:35] <kirkland> mvo: oh
[16:36] <kirkland> mvo: it gave me a few fits :-)
[16:36] <kirkland> mvo: i got around it
[16:36] <mvo> kirkland: would it make sense to just modify apt-check so that it has a "--for-update-motd" (or something like that) so that it prints out exactly what you need?
[16:37] <mvo> kirkland: update-notifier has a lot of UI dependencies, so changes to update-notifier are required I assume?
[16:37] <kirkland> mvo: right, i'd need something in update-notifier-common
[16:37] <kirkland> mvo: can't really bring all those UI deps into ubuntu-server
[16:38] <kirkland> mvo: what cronjob currently drives apt-check?
[16:38] <mvo> kirkland: indeed :) so if we need to do that anyway, I wonder if we should have a apt-check that is tailored to the needs of update-motd in the sense that it outputs the right kind of message (with i18n and everything)
[16:39] <mvo> then all that is needed is that it installs a symlink to update-motd and is done with it
[16:39] <kirkland> mvo: okay, so i have throw one more wrinkle into the mix ...
[16:39] <mvo> kirkland: update-notifier itself drives apt-check, it has inotify rules to monitor apt/dpkg so that it known when it should (re)check for updates
[16:40] <kirkland> mvo: i think it's going to be landscape-sysinfo that's going to gather this info
[16:40] <mvo> kirkland: hm
[16:40] <kirkland> mvo: so landscape-sysinfo could even use a python library to grab this from apt-check
[16:41]  * mvo scratches his head and thinks about it a bit
[16:43] <sbeattie> pitti: I'll take a peek
[17:33] <ddfire> hi
[17:33] <ddfire> i need help making a deb package
[17:33] <ddfire> or backporting asterisk 1.4.21 from 8.10 to 8.04
[17:33] <ddfire> anyone have an idea?
[17:34] <ddfire> a pdf?
[17:34] <ddfire> a clue?
[17:34] <Nafallo> ddfire: wrong channel. try #ubuntu-motu.
[17:34] <ddfire> Nafallo: thanks
[17:36] <ddfire> Nafallo: what is the objetive of this channel?
[17:36] <Nafallo> ddfire: what the topic says ;-)
[17:38] <EtienneG> quick question ... will we get Mono 2.0 in Jaunty?  I suppose so, just wondering.
[17:44] <ddfire> ok
[17:44] <ddfire> thanks
[17:47] <maxb> The intrepid-backports devscripts has broken the "dch --distributor" option :-/
[17:48]  * maxb wanders in the direction of launchpad
[17:52] <pitti> mvo: is it really deliberate that apt-get build-dep installed packages get auto-removed?
[17:52] <pitti> it makes 'autoremove' pretty useless on a developer box
[17:57] <ScottK> Maybe we need apt-get autoremove-build-dep-yes-really
[17:59] <maxb> "apt-get build-dep" is an explicit user request to install packages, so shouldn't they count as manually installed?
[17:59] <cjwatson> I could go either way
[18:00] <cjwatson> often build-dep is only very temporary for me
[18:00] <cjwatson> install, build, remove
[18:00] <cjwatson> anyway:
[18:00] <cjwatson>   * make "apt-get build-dep" installed packages marked automatic
[18:00] <cjwatson>     by default. This can be changed by setting the value of
[18:00] <cjwatson>     APT::Get::Build-Dep-Automatic to false (thanks to Aaron
[18:00] <cjwatson>     Haviland, closes: #44874, LP: #248268)
[18:00] <cjwatson> so change that configuration option if you don't like it
[18:01] <ion_> Yeah, build-deps are typically temporary – if i want -dev packages that stay, i can make them manually installed.
[18:03] <pitti> cjwatson: ah, thanks; so feature, not bug
[18:06] <liw> I tend to find that apt's (or aptitude's) heuristics of autoremovable packages meshes badly with what I want to keep, but I am probably excentr^Wodd
[18:11] <ion_> liw: You might want to try debfoster. I use that (and apt-mark-sync to sync its decisions to apt and aptitude).
[18:20] <apachelogger> james_w: we are going to discuss bzr for KDE packages at the next Kubuntu meeting, please select agreeable time slots at http://doodle.com/participation.html?pollId=tvt9bb3fvtbqda8v
[18:26] <bryce> slangasek: hey, SRU question for you
[18:28] <bryce> slangasek: wacom tablets are fairly broken right now in Intrepid.  There is a newer version of the linuxwacom driver in Jaunty (0.8.1-6 vs 0.8.1-4) with necessary fixes.  Would a sync of something like that be conceivably within the realm of possibility?
[18:45] <jdong> bryce: since it's the same upstream version can't we just call it a "SRU"? :)
[18:46] <bryce> jdong: guess that's my question ;-)
[18:46] <pwnguin> bryce: isn't it really hard to test jaunty right now?
[18:46] <bryce> pwnguin: indeed.  In this case, the users self-compiled the driver and tested it on intrepid.
[18:46] <jdong> I mean if wacom is "fairly broken" IMO it wouldn't hurt to do some ~proposed testing. If you have big enough a base, put it into a PPA I guess
[18:46] <pwnguin> i mean, im all for better wacom; the status quo is terrible
[18:46] <jdong> s/base/bug subscriber base/
[18:47] <pwnguin> i hope i dont have a big ppa base
[18:48] <pwnguin> anyways, i dont have the right hardware to test
[18:48] <jdong> me neither.
[18:48] <jdong> christmas presents welcome ;-)
[18:48] <pwnguin> heh
[18:48] <bryce> well, I'm trying to determine how much time this is going to require.  If we can just sync it in, it should be a reasonable amount of time and I'll give it a shot.  If it's going to require patch cherry picking, ppa testing, and so on, I likely won't have sufficient time to see the whole thing through to completion, so ought to focus my efforts elsewhere.
[18:49] <jdong> bryce: well I assume the differences between debian revision 4 and 6 is just going to be a lot of debian/patches magic, right?
[18:50] <bryce> probaby
[18:50] <bryce> +l
[18:50] <jdong> I'd just package all of those patches into a SRU-like version number (i.e. -4ubuntu0.1) and consider that a SRU candidate, get a couple users to tell you it works okay, then you're done :)
[18:51] <jdong> (QA FOLKS PLEASE LOOK AWAY)
[18:51] <pwnguin> heh
[18:51] <pwnguin> what's the worst that can happen?
[18:51] <pwnguin> wacom remains broke?
[18:51] <jdong> pwnguin: from the way it sounds, it can't get any worse.
[18:51] <jdong> s/any/much/
[18:52] <pwnguin> i suppose it could crash X
[18:52] <jdong> I wouldn't expect that to happen with the kind of changes in a new debian revision though.
[18:52] <pwnguin> but the recovery tools are supposed to be bulletproof now ;)
[18:53] <jdong> I'd be a lot more scared if it were an entire new upstream release and a huge diff
[18:55] <mvo> pitti: it was a feature request to have it this way, -o apt::get::build-dep-automatic=false turns it off
[18:55]  * ScottK notices the upload of sane-backends and waits for insane-backends .
[18:55] <mvo> pitti: I don't mind either way, I can switch it to the reverse again
[18:56] <sebner> ScottK: I just subscriped MC, I'll recieve more and more questions so it's easier
[18:56] <pwnguin> bryce: fyi, wacom is apparently scheduling a new release next week ;)
[18:56] <ScottK> sebner: OK.  You know you didn't really answer all my questions in your reply.
[18:57] <sebner> ScottK: well, I didn't know. apachelogger told me. So maybe I'm missunderstanding you or my lack of english skills has the fault
[18:57] <bryce> pwnguin: nice... wonder if they'll include the changes needed for hal
[18:58] <pwnguin> i suspect not;
[18:58] <pwnguin> The new hotplugging (Xorg 1.5.1 or later) will be supported with linuxwacom version 0.8.4 (0.8.3 will be its unstable release).  It is too late to add the support to the coming stable release (0.8.2), which is scheduled to be posted this week.
[18:58] <pwnguin> ""
[18:58] <ScottK> sebner: I'll write a new mail.
[18:58]  * ScottK waits for jdong to package insane-backends
[18:59] <sebner> ScottK: yeah! yet another mail. keep going. I have a bet running that I'll recieve more than 10 questions :D
[19:00] <ScottK> sebner: Sent.
[19:02] <sebner> ScottK: now I'm subscriped, Does also my pending question (for dholbach) get's posted?
[19:03] <ScottK> sebner: You mean you sent a reply to dholbach?  If so, I haven't seen it.
[19:03] <sebner> ScottK: besides .. would you mind explaining your question question  ^ ^  I don't know what you want. A specific example?
[19:03] <sebner> ScottK: well, I wasn't subscriped so it was pending
[19:04] <sebner> or still is
[19:04] <ScottK> Yes.  An example of one you wish you had asked for and didn't and one you wish you hadn't asked for and why, what you learned, etc.
[19:06] <sebner> ScottK: I made mistakes (like syncs that were merges) but I don't have regrets about any sync that filed
[19:06] <sebner> + I
[19:06] <ScottK> sebner: Then comment on that to the ML.
[19:07] <sebner> ScottK: ah, ok (though it seems that is not the answer you wanted to hear) :)
[19:10] <sebner> ScottK: ah ah ah. I lost your mail xD would you mind resending it to me?
[19:16] <geser> sebner: I've just moderated your mail to motu-council
[19:17] <sebner> geser: thx, I'm now subscriped. sry for the trouble
[19:19] <sebner> geser: but please don't vote yet. still more questions are in the pipelie ;D
[19:19] <sebner> *pipeline
[19:22] <james_w> apachelogger: done, thanks. Unfortunately I can't commit to any times this week, but I will do my best to attend if one of those times is picked
[19:32] <apachelogger> james_w: looks like it's gonna be sunday since you have time and we have a quorum for the membership application :)
[19:32] <james_w> I have time, but I may be asleep :-)
[19:36] <ScottK> james_w: As long as you're awake enough to simulate agreement to do stuff, I think it'll be fine.
[19:37] <ScottK> Better you're not awake enough to really process it anyway.
[19:38] <james_w> heh :-)
[19:39] <ScottK> apachelogger: He thinks I'm kidding.
[19:50] <superm1> kees, ping
[19:51] <apachelogger> james_w: no one really is awake at kubuntu meetings, at least I am not, I usually just drop off some lines and continue dozing ;-)
[20:01] <kees> superm1: pong
[20:01] <superm1> kees, i'm thinking something in default build flags decided to wreck some havock
[20:01] <superm1> kees, would you mind taking a look, i think you saw this before: bug 296453
[20:01]  * kees goes to read
[20:02] <kees> heheh, that's a great build log
[20:03] <kees> superm1: I thought cvs was fixed for hardening weirdness.  I will poke at it.
[20:04] <superm1> thanks
[20:36] <kees> superm1: I can't reproduce the cvs crashes...
[20:47] <slangasek> jordi: right, so how useful is /that/? :)
[20:49] <slangasek> bryce: wacom tablets are broken in intrepid aside from the known, release-noted fdi issue?
[20:49] <superm1> kees, i'm assuming on jaunty up to date chroot?
[20:50] <superm1> i've got a local sbuild lvm snapshot that is fully updated with no delta otherwise ( both i386 and amd64) that reproduce it
[20:51] <kees> superm1: might be a bit out of date, let me try it again, on sec
[21:03] <cyberix> In some previous version of Ubuntu I double clickked on a gnumeric file and it suggested I should install gnumeric.
[21:03] <cyberix> Why doesn't this work anymore?
[21:18] <kees> superm1: here's the note I removed about cvs: https://wiki.ubuntu.com/CompilerFlags?action=diff&rev2=27&rev1=26
[21:19] <kees> superm1: I still can't reproduce on either amd64 or i386, updated jaunty chroots
[21:19] <superm1> kees, how weird that you can't reproduce.  i can in sbuild, pbuilder, and on buildd's
[21:19] <bryce> slangasek: yeah, additional bugs
[21:20] <superm1> kees, so try to rebuild cvs with that env variable and see if things improve then?
[21:20] <kees> superm1: are there any minimal commands that fail for you?
[21:20] <slangasek> bryce: what bugs are those?
[21:21] <kees> superm1: yeah, that'll certainly force those checks off in cvs, but I'd like to have a better idea of what's going wrong.
[21:21] <superm1> kees, the most minimal command that fails is "cvs status"
[21:22] <kees> .... uhm
[21:22] <kees> it's failing for me now.
[21:22] <kees> wtf.
[21:23] <NCommander> hey superm1
[21:23] <superm1> hi NCommander
[21:23] <NCommander> superm1, how goes it?
[21:23] <superm1> NCommander, busy as usual :)
[21:23] <bryce> slangasek: like #291908, hangs device when any pressure is on it
[21:24] <NCommander> superm1, busy with what specifically; anything I can do to hep?
[21:25] <superm1> NCommander, with work related things, so not really so much.  but if you are looking for bugs to fix on stuff, i've got plenty i can point you at :)
[21:25] <NCommander> heh, ScottK just got me on one :-)
[21:27] <kees> superm1: ah-ha, cvs 1:1.12.13-11 happened on Jan 27, 2008.  Hardening was enabled on Jun 08, 2008.
[21:27] <bryce> slangasek: basically my question is whether a sync of the driver is feasible, or if the individual fix needs to be identified and SRU'd by itself
[21:27] <kees> superm1: so, this is a problem now (I have no idea how it was ever noticed during intrepid... weird)
[21:28] <superm1> kees, ah so it never got rebuilt for hardening.  the fact that we synced is why it happens now
[21:28] <kees> superm1: right.  I'm curious how the problem in the wiki was ever noted, but when I tested it had "gone away" since it wasn't rebuilt yet.  wheee
[21:28] <superm1> kees, well at least i'm catching this early You've got eon's to ponder on it now. :)
[21:29]  * kees wonders why it doesn't freak out in fedora...
[21:45] <jackrabbit> I'm having a problem running autogen.sh on a svn build of network-manager-applet since upgrading to 8.10
[21:45] <jackrabbit> the error I get is: libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
[21:46] <jackrabbit> libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
[21:46] <jackrabbit> libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
[21:46] <jackrabbit> does anybody know what's causing this?
[21:48] <cjwatson> jackrabbit: surely that is a warning, not an error; if you aren't the developer you can ignore it
[21:48] <jackrabbit> well, it started after I upgraded and then I got some other errors as well
[21:48] <cjwatson> then you should investigate the things that are actually errors
[21:48] <jackrabbit> and . . . I ma developing
[21:48] <jackrabbit> :)
[21:49] <cjwatson> the output you quote from libtoolize is clear instructions to developers on changes in libtool macro handling
[21:49] <jackrabbit> which I believe are responsibles for the errors later on
[21:49] <cjwatson> but, as you can tell from the language used ("Consider ..."), they don't need to be fixed immediately
[21:50] <cjwatson> jackrabbit: it seems unlikely, but it is impossible to tell without knowing what those errors are
[21:50] <jackrabbit> cc1: warnings being treated as errors
[21:50] <jackrabbit> utils.c: In function ‘utils_fill_connection_certs’:
[21:50] <jackrabbit> utils.c:231: error: implicit declaration of function ‘nm_setting_802_1x_set_ca_cert_from_file’
[21:50] <jackrabbit> utils.c:235: error: implicit declaration of function ‘nm_setting_802_1x_set_client_cert_from_file’
[21:51] <cjwatson> totally and utterly unconnected to the libtoolize output
[21:51] <cjwatson> what is the svn url?
[21:51] <jackrabbit> I think they're caused by the abcense of header files
[21:51] <cjwatson> what would libtoolize have to do with header files?
[21:51] <cjwatson> (it operates on objects and has nothing to do with headers)
[21:51] <jackrabbit> svn://svn.gnome.org/svn/network-manager-applet/trunk
[21:52] <jackrabbit> cjwatson: I'm not that familiar with libtool/autotools etc
[21:56] <cjwatson> jackrabbit: the network-manager-applet version you're compiling requires a newer NetworkManager than what's packaged in Ubuntu 8.10
[21:57] <cjwatson> jackrabbit: the nm_setting_802_1x_set_ca_cert_from_file and nm_setting_802_1x_set_client_cert_from_file functions were added in revision 4239 of NetworkManager, which was committed on the day 8.10 was released
[21:57] <jackrabbit> that's svn too
[21:57] <jackrabbit> ok, I'll re-install and see if that helps
[21:58] <cjwatson> that suggests that you are not successfully using the headers from the NetworkManager you built, but are instead using the system headers, then
[21:59] <jackrabbit> cjwatson: mind if I ask how you figured that out?
[21:59] <cjwatson> how I figured which bit out?
[22:00] <jackrabbit> that the symbols were from a newer version than 8.10
[22:00] <cjwatson> jackrabbit: I checked out NetworkManager, grepped for that function, used 'svn blame' to find out when the lines in the header file in question were last changed, and used 'svn diff' to confirm that the revision in question was the one that initially introduced those symbols
[22:01] <cjwatson> and then 'svn log' told me the commit date which was later than the time 8.10 was released so I didn't need to look any further than that
[22:02] <jackrabbit> ok
[22:02] <jackrabbit> thanks, now I'll be able to check that out next time :)
[22:08] <directhex> hm, /me spots a minor bug
[22:08] <directhex> looks like a gtk label doesn't have pango markup enabled on it
[22:44] <kees> holy cow.  cvs implements its own kind of asprintf.
[22:44] <kees> and manually constructs %n-using vsprintfs
[23:07] <kees> superm1: well that was fun to track down.  I've uploaded a fixed cvs now.
[23:09] <NCommander> hey kees
[23:09] <kees> hola NCommander
[23:09] <NCommander> So here's my research
[23:09] <NCommander> If you have a prebuilt PIE GCC and glibc, you can install it into an existing system
[23:10] <NCommander> But I need doko's help to actually get a usable patch, mine breaks the C++ compiler from compiling :-/
[23:10] <kees> why do gcc and glibc need to be PIE before I can built other PIE stuff?
[23:10] <kees> er, can build
[23:10] <NCommander> no, if you want glibc/gcc to be pie
[23:10] <NCommander> :-)
[23:10] <NCommander> You can have PIE binaries without them
[23:11] <kees> I'm happy to move one step at a time
[23:11] <NCommander> kees, if your going to be at UDS, we could work on this there (aka, get the spec fully hammered out and such)
[23:11]  * kees nods
[23:11] <kees> yup, I'll be there.  :)
[23:12] <NCommander> That way, we can also pin doko and extract the secrets of GCC from his brain
[23:14] <elmo> woo, security vs. toolchain!
[23:14] <elmo> it wouldn't be a UDS without it!
[23:14] <kees> :)
[23:15] <elmo> \o/
[23:15] <wgrant> Toolchain always wins.
[23:15] <elmo> wgrant: this time, kees brought reinforcements
[23:15] <elmo> TAG TEAM CAGE MATCH
[23:15] <kees> though, I think I still lost since I ended up joining the toolchain group.  :P
[23:16] <NCommander> We should have a four way fight, toolchain v. server v. kernel v. security!
[23:16]  * NCommander runs
[23:16] <wgrant> elmo: But now you've warned doko of the evil reinforcement plan.
[23:16] <NCommander> elmo, got a moment?
[23:17] <wgrant> Do the archive admins know that Jaunty PPAs are waiting on them now, or are we in a deadlock like we were with Intrepid translations?
[23:17] <elmo> NCommander: not really, but what's up?
[23:18] <NCommander> elmo, its yet another PPA question. I have a pending request to see if the kernel team can get a non-virtualized PPA for the linux-ports kernel. Obviously building the -ports kernel on x86/amd64 is of *ahem* limited value :-)
[23:18] <NCommander> er
[23:19] <NCommander> THat wasn't meant to be a PM
[23:19] <NCommander> https://answers.edge.launchpad.net/soyuz/+question/48531 - the distro team asked me to bring to the PPA admins
[23:19] <wgrant> NCommander: You mean the other way around?
[23:20] <NCommander> wgrant, what the otherway around?
[23:20] <wgrant> The PPA people seem to be asking you to ask the distro team, not vice-versa.
[23:20] <NCommander> the distro team sent me back :-P
[23:20] <wgrant> Ah.
[23:20] <NCommander> EINFINITELOOP
[23:24] <elmo> well
[23:25] <NCommander> Ports is somewhat unique, since even just finding some of the hardware *cough*hppa*/cough* is a down right pain
[23:50] <kees> ogra: can you handle the moodle merge? the security fixes I added are all in the Debian package now.
[23:59] <DoYouKnow> how do I get the latest development kernel on ubuntu?