[12:10] <Seveas> _ion, ping
[12:10] <_ion> seveas: Pong.
[12:11] <Seveas> _ion, the madwifi-ng patch required for wpa seems to work for madwifi-old too
[12:11] <Seveas> you need to patch manually, but the spot is easy to locate
[12:11] <_ion> Ok, thanks.
[12:11] <Seveas> that combined with robert love's NM patch should give you something much more usable
[12:12] <_ion> Yep.
[12:20] <Burgwork> http://www.kdedevelopers.org/node/1868  <-- funny
[12:29] <LaserJock> Burgwork: lol
[12:45] <jdub> wow, beineri actually is an all-round prick
[12:46] <Seveas> jdub, wouldn't know about the shape, but yeah...
[12:48] <tseng> yay for trolls
[12:49] <Burgwork> personally, I think it is funny
[12:50] <xhaker> it is.. but it was not meant to be.. so i think it's abusive
[12:50] <jdub> hard to find it amusing when you know it's not done for amusement value alone
[12:50] <Burgwork> I don't have history
[12:52] <Burgwork> ie, I haven't seen what he has produced before
[12:52] <xhaker> who here thinks is more ripped off (in the internet bill) than me?
[12:53] <Kinnison> well, canonical are
[12:53] <Fujitsu> Where are you, Kinnison, and why is it so expensive!?
[12:53] <Kinnison> london
[12:53] <Kinnison> orange wireless
[12:53] <Kinnison> :-)
[12:53] <Fujitsu> Ahh
[12:53] <Fujitsu> What's happening there?
[12:54] <Kinnison> Lots of Soyuzery in my case
[12:54] <Kinnison> xhaker: that's a bit expensive
[12:54] <Fujitsu> It is pretty expensive...
[12:55] <Fujitsu> AU$49.95 per month, 10Mbits cable...
[12:55] <Fujitsu> Wait for it...
[12:55] <Fujitsu> 1GB traffic limit.
[12:55] <xhaker> Portugal is so messed up with price fixing in broadband :( 
[12:55] <xhaker> 1GB?
[12:55] <Fujitsu> I could download that in less that 10 minutes!
[12:56] <xhaker> Fujitsu: 1GB a day? month?
[12:57] <xhaker> 1GB per month must be a lie
[12:57] <Fujitsu> Month.
[12:57] <Fujitsu> OptusNet.
[12:57] <Fujitsu> It's really great.
[12:57] <Fujitsu> Stupid parents :(
[12:57] <xhaker> so you spend those 1000Mb on irc traffic?
[12:57] <xhaker> .P
[12:57] <Fujitsu> I can't really do much else :(
[12:58] <Fujitsu> 30MB a day :(
[12:58] <Fujitsu> I have to go to friends houses to upgrade every couple of days...
[12:58] <xhaker> i don't even understand the traffic limits, there shouldn't be traffic limits.. the man that thought of imposing traffic limits must be a rich bastard
[12:58] <Fujitsu> Yep.
[12:59] <Fujitsu> Velly lich.
[12:59] <Fujitsu>  .
[12:59] <Fujitsu> OOps.
[12:59] <Fujitsu> Not Russian...
[12:59] <Fujitsu> Australian broadband prices are, as a rule, expensive.
[01:01] <xhaker> Fujitsu: my friend phoned the support line of his ISP, and said he wanted to terminate his contract. they offered him 4mbits connection + 30gb traffic monthly for 23euros
[01:01] <Fujitsu> Heh
[01:01] <Fujitsu> Not bad.
[01:02] <xhaker> i think i need him to meet them for me
[01:02] <Kamion> Ha
[01:02] <Kamion> Working i18n in espresso, I think
[01:03] <Fujitsu> Nice.
[01:03] <Kamion> not perfect, but getting there
[01:03] <Kinnison> Kamion: cool
[01:04] <xhaker> now that i think of it..
[01:04] <xhaker> i cannot make type the euro symbol on my keyboard :S
[01:04] <_ion> Fortunately there are no traffic limits in normal ADSL connections here in Finland.
[01:05] <xhaker> s/make/""
[01:05] <_ion> 
[01:05] <Fujitsu> Gar.
[01:05] <xhaker> _ion: Ludon will have 1Gb connection per house, you lucky "people".
[01:05] <Fujitsu>   .
[01:05] <Fujitsu> Not again >_<
[01:05] <xhaker> _ion: how do you type 
[01:06] <Fujitsu> "Silly silly Finland."
[01:06] <_ion> xhaker: I switch to the Finnish layout and press altgr-e.
[01:06] <Kamion> Kinnison: can't sleep, still waiting for the remaining bolts to arrive so we can put our bed together; bed isn't a terribly appealing option :-/
[01:06] <Fujitsu> Hahah
[01:06] <xhaker> _ion: omg.. i was trying altgr+5
[01:06] <_ion> It works as well.
[01:06] <Kinnison> Kamion: hehe
[01:07] <xhaker> mj59 you up?
[01:07] <xhaker> i meant mjg59
[01:12] <xhaker> what have you decided to do with Acer "wierd" keyboard keys.. like  and $ ?
[01:13] <xhaker> they see ignored for now
[02:27] <LeeJunFan> how does one go about adding a page to the wiki? I'd like to write somethign up for diskless server/clients with dapper.
[02:28] <LeeJunFan> I see editing, stuff in the docs but not creation.
[02:28] <_ion> Just type the title to the URL and edit.
[02:29] <LeeJunFan> _ion: ah, I see - thanks.
[02:30] <_ion> That's how it works in all the wikis.
[02:30] <_ion> Or alternatively make a link from another page to the page you want to create, click it and edit.
[02:57] <jdub> LeeJunFan: have you looked at the ltsp support in ubuntu (or are you writing about exactly that)?
[02:58] <LeeJunFan> jdub: no, not remote X, just multiple PC's booting w/o disk and then sharing the same filesystem via NFS
[02:59] <LeeJunFan> I finished setting up my library like that today, 22 diskless workstations. But with 22 workstations and the possibility of many of them running openoffice at the same time I don't think I could buy enough RAM for the server, and the PC's are all new and fast with enough RAM, so let them to the processing work.
[03:00] <LeeJunFan> my library == my local library, not my workplace.
[03:02] <Kamion> fabbione: I've fixed a couple of bugs in partman_newlayout (manual partitioning didn't work from the autopartition-one-device menu which meant it was inaccessible if you only had one disk, and backup from that menu didn't work in the single-disk case)
[03:02] <Kamion> fabbione: uploading in a moment
[03:08] <bddebian> infinity: You around?
[03:11] <minghua> bmonty: ping
[03:11] <bmonty> hi minghua 
[03:12] <minghua> bmonty: IIRC, you were the one who did m17n-db new version upload, right?
[03:12] <bmonty> minghua: yes
[03:12] <minghua> bmonty: we now have https://launchpad.net/distros/ubuntu/+source/scim-m17n/+bug/34851
[03:12] <Ubugtu> malone bug 34851 in scim-m17n "scim crashes Xchat" [Normal,Unconfirmed]  
[03:26] <Chipzz> jdub: the guy is a kde developer; what did you expect? ;)P
[03:28] <infinity> bddebian: Am now.
[03:29] <bddebian> infinity: Is there any chance I could bug you for a little bit about something?
[03:29] <infinity> bddebian: Depends on what it is.  Just spit it out.
[03:31] <bddebian> infinity: Well I am trying to set up a repository and was hoping you'd take mercy on me and help me?
[03:32] <infinity> Define "set up"... You want to create a Packages.gz and a Sources.gz from a bunch of files in a directory (man dpkg-scan{packages,sources}), do the same for a bunch of files in a tree (man apt-ftparchive), or set up something that allows uploads and does publishing (apt-cache show mini-dinstall)?
[03:33] <bddebian> I want to pull Ubuntu source packages, tweak them a little, dput them up and have them in /pool/main/foo/bar
[03:34] <infinity> Then you want mini-dinstall, probably.
[03:34] <infinity> Or "dak" (which is what Debian uses), but you could spend weeks/months learning how dak works, which is why mini-dinstall was written. :)
[03:34] <bddebian> Well that's wehre I'm getting a little lost.  mini-dinstall, dinstall, dak, reprepo...
[03:35] <infinity> dak is serious overkill.
[03:35] <jdub> Chipzz: for a long time there's been a good relationship between the *developers*, but it has started eroding recently.
[03:35] <infinity> It's meant for massive installations (like Debian, or like Ubuntu, before we switched to Launchpad)
[03:36] <_ion> I found reprepro to be very nice.
[03:36] <bddebian> infinity: Right, but mini-dinstall won't create the binaries right?  Or am I lost as usual?
[03:36] <bddebian> _ion: Yeah?
[03:36] <infinity> bddebian: Erm, "create the binaries"?  You mean, you also want a build daemon?
[03:36] <bddebian> Well that was my question.  I assume I need one?
[03:36] <infinity> bddebian: Just do source+binary uploads to your mini-dinstall repo. (using whatveer you want to do binary builds, pbuilder, sbuild, whatever you're comfy with)
[03:37] <_ion> Nicer than mini-dinstall IMHO.
[03:37] <bddebian> Well it will be basically a copy of xubuntu
[03:37] <infinity> bddebian: If you really need build daemons, you need more than a "quick chat" with me, I suspect.
[03:37] <bmonty> bddebian: mini-dinstall works great and is fairly easy to set up
[03:37] <bddebian> bmonty: I know for local, but I'm looking at 1800/1900 packages :-)
[03:38] <infinity> I tend to prefer mini-dinstall too, since it behaves a bit like dak, which I'm comfy with.
[03:38] <infinity> But to each their own.
[03:39] <infinity> bddebian: If you're only building for one arch, just do source+binary uploads to your repo.  Trust me, that's MUCH less hassle than also maintaining some sort of buildd infrastructure for one user.
[03:40] <infinity> bddebian: If you're doing multiple arches, you can either feed them all manually, or you may want to start looking at wanna-build, but it's not simple (and without some heavy tweaking, wanna-build will want a dak installation to hang out with)
[03:40] <bddebian> infinity: Well eventually I hope it's more than one user.. :-)
[03:40] <infinity> bddebian: One user uploading was what I meant.
[03:41] <bddebian> Oh, hehe
[03:41] <bddebian> Well I HOPE there's more than that too :-)
[03:42] <tritium> bddebian: are you starting ubuntu-hurd?  ;)
[03:42] <bddebian> tritium: No, though I would still like to :-)
[03:43] <tritium> hmm, that was my best guess as to what you're up to :)
[03:43] <Kamion> I got tantalisingly close to getting a bootable hurd-i386 d-i the last weekend I tried hacking on it
[03:43] <Kamion> but wasn't quite there yet
[03:43] <bddebian> Kamion: Really?
[03:44] <infinity> Kamion: Find other ways to spend your spare time, kthx.
[03:44] <Kamion> yeah, just need to attack the CD boot sequence harder
[03:45] <Chipzz> jdub: I realise the irony in my statement (in that I'm "trolling" myself), but note the ";)P" (ie don't take to seriously); but I guess it's mostly individuals, not the whole (kde and/or gnome) community at alrgew
[03:45] <Kamion> infinity: any other useful hacking I can think of would be near-term usable by Ubuntu and thus qualify as work not relaxation ;-)
[03:45] <infinity> Kamion: Hahaha.
[03:45] <Kamion> and I'm an installer hacker, I like making systems boot when they really don't want to and putting stuff together from tiny pieces all over the floor
[03:47] <infinity> So, what's so mystical about booting the Hurd?... Is grub still the only bootloader that knows how to boot it, so you have to chain syslinux to grub?
[03:48] <infinity> Or are we talking failure much later on, like "the system, once booted, refuses to talk to the CD properly", or some such?
[03:48] <Kamion> no point chaining syslinux to grub, just boot straight from grub
[03:49] <Kamion> the mystical bit is getting it to boot from CD and have a writable root filesystem
[03:49] <Kamion> because it has no initrd concept as such
[03:49] <bddebian> infinity: So mini-dinstall will handle binary+source uploads coming in to incoming?
[03:49] <infinity> bddebian: That's the theory, yes.
[03:49] <bddebian> theory? :-)
[03:49] <infinity> bddebian: Since binary+source is the Debian standard, and mini-dinstall was written to run on people.debian.org, I'm going to go with "yes". :)
[03:50] <infinity> bddebian: (I say theory a lot, when I really mean, "try it yourself, I know it works, but you won't beleive me anyway until you make it go on your own")
[03:50] <Kamion> you have to set up a ramdisk translator on the fly that's backed by the compressed filesystem on the CD, before you really get the rest of the Hurd running at all
[03:50] <bddebian> And we have issues with ramdisk/tmpfs :-(
[03:50] <infinity> Kamion: That does kinda sound like fun.
[03:50] <Kamion> it's not conceptually difficult, but the pieces involved are so much different from Linux that it's tricky to get your head around
[03:50] <Kamion> bddebian: oh?
[03:50] <Chipzz> infinity: is the hurd actually usefull for anything yet? ;)
[03:51] <infinity> Kamion: Too bad I have my own useless port to look after (one that actually installs, boots, runs, and has 95% of the archive built), or I'd be interested.
[03:51] <bddebian> infinity: Hurd boots and runs :-)
[03:51] <infinity> bddebian: LIES.
[03:51] <infinity> bddebian: Does it stay up for more than a few days now?
[03:51] <Kamion> mind you I quit looking at tmpfs as such and started looking at an insane pure-menu.lst storeio-based hack I found Roland McGrath posting about in 1998 or something
[03:51] <bddebian> And if people didn't use freaking PATH_MAX, MAXPATHLEN, et al, we'd probably have about 95% of the archive too :-)
[03:51] <infinity> bddebian: (while doing anything strenuous, like running a buildd)
[03:51] <_ion> chipzz: You can ping localhost.
[03:52] <bddebian> infinity: http://www.bddebian.com runs on it, check the uptime :-)
[03:52] <bddebian> Of course it has like 0 load :-)
[03:52] <infinity> Yeah, I'll reiterate the "strenuous" bit.
[03:52] <_ion> bddebian: Try running cpuburn for a while. :-)
[03:52] <Chipzz> last I heard dhcp didn't even work
[03:52] <bddebian> _ion: All I have to do is build glibc ;-P
[03:52] <infinity> ISTR the Debian hurd-i386 buildd could never manage more than a couple of days uptime.
[03:52] <Kamion> Chipzz: that was sorted a while back
[03:52] <jdub> oh man
[03:53] <jdub> so when someone does a hurd derivative
[03:53] <jdub> they can call it hubuntu
[03:53] <jdub> and the theme song would be
[03:53] <bddebian> No, it's UbuntGNU :-)
[03:53] <jdub> huuuuuuuuubuntu, hu-hu, hu-hu
[03:53] <bddebian> Or GNUbuntu
[03:53] <jdub> to the tune of who are you?
[03:53] <Chipzz> or gnubuntu ;)
[03:53] <jdub> bddebian: whois gnubuntu.org :-)
[03:53] <jdub> bddebian: and ask rms why he won't let us help gnu by using it :)
[03:54] <Kamion> gnubuntu could also mean a derivative built without restricted - name clash there
[03:54] <infinity> Hu's in the buntu, hu, hu, hu!
[03:54] <Chipzz> ah yes, thats rms ubuntu derivative
[03:54] <Chipzz> iirc
[03:54] <jdub> Chipzz: "ask rms why he won't let us help gnu by using it"
[03:54] <infinity> Kamion: I think the "no non-free" gnubuntu was already proposed...
[03:54] <Kamion> Chipzz: yri
[03:54] <bddebian> jdub: Fuck RMS :_)
[03:54] <Chipzz> jdub: "it"?
[03:54] <jdub> gnubuntu
[03:54] <ajmitch> bddebian: play nice :)
[03:55] <jdub> i so feel like blogging about that
[03:55] <Gman> fuck rms, please?
[03:55] <jdub> but i probably shouldn't
[03:55] <jdub> hrm
[03:55] <jdub> actually, that's an interesting point
[03:55] <infinity> bddebian: Anyhow, I'll happily toy with the idea of an Ubuntu/Hurd port when you can demonstrate that we won't have to reboot the buildds every 3 days. :)
[03:56] <jdub> "does your blog have to abide by the CoC if you're on puc?"
[03:56] <bddebian> infinity: Fair enough :-)
[03:56] <Kamion> the other reason to look at porting d-i to the Hurd is general portability
[03:56] <jdub> infinity: it's okay - jbailey will do it!
[03:56] <mjg59> jdub: Well, I'm not on puc...
[03:56] <infinity> jdub: The stuff syndicated to puc should, which is why you should only syndicate based on certain tags/topics, not the whole blog.
[03:56] <infinity> Kamion: Have the kfreebsd folk done much to get d-i going there yet?
[03:56] <jdub> mjg59: you have not asked for either of your blogs to be on puc
[03:57] <Kamion> it's a port that's reasonably accessible from the Debian point of view, but yet gives us the opportunity to start looking at the rampant Linuxisms scattered throughout d-i
[03:57] <jdub> infinity: but that goes against the whole point of planets
[03:57] <mjg59> jdub: I never post to one, and you refused to put the other on pgo
[03:57] <Kamion> infinity: absolutely nothing as far as I'm aware
[03:57] <Kamion> infinity: AFAIK they'd have similar booting fun, though it's been a while since I talked about it with mjg59
[03:57] <infinity> jdub: Not IMO... I'd like a certain amount of relevance in my planet, I don't want to read about how J Random Developer just spent the weekend flossing his grandmother's cows.
[03:57] <jdub> mjg59: this is a bitter stalemate that we may only be able to solve with tequila and blades attached to our fingers
[03:58] <infinity> jdub: I want some technical/social relevance to the planet in question.
[03:58] <bddebian> WTF? Canonical registered GNUbuntu??
[03:58] <jdub> infinity: culture killer
[03:58] <infinity> jdub: It may also help to note that I'm not a big fan of planets anyway. :)
[03:59] <infinity> (5 people whose blogs I find interesting, 45 people who I don't care about, I'd be better off reading the 5 individually)
[03:59] <Kamion> bddebian: the name's been tossed around for a long time, and we'd be happy to let people use it who were going to actually take it in plausible directions
[03:59] <jdub> gnubuntu was thought up mere moments after we talked about "hey, well, y'know, someone's just gonna add a K to that sucker..."
[03:59] <Kamion> Canonical has registered rather a lot of domains related to Ubuntu; Gnubuntu isn't particularly special in this regard
[03:59] <bddebian> Damn you people are tempting me... :-)
[03:59] <slomo> infinity: ross is doing funny things again... like not wanting to build anything :(
[04:00] <infinity> slomo: Did it just build banshee?
[04:00] <infinity> Yup.
[04:00] <infinity> slomo: Fixing.
[04:00] <slomo> infinity: banshee built fine but that was the last thing... is something broken with the banshee package?
[04:01] <infinity> slomo: No, something's goofy (but difficult to reproduce and track down) with the removal of one of banshee's build-deps, which someone managed to BREAK OUT of the chroot by accident and reset permissions on /dev/null in the base system.
[04:01] <infinity> Seriously.
[04:01] <infinity> FUN.
[04:01] <infinity> s/someone managed/somehow manages/
[04:02] <ajmitch> impressive
[04:02] <infinity> Wow, brain/finger disconnect there.
[04:02] <_ion> Wow. :-)
[04:02] <infinity> (Okay, it's easy for a process running as root to break out of a chroot, but it's bizarre for one to do it without trying...)
[04:03] <infinity> Anyhow.  It's on my list of things to care about when I have free time, but for now it's easier just to clean up after it.
[04:03] <bddebian> How do I run mini-dinstall on a "system" level rather than via a user?
[04:04] <infinity> Run it as a daemon.
[04:05] <infinity> And still have a dedicated user for it, cause running daemons as root is dumb.
[04:05] <infinity> slomo: Cleaned up; thanks for the heads-up.
[04:06] <infinity> slomo: You're still waiting on evolution-sharp, aren't you?  That's why you noticed. :)
[04:07] <infinity> slomo: Thankfully, ross finally seems to be done building the 5-day backlog of OpenOffice and compiler uploads <glares at doko>
[04:07] <slomo> infinity: exactly... i always watch my uploads until they failed/worked fine everywhere ;)
[04:07] <infinity> slomo: Good man.  More should follow your example.
[04:22] <Chipzz> +   512 Mar 17 Fran Hickman        (6513) Microsoft Adobe
[04:23] <Chipzz> what will those spammers come up with next? microsoft linux? :)
[04:27] <Lathiat> haha
[04:28] <Chipzz> Gman: I can shove a cup of tea up his arse next fosdem if you want to ;)
[04:29] <bddebian> _ion: Still here?
[04:29] <_ion> bddebian: Yep.
[04:30] <bddebian> _ion: Where did you put your conf file for reprepro in /dists/ ?
[04:32] <_ion> bddebian: Here's a live example, http://johan.kiviniemi.name/ubuntu/ . Look at the conf directory.
[04:33] <bddebian> _ion: Awesome, thanks!
[04:53] <bddebian> infinity: Still awake?
[04:54] <infinity> I should hope so, it's only 3pm.
[04:54] <bddebian> Oh, heh, sorry
[04:55] <bddebian> Got a suggestion for an ftpd to process incoming?
[04:56] <bddebian> I used to use wuftp but everyone always gave me shit for it :-)
[04:56] <infinity> bddebian: I like ProFTPd and vsftpd.
[04:56] <bddebian> OK thx
[04:56] <infinity> vsftpd has the advantage of being in main.
[04:56] <infinity> ProFTPd is really simple to understand if you know Apache configuration.
[04:57] <bddebian> hmm
[05:05] <bddebian> infinity: To point /incoming to dir /archive/incoming, use alias like apache?
[05:06] <infinity> http://www.proftpd.org/docs/
[05:07] <infinity> In your case, you probably just want a DefaultRoot and DefaultChdir for the anonymous user.
[05:11] <bddebian> Thx
[05:19] <bddebian> FUCK, sometimes having to sudo everything pisses me off
[05:20] <nekohayo> has someone experienced weirdness with nm-applet lately?
[05:21] <nekohayo> like, networkManager tries to connect me to an impossible local IP (169.254.195.122)
[05:21] <nekohayo> instead of being assigned something in 192.168.1.x
[05:21] <bddebian> That looks like it can't find a DHCP server ( if that even makes sense)
[05:23] <Fujitsu> That means it can't get DHCP.
[05:23] <Fujitsu> It an automatically self-assigned IP.
[05:23] <nekohayo> what could cause that?
[05:23] <Fujitsu> No DHCP server.
[05:23] <nekohayo> it's totally random it seems
[05:24] <Burgundavia> no, 169 is a defined spec for address self assignment
[05:24] <Burgundavia> windows and OS X will also do this
[05:24] <nekohayo> whew
[05:24] <Fujitsu> Yes.
[05:24] <Fujitsu> Everything has to, or it doesn't meet the IP specs.
[05:24] <Burgundavia> by default, a linux machine will not, afaik
[05:24] <_ion> 169.254.0.0/16 - This is the "link local" block.  It is allocated for communication between hosts on a single link.  Hosts obtain these addresses by auto-configuration, such as when a DHCP server may not be found.
[05:24] <_ion>  RFC 3330
[05:25] <Fujitsu> Linux machines will!
[05:25] <nekohayo> my dhcp server is a simple linksys router, it always worked fine so far, it's the first time I see this
[05:25] <_ion> My guess would be that it's used for the mdns stuff.
[05:27] <_ion> Nope. "Any DNS query for a name ending with ".local." MUST be sent to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent FF02::FB).
[05:27] <nekohayo> would it be safe to assume it's a software misconfiguration or..? how could I determine this?
[05:27] <nekohayo> it happens with both wired and wireless
[05:27] <Burgundavia> it might be your router
[05:27] <bddebian> Gah, why doesn't proftpd wanna start as inetd?
[05:27] <nekohayo> hmm
[05:27] <nekohayo> I guess I have to do a full reset to test
[05:28] <nekohayo> question: does nm-applet conflict with gnome's network-admin in any way? is there something I must be aware of ?
[05:28] <nekohayo> as I could not find things on that matter on the project page
[05:29] <_ion> You should disable everything from gnome's network-admin ( from /etc/network/interfaces  except lo, of course). That way network-manager gets to do its job.
[05:29] <nekohayo> ok I did
[05:30] <nekohayo> I'll try restarting the router and see if that may be the problem then
[05:30] <nekohayo> brb (and thanks all)
[05:39] <nekohayo> nope, not the router
[05:39] <nekohayo> other ideas? or is there a debug mode or verbose option I could use?
[05:39] <nekohayo> if it's a bug I'd like to report it, but I'm pretty empty handed ;)
[06:10] <tritium> Is there a policy or spec on /var/run being a tmpfs, and how to handle that properly in init scripts?
[06:12] <infinity> The "proper" way to handle it is to make sure it exists with the right ownership/permissions before your daemon starts. :)
[06:12] <infinity> (Or in the daemon itself, if you're clever)
[06:13] <infinity> s,it exists,the subdirectory you want in /var/run exists,
[06:14] <infinity> Note that for (at least) everything in main, we're about to run through and fix anything that hasn't already been fixed.
[06:14] <infinity> And if Keybuk's feeling keen, he may do some/most/all of universe. :)
[06:14] <tritium> infinity: it's tor (in universe)
[06:15] <ajmitch> is keybuk really that bored?
[06:19] <infinity> ajmitch: No, he's just really that responsible for changing /var/{run,lock} to tmpfs, so he gets to clean up the mess. :)
[06:19] <infinity> (If his cleaning doesn't go well, he'll get help, I suspect)
[06:19] <ajmitch> something to delegate to MOTUs for universe, as far as it's possible
[06:21] <tritium> As I learn best by example, I'll look for a package that's handling it cleanly already, and try to fix tor.
[06:21] <infinity> Sure, and if you guys want to start grepping now and fixing stuff, that's less stuff for him to fix later. :)
[06:21] <infinity> tritium: apache2 has handled it for ages in its init script.
[06:21] <tritium> thanks, infinity.  Will check it out now.
[06:21] <infinity>                 # /var/run and /var/lock could be on a tmpfs
[06:21] <infinity>                 [ ! -d /var/run/apache2 ]  && mkdir /var/run/apache2
[06:21] <infinity>                 [ ! -d /var/lock/apache2 ]  && mkdir /var/lock/apache2
[06:21] <infinity>                 # Make sure /var/lock/apache2 has the correct permissions
[06:21] <infinity>                 chown www-data /var/lock/apache2
[06:22] <infinity> (That's in the start target)
[06:22] <tritium> That helps :)
[06:22] <infinity> You can get that in one shot by using "install" instead of "mkdir && chown"
[06:22] <infinity> (If you need to care about permissions)
[06:23] <tritium> which I do
[06:25] <infinity> So, for apache, I'd do "[ ! -d /var/lock/apache2 ]  && install -m 755 -o www-data /var/lock/apache2"
[06:25] <infinity> (Which I may change it to in the next upload)
[06:25] <Mithrandir> or just do install -m 755 -o www-data -d /var/lock/apache2
[06:25] <Mithrandir> (unconditionally)
[06:26] <infinity> Oh, missed the -d on that. :)
[06:26] <fabbione> iirc install complains if the dir is already there
[06:26] <infinity> Mithrandir: Will -d foo not return non-zero if it's there?
[06:26] <tritium> This mentoring is great!
[06:27] <infinity> Oh, it does ignore existing directories.  Spiff.
[06:27] <infinity> tritium: What Mithrandir says, then.
[06:28] <tritium> aye.  Thanks to infinity, Mithrandir, and fabbione.
[06:28] <infinity> You forgot to thank your mom.
[06:28] <infinity> And your producer.
[06:28] <fabbione> what have I done this time?
[06:28] <tritium> The teleprompter was saying "wrap things up"... :)
[06:28] <fabbione> i swear i didn't touch the BIG RED BUTTON
[06:28] <infinity> fabbione: Spoke.
[06:28] <fabbione> oh ok :)
[06:28] <Mithrandir> infinity: yeah, seems to DTRT for me.
[06:29] <infinity> Mithrandir: Yeah, I had to test myself before I believed you. :)
[06:29] <infinity> You know me.
[06:29] <Mithrandir> infinity: I had to test myself and look at $? before I believe mee, too.
[06:29] <Mithrandir> me, even
[06:30] <fabbione> infinity: it's about time :)
[06:30] <infinity> I curiously noticed that in my last upload, when "removing cruft", I kinda removed too much "cruft"... Didn't notice until I installed apache2 on the sparc buildds (which run dapper). :)
[06:31] <fabbione> ehe
[06:31] <fabbione> infinity: monday or tuesday i will give you access to a serious sparc
[06:31] <fabbione> it depends how fast i can get the blood lines for it
[06:31] <infinity> I'm happy with my little sparcs.
[06:31] <infinity> They're fast enough for all but toolchain hacking.
[06:32] <fabbione> mine is too fast.. even for toolchain hacking
[06:32] <infinity> Nothing is ever too fast for toolchain hacking.  Ever.
[06:32] <fabbione> infinity: you joking right?
[06:32] <fabbione> it's faster than an e10k
[06:32] <infinity> Until you can do a 10-stage GCC bootstrap in a couple of minutes, anyway.
[06:32] <infinity> I expect a chroot and an account to test this theory. :)
[06:33] <fabbione> approx 32 times faster than the toys you have
[06:33] <infinity> And so help me god, if you impose ulimits, I'll setit on fire remotely... Somehow.
[06:33] <fabbione> sure
[06:33] <fabbione> no i don't use ulimit
[06:33] <fabbione> i hate ulimit
[06:33] <fabbione> that's how I found a small memory corruption but in the kernel when building with make -j8192
[06:33] <fabbione> s/but/bug
[06:37] <infinity> It's impressive that the kernel's makefiles are sane enough that you can build with that level of parallellisation.  I suppose you weren't the first to try, though. :)
[06:37] <fabbione> well the kernel stops forking at about 7500
[06:38] <fabbione> that's the amount of files we do build on sparc for our kernel :)
[06:38] <fabbione> i was the first onn that CPU to do that
[06:38] <infinity> I assume that years ago, when Linus decided to use an 8-way box as his primary workstation, he started stumbling on a bunch of bugs in the dependencies.
[06:38] <fabbione> i know IBM did it on some super machines to test stuff
[06:39] <fabbione> yeah
[06:39] <fabbione> go alpha!
[06:39] <infinity> And DEC, for that matter.
[06:39] <fabbione> i always wanted one
[06:39] <fabbione> never able to get one
[06:39] <fabbione> (for free)
[06:39] <fabbione> but i will get there sooner or later
[06:40] <infinity> I have one, but it doesn't (can't) run Linux.
[06:40] <infinity> I always intended to do a Debian/NetBSD-alpha port, but never found any round tuits.
[06:40] <fabbione> hey you can run windows on it
[06:41] <Lathiat> hehe
[06:41] <fabbione> Lathiat: no, it's damn true
[06:41] <fabbione> at the time there was a version for alpha cpu
[06:41] <infinity> No, can't run NT on that one either.
[06:41] <Lathiat> yeh i know, NT runs on alpha
[06:41] <Lathiat> :)
[06:42] <Lathiat> infinity: what is it?
[06:42] <infinity> It's a TurboChannel DEC AlphaServer, they only ever ran OSF and VMS
[06:42] <fabbione> infinity: doh..
[06:42] <infinity> The other option has been to port the TurboChannel drivers from Linux/MIPS to Linux/Alpha, but the same round tuit issue cropped up.
[06:43] <infinity> And now it's in my friend's basement, happily running NetBSD.
[06:43] <infinity> And probably keeping him awake at night with all the fans. :)
[06:44] <infinity> (s/OSF/Digital UNIX/ or s/OSF/Tru64/, depending on how old you are)
[06:45] <infinity> Obviously, I'm an old fart. :/
[06:46] <fabbione> wow.. hppa managed to build the installer?!?!?
[06:46] <fabbione> that's scary
[06:46] <fabbione> infinity: no. you are not THAT old
[06:46] <Lathiat> <-- 18
[06:47] <fabbione> Lathiat: you are a kid
[06:47] <infinity> fabbione: hppa's coming back.. Slowly. :)
[06:47] <fabbione> infinity: yeah..
[06:47] <fabbione> let's hope the new kernels are a bit better
[06:47] <fabbione> both ia64 and hppa are farting on me
[06:47] <infinity> It's also hilighting a mess of FTBFSs in the archive that I missed on previous looks through logs, which is nice. :)
[06:47] <fabbione> ehhe
[06:47] <infinity> Well, if lamont ever gets that hppa machine to me, I'll happily tweak the kernel a bit.
[06:48] <fabbione> infinity: we should probably start considering a dapper auto-rebuild-of-death
[06:48] <infinity> Yes, it's overdue.
[06:48] <infinity> I meant to get it underway right after FeatureFreeze.
[06:48] <fabbione> infinity: nah.. it's stuff that not even parisc guys can get fixed...
[06:48] <fabbione> there is a big issue with the toolchain
[06:48] <infinity> fabbione: Yeah, but I've been wanting to get my hands dirty in the parisc kernel for a while.
[06:48] <infinity> (And the toolchain)
[06:49] <fabbione> where in pa1.0 mode, the code cna't do jump with offset bigger than 17bit
[06:49] <fabbione> that makes basically a bunch of kernel modules unloadable
[06:49] <fabbione> it goes very very very very deep into the toolchain
[06:49] <Mithrandir> infinity: we're aiming for a flight at end of next week, so I would really like to have the buildds not choking at your rebuild of death at that point.
[06:50] <infinity> Mithrandir: Well, we'll either do the rebuild on the wanna-build buildds (so they don't affect you), or I'll have to talk to the LP folk to get segregation, so we can do rebuilds without affecting the distro.
[06:50] <infinity> Mithrandir: At this point, the wanna-build option seems more realistic, if we want the rebuild RIGHT NOW (which we kinda do)
[06:51] <Mithrandir> infinity: or at least being able to tell the buildds that there is more important stuff going on and if they would please drop whatever they're doing and get to useful work, that'd be nice.
[06:51] <Mithrandir> infinity: sure, I don't mind if they're a tad slower as long as it's not "no, you can't build anything for three days because the buildds are busy".
[06:51] <fabbione> Mithrandir: did you already write and approved a spec for it?
[06:52] <Mithrandir> fabbione: is this the point where I ask you to sod off? :-)
[06:52] <fabbione> Mithrandir: it's the point in which you can autoanswer yourself that it will be done with w-b :)
[06:53] <Mithrandir> fabbione: oh, the rebuild, no I'm not responsible for that, so I'm not writing a spec for it.
[06:53] <fabbione> Mithrandir: ehhe
[06:54] <infinity> Mithrandir: By "end of next week", you mean in ~7 days?
[06:56] <fabbione> infinity: what did BusError ?
[06:56] <fabbione> that usually means that there is a non-64bit alligned access in mem
[06:57] <infinity> fabbione: ghc6... I'm tossing it back to see if it was random (which some are), and if it's not, it's probably an alignment issue that needs to be patched.
[06:57] <fabbione> infinity: ok.. mostlikely the second one
[06:57] <fabbione> too bad ghc6 can't fork in the build
[06:57] <Mithrandir> infinity: yes.  Or ten days.  Depending on how I feel.
[06:58] <infinity> Mithrandir: Alright, well, I'll try to get my hacking with cprov in at the beginnning of the week so you have me as a slave at the end.
[06:58] <Mithrandir> infinity: ooh, slave, fun.
[06:59] <Mithrandir> infinity: I hope I won't require much from you in the end, but we'll see.
[06:59] <Mithrandir> infinity: are you going out to visit the PENGUINS next weekend too?
[06:59] <infinity> Mithrandir: Hey, I'm happy with you taking over Flight releases completely, but one never knows. :)
[06:59] <Mithrandir> sure, tag-teaming is fun
[06:59] <Mithrandir> but, I gotta go for a while.  See you around.
[06:59] <infinity> Mithrandir: No penguins, though I do like to keep my weekends pretty sacred and "non-work", until we're in release crunch mode.
[06:59] <Mithrandir> sure
[07:28] <_ion> Now all the patches from the official network-manager package except for 20-linux-wlan-ng.patch should ported in my 0.6 package.
[07:31] <infinity> _ion: Cool.  And do they appear to work as expected?
[07:32] <_ion> infinity: Yes so far. Of course the package needs a lot of testing.
[07:33] <whiprush> _ion: can you please cc fridge-devel@ubuntu.com when you announce widespread testing?
[07:33] <_ion> whiprush: Will do.
[07:33] <whiprush> thanks
[07:49] <infinity> fabbione: Do you have any urge to look at why redland-bindings is FTBFS on sparc, despite building fine everywhere else?
[07:57] <fabbione> infinity: is that main?
[07:58] <fabbione> infinity: looking at it
[07:58] <infinity> fabbione: It claims to be.
[07:58] <fabbione>  ?1.0.2.1-1ubuntu4
[07:58] <infinity> https://launchpad.net/distros/ubuntu/+source/redland-bindings/1.0.2.1-1ubuntu4
[07:59] <fabbione> ok
[07:59] <infinity> (And yes, I've already retried the build in the past, same failure)
[07:59] <fabbione> chekcing now
[07:59] <infinity> So, I assume some sort of toolchain buggery earlier up in the log, and I'm too lazy to look right now. :)
[08:01] <fabbione> infinity: it builds here
[08:01] <fabbione> let me check something else too
[08:01] <infinity> Oh, joy.
[08:02] <infinity> Could be something sketchy like a corrupt ccache.
[08:02] <highvoltage> me hates "it works in windows"
[08:02] <infinity> Though that's pretty rare when it happens.
[08:03] <fabbione> infinity: let me try with a super clean buildd chroot
[08:03] <infinity> You can have the one I'm using, if you have decent bandwidth to the DC. :)
[08:04] <infinity> Only 42 megs.
[08:04] <fabbione> infinity: i do.
[08:04] <fabbione> but i can debootstrap locally..
[08:04] <infinity> fabbione: chinstrap:~adconrad/
[08:04] <fabbione> infinity: ok
[08:04] <infinity> fabbione: To be just like a buildd, just dist-upgrade it when you get in there, and set /CurentlyBuilding appropriately. :)
[08:05] <fabbione> infinity: yeah i know the trick
[08:06] <infinity> I know.  Just being "helpful". :)
[08:08] <infinity> Hrm, ghc6 hasn't failed yet on vivies, I think the BusError was cosmic rays.
[08:09] <fabbione> infinity: it might be, but it's not a good sign
[08:09] <infinity> No, it's not.
[08:09] <infinity> I used to get them (randomly) on Sparc all the time, though.
[08:11] <fabbione> infinity: do you still mount /proc and dev/pts in the chroots?
[08:11] <infinity> Yes, though the latter is pointless.
[08:11] <infinity> (Since they have a full set of legacy PTYs as well)
[08:11] <fabbione> ok
[08:16] <fabbione> infinity: it does build here.. even with your chroot..
[08:17] <infinity> fabbione: Well, that's fantastic.
[08:17] <infinity> I'll kick it back one more time. :)
[08:17] <_ion> seveas: Does this look right at all? http://johan.kiviniemi.name/tmp/madwifi-robertlove-danwilliams.patch
[08:17] <_ion> seveas: It's made against the current linux-restricted-modules source package.
[08:17] <fabbione> infinity: i am trying different combinations... 
[08:18] <_ion> seveas: I don't have madwifi hardware, so i can't test.
[08:18] <dholbach> good morning
[08:19] <fabbione> infinity: can you try a manual build with a console?
[08:19] <fabbione> i wonder if it's a tty issue
[08:20] <_ion> seveas: Another thing: is this patch needed? http://mail.gnome.org/archives/networkmanager-list/2006-February/msg00081.html
[08:21] <infinity> fabbione: I can in a while.  Though, if it's a TTY issue, the other buildds should have failed too.
[08:22] <fabbione> infinity: i know.. but the other buildds might have tty1 or so.. sparc doesn't
[08:32] <fabbione> infinity: E: Package espresso-keyboard-setup has no installation candidate
[08:32] <fabbione>  <- sparc
[08:33] <fabbione> oh i see
[08:33] <fabbione> it's generated from new console-data that's FTBFS on sparc
[08:35] <infinity> Ahh, so it is.
[08:38] <fabbione> this is embarassing...
[08:38] <fabbione> running a 350GB /usr/src out of space
[08:38] <pitti> Good morning
[08:39] <fabbione> hi pitti
[08:40] <_ion> 'ning
[08:41] <ajmitch> morning pitti 
[08:42] <infinity> fabbione: Yup, failed again, trying a manual build...
[08:44] <fabbione> infinity: ok
[08:46] <sivang> Seveas: pong
[08:46] <sivang> Morning everybody.
[08:46] <sivang> hey pitti 
[08:47] <infinity> fabbione: Same failure on a manual build...
[08:48] <fabbione> HMMMM
[08:48] <fabbione> that's kind of weird
[08:49] <fabbione> try disabling ccache?
[08:49] <kagou> hi
[08:49] <infinity> fabbione: Yeah, I can.  Though we've ruled out a broken cache, cause I was using a fresh one.
[08:50] <fabbione> i had ccache enabled...
[08:50] <fabbione> and disabled..
[08:51] <fabbione> i wonder if it could be something completely different.. like the host not being updated
[08:51] <infinity> ...?
[08:51] <infinity> LP buildds run a dist-upgrade before each build.
[08:51] <infinity> Or, you mean the base system could be affecting it in curious ways? :)
[08:51] <fabbione> probably...
[08:52] <fabbione> i am running a more recent and actually bugfree kernel...
[08:53] <infinity> Erm, no, the problem is much more obvious.
[08:53] <infinity> I'm wondering why you're not seeing it...
[08:53] <infinity> Compare the tail end of these lines:
[08:54] <infinity> -DPIC -I/usr/lib/ruby/1.8/powerpc-linux redland_wrap.c -c -o redland_wrap.so
[08:54] <infinity> -DPIC -I redland_wrap.c -c -o redland_wrap.so
[08:54] <infinity> Where's the ruby include on sparc?  :)
[09:02] <infinity> And there's the real problem.
[09:02] <infinity> fabbione: 
[09:02] <infinity> buildd@sejong:/build/buildd/redland-bindings-1.0.2.1$ ruby1.8 -rrbconfig
[09:02] <infinity> Illegal instruction
[09:02] <infinity> fabbione: ruby is failing when configure calls it to find out the config settings. :)
[09:02] <fabbione> sec...
[09:03] <netstar> Anyone noticed MANY panel applets won't load?
[09:03] <fabbione> is that suppose to give any output?
[09:03] <fabbione> infinity: ^^
[09:03] <fabbione> it's does  not die on me
[09:04] <infinity> fabbione: No, this should:
[09:04] <infinity> ruby1.8 -rrbconfig -e "puts Config::CONFIG['archdir'] "
[09:04] <fabbione> ruby1.8 -rrbconfig -e "puts Config::CONFIG['archdir'] "
[09:04] <fabbione> /usr/lib/ruby/1.8/sparc-linux
[09:04] <infinity> Fun.  What CPU is in that machine?
[09:04] <fabbione> cpu             : TI UltraSparc IIi (Sabre)
[09:04] <fabbione> it's not the IIIi like at the DC
[09:04] <infinity> This IIIi either hates ruby, or the kernel is seriously confused.
[09:05] <fabbione> i did already file an RT request for upgrading the kernrel on the buildd
[09:05] <fabbione> the best would be to try on faure
[09:05] <fabbione> it already has the latest kernel
[09:05] <fabbione> (or almost)
[09:07] <netstar> The panel or something it depends on ( I can't ascertain what) is causing panel applets to die on PPC.  Anythin I can test, anyone having the same problem?
[09:08] <infinity> fabbione: Well, if I knew that these machines could safely reboot remotely, I'd reboot them with the new kernel...
[09:08] <infinity> fabbione: I do all the other updates on them, but don't have the balls to reboot them. :)
[09:08] <netstar> There's nothing that jumps out to me that could be causing this fromt he last 24 hour's update
[09:09] <infinity> fabbione: I don't suppose you could reboot with a -16- series kernel and see if you get an Illegal insn there as well?
[09:09] <fabbione> infinity: they can reboot if you do a dist-upgrade, but there is an RT for them.
[09:09] <fabbione> infinity: they really need to have a new udev
[09:09] <fabbione> or network won't come up
[09:10] <fabbione> infinity: i am not even sure i have these images around anymore
[09:10] <infinity> fabbione: Well, they all have the latest dapper.  It's just the "reboot for the new kernel" step that hasn't happened... <shrug>
[09:10] <fabbione> infinity: you sure they are all superupdated?
[09:10] <infinity> Yes. :)
[09:10] <fabbione> infinity: just check the symlinks /boot
[09:10] <fabbione> and reboot only one of them
[09:10] <fabbione> they all have console/ALOM access
[09:11] <fabbione> in the worst Karl will have to mangle only one of them
[09:11] <fabbione> btw.. console-data with the fix is uploaded...
[09:11] <fabbione> espresso will be installable as soon as it builds
[09:11] <fabbione> infinity: the reboot of these machines takes quite a while
[09:11] <fabbione> about 2/3 minutes
[09:11] <infinity> Yeah, I'm used to real hardware.
[09:11] <fabbione> even longer sometimes
[09:11] <fabbione> ok
[09:12] <netstar> http://www.rafb.net/paste/results/c1CtgD69.html is the output I get
[09:14] <netstar> weird
[09:15] <infinity> fabbione: No such luck.
[09:15] <infinity> buildd@sejong:~$ ruby1.8 -rrbconfig -e "puts Config::CONFIG['archdir'] "
[09:15] <infinity> Illegal instruction
[09:15] <infinity> buildd@sejong:~$ uname -a
[09:15] <infinity> Linux sejong 2.6.15-18-sparc64 #1 Thu Mar 9 14:41:32 UTC 2006 sparc64 GNU/Linux
[09:15] <fabbione> infinity: one second.. please
[09:15] <fabbione> can we strace it?
[09:16] <infinity> Ideally, we should disassemble it, but gdb hung on me when I ran it.
[09:16] <infinity> Go gdb.
[09:16] <fabbione> use strace please
[09:16] <fabbione> i know gdb is borked
[09:16] <fabbione> it's in the endless TODO list
[09:16] <fabbione> make sure to kill -9 the gdb processes
[09:16] <fabbione> or they will stay there
[09:16] <infinity> Yeah, I noticed. :)
[09:17] <infinity> Anyhow, strace isn't terribly enlightening in the case of an Ill insn.
[09:17] <infinity> _sysctl({{CTL_KERN, KERN_VERSION, 0, 21ab1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, 2, 0xef8fba60, 30, (nil), 0}) = 0
[09:17] <infinity> getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
[09:17] <infinity> brk(0)                                  = 0x22000
[09:17] <infinity> brk(0x44000)                            = 0x44000
[09:17] <infinity> mmap(NULL, 245760, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7038e000
[09:17] <infinity> --- SIGILL (Illegal instruction) @ 0 (0) ---
[09:17] <infinity> +++ killed by SIGILL +++
[09:17] <fabbione> the next instruction is a break
[09:17] <fabbione> ok
[09:18] <fabbione> let me see if i can reproduce it on Niagara
[09:20] <fabbione> yeps...
[09:20] <fabbione> i can 
[09:20] <infinity> BTW, (other than this), I'm really impressed with the work that's gone into Sparc on Linux 2.6 recently.  Give DaveM some "mad props" from me.
[09:20] <infinity> These buildds are much more stable than the sparc/linux machines I used to run at work.
[09:20] <fabbione> ehhe
[09:21] <fabbione> that's because recently i managed to stress the kernel a bit more
[09:22] <MrFaber> hi all
[09:23] <MrFaber> I have problems with frequency scaling with current dapper kernel
[09:23] <MrFaber> It shows the correct frequency maximum and minimum but it didn't change from the maximum
[09:23] <MrFaber> A friend of mine has the same problem
[09:23] <fabbione> MrFaber: file a bug on malone, if there isn't one already
[09:24] <MrFaber> there are several
[09:24] <infinity> fabbione: Alright, I'm going to clean up and light up sejong again.  Poke me if you get ruby sorted, so we can retry its reverse deps.
[09:24] <MrFaber> according to frequency scaling
[09:24] <fabbione> infinity: i don't think it's a reverse-deps problem.. but i am going there slowly
[09:24] <fabbione> infinity: i still can't reproduce it locally
[09:25] <infinity> fabbione: No, I mean so I can retry the stuff that build-deps on it. ;)
[09:25] <infinity> fabbione: (Once it's fixed)
[09:25] <fabbione> infinity: ah sure
[09:27] <tritium> floe (ia64) doesn't like building tor (gs error building docs)
[09:27] <fabbione> MrFaber: so if there are several, they might get fixed. coming here to push, won't help
[09:27] <fabbione> MrFaber: or do you have a patch to fix them all?
[09:27] <MrFaber> fabbione, just wanted to ask
[09:28] <MrFaber> maybe they are already fixed
[09:28] <MrFaber> fabbione, Kanotix 2.14 kernel scales my cpu :)
[09:28] <infinity> tritium: I'm retrying the build now.  If it fails the same way again, can you file a bug on gs with a pointer to the build log?
[09:29] <tritium> infinity: okay.  It looks like it failed on a previous upload on March 9.
[09:29] <MrFaber> Then I have some other questions, if you disable splash screen I see some error messages, is this normal? If I mount e.g. a loop-aes device it shows me information messages with red stars but mounting works fine
[09:30] <infinity> tritium: Ahh, then it's probably a bona fide gs bug, yes.
[09:30] <infinity> tritium: Please file it, so our gs maintainer (iwj) will poke at it.
[09:30] <netstar> MrFaber: Yes it is normal (within reason)
[09:30] <MrFaber> netstar, ok thanks
[09:30] <tritium> infinity: will do.
[09:32] <infinity> Oh, for fuck's sake...
[09:33] <tritium> infinity: I'm going to get a few hours of sleep before work.  I'll take care of it in the morning.
[09:36] <fabbione> infinity: davem is on that ruby issue... but he will have to debug it tracing via kernel.. because gdb is useless
[09:37] <fabbione> infinity: i am ready to bet he will have a fix in less than 1 hour
[09:39] <Seveas> _ion, how's the nm/driver patching going?
[09:39] <pitti> Hi Seveas 
[09:39] <Seveas> hi
[09:40] <_ion> seveas: /lastlog -hilight
[09:40] <pitti> hi _ion 
[09:40] <_ion> Hi
[09:40] <pitti> infinity: can you please try a give-back for nautilus on amd64?
[09:41] <pitti> infinity: ... and sparc?
[09:41] <infinity> pitti: We don't build nautilus on those arches.
[09:41] <pitti> infinity: ...
[09:41] <infinity> :)
[09:41] <_ion> pitti: All the patches except for 20-linux-wlan-ng.patch should be ported now.
[09:41] <pitti> _ion: rock :)
[09:42] <pitti> _ion: I'll care for that one, the current patch is far from perfect anyway
[09:42] <infinity> pitti: Given-back.
[09:42] <Seveas> _ion, http://mail.gnome.org/archives/networkmanager-list/2006-February/msg00081.html should be covered with the patch collection from robert love I pointed too
[09:43] <pitti> _ion: did you talk with Scott about releasing this one? And is there an UVF exception already?
[09:43] <Seveas> _ion, but if you have updated packages for l-r-m and nm, I'll test
[09:44] <Burgundavia> -
[09:44] <Burgundavia> _ion: do you need testing on madwifi?
[09:45] <doko> pitti, Kamion: we maybe want to revert the dependency of language-support-en on openoffice.org-helpe-en-gb, it's +12mb for the CD's
[09:46] <pitti> doko, Kamion: would be fine for me; I already wanted to ask you about this (2x en help)
[09:46] <_ion> I haven't touched the l-r-m package yet, but it should be tested whether this works or not: http://johan.kiviniemi.name/tmp/madwifi-robertlove-danwilliams.patch
[09:46] <_ion> I or Pygi will build a patched l-r-m package in the near future.
[09:46] <infinity> _ion: What needs to be patched in LRM?
[09:47] <_ion> infinity: It will need to be patched with the diff from the URL.
[09:47] <_ion> infinity: Or at least so i've heard. ;-)
[09:47] <infinity> _ion: Erm, that patch is just for networkmanager..
[09:48] <_ion> http://johan.kiviniemi.name/tmp/madwifi-robertlove-danwilliams.patch
[09:48] <infinity> _ion: Hrm, I fear that patch may be against madwifi-ng...
[09:48] <infinity> _ion: Can you file a bug on LRM, and I'll chase it up later?
[09:49] <_ion> infinity: The original is, but that diff is against the current l-r-m source package.
[09:49] <infinity> _ion: And does it work?
[09:49] <_ion> infinity: That is yet to be tested. :-)
[09:49] <infinity> _ion: And, more to the point, not break anything else? :)
[09:51] <_ion> I really don't know much about the whole madwifi situation. I only saw two patches that allegedly fix the WPA support and modified them to apply against the madwifi-old tree. :-)
[09:51] <_ion> That diff hasn't been tested at all yet.
[09:51] <MrFaber> _ion, wpa is very strange under Linux
[09:51] <MrFaber> some version work, next version doesn't work of wpa_supplicant
[09:52] <MrFaber> at least for me :)
[09:52] <Seveas> _ion, if you have the patched version up - poke me and I'll test 
[09:52] <pitti> infinity: is it possible to build php5-sqlite with libsqlite3? (that worked fine with qt3)
[09:53] <Seveas> madwifi devs are not interested in supporting WEXT in the near future so you will need the collection of workarounds in NM
[09:53] <infinity> pitti: Probably? :)
[09:53] <pitti> infinity: however, I don't know whether the libs just have a different API, or different db format, too
[09:53] <_ion> seveas: Will do. :-)
[09:53] <ajmitch> pitti: totally different & incompatible DB format
[09:53] <infinity> pitti: The database formats aren't backward compatible (and sqlite3 has no support for reading sqlite0 databsases), that's my only concern.
[09:53] <pitti> hm
[09:53] <infinity> pitti: At least, AFAIK.
[09:53] <infinity> pitti: I was going to do a bit more research on it before I comitted.
[09:53] <pitti> so, all packages but php-sqlite use 3 now, but that doesn't help us much then, I guess...
[09:53] <ajmitch> infinity: yeah, I've run into it with f-spot
[09:54] <kagou> do we considere that under a dapper filesystem, ALL files must be encoded in utf-8. Or some files can be encoded in ISO8859-1 ?!
[09:54] <infinity> pitti: I can transition php to sqlite3 (and call it php5-sqlite3), and then build a php5-sqlite in universe that uses sqlite0, if we're concerned about upgrade paths.
[09:54] <pitti> if that isn't too much work?
[09:54] <infinity> kagou: There's no standardisation for text file encoding at all, except in some very rare cases.
[09:55] <infinity> pitti: Not really much effort, assuming it compiles cleanly and works.
[09:55] <infinity> pitti: I'll need to chase it up on Monday (I'm already several hours into my weekend) :)
[09:55] <_ion> The situation would be optimal if everything was encoded in UTF-8.
[09:56] <pitti> _ion: time will heal all wounds :)
[09:56] <kagou> Mithrandir, i'm talking of course of your answer in #35045
[09:56] <Seveas> pitti, and then they will replace utf-8
[09:56] <infinity> "They" already have replaced it.
[09:56] <infinity> (or extended it)
[09:56] <pitti> infinity: ?
[09:56] <infinity> Windows is UTF-16, n'est-ce pas?
[09:57] <pitti> infinity: there is sth. even more crackful^Wmodern than unicode?
[09:57] <infinity> No, still Unicode, just bigger! :)
[09:57] <pitti> infinity: oh, right, but that has always been there, hasn't it?
[09:57] <_ion> UTF-$n are just different encoding methods for Unicode.
[09:57] <pitti> there are even more encodings for unicode 
[09:57] <infinity> Yeah, UTF-8 and UTF-16 grew up together, I believe, not sure why we standardised on one, and Microsoft on the other.
[09:57] <pitti> infinity: becuase that's what they always do? :)
[09:58] <infinity> To be fair, this one might be our fault. :)
[09:58] <infinity> Windows has been UTF-16 internally for a long time.
[09:58] <_ion> UTF-8 is very good for networking, file contents and file names. Handling UTF-16 strings is faster codewise.
[09:58] <Treenaks> UTF-8 is ASCII compatible (it's identical in the 7-bit range)
[09:58] <pitti> _ion: how is it faster?
[09:58] <Treenaks> UTF-16 makes ALL characters 2 bytes long
[09:58] <Mithrandir> infinity: utf16 isn't backwards compatible in the way utf8 is (ascii) and it requires double the space for storage.
[09:58] <hunger> infinity: utf16 is basically the unicode standard.
[09:59] <Mithrandir> infinity: so utf8 is "better" than utf16.
[09:59] <pitti> Treenaks: how does utf16 handle characters above 0x10000 then?
[09:59] <hunger> infinity: Utf8 is a trick to shoehorn utf16 into 8 bit.
[09:59] <infinity> Mithrandir: Ahh, I didn't realise it lacked the ASCII backward compatibility.  That would explain why UNIX vendors prefer UTF-8.
[09:59] <hunger> pitti: Surrogate pairs:-)
[09:59] <_ion> pitti: It doesn't AFAIK. :-) For that you need UTF-32.
[09:59] <Treenaks> pitti: http://en.wikipedia.org/wiki/UTF-16
[09:59] <Treenaks> _ion: it does :)
[09:59] <pitti> _ion: well, unless you are a hard disk vendor, UTF-32 seems even to be a worse idea...
[09:59] <_ion> treenaks: Ok.
[10:00] <robtaylor> pitti: hey, Cardoe was on #dbus last night complaining we (upstream) weren't applying distro patches. Which out of the ubuntu patch set are we currently missing?
[10:00] <pitti> hi robtaylor 
[10:00] <hunger> pitti: There are ranges in the 16bit range that encode a couple of bits and must be followed by some other 16bit value that has the rest.
[10:00] <pitti> robtaylor: shall we go through them in pm? I'm not sure which of them have been applied
[10:00] <robtaylor> pitti: ok, cool
[10:01] <pitti> hunger: very muhc like utf-8 then ;)
[10:01] <hunger> pitti: Somewhat:-)
[10:01] <hunger> pitti: You should only need the stuff > 0xFFFF for really strange languages though, so it is a bit of a progress.
[10:01] <minghua> there is still UCS-2 and UCS-4 after all
[10:01] <Treenaks> minghua: UCS-2 == UTF-16
[10:01] <Treenaks> minghua: "UTF-16 is officially defined in Annex Q of ISO/IEC 10646-1. It is also described in The Unicode Standard version 3.0 and higher, as well as in the IETF's RFC 2781."
[10:02] <pitti> hunger: for my POV, everything > 0x7F is strange enough already :)
[10:02] <minghua> hunger: not really, the Chinese in Hong Kong uses characters > 0xFFFF
[10:02] <hunger> minghua: unicode defines which "number" corresponds to which letter.
[10:02] <Treenaks> pitti: trange? :P
[10:02] <pitti> Treenaks: :)
[10:03] <minghua> hunger: I think I understand the concept of codepoints
[10:03] <hunger> minghua: Yeap, but only for "strange" letters of that languages (or so the standard claims).
[10:03] <_ion> trange ndeed. 
[10:03] <hunger> minghua: utf* is a mapping of the "unicode numbers" into bitpatterns.
[10:03] <minghua> hunger: from what I heard they use those characters every day
[10:03] <hunger> minghua: I don't know... I just know the unicode standard:
[10:03] <pitti> robtaylor: did you get my /msg?
[10:04] <minghua> hunger: it's a mandarin/cantonese difference
[10:04] <hunger> minghua: And before 3.0 there were no chars defined > 0xFFFF.
[10:04] <hunger> minghua: Only after that those were added to cover some more obscure languages.
[10:04] <minghua> hunger: yeah, I know that story
[10:06] <minghua> Treenaks: from wikipedia: "The only difference between the two formats is that UTF-16 requires support of surrogates (explained below), whilst UCS-2 forbids such support and thus only encodes the BMP."
[10:06] <hunger> minghua: I do not know any east asian language (except maybe 50 of the less useful chinese chars that I picked up traveling through china:-)
[10:06] <Treenaks> minghua: so they're mostly compatible
[10:07] <minghua> Treenaks: so UTF-16 and UCS-2 are different, UCS-2 doesn't have chars > 0xFFFF, which is the reason we have UCS-4
[10:07] <Treenaks> minghua: yes, but UTF-16 is UCS-2 + a hack which allows characters > 0xFFFF
[10:07] <hunger> utf8 is shorter for latin-based languages, but longer for east asian languages.
[10:07] <minghua> hunger: not bad if you can pick up that many chars in such a short time
[10:07] <minghua> :-)
[10:08] <hunger> utf32 stays constant wrt. size but is 4times bigger for ASCII when writting english.
[10:09] <hunger> minghua: I was with a friend who studied chinese and asked him whenever I saw a char I could remember.
[10:09] <hunger> minghua: So I picked up a really strange cross-section of chars... like "old in the sense of made in dynasty XY":-)
[10:14] <minghua> hunger: strange indeed.  I am not so sure which chars you are talking about :-)
[10:15] <fabbione> infinity: ruby with the fix is pending upload..
[10:15] <fabbione> infinity: i told you less than one hour :)
[10:16] <MagnusR> p
[10:19] <hunger> minghua: Whatever looks vagualy recognizeable to a european hanging around in antiques stores and other touristy places.
[10:20] <mdke> mdz, ping?
[10:20] <doko> seb128, dholbach, jdub: are icons overwritten by some package?
[10:21] <dholbach> doko: hm?
[10:21] <doko> dholbach: I'm wondering, why OOo has different icons on i386 and amd64 ...
[10:22] <seb128> doko: it uses your theme first, and if the theme has no icon for what you ask fallback to what the theme specify (Tango for Human by example), then GNOME, then hicolor
[10:22] <seb128> doko: maybe you don't use the same icon theme
[10:23] <doko> seb128: ohh, right, now everything looks ugly, not just some icons :-/
[10:24] <seb128> what theme do you use?
[10:24] <doko> jdub: the folder icon for the menus looks really bad ... too much orange (install menu, open the Debian menu)
[10:24] <doko> seb128: Human now
[10:24] <Kamion> doko: ugh, yeah, 12MB on CDs is bad, I hadn't got round to noticing yet
[10:25] <Kamion> pitti: dropping -help-en-gb should be fine; no British English speaker will have a problem with American English help
[10:25] <pitti> hmm, is it just me, or has responsiveness during 100% I/O operations vastly deteriorated?
[10:25] <dholbach> hey mvo!
[10:26] <dborg> guten morgen!
[10:26] <pitti> Kamion: alright, will upload a new package now
[10:27] <seb128> hi dborg mvo
[10:27] <mvo> hello
[10:27] <seb128> mvo, pitti: how do one trigger the "restart required" icon?
[10:27] <mvo> pitti: I noticed the same
[10:27] <mvo> seb128: click on it
[10:27] <pitti> Kamion: hmm, do we want to keep l-support-en on the CD in the first place? We might leave it as it is, and just add a subset of the packages to desktop maybe (those which are required by OOo to work)
[10:28] <seb128> mvo: no, how do you get that icon without installing a package that requires a reboot ... like what file should be created? :)
[10:28] <pitti> seb128: /usr/share/update-notifier/notify-reboot-required
[10:28] <seb128> thank you pitti
[10:28] <pitti> seb128: just call it
[10:28] <seb128> that's an idea :)
[10:28] <Burgundavia> pitti: I have noticed the same issue, with regards to IO
[10:28] <pitti> Kamion: l-s-en currently has two help packages, and three l10n packages
[10:28] <seb128> that's for https://launchpad.net/distros/ubuntu/+source/gedit/+bug/33087
[10:28] <Ubugtu> malone bug 33087 in gedit "gedit crashes when restart after update is forced" [Normal,Confirmed]  
[10:28] <robtaylor> mvo: hey :), i'm just going through distro patches for dbus to commit upstream.. can you give me some history on http://people.ubuntu.com/~pitti/tmp/dbus-patches/patches/int64detection.diff ?
[10:29] <pitti> Kamion: l10n-en-{us,gb,za}
[10:29] <pitti> Kamion: not to mention tbird-locale-en-gb and two myspell packages
[10:29] <Kamion> pitti: I think language-support-en is a good place to put "extra English stuff we want on the CD" at the moment, but if you'd rather that be desktop, I guess I don't mind; the downside of using desktop is that people who don't care about English can't conveniently uninstall it
[10:29] <mvo> robtaylor: without the patch IIRC the qt bindings didn't worked (compile error with incorrect types) on amd64
[10:30] <Kamion> the multiple oo.o l10n packages are reasonably small now - it's just the help that's huge
[10:30] <pitti> Kamion: true
[10:30] <robtaylor> mvo: but what's the reasoning behind it?
[10:30] <pitti> Kamion: ok, then I'll throw out -en-gb help for now; it's trivial to change anyway
[10:31] <Kamion> ok, thanks
[10:31] <Kamion> doko: how much in the way of common files is there between -help-en-us and -help-en-gb?
[10:32] <robtaylor> mvo: and what was the build error?
[10:32] <infinity> fabbione: I'm just glad it wasn't a toolchain bug.
[10:32] <doko> Kamion: no common files, only thing I can say, there are about 5000 different message strings in the help (out of 40000)
[10:32] <doko> maybe most s/z/s/g?
[10:33] <Kamion> pitti: mozilla-firefox-locale-xh-za seems to be disappearing (not built from source); is there a replacement that language-support-xh could use?
[10:33] <pitti> Kamion: no really, nobody updated the xh translations
[10:33] <Kamion> that's more different strings than I'd expected; OK
[10:33] <fabbione> infinity: no, it's ruby crap. it was working on my machine by mistake...
[10:33] <fabbione> infinity: i am just doing an extra test/build to be sure..
[10:34] <Kamion> pitti: well, either language-support-xh drops that dependency or it becomes uninstallable, then :-(
[10:34] <pitti> Kamion: hm, I should provide an empty dummy package for transition
[10:34] <Kamion> transition to what? :)
[10:34] <pitti> Kamion: yes, I'll drop the dependency in any case
[10:34] <Kamion> the old package should be uninstallable now, so I think it should be automatically removed
[10:34] <pitti> Kamion: oh, right, it shuold uninstall itself in a breezy->dapper upgrade
[10:36] <infinity> dholbach: gnumeric needs the same fix you just made for goffice.
[10:36] <pitti> Kamion: both uploaded, thanks
[10:37] <dholbach> infinity: righto, merci
[10:37] <doko> seb128: #23049 ping
[10:37] <robtaylor> pitti: i think the applied fix for dbus-qdbusmarshall-amd64.patch also removes the need for int64detection.diff
[10:38] <pitti> robtaylor: ok; it's easy enough to check :)
[10:38] <robtaylor> heh :)
[10:38] <Kamion> pitti: did you manage to get far enough through any espresso installs on powerpc to find out if yaboot configuration works?
[10:38] <seb128> bug #23049
[10:38] <Ubugtu> malone bug 23049 in openoffice.org "Printer properties: no paper orientation option" [Major,Confirmed]  http://launchpad.net/bugs/23049
[10:38] <robtaylor> gotta love ubuntu buildd
[10:38] <pitti> Kamion: no, it always crashes at the keyboard selection, I filed a bug about it
[10:39] <seb128> doko: what about it?
[10:39] <pitti> Kamion: it seems to be independent from the language setting :(
[10:39] <pitti> Kamion: I didn't try the latest CDs though, just the one from about two days ago
[10:39] <infinity> robtaylor: ?
[10:39] <pitti> robtaylor: I'm building on my own machine :)
[10:40] <robtaylor> pitti: ah, cool. CVS, right?
[10:40] <doko> seb128: can I turn off the options off again?
[10:40] <pitti> robtaylor: oh, you mean the upstream fix should cure that? well, I just meant the current ubuntu package; anyway, that's something we can sort out in dapper+1, when upgrading
[10:40] <seb128> doko: why?
[10:40] <seb128> doko: "All seems to work perfectly. This bug can be marked as fixed for me. Thank you :-)"
[10:41] <seb128> doko: what is your issue with something that "work perfectly"?
[10:41] <robtaylor> pitti: yeah, i think that http://people.ubuntu.com/~pitti/tmp/dbus-patches/patches/int64detection.diff is very broken
[10:41] <doko> seb128: "seems" is not enough. did you _check_ this with different page orientation in the page formats?
[10:41] <fabbione> Kamion: hey dude.. i am perfectly fine with whatever change you did in partman-auto...
[10:41] <seb128> doko: ploum did and commented
[10:41] <robtaylor> pitti: its just fixing for a problem in http://people.ubuntu.com/~pitti/tmp/dbus-patches/patches/dbus-qdbusmarshall-amd64.patch, and breaking abi :/
[10:42] <seb128> doko: he was the guy who complained about it
[10:42] <fabbione> Kamion: btw.. i also got espresso running on sparc :) it exits at the keyboard selector, but i will get there :)
[10:42] <seb128> doko: why of why want you to put the bug back if nobody complain and some people commented it works for him?
[10:42] <doko> seb128: so he only checks about the things he's interested in
[10:42] <pitti> robtaylor: ok, can you point me to the better fix for qdbusmarshall?
[10:42] <seb128> doko: that's better than having people not testing anything
[10:42] <pitti> robtaylor: then I can throw away the two ubutu patches and use upstream's instead
[10:43] <seb128> doko: you can't blame an user to have interest to some stuff only and not want to debug all openoffice.org for you
[10:43] <Kamion> fabbione: was just a small logic tweak
[10:43] <Kamion> pitti: hmph, ok, I wish I could boot CDs on my powerbook at the moment
[10:43] <fabbione> Kamion: yup.. i am always fine with your changes..
[10:43] <fabbione> Kamion: you so much don't need to explain to me :)
[10:43] <robtaylor> pitti: hmm, hand on a mo, i'm just checking over with qt maint
[10:44] <Kamion> I imagine your keyboard selector problem is the same as pitti's, basically
[10:44] <seb128> (s/of/oh)
[10:44] <seb128> doko: dunno why he used "seems", he tried and it works fine for him
[10:45] <doko> seb128: no, the behaviour is broken upstream. I'm not in favour of breaking something for a "nice to have" thing
[10:45] <doko> seb128: you did agree on testing this ...
[10:45] <seb128> doko: I got ploum to test it, I've no working printer
[10:45] <robtaylor> pitti: it seems to be correct in 0.61
[10:45] <fabbione> Kamion:  i didn't check with pitti, but i have no rush to get espresso working.. i need to get X autoconfig going first
[10:46] <seb128> doko: we tried during UI sprint on fedora or suse (not sure know) and they had the option too
[10:46] <seb128> s/had/have
[10:46] <robtaylor> mvo, pitti: we still can't make sense of int64detection.diff
[10:46] <seb128> doko: k, I'll not bother again for openoffice and users wanting to get it better, break it if you want too
[10:46] <mvo> robtaylor: have you tried building it on a amd64 without the patch?
[10:47] <robtaylor> mvo: qt maint has, says it works
[10:47] <seb128> doko: remove that option again without reason, ploum will complain and search for an openoffice1 package to install and you will be happy
[10:47] <robtaylor> (0.61 this is)
[10:47] <doko> seb128: looking at the sources, suse doesn't have this option.
[10:47] <robtaylor> mvo: that patch breaks abi on amd64
[10:47] <Kamion> fabbione: I suspect I don't have time to do espresso-silo anyway ...
[10:47] <mvo> robtaylor: it's possible that it is fix now, then we can drop the patch
[10:47] <seb128> doko: so that's FC5 :)
[10:48] <fabbione> Kamion: i might be able to help you for that....
[10:48] <fabbione> Kamion: silo doesn't ask anything.. just does..
[10:48] <robtaylor> pitti: ah well, i think we can definitly conclude we can drop both of those for 0.61+ :) our work here is done ;)
[10:48] <Kamion> espresso-grub and espresso-yaboot should be reasonable examples there
[10:48] <fabbione> anyway don't worry about it
[10:48] <fabbione> exactly
[10:49] <mvo> robtaylor: which one? the int64detection.diff? or the other one?
[10:49] <fabbione> it's more important for me to get X autoconfig going properly
[10:49] <fabbione> but now i have the tools to do so
[10:50] <robtaylor> mvo: int64detection.diff breaks abi
[10:50] <robtaylor> mvo: i think
[10:50] <mvo> robtaylor: why? it shouldn't matter
[10:51] <pitti> Kamion: I just noticed that I forgot to remove python-gdchart from the server seed; this was the only place which still refered to it (which prevented it to appear in anastacia, I guess); is there an associated metapacakage that I need to update?
[10:51] <Kamion> pitti: no
[10:52] <pitti> ah, so anastacia looks directly at the seeds for server?
[10:52] <Kamion> yeah
[10:52] <Kamion> well, I mean, it always looks directly at the seeds
[10:52] <Kamion> but sometimes there are metapackages as well
[10:52] <pitti> aah, ok
[10:52] <robtaylor> mvo: it means that longlong gets used instead of long for int64 in all the interfaces, does that not change abi?
[10:52] <Kamion> looks like it should drop out of main in the next hour, then
[10:52] <pitti> Kamion: thank you
[10:56] <infinity> pitti: I'm hand-picking some builds to get gnutls11 completely gone... Should be ready to go by Monday.
[10:56] <pitti> Kamion: is there a possiblity that you will need directfb in main for cdebconf or so?
[10:56] <pitti> infinity: cool
[10:57] <pitti> infinity: does that require some no-change uploads for evo? i. e. were the current packages built against 11, or were they just not yet built at all?
[10:58] <pitti> Kamion: we seeded libdirectfb-dev, which does not have rdepends, and we could get rid of directfb and libmpeg3 (mentioned in duplicated packages) if we don't need it for the installer
[10:58] <mvo> robtaylor: I don't think so, sizeof(long) == sizeof(long long) on amd64 (8)
[10:58] <pitti> mvo: it might break ABI on other architectures
[10:59] <robtaylor> pitti: very good point
[10:59] <pitti> mvo: i. e. i386 long is 4 byte, long long is 8
[10:59] <infinity> pitti: Looks like only two packages (evo-exchange, and control-centre) will require rebuild uploads (for ia64), but I'll know for sure when I'm done getting hppa caught up on those rdeps.
[10:59] <robtaylor> pitti: not in that case, as its comparing against 8
[10:59] <pitti> robtaylor: OTOH, using 'long' etc. to define fixed-size datatypes is a very bad idea in the first place
[11:00] <pitti> robtaylor: you should probably prefer stdint.h, with uint64_t, and so on
[11:00] <robtaylor> pitti: its a configure check on the actual size
[11:00] <pitti> ah, I see
[11:00] <pitti> but still, stdint.h is easier and less prone to such bugs, isn't it?
[11:00] <mvo> robtaylor, pitti: I don't think so, the patch disables "long" as a possible 64 bit datatype, that shouldn't be a problem in any way as long long is still tested. don't get me wrong, the patch is a hack, but I don't think it breaks the abi
[11:00] <robtaylor> pitti: not necesarilly there on all dbus targets
[11:00] <robtaylor> mvo: yep, i think your right
[11:01] <mvo> robtaylor: so I would be more than happy if it could be removed by a better patch :)
[11:01] <robtaylor> mvo: i just get slightly scared what subtleites lie in eabis ;)
[11:01] <mvo> robtaylor: don't talk to me about c++ abis ;) 
[11:01] <robtaylor> mvo: well it's certainly the wrong fix, so I'll just make sure thiago checks on amd64 before release
[11:01] <robtaylor> mvo: exactly ;)
[11:02] <pitti> robtaylor: uh, there are dbus targets which don't have stdint.h? that's ISO C99
[11:02] <mvo> robtaylor: I'm happy to re-check it again on monday when I'm back at my amd64 (please remind me again if I forget it)
[11:04] <seb128> Mithrandir: is your evolution shell patch supposing to make it using the running instance instead of opening a new window? If that's the case seem it doens't work for me
[11:04] <mvo> robtaylor: thanks for checking/forwarding our patches, that is a great help
[11:04] <robtaylor> pitti: i have to admit, i dont know the full reasoning ;)
[11:04] <robtaylor> mvo: np, thanks for the help..
[11:05] <Mithrandir> seb128: no.  It's supposed to make evolution 'calendar:///?startdate=20050601' (or something similar) open one window, not two.
[11:06] <seb128> Mithrandir: it was opening 2 windows before?
[11:06] <Mithrandir> seb128: yes.
[11:06] <seb128> hum
[11:07] <Mithrandir> seb128: it doesn't reuse the existing instance.  I could probably investigate how to do so, but it's not the primary goal of the patch.
[11:07] <Mithrandir> seb128: it's basically so double-clicking on a date in the clock applet will give you one window (like today), not two.
[11:11] <seb128> Mithrandir: hum, it opens only one without the patch
[11:11] <seb128> dholbach: if you do evolution 'calendar:///?startdate=20050601', how many windows are open?
[11:12] <Mithrandir> seb128: that's really weird..
[11:12] <dholbach> two... an evolution window (with mail and stuff) and one with the calendar
[11:12] <mdke> if someone with main access has a spare 2 minutes, could they have a look at bug #30694, there is a patch on there for the fix. Thanks!
[11:12] <Ubugtu> malone bug 30694 in xmms "unfriendly menu entry for XMMS" [Normal,Unconfirmed]  http://launchpad.net/bugs/30694
[11:12] <seb128> dholbach: thank you
[11:13] <seb128> Mithrandir: it ws just to try, but the patch is simple enough, I'll use it even if I don't get the issue :)
[11:13] <dholbach> seb128: de rien
[11:13] <Mithrandir> seb128: do you get just one window if you close all the existing evolution windows too?
[11:14] <seb128> Mithrandir: no, in that case I got 2
[11:14] <seb128> but I've a mailer open usually, in which case it opens a new one with the calendar
[11:14] <Mithrandir> seb128: yes, that's the case I'm trying to address.  One could argue whether doing evolution $uri should reuse the existing shell or not, but it's not what my patch touches.  It's just the initial startup.
[11:15] <seb128> verified, it fixes the issue
[11:16] <Mithrandir> excellent, and sorry for poor description of the problem in my bug report.
[11:16] <seb128> np, thank you for the patch :)
[11:16] <Mithrandir> I've found getting stuff fixed is _much_ faster if you provide a patch, so I try to do that.
[11:16] <Mithrandir> even for trivial problems like this one.
[11:16] <seb128> that's for sure
[11:17] <seb128> I know we have a ton of small bug like that
[11:17] <seb128> so even if the patch take 15min to do, we usually tend to ignore a lot of them
[11:17] <Mithrandir> it'd be nice if we had a month to sit down and work out small patches for them.  I bet 90% of them will have patches that are less than twenty lines.
[11:17] <seb128> but if that's just a matter to try a patch and push it that's easier
[11:17] <Mithrandir> yeah, it took me an hour or two, but I don't know the evolution model and didn't have it in my ccache.
[11:18] <Mithrandir> mhm
[11:18] <seb128> not to mention that it feel a bit harsh to ignore a patch because somebody put work to it, so I try to make sure patches are used :)
[11:21] <seb128> Mithrandir: https://launchpad.net/distros/ubuntu/+source/xkeyboard-config/+bug/21595 ... look at the list of people subscribed and the number of dups and comments for it
[11:21] <Ubugtu> malone bug 21595 in xkeyboard-config "alts_toggle breaks instead of overriding ralt -> l3" [Major,Unconfirmed]  
[11:22] <seb128> Mithrandir: just to give you some motivation for tha xkeyboard-config 0.8 update :) You will win some extra cool points if you manage to get it done :)
[11:22] <Mithrandir> seb128: that's like half the world. :-)
[11:22] <seb128> yeah
[11:27] <fabbione> Kamion: grub-installer/espresso seems really trivial..
[11:27] <fabbione> Kamion: i think i can do silo easily
[11:32] <viviersf> fabbione, whats up with grub-installer ?
[11:33] <fabbione> viviersf: ??
[11:34] <mdz> seb128: why do we still get so many dupes of #21595?  did the backported fix for breezy not work?
[11:34] <Kamion> pitti: not for dapper; perhaps dapper+1
[11:35] <Kamion> viviersf: nothing
[11:35] <seb128> mdz: I don't know if the breezy-update has been done, accepted and is working for one thing
[11:35] <seb128> mdz: for an another thing the dapper package is still bugged
[11:36] <seb128> mdz: I don't know xkb stuff good enough to point a trivial fix, what I know is that I'm running xkeyboard-config 0.8 for 2 days now and it fixes the issue
[11:37] <pitti> Kamion: ok, so you wouldn't mind if I unseeded it?
[11:38] <mdz> seb128: xkeyboard-config | 0.6-5breezy1 | http://security.ubuntu.com breezy-updates/main Sources
[11:38] <mdz> it went in ages ago
[11:38] <Kamion> pitti: not at all
[11:39] <seb128> mdz: maybe daniels screwed on that version doesn't fix it so
[11:41] <pitti> hey jdub
[11:41] <pitti> I *knew* that someone would jump that :)
[11:41] <jdub> ;)
[11:41] <ogra> :)
[11:42] <_ion> Hehe.
[11:42] <Kamion> pitti: python-gdchart, libgdchart-gd1, libgd evicted from main
[11:42] <pitti> \o/
[11:42] <_ion> Sigh, i can't get sleep.
[11:43] <jdub> Kamion: (what are your thoughts about pushing our python love out of the desktop seed and into a python seed, and using an 'ubuntu-python' metapackage or something?)
[11:43] <seb128> mdz: is "breezy-updates" configured by default? there is also the possibility that many people don't use -updates but just -security
[11:43] <mdz> seb128: yes it is
[11:44] <pitti> jdub++
[11:44] <pitti> hey sabdfl
[11:44] <mdz> seb128: it looks like maybe the reports are mostly dapper though
[11:44] <sabdfl> hey hey
[11:44] <seb128> mdz: yeah, atm that's the case
[11:44] <_ion> Hi
[11:44] <seb128> hi sabdfl
[11:44] <ogra> pitti, is thhere a chance to install language packs without firefox-locale packages ? 
[11:44] <mdz> seb128: so we may have the option of bringing forward that fix rather than 0.8
[11:44] <sabdfl> seb128: you beating back the flood?
[11:44] <pitti> ogra: you mean language-support-*? no
[11:44] <ogra> gah ... k
[11:45] <pitti> ogra: if you only want specific packages, you can install them :)
[11:45] <seb128> sabdfl: that's right, we will defeat the bug backlog today :)
[11:45] <ogra> i was pondering to switch edubuntu to epiphany to gain more CD space ... but if the langpacks need to persist on the CD thats shallow
[11:46] <ogra> pitti, no, th elanguage selector will need the full langpacks
[11:46] <pitti> ogra: no
[11:46] <ogra> no ? 
[11:46] <ogra> oh
[11:46] <pitti> ogra: language-pack-* doesn't depend on ffox
[11:46] <pitti> ogra: language-support-* does, but it's not on the CD anyway
[11:46] <ogra> ah
[11:47] <ogra> then i'll do some tests for the next dailies over the weekend ... i bet it saves a lot
[11:47] <seb128> mdz: diff between 0.6 package and 0.8 is quite short and there is a bunch of new keymaps that would be nice for the l10n goal ... I would recommend using 0.8
[11:47] <ogra> and will make seb128 happy :)
[11:47] <seb128> mdz: FC5 is using it, and Debian has it packaged already too
[11:49] <mdz> seb128: have you already packaged it or are you testing it some other way?
[11:49] <seb128> mdz: I made a "stock upstream" package, ie: just copied the debian/ dir and rebuilt it and I'm running that
[11:50] <seb128> there is a bit of .diff.gz to look at for a proper update, Mithrandir is supposed to do that
[11:50] <seb128> Mithrandir: have you already looked on it?
[11:51] <seb128> though the .diff.gz is probably mostly CVS fixes than daniels backported to 0.6
[11:51] <Mithrandir> seb128: I started looking at it yesterday, but didn't make it before end-of-day.
[11:52] <pitti> mdz: do we consider GFDL suitable for main? we seeded autoconf-doc, but autoconf-nonfree (its source) is in universe right now
[11:52] <Mithrandir> pitti: we do, yes.
[11:53] <pitti> ok, so we can promote it, I guess
[11:54] <fabbione> pitti: do you think you can manage to take a look at git-core and see how bad would it be for main inclusion?
[11:54] <fabbione> pitti: it has all Depends/B-D in main afaik
[11:55] <fabbione> i am pretty sure it does.. just an extra eye would be helpful
[11:55] <pitti> fabbione: if you think it's a good idea to support it for 3 years?
[11:55] <fabbione> it's quite stable now
[11:55] <pitti> i. e. I don't really see the benefit, but that might be just me
[11:55] <fabbione> so yes.. considering it's our RCS for the kernel
[11:55] <pitti> but I can certainly take a look at it
[11:55] <fabbione> that would be lovely
[11:56] <fabbione> pitti: quite a bunch of users asked for a linux-kernel-devel meta package
[11:56] <fabbione> that would include git-core
[11:56] <fabbione> and it's only bit outside main atm
[11:56] <pitti> ok
[11:56] <fabbione> (the metapackage is not in the archive yet, but will be soon)
[11:57] <fabbione> thanks a lot my german friend
[11:57] <pitti> ok, I need to write some reports anyway now to clean up anastacia
[11:57] <fabbione> eheh
[12:01] <doko> seb128: please could you check #25998?
[12:01] <pitti> seb128: gst-plugins-ugly0.10 - what exactly is ugly about it? it doesn't really sound suitable for main :)
[12:02] <mdz> pitti: yes, we do
[12:02] <seb128> bug #25998
[12:02] <Ubugtu> malone bug 25998 in openoffice.org2-amd64 openoffice.org2 "French accents not working properly in OOo2" [Normal,Needs info]  http://launchpad.net/bugs/25998
[12:02] <seb128> pitti: ugly licence, patents, etc
[12:02] <dholbach> pitti: http://webcvs.freedesktop.org/gstreamer/gst-plugins-ugly/README?rev=1.12&view=markup
[12:02] <pitti>  This packages contains plugins from the "ugly" set, a set of
[12:02] <pitti>  good-quality plug-ins that might pose distribution problems.
[12:03] <seb128> pitti: mp3, mpeg, those sort of stuff
[12:03] <pitti> seb128: so we don't want it in main, right? because it's explicitly seeded right nwo
[12:03] <pitti> s/nwo/now/
[12:03] <seb128> pitti: it is?
[12:03] <pitti> o gst-plugins-ugly0.10: gstreamer0.10-plugins-ugly gstreamer0.10-plugins-ugly-dbg
[12:03] <pitti>    [Reverse-Depends: Dapper supported seed
[12:03] <Kamion> jdub: python seed> I don't mind, but you get to fight it out with sabdfl :-)
[12:04] <seb128> pitti: supported: * gstreamer0.10-plugins-ugly-dbg
[12:04] <pitti> seb128: ah, the -dbg package is seeded
[12:04] <sabdfl> i'm ready
[12:04] <pitti> seb128: ok, this time you snapped me :)
[12:04] <seb128> pitti: I've been optimistic when refreshing the -dbg list it looks like :p
[12:04] <pitti> seb128: I unseed it, ok?
[12:04] <seb128> sure
[12:04] <seb128> thanky ou
[12:04] <seb128> sorry for the mistake
[12:04] <pitti> no problem
[12:05] <Kamion> damnit, why do all emulators suck
[12:05] <seb128> pitti: upstream creating -ugly to make easy for distribution to separate what to ship or not :)
[12:05] <seb128> pitti: so -good is for main and -ugly for universe
[12:05] <jdub> Kamion: it's been rejected in the past, or you don't think it'll score highly on the love chart?
[12:05] <pitti> right, that's what I like about the current packaging
[12:08] <Seveas> rraphink, your r seems to be stuck ;)
[12:08] <Kamion> jdub: python-* in the desktop seed is owned by Mark
[12:08] <rraphink> lol
[12:08] <Kamion> jdub: I don't mind, but whether I mind does not matter
[12:11] <pitti> Kamion: pootle can be removed from the archive, as well as linux-source-2.6.12 (already in universe, and older than in breezy-security)
[12:11] <pitti> Kamion: (pootle was renamed to translate-toolkit)
[12:15] <mdz> Kamion: what's your current preference for grouping installer bugs?  subscribing ubuntu-installer, subscribing you, assignment?
[12:16] <mvo> dholbach: can you have a look at #26308 (arabic problem)
[12:17] <infinity> Does dholbach read arabic?
[12:17] <Kamion> mdz: either subscribing ubuntu-installer or subscribing me
[12:18] <Kamion> subscribing ubuntu-installer is probably better going forward
[12:18] <dholbach> bug 26308
[12:18] <Ubugtu> malone bug 26308 in openoffice.org "Ooo2 breaks arabic ligature on entering diacritic" [Normal,Needs info]  http://launchpad.net/bugs/26308
[12:18] <dholbach> mvo: that looks broken
[12:19] <dholbach> mvo: it should be joined up as in gedit :/
[12:20] <mvo> dholbach: join #ubuntu-l10n
[12:21] <Mithrandir> pitti: how does one get rid of the really annoying "partition $foo is N% full"?
[12:21] <pitti> Mithrandir: free some space :)
[12:21] <pitti> Mithrandir: seriously, you only get it now for system partitions which are > 95% full
[12:21] <pitti> Mithrandir: is that the case for you?
[12:21] <Mithrandir> pitti: seriously, it's really annoying.
[12:21] <Mithrandir> and there's no obvious way to get rid of it.
[12:22] <pitti> do you get it for a partition that shouldn't be watched?
[12:22] <Mithrandir> I get it for /tmp
[12:22] <pitti> Mithrandir: unfortunately g-v-m upstream doesn't provide a means to disable it per-partition
[12:23] <pitti> bug 33967
[12:23] <Ubugtu> malone bug 33967 in gnome-volume-manager "A way to disable low disk space warnings" [Normal,Unconfirmed]  http://launchpad.net/bugs/33967
[12:23] <Mithrandir> pitti: ok.  It's also a problem that there's no obvious way to know what makes those messages pop up.
[12:23] <infinity> That bug title is missing a verb...
[12:24] <pitti> Mithrandir: erm, that disables *all* notifications
[12:24] <Mithrandir> pitti: yes, and?  They're generally just really, really annoying.
[12:24] <pitti> heh :)
[12:24] <pitti> Mithrandir: I guess upstream added this notification after all the bugs which complain about your system acting strange and breaking if your disk is full
[12:24] <Mithrandir> we're getting into the windows popup syndrome.  Way too much which pops up on the screen.
[12:24] <pitti> we have lots of these bug reports ourselves
[12:25] <pitti> Mithrandir: if we can find sb who speaks gtk/gconf, we could add it ourselves
[12:25] <tseng> my favorite is 'i imported 42334 into f-spot, now my disk is full and everything crashes'
[12:25] <Mithrandir> pitti: sure, but I know how to diagnose bugs and would really like my system to not go "you only have 500MB left in /tmp, it's VERY URGENT to free some space".
[12:25] <tseng> filed against f-spot
[12:26] <Mithrandir> pitti: it's g-v-m?
[12:26] <pitti> Mithrandir: yes
[12:26] <Mithrandir> pitti: hmm, I'll see if I can find time to fix it, then.
[12:26] <pitti> Mithrandir: ideally, the bubble would contain an option 'do not warn me again for this drive' 
[12:26] <pitti> s/drive/partition/
[12:27] <Mithrandir> pitti: ideally, notification-daemon would have a filter so you could say "please don't show messages from those services" possibly with a bit more filtering.
[12:27] <pitti> Mithrandir: too complicated for users
[12:27] <infinity> Not too complicated for a gconf key, but certainly too complex for a GUI configurable thing.
[12:28] <Mithrandir> pitti: the current scheme is too bloody complicated for _me_. :-)
[12:33] <doko> infinity: how is thunderbird supposed to handle mail attachments (OOo/Send document as email calls mozilla-thunderbird attachment=file:///tmp/foo.odt , but the send-mail window pops up without the attachment
[12:34] <Kamion> pitti: all done
[12:37] <infinity> doko: I'm not sure if it *can* handle attachments from the command line...
[12:41] <doko> infinity: it did work until some days ago ...
[12:41] <infinity> ...
[12:41] <infinity> Days?
[12:41] <infinity> Nothing's changed in tbird (certainly not in that area) since the 1.5 upgrade.
[12:42] <infinity> However, this looks suspicious:
[12:42] <infinity> https://bugzilla.mozilla.org/show_bug.cgi?id=316177
[12:42] <Ubugtu> mozilla bug 316177 in General "command-line options for "-compose" broken" [Major,Verified: fixed]  
[12:43] <infinity> doko: Looks like I should apply that patch. :)
[12:43] <infinity> doko: Will do before the next upload.
[12:44] <doko> infinity: thanks!
[12:50] <Mithrandir> mdz: ok to upload xkeyboard-config 0.8?  It works for seb and for me.
[12:54] <Kamion> pitti: demoted directfb and a slew of dependencies
[12:54] <pitti> great, thanks; I also saw your wiki changes for the promotions
[12:54] <pitti> Kamion: libmpeg3 kills another duplicated-packages item :)
[12:54] <Kamion> libnet-perl doesn't seem to be in anastacia
[12:54] <Kamion> so I left it alone
[12:55] <pitti> hm, it was the day before yesterday
[12:55] <pitti> but so much the better
[12:55] <Kamion> dunno what's up there, I didn't investigate
[12:55] <Kamion> I don't understand though, liburi-perl is in main, libnet-perl in universe, and liburi-perl Depends: libnet-perl
[12:56] <pitti> Kamion: ah, liburi-perl wanted it
[12:56] <Kamion> oh, perl-modules Provides: libnet-perl
[12:57] <Kamion> since 2002
[12:57] <Kamion> so I've got no idea why it showed up in anastacia briefly. Whatever. Ignoring. :)
[01:01] <pitti> infinity: https://wiki.ubuntu.com/DapperDuplicatedPackages TODO-list looks pretty good now :)
[01:03] <infinity> pitti: GTK1.2 still isn't gone?
[01:03] <pitti> infinity: xmms :/
[01:04] <infinity> Bah.  Make an executive decision and demote it.
[01:04] <pitti> I so much would love to get rid of it
[01:04] <infinity> I use it daily, and I don't care if it's in main.
[01:04] <infinity> (And when's the last time you did a security release for it?... Never, right?)
[01:04] <_ion> Xmms is teh suxor. ;-)
[01:04] <pitti> and evms-gui?
[01:04] <pitti> infinity: never
[01:04] <infinity> I'm sure it MUST have security holes, given that it's a pretty sketchy network client and server (creepy), but no one's bothered to find and patch any.
[01:04] <infinity> So like they're going to start now?
[01:05] <infinity> evms-gui is, from what I've been told, worthless, but perhaps a poll of more than just "me and my buddies" could be taken.
[01:05] <pitti> "Excuse me, I have a package to demote"
[01:05] <_ion> In Soviet Russia, packages demote _you_!
[01:06] <pitti> infinity: we still have evms-cli, which fits the GettingRidOfTheDesktop spec :-P
[01:06] <pitti> seb128: you can certainly port evms-gui to gtk2, right? shouldn't take you more than 5 minutes :)
[01:07] <pitti> oh, wait, /me knows the Debian maintainer pretty well
[01:07] <infinity> pitti: The rest of the page looks pretty darn good.
[01:08] <Mithrandir> pitti: there exists a patch for evms
[01:08] <infinity> pitti: As for evms, I may be a bit of an elitist here, but I can't imagine that many people are using evms who A) don't know the CLI well, and B) would prefer a GUI.
[01:08] <_ion> I agree.
[01:09] <pitti> infinity: uninstalling it is always one of the first things I do ...
[01:09] <seb128> desktop: * irssi-text
[01:09] <seb128> that should be changed forrssi" right?
[01:09] <seb128> that should be changed for' irssi" right?
[01:09] <Mithrandir> infinity: I tend to use the curses interface, but that's because the GTK interface is GTK 1. :-P
[01:11] <infinity> seb128: Yes.
[01:11] <Mithrandir> pitti: https://sourceforge.net/tracker/?func=detail&atid=383344&aid=1429537&group_id=25076
[01:11] <seb128> infinity: k, updating desktop so
[01:12] <infinity> seb128: You may want to keep irssi-text in supported, though, for smooth upgrades.
[01:12] <infinity> seb128: I don't recall when the name change happened.
[01:13] <infinity> seb128: Yeah, the name change is from breezy->dapper, so we probably want to keep the transitional package in supported.
[01:13] <infinity> seb128: For people who don't have universe in their sources.list (whoever these theoretical people are)
[01:13] <seb128> infinity: that's useful because Provides is not version, right?
[01:14] <seb128> versionned
[01:14] <infinity> seb128: Right.
[01:14] <infinity> A provides won't auto-upgrade a package.
[01:14] <infinity> Some day, that really should be fixed....
[01:17] <infinity> seb128: Do you need to upload evolution-exchange for any bugfixes, by any chance? :)
[01:17] <infinity> seb128: (Cause the next upload will build against gnutls12 on ia64, and clear up one more blocker to dropping gnutls11)
[01:17] <tepsipakki> does somebody know how LTSP scales, what is the limiting factor with the number of clients?
[01:17] <infinity> seb128: If not, I can do a no-change upload.
[01:17] <Mithrandir> tepsipakki: RAM, usually.
[01:18] <seb128> infinity: not really, go for the no-change :)
[01:18] <infinity> seb128: Same question for control-center
[01:19] <seb128> infinity: I've some changes to do for that one probably, but that will probably wait next week so go for a no-change if you want to get that sorted now
[01:19] <tepsipakki> mithrandir: that's what I thought..
[01:19] <infinity> seb128: Kay, cool.
[01:19] <infinity> seb128: I'm just trying to make pitti happy. ;)
[01:20] <seb128> infinity: that's nice from you :)
[01:20] <seb128> k, I've made the irssi change
[01:20] <seb128> am I supposed to do the same for server, kubuntu, edubuntu, etc?
[01:20] <infinity> seb128: If you're feeling nice.
[01:20] <infinity> seb128: Otherwise, others are (in theory) supposed to merge seed changes.
[01:20] <seb128> I am, let's do it :)
[01:22] <pitti> seb128: yes, please merge (not apply manuallY)
[01:24] <infinity> pitti: In about 2 cron.daily cycles, gnutls11 should fall out of main.
[01:24] <pitti> yay
[01:25] <infinity> pitti: Building the hppa stragglers now, and just uploaded for the two ia64 oopses.
[01:25] <pitti> three DapperDuplicatedPackages items solved on one day :)
[01:25] <infinity> pitti: Anything else the SCC arches are holding you back on?
[01:25] <pitti> no, gnutls11 was the only one
[01:25] <pitti> the others were just seed changes
[01:26] <Riddell> seb128: if you do seed changes you should at least tell me and orga, else we won't know to merge
[01:26] <Riddell> seb128: and if you merge yourself them we'll love you all the more
[01:26] <pitti> Riddell: I did a couple, but I always merge immediatel after them
[01:26] <Riddell> just like we love pitti
[01:26] <pitti> heh :)
[01:27] <seb128> pitti, Riddell: change merged for server, edubuntu, kubuntu
[01:28] <Riddell> groovy, thanks
[01:28] <seb128> np
[01:30] <infinity> After some bumpy starts, I think we understand each other now.
[01:31] <pitti> love on the second sight then :)
[01:37] <Kamion> infinity: how soon do you reckon I can turn anastacia back on for hppa?
[01:38] <Kamion> 'cos I'd like to do that, sort anastacia out, and then promote xubuntu
[01:38] <Kamion> rather than trying to cope with the hppa-induced wreckage when working out what to do with xubuntu :)
[01:40] <infinity> Kamion: Turn it back on now and see how horrifying it is?
[01:40] <infinity> Kamion: But hppa should be completely caught up (modulo the usual hiccups) after the weekend, I suspect.
[01:43] <Kamion> are the toolchain issues I saw vaguely mentioned some hours back likely to hold it back in places?
[01:48] <infinity> Kamion: The only toolchain issue is in Java, which can be either worked around or completely disabled if a better solution doesn't present itself quickly.
[01:49] <infinity> The usual "gcj only works on 3 of the 400 architectures gcc works on, and no one really cares, and even on the 3 where it does work, it sometimes doesn't" song and dance.
[01:49] <pitti> Mithrandir: hm, what's wrong with the about box change? s/DIALOG/POPUP/?
[01:49] <Mithrandir> pitti: nah, it's the "GTK 2 port by" part I was thinking about.
[01:50] <pitti> hm, it's a pretty big patch, you think we should remve the credit for it?
[01:50] <pitti> (as it is now, it looks wrong, though, you are right)
[02:04] <mdke> Keybuk, sabdfl, mjg59, still looking for a response on the documentation string freeze date... I figure it's important to get it sorted quickly so that's the reason for pinging you on irc
[02:06] <Keybuk> mdke: I'm still not convinced that UIFreeze and StringFreeze aren't critical-path for the DocStringFreeze
[02:06] <Keybuk> so far the argument seems to be "we're nearly finished now, so we should freeze now" ... which doesn't necessate moving the freeze date
[02:07] <mdke> Keybuk, the argument is based on translation
[02:07] <mdke> the docs don't need more time, translation does
[02:08] <mdke> the alternative is simply starting translation earlier than the freeze date, but it would make the freeze date pretty meaningless, since the whole point is to ensure that translators get a fair shot at the strings without them changing
[02:08] <Keybuk> translation is getting more time though, under the new schedule
[02:08] <Keybuk> how much more time for it would you like?
[02:09] <mdke> Keybuk, 4 weeks or so. so, moving doc freeze 2 weeks, rather than 6
[02:09] <Keybuk> that'd mean you were freezing the documentation 3 weeks *before* what you were documenting was frozen
[02:09] <Keybuk> so we'd end up shipping wrong docs
[02:10] <mdke> Keybuk, the likelyhood of changes affecting the documents is slim. And if you saw my email, I suggested allowing later amendments for any changes, which would be announced to the translators
[02:11] <Keybuk> ok
[02:11] <raphink> i've got a questions about cups
[02:11] <raphink> -s
[02:11] <raphink> what are the default admin name and pass for cups ?
[02:12] <raphink> since we only set one user without a root account by default
[02:12] <raphink> and this user can't access cups as admin it seems
[02:14] <pitti> raphink: it can, you need to be member of 'lpadmin' group
[02:14] <raphink> ah ok thanks pitti
[02:15] <raphink> pitti: I just checked it doesn't work
[02:16] <raphink> maybe it's linked to the printing module in systemsettings
[02:16] <pitti> raphink: and gnome-cups-admin doesn't work?
[02:16] <pitti> raphink: ah, KDE?
[02:16] <fiveiron> so where would I go if I was having a major problem getting any of my repositories to work?
[02:16] <raphink> yep
[02:16] <fiveiron> using dapper
[02:16] <pitti> raphink: known broken, yes
[02:16] <pitti> raphink: bug 33173
[02:16] <Ubugtu> malone bug 33173 in kdebase kdeprint "kdeprint can not contact cups" [Major,Confirmed]  http://launchpad.net/bugs/33173
[02:16] <mdke> fiveiron, forum/mailing list/support request on launchpad/#ubuntu irc channel
[02:16] <raphink> pitti: when I got to systemsettings, in the kdeprint section and choose Server -> Configure Server
[02:16] <raphink> pitti: no, it's something else
[02:17] <mdke> fiveiron, or if you think it's a bug, https://launchpad.net/distros/ubuntu/+bugs
[02:18] <fiveiron> i just know i get md5 sum mismatches/gzip errors/bzip2 errors all over the place... i can barely get anything installed
[02:19] <mdke> Keybuk, is that an ok, as in "ok from me, ask the rest of the TB", or "ok, consider it changed"?
[02:19] <pitti> raphink: well, kdeprint is known broken with our cups, it just won't work
[02:20] <Keybuk> mdke: as I said yesterday, *I* don't have any particular problem with moving just that date if you wish :)  however the rest of the TB and CC probably need to vote, as we've already approved the new schedule and stuff
[02:20] <mdke> Keybuk, sorry, I wasn't around yesterday. So how do I go about getting them to vote?
[02:21] <seb128> ogra: irssi-text to irssi
[02:22] <ogra> seb128, thanks ...
[02:22] <Keybuk> mdke: wait for replies to your e-mail I guess
[02:23] <seb128> ogra: np :)
[02:23] <Keybuk> or just grab people on IRC
[02:23] <seb128> dholbach: lunch time for me too :)
[02:24] <mdke> Keybuk, ok. hopefully someone will respond. The sooner it is sorted out, the better.
[02:28] <Kamion> Keybuk: just the TB would be fine I think
[02:28] <Kamion> if the CC doesn't trust the TB on technical issues we're kinda screwed anyway
[02:29] <elkbuntu> hmm... is there a known permission bug with nautilus? i'm asking because sometime within the last 12 hours or so, directory permissions have been weird. i think it's just nautilus because ls shows permissions fine. in nautilus when i rightclick -> properties -> permissions, it's saying 'The permissions of 'directoryname' could not be determined.'
[02:31] <mdke> Keybuk, maybe if you reply to the email, there will be an avalanche effect and the emails will come flooding in.
[02:32] <Keybuk> mdke: I've already sent another
[02:33] <mdke> Keybuk, thanks! 
[02:38] <zul> heylo
[02:42] <xhaker> dholbach, metacity is not built with libcm7, and i think it should, shouldn't it?
[02:43] <Mithrandir> xhaker: no, why should it?
[02:43] <xhaker> Mithrandir: changelog claims compositing manager inclusion :S
[02:44] <pitti> jdub: ping
[02:44] <infinity> xhaker: You probably want spiftacity.
[02:44] <infinity> xhaker: I doubt libcm7 (and hence compositing in metacity) will be in main for dapper.
[02:45] <xhaker> infinity, again.. see the changelog of ubuntu metacity. dholbach wrote compositing manager
[02:46] <xhaker> i just find it wierd it's on the changelog
[02:46] <infinity> xhaker: He's documenting changes to the source (he notes that the feature is disabled)
[02:46] <infinity> xhaker: The desktop guys often mention stuff in their changelogs that doesn't seem immediately Debian/Ubuntu relevant, it seems. :)
[02:47] <infinity> (base)adconrad@cthulhu:~$ zgrep Solaris /usr/share/doc/metacity/changelog.Debian.gz
[02:47] <infinity>     - manually define HOST_NAME_MAX if not already defined to fix Solaris
[02:47] <infinity>     - Fix Solaris compilation issues
[02:47] <infinity> (for example)
[02:47] <xhaker> infinity, oh, as in ifed out? i thought he was talking about gconf schema
[02:47] <seb128> no
[02:47] <seb128> that's a configure option
[02:47] <seb128> and we don't use it
[02:48] <xhaker> ok then 
[02:48] <seb128> infinity: would should be pinged for packages removal? a bug triager pointed https://launchpad.net/distros/ubuntu/+source/live-com/+bug/6651
[02:48] <Ubugtu> malone bug 6651 in live-com "duplicate package" [Normal,Unconfirmed]  
[02:48] <infinity> seb128: Kamion, probably.
[02:49] <infinity> seb128: I'm not familiar with the tool used for removals just yet.  (I guess I should teach myself sometime)
[02:49] <seb128> Kamion: https://launchpad.net/distros/ubuntu/+source/live-com/+bug/6651 suggests live-com should be removed, it's a multiverse package, liblivemedia for universe deprecates it now
[02:49] <Ubugtu> malone bug 6651 in live-com "duplicate package" [Normal,Unconfirmed]  
[02:55] <pitti> Riddell: did you try nss-mdns? it's seeded to kubuntu-desktop now
[02:56] <Riddell> pitti: yes, I've tried it
[02:56] <pitti> Riddell: there are now some Debian bugs, but they don't look too scary
[02:56] <pitti> Riddell: so it *only* resolves domains from .local?
[02:56] <pitti> Riddell: or can you fool it to resolve other domains?
[02:57] <Riddell> pitti: yes, .local is reserved for zeroconf I believe so that should be hard coded
[02:57] <pitti> Riddell: e. g. if you accidentially put it first in nsswitch.conf
[02:57] <Riddell> Lathiat might know
[02:57] <Riddell> pitti: putting it first in nsswitch isn't a problem
[02:57] <Riddell> infact it's recommended by the authors I think, not sure why debian puts it last
[02:58] <pitti> Riddell: hm, so with a modified avahi I can't change the DNS of e. g. www.google.de or so?
[02:58] <Riddell> pitti: you'd need to ask the avahi people to confirm but I'm pretty sure it's hard coded to only do .local
[02:58] <Kamion> seb128: done, thanks
[02:58] <seb128> Kamion: thank you!
[02:59] <pitti> Riddell: I think the currnet package does not change nsswitch automatically at all; there are just debian bugs
[02:59] <Riddell> pitti: I have mdns in my nsswitch on this fairly fresh install from a flight CD, no libnss-mdns installed
[02:59] <pitti> Riddell: oh, ok, I checked the code, it does
[03:00] <pitti> Riddell: oh, right, me too, so that must already be the default
[03:00] <Riddell> so it must be the default in nsswitch
[03:04] <pitti> Kamion: alright, so with the recent fixes and approvals, the universe->main section of anastacia should become empty
[03:06] <pitti> Riddell: would it be easy to change kicker-applets to not build the xmms remote control, i. e. drop the libgtk1.2 build dep?
[03:06] <desrt> pitti; know anything about recent hal changes that are causing tonnes of new volumes to show up in gnomevfs?
[03:07] <pitti> desrt: that was a last-minute patch in upstream gnome-vfs
[03:07] <Riddell> pitti: I think I already did that, at the distro sprint
[03:07] <pitti> desrt: they removed all the policy bits
[03:07] <desrt> pitti; ouch.
[03:07] <pitti> desrt: I worked around that by adding some volume.ignore policy to our hal package
[03:07] <Kamion> pitti: cool, thanks! I'll start in on that after this publisher run
[03:07] <Kamion> pitti: no report for c2man?
[03:07] <desrt> pitti; sweet.
[03:07] <pitti> Kamion: c2man is crack and should die
[03:07] <desrt> <3
[03:07] <bddebian> heh
[03:07] <Kamion> ah, so libvformat is being changed?
[03:07] <pitti> Kamion: I changed libvformat to not use it any more
[03:07] <seb128> desrt: davydz changed the gnome-vfs code after freezes and changed the behaviour upstream ...
[03:08] <pitti> Kamion: same for gnulib, I fixed libgd2
[03:08] <Riddell> pitti: I can't see a gtk build dep 
[03:08] <Riddell> "* Remove build-dep on xmms-dev to get xmms out of main"
[03:08] <Kamion> ok, good stuff
[03:08] <desrt> wow.  i totally love last minute api breaks.
[03:08] <desrt> ahem
[03:08] <pitti> Kamion: (the dependency is not necessary)
[03:08] <pitti> Riddell: ok, so then it's just the wiki page which is outdated. thank you!
[03:09] <pitti> desrt: yes, that was pretty bad
[03:11] <pitti> Kamion: argh, libvformat was rejected, uploading fixed pacakge now (s/unstable/dapper/ *brown paperbag*)
[03:11] <desrt> er.  some bad foo is going down.
[03:13] <desrt> pitti; after a reboot, my 153.7 GB Volume is still here
[03:13] <desrt> pitti; but my external cdrom drive is now hidden
[03:14] <desrt>   volume.ignore = false  (bool)
[03:14] <desrt> on my /mnt/media drive
[03:15] <pitti> desrt: hm, false is right
[03:15] <desrt> why?
[03:15] <pitti> desrt: do you use the latest dapper hal/gvfs, or upstream's?
[03:15] <infinity> pitti: Speaking of anastacia output, can you make sure that for every libdbX.X we have in main, we have the corresponding dbX.X-util in supported?
[03:15] <desrt> latest dapper
[03:15] <infinity> pitti: (Since you're playing with seeds already)
[03:15] <pitti> infinity: s/are/was/, but I can add it, sure
[03:15] <pitti> desrt: well ignore = false --> it is shown :)
[03:15] <infinity> pitti: Having the libs without the utils is pretty bad form (especially since many packages suggest/recommend the utils for recovery and such)
[03:16] <desrt> pitti; i don't want it shown
[03:16] <desrt> pitti; /mnt/media is a ext3 filesystem that gets mounted on boot... it's part of my system
[03:16] <pitti> desrt: you don't want to see your cd-rom drive?
[03:16] <pitti> ah, that one
[03:16] <desrt> it's got my oggs :)
[03:16] <pitti> desrt: right, I left /mnt and /media visible and hide all the rest
[03:16] <desrt> ah.  i see.
[03:16] <pitti> it's pretty hard to come up with a default policy which suits everyone
[03:16] <pitti> s/hard/impossible
[03:17] <pitti> desrt: this stuff doens't belong into hal at all
[03:17] <desrt> default policy: if i can mount/unmount it as my user, let me see it
[03:17] <desrt> if it's fstab root-only then i don't want to see it :)
[03:17] <pitti> desrt: hal doesn't read fstab, but it would be nice if it did
[03:17] <desrt> hmm
[03:17] <pitti> desrt: and second, many peopel statically mount their windows drive and still wnat to see it
[03:17] <pitti> bah, my typing sucks
[03:17] <desrt> can we roll back the gnome-vfs change?
[03:18] <pitti> desrt: we could, of course, but only if upstream does it as well
[03:18] <desrt> hm
[03:18] <pitti> which i hope they do
[03:18] <desrt> excellent.
[03:18] <pitti> it wasn't well thought out at all
[03:18] <desrt> in the mean time i wonder why the heck my cdrom isn't in my drivemount applet anymore
[03:18] <pitti> desrt: I always thought that David wanted to push policy out of hal into gconf
[03:18] <desrt> it doesn't have an  'ignore' attribute at all
[03:18] <desrt> which i assume means that it defaults to false
[03:18] <pitti> desrt: oh, hm, that explains it
[03:19] <pitti> desrt: not necessarily
[03:19] <desrt> lemme guess
[03:19] <desrt> ignore = hal_get_bool(); // returns -1
[03:19] <desrt> if (ignore)
[03:19] <desrt>   ...
[03:19] <pitti> desrt: no, it's FDI policy
[03:19] <pitti> desrt: but that might still do that approach
[03:19] <pitti> oh, I'm talking rubbish
[03:20] <pitti> desrt: ok, so we should make sure that all devices get that attribute :)
[03:20] <desrt> pitti; hold on a sec
[03:20] <desrt> pitti; this may not be the problem
[03:20] <pitti> desrt: can you please send me the hal-device output for your cdrom? I'll deal with that after lunch
[03:20] <desrt> pitti; under SCSI Host Adapter -> SCSI Device -> SCSI Generic Interface
[03:21] <desrt> but no 'scsi cdrom interface'
[03:21] <desrt> and nowhere in lshal do i see 'scd0'
[03:21] <pitti> oh, iz hal bug then?
[03:21] <seb128> hum
[03:21] <desrt> it's recent.
[03:21] <seb128> desrt, pitti: upstream is not going to revert if nobody does complain loud about it
[03:22] <desrt> seb128; i'm good at complaining loud :D
[03:22] <pitti> desrt: will you?
[03:22] <seb128> desrt: so go for it :) I argued it with davydz the day he did the commit and broke it
[03:22] <seb128> but he somewhere convinced me it was ok
[03:23] <seb128> saying using the .ignore hal property stuff works fine, that they are doing it on fedora, etc
[03:23] <pitti> well, but hal is just the wrong place to define that stuff
[03:23] <seb128> that nobody was using the gconf settings anyway
[03:23] <pitti> so he made it worse :)
[03:24] <desrt> can't we take whatever logic was living inside gnome-vfs and move it into hal?
[03:24] <desrt> anyway.  gotta go to school.  peace.
[03:24] <infinity> lp_archive@drescher:~$ checkrdepends gnutls11 dapper
[03:24] <infinity> -- dapper/universe build deps on libgnutls11-dev:
[03:24] <infinity> [...] 
[03:24] <infinity> pitti: No more main deps.
[03:24] <pitti> desrt: no, my point is that it is *wrong* to put it into hal
[03:25] <desrt> pitti; ah.
[03:25] <desrt> pitti; you'll hear more from me later :)
[03:25] <pitti> desrt: that's something a user wants to customize
[03:25] <pitti> infinity: nice to see my script be useful somewhat :)
[03:25] <infinity> pitti: Yup, should have had it take nother argument for component, though. :)
[03:25] <pitti> infinity: so we'll see it in anastacia in 7 minutes
[03:26] <pitti> infinity: right, easy enough to add
[03:26] <bddebian> infinity: Sorry to bug you but I have what I hope is a quick question on proftpd.  I set DefaultDir to /archive and created a <Directory> /archive/incoming but when I connect I get dumped into my home dir?
[03:26] <infinity> pitti: Respecting the ogre model, of course (so, checkrdeps foo dapper restricted would check main/restricted)
[03:26] <pitti> alright, I'm *finally* going to have some lunch
[03:26] <pitti> infinity: can you please mail it to me with your fixes?
[03:27] <infinity> bddebian: DefaultRoot and DefaultChdir are what you want, I htink.
[03:27] <infinity> pitti: Sure, when I change it.
[03:27] <infinity> pitti: Which will be later, cause it's 1:30am, and I only stayed up to babysit these builds. :)
[03:27] <pitti> then, rather enjoy your weekend :)
[03:27] <infinity> pitti: But I'd written a very similar script last release cycle when I was tracking the libgl-mesa transition. :)
[03:28] <infinity> (Mine had prettier output, though... Thpt)
[03:28] <Kamion> pitti: I already added a -b switch to check just one binary package, btw
[03:28] <Kamion> my bad for not mailing it to you already
[03:28] <pitti> infinity: I know that I suck at UI :)
[03:29] <pitti> no problem :) let's just make sure that we unify it at some point
[03:29] <cpt-carter> Not sure if this is the write channel, but since the official release of Dapper is 1June, will gnome 2.14.1 make it into dapper?
[03:29] <cpt-carter> Since they are talking about the newer version of KDE
[03:29] <cpt-carter> gnome 2.14.1 comes out  April 12th
[03:30] <Treenaks> cpt-carter: yes, it will
[03:32] <infinity> bddebian: DefaultRoot is a chroot, DefaultChdir defines where the client starts when they login.
[03:33] <infinity> bddebian: (So, a classic UNIX-life FTP setup would be DefaultRoot /, DefaultChdir ~)
[03:36] <cpt-carter> Treenaks: Awesome! Thankyou
[03:50] <netstar> Does anyone get a warning dialogue pop up for half a second when accessing desktop properties dialogues?  Others are reporting the same.
[03:59] <giftnudel> how can I debug swsusp hibernating so that I can see some messages (debug if possible) on the screen
[04:10] <infinity> pitti: Your evms changes are FTBFS...
[04:10] <infinity> pitti: http://librarian.launchpad.net/1776859/buildlog_ubuntu-dapper-ia64.evms_2.5.4-5ubuntu2_FAILEDTOBUILD.txt.gz
[04:14] <Kamion> Mithrandir: please merge http://people.ubuntu.com/~cjwatson/bzr/casper/espresso-passwd/ - fixes wrong defaults on espresso's user/password screen
[04:23] <pitti> infinity: will look at that, thanks; hm, worked for me
[04:24] <pitti> Kamion: yay, gnutls11 in anastacia :)
[04:34] <pitti> infinity: bah, that's likely due to the heartbeat installation failure
[04:37] <Kamion> pitti: and demoted already :)
[04:38] <Kamion> pitti: indent is a very popular development tool; perhaps we should have it in supported?
[04:38] <pitti> Kamion: I have no objection
[04:41] <Kamion> (it was already there anyway as a build-dependency, but wants to fall out recently)
[04:41] <pitti> Kamion: right, has always been in main, so I can shy around an inclusion report :)
[04:42] <Kamion> ok, done
[04:42] <Kamion> and mozilla-thunderbird-locale-* should be in supported for transitional purposes, I think
[04:47] <pitti> Kamion: right, shall I add them?
[04:49] <Kamion> pitti: I just did
[04:49] <pitti> cheers
[04:49] <pitti> doko: is gcj-4.0 safe to go to universe? we're using 4.1 now consitently?
[04:51] <pitti> Riddell: konserve is superseded by keep? can it go to universe safely?
[04:52] <pitti> ogra: if you want gobby in edubuntu, can you please seed it? it currently wants to go to universe again
[04:52] <ogra> pitti, i dont think pkern fixed it ...
[04:52] <pitti> ogra: 'it'?
[04:53] <ogra> howl dependency
[04:53] <doko> pitti: it should be, but we currently have a problem with hppa
[04:54] <pitti> seb128: AFAIR we added wavpack because gstreamer had a module for it; the current gstreamer hasn't any more?
[04:55] <infinity> doko: Hopefully we can resolve the hppa breakage next week...
[04:55] <ogra> pitti, its still depends on libavahi-compat-howl0, even in debian ... i wont be the evil guy pulling the howl compat layer into a 5 year release ... gobby can go to universe :/
[04:55] <infinity> doko: If 4.0 works on hppa and 4.1 doesn't, the regression can't be too hard to find... Hopefully.
[04:55] <Kamion> ogra: ok, I'll demote it if nobody objects
[04:56] <ogra> yup :(
[04:56] <doko> infinity: 4.1 works on unstable, but not on dapper, pestering jbailey ...
[04:56] <pitti> Kamion: net6 and obby can go then, too
[04:56] <Kamion> yep
[04:56] <pitti> janimo: what about ivman? do you want it for xfce?
[04:56] <janimo> pitti, we no longer use it
[04:57] <janimo> it won;t be in default install
[04:57] <infinity> ogra: What's wrong with libavahi-compat-howl0?
[04:57] <seb128> pitti: gstreamer0.10-plugins-bad: /usr/lib/gstreamer-0.10/libgstwavpack.so
[04:57] <pitti> janimo: what's the replacement?
[04:57] <pitti> seb128: ah, so that's universe now
[04:57] <janimo> pitti, thunar has built in volmanager
[04:57] <pitti> janimo: ah, cool
[04:57] <seb128> pitti: for now, it'll come back probably
[04:57] <ogra> infinity, upstream will drop it (and support for it) soon 
[04:57] <janimo> which upstream wants to split out to a sane daemon
[04:57] <janimo> so ther's going to be a new one apparenyly
[04:57] <ogra> infinity, thats why we dont build it at all
[04:57] <seb128> pitti: -bad are stuff lacking documentation, or testing, or maintainer but destined to be moved to ugly or good
[04:58] <infinity> ogra: Oh, shame.  Kay.  And no work being done (rapidy enough for us, anyway) to port gobby to use avahi natively?
[04:58] <infinity> ogra: Err, we do so build it.
[04:58] <ogra> infinity, i havent talked to pkern (upstream) since UVF (where he added that dep one day before)
[04:58] <janimo> what was the reason for avahi spec not making dapper
[04:58] <sladen> Kamion: what's the best practice for getting logfiles out of the installer?  Does it have 'scp' or similar in the initramfs at that stage?
[04:59] <ogra> infinity, what ? 
[04:59] <Kamion> we do build it, but there was an admonishment in the changelog to never put it in main
[04:59] <pitti> Riddell: btw, are you aware that *you* are now the bad guy who holds libmad in main? :)
[04:59] <Kamion> sladen: 'anna-install openssh-client-udeb' to get scp; alternatively, and what I usually recommend to bug reporters, go back to the installer main menu and select "Save debug logs"
[04:59] <Kamion> one of the items there fires up a mini-web-server so you can fish the logs out
[04:59] <pitti> Riddell: totem doesn't need it any more, but libakode-dev and libarts1-dev do :)
[04:59] <Kamion> or you can save to floppy or mounted filesystem or whatever
[05:00] <pitti> Riddell: and k3b, although this seems to be a stray build dependency
[05:00] <Kamion> pitti: weird, I wonder why ivman was apparently in breezy main
[05:00] <Kamion> it doesn't seem to be germinated in breezy
[05:00] <pitti> Kamion: for KDE maybe
[05:00] <sladen> Kamion: excellent, thanks
[05:01] <Kamion> pitti: oh, yeah, it was in kubuntu-breezy desktop
[05:01] <pitti> Kamion: yep, kubuntu-desktop in breezy
[05:01] <ogra> Kamion, any idea why ? 
[05:01] <Kamion> ogra: no
[05:01] <pitti> well, for autoamtic mounting? 
[05:01] <pitti> Riddell: what does KDE use now, instead of ivman?
[05:01] <ogra> the changelog entry doesnt tell a reason ...
[05:01] <Kamion> "remove ivman since KDE 3.5 includes own
[05:01] <Kamion> manager
[05:01] <Kamion> "
[05:02] <pitti> ah
[05:02] <Kamion> kubuntu-dapper bzr log
[05:02] <ogra> slomo, ?? "  * Enable the howl/libdns-sd compat packages. These are to be demoted to
[05:02] <ogra>     universe and should stay there forever"
[05:02] <pitti> . o O { it's so nice to clean up the house^Warchive on a Friday afternoon :) }
[05:03] <Kamion> what about libdvd{nav,read}? that's potentially for gstreamer dvd support, I think
[05:03] <pitti> ogra: ... so prevent them from ever being demoted :)
[05:03] <ogra> haha
[05:03] <pitti> Kamion: AFAIK gst now can read DVDs, but menu support wasn't ported yet
[05:03] <pitti> Kamion: so I guess dvdnav might stay around eventually
[05:03] <ogra> pitti, i guess there was a reason for such a sentence :)
[05:03] <slomo> ogra: that's just a notice that nobody ever gets the idea to promote them to main :)
[05:03] <ogra> slomo, why ? 
[05:04] <Kamion> I think part of the question is "why do we build them in the first place?"
[05:04] <ogra> they are only compatibility layers...
[05:04] <pitti> Kamion: dvd or howl?
[05:04] <Kamion> howl
[05:04] <slomo> ogra: they're to be dropped (and not recommended) by upstream soon and as such not really supportable for 3/5 years...
[05:05] <ogra> debian builds them ... even for main ...
[05:05] <slomo> Kamion: because there were many users that wanted them anyway
[05:05] <Kamion> ok
[05:05] <ogra> slomo, ok, thats what i thought ...
[05:09] <Kamion> pitti: it's required on the build machine for building hppa CD images
[05:09] <pitti> ah
[05:10] <Kamion> in fact, I should put it in supported for all arches with a comment to that effect, since it's installed on little
[05:10] <pitti> oh, I just found another excellent cleanup canditate: libxml++2.6 is not needed any more, it's just the doc that keeps it in main
[05:11] <pitti> Kamion: do you have a currently pending seed change?
[05:11] <pitti> Kamion: if so, maybe you could remove libxml++2.6-doc
[05:12] <Kamion> pitti: will do, just a sec
[05:13] <pitti> doko: openoffice.org2 can be entirely removed?
[05:13] <Kamion> pitti: done, will merge
[05:14] <Kamion> pitti: we might want to keep transitional packages around for upgrades?
[05:14] <Kamion> (oo.o2)
[05:14] <doko> pitti: entirely?
[05:14] <pitti> Kamion: right, but aren't they produced by the ooo pacakge now? doko?
[05:14] <doko> no, just the binary packages at http://people.ubuntu.com/~cjwatson/testing/dapper_probs.html
[05:15] <pitti> doko: erm, why should we keep the source in main?
[05:15] <Kamion> doko: those are still built by openoffice.org, I can't just remove them
[05:15] <Kamion> pitti: I removed openoffice.org2 source a couple of days ago
[05:15] <pitti> Kamion: the ooo2 transitional binaries shuold stay of course
[05:16] <pitti> Kamion: ah, my bad, should look closer :) yes, they should be seeded then
[05:16] <pitti> doko: sorry, nevermind then
[05:16] <Kamion> as doko observes they're uninstallable at the moment
[05:16] <Kamion> haven't investigated why
[05:16] <infinity> Kamion: Is britney not running anymore, or are those binaries hanging around from an old OO.o build?
[05:17] <Kamion> britney's running ...
[05:17] <infinity> Kamion: Note that they claim to be from 2.0.1-something, we're at 2.0.2
[05:17] <Kamion> weird though, I see what you mean
[05:17] <Kamion> maybe they're ASBA binaries
[05:17] <Kamion> architecture: any superseded by architecture: all
[05:17] <doko> Kamion: no, the all packages ...
[05:17] <doko> yes
[05:17] <Kamion> soyuz doesn't always manage to kill off the old binaries properly
[05:18] <infinity> Ouch.
[05:18] <Kinnison> yeah, that's weird
[05:18] <Kinnison> We need to track that down at some point
[05:18] <Kamion> yeah, archive-cruft-check lists them as ASBA
[05:18] <Kamion> also eclipse and openoffice.org2-evolution
[05:18] <Kamion> Kinnison: is there any sensible way to get rid of them for now, or should I just leave them there?
[05:18] <doko> openoffice.org2-evolution is correct
[05:19] <Kamion> I suppose I could figure out how to make britney ignore them, but that sounds like work
[05:19] <Kinnison> Kamion: erm, not sure
[05:19] <doko> that's a binary-arch depdency package (we don't have this for amd64)
[05:19] <Kinnison> Kamion: they *should* get dominated, but they're not for some reason
[05:19] <Kamion> openoffice.org2-evolution | 2.0.1oob680m5-0ubuntu2 |        dapper | all
[05:19] <Kamion> openoffice.org2-evolution | 2.0.2-1ubuntu3 |        dapper | i386, powerpc, sparc
[05:19] <Kinnison> Kamion: essentially I need to concentrate hard and work it out
[05:20] <Kamion> presumably it isn't dominated because it's still the newest on some arches
[05:20] <Kinnison> Kamion: but it's probably a couple of days to reliably reproduce in a small sample set and then a few minutes to fix
[05:20] <Kinnison> domination is per-arch
[05:20] <infinity> Do we have the same problem going from any -> all?
[05:20] <infinity> Or just all -> any?
[05:20] <Kinnison> I imagine only all->any
[05:20] <Kamion> I have noticed ASBA binaries disappearing *eventually* sometimes; there used to be four sets in the archive and now there are only three
[05:20] <Kinnison> Kamion: probably when hppa and sparc catch up?
[05:20] <Kamion> doko: it can't be correct because it isn't built from newest source
[05:21] <infinity> Kinnison: hppa, amd64, and ia64 don't build openoffice, you have all the binaries you'll ever have.
[05:21] <Kamion> unless the old arch: all binary is effectively NBS
 openoffice.org2-evolution | 2.0.2-1ubuntu3 |        dapper | i386, powerpc, sparc
