[12:03] <AlinuxOS> hello someone Armenian user here?
[12:03] <AlinuxOS> or font package mantainer ?
[12:28] <nickrud> does anyone know the proper syntax to use in /etc/apt/preferences for pinning according to release? (hoary, breezy, dapper)
[12:29] <LaserJock> nickrud: I think the Debian Apt HowTo has that information
[12:31] <nickrud> LaserJock, the Releases file for debian and ubuntu are not the same, and my mediocre attempts at reconciling them have failed
[12:32] <LaserJock> nickrud: have you tried https://wiki.ubuntu.com/PinningHowto ?
[12:33] <nickrud> LaserJock, thanks, component from that link may help me get where I need to be
[12:34] <LaserJock> np, hope it helps
[12:37] <nickrud> argh, no, it does not. Why, oh why, did ubuntu go so non-standard?
[12:47] <Kamion> nickrud: we've changed nothing about the Release file syntax
[12:47] <Kamion> nickrud: what are you trying?
[12:48] <Kamion> (not that I use pinning myself, so I may only be of limited help)
[12:49] <nickrud> Kamion, I'm trying (as an exercise, for fun, and all that) a downgrade on a dapper box. In debian, I'd pin to sarge, to downgrade a sid. I've not found an equivalent syntax
[12:49] <Kamion> yes, what syntax are you using I mean
[12:50] <nickrud> I was hoping for a quick, "oh, I know that :)" A second, Kamion, while I pull up some refs
[12:51] <Kamion> I'd expect "Pin: release a=breezy"
[12:55] <nickrud> Kamion, I'll try that; comparing the Release files, Suite or Codename is what I'd expect, and no, release a=breezy didn't do it
[12:56] <nickrud> hm, I'll try lowercase breezy
[12:58] <Kamion> from the code it appears to be case-insensitive
[12:59] <Kamion> there's no facility in apt for matching on Codename as far as I'm aware; Suite maps to a=
[12:59] <Kamion> (the former in the Release file, the latter in pins)
[12:59] <nickrud> thank you
[12:59] <Kamion> documentation's confusing, I had to grovel through the source
[12:59] <nickrud> double thank you :)
[12:59] <Kamion> it talks about Archive, which I suspect was an old name for Suite
[01:00] <Kamion> if that doesn't work, might be worth looking at 'apt-cache policy' output for various packages to see what it's finding
[01:00] <Kamion> that should tell you the pin priorities
[01:02] <nickrud> Yes, that probably will get me there. It's just that I'm very cautious about things; for example ubuntu has a Version in the Release file, and Debian did not. That scares me :)\
[01:03] <Kamion> Version maps to v= in pins
[01:04] <Kamion> nickrud: Debian certainly does have Version in Release files, just only for released versions
[01:04] <Kamion> because the version number doesn't get assigned until not that long before release in Debian; whereas we have a predefined version numbering scheme so we know it in advance
[01:05] <Kamion> $ grep Version ftp/dists/sarge/Release
[01:05] <Kamion> Version: 3.1r1
[01:05] <Kamion> you can use v=5.10 if you like for breezy, should be equivalent
[01:06] <Kamion> breezy-updates will be a=breezy-updates or v=5.10
[01:07] <nickrud> but the version is not recorded in the Release File: aias: ~ $ head /var/lib/apt/lists/ftp.us.debian.org_debian_dists_testing_Release
[01:07] <nickrud> Origin: Debian
[01:07] <nickrud> Label: Debian
[01:07] <nickrud> Suite: testing
[01:07] <nickrud> Codename: etch
[01:07] <nickrud> Date: Wed, 25 Jan 2006 21:47:06 UTC
[01:07] <nickrud> Architectures: alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc
[01:07] <nickrud> Components: main contrib non-free
[01:07] <nickrud> Description: Debian Testing distribution - Not Released
[01:07] <Kamion> so I guess that does mean there's a slight difference in semantics between a=breezy and v=5.10
[01:07] <nickrud> yes
[01:07] <Kamion> nickrud: testing isn't released and doesn't have a version number yet.
[01:07] <nickrud> ah
[01:07] <nickrud> :)
[01:07] <Kamion> sarge does have a Version in its Release file.
[01:08] <Kamion> (as I showed above)
[01:08] <nickrud> Kamion, thanks, you've given me some paths to explore. thanks
[01:08] <Kamion> np
[01:08] <Kamion> the grep above was on ftp-master.debian.org, btw, so is canonical :)
[01:08] <nickrud> god, I do love that word. It is so ambiguous
[01:09] <Kamion> yep, good innit
[01:09] <jsgotangco> good morning
[01:53] <jordi> how do I find out what font is providing me with a UTF-8 character?
[02:23] <wasabi_> I like the Restart Required systray icon.
[02:40] <Riddell> lamont: when uploading kdebase I get Uploading via ftp kdebase_3.5.1.orig.tar.gz: Error '(110, 'Connection timed out')' during ftp transfer of kdebase_3.5.1.orig.tar.gz
[02:40] <Riddell> is that likely to be my fault or the buildds?
[02:40] <Kamion> source uploads have nothing to do with the buildds
[02:41] <Riddell> good point
[02:42] <Kamion> -rw-r--r--  1 poppy katie 28121368 Jan 27 00:54 kdebase_3.5.1.orig.tar.gz
[02:42] <Kamion> is that the right size, or too small?
[02:42] <Riddell> 28121368 it is
[02:43] <Kamion> you could try uploading just the .changes then; the rest of the files seem to be in unchecked
[02:43] <Kamion> dunno if poppy will let you do that
[02:43] <Kamion> I don't know why it put an upload without a .changes in unchecked in the first place; strikes me as a bug
[02:45] <floam> hm.
[02:46] <floam> anyone notice that sense ubuntu changed the fileselectors default directory to ~/Documents that epiphany fails to respect your set download directory?
[02:46] <floam> it always defaults to Documents now even if you've got it set to some other directory in ephys UI. (I'm hoping this isn't intentional)
[04:48] <dabaR> So, did you guys know that there seems to be a bug in the download manager for firefox in breezy? Fx crashes when you have the download manager open, and when you do not, it does not crash.
[04:53] <dilinger> ugh.  hate the new xchat in dapper.
[04:55] <psusi> it has some strange default layout doesn't it?
[04:56] <Burgundavia> psusi, dilinger bug the xchat-gnome people in #xchat-gnome on freenode
[04:56] <LaserJock> the only thing I don't like about it is the user list. They obviously thought that nobody cared about how they chat with ;-)
[04:56] <psusi> it isn't xchat... it's the profile or something... I'm running dapper on my desktop and my xchat still looks sane
[04:57] <psusi> so it's got to be some default config file setting that got changed in the ubuntu package
[04:57] <jdub> it's a totall different project
[04:57] <Burgundavia> psusi, it is xchat-gnome, a fork of xchat
[04:57] <jdub> vastly forked
[04:57] <psusi> ohhh
[04:57] <jdub> and, well, needing more love
[04:57] <Burgundavia> indeed
[04:58] <psusi> so.... it's like ubuntu-desktop depends on either xchat or xchat-gnome, but xchat-gnome is now prefered?  so I'm still using xchat since I upgraded?
[04:59] <psusi> nevermind... looks like ubuntu-desktop just switched to xchat-gnome completely, but I had removed it at some point probably due to broken depends from the ABI breakage
[05:00] <psusi> why did that change happen?  and can we undo it? ;)
[05:01] <LaserJock> xchat-gnome is supposed to be more integrated. I really don't know what that means other than it maybe looks more like a gnome app?
[05:05] <Burgundavia> LaserJock, it does have sexy spelling checking and handles urls better
[05:06] <psusi> to me it looked like xchat, but with a fubar theme that rearanged everything in eye wrenching positions
[05:06] <psusi> url handling is one thing I don't like about xchat
[05:07] <psusi> oh my god... according to /. 40% of brits believe in creationism over evolution... is the whole world slipping into a new dark age?  I thought it was just the US that was filling up with retards?
[05:08] <jsgotangco> :/
[05:08] <LaserJock> psusi: well, I don't want to get into it but I'm one of the retards your talking about
[05:08] <psusi> you're kidding?  you don't believe that evolution of the species takes place?
[05:09] <bddebian> LaserJock: Me too ;-)
[05:09] <LaserJock> psusi: umm, not in the sense that most people think of it no
[05:09] <psusi> it's like saying the sky is blue because picaso painted it or something... not because it's filled with water dropplets
[05:09] <bddebian> psusi: creationism and evolution are not necessarily mutually exclusive
[05:09] <jsgotangco> yeah
[05:09] <psusi> true... I'm talking about the people who believe they are though
[05:10] <bddebian> Well there are extremists everywhere :-)
[05:10] <jsgotangco> irregardless of religious belief
[05:10] <psusi> i.e. literally believe that humans were plopped down on the earth by some magical man in the sky rather than evolving over millenia from lesser beings
[05:10] <LaserJock> that would be me to a large extent ;-)
[05:10] <bddebian> It's like pro-lifers that kill abortion doctors ;-P
[05:10] <Burgundavia> guys, this is horribly offtopic
[05:10] <psusi> that's some delicous irony right there
[05:10] <jsgotangco> yeah
[05:10] <bddebian> True, sorry
[05:10] <Burgundavia> please take it to #ubuntu-offtopic
[05:10] <psusi> hehe
[05:11] <jsgotangco> i'd rather not talk about it really
[05:11] <jsgotangco> its something private
[05:12] <Burgundavia> jsgotangco, why are you not in -doc?
[05:12] <psusi> Mithrandir, ping
[05:12] <jsgotangco> ekk
[05:12] <jsgotangco> im in a new client and i forgot
[05:13] <psusi> Mithrandir, was wondering if there's any news on the e2fsprogs header that was causing dmraid to ftbfs on amd64
[06:00] <dilinger> yea, i was talking about plain old xchat, not xchat-gnome
[06:01] <dilinger> i have some 20 tabs open
[06:01] <dilinger> it used to be, in order to close a tab/window, there was an 'x' up top that you clicked
[06:01] <dilinger> they moved it right next to the slider arrows in the xchat that's in dapper
[06:01] <dilinger> so now i go to slide my tabs around, and accidentally close windows
[06:02] <dilinger> not just one, because in order to slide the tabs you must click multiple times; so i /part 3 or 4 channels before i realize what i'm doing and stop
[06:02] <dilinger> *really* annoying
[06:45] <neuralis> mdz: please review the updated CommunityServerHardwareTesting with the web catalog split out to HardwareTestingCatalog, and approve community-server-hardware-testing if you're satisfied.
[07:22] <ajmitch> evening
[07:43] <poningru> sorry to disturb but can someone confirm that networkmagic was aborted for dapper
[07:43] <ajmitch> no, I know that people have still been working on it
[07:43] <poningru> ok cool thanks
[07:44] <ajmitch> whether it's ready & stable enough in time will be decided closer to feature freeze, I suspect
[07:47] <Aegir> Sweet. Now. If only my wireless drivers would actually load on boot... Then networkmanager would be quite handy
[07:51] <poningru> also any clue when espresso will land?
[08:15] <Burgundavia> poningru, soon
[08:15] <Burgundavia> poningru, as for NM, it is probably not
[08:15] <Burgundavia> poningru, not cancelled, that is
[08:28] <Burgundavia> neuralis, your catalog spec doesn't cover any of the design of actually querying the db
[08:31] <pitti> Good morning
[08:31] <Burgundavia> neuralis, I also filled out the laptop use cases
[08:31] <Burgundavia> salut pitti 
[08:32] <pitti> mdz / Kamion: can you please approve all the breezy-update langpacks?
[09:16] <neuralis> Burgundavia: thanks for filling those out. i have a feeling the catalog will get developed outside the general spec process (at least if it happens for dapper), so i'm reluctant at present to spend much time fleshing out the spec.
[09:16] <ajmitch> neuralis: how are the other server specs going?
[09:17] <Burgundavia> neuralis, that seems minor counterproductive. I can flesh out some of them if you want
[09:17] <Burgundavia> s/minor/minorly
[09:17] <neuralis> Burgundavia: counterproductive in what sense?
[09:17] <Burgundavia> neuralis, having a spec will allow people to join you in creating it
[09:17] <neuralis> ajmitch: c-s-h-t is the only one assigned to me; i haven't had time to pay close attention to the others.
[09:18] <neuralis> ajmitch: i know there have been some licensing hitches with the cluster spec, and there is massive confusion about server certification, but malcolm and i can't seem to synchronize enough to get a phonecall through and discuss it.
[09:19] <Burgundavia> neuralis, licensing of what sort?
[09:19] <neuralis> Burgundavia: one of the primary pieces of software in the cluster spec links against openssl
[09:20] <Burgundavia> oh ick
[09:21] <neuralis> Burgundavia: yeah.
[09:22] <neuralis> Burgundavia: i welcome your work on the catalog spec. i'm moving across continents in a few days, so i'm horribly busy and can't find the time for it now.
[09:29] <ajmitch> neuralis: ah, licensing is annoying
[09:29] <ajmitch> neuralis: selinux work is going ahead again, thankfully
[09:33] <Burgundavia> ajmitch, anything in place for dapper or are you looking at dapper+1?
[09:33] <ajmitch> Burgundavia: I'm looking at policy packages & some few admin tools in universe for dapper
[09:33] <ajmitch> promotion to main after some testing for dapper+1, if all goes well
[09:34] <ajmitch> I could probably get policy ready for main for dapper if I worked hard :)
[09:35] <ajmitch> but it'd depend on what would be approved
[09:35] <Burgundavia> selinux is good, if only a pr front
[09:35] <ajmitch> I'd hate to have it as only pr
[09:35] <Burgundavia> I have heard/read a few people bang us around on security (wrongly) because we don;t have selinux
[09:35] <Burgundavia> ajmitch, yes, I realize that. Remember, I am the salesman, I think in terms of PR
[09:36] <ajmitch> targeted policy for main is basically what fedora has
[09:37] <ajmitch> I'm surprised that people are that concerned about it though :)
[09:37] <ajmitch> though I know it can bring real benefits
[09:38] <Burgundavia> ajmitch, mostly it is optics, nothing more
[09:38] <ajmitch> hm?
[09:39] <Burgundavia> selinux is a fancy name to swing around. Things like the work of pitti derooting things just doesn't have the same ring
[09:39] <Burgundavia> ajmitch, you looked at apparmour yet?
[09:39] <ajmitch> so you think selinux is just smoke & mirrors?
[09:40] <Burgundavia> ajmitch, far from it
[09:40] <Burgundavia> I am merely pointing out the great marketing opportunities from this
[09:40] <ajmitch> 'mostly optics' and 'a fancy name' doesn't sound like you think highly of it
[09:40] <Burgundavia> ajmitch, sorry, I am not talking about the technology. I am talking about the preception of the technology
[09:40] <Treenaks> ajmitch: fwiw, all I've seen of selinux until now is hype
[09:41] <Treenaks> ajmitch: or severe restrictions which made the system barely useable
[09:41] <ajmitch> Treenaks: if you were using an early strict policy on fedora core 2 or similar, then yes, it was hard to use
[09:41] <Burgundavia> Treenaks, it seems to be working for Fedora now. They just had to make a few mistakes along the way
[09:41] <ajmitch> nowadays it has improved an awful lot
[09:42] <Treenaks> I still don't see the need, but I might be weird
[09:42] <Burgundavia> Treenaks, any and all security is a good thing
[09:42] <tepsipakki> ajmitch: I'll test the policy when you have it ready. selinux is useful for multi-user systems..
[09:43] <Treenaks> Burgundavia: maybe; try getting into the building here at work and you'll start to disagree ;)
[09:43] <Burgundavia> Treenaks, caveat my statement with "where implemented appropriately"
[09:44] <ajmitch> Treenaks: because running daemons with fewer privileges is a good thing - beyond just derooting :)
[09:44] <Burgundavia> I trust ajmitch is smart enough not to make the same mistakes as FC2
[09:44] <ajmitch> tepsipakki: thanks, it'll need a lot of testing :)
[09:44] <Treenaks> ajmitch: oh sure.. as long as it doesn't make the system as a whole 50% slower because of all the checking
[09:44] <ajmitch> Burgundavia: because I'll be using the same policy base as FC5
[09:45] <ajmitch> Treenaks: about the highest performance impact people have seen is up to 5% in some cases
[09:45] <Burgundavia> ajmitch, cool. Have you been in contact with the FC people to poll knowledge/work?
[09:45] <Treenaks> ajmitch: if it's default, people with slow computers will cry
[09:45] <ajmitch> Burgundavia: yes, especially this week at LCA
[09:46] <ajmitch> Burgundavia: I've known & talked to russell coker for awhile
[09:46] <Burgundavia> ah
[09:47] <ajmitch> Treenaks: considering that I'm mainly advocating it for server use..
[09:47] <Treenaks> ajmitch: that doesn't help... someone might not get that point and enable it for everything
[09:47] <ajmitch> Burgundavia: he's a DD & quite willing to help out with policy problems, as he works fulltime on policy & related stuff 
[09:48] <ajmitch> Treenaks: and someone might not get that you don't run KDE on a p166
[09:48] <Treenaks> you don't?!
[09:48] <ajmitch> Treenaks: you didn't get that I said 5%, in some cases when the system is loaded :P
[09:48] <Treenaks> ajmitch: I remember running KDE1 on that ;)
[09:48] <ajmitch> I've run selinux with no noticeable perfomance drop on my older systems
[09:49] <ajmitch> yes, so did I.. ;)
[09:49] <Aegir> KDE2 will run on a p166. Runs quite nicely infact.
[09:49] <ajmitch> Aegir: 3.5, however...
[09:49] <ajmitch> and with 32MB RAM
[09:49] <Aegir> ajmitch: Heheh
[09:49] <Aegir> ajmitch: Oh, good point. My P166 laptop had 90'ish MB of ram
[09:50] <Burgundavia> anyway, I have to sleep. night all
[09:50] <ajmitch> Treenaks: your bad experiences with it in the past seem to make you wary of it now :)
[09:51] <ajmitch> it's not like OOo2, where the developers conspired to make it even slower :)
[09:51] <Treenaks> ajmitch: I'm just not convinced that the standard security model that we've been using for ages is broken enough :)
[09:52] <ajmitch> oh it is ;)
[09:53] <ajmitch> we just manage to stay ahead of the more serious problems at times
[10:03] <pitti> mjg59: libpam-foreground looks fine now, I approved it; it needs germinating and promotion to main now
[10:04] <tepsipakki> ..and some docs ;)
[10:04] <pitti> heh, well, it doesn't do much, but true
[10:05] <tepsipakki> without docs it won't do even that much ;)
[10:05] <tepsipakki> anyway, I'm patient..
[10:07] <ajmitch> hey pitti 
[10:14] <pitti> Kamion: who is currently in charge of the automatic keyboard selector in the installer (which determines layout by pressing keys)
[10:14] <pitti> ?
[10:14] <pitti> Kamion: it insists that I have a 'jp106' keyboard when I press pc104/US keys (which I want)
[10:15] <pitti> Kamion: also, do you want a bug report about the proxy dialog, which is superfluous when installing without network?
[10:21] <pitti> Kamion: (oh, forget the proxy thing, that's already fixed now)
[10:22] <pitti> oh no, it's not
[10:25] <doko> Kamion: today's install CD just hangs "Unpacking libsqlite0 ..."
[10:26] <Kamion> pitti: feel free to send me details of which keys you're pressing in which order in a bug against kbd-chooser (for now)
[10:27] <Kamion> pitti: the proxy question is displayed because it's hard for choose-mirror to tell the difference between "no network" and "internal network only, needs proxy to get out to the Internet"
[10:27] <Kamion> I suppose ideally it would check for an interface being up or something
[10:27] <Kamion> doko: sure it's not a dodgy CD?
[10:27] <Kamion> if nobody digs into it I'll sort it out at the sprint I guess
[10:28] <pitti> Kamion: bugs reported about both issues
[10:28] <pitti> Kamion: I'm doing a current ppc install ATM, I'll watch out for the libsqlite thingy
[10:28] <doko> Kamion: maybe, but that happens after the packages are copied to the hard disk
[10:29] <doko> Kamion: minor bug: the installer says "Downloading packages", while copying them from the CD
[10:30] <doko> ok, installation did succeed by just restarting it ...
[10:31] <doko> hrm, no /etc/X11/xorg.conf ...
[10:32] <ajmitch> libsqlite0 is still on the cd?
[10:33] <Kamion> doko: packages aren't copied to the disk any more
[10:33] <Kamion> unless apt does that, but I don't think it does
[10:33] <Kamion> doko: aptitude bug, not my fault :)
[10:33] <Kamion> should just say Retrieving or something
[10:34] <pitti> ajmitch: it's on the kill list on DapperDuplicatedPackages
[10:34] <ajmitch> pitti: that's what I thought
[10:35] <ajmitch> hm, that apparmour looks interesting, though it's certainly less comprehensive than selinux
[10:35] <Kamion> pitti: er, isn't it bad for breezy-updates versions to be > dapper for language packs?
[10:35] <doko> mvo: ^^^
[10:38] <mvo> doko: asking about the hang? what does ps ax show? is dpkg still runing?
[10:39] <doko> mvo: no, aptitude saying "Downloading" while "copying"
[10:40] <mvo> doko: can you strace `pidof aptitude` please?
[10:41] <doko> mvo: too late, that was during the installation ...
[10:41] <pitti> Kamion: hm, eventually I should encode the release version number, true
[10:41] <Kamion> mvo: AFAICT aptitude just unconditionally says Downloading
[10:41] <Kamion> it certainly does it reliably on every installation
[10:42] <mvo> doko: is the problem reproducable?
[10:42] <Kamion> pitti: is there going to be an update to dapper too?
[10:42] <mvo> Kamion: ah, thanks
[10:42] <doko> mvo: ehh, I'm not reinstalling again today ...
[10:42] <pitti> Kamion: it seems that I have to do that, unless we want to reject all those packages
[10:42] <pitti> Kamion: thanks for spotting that
[10:42] <Kamion> not especially, considering that rejects from -updates are kinda hard anyway
[10:43] <pitti> Kamion: I'll build the dapper ones with version 1:6.04+2006blabla
[10:43] <pitti> Kamion: and the future breezy/hoary ones likewise
[10:43] <Kamion> sounds reasonable
[10:43] <pitti> oh, no need for the epoch, even
[10:43] <mvo> doko: ok, but it happend with todays image?
[10:44] <pitti> no, we do need an epoch
[10:44] <Kamion> yes
[10:44] <pitti> Kamion: ok, I'll build dapper packs now, maybe we should hold back the breezy ones for now
[10:45] <doko> mvo: yes
[10:47] <mvo> doko:  20060127 (i386)? or amd64?
[10:48] <mvo> amd64 is a bit awkward for me to test (it's my main workstation)
[10:48] <pitti> mvo: no spare partition? :)
[10:49] <Kamion> pitti: ok, let me know when you've uploaded them
[10:49] <mvo> pitti: sure, but it means, I can't work that efficiently anymore :)
[10:49] <doko> mvo: $ md5sum ubuntu/dapper-install-i386.iso
[10:49] <doko> b3c61ad9e6cd3c6b4c7ddcd4ffc4136e  ubuntu/dapper-install-i386.iso
[10:50] <mvo> doko: I give it a try here once it finished downloading
[10:55] <enrico> Hi mvo!
[10:57] <mdz> infinity: awake?
[10:58] <pitti> good morning Matt
[10:58] <Mithrandir> mdz: he'll be around in a minute or two.
[10:59] <seb128> hi mdz
[10:59] <mdz> morning
[10:59] <mdz> neuralis: done
[11:00] <mdz> Mithrandir: thanks
[11:03] <infinity> mdz: Yo.
[11:04] <mdz> infinity: could you make available to Kinnison and cprov copies of the current buildd chroots from the production environment?
[11:04] <infinity> Yup, can do.
[11:04] <mdz> thanks
[11:05] <mdz> Kamion: what would it take to arrange a CD build test using the soyuz-published archive?  ship a copy over to little?
[11:08] <janimo> pitti, hi could you schedule xfdesktop review for when you have time? It's the only essential package of the remaining xfce bits. thank you
[11:10] <pitti> ok
[11:13] <Kamion> mdz: is it accessible within the DC? then I could just mirror that
[11:16] <Kamion> after that presumably it should be pretty trivial for me to try
[11:23] <dholbach> hello
[11:23] <pitti> doko, Kamion: no problem with libsqlite0 here on ppc/daily
[11:23] <pitti> hi dholbach 
[11:23] <dholbach> hey pitti
[11:23] <pitti> doko: confirmed, I have a 0-byte xorg.conf here, too
[11:23] <pitti> doko: did you already file a bug about this?
[11:25] <pitti> hrm, of course I don't have a backup for xorg.conf *grumpf*
[11:26] <tepsipakki> pitti: it's already filed
[11:26] <pitti> ok, thanks
[11:28] <tepsipakki> pitti: https://launchpad.net/distros/ubuntu/+source/xorg/+bug/29564
[11:28] <Ubugtu> Malone bug 29564 in xorg: "xorg.conf is left empty by installer" [Normal,Unconfirmed] 
[11:29] <Kamion> (not that it's the installer doing that)
[11:30] <tepsipakki> yeah, well it wasn't reported by me ;)
[11:30] <tepsipakki> "during install" is closer
[11:30] <Kamion> your comment said "I can confirm that the installer leaves ..." :-)
[11:30] <tepsipakki> oh
[11:31] <tepsipakki> grr
[11:31] <tepsipakki> great day, can't even remember stuff I did 5min ago
[11:36] <mdz> Kamion: it's accessible both within and without
[11:36] <mdz> Kamion: staging.archive.ubuntu.com
[11:41] <Kamion> I suspect I'll run into rsync limits on that eventually, but sure
[11:42] <doko> which are the most recent install cd's for ia64?
[11:43] <Kamion> doko: http://cdimage.ubuntu.com/ports/daily/current/
[11:43] <doko> Kamion: thanks
[11:44] <doko> Kamion: but not available via rsync?
[11:44] <doko> found them ...
[11:44] <Kamion> rsync URL constructed as usual
[11:46] <Kamion> mdz: rsyncing over to little now
[11:46] <Kamion> will take a while, I'm sure
[11:47] <mdz> Kamion: did you make a copy of the existing archive on little and rsync --delete over that?
[11:47] <mdz> might be quicker
[11:47] <Kamion> only by 50% at most, due to ports
[11:48] <mdz> ports?
[11:48] <Kamion> hppa/ia64/sparc
[11:48] <mdz> those are present in both archives
[11:48] <Kamion> at the moment they're in a separate tree on little
[11:48] <Kamion> due to the way mirrors are presented to me
[11:48] <mdz> ah
[11:48] <Kamion> Kinnison: I thought there weren't supposed to be main->universe symlinks any more
[11:49] <Kamion> pool/main/b/bison-1.35/bison-1.35_1.35.orig.tar.gz -> ../../../../pool/universe/b/bison-1.35/bison-1.35_1.35.orig.tar.gz
[11:49] <Kamion> besides, this way gives better logs :)
[11:49] <Kamion> I'm also curious to know how long it takes to sync the whole thing from scratch, for future cdimage planning
[11:49] <Kinnison> Kamion: Erm, odd
[11:50] <Kinnison> that's not in my archive
[11:50] <Kinnison> Kamion: you sure you're looking in an lp-generated archive rather than a katie one?
[11:50] <Kamion> it's definitely rsyncing from staging.archive.ubuntu.com::ubuntu/
[11:50] <Kamion> according to ps
[11:51] <Kinnison> which isn't right
[11:51] <Kinnison> Well, I assume it won't be
[11:51] <Kinnison> since I never set that up
[11:51] <Kamion> where is the correct rsync URL?
[11:51] <mdz> I don't know that rsync is set up for this archive
[11:51] <Kinnison> I doubt it is
[11:51] <Kamion> please do that, I need it
[11:51] <mdz> if you aren't syncinc with an existing archive, I don't see why you need rsync
[11:51] <Kamion> I'm not rewriting everything to use HTTP
[11:51] <Kamion> I will be, for everything but this one test
[11:52] <Kamion> so we need rsync anyway, might as well have it
[11:52] <mdz> Kamion: elmo is not here right now
[11:52] <mdz> Kamion: if you open up an nc -l I will netcat it over to you from drescher
[11:53] <Kamion> I'd much rather have the opportunity to make sure anonftpsync works on lp
[11:53] <Kamion> there are some interesting cases in that script wrt symlinks
[11:53] <Kamion> since I know that symlink layout is slightly different in lp, I want to test that
[11:53] <mdz> you'll get exactly the same layout
[11:53] <Kamion> Kinnison has told me that it differs
[11:53] <Kamion> in particular, no main -> universe symlinks like we have on katie
[11:53] <mdz> you'll get the same layout via nc that you would via rsync
[11:54] <Kamion> er, sorry, how does this work with nc?
[11:54] <mdz> nc -v -l -p 1234 | tar xvf -
[11:54] <Kamion> ok, but we'll have to rerun all this again in order to test anonftpsync.
[11:55] <mdz> ok
[11:55] <siretart> mdz: I don't know if you read the ipython discussion on ubuntu-motu. the debian maintainer (nobse) told me these days, that upstream would like to see the current version in dapper (0.7.1). I've already sent an diffstat and changelog for 0.7.0. I trust nobse (the DD) in charge. are you okay with the update or do you want more analysis?
[11:55] <Kamion> mdz: 1234 opened
[11:55] <Kamion> using tar xvpf
[11:55] <mdz> siretart: I don't have a problem with it, no.  note that universe UVF exceptions are meant to be queued through dholbach
[11:56] <siretart> mdz: we are still waiting for answer :)
[11:56] <dholbach> mdz: I sent a mail to colin and you
[11:56] <Kinnison> Kamion: don't expect the dists/ for anything other than dapper/ to make sense. And we don't have the installer-* dirs yet
[11:56] <Kamion> mdz: could you cd to ubuntu-archive/ubuntu/ and do that again?
[11:56] <Kinnison> Kamion: if you rely on those, we need to wait some more time
[11:56] <Kamion> Kinnison: I rely on those for anything meaningful
[11:57] <Kamion> Kinnison: I don't need them for live CD builds, but live CD builds hardly touch the archive at all on little
[11:57] <Kamion> rely on> installer-*, that is
[11:57] <Kinnison> Kamion: then they're jumping the gun
[11:57] <Kinnison> which, tbh, they tend to do
[11:57] <Kinnison> Kamion: we'll prod you when we're ready, and hopefully we'll have rsync ready too
[11:57] <Kamion> ok, shut down nc again then
[11:58] <Kinnison> Sorry colin
[11:58] <Kamion> I'd offer to come down to London for better communication, but I have to stay here to look after the child
[11:58] <Kamion> feel free to phone me if need be
[12:00] <mdz> Kamion: connection refused
[12:00] <Kamion> 10:57 < Kamion> ok, shut down nc again then
[12:01] <Kamion> there's no point until I have the installer-* directories
[12:01] <mdz> Kinnison: ok, I need to take care of some other things
[12:01] <mdz> Kinnison: please drive nc if needed
[12:01] <Kamion> I won't be able to build a complete CD without those, and will have trouble comparing with previous images etc.
[12:02] <ajmitch> mdz: is it too late for dapper bounties? :)
[12:03] <ajmitch> given that feature freeze is in a few weeks
[12:03] <mdz> ajmitch: depends on how long the project would take to complete, whether it has a spec...
[12:03] <mdz> feature freeze is the deadline for delivery
[12:03] <Kamion> btw, is it a bad idea to upload NEW stuff today?
[12:03] <ajmitch> selinux spec, I'm just working on policy now
[12:03] <Kinnison> mdz: I will do, thanks
[12:03] <Kamion> as in, will it be carried over to soyuz?
[12:05] <mdz> Kamion: I think there are already packages in queue/new we'd need to deal with
[12:07] <infinity> Oo, my FS just remounted readonly.  AFK for a while.  fscking.
[12:15] <\sh> seb128: please don't assign gajim bugs to gajim-maintainers team, instead use motu or motuim team
[12:15] <seb128> why?
[12:16] <seb128> why is there a gajim team if they don't do gajim?
[12:16] <\sh> seb128: because gajim-maintainers are upstream, and not the ubuntu responsible people in the first place :)
[12:17] <seb128> and upstream don't want to heard about bugs in their software?
[12:17] <seb128> what a nice upstream, I'll keep using gaim
[12:17] <\sh> seb128: they don't use launchpad for bugs :)
[12:17] <seb128> so they should not care
[12:18] <pitti> ogra__: any reason why schooltool and schoolbell have lots of translations (po files), but don't ship mo files?
[12:18] <\sh> seb128: we had some discussions about this topic...and I'm thinking about taking over the reponsibilties of gajim-maintainers team...gajim upstream are using launchpad only for translations so far
[12:19] <seb128> maybe they will reply to some bugs when getting the mails, that's their software, they should care a bit for it
[12:19] <pitti> ogra__, doko: oh, may it be that zope and zope apps (school{tool,bell} don't use gettext, but use po files directly?
[12:19] <pitti> because they ship the po files
[12:20] <ogra__> pitti, i must admint, i never looked at translations in schooltool
[12:22] <pitti> ogra__: well, as long as they work, it's fine
[12:22] <\sh> seb128: but first there must be a test if it's happening only with our package or it is really an upstream problem, and then we'll inform upstream directly
[12:22] <\sh> seb128: or fixing the problem and push the patch towards upstream
[12:22] <ajmitch> morning \sh 
[12:22] <seb128> bah
[12:22] <\sh> moins ajmitch 
[12:22] <siretart> \sh: if you want gajim bugs to be filed against the gajim lp team, you could indicate that with adjusting the maintainer field
[12:22] <seb128> gajim upstream are ... no comment
[12:22] <seb128> hate such upstream
[12:23] <\sh> siretart: no..the reporter tested gajim on dapper...and this is our area..not upstreams.
[12:23] <\sh> upstream == real upstream
[12:23] <\sh> siretart: we had some real hard discussions about this with kiko and nkour on #launchpad :)
[12:23] <\sh> coffee time
[12:23] <seb128> so you run a LFS box to reproduce bugs out of Ubuntu before forwarding them? :p
[12:24] <doko> pitti: schooltool/schoolbell is currently broken, because it doesn't work with zope3.2
[12:24] <siretart> \sh: err, no, you misunderstand me. I mean the maintainer field of the gajim package in dapper
[12:25] <pitti> doko: gcj does not ship mo files as well, although it looks like it should
[12:25] <pitti> doko: gcj-4.0 source package, in particular
[12:26] <pitti> doko: hmm, maybe not, src/gcc/po, src/libcpp/po, src/libstdc++-v3/po doesn't look very gcj specific; the po files might just be superfluous
[12:28] <\sh> seb128: please...I'm really not in the mood of discussion the mess with real upstream maintainers and launchpad issues. I'll be happy when I convience real upstream to use launchpad, instead of trac, which is quite difficult, when you are dealing with real upstream and real upstream has a debian package maintainer in their team...and no, i will stop discussion this issue right here. MOTU IM is dealing with it..and will take the necessary ac
[12:28] <\sh> s/discussion/discussing/
[12:28] <doko> pitti: gij/gcj/libgcj don't have any po/mo files
[12:28] <seb128> no problem, I'll just no use gajim if upstream are that kinds of guys and don't care about their software
[12:28] <pitti> doko: ok, thanks
[12:29] <pitti> doko: it causes translation import errors, so I'll just blacklist them
[12:29] <seb128> (and sure, I'm dealing with fake upstream all the time)
[12:29] <\sh> seb128: to be honest, i think it's more a jabber server problem not using the right DNS records...
[12:29] <doko> pitti: yes, maybe because these are duplicated. it's the same tarball as gcc-4.0
[12:29] <mantiena-baltix> Kamion, Hi
[12:30] <pitti> doko: yes, that sounds plausible
[12:30] <Kamion> mantiena-baltix: hello
[12:32] <mantiena-baltix> Kamion, I've read latest Ubuntu Dev status and found there info, that you will upload your ubuntu-express today :)
[12:33] <Kamion> should be able to, yes
[12:33] <Kamion> aside from it not being called ubuntu-express, of course
[12:33] <mantiena-baltix> Kamion, when and where ?
[12:33] <Kamion> dunno. the archive, of course
[12:33] <mantiena-baltix> archive.ubuntu.com ?
[12:33] <Kamion> I don't generally bother with staging repositories or whatever
[12:33] <Kamion> yes
[12:34] <Kamion> note, it will *not* be easily backportable to anything breezy-equivalent
[12:34] <Kamion> I think I mentioned that to you before though
[12:35] <mantiena-baltix> Kamion, yes, I remmember your worlds about dependancies to latest debconf
[12:36] <Kamion> http://people.ubuntu.com/~cjwatson/bzr/espresso/ubuntu/, anyway
[12:36] <mantiena-baltix> Kamion, because of this my strategy for this (and next) week is to try integrate some parts of your expresso installer into guadalinex ubuntu-express
[12:37] <mantiena-baltix> at least 3 parts of guadalinex ubuntu-express are more or less broken - autopartitioning, copying and installing bootloader
[12:37] <Kamion> mantiena-baltix: I understood that Guadalinex were coming up to a release
[12:38] <Kamion> I don't think they'd want this code right before a release; if nothing else it's currently very slow and the UI is unresponsive at many points
[12:39] <Kamion> it's perhaps worth noting that aside from autopartitioning, copying, and installing the bootloader, there isn't that much else ;-)
[12:39] <mantiena-baltix> Kamion, yea, but I don't need your UI now, guadalinex ui is good enough for me ;)
[12:39] <Kamion> mantiena-baltix: you're missing the point, I'm afraid
[12:39] <mantiena-baltix> Kamion, what point ?
[12:39] <Kamion> mantiena-baltix: the changes I've made to autopartitioning and installing the bootloader are intrinsically connected to the UI and its responsiveness; you cannot separate them
[12:39] <mantiena-baltix> :(
[12:40] <Kamion> I do plan to make the UI more responsive, obviously
[12:40] <mantiena-baltix> Kamion, so, there are no backend/frontend now ?
[12:40] <Kamion> but I don't have time to do it before the distro team sprint next week, which is my target for an initial version
[12:40] <Kamion> mantiena-baltix: there is, but the debconffiltered backends drive the frontend in places
[12:40] <Kamion> and it isn't separated quite enough yet to allow the frontend to keep processing UI events in the meantime
[12:43] <pitti> jbailey: somewhere between glibc 2.3.5-1ubuntu11 and 2.3.5-1ubuntu17 no .mo files were shipped any more (libc.mo). Is that deliberate or a bug?
[12:43] <Kamion> somebody mentioned passing stuff over dbus rather than using the current whatever-works mechanism, or maybe there are other IPC mechanisms available
[12:43] <Kamion> I hope to investigate that next week
[12:45] <mantiena-baltix> Kamion, ok, thanks for info. how about file copy ? guadalinex ubuntu-express has very slow copying, because it collects information about every file, which needs to be copied and then copies each file separately instead of copying whole folders (/usr/, /lib/, /etc/, etc..)
[12:47] <pitti> jbailey: ah, I know: 2.3.5-1ubuntu17 disabled the locales package, which apparently shipped libc.mo. Can you please install them into the libc6 deb?
[12:52] <Kamion> mantiena-baltix: hmm? it just seems to use cpio
[12:53] <Kamion> oh, it does have to find them all in advance, I guess, but since it's only in two processes I'm not sure it should make all that much difference ...
[12:53] <Kamion> anyway, I haven't touched that
[12:55] <seb128> jbailey: another duplicate of #28640
[01:02] <jbailey> pitti: Will do.
[01:02] <pitti> jbailey: great, thanks
[01:03] <mdke> gnome-panel is not installing properly, is this known? http://pastebin.com/525480
[01:05] <mdke> seems to install ok the second time around
[01:05] <pitti> hey sabdfl 
[01:06] <seb128> mdke: seems to be a scrollkeeper-update crash
[01:06] <ajmitch> morning sabdfl 
[01:06] <seb128> mdke: sudo scrollkeeper-update -q ?
[01:06] <mdke> seb128, can I get any more useful information out of my system, given that the packages have installed ok the second time I tried?
[01:06] <sabdfl> hi guys
[01:06] <mdke> hey sabdfl 
[01:06] <seb128> Hi sabdfl
[01:06] <Kinnison> hey sabdfl feeling better?
[01:07] <mdke> seb128, that command shoots out some errors, I'll paste em
[01:08] <mdke> seb128, it is just lots of this: http://pastebin.com/525483
[01:08] <mdke> but as I say, gnome-panel is installed ok now
[01:13] <carlos> mvo: hi, around?
[01:13] <LeeJunFan> Anyone know the mirror maintainer? Looks like us.archive.ubuntu.com is stuck. missing such things as hal updates and some other stuff.
[01:13] <sabdfl> yes thanks Kinnison, now i just have to write a keynote for LCA :-)
[01:14] <mvo> carlos: lunch, is it urgent?
[01:14] <carlos> mvo: no, just ping me when you are back ;-)
[01:14] <ajmitch> sabdfl: we'll look forward to it :)
[01:14] <carlos> mvo: enjoy your lunch
[01:14] <ajmitch> assuming I can wake up in time
[01:33] <hunger> Any intend to package the new gentium font yet?
[01:34] <hunger> "belonging to all nations" (== gentium) would fit well with ubuntu:-)
[01:41] <siretart> Kamion: does lintian also need UVF exception? I just stumbled over a bug (false positive error) and noticed, that djpig recently uploaded a new lintian to debian, fixing many many bugs. I'd like to upload that version, with our (trivial changes) merged
[01:41] <mjg59> pitti: Rock, thanks
[01:44] <Kamion> siretart: yeah, mail me/mdz as usual for main
[01:45] <siretart> Kamion: okay. will do.
[01:52] <Kinnison> Kamion: right, rsync is available
[01:53] <Kinnison> Kamion: staging-ubuntu
[01:53] <Kinnison> Kamion: I've copyied the installer-* from archive.ubuntu.com's dapper/main
[01:53] <Kinnison> Kamion: I hope that's enough for you for now
[01:57] <Kamion> Kinnison: rsyncing now, thans
[01:57] <Kamion> thanks
[01:57] <Kamion> Kinnison: you'll want to be sure to copy daily-installer-* too
[01:57] <Kamion> although installer-* will do for now
[01:59] <Kinnison> Kamion: okay, although the archive won't necessarily be in sync for that
[02:00] <Kamion> you could tell infinity/lamont/fabbione (all) to shut down the daily builds
[02:01] <Kamion> at some time that's convenient
[02:01] <Kamion> or we can just not process them, and transfer queue/byhand/ to launchpad after the migration
[02:01] <fabbione> Kamion: i am not building daily atm, you have green light my side
[02:02] <infinity> Kamion: d-i or live, or both?
[02:03] <infinity> d-i dailies will fail miserably anyway, since Kinnison stole those machines. :)
[02:08] <hunger> Hmm... is it only me of does apt fail to recognize that it has installed python-twisted and python2.4-twisted?
[02:08] <hunger> apt-get -u upgrade wants to upgrade those two and does not give any error message.
[02:08] <Kinnison> infinity: Hehe
[02:08] <Kinnison> infinity: ask mdz what he wants to do about it :-)
[02:08] <hunger> running apt-get -u upgrade again results in it doing the installs again.
[02:09] <Kamion> infinity: just d-i
[02:09] <dholbach> gar! It took me some time to figure out my network problems were my brothers edubuntu installation which offered dhcp in addition to the dsl router
[02:10] <ogra> ouch
[02:10] <dholbach> Yes. I wondered how the network could be *that* flakey.
[02:10] <lamont-away> Kamion: there is the lingering question of what hppa/sparc will do in the launchpad world...
[02:10] <Kamion> lamont-away: SEP from my point of view, though :)
[02:11] <mdz> infinity: you can either set up the daily d-i build on the remaining machine, or do a daily sourceful upload and let it happen in the usual way
[02:12] <infinity> Kamion / mdz : Kay, well, daily d-i is disabled for now, I'll sort out the move a bit later.
[02:13] <lamont-away> Kamion: SEP?
[02:13] <Kamion> lamont-away: Somebody Else's Problem
[02:13] <lamont-away> Kamion: ah, well.  hrm... yes.
[02:14] <lamont-away> :-)
[02:14] <Kamion> not to say I don't want it fixed, just that I don't want to end up hacking Soyuz :)
[02:15] <Kinnison> I thought sparc was soon going to be in the datacentre
[02:18] <infinity> In theory, but we still need to sort how how to do non-DC ports at some point.
[02:18] <infinity> Like the s390 port that's been bandied about.
[02:27] <jbailey> infinity: *blink*
[02:27] <jbailey> infinity: You're kidding, right?
[02:28] <infinity> jbailey: Nope.
[02:29] <pitti> jbailey: he'll announce an m68k port next week, shall we bet?
[02:29] <Kinnison> infinity: Yeah, I have a plan for non-DC ports
[02:29] <Kinnison> infinity: mostly done, just needs some tweaking
[02:29] <infinity> pitti: Already bootstrapped on Coldfire. :P
[02:30] <jbailey> infinity: In qemu?  /me says hopefully.
[02:30] <infinity> jbailey: No, on bare metal.
[02:30] <jbailey> I think we should have a rule anything slower than 250mhz needs to run in qemu.
[02:31] <jbailey> I wonder if s390s come in a desktop model so I could get one here.
[02:35] <Kamion> Kinnison: archive still syncing. definitely don't wanna do this from scratch every time, gigabit networking or no.
[02:35] <Kamion> :)
[02:36] <Kamion> it's at k
[02:37] <lamont-away> dear casper.  please launch getty's on ttyS[01] , esp if starting gdm fails.  kthxbye
[02:37] <lamont-away> jbailey: apt-get install hercules
[02:37] <lamont-away> :-)
[02:38] <jbailey> lamont-away: Right, I keep forgetting about that.  do you know if it needs extra ROMs or anything?
[02:38] <lamont-away> nothing extra needed.
[02:38] <lamont-away> of course, you'll need to install a kernel. :-)
[02:39] <jbailey> *gasp*
[02:39] <jbailey> INSUFFICIENTLY USER FRIENDLY, BAH!
[02:39] <lamont-away> there's this free one you can use, or you can buy VM from IBM or somesuch.
[02:39] <jbailey> Err.
[02:39] <lamont-away> jbailey: mind you, I've never done it.  But I know dannf has one on his ia64 box.
[02:39] <jbailey> lamont-away: Do you know if it's reasonably performant?
[02:40] <lamont-away> nfc
[02:40] <jbailey> Fair 'nuff.
[02:40] <lamont-away> iz pretty phat ia64 box
[02:40] <lamont-away> faster than an m68k, almost certainly. :-)
[02:40] <lamont-away> I think it falls into the "doesn't suck horribly" category.
[02:40] <lamont-away> tseng: it happens
[02:41] <jbailey> tseng: I think I've even heard it.
[02:41] <lamont-away> although, for some reason, it seems to trend towards my mutiliation of a french accent. :0)
[02:41] <jbailey> lamont-away: Mine's only a dual 900, but the 10gb of ram makes up for a lot. =)
[02:41] <lamont-away> jbailey: yes, it does.
[02:42] <jbailey> lamont-away: We tried comparing building gcc on a ramdisk and on disk.  No speed difference because it never leaves cache anyway.
[02:43] <lamont-away> jbailey: as it should be.
[02:43] <lamont-away> you need more ram, though, so you can keep the entire build chroot in ram
[02:44] <jbailey> =)
[02:46] <mvo> carlos: I'm available now
[02:46] <carlos> mvo: hi
[02:46] <carlos> mvo: I have a problem with latest update-notifier on Dapper
[02:47] <carlos> mvo: it makes X.org eat most of my CPU cycles
[02:49] <mvo> carlos: can you strace it?
[02:51] <carlos> mvo: I will try to do it when I restart my session
[02:51] <carlos> I had to kill it
[02:51] <carlos> and executing it by hand seems like works without problems
[02:53] <mvo> carlos: ok, if it happens again, please strace it
[02:54] <carlos> will do
[02:58] <bronson> Is there any reason CONFIG_9P_FS is not set in 2.6.15-11?
[02:58] <bronson> Why not make it as a module?
[02:58] <bronson> (this is the v9fs network filesystem -- looks to be real nice)
[02:59] <mdz> bronson: that'd be one for #ubuntu-kernel, kernel-team@lists or BenC
[03:00] <bronson> hah -- didn't even realise ubuntu-kernel existed.
[03:00] <bronson> mdz, thanks.
[03:08] <pitti> lamont-away: any idea why rookery:~lamont/public_html/translations has not a single tarball for diffutils?
[03:08] <lamont-away> because diffutils is unloved? :-)
[03:08] <pitti> lamont-away: diffutils has po and mo files and all that
[03:08] <pitti> pkgstriptranslations creates a nice tarball
[03:09] <pitti> lamont-away: hmm, boggle - the build log has no trace of pkgstriptranslations
[03:10] <lamont-away> well, that would explain it.
[03:10] <lamont-away> last built in sept, for that matter.
[03:10] <pitti> lamont-away: ... because it doesn't use debhelper *headdesk*
[03:10] <pitti> lamont-away: ok, nevermind, sorry for the noise
[03:10] <lamont-away> np
[03:10] <lamont-away> do I see a -ubuntu2 upload in our future?
[03:10] <pitti> yes, in a very near future
[03:30] <mvo> carlos: can you please import gdebi into rosetta?
[03:34] <bddebian> Morning
[03:37] <simira> god afternoon
[03:37] <simira> s/god/good
[03:45] <carlos> mvo: breezy?
[03:45] <carlos> mvo: product?
[03:45] <mvo> carlos: dapper, product "gdebi"
[03:45] <carlos> mvo: dapper is not ready to be translated with Rosetta
[03:46] <seb128> take it as an upstream project
[03:46] <carlos> mvo: we will open it soon so I suppose it should be automatically imported
[03:46] <carlos> seb128: ?
[03:46] <seb128> carlos: it needs to be translated, it's mvo software, if we can't get to rosetta as a package it can be registred as a project no?
[03:46] <mvo> carlos: it's available as a (upstream) prodcut in rosetta I think
[03:47] <seb128> mvo: you can update a .pot for your own project I bet
[03:47] <zakame> hi devs :)
[03:47] <carlos> seb128: if it's Ubuntu specific, it should not be added as a product
[03:47] <mdke> the first one needs to be imported
[03:47] <seb128> carlos: that's an app, I bet Debian is going to jump on it :)
[03:47] <carlos> seb128: ok
[03:47] <mvo> carlos: it's available in debian as well
[03:48] <seb128> carlos: it's a "double click on a deb to install it"
[03:48] <carlos> mvo: then I suppose you as upstream would want to use Rosetta  ;-)
[03:48] <Kamion> Kinnison: archive synced (taking nearly two hours); just syncing up the katie archive so I can do side-by-side test builds now
[03:48] <seb128> carlos: every .deb based distro will want to use it :)
[03:48] <carlos> mvo: import it as a product, please
[03:48] <mvo> carlos: yeah, I just need to figure out how to make gdebi actually my project :)
[03:48] <seb128> carlos: https://launchpad.net/products/gdebi
[03:48] <carlos> mvo: aren't you the owner?
[03:48] <seb128> Registrant:
[03:48] <seb128> Tim Fuchs 
[03:48] <seb128> 
[03:48] <carlos> ok
[03:48] <seb128> who is  he?
[03:48] <carlos> I will change it now
[03:49] <carlos> seb128: someone that likes the application ;-)
[03:49] <seb128> ah ok
[03:49] <seb128> you can register a project even if you are not upstream?
[03:49] <seb128> I though the policy was to get upstream asking for it
[03:49] <Kamion> pitti: uh, surely manual calls to pkgstriptranslations aren't necessary any more?
[03:49] <carlos> mvo: it's yours now
[03:50] <mvo> carlos: woah, thanks. I bow on your launchpad super-powers :P
[03:50] <Kamion> pitti: a rebuild would've done fine, the problem was that the last build of diffutils was from before we did the buildd trick to do automatic pkgstriptranslations on everything
[03:50] <carlos> seb128: yes, but we don't have a way to review those new projects and I don't think it's a bad thing to allow people to register it
[03:50] <carlos> seb128: if upstream wants to use it we give them ownership (like I just did)
[03:50] <seb128> fair enough
[03:50] <seb128> thanks carlos :)
[03:51] <Kamion> pitti: sorry it didn't occur to me to mention it when you were talking about it up above
[03:51] <mvo> carlos: when I click on "translations" I get "administration help required"
[03:51] <pitti> Kamion: oh, I remember, right
[03:51] <pitti> Kamion: ok, I'll remove it again
[03:51] <carlos> mvo: yeah, I need to fix the link
[03:51] <carlos> mvo: create the series, and under overview
[03:51] <carlos> you have a link to request new uploads
[03:51] <carlos> upload there the .pot and any .po file that you already have
[03:52] <carlos> and jordi will handle the import request next time he reviews the queue
[03:52] <mvo> carlos: woooooohhhhhh THANKS
[03:52] <pitti> Kamion: fixed (i. e. reverted), thanks for your phenomenal brain
[03:53] <mvo> carlos: and uploaded!
[03:53] <Kamion> pitti: heh
[03:54] <carlos> mvo: I see them
[03:54] <janimo> mvo, what fromat did you use?
[03:54] <janimo> my upload of a tar.bz2 failed
[03:54] <mvo> janimo: I have only 3 po files and a pot so far :)
[03:55] <mvo> uploaded them idividually, but I think it can deal with tar.gz
[03:55] <janimo> so no tarball?
[03:55] <janimo> aha
[03:55] <janimo> thanks
[03:55] <carlos> janimo: really?
[03:55] <janimo> it says it can deal with tar tar,.gz and tar.bz2 but failed on tar.bz2, let's try again
[03:55] <carlos> I fixed that already
[03:55] <janimo> carlos I did not get notification form LP I thiught it was not fixed
[03:55] <carlos> janimo: could you give me an URL to the tarball and the URL where you try to upload it?
[03:56] <janimo> carlos I made the tarball since upstream in in svn
[03:56] <carlos> janimo: perhaps I forgot to close that bug as I fixed it as a side effect of another change....
[03:56] <janimo> the project was thunar, tried 3 days ago and filed a bug in LP
[03:57] <carlos> janimo: bug number?
[03:57] <janimo> carlos, so fixes to LP are done daily?
[03:57] <janimo> let me check
[03:57] <carlos> janimo: no, seems like your tarball triggered another problem
[03:57] <carlos> as my fix was applied two weeks ago
[03:58] <carlos> janimo: are weekly unless critical/security bugs
[03:58] <janimo> https://launchpad.net/products/launchpad/+bug/29604
[03:58] <Ubugtu> malone bug 29604 in launchpad "Upload of bzip2-compressed PO file tarballs to Rosetta fails" [Normal,Unconfirmed]  
[03:58] <carlos> mvo: could you tell me the path where you have the .pot file inside your tree?
[03:58] <carlos> po/gdebi.pot ?
[03:59] <mvo> yes
[04:00] <carlos> mvo: ok
[04:00] <carlos> janimo: ok, this is a different problem. I need to investigate a bit the error message
[04:00] <carlos> janimo: in the mean time, could you upload a tar.gz?
[04:00] <janimo> carlos, trying that just now
[04:01] <carlos> thanks
[04:01] <janimo> tar.gz worked
[04:02] <carlos> cool
[04:06] <Kamion> Kinnison: how out-of-date is staging meant to be?
[04:06] <Kamion> Kinnison: it's lacking a kernel with the current ABI (-14)
[04:07] <Kamion> Kinnison: (which hoses images)
[04:09] <Kinnison> Kamion: erm, when was -14 uploaded?
[04:10] <Kamion> Date: Wed, 25 Jan 2006 09:39:28 -0500
[04:10] <Kamion> ^-- source upload
[04:10] <Kamion> Date: Wed, 25 Jan 2006 09:39:28 -0500
[04:10] <Kamion> er
[04:10] <Kamion> -rw-rw-r--  1 katie katie 14066 Jan 25 17:35 queue/done/linux-source-2.6.15_2.6.15-14.19_i386.changes
[04:10] <Kamion> think that was the binary upload
[04:11] <Kamion> it required NEW processing, but I did that for the big three architectures on Wednesday evening
[04:12] <carlos> mvo: is gdebi part of the APT project?
[04:13] <mvo> carlos: no
[04:13] <Kamion> Kinnison: unless you haven't synced the overrides for a while or something?
[04:13] <carlos> mvo: but it's related to it
[04:14] <mvo> carlos: well, it's based on python-apt. I think the person registering the project added it as releated
[04:14] <carlos> just asking in case we should remove that link...
[04:15] <carlos> mvo: anyway, I suppose you will change the descriptions / information as needed
[04:16] <mvo> carlos: yeah, need to update/polish it a bit
[04:17] <Kamion> Kinnison: espresso-grub's also missing, which I uploaded on Monday and was NEWed not long afterwards
[04:17] <carlos> ok
[04:18] <Kamion> Kinnison: and according to germinate output a bunch of packages that were removed from katie are still there in soyuz (e.g. mozilla-thunderbird-offline, x-window-system-dev, baseconfig-udeb)
[04:18] <Kinnison> Yes, we haven't handled removals since xmas because gina can't
[04:18] <Kamion> oh dear!
[04:18] <Kinnison> We're compiling a list of things to test elmo's melanie implementation
[04:18] <Kamion> ok
[04:19] <Kamion> there's removals.txt on jackass which could just be fed to soyuz ...
[04:19] <Kamion> admittedly it's a sucky format for machine-readability, but we already do that for debian->ubuntu
[04:20] <Kamion> Kinnison: you can have the CD build log diff if you like; I Ctrl-Ced it at the end and there's lots of noise in it, but the germinate diff near the top should be useful
[04:21] <Kamion> +W: GPG error: file: dapper Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EFC2E3F9C1597003
[04:21] <Kamion> Kinnison: new archive key?
[04:22] <Kamion> -Version: 6.04
[04:22] <Kamion> Kinnison: removing Version from the Release file may break people's existing pinning setups
[04:22] <Kamion> -Architectures: i386 amd64 powerpc ia64 sparc hppa
[04:22] <Kamion> +Architectures: amd64 sparc powerpc source i386 ia64 hppa
[04:22] <Kamion> having source in there seems a bit odd
[04:22] <Kamion> -Origin: Ubuntu
[04:22] <Kamion> -Label: Ubuntu
[04:22] <Kamion> +Origin: ubuntu
[04:22] <Kamion> +Label: ubuntu
[04:22] <Kamion> not sure if that'll break pinning - I *think* it's case-insensitive
[04:23] <Kinnison> Kamion: yeah, there are various little tweaks for the Release files, I'll add those to my list
[04:23] <Kinnison> the key is a test signing key
[04:24] <Kamion> it would be *really* nice if the md5sum/sha1sum entries were sorted in some rational way
[04:25] <Kinnison> I'll have to look into that, dunno how easy it'll be
[04:26] <Kinnison> once I have the full chain going, I'll sit down and make sure I can fix as many of the Release tweaks as I can
[04:26] <Kamion> Kinnison: there are *still* no debian-installer sums in Release
[04:26] <Kamion> I thought I brought that one up at UBZ :(
[04:27] <pitti> seb128, Riddell: can you help me with testing a new set of langpacks again? http://people.ubuntu.com/~pitti/langpacks/
[04:27] <seb128> pitti: sure
[04:28] <Kinnison> Kamion: there aren't? feck, I think I must have a branch somewhere unmerged, ta
[04:29] <Kamion> Kinnison: (these things *are* being picked up by mdz's comparator, right?)
[04:29] <Kinnison> yes
[04:29] <Kinnison> but having an independant rant from you is handy
[04:30] <Kinnison> makes sure we're seeing the right stuff :-)
[04:32] <Kamion> Kinnison: http://people.ubuntu.com/~cjwatson/tmp/katie-soyuz-cd-build.diff
[04:32] <Kamion> the stuff near the top will be the most useful
[04:39] <mdz> Kamion: gina has been temporarily disabled while we're working here
[04:40] <mdz> so we're expecting to be missing the past several days of uploads there
[04:40] <Kamion> ok, unfortunately that makes CD build tests rather difficult since we'd have to wind back seed changes and retrieve older versions of the installer trees
[04:41] <Kamion> I mean the basics of CD building seem to work, at least, it's just they're working with the wrong pieces :)
[04:41] <Kinnison> Cool
[04:41] <Kinnison> Kamion: thanks for this stuff
[04:45] <Riddell> pitti_: language packs working good here
[04:45] <pitti_> Riddell: here, too, thank you
[04:47] <seb128> pitti: works fine for me too
[04:49] <pitti> seb128: thanks
[04:57] <hunger> Anyone else having problems with python-twisted upgrades?
[04:57] <hunger> The debs install fine... but apt insists on reinstalling them over and over again with each upgrade done.
[04:59] <psusi> I noticed that last night
[05:00] <psusi> yea... synaptic installs them just fine, only they remain selected for upgrade
[05:00] <psusi> really weird
[05:00] <hunger> psusi: Great! I was already thinking I am going crazy:-)
[05:00] <psusi> me too ;)
[05:01] <hunger> psusi: Should we file a bugreport or nag pitti and co. here?;-)
[05:02] <hunger> psusi: Well not pitti, doko did the last changes.
[05:10] <pitti> Kamion: all dapper langpacks are now in the archive (with 6.04+2006... version), so the breezy ones are good to go
[05:15] <segfault> humm, gnome-screensaver is not safe.
[05:15] <ogra> segfault, ??
[05:15] <segfault> when it locks the screen, one can press ALT+F2, and then type xterm, and then, enter.
[05:15] <pitti> haha
[05:15] <segfault> after that, you can run: killall -9 gnome-screensaver, and its gone.
[05:15] <segfault> :)
[05:15] <ogra> the same you can do with xscreensaver
[05:15] <torkel> segfault: of course it is safe, the dialog does not get focus so you can't unlock it :-)
[05:16] <segfault> xscreensaver doesn't let you press ALT+F2 i think
[05:16] <ogra> there is no screensaver implementation you cant shut down from console
[05:16] <segfault> (and call the run dialog)
[05:16] <ogra> it does
[05:16] <torkel> sure it does, but I think it kills the xsession if you kill it
[05:16] <ogra> oh, alt-f2 ? 
[05:17] <ogra> torkel, nope
[05:17] <segfault> yes, alt+f2 and calls the run dialog in "background". can anyone try it?
[05:17] <mdke> yes, apparently that is known and solved upstream
[05:17] <ogra> and doesnt work here
[05:17] <torkel> ogra: it doesn't? Then it was another screensaver...
[05:18] <segfault> mdke: ah, didn't know that
[05:18] <dholbach> segfault: next gnome-panel upload will fix that.
[05:18] <ogra> torkel, there are only 3 locking screensaver impelmentations i know of ... 
[05:18] <segfault> dholbach: great!
[05:18] <ogra> torkel, either of them allows to switch to console
[05:19] <ogra> all of them just unlock the screen if you kill the daemon
[05:19] <segfault> i know one can still log from console and kill it, if he has root or sudo access, but this was weird.
[05:19] <segfault> anyway, back to work. thanks!
[05:20] <ogra> no need for root or sudo
[05:20] <segfault> why not?
[05:20] <segfault> how can user A kill user B screensaver?
[05:20] <ogra> because you can log in as the logged in user and kill your own processes ;)
[05:20] <ogra> nope, but user A on the console can kill user A's processes in X
[05:20] <torkel> ogra: I'm pretty sure it was xscreensaver, but it was on RH and some years ago
[05:20] <segfault> ahh, but that makes no sense, since you know the password, you can unlock it from the screensaver
[05:21] <segfault> :D
[05:21] <ogra> exactly 
[05:21] <Riddell> Kamion: please promote libmimelib1c2a to main (rename of libmimelib1c2)
[05:21] <segfault> but indeed, sometimes that situation saves my work, since i had some weird problems with screensavers
[05:21] <Riddell> Kamion: also demote kuser to universe
[05:21] <ogra> and if you are truested enough to be in the admin group and use sudo, you wont do it except for a good reason ;)
[05:21] <Riddell> Kamion: and promote kviewshell to main again
[05:22] <segfault> heh, sure
[05:22] <tseng> ja
[05:22] <tseng> ergh
[05:24] <Kamion> pitti: all accepted
[05:24] <Kamion> er, installed
[05:24] <pitti> Kamion: thank you
[05:26] <Kamion> Riddell: all done
[05:27] <Riddell> Kamion: thanks
[05:29] <ogra> yay, espresso ...!
[05:32] <segfault> how's espresso going?
[05:33] <ogra> got its first upload some mins ago
[05:35] <Diziet> I like the bug 29760 where someone confirms the bug before I've uploaded the package version which causes the bug.
[05:35] <Ubugtu> malone bug 29760 in flashplugin-nonfree "Sound does not work properly in Flash in firefox" [Normal,Confirmed]  http://launchpad.net/bugs/29760
[05:35] <segfault> heh, nice
[05:45] <Kamion> segfault: UI still extremely rough, number of features missing, but it does at least manage to install ... for me
[05:50] <segfault> kamion: great. will it be available in today's livecd build?
[05:52] <siretart> seb128: what are your plans about ekiga for dapper? do you have any?
[05:52] <slomo_> siretart: dholbach wanted to do it this or next week
[05:52] <siretart> slomo_: ah. okay
[05:54] <Kamion> segfault: no
[05:54] <seb128> siretart: dholbach is working on it atm
[05:55] <dholbach> siretart, slomo_: i investigated in debian pkg-voip's packages, investigated in library updates, currently looking at rdepends and their rebuild-ability
[05:55] <dholbach> siretart, slomo_: when i'm going to propose this to Kamion and mdz, i want to be sure to have the information together :)
[05:55] <siretart> dholbach: bien sr
[05:55] <dholbach> :-)
[05:56] <dholbach> la mafia franaise :-)
[05:58] <siretart> dholbach: so debian already has ekiga packages in their svn?
[06:18] <ogra> pitti, ping
[06:18] <ogra> pitti, unping, sorry
[06:19] <ogra> :)
[06:52] <Kamion> This "Boot from first hard disk" option is the best thing I ever let somebody persuade me into adding. I never bother to take CDs out any more.
[06:57] <Diziet> kamion: Excellent.
[06:57] <Diziet> Does it do it by default ?
[06:58] <mdke> Riddell, I added the packagingguide as target "package" to the Makefile in kubuntu-docs. Can you make the changes to debian/ to ensure that it gets installed? I don't know how. Thanks!
[07:00] <Kamion> Diziet: no
[07:01] <Kamion> it's prominently visible on the boot menu though
[07:02] <Mithrandir> Kamion: yeah, it's bloody useful.
[07:04] <LaserJock> Diziet: have you started work on the Ubuntu Developer's Reference?
[07:04] <pitti> Kamion: nice to hear :)
[07:06] <Riddell> mdke: in generic?
[07:06] <LaserJock> Riddell: yeah, it's in generic
[07:14] <Diziet> LaserJock: No.
[07:14] <Diziet> (sorry)
[07:16] <LaserJock> Diziet: np, I'm getting the Ubuntu Packaging Guide going a bit more and I was trying to get a feel for what the UDR would look like so I can minimize overlap
[07:16] <LaserJock> Diziet: will it be more or less like the DDR?
[07:22] <Diziet> LaserJock: Yes, I was going to make it as a big patch to the DDR.  But obviously it would have stuff in it about Ubuntu-specific things like MOTU.
[07:23] <Diziet> I think the best thing would be for you to go ahead and if I like your content then I'll just cut-and-paste it and let you (or other UPG maintainers) know.
[07:24] <LaserJock> Diziet: yes, that sounds good. I have GPLd (instead of the docteam's usual GFDL/CC-SA license so you can use the material withought licensing issues
[07:25] <LaserJock> Diziet: sorry, that was a terrible sentence. The Packaging Guide is GPL so it will be compatible with the Debian docs and the UDR
[07:41] <fabbione> NEWS FROM THE APACHE SPRINT: first external modules are running test suites
[07:41] <Riddell> mjg59: is pmi used any more by gnome or is it all hal?
[07:50] <mdz> fabbione: FILM AT 11
[07:51] <Tm_T> hmm, where's xfonts-base-transcoded ?
[07:51] <fabbione> mdz: php5 is GO, subversion is going as we speak
[07:53] <mdz> fabbione: GO GO GADGET APACHE
[07:53] <fabbione> mdz: ehhee
[07:53] <fabbione> modperl is go too
[07:53] <fabbione> (Mith claims so)
[07:53] <Tm_T> this is interesting, there's no transcoded base fonts at all in dapper repository
[07:54] <Diziet> Does anyone know anything about *gtk_icon_cache* ?
[07:54] <Diziet> LaserJock: Thanks, that's great.
[07:56] <fabbione> DVD9 PORN DOWNLOAD: success
[07:56] <fabbione> apache2.2 is the future!
[07:57] <LaserJock> Diziet: btw, the HTML version of the packaging guide is at doc.ubuntu.com and is updated from the docteam svn repo on a daily basis.
[07:57] <ajmitch> morning
[07:58] <seb128> Diziet: is that supposed to be a GTK API for you?
[07:59] <Diziet> I'm debugging sabdfl's ff crash and it seems to be dying in _gtk_icon_cache_new_for_path.  That mmaps some file or other.
[07:59] <Diziet> I'm wondering if it's possible that the cache file it's mmaping is corrupt and whether that might cause a segfault.
[07:59] <seb128> oh
[08:00] <seb128> the caches are to /usr/share/icons/<icon_theme>/icon-theme.cache
[08:00] <Diziet> mmaps some file or other> looking at the source, gtk+2.0-2.8.10/build-tree/gtk+-2.8.10-static/gtk/gtkiconcache.c
[08:00] <seb128> one cache by theme
[08:00] <seb128> we don't use a cache for hicolor or gnome
[08:00] <seb128> gnome == /usr/share/icons/gnome
[08:00] <seb128> the cache is stupid
[08:00] <Diziet> "we don't use a cache for hicolor or gnome"> I don't understand.
[08:01] <seb128> the specs requires you update the mtime of the folder when installing an icon
[08:01] <seb128> other way it just "mask" your icon
[08:01] <seb128> so if you have a /usr/share/icons/gnome/icon-theme.cache
[08:01] <seb128> and install an icon to /usr/share/icons/gnome/... without updating the mtime
[08:01] <seb128> GTK reply the icon doesn't exist
[08:01] <seb128> and some apps go buum
[08:02] <Diziet> Uhh, but surely that wouldn't lead to a crash in the middle of the GTK function ?
[08:02] <seb128> should not no
[08:02] <seb128> it should crash on a function which expect an icon and get 0x0
[08:02] <Diziet> Also, I'm not sure about this crash in particular, but sabdfl said it happened to him when he tried to `save link target as ...'.
[08:02] <seb128> some apps doesn't handle the case their icon is not present
[08:03] <Diziet> That's not what's happening here.  The stack frame for _gtk_icon_cache_new_for_path is still there.
[08:03] <seb128> anyway we don't use the cache for those folders because it would require updating all the packages installing an icon, and break package not doing it
[08:03] <Diziet> I should say `that's not what happened here'; I don't know if sabdfl's crashes are all the same.
[08:03] <seb128> this is fine for themes because nothing else will install an icon to a theme folder
[08:03] <Diziet> So you're saying this function shouldn't be mmapping anything ?
[08:04] <seb128> yes, it should
[08:04] <seb128> we do have caches for /usr/share/icons/*/
[08:04] <Diziet> So is it possible that if the file was corrupt the program would crash ?
[08:04] <seb128> * beeing all the themes out of gnome
[08:04] <seb128> yep
[08:05] <seb128> ask what theme he uses and make him move /usr/share/icons/<theme>/icon-theme.cache maybe
[08:05] <Diziet> So I think I should tell sabdfl to tar up the cache and email it to me and to move it aside.
[08:05] <Diziet> Right.
[08:05] <Diziet> OK, thanks, that's helpful.  Good next step.
[08:05] <j^> NetworkManager installes files in hicolor/22x22/apps/...
[08:05] <seb128> np
[08:06] <seb128> j^: like some hundred other packages, that's why we don't create a cache for hicolor
[08:07] <j^> ah ok. just rememberd that i had a cach once,... 
[08:07] <seb128> maybe some unofficial package bugged or something
[08:07] <seb128> anyway, time for dinner, bbl
[08:10] <Tm_T> hum, what's the mailing list to ask about font packages? or should I use launchpad?
[08:11] <zyga> hello
[08:11] <fabbione> night everybody
[08:11] <ogra> ciao fabbione :)
[08:14] <dholbach> Tm_T: if it's a bug, file a bug report :)
[08:15] <Tm_T> dholbach: well, I think transcoded fonts should be shipped, like in hoary, but not in breezy nor dapper
[08:15] <Tm_T> transcoded base fonts I mean
[08:16] <dholbach> hmm
[08:18] <Tm_T> yeah, no problem as long as you keep your system as utf-8
[08:18] <Tm_T> but mine isn't
[08:20] <Tm_T> dholbach: looks like I have those packages from hoary
[08:21] <Tm_T> "Reinstallation of xfonts-100dpi-transcoded is not possible, it cannot be downloaded" ;(
[08:34] <mdke> Riddell, the doc is in generic, but i added it to the kubuntu/ Makefile
[08:35] <dholbach> Tm_T: might be interesting to investigate the changelogs
[08:35] <dholbach> Tm_T: there should be a rationale
[08:36] <Tm_T> dholbach: chancelogs of what?
[08:36] <dholbach> Tm_T: the package?
[08:40] <Tm_T> dholbach: hm, you mean in hoary package? because no packages since hoary ;(
[08:49] <siretart> dholbach: Tm_T is right. we currently don't ship those -transcoded packages anymore. :(
[08:50] <Tm_T> yes, and that's flaw
[08:50] <siretart> Tm_T: the problem gets even worse: the location of the font paths changed. so you have to move them around anyway
[08:50] <AlinuxOS> pitti?
[08:50] <siretart> Tm_T: for what do you need the transocded fonts?
[08:50] <Tm_T> siretart: osd_cat
[08:51] <siretart> osd_cat?
[08:51] <Tm_T> yes, xosd app
[08:51] <siretart> hmhm
[08:51] <Tm_T> http://packages.ubuntu.com/dapper/x11/xosd-bin
[08:52] <siretart> I know xosd. I'm using it
[08:52] <siretart> I wasn't aware that it depends on transcoded fonts
[08:52] <Tm_T> it does, if your locales are ISO-8859-15 ;(
[08:52] <Tm_T> because now it doesn't find its default font
[09:06] <siretart> Tm_T: the xfonts package seem to contain kinda pregenerated fonts
[09:07] <siretart> Tm_T: I don't see an obvious way to add the -transcoded fonts to them
[09:08] <siretart> Tm_T: filing a bug is a good idea in any case
[09:10] <Burgwork> neuralis, http://sourceforge.net/projects/pootypedia/ <-- you looked at this?
[09:10] <siretart> Tm_T: well, the obvious way would be to just grab the transcoded fonts as they are on my harddrive and stick them into a package
[09:25] <Kamion> missing signal_connect in the Gnome frontend
[09:25] <Kamion> apparently Gtk2::Object in the perl gtk bindings has somehow managed not to have Glib::Object as its base class
[09:31] <ogra> Kamion, there is a bug with recent gtk perl ...
[09:32] <Kamion> yes, I'd gathered that
[09:32] <Kamion> any actual diagnosis? :)
[09:32] <ogra> seb pointed me to a bugurl, but i lost it, most gtkperl stuff is broken currently it seems
[09:32] <Treenaks> bug-eyed earl?
[09:33] <Kamion> the workaround suggested in #28719 doesn't work for me
[09:33] <ogra> seb128, do you have the bugnr from the gtkprel bug ?
[09:33] <Kamion> cjwatson@cittagazze:~/libgtk2-perl-1.102$ perl -MGlib -MGtk2 -le 'my $win = Gtk2::Window->new; print "yes" if $win->isa(Glib::Object)'
[09:33] <ogra> *gtkperl
[09:33] <Kamion> cjwatson@cittagazze:~/libgtk2-perl-1.102$
[09:34] <Kamion> and putting 'use Glib;' in the debconf gnome frontend doesn't help either, so AFAICT that last comment is a red herring
[09:35] <Kamion> I can't think of a plausible way that would make a difference to perl anyway
[09:35] <jordi> mvo: DUDE
[09:35] <seb128> ogra: I did spoke about a gtkperl bug?
[09:35] <mvo> jordi: hu?
[09:35] <seb128> ogra: maybe I read it just before you asked or something
[09:35] <seb128> dunno about it
[09:36] <jordi> mvo: nm me. I saw your conversation with carlos
[09:36] <Kamion> I'll look at it myself, my XS-fu should be sufficient if dusty
[09:36] <ogra> seb128, i asked about it some days ago, you pointed me to an upstream bug ...
[09:36] <ogra> sadly i lost it
[09:36] <seb128> ah
[09:38] <seb128> Overview of changes in Glib 1.114
[09:38] <seb128> [09:38] <seb128> * Completely redo the way GObject types are mapped to package names.  This
[09:38] <seb128>   fixes the problem uncovered by the recent GInitiallyUnowned issue.  See the
[09:38] <seb128>   ChangeLog for a detailed description of the changes.
[09:38] <seb128> 
[09:38] <seb128> maybe
[09:38] <seb128> that's a fix of gtk2-perl 2.13.5
[09:39] <seb128> 
[09:39] <seb128> Overview of Changes from GTK+ 2.8.9 to GTK+ 2.8.10
[09:39] <seb128> [09:39] <seb128> * Derive GtkObject from GInitiallyUnowned instead of
[09:39] <seb128>   GObject, if possible. Note that this change is known
[09:39] <seb128>   to break versions of the GTK+ Perl bindings older
[09:39] <seb128>   than GTK+ Perl 2.13.4.
[09:39] <seb128> 
[09:39] <Kamion> ah, yes, that sounds plausible
[09:39] <ogra> yes, that was it
[09:39] <seb128> that's what I know on the topic
[09:39] <Kamion> ok, so we just need newer bindings then
[09:39] <seb128> correct
[09:42] <Kamion> thanks
[09:44] <siretart> Kamion: if you upload xorg the next time, care to fix malone #29483?
[09:44] <Ubugtu> malone bug 29483 in xorg "x11-common must depend on laptop-detect" [Normal,Unconfirmed]  http://launchpad.net/bugs/29483
[09:45] <Kamion> siretart: no great plans to do so, I was fixing an installation failure
[09:46] <Kamion> and as I said in the bug, that description is wrong
[09:46] <Kamion> in fact, x11-common *already* depends on laptop-detect
[09:46] <siretart> I beg your pardon
[09:47] <Kamion> I don't see the problem though, looks like it degrades gracefully-ish
[09:47] <Kamion> albeit to thinking it's a desktop
[09:47] <siretart> well, it produces noise in the buildd logs
[09:47] <siretart> as well as in my chroot
[09:48] <siretart> but you're right, it is quite low priority
[09:51] <mjg59> Riddell: It's currently still called by gdm, though probably shouldn't be
[09:55] <ogra> mjg59, using hal from gdm ? #
[09:55] <ogra> that sounds evil
[09:55] <mjg59> ogra: Why not?
[09:56] <ogra> gdm runs as root ? 
[09:56] <mjg59> Yes
[09:57] <ogra> if you have security holes there you could abuse hal ... ?
[09:57] <mdz> mjg59: heckle him once for me
[09:58] <Kamion> grr, I think Debian hasn't noticed the libgtk2-perl thing 'cos it only happens if you build libgtk2-perl with the newer libgtk2.0-0
[09:58] <Kamion> evil lurking bugs
[09:59] <simira> who can I blame for my gweather applet not working? It crashes when I try to put it on the Gnome -panel
[10:01] <Riddell> mjg59: so what uses hal?
[10:01] <ogra> simira, its starts with a g ....
[10:01] <ogra> simira, must be a seb128 package then :P
[10:02] <simira> :)
[10:02] <ogra> Riddell, the powermanager calls hal who directly accesses pmi
[10:02] <ulaas> cdrom   floppy   floppy1  floppy3  floppy5  floppy7  sda2
[10:02] <ulaas> cdrom0  floppy0  floppy2  floppy4  floppy6  sda1
[10:02] <ulaas> flight 3
[10:02] <ulaas> known issue?
[10:03] <Riddell> ogra: powermanager is a panel applet?
[10:04] <ogra> a notification area applet
[10:04] <ogra> using gconf for settings ... 
[10:04] <ogra> would be some work to reimplement it in QT i guess
[10:04] <ogra> in fact its a daemon a config tool and the applet
[10:05] <ogra> tied up with gnome-screensaver for dpms 
[10:06] <Kamion> ulaas: I've got a bug about it at least, haven't investigated yet
[10:06] <Kamion> I'm assuming it's probably a udev bug
[10:07] <ulaas> Kamion, ping me if you need info.
[10:08] <Kamion> ulaas: feel free to subscribe to malone bug #27926
[10:08] <Ubugtu> malone bug 27926 in partman "fstab  contains 8 floppy drives but PC does not have any" [Minor,Confirmed]  http://launchpad.net/bugs/27926
[10:13] <ulaas> slomo_, ping
[10:18] <Tm_T> siretart: ok, I'll file a bug?
[10:19] <siretart> Tm_T: yes. or even better, provide a package ;)
[10:49] <ulaas> Cannot find mozilla installation directory. Please set MOZILLA_FIVE_HOME to your mozilla directory
[10:49] <ulaas> i get this when i try to launch monodevelop
[10:49] <ulaas> is this monodevelop or firefox?
[10:50] <ulaas> and should i file it?
[10:53] <torkel> ulaas: works for me. Do you have the latest versions of monodev and firefox installed?
[10:54] <ulaas> torkel, lemme check.
[10:57] <ulaas> torkel, monodevelop 0.9-1ubuntu1 firefox 1.5.dfsg-4ubuntu5
[11:02] <torkel> ulaas: works for me with those versions.
[11:03] <torkel> ulaas: on the other hand, I have mozilla installed too...
[11:03] <ulaas> torkel, hmm. lemme try mozilla as well. i have a feeling that it wil work
[11:03] <ulaas> slomo_, ping
[11:05] <torkel> ulaas: you need mozilla for it to work. I.e file a bug against monodevelop that it probaly needs it's depends checked
[11:05] <ulaas> sure
[11:06] <torkel> and/or it have to be updated to work with firefox
[11:10] <Tm_T> siretart: provide a package.. huh, that would be "later" 'cause haven't done those ever
[11:10] <Tm_T> should learn though
[11:20] <Tm_T> siretart: so basically, I just take hoary package and do necessary changes and that's about it?
[11:21] <Tm_T> siretart: or, from debian and change it
[11:25] <Tm_T> ...and ofcourse packages.debian.org is down
[11:26] <crimsun> use packages.qa.debian.org
[11:29] <Tm_T> ah, ty
[11:44] <rob> hi, does anyone know who is looking after gnome-app-install? I emailed Ross Burton but he said its not him anymore, and that it undergoing a rewrite
[11:45] <Burgwork> rob, mvo handles it
[11:46] <rob> ok thanks Burgwork, do you know how I can contact him?
[11:46] <Burgwork> rob, right here
[11:47] <rob> heh true that
[11:48] <rob> ping mvo?
[11:50] <mvo> hello rob
[11:50] <rob> hi mvo, I was just wondering what the current status of gai is
[11:51] <rob> I emailed Ross, but yeah
[11:51] <rob> is there a repository somewhere where I can take a look at the latest code?
[11:52] <mvo> rob: sure, I'm happy about your interesst
[11:52] <rob> he mentioned it was undergoing a rewrite
[11:52] <mvo> rob: not exactly a rewrite, but a big refactor, the current tree that is in dapper is at http://people.ubuntu.com/~mvo/bzr/gai--main/
[11:52] <mjg59> ogra: If it's running as root and you gain any control over it, you've lost already
[11:52] <mvo> it has the current treeview design
[11:52] <mvo> the new look is at http://people.ubuntu.com/~mvo/bzr/gai--new-look/
[11:53] <mvo> I hope to get it into dapper, i like it better than the "old" look
[11:53] <mvo> rob: http://people.ubuntu.com/~mvo/gnome-app-install/new-look/gai--new-look.png
[11:53] <ogra> mjg59, hmm, true ...
[11:54] <rob> mvo, yes so do I, actually I was going to suggest an "unsupported packages" feature :)
[11:54] <rob> and spliting the layout like that makes it much clearer
[11:55] <rob> will you accept patches on gai--new-look?
[11:56] <mvo> rob: sure, happy to merge from your bzr branch!
[11:56] <mvo> rob: it should work reasonable well already, but there are some smaller bugs I think
[11:56] <rob> ok, I'll have to get it set up, this is the first time I've looked at the new code
[11:56] <mvo> happy to help you with the code or any other questions
[11:56] <rob> thanks, sounds good
[11:56] <mvo> to build a package just run debian/rules arch-build
[11:57] <rob> ok
[11:58] <rob> I gotta go put my daughter to sleep, thanks I'll take a look and get back to you soon