[05:21] <doko> that is newest sourc
[05:21] <doko> e
[05:21] <Kamion> doko: 16:19 < Kamion> openoffice.org2-evolution | 2.0.1oob680m5-0ubuntu2 |        dapper | all
[05:21] <Kamion> that isn't
[05:21] <seb128> pitti: "Add missing build dependency libdevmapper-dev and libglib1.2-dev" ... it uses gtk2 but still glib1.2?
[05:21] <doko> ok
[05:21] <Kamion> and it's still in the archive, stuck
[05:21] <pitti> seb128: yes, sadly
[05:21] <Kamion> Kinnison: what happens if amd64 *never* builds the new binary, as doko seems to be suggesting?
[05:22] <pitti> seb128: more precisely, the curses interface uses glib
[05:22] <Kamion> i.e. an arch-specific NBS
[05:22] <Kinnison> Kamion: probably needs archive-cruft-check to recommend a removal on that arch
[05:22] <seb128> pitti: hum, k
[05:22] <Kamion> can I do that if the binary's arch: all?
[05:22] <Kamion> all - amd64
[05:22] <seb128> pitti: that's probably trivial to port to glib2.0
[05:22] <Kinnison> Kamion: I don't know
[05:22] <jordi> pitti: who do I talk to to get a new pacakge from debian synced into ubuntu?
[05:22] <infinity> Such confidence!
[05:22] <pitti> seb128: would be nice :)
[05:22] <Kinnison> Kamion: I've never tried
[05:23] <doko> Kamion: "never" in the sense, that we build it still from i386 binaries, which is incompatible with the current 64bit evolution
[05:23] <pitti> jordi: upload it as Nbuild1, syncs are borked at the moment
[05:23] <pitti> jordi: then pester Kamion to NEW it
[05:23] <Kinnison> if infinity continues to heckle, I'll remove that patch
[05:23] <infinity> Kinnison: I'll not heckle. :)
[05:23] <jordi> ick
[05:23] <jordi> mvo: ^ can you do that?
[05:23] <Kamion> Kinnison: I think infinity's heckling seb128, not you. :-)
[05:24] <jordi> pitti: can't upload anything, so...
[05:24] <infinity> Kinnison: (That patch will reduce hppa's "catching up" from a week to a couple of days, so, yeah. I want it. :))
[05:24] <bddebian> infinity is still awake?
[05:24] <Kinnison> Kamion: oh right
[05:24] <pitti> jordi: which package do we talk about?
[05:24] <jordi> bddebian: must be pretty late there
[05:24] <Kamion> infinity: BTW makx is looking for you on #ubuntu-boot
[05:24] <jordi> ttf-lao; incoming
[05:24] <bddebian> jordi: Heh, no kidding :-)
[05:24] <infinity> Kamion: He found me in -kernel. :)
[05:24] <Kamion> fair enough :)
[05:24] <jordi> pitti: go for it
[05:25] <infinity> bddebian: Rumour is that he never sleeps, only sets himself "away" on IRC occasoinally and pretends to not be around.
[05:25] <infinity> bddebian: I'm not sure if there's any truth to this rumour.
[05:25] <pitti> jordi: hm, sure? that package is a mere 50kB
[05:26] <jordi> pitti: checking
[05:26] <jordi> it's just a font
[05:26] <infinity> Kinnison: Oh, and for the reocrd, I was heckling you, not seb, though I appreciate Colin's attempt to save my ass. :)
[05:26] <pitti> jordi: a small one, for a change :)
[05:26] <jordi> heh
[05:26] <Kamion> infinity: heh, fair enough :)
[05:26] <jordi> it covers lao,  and thats all, hopefully
[05:27] <Kinnison> but that's 'cos daf has such a nice donkey
[05:27] <Kamion> pitti: oh, archive-cruft-check wants to remove libpoppler0c2{,-glib,-qt} but some of them still have reverse-deps
[05:27] <jordi> pitti: hmm
[05:27] <pitti> Kamion: oh, right, that requires porting work
[05:27] <pitti> jordi: ready to upload? I can fire at your command :)
[05:27] <jordi> pitti: the ttff I've got here is about 120K
[05:27] <pitti> Kamion: I only ported tetex so far
[05:28] <jordi> let me check further
[05:28] <bddebian> infinity: :-)
[05:28] <Kamion> pitti: oh, right, didn't realise that
[05:28] <sabdfl> Kinnison: just to be clear. do you want an ass like that of your neighbour?
[05:28] <sabdfl> or would any old ass do?
[05:28] <Kinnison> sabdfl: Well, my neighbour's ass is nicer than mine
[05:29] <pitti> Kamion: *sigh* thanks for reminding me; seb128, did you happen to start with the poppler transition for abiword?
[05:29] <jordi> pitti: FIRE
[05:29] <Kinnison> ogra: not particularly
[05:29] <ogra> heh
[05:29] <pitti> jordi: BOOM, it'll be in NEW in a few minutes
[05:29] <dholbach> pitti: abiword is built without it
[05:29] <dholbach> pitti: iirc
[05:29] <pitti> $ apt-cache rdepends libpoppler0c2
[05:29] <pitti>   abiword-plugins
[05:29] <dholbach> pitti: if we were to use it, the patch is about one line
[05:30] <dholbach> oh
[05:30] <dholbach> let me try to find the patch again
[05:30] <ogra> Kinnison, thats what donkey reminds me on, sorry :)
[05:30] <ogra> s/on/of/
[05:30] <Kinnison> are we there yet?
[05:30] <seb128> pitti: not yet, but seems dholbach has that under control :)
[05:30] <infinity> Kamion: Would it be possible to get _outdate.txt sorted by package instead of by arch?... It's a bit more informative to see "this is out of date on all arches, probably broken; this is outdated on one arch, should chase up why it failed; etc"
[05:31] <pitti> Kamion: I'll grab and port kpdf then
[05:31] <pitti> *sigh* why, oh why did I ever touched that stuff
[05:32] <infinity> pitti: Masochism.
[05:32] <infinity> Hrm, britney output for ports is slowly approaching readable again...
[05:33] <dholbach> pitti: http://www.abisource.com/viewcvs/cgi/viewcvs.cgi/abiword-plugins/wp/impexp/pdf/xp/ie_imp_PDF.cpp.diff?r1=1.2&r2=1.3 :)
[05:33] <pitti> yay, 48 MB build dependencies for kdegraphics
[05:33] <jordi> Kamion: any what's the formail way of making you kick ttf-lao in main? mail?
[05:33] <dholbach> pitti: you want me to do the change for abiword or do you have the source already there?
[05:34] <pitti> dholbach: YM that s/true/false/ is everything required for libpoppler1?
[05:34] <pitti> dholbach: no, I haven't, and I'm just scratching my quota with kdegraphics
[05:34] <pitti> dholbach: can you do abiword?
[05:34] <dholbach> pitti: ok, I'll poke at it
[05:34] <pitti> dholbach: it's all Seb's fault anyway, he broke the API with the poppler upload :)
[05:36] <ogra> hey, cant you go to the hug room ? 
[05:36] <Kamion> infinity: sorted by source or binary?
[05:36] <seb128> dholbach: I doubt that will fix the FTBFS
[05:36] <Kamion> jordi: http://wiki.ubuntu.com/UbuntuMainInclusionQueue; pitti reviews main inclusion requests
[05:36] <dholbach> seb128: I'll be happy to try :)
[05:36] <jordi> Kamion: thanks
[05:36] <seb128> dholbach: that's an argument change, I have difficulties to get how it'll fix an API change
[05:37] <seb128> dholbach: especially it's not even a data type change
[05:37] <infinity> Kamion: Source would be ideal, same as _probs.html
[05:37] <dholbach> it's an additional argument
[05:38] <bddebian> w00t, fucking w00t, dput worked...
[05:40] <seb128> dholbach: good :)
[05:40] <dholbach> seb128: good?
[05:41] <seb128> dholbach: if it fixes the issue that's good no?
[05:41] <dholbach> I'm quite sure it does... I tried something with abiword before (get an dbg build on amd64 where I needed the patch too)
[05:41] <dholbach> i'll run it through pbuilder so I'll soon know for sure
[05:42] <seb128> dholbach: I looked quickly on the patch, I though it was just changing a true but a false
[05:42] <seb128> dholbach: the CVS commit is misleading
[05:42] <Kamion> infinity: done
[05:42] <seb128> dholbach: it says it's a change for poppler 0.5.0, where the API change is poppler 0.5.1
[05:42] <dholbach> we'll see
[05:43] <Kamion> yeah, definitely easier to read, that
[05:43] <infinity> Kamion: Spiffy, that seems immediately much more useful to me.  Thanks.
[05:46] <seb128> Kamion: got my "enchant" UVF mail?
[05:46] <Kamion> seb128: yeah, but haven't been looking at UVF exceptions today
[05:47] <seb128> Kamion: k, this one is trivial ("7 insertions(+), 12 deletions(-)")  if you want to approve it :) 
[05:49] <dholbach> mvo: pitti wondered that too today
[05:49] <pitti> mvo: me too
[05:49] <mvo> pbuilder builds are no fun currently
[05:50] <pitti> mvo: I noticed it during jigdo
[05:50] <No1Viking> What to do if  sudo dpkg-reconfigure locales aint working as before? I would like to change so I can use my special characters and UTF-8 in file names.
[05:50] <pitti> mvo: copying my iso to an iso.old basically locks my machine now
[05:51] <pitti> BenC: did you recently change anything in the kernel that made reponsiveness during high I/O load drastically worse?
[05:51] <dholbach> No1Viking: you could use language-selector
[05:51] <BenC> nothing recently changed that would do that, that I am aware of
[05:52] <dholbach> pitti, mvo: you guys have been working too long again
[05:52] <Kamion> No1Viking: or run locale-gen
[05:52] <No1Viking> Thanks guys!  :)
[05:52] <pitti> BenC: hmm, I never noticed my machine blocking while copying big files like iso images
[05:53] <pitti> BenC: anyway, thanks
[05:53] <BenC> ok
[05:53] <pitti> BenC: who else can we blame? iz gtk bug?
[05:53] <BenC> pitti: could be any number of things...does it block when you use cp?
[05:54] <pitti> BenC: yes, that's what I'm using
[05:54] <pitti> BenC: (that was just bitching, I don't use gnome stuff in my CD update scripts)
[05:54] <BenC> ppc, i386, ...?
[05:54] <pitti> BenC: and I notice it during other heavy I/O operations, too
[05:54] <pitti> amd64
[05:54] <infinity> BenC: FWIW, I've noticed it too, but just chalked it up to me being impatient.
[05:54] <Kamion> seb128: ok, you have mail
[05:54] <infinity> BenC: -686 here.
[05:54] <BenC> never noticed it myself, even copying some DVD images around
[05:55] <pitti> heh, that makes four paranoid people then
[05:55] <BenC> but I'm on ppc :)
[05:55] <infinity> Does PPC use libata?
[05:55] <BenC> does it cause desktop to be jumpy?
[05:55] <pitti> BenC: not jumpy at all, rather 'frozen'
[05:55] <infinity> BenC: Jumpy is an understatement.
[05:55] <BenC> mine's using powermac-ide
[05:56] <infinity> BenC: It'll just lock the machine hard for a few seconds at a time.
[05:56] <doko> BenC: it's common on amd64, i.e. when unpacking OOo on a stripe array
[05:56] <BenC> that's really odd considering 1000HZ and PREEMPT are supposed to prevent that :)
[05:56] <pitti> BenC: preemt works for I/O, too?
[05:56] <bddebian> _ion: ping?
[05:56] <BenC> I have the big-kernel-lock preemptable aswell
[05:57] <BenC> so yeah, it should preempt i/o aswell
[05:57] <pitti> hm; lemme try on my slow ppc
[05:57] <infinity> BenC: I'd guess libata is our common issue here, and perhaps a preempt bug in libata?
[05:57] <BenC> I have an amd64 and it is using libata, so I can test
[05:57] <seb128> Kamion: thank you :)
[05:58] <pitti> BenC: yep, here it copies around 300 MB without any noticeable responsiveness impact, then it completely locks for 5 seconds
[05:59] <pitti> BenC: and the hard disk 'sounds' different than in earlier times, as if it would transmit larger chunks now
[06:00] <pitti> BenC: right, that doesn't happen at all on my ibook; it remains responsive even though it has a much slower hd and cpu
[06:01] <bddebian> Would anyone happen to know why reprepro is looking for an overrides file?
[06:01] <BenC> I can't reproduce it
[06:02] <BenC> I copied 1.5Gigs just now, the whole time dragging my firefox window around while it was loading a large graphic page
[06:02] <BenC> only a single split second did it jitter
[06:02] <pitti> BenC: on amd64?
[06:02] <Kinnison> pitti: on your machine where it locks up, what is your dma/irq settings like?
[06:02] <BenC> yeah, Athlon 3700+
[06:03] <pitti>  multcount    =  0 (off)
[06:03] <pitti>  IO_support   =  1 (32-bit)
[06:03] <pitti>  unmaskirq    =  1 (on)
[06:03] <pitti>  using_dma    =  1 (on)
[06:03] <BenC> I am using sata_nv
[06:03] <pitti> Kinnison: AFAICT, that didn't change for ages
[06:03] <Kinnison> multicount zero? yeesh
[06:03] <Kinnison> but that's not to blame
[06:03] <pitti> BenC: I have ordinary IDE disks
[06:04] <BenC> is it on a libata bus though?
[06:04] <pitti> BenC: I have libata and sata_nv modules loaded as well; my mb has a sata controller, but there's nothing attached to it
[06:04] <pitti> BenC: how do I find out?
[06:05] <Kinnison> WTF?
[06:05] <BenC> is it hda or sda?
[06:05] <pitti> hda
[06:05] <BenC> using normal IDE then
[06:05] <pitti> hdc, precisely
[06:05] <BenC> I can through a normal IDE disk in there later and try again
[06:06] <infinity> BenC: Okay, not libata then (though mine is, ata_piix)
[06:06] <BenC> infinity: is your drive hd or sd?
[06:06] <infinity> BenC: sda
[06:06] <BenC> which controller?
[06:06] <BenC> doh
[06:06] <BenC> piix
[06:07] <infinity> Yes. :)
[06:07] <infinity> ICH6.
[06:07] <pitti> BenC: hm, am I on crack? after rmmod'ing sata_nv and libata, it just works
[06:07] <BenC> pitti: what controller is your IDE (dmesg should say)?
[06:07] <pitti> [   25.045781]  NFORCE3-250: IDE controller at PCI slot 0000:00:08.0
[06:07] <pitti>    25.045897]  NFORCE3-250: 0000:00:08.0 (rev a2) UDMA133 controller
[06:07] <pitti> [   25.045906]      ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
[06:07] <pitti> [   25.045923]      ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
[06:07] <BenC> amd74xx
[06:08] <pitti> amd74xx                16944  0 [permanent] 
[06:08] <jdub> BenC: (should hdparm -i work for libata/sata_sil connected disks?)
[06:08] <Kamion> bddebian: just use /dev/null as the overrides file if you don't want to override any sections or priorities (which to start with you probably won't)
[06:08] <BenC> doesn't seem to for mine
[06:08] <infinity> BenC: Mine's a whacky sata->pata bridge, if that makes a difference (the drive is UDMA133, hanging off the ICH6M sata controller)
[06:09] <BenC> yeah, that's possible, plus I've heard a lot of shitty things about the piix driver, especially the ata_piix one
[06:09] <infinity> Gee, good thing that doesn't ship in a lot of laptops with the "Centrino" logo on them, then..
[06:09] <infinity> Wait...
[06:10] <bddebian> Kamion: Thx, I just got it.  However it just produced the db "stuff", it didn't move any of the binary files..
[06:10] <pitti> BenC: is it even remotely possible that merely removing the module fixes it? or shall I measure again?
[06:10] <BenC> pitti: I'd check again, that would be really odd
[06:11] <Kamion> bddebian: sounds like you're running something that generates indices, not (say) an incoming package queue processor
[06:11] <Kamion> not that I've ever used reprepro
[06:11] <pitti> BenC: ok, will do
[06:11] <Kamion> and you don't want something that generates indices to move files around!
[06:12] <Seveas> I found all existing tools to maintain a simple repository so cumbersome I decided to write my own :) 
[06:12] <bddebian> Hmm, well according to the debian-administration.org it's supposed to create the indices and move the files
[06:14] <pitti> BenC: ok, I still get the lockups without the module
[06:16] <BenC> what kind of drive is it?
[06:17] <BenC> is it really crappy, or a decent drive?
[06:17] <pitti> BenC: about a year old, a 120 GB hard disk
[06:17] <pitti> BenC: not really the cheapest one
[06:17] <BenC> ok
[06:17] <pitti> SAMSUNG SV1604N
[06:18] <pitti> oh, 160 GB, but that shouldn't matter
[06:18] <pitti> BenC: btw, I can reproduce it by continuously doing ls -l on the shell while cp'ing an iso
[06:18] <pitti> BenC: moving ffox window didn't work, probably because it doesn't trigger (enough) I/O
[06:19] <BenC> I'll give that a try too
[06:19] <Pygi> _ion: awake?
[06:20] <bddebian> If he is, he's MINE :-)
[06:20] <Pygi> bddebian: lol
[06:20] <infinity> doko: Do you have any urge to fix up the 3 packages in universe that build-dep on ia32-libs-dev, do it can be safely removed forever?
[06:22] <_ion> bddebian, pygi: Good morning. :-)
[06:22] <_ion> pygi: You got my email?
[06:22] <Pygi> _ion: it's not mornin' ;)
[06:22] <_ion> Well, i woke up. :-)
[06:22] <Pygi> _ion: yup, please read response
[06:23] <_ion> Ah, ok, i looked at my mail server's log  the message's delayed due to graylisting.
[06:23] <Pygi> _ion: ah, so can you see my response or should I send you to private message here?
[06:24] <bddebian> Heya _ion :_)
[06:24] <_ion> pygi: I can't see it until the gmail server tries to resend it. :-) Please /msg it, if you don't mind.
[06:24] <bddebian> _ion: You were using reprepro right?
[06:24] <_ion> bddebian: Yep.
[06:25] <bddebian> _ion: WHen you did reprepro -Vb . include incoming/blah.changes  does it move the .debs for you?
[06:25] <_ion> bddebian: Not move, but copy.
[06:26] <bddebian> _ion: Right.  It's not touching the .debs for me :-(
[06:26] <_ion> bddebian: Oh, actually i haven't tried including some_other_dir/foo.changes, i have always been in the directory where the .changes file is.
[06:26] <_ion> Try (cd incoming && reprepro -Vb .. include foo.changes)
[06:26] <bddebian> Then where is your conf/distributions file?  Underi incoming?
[06:26] <bddebian> Ahh
[06:27] <_ion> Oh, and the syntax is e.g. "include dapper foo.changes"
[06:27] <bddebian> Yeah, got that.  Though I'm also doing *.changes, is that ok?
[06:27] <Pygi> _ion: msg pls
[06:28] <bddebian> Damnit, it's still just building the db entries, not the pool/for/bar stuff :-(
[06:28] <_ion> pygi: Hm, i was a bit unclear in my email. I meant that my modified patch should apply to madwifi-old, i made it against the current l-r-modules source.
[06:29] <Pygi> _ion: o joy, you said -ng ;)
[06:29] <_ion> pygi: The originals were against -ng, but i applied them manually to the -old source.
[06:29] <Pygi> _ion: k, great :)
[06:29] <_ion> And saved _that_ diff to the file in my web page.
[06:30] <_ion> And, as i said, i have absolutely no idea whether it works. ;-)
[06:30] <_ion> It needs to be tested.
[06:30] <Pygi> _ion: perhaps build l-r-m package?
[06:30] <_ion> bddebian: It doesn't seem to be ok, i have done "for f in *.changes; reprepro ... include ... $f"
[06:30] <_ion> pygi: Yeah, one of us should do that. :-)
[06:31] <infinity> Pygi, _ion : I can build a set of LRM packages with that patch for you eight now.
[06:31] <Pygi> infinity: that would be great...thanks ;)
[06:31] <_ion> infinity: That would be very nice, thanks.
[06:31] <infinity> Pygi, _ion : I should have a hot ccache with LRM in it, no big deal.
[06:31] <_ion> The URL is http://johan.kiviniemi.name/tmp/madwifi-robertlove-danwilliams.patch
[06:31] <Pygi> infinity: your help is appreciated ;)
[06:33] <_ion> pygi: Now the e-mail came through. :-)
[06:33] <Pygi> infinity: can you please send it mine and _ion's mail once you build it? ;)
[06:33] <Pygi> _ion: o joy ;)
[06:33] <infinity> Pygi: It won't be that long, I'll just ping you on IRC.
[06:33] <_ion> pygi: Graylisting is a compromise. It decreases the amount of spam that gets through, but also delays some of the incoming "real" messages.
[06:33] <Pygi> infinity: kk
[06:34] <Pygi> _ion: yup, like mine ^^
[06:36] <infinity> _ion: Who do I credit for this patch?
[06:37] <_ion> infinity: Well, Robert Love and Dan Williams are the actual authors, i just modified it a little bit in order to apply to the madwifi-old tree. I don't know whether i should be credited about anything, but if you think so, "Johan Kiviniemi <debian@johan.kiviniemi.name>"
[06:40] <bddebian> _ion: OK, I'm getting closer, any idea on this: ?
[06:40] <bddebian> Data seems not to be signed trying to use directly...
[06:40] <bddebian> Missing file pool/main/b/bash/bash_3.1.orig.tar.gz
[06:40] <bddebian> Does the orig.tar.gz already have to exist?
[06:40] <bddebian> Or can I get dput to dump up the orig.tar.gz too?
[06:40] <_ion> bddebian: For the source package, yes.
[06:40] <_ion> You need foo.dsc, foo.orig.tar.gz and foo.diff.gz
[06:41] <_ion> And for reprepro's "include" command, the changes file.
[06:41] <bddebian> _ion: You mean I have to have all that ahead of time?
[06:42] <_ion> bddebian: Ahead of time?
[06:42] <bddebian> _ion: They must already exist in pool/main/b/bash/ ?
[06:42] <_ion> bddebian: Btw., instead of always giving the "-b path" parameters to reprepro, i have 'export REPREPRO_BASE_DIR="${HOME}/src/apt-repository"' in my shell's startup script.
[06:43] <bddebian> _ion: Well I am going to cron a script at some poin, I just want to get it working first :-)
[06:43] <_ion> http://archive.ubuntu.com/ubuntu/pool/main/b/bash/bash_3.1.orig.tar.gz
[06:43] <infinity> bddebian: When uploading a package with no orig, you should build with "-sa", so it gets in the .changes.
[06:44] <bddebian> infinity: Ahh, thx.
[06:45] <infinity> (Next upload, of course, you won't have to, cause the orig is already in the repo)
[06:47] <pitti> dholbach: were you lucky with abiword? It seems I finally managed to port kdegraphics
[06:48] <Riddell> pitti: what's this being ported?
[06:48] <pitti> Riddell: new poppler API
[06:48] <dholbach> pitti: just finshed building :)
[06:48] <pitti> Riddell: soname 0 to 1
[06:48] <Riddell> aah
[06:49] <dholbach> pitti: uploading
[06:49] <Riddell> what does abiword do with poppler?
[06:49] <dholbach> Riddell: pdf imp/exp (juding by the filename) ;)
[06:49] <Pygi> _ion: I have to go now...please send me package once it's done,...also, we won't release just yet...I'll get madwifi card..ok?
[06:50] <_ion> pygi: Naturally, it will be tested a lot before releasing. :-)
[06:50] <Riddell> pitti: by the way kpdf in KDE 4 has been ported to poppler so seems like the kpdf authors resolved their differences with the other poppler developers
[06:50] <pitti> yay, cool
[06:50] <_ion> pygi: Some people at this chan promised to test the package.
[06:50] <pitti> Riddell: any hope for kword
[06:50] <infinity> _ion: uploading packages to pepole.u.c right now...
[06:50] <pitti> ?
[06:50] <Pygi> _ion: yup, great ofcourse ;)
[06:50] <infinity> . o O (pepole?)
[06:51] <Pygi> hehe :)
[06:51] <pitti> peephole?
[06:51] <Riddell> pitti: that's still being planned for, but the kpdf author was having problems last I heard
[06:51] <pitti> Riddell: I thought kpdf was solved?
[06:51] <Riddell> pitti: yes, but the kpdf guy was going/is going to do the kword port too
[07:07] <infinity> _ion, Pygi :
[07:07] <infinity> deb     http://people.ubuntu.com/~adconrad/networkmanager-lrm/ ./
[07:07] <infinity> deb-src http://people.ubuntu.com/~adconrad/networkmanager-lrm/ ./
[07:07] <_ion> infinity: Thanks a lot!
[07:07] <infinity> NP.
[07:10] <Seveas> aight
[07:11] <_ion> Anyone else with a madwifi card?
[07:11] <_ion> Oh, hi. :-)
[07:11] <Burgwork> _ion, yes
[07:12] <Seveas> _ion, we're gonna need a new NM to test it 
[07:12] <Seveas> (with the workaround patches applied)
[07:12] <_ion> So let me see... One needs the network-manager 0.6 package from http://johan.kiviniemi.name/ubuntu/ , the wpasupplicant 0.4 package at http://siretart.tauware.de/wpasupplicant/ and the l-r-m package from infinity.
[07:12] <_ion> If we're very lucky, WPA _might_ work with that combination. ;-)
[07:13] <Seveas> _ion, if those nm packages have that patch it may just work ;)
[07:14] <_ion> seveas: Hm. Is http://mail.gnome.org/archives/networkmanager-list/2006-February/msg00081.html needed? I might have misunderstood your answer the last time (i'm not native English speaker). :-)
[07:15] <Seveas> there is a patch that supersedes this one
[07:16] <Seveas> http://mail.gnome.org/archives/networkmanager-list/2006-March/msg00068.html
[07:16] <Seveas> that one
[07:16] <bddebian> Fucking A skippy
[07:17] <_ion> seveas: Okay, thanks. I'll apply that to my package immediately.
[07:17] <Seveas> bddebian, I assume you've got something working? I must say i'm glad I didn't help ;)
[07:17] <bddebian> Seveas: :-)
[07:21] <bddebian> _ion: Does reprero update Packagages.gz too or do I still need to do something like dpkg-scanpackages?
[07:21] <bddebian> Packagages.. Heh
[07:21] <_ion> bddebian: It does everything that is needed when you "include foo bar.changes".
[07:22] <bddebian> kick ass, thanks again!
[07:39] <_ion> seveas: The patch didn't apply cleanly to 0.6.1, i had to apply it manually. I'm building the package now.
[07:40] <Seveas> ah cool, you moved to 0.6.1 already
[07:40] <_ion> ?
[07:40] <_ion> My package was 0.6.1 from the beginning.
[07:50] <siretart> _ion: hi
[07:50] <_ion> siretart: Hi
[07:50] <siretart> _ion: whats special about infinity's l-r-m package? (sorry, I didn't follow this channel)
[07:51] <_ion> It contains these two patches: http://mail.gnome.org/archives/networkmanager-list/2006-March/msg00134.html http://mail.gnome.org/archives/networkmanager-list/2006-February/msg00005.html
[07:51] <_ion> (backported for madwifi-old)
[07:52] <shaya> join #latex
[07:52] <shaya> argh
[07:52] <siretart> _ion: dies the new l-r-m package include madwifi-ng?
[07:52] <_ion> siretart: No.
[07:52] <siretart> ok
[07:53] <_ion> Here's the backported patch i came up with, this is what has been applied to infinity's package: http://johan.kiviniemi.name/tmp/madwifi-robertlove-danwilliams.patch
[07:54] <sabdfl> jdub: ping
[08:10] <dotwaffle> If I have to mkinitrd once more with dapper, I think I am actually going to scream...
[08:10] <Kamion> mkinitr*d*?
[08:10] <zul> welcome to the jungle..
[08:11] <dotwaffle> Kamion: There are plenty of bug reports out there... The dapper 2.6.15-* kernels don't appear to have a valid initrd for a lot of machines. I know this isnt' tha place to discuss this, so I'll just grunt quietly in the corner ;)
[08:12] <infinity> dotwaffle: The place to discuss it is to file a bug on initramfs-tools telling me which module(s) your machine needs to boot that I'm not including.
[08:12] <infinity> dotwaffle: Bug reports "out there" (wherever that is) don't tend to help me much.
[08:13] <Kamion> dotwaffle: well, my point was more that you shouldn't be using mkinitrd at all with 2.6.15
[08:13] <dotwaffle> infinity: I can't work out which module - it doesn't detect _anything_ - I've filed a comment on a pre-existing bug, I'll do a little investigation tonight and update the bug to include all the data I can.
[08:13] <Kamion> if you mean mkinitramfs (or better, update-initramfs), sure
[08:13] <dotwaffle> infinity: tell me about it - the number of times I get bugs for Xen units with "it doesn't work" under something generic annoys me greatly.
[08:14] <dotwaffle> ... didn't know there was an update-initramfs - need to get up to date on these new fangled tools =)
[08:14] <infinity> dotwaffle: Our default initramfs setup doesn't detect anything, it just throws a whole bunch of modules in a fat image and that's what you get.
[08:14] <infinity> dotwaffle: On BOOT, detection galore occurs, but that's udev, not initramfs.
[08:15] <Kamion> dotwaffle: if you're trying to use mkinitrd, that would be your problem. :-)
[08:15] <Kamion> initrd-tools relies on devfs, which is gone
[08:15] <dotwaffle> infinity: briefly (not to clog up the channel) when the kernel is updated, it will not boot, it gets an alert. To fix, you boot into an old kernel, then do "mkinitrd -o blah bleh" and it works. I've not tried initramfs, I'll give it a go.
[08:16] <dotwaffle> Kamion: ah, ok.
[08:16] <dotwaffle> infinity + Kamion: https://launchpad.net/distros/ubuntu/+source/initramfs-tools/+bug/32123
[08:16] <Ubugtu> malone bug 32123 in initramfs-tools "Cannot find ide hard disk on boot" [Major,Confirmed]  
[08:16] <dotwaffle> beat you to it ;)
[08:18] <dotwaffle> let me know if you need anymore info - I'm watching the bug.
[08:18] <_ion> seveas: Okay, the package in my repo has the patch. Also siretart's wpasupplicant is there.
[08:18] <infinity> Oh, right, the 4 bugs in one bug bug.
[08:19] <dotwaffle> i'm new to udev, so i'll have to play around with it, see what's causing the modules not to appear...
[08:19] <infinity> dotwaffle: Can you produce one of these broken initramfs images on demand?
[08:19] <infinity> dotwaffle: If so, I'd love a copy of one.
[08:19] <dotwaffle> infinity: I'll get you one as soon as it next breaks ;)
[08:20] <infinity> dotwaffle: Thanks.
[08:20] <infinity> dotwaffle: Bug reports like these are (unfortunately) painfully vague without something tangible to tear apart and examine.
[08:55] <_ion> seveas: Are there still some patches that should be applied?
[08:56] <Seveas> _ion, didn't test yet (kinda need my connection at this moment)
[08:56] <dholbach> bye
[08:57] <sebest> hello, i'm testing dapper flight 5, but partman isn't starting
[08:57] <sebest> what should i report to make a good bug report
[08:57] <Seveas> that partman doesn't start ;)
[08:57] <Seveas> (and the specifics of your disks)
[08:58] <Mithrandir> sebest: using debian-installer or espresso?
[08:58] <sebest> Mithrandir using the debian-installer
[08:58] <sebest> the strange thing is that it is working with debian
[08:58] <Mithrandir> sebest: file a bug against partman attaching /var/log/syslog
[08:58] <sebest> with breezy i mean
[08:59] <sebest> looking at this file i see nothing unusual
[09:00] <sebest> the scsi controller is found and the harddisk and cdrom too
[09:00] <sebest> my previous installation with breezy was using LVM
[09:01] <sebest> and the last message from partman is that it found the volume group "Ubuntu"
[09:01] <sebest> but the screen stay blue and empty
[09:02] <_ion> Blue screen.  :-)
[09:02] <sebest> Mithrandir : how could i attach /var/log/syslog, i don't have easy way to copy the file, no ssh client or server
[09:02] <Mithrandir> sebest: install openssh-client-udeb
[09:13] <sebest> it seems that partman was confused by my external usb hard drive
[09:20] <Mithrandir> sebest: it should handle USB drives just fine.  Dapper supports installing to those just fine.
[09:26] <Kamion> sebest: you don't need to google for it - just 'anna-install openssh-client-udeb'
[09:26] <Kamion> then you have scp
[09:26] <Kamion> or "save debug logs" from the installer main menu
[09:28] <palong> I can't seem to find where the desicion is made when update-notifier tells the user to reboot. I found the script setting /var/run/reboot-required in the update-notifier sources but I can't figure out when it is called from where. Any hints?
[09:29] <_ion> Probably from the postinstall scripts.
[09:29] <wasabi> It's called from each package that needs it, probably.
[09:29] <wasabi> they probably just touch the file.
[09:30] <_ion> Confirmed, grep reboot-required /var/lib/dpkg/info/*.postinst
[09:30] <palong> hm, so there is no way of telling which package is responsible for creating the file afterwards?
[09:31] <palong> I was thinking of adding this information to update-notifier
[09:32] <palong> s/no way/no easy way/ :)
[09:33] <sebest> thanx Kamion, i solved my issue
[09:33] <wasabi> palong: For what purpose?
[09:34] <sebest> Mithrandir, i think that partman just took a lot of time to display the UI, and when i swtich to the other tty to see debug message, and switch back to debian-installer the framebuffer didn't accept anymore my input keys
[09:34] <palong> wasabi: I am often wondering myself if I agree with the desicion that a reboot is indeed necessary. I thought always knowing which upgrade produced the message would help me make that desicion
[09:35] <_ion> palong: IMO that would be quite nice. Maybe something like this: notify-reboot-required is ran without parameters  just touch the reboot-required file if /var/run is tmpfs. notify-reboot-required with the package name as a parameter: echo "$1" >> /var/run/reboot-required if /var/run is tmpfs. The notifier then shows the list from the file.
[09:36] <wasabi> palong: I suspect the only reason it makes the message is if the kernel, hal, or dbus are updated.
[09:36] <wasabi> or udev.
[09:36] <palong> _ion: but then all the package's postinst scripts would need modification to call the script with the parameter, no?
[09:36] <wasabi> Maybe udev.
[09:36] <wasabi> Probably not
[09:37] <wasabi> Oh, looks like there's more than that now.
[09:37] <wasabi> But not much. initscripts, ifupdown.
[09:38] <palong> wasabi: yeah. and if, for example, ifupdown was the cause, I would know, that I don't want to reboot right away, while, if the kernel was it, a reboot might be more important to me.
[09:38] <palong> wasabi: I know I am probably being a bit pedantic here :)
[09:38] <_ion> Maybe we should go towards the way Windows works. Just make apt run notify-reboot-required automatically after any install/upgrade operation.
[09:39] <palong> :)
[09:39] <lfittl> BenC: ping
[09:39] <trappist> and run fam on /etc and beg for a reboot if anything there changes
[09:42] <mroth> sladen: around?
[09:43] <palong> ok, well, I think I give up, thanks for your kind help.
[09:46] <sladen> mroth: ack
[09:46] <Kyral> So D-Day is now in June?
[09:47] <sladen> Kyral: 2006-06-01
[09:48] <Kyral> sladen, ty
[09:48] <sladen> missed opportunity to make it  6.6.6 
[09:48] <BenC> lfittl: pong
[09:48] <sladen> that would be such a rocking release date
[09:48] <lfittl> BenC: when do you plan to upload the 2.6.15-19.28 kernel image?
[09:48] <BenC> lfittl: tonight
[09:48] <Kyral> then make it available online lol
[09:48] <lfittl> BenC: perfect, thanks :)
[09:48] <mroth> sladen: wanted to get clarification from you on some of the kotkey-setup stuff you wanted me to file re: thinkpad x60
[09:48] <sladen> Kyral: you still can;  add them to launchpad
[09:49] <Kyral> "If you are too lazy to remember all the dates, just download this iCal file and import it into your favorite Calandar app" :P
[09:49] <Kyral> sladen, but does LP allow you to save it :P
[09:49] <mroth> sladen: for the hotkey-setup bug, which key presses do you want the showkey output from?
[09:50] <sladen> mroth: yup, can you drop to a console with ctrl-alt-f1 and check what the new fn+(top row) sequences produce.with  'sudo showkey -u'
[09:51] <sladen> Kyral: you're right, LP maybe be cunningly write-only.  Ask on #launchpad and file a but if you can't export it
[09:52] <mroth> sladen: entire row?  ok, will do.  and for the acpi-support one, just file as "Fn-F3 is now Battery Not Lock" and include those dmidecode variables?
[09:53] <sladen> mroth: the Fn+F1-F12 come via ACPI events
[09:53] <sladen> mroth: it's those new ones (you were having trouble sending  Alt-SysRq and wondering if the Fn-SysRq is actually escaped)
[09:54] <mroth> sladen: ok, just trying to figure out what you actually want me to file :-)
[09:54] <sladen> mroth: SysRq, NumLk and Break;  eg. NumLck used to be accessed via  Shift-NumLock  on the IBM ThinkPads
[09:55] <mroth> sladen: so you want the showkey for SysRq NumLk and Break on the acpi-support bug
[09:57] <mroth> sladen: filed the acpi-support in #35395, let me know what to add to it.   going to work on getting the showkey values for the hotkey-setup one now
[09:58] <hunger> Is language-selector giving a traceback on upgrade a known problem?
[09:59] <jcole> how do i get vnc-java to work with vino? i used to use the X vnc module, but that doesn't seem to work in ubuntu
[10:00] <sladen> Ubugtu: why didn't you pickup #35395, ?
[10:00] <sladen> Ubugtu: why didn't you pickup #35395 , ?
[10:00] <hunger> Why is fontconfig needed on a no-gui system? I assume it is pulled in by cups somehow?
[10:01] <sladen> Seveas: Ubugtu didn't seem to see the above bug number and turn it into a nice URL
[10:01] <LaserJock> sladen: go easy on the poor fella ;-)
[10:01] <sladen> LaserJock: yeah, I wondering if the regex required a space after, rather than a comma
[10:01] <Seveas> sladen, why would it?
[10:02] <Seveas> it needs 'bug'|trackername (bug')?
[10:02] <Seveas> (pseudo-regex style)
[10:02] <sladen> Seveas: ah, so bug #35395
[10:02] <Seveas> bug #35395, #35394
[10:02] <Ubugtu> Malone bug 35395 in acpi-support "Changed Keyboard Layout on new Thinkpad models" [Normal,Unconfirmed]  http://launchpad.net/bugs/35395
[10:02] <Seveas> -Ubugtu- Error: This bug is private
[10:03] <Seveas> (for 94)
[10:03] <mroth> sladen: hotkey-setup as bug #35396
[10:03] <Ubugtu> Malone bug 35396 in hotkey-setup "New Keyboard Layout in Thinkpad X60 Series" [Normal,Unconfirmed]  http://launchpad.net/bugs/35396
[10:04] <Seveas> sladen, I doubt that matching #\d+ without preceding bug/trackername would be useful
[10:06] <jdub> hunger: it's used by various command line programs that use fonts (image rendering libs, document creation tools, etc)
[10:06] <sladen> Seveas: nod, ta.  I wondering about automatching the same string in the wiki rather than requiring  [https://launchpad.net/bugs/1234 #1234]  everytime
[10:07] <Seveas> sladen, that would be doable
[10:08] <Seveas> something like s!bug:#?\d+!http://launchpad.net/bugs/\1!
[10:08] <Seveas> should be easy to work out for a moin guru
[10:09] <sladen> mroth: you can use  sudo showkey -u | tee -a thinkpad-x60s-keys.log  to make things easier
[10:13] <mroth> sladen: hrm, even with showkey running, it seems to like to hibernate on me when I hit Fn-F12, which is what i'm looking into right now
[10:14] <mroth> and since it cant properly wake up from hibernate, that gets complicated to test ;-)
[10:14] <sladen> mroth: that sends an ACPI even, you can ignore those since we know what they are
[10:15] <mroth>  sladen ah, so you want... which ones?  most of them seem to send ACPI events, and not showkeys
[10:15] <sladen> mroth: But I am interested whether oddities like  Fn-Ins  Fn-Backspace  Fn-Delete still generate events  (but only for my own personal curiousity)
[10:15] <sebest> is there any hope that apple keyboard will be supported on ubuntu i386 ?
[10:16] <jcole> does ubuntu's vino have java support?
[10:16] <sladen> mroth: the combinations marked  SysRq, NumLock, Break, Fn-Left/Right/Up/Down
[10:16] <jcole> "sudo apt-get install vnc-java" makes vncserver work, but not vino
[10:17] <sladen> sebest: yes, should work out of the box.  Please ask on #ubuntu
[10:17] <sebest> sladen: i know how to get it working, but i'd like it to work out of box
[10:18] <sladen> sebest: please file a bug report with the sequence that you had to use to get it to work
[10:18] <sebest> sladen: i just installed dapper flight 5 and it doesn't work "out of box" , i suspect it is because my locale is french
[10:18] <jcole> i usually use a stunnel wrapper around vnc java so i can it access via browser encrypted
[10:18] <jcole> https
[10:18] <sebest> sladen: what do you mean by "sequence" ?
[10:19] <sladen> sebest: the set of operations.  The list of commands that you had to use to configure the Apple keyboard to work correctly.  This is so that that list of commands can be automated.
[10:20] <sebest> sladen: ok, but i must download a separated package to have the right keymap
[10:20] <jcole> in conjunction with the /usr/X11R6/lib/modules/extensions/vnc.so module... which is borked in ubuntu for some reason
[10:20] <sladen> sebest: please include that Link aswell
[10:20] <sebest> sladen, ok will do right now
[10:20] <sebest> sladen thanx
[10:21] <sladen> jcole: run  dpkg -S /usr/X11R6/lib/modules/extensions/vnc.so  and file the bug against whichever package it belongs to
[10:23] <mroth> sladen: so far the only things with Fn blue text that appear to produce showkeys events are: SysRq, NumLk, Break, and the start/stop/play/pause keys mapped to the arrow keys
[10:23] <jcole> sladen: there's already a bug report, vnc4server is in universe so who knows if it'll get fixed... i was however the ubuntu way of doing vnc java... ubuntu's "Remote Desktop" uses vino, but i can't figure out how to add java support to it
[10:23] <sladen> mroth: and tapping and releasing  Fn  without pressing anthing else?
[10:24] <jcole> s/i was//g
[10:24] <mroth> sladen: yes, that produces a code too
[10:25] <sladen> mroth: Do the volume/ThinkPad/Fn-Space/Brightness keys still go via nvram or via a keystroke?
[10:25] <sladen> mroth: (do  sudo killall thinkpad-keys  first)
[10:26] <sladen> mroth: btw, thank you for following this up interactively!  Makes it alot easier to catch everything in one go
[10:27] <mroth> sladen: I have no thinkpad-keys process running (and have never noticed one before).  nope, the volumne, thinkpad, etc don't generate showkeys, so my assumption is nvram?
[10:27] <sladen> mroth: back and forward  should send keycodes too
[10:28] <mroth> sladen: yep, documenting them all now
[10:28] <sladen> mroth: groovy! :)
[10:29] <jcole> sladen: i'll just hack together another vnc ssl solution
[10:30] <sladen> jcole: to server up the java-binary you'll need a mini-webserver running I guess?
[10:31] <jcole> sladen: vnc-java does that
[10:31] <jcole> sladen: but it needs to tie in with vnc4server
[10:31] <jcole> sladen: i don't know how to make vino work with it
[10:32] <jcole> sladen: also, i don't know how to make the ubuntu vino work with the gdm login screen
[10:34] <jcole> sladen: i think vino is more for simple things like sharing and not for administrating
[10:34] <jcole> bingo!
[10:35] <jcole> it works now
[10:35] <jcole> heh
[10:39] <_ion> seveas: Have you been able to test the packages yet?
[10:39] <Seveas> _ion, no, I've been working on more important things 
[10:39] <_ion> Ok.
[10:43] <jcole> dang, doesn't work
[10:43] <jcole> nm
[10:43] <jcole> jcole@jcubuntu-p4smp:~$ vncserver
[10:43] <jcole> Found /usr/share/vnc-java for http connections.
[10:44] <jcole> i think vncserver (vnc4server) embeds the jvncviewer applet (vnc-java) in a mini webserver
[10:45] <jcole> who knows, it's a friday... forget it, i'm done for now :)... later all
[11:45] <carlos> simira: hi, around?
[11:50] <simira> carlos: on my way off, but I can hold a minute or two for you
[11:50] <carlos> simira: thanks. It should be fast
[11:50] <carlos> simira: https://launchpad.net/rosetta/imports/?status=NEEDS_REVIEW&type=po
[11:51] <carlos> simira: what should I do with those no.po files?
[11:51] <carlos> import them, import them as nb.po ? as nn.po? ignore?
[11:51] <carlos> simira: we are importing now Dapper
[11:51] <carlos> and we are able to block those files from being imported
[11:53] <simira> carlos: ah, great. Can you rename them to nb.po?
[11:53] <simira> carlos: great timing, btw, I'm clearing out Ubuntu issues tonight. :)
[11:53] <carlos> simira: well, more than rename, I can import them as nb
[11:54] <carlos> simira: but what will happen with nb translations?
[11:54] <carlos> are they exactly the same?
[11:54] <simira> carlos: yes
[11:54] <simira> they should be, at least
[11:54] <carlos> hmm, then perhaps is better that we just ignore those no.po files
[11:55] <carlos> as will not be lost because the nb.po files will be imported as usual
[11:56] <simira> carlos: as long as there's nb.po-files, that would be ok, yes
[11:56] <carlos> simira: ok, blocking the files mean that they will stay on the import queue for ever
[11:56] <carlos> simira: with the 'blocked' status set
[11:57] <carlos> if you miss anyone, you can always ask for a change on that entry and we will import that no.po file as nb.po
[11:57] <carlos> does it works for you?
[11:57] <simira> carlos: you can probably throw them away. Do you have any option to import the newer one of nb.po/no.po?
[11:57] <simira> else, that works fine, yes
[11:57] <carlos> well, yes, but sometimes, implies some extra work on our side
[11:58] <carlos> we can try importing the no.po as nb.po and if it adds too much work to us then move to the blocking procedure I just told you about
[11:58] <simira> ok. Just have the nb ones then
[11:58] <carlos> ;-)
[11:59] <simira> sure, that's great. I'm happy to get rid of no :p
[11:59] <carlos> we are not able to agree :-P
[11:59] <carlos> I will try to get rid of any other no pofile we already imported by mistake on dapper so we can tag dapper as a 'no' free zone
[11:59] <carlos> ok?
[12:00] <simira> carlos: you're an angel if you manage that. I won't crucify you for any no that would happen to show up, I promise
[12:00] <carlos> simira: ;-)
[12:00] <carlos> simira: feel free to file bug reports if you find anyone
[12:01] <carlos> but give me a couple of weeks to clean up the system ;-)
[12:01] <simira> carlos: I'll have a look on it. You're doing great work anyway. I'll come bother you at the next conference, whenever that is...
[12:01] <carlos> ;-)
[12:01] <carlos> I take your word