[00:40] <Hobbsee> slangasek: what do you want with bugs that are a "please test if this is fixed in the next alpha"?
[00:41]  * Hobbsee milestones, assigns to her, etc
[01:16] <TheMuso> c
[03:00] <superm1> if any archive admins are about, can you see why https://edge.launchpad.net/ubuntu/+source/mythtv/0.21.0~fixes16338-0ubuntu3/+build/530056 hasn't hit the archive yet?  It built like 8 hours ago.
[03:01] <superm1> and its not in NEW
[03:19] <nosredna_ekim> jcastro: ping.
[03:52] <slangasek> Hobbsee: hmm, not sure what you mean; is the bug a serious one that needs milestoned in the first place, is the bug marked as 'fix released'...?
[04:06] <Hobbsee> slangasek: it's a "i could reproduce this originally, and it's not good for the final release if it's reproducable - it needs testing during our testing for t6
[04:06]  * Hobbsee can't seem to reproduce it now
[04:07] <slangasek> ok; probably nominating/targetting it for hardy would be best I think
[04:08] <Hobbsee> mhmm.  with the rest of them, that people say "affects hardy.  we hope it gets fixed sometime, but we have no fix in sight" ones
[04:08] <Hobbsee> (that's why i don't use affecting hardy
[04:08] <Hobbsee> )
[04:09] <superm1> slangasek, would you mind checking why a build from about 8 hours didn't publish yet?
[04:09] <Hobbsee> superm1: is probably soyuz bug :)
[04:09] <slangasek> Hobbsee: well, I mean for the bugs that are targetted for hardy to actually be fixed for hardy in accordance with their severities :)
[04:09] <slangasek> superm1: sure, what do you have?
[04:10] <superm1> https://edge.launchpad.net/ubuntu/+source/mythtv/0.21.0~fixes16338-0ubuntu3/+build/530056
[04:10] <Hobbsee> slangasek: that's not what the others tend to use it for, but yeah
[04:10] <superm1> Hobbsee, now lets not be pessimistic or anything...
[04:10] <Hobbsee> oh damn, i didn't bring my laptop
[04:10]  * Hobbsee could have rsynced.
[04:10] <Hobbsee> superm1: of course not.  just aware of the way soyuz likes to work.
[04:11] <Hobbsee> superm1: it's either in the new queue, or its' a bug, and soyuz has gotten hungry again.
[04:11] <superm1> its not in the new queue
[04:11] <superm1> nothing has changed with it that would have put it there, and i looked there a little bit ago to make sure
[04:11] <superm1> see and i dont even talk bad about soyuz, why would it want to eat my builds?
[04:11] <superm1> if anything it should eat yours :)
[04:12] <Hobbsee> hah
[04:13]  * Hobbsee looks, blinks
[04:14] <Hobbsee> superm1: erm.  what makes you think it's not published?
[04:14] <slangasek> superm1: https://edge.launchpad.net/ubuntu/hardy/+source/mythtv/0.21.0~fixes16338-0ubuntu3/ shows it as 'done', yeah
[04:14] <superm1> Hobbsee, it hasn't shown up on archive.ubuntu.com or packages.ubuntu.com
[04:15] <slangasek> and drescher agrees that it's there...
[04:15] <Hobbsee> http://archive.ubuntu.com/ubuntu/pool/multiverse/m/mythtv/
[04:15]  * Hobbsee points at mythtv-backends
[04:15] <superm1> look at mythtv-common
[04:15] <Hobbsee> http://archive.ubuntu.com/ubuntu/pool/multiverse/m/mythtv/mythtv-backend_0.21.0~fixes16338-0ubuntu3_amd64.deb
[04:15] <superm1> in archive.ubuntu.com
[04:15] <superm1> its missing
[04:15] <Hobbsee> oh, hmm
[04:16] <Hobbsee> so, some of the binaries are there
[04:16] <superm1> along with the rest of i386
[04:16] <Hobbsee> superm1: mythtv-common is arch: all?
[04:16] <superm1> yeah
[04:16] <Hobbsee> i thought it might be
[04:17] <Hobbsee> superm1: it' ssitting on launchpad i fyou awnt to grab it from there
[04:17] <Hobbsee> but, uh, i suspect that's a soyuz bug :)
[04:18] <superm1> Hobbsee, its not a big deal for myself, but when the alternate disks go to build in 3 or 4 hours, they aren't going to like it
[04:19] <slangasek> the CD builds pull directly from drescher, though
[04:20] <slangasek> so if there's an issue preventing it from being visible for archive.ubuntu.com, that won't affect the CD builds anyway
[04:20] <Hobbsee> superm1: i think you'll need to poke cprov over that, and he doesnt' appear to be around.
[04:20] <slangasek> mythtv-common | 0.21.0~fixes16338-0ubuntu3 | hardy/multiverse | all
[04:20] <slangasek> that's the one you're looking for?
[04:20] <Hobbsee> yes
[04:23] <superm1> well if the cd builds right from drescher not a big deal
[04:23] <superm1> that's the only thing that really matters to  get it in "tonight"
[04:23] <superm1> i'll wait for cprov tomorrow then for fixing it on a.u.c and p.u.c
[04:24] <superm1> yup
[04:25] <Hobbsee> hmm.  i need noise cancelling earphones, or to kick these giggling girls out of the lab.
[04:26] <StevenK> Heh
[04:26] <Hobbsee> and then people complain about not that many females in IT.  Well, if they act like that, then no...
[04:26] <Hobbsee> There's a shopping centre ~10 mins away.  go there!
[04:39] <TheMuso> Aw
[04:40] <StevenK> Aw?
[04:40] <TheMuso> StevenK: supposed to be /aw
[05:27] <TheMuso> _MIf you have the ubuntustudio splah installed, you may also have to remove that.
[05:27] <TheMuso> gah wrong channel
[05:35] <bryce> wasabi: glad you like the gui - were my bug fix updates from today enough to get things sorted?
[05:39] <slangasek> superm1: yah, it doesn't build "right" from drescher, but the CD build servers all mirror directly from drescher
[05:44] <bryce> wasabi: thanks, I've noted the feature requests.  Perhaps a hardy+1/+2 type thing
[05:44] <bryce> wasabi: if you're ever interested in doing some cairo/gtk hacking, I'd be happy to point you at the code (it's not terribly complex) and explain it
[06:52]  * Hobbsee smashes wget against a brick wall
[07:12] <pitti> Good morning
[07:13]  * slangasek waves
[07:13] <cody-somerville> Heya pitti
[07:26] <slangasek> ogra_: artwork> which package does this refer to, precisely?
[07:27] <ogra_> ogra@ceron:~/devel/packages/gfxboot-theme-ubuntu-0.5.3$ dpkg -S /usr/share/backgrounds/simple-ubuntu.png
[07:27] <ogra_> ubuntu-wallpapers: /usr/share/backgrounds/simple-ubuntu.png
[07:27] <ogra_> wallpapers ...
[07:28] <ogra_> but i suspect other artwork packages might have grown as well ...
[07:28] <TheMuso> slangasek: I would need to check, but all the sounds for the sound scheme are at 44100Hz, 16 bit Stereo. At the least, I could resample them to 22050, and for a sound scheme, that wouldn't impact on their quality much for general use anyway.
[07:28] <TheMuso> slangasek: So, ubuntu-sounds being 2.3 currently, could be taken down to about 1.5/1.6 probably...
[07:29] <slangasek> ogra_: yes, could be.  ubuntu-wallpapers hasn't changed since alpha-5, so it doesn't account for the size increase - but of course if we can slim it back down again, that would be welcome all the same
[07:29] <ogra_> TheMuso, do we still use .wav files ?
[07:29] <TheMuso> ogra_: We do indeed, and thats all we can use, due to the audiofile library being used.
[07:29] <TheMuso> afaik
[07:30] <ogra_> slangasek, well, 3.5M is quite heavy for a wallpaper imho
[07:30] <ogra_> TheMuso, hrm ... we should really look into switching to ogg
[07:30] <TheMuso> ogra_: files of many common formats (currently AIFF, AIFF-C, WAVE, NeXT/Sun, BICS, and raw data).
[07:30] <ogra_> to gain some compression
[07:30] <TheMuso> ogra_: Willing to massively edit either the audiofile library, or GNOME code proper?
[07:31] <ogra_> TheMuso, lest talk about that after hardy is out :) i cant oredict my workload for interpid yet since so much changed in edubuntu land
[07:31] <TheMuso> ogra_: Something like that needs doing upstrea.
[07:31] <asac> TheMuso: how do i test the scim thing?
[07:31] <TheMuso> ogra_: I'm just saying its a lot of work.
[07:32] <ogra_> right, i'm aware :)
[07:32] <TheMuso> asac: I can't remember without looking it up./
[07:32] <slangasek> rather unfortunate that GNOME has this lovely gstreamer framework, but system sounds can only be .wav files :-P
[07:32] <ogra_> asac, open the scim gui, select de nodeadkeys, re-login is what i did
[07:32] <TheMuso> slangasek: Indeed.
[07:32] <TheMuso> slangasek: But it is an option, and I can do it if 1.3 or so MB is that critical.
[07:33] <ogra_> slangasek, there was a patch floating around that made the systeem sounds use gstreamer as well i think it was abandoned :(
[07:34] <slangasek> TheMuso: let me see what happens after the latest round of liveCD builds, and after I try to fix python2.5+db4.6 so we can kick db4.2 back off, and I'll see where we are; making changes to the fundamentals of GNOME sound handling is not a useful fix for alpha-6, and I'd rather not have to short us on sound quality either
[07:35]  * cjwatson trims 50KB off the CD boot menu; every little helps
[07:35] <TheMuso> slangasek: Ok fair enough.
[07:35]  * TheMuso should really do a new scheme one day...
[07:36] <slangasek> one place where I know we ought to be trimming for sure is the fact that we now have two distinct gtk2 engines being pulled in by human-theme on the Ubuntu CD
[07:36] <slangasek> but I'm not sure which one needs to be gotten rid of yet
[07:37] <cjwatson> slangasek: Ken didn't reply last night, I take it?
[07:37] <Amaranth> slangasek: Wasn't clearlooks already on the CD?
[07:37] <ogra__> it should be dropped if that is the case
[07:38] <ogra__> we default to murrine now
[07:38] <slangasek> cjwatson: nope, hoping he's a fairly early riser :)
[07:38] <slangasek> Amaranth: this is gtk2-engines-murrine vs. gtk2-engines-ubuntulooks
[07:38] <Amaranth> slangasek: oh, in that case i thought ubuntulooks was being dropped
[07:38] <slangasek> ogra__: so -ubuntulooks isn't used and can be dropped without ill effect?
[07:38] <Amaranth> that was the point of redoing the themes using clearlooks and murrine
[07:39] <slangasek> Amaranth: makes sense, I just have no clue whether we're at the point where -ubuntulooks is ready to be dropped, do you?
[07:39] <cjwatson> -ubuntulooks is only 40KB though?
[07:39] <ogra__> slangasek, well, my installs all use murrine by default here, not sure kwwii wants to ship a fallback with Human, that would require clearlooks indeed
[07:39] <cjwatson> pulls in a bunch of libraries, but I assume most of those are used by something else
[07:39] <Amaranth> slangasek: Well, I'd say no, the other two themes...need some work
[07:39] <slangasek> cjwatson: ah, argh
[07:40] <slangasek> cjwatson: alright, moving that to the "every little bit counts" pile
[07:40] <ogra__> heh
[07:40] <slangasek> cjwatson: yes, all the libs it pulls in are already there
[07:41] <slangasek> Amaranth: umm... are they "not happening for hardy" need some work, or "needs to get done by hardy" need some work?
[07:41] <Amaranth> I suspect the latter
[07:41] <Amaranth> Probably just need someone to spend a day with them polishing
[07:41] <slangasek> whichever side they fall on, we should cut the other end off as long as it still leaves us with a functional desktop :-)
[07:42] <Amaranth> they work fine, they just need some tweaking (tooltips aren't themed properly, etc)
[07:42] <ogra__> hmm, using pngcrush on the wallpaper actually gains zero ... thats really strange
[07:43] <Amaranth> ogra__: someone crushed it already?
[07:43] <ogra__> Amaranth, but its stil 3.5M
[07:44] <Amaranth> well, pngcrush just removes metadata
[07:44] <ogra__> it makes my classmate desktop unresponsive while it loads
[07:44] <Amaranth> it doesn't compress the image more or anything
[07:44] <ogra__> oh, i thought it does
[07:45] <Amaranth> oh, i guess it does
[07:45] <slangasek> 703M	daily-live/20080305/hardy-desktop-amd64.iso
[07:45] <slangasek> 705M	daily-live/20080305/hardy-desktop-i386.iso
[07:45] <slangasek> hnngh
[07:45] <Amaranth> i was thinking of another tool
[07:45] <Amaranth> slangasek: drop gthumb ;)
[07:46] <slangasek> Amaranth: in favor of?
[07:46] <ogra__> slangasek, amd64 alternate is fine ... lets just resort to that one :P
[07:46] <Amaranth> slangasek: well, we have fspot already
[07:46] <ogra__> slangasek, we have f-spot in the default install
[07:46] <Amaranth> but this debate has gone on for like 3 releases now
[07:47] <superm1> slangasek, unfortunately it still used the wrong packages for this build.  guess we'll have to wait until tomorrow for more luck :(
[07:47] <ogra__> but people will complain if you drom gthumb
[07:47] <ogra__> *drop
[07:47] <pitti> didn't we already drop gthumb?
[07:47] <cjwatson> can we not have the applications debate *again*
[07:47] <pitti> yes, we did; it even wants to go to universe, needs seeding
[07:47] <slangasek> pitti: yes
[07:47] <Amaranth> oh, yay
[07:47] <Amaranth> but oh, still need rom
[07:47] <Amaranth> room*
[07:48]  * Amaranth uninstalls gthumb
[07:48] <slangasek> superm1: mmm, odd
[07:48]  * pitti wonders what used up some 80 MB since alpha-4
[07:49] <Amaranth> yeah, i thought alpha 4 was way under the limit
[07:49] <Amaranth> i can't think of anything that got added though
[07:49] <pitti> some 650 MB including some langpacks, yes
[07:49] <slangasek> the manifest diff between alpha-5 and alpha-6 is short enough, but looking through for which packages have grown would take some doing
[07:50] <Amaranth> are those langpacks still on the disc?
[07:50] <pitti> slangasek: for the alternates we could flip some large packages to lzma
[07:50] <slangasek> and none of the alpha-4 metadata is still around, sigh
[07:50] <Amaranth> maybe just drop them again for now?
[07:50] <pitti> Amaranth: we did
[07:50] <Amaranth> oh, i missed that bit
[07:50] <pitti> Amaranth: that's where the other ~ 30 MB from my estimation (80 MB) come from
[07:50] <Amaranth> stupid splits :P
[07:51] <slangasek> pitti: alternates don't concern me nearly as much; as soon as OOo-l10n lands, I understand we'll already have more space there
[07:51] <pitti> ah, right, lzma FTW
[07:51] <ogra__> is there a howto anywhere for switching packages to lzma ?
[07:52]  * ogra__ would like to see how gcompris would behave with that
[07:52] <cjwatson> it ought to be possible to take the manifest diff and feed it to something that downloads all the old packages from the librarian and compares sizes
[07:52] <cjwatson> might want to do that inside the DC, of course
[07:52] <slangasek> ogra__: dh_builddeb -- -Zlzma; but calc already did the archive analysis on which packages benefit most, I think
[07:53] <ogra__> slangasek, ah, thanks
[07:53] <cjwatson> ogra__: dh_builddeb -- -Zlzma, pre-depends: dpkg (>= 1.14.12ubuntu3)
[07:53] <ogra__> well, gcompris is 60M source :)
[07:53] <ogra__> it should gain *something*
[07:54] <slangasek> ogra__: there's a space/performance trade-off with lzma; the focus is (and IMHO should be) on deploying it first in the packages with the largest footprint
[07:54] <slangasek> hrm
[07:54] <ogra__> gcompris is my largest package in edu land ...
[07:55] <slangasek> bloody hell, I was looking at the ship seed before, not the live CD; live still has a number of langpacks that can be unseeded if necessary :/
[07:55] <ogra__> the binaries take about 80M or so ... i dont have space constraints on the addon CD atm though
[07:55] <cjwatson> slangasek: it may be that calc only looked at the Ubuntu CDs
[07:56] <slangasek> cjwatson: oh, possible, yes
[07:58] <fabbione> Spads, Ng: ping?
[07:58] <fabbione> oh wrong channel
[08:22] <tjaalton> where's openoffice.org-common for 2.4.0rc2?
[08:24] <tjaalton> slangasek: mind if I upload oo.org-voikko for a rebuild?
[08:25] <slangasek> tjaalton: go ahead, please
[08:25] <tjaalton> slangasek: thanks
[08:25] <slangasek> openoffice.org-common> what do you mean? I see it in the archive where it should be?
[08:25] <tjaalton> slangasek: ok, maybe archive problems again? it's not on a.u.c
[08:26] <slangasek> yes, superm1 was mentioning mythtv wasn't making it to a.u.c either
[08:26] <pitti> OO.o not installable on amd64 for me either
[08:27] <emgent> morning
[08:32] <tjaalton> slangasek: hmm, there's also voikko 2.2-1 in unstable, which seems to add some additional support for OO.o 2.4. maybe sync that?
[08:32] <tjaalton> not too many changes
[08:32] <slangasek> are you asking me to sync it, or are you asking my opinion on whether a sync is appropriate?: )
[08:32] <tjaalton> well, both :)
[08:34] <tjaalton> slangasek: I'll try a pbuilder run first
[08:36] <slangasek> "Sorry, Gestor de actualizaciones closed unexpectedly"
[08:36]  * slangasek twitch
[08:36] <cjwatson> slangasek: BTW, while live filesystems do build straight from drescher, the archive mirror on antimony comes from syncproxy
[08:36] <cjwatson> slangasek: and it looks like that's out of date
[08:37] <tjaalton> "Cannot install 'openoffice.org-dev'E: pbuilder-satisfydepends failed."
[08:37] <tjaalton> so much for trying pbuilder
[08:37] <cjwatson> I was expecting partman-ext3 49ubuntu2 to be there, which is timestamped 22:05 last night on drescher, but it isn't
[08:38] <cjwatson> slangasek: have you poked IS about it yet?
[08:38] <slangasek> cjwatson: ah, I hadn't poked, no
[08:38] <seb128> pitti, slangasek: any opinion if we should switch evolution-data-server to use gnome-keyring in hardy? Currently passwords are stored in the user directory, keyring would be better but there is no migration which means users would have to re-enter their password on upgrade
[08:52] <stgraber> Riddell: around ?
[08:53] <pitti> seb128: I'm all for consolidating to gnome-keyring
[08:54] <pitti> seb128: it's much easier to do backups, put keys on USB stick, etc.
[08:54] <seb128> pitti: do you think having to re-enter the passwords is an issue we need to fix though?
[08:54] <pitti> seb128: hm, wrt. bug 196962, do you remember the decision about rb vs. sj for audio CDs?
[08:54] <ubotu> Launchpad bug 196962 in gnome-volume-manager "Audio CD launches both Rhythmbox and Sound Juicer" [Undecided,New] https://launchpad.net/bugs/196962
[08:54] <seb128> pitti: launch rhythmbox
[08:54] <pitti> seb128: if we could fix that, the evo keyring would be badly protected :)
[08:55] <pitti> seb128: but it's just entering your password once for the hardy upgrade, right? that seems bearable to me
[08:55] <pitti> seb128: rb> ok, fixing in gvm then
[08:55] <seb128> pitti: well, evolution passwords are not protected right now, evolution could read those and store them in the keyring if they are not there
[08:55] <seb128> pitti: yes
[08:55] <pitti> oh, one more reason to do that switch
[08:56] <pitti> seb128: so, IMHO it's  worth an upstream bug report to do that transition, but if it won't happen, I don't think that it bites too much
[08:56] <seb128> pitti: I though we stopped using gvm for mounting?
[08:56] <pitti> seb128: I'd like to see the evo keyring cleaned on upgrade, though
[08:56] <seb128> pitti: I talked to upstream about it, they will likely do something but maybe not before hardy
[08:56] <seb128> pitti: right
[08:56] <pitti> seb128: gvm> it still handles scanners, printers, and the like
[08:57] <pitti> and cameras
[08:57] <seb128> pitti: right, but audio CD should be nautilus
[08:57] <pitti> I agree
[08:57] <pitti> just wanted to confirm with you
[08:57]  * pitti hugs seb128
[08:57]  * seb128 hugs pitti
[08:57] <pitti> seb128: btw, we already have the first complaints about that :)
[08:57] <slangasek> seb128: I'm never happy when users (particularly those named Steve) have to reenter information after upgrades.  Is gnome-keyring already supported by e-d-s upstream as an option, and is there any prospect of migration support in the future?
[08:57] <seb128> pitti: I'm not sure what you are fixing in gvm for rb then?
[08:58] <seb128> pitti: about what?
[08:58] <pitti> seb128: complaint> bug 198505
[08:58] <ubotu> Launchpad bug 198505 in gnome-volume-manager "gnome-volume-manager does not mount devices any more in hardy" [Undecided,Won't fix] https://launchpad.net/bugs/198505
[08:58] <pitti> seb128: apparently gvm still launches sj
[08:58] <pitti> so I'll make it not do that
[08:59] <seb128> alright
[08:59] <seb128> thanks
[08:59] <seb128> slangasek: what I wrote to pitti before, keyring is supported and other distros use it now, there is no migration code but upstream agree that would be nice to do, somebody needs to write this code though
[09:00] <slangasek> mm right
[09:02] <slangasek> well, I take the view that if it wasn't hurting users before now to have the passwords outside of gnome-keyring, leaving them there until a migration path is available is not a big deal and I'd rather have the user experience right
[09:03] <seb128> I tend to agree with that
[09:03] <slangasek> what's the likelihood the upstream bits would be ready in time for the hardy point release?
[09:03] <seb128> I would like to use the keyring though, I'll try to get somebody upstream helping getting that migration code before hardy beta
[09:17] <seb128> are daily cd images mirrored? cdimage.ubuntu.com is slow today
[09:17] <slangasek> there are no mirrors of dailies, no
[09:17] <seb128> ok, thanks
[09:17] <seb128> slangasek: and for milestones?
[09:18] <slangasek> alphas, also no
[09:18] <seb128> ok
[09:21] <cjwatson> I have a really impressive metacity bug here; the window switcher (i.e. the pop-up when you use C-A-<cursor> to move between workspaces) has got stuck on, and won't (a) go away or (b) let me move out of the first row of workspaces
[09:21] <cjwatson> I'm going to have to kill my X session once various stuff has finished running, but is there anything I can do in the meantime to diagnose this?
[09:22] <cjwatson> it started while some pretty heavy disk I/O was going on
[09:22] <seb128> are other window manager things, moving, switching between tasks, etc still working?
[09:23] <seb128> cjwatson: why do you need to restart the session? restarting the wm should be enough no?
[09:23] <cjwatson> I can move between workspaces, but not Alt-Tab, and the window switcher has keyboard focus so I can't do anything useful
[09:24] <cjwatson> restarting the window manager would probably be enough, true
[09:24] <seb128> no idea on what debug information would be useful
[09:24] <seb128> it doesn't seem to be stucked so a backtrace would likely be of no use
[09:25] <seb128> the most useful information would be a way to trigger the bug
[09:25] <seb128> I would say you can just restart it
[09:26] <cjwatson> yeah, I've never seen it before - if I see it again I'll try to find common features
[09:26] <ogra_cmpc> cjwatson, i had some similar things with my alt key the last days ... not actually metacity i guess but similar
[09:26] <huats> moring seb128
[09:26] <ogra_cmpc> like if i click on a window i can only move it (like with a stuck altkey)
[09:27] <seb128> hi huats
[09:27] <seb128> ogra_cmpc: there is a linux or xorg bug about key events being continuously generated sometimes
[09:27] <cjwatson> ogra_cmpc: I don't think it's that; setxkbmap normally clears that kind of thing for me and doesn't help in this case
[09:28] <ogra_cmpc> it didnt for me
[09:28] <ogra_cmpc> and given that it happened on the classmate it verz likely happened under heavy disk IO
[09:28] <ogra_cmpc> *very
[09:28] <cjwatson> stracing metacity from a console says it's very busy, constantly reading/writing
[09:28] <cjwatson> it could well be a stuck key event
[09:29] <ogra_cmpc> thats what i mean
[09:29] <seb128> cjwatson: xev?
[09:29] <ogra_cmpc> i had that happening before always related to the alt key
[09:29] <cjwatson> seb128: how do I get metacity's windowid from a console?
[09:30] <cjwatson> ah, xwininfo
[09:30] <seb128> I was going to suggest xprop but that should do it too
[09:30] <cjwatson> hm, xev isn't saying anything
[09:31] <Amaranth> cjwatson: there are some bugs reported against xorg about keys getting stuck
[09:31] <Amaranth> mostly page down and such but i suppose alt could get stuck too
[09:32] <Amaranth> bug 194214
[09:32] <ubotu> Launchpad bug 194214 in xorg-server "Keys get "stuck" down" [Medium,Confirmed] https://launchpad.net/bugs/194214
[09:32] <Fujitsu> I often get Tab, and something that doesn't seem to be real, stuck.
[09:32] <ogra_cmpc> i've had that in feisty and gutsy happening as well at least once every release cycle
[09:32] <Fujitsu> Amaranth: There's another very similar to that.
[09:32] <ogra_cmpc> and it always seemed related to IO
[09:33] <Amaranth> ogra_cmpc: i believe the original reporter was scrolling in firefox when it happened, dunno if that'd hit the disk or not
[09:33] <Amaranth> certainly spikes your CPU
[09:33] <ogra_cmpc> indeed
[09:33] <Fujitsu> That fits with my tab key getting stuck, it was during 100% load.
[09:33] <ogra_cmpc> i only have it happening on special key combos (alt+tab etc) and if there is actually lots of disk IO
[09:34] <Fujitsu> (CPU load)
[09:34] <ogra_cmpc> havent seen it in normal browser operation or so
[09:35] <RAOF> ogra_cmpc: I'm not sure that it's related to CPU load; it also seems to correlate with mouse activity.
[09:35] <ogra_cmpc> might be
[09:35] <ogra_cmpc> it usually went away with the next kernel upgrade for me ...
[09:35] <Fujitsu> RAOF: Not for me.
[09:35] <cjwatson> disk I/O> I was doing 'dd if=/dev/zero of=alt.img bs=1024 count=$((3*1024*1024))' and simultaneously rsyncing a CD image
[09:35] <cjwatson> probably not massive CPU load involved
[09:36] <ogra_cmpc> the prob its that it occurs so randomly that you cant even reliably reproduce it
[09:37] <RAOF> ogra_cmpc: *I* can.  It's nice and easy to reproduce.
[09:37] <ogra_cmpc> ah
[09:37] <RAOF> Hold down a key, scroll madly in firefox.
[09:37] <RAOF> Tada!  Key is stuck down.
[09:37] <pwnguin> ive been having problems where enter gets stuck for a moment
[09:37] <cjwatson> pwnguin: yes, also that
[09:37] <pwnguin> esp if i run something like apt-get upgrade
[09:37] <RAOF> Also works in WoW, but you don't need to scroll madly.
[09:38] <cjwatson> iwj conjectured that it might have something to do with the fact that my CPU is hyperthreaded
[09:38] <cjwatson> or at least might be easier to reproduce given that
[09:38] <pwnguin> mine's dual core
[09:38] <pwnguin> all mine are
[09:38] <ogra_cmpc> well, mine isnt,  neither here on the classmate nor on the laptop where i saw the issue in other releases
[09:39] <RAOF> *Definitely* not firefox related.  Hold down 'a', scroll madly in gedit.  'a' is no stuck down.
[09:39] <RAOF> s/no/now/
[09:39] <RAOF> Also probably not CPU load related, my laptop's not doing _too_ much.  One core is ~50%, the other is idle.
[09:40] <ogra_cmpc> whats the load average at ?
[09:41] <dbmoodb> hi is there a social contract for ubuntu like debians ?
[09:41] <cjwatson> bug 124406 has a massive pile of key repeat reports
[09:41] <ogra_cmpc> dbmoodb, search for "code of conduct"
[09:41] <ubotu> Launchpad bug 124406 in ubuntu "Keyboard keys get stuck and repeat (Feisty, Gutsy) (dup-of: 194214)" [Undecided,Confirmed] https://launchpad.net/bugs/124406
[09:41] <ubotu> Launchpad bug 194214 in xorg-server "Keys get "stuck" down" [Medium,Confirmed] https://launchpad.net/bugs/194214
[09:41] <dbmoodb> but that is not a contract is it ?
[09:41] <pwnguin> dbmoodb: there's a code of conduct, and a set of core beliefs, but not i dont think theres anything quite like debian's dfsg
[09:41] <RAOF> 1.63.  Hm, tracker must be indexing.
[09:41] <ogra_cmpc> ubuntu members have to sign it
[09:41] <cjwatson> ogra_cmpc: it's not the same thing
[09:42] <ogra_cmpc> right, but similar
[09:42] <dbmoodb> --- not dfsg -- social contract - 'debian will remain free' kind of thing
[09:42] <pwnguin> there's the Ubuntu Promise
[09:42] <dbmoodb> is there a contract
[09:42] <dbmoodb> a legally binding document
[09:42] <pwnguin> dfsg is part of the social contract of debian
[09:42] <pwnguin> it defines what Free means
[09:42] <cjwatson> the Debian Social Contract is NOT legally binding
[09:42] <ogra_cmpc> heh
[09:42] <dbmoodb> it is
[09:42] <cjwatson> there is no consideration involved and therefore it cannot be
[09:43] <pwnguin> its more like a constitution
[09:43] <cjwatson> in order for a contract to be binding it must involve consideration in both directions
[09:43] <slangasek> dbmoodb: no, it is not
[09:43] <cjwatson> dbmoodb: there isn't a single document that's like the Debian Social Contract, but there are a number of things that address different bits of it; the licensing policy, the code of conduct, the Ubuntu Promise
[09:43] <dbmoodb> it does
[09:44] <cjwatson> dbmoodb: slangasek and I are both Debian developers
[09:44] <dbmoodb> ok so is ubuntu promised to remain "free"
[09:44] <cjwatson> dbmoodb: yes, it's right there on www.ubuntu.com
[09:44] <dbmoodb> -where
[09:44] <cjwatson> front page
[09:44] <pwnguin> if you're looking for guiding philosophies
[09:44] <pwnguin> http://www.ubuntu.com/community/ubuntustory/philosophy
[09:44] <dbmoodb>  the promise ?
[09:44] <cjwatson> "Ubuntu will always remain free of charge" and "Ubuntu CDs contain only free software applications"
[09:45] <cjwatson> and, as pwnguin says, the philosophy link for more detail
[09:45] <ogra_cmpc> heh, googling ubuntu promise brings up an intresting pile of scsi howtos :)
[09:45] <dbmoodb> ok ... so how is it different to the dfsg ?
[09:45] <cjwatson> we are not going to compromise Ubuntu's freedom as stated on the philosophy and licensing pages
[09:46] <dbmoodb> sure
[09:46] <cjwatson> the differences between Ubuntu's licensing policy and the DFSG are quite small; in essence they amount to more liberal treatment of non-code works
[09:47] <pwnguin> well number one, developers can't vote to change the policy as far as i can tell
[09:47] <cjwatson> see "Documentation, Firmware, and Drivers" on the licensing page
[09:47] <dbmoodb> ok...
[09:47] <cjwatson> other than that, the Ubuntu licensing policy is largely just a rephrasing of the DFSG
[09:48] <cjwatson> and that should be pretty obvious from reading them side-by-side
[09:49] <dbmoodb> - yes i  got that that is why i was wondering
[09:49] <dbmoodb> if there was a social contract ")
[09:50] <pwnguin> its probably better off without one
[09:51] <pwnguin> lest an argument break out whether "a comma is a typo widely held belief"
[09:59] <\sh> guys I'm really lost...and at the end of my knowledge somehow
[10:02] <\sh> Building wine in pbuilder and on a clean chroot (which is used for sbuild, too) wine works like a charm...
[10:02] <seb128> carlos, pitti: any language pack update planned then?
[10:03] <seb128> carlos, pitti: would be nice to have a reflect of the GNOME current translations on current dailies
[10:03] <pitti> can do, but it'll block the buildds quite a bit
[10:03] <pitti> slangasek: ^ ok?
[10:03] <\sh> building wine as package, the binaries in the package are borked...and I don't see anything in my buildlogs what triggers it...(this is the cause why wine is not running in the moment...building it on our buildds or in any plain sbuild chroot bring us broken binaries)
[10:03] <slangasek> pitti: are the packages going to get bigger? :/
[10:03] <pitti> slangasek: smaller, since it's a -base refreshment
[10:03] <seb128> carlos: btw did you get the list of packages not building a template?
[10:04] <slangasek> ok, go ahead please
[10:05] <carlos> seb128: still working on that..
[10:05] <pitti> oh, argh
[10:05] <pitti> no, nevermind; unargh
[10:06] <seb128> carlos: any estimation on how long it'll take? I would like to start fixing those issues, just to know if I should wait or try building a list by some other way
[10:06]  * seb128 hugs pitti
[10:07] <pitti> carlos: btw, we got new KDE l10n packages yesterday, so I guess next week we should do another -base refreshment?
[10:09] <cjwatson> holy crap, I didn't expect to get that partman-auto change right first time
[10:12] <soren> cjwatson: Which one is that?
[10:13] <cjwatson> the first part of fixing bug 134950
[10:13] <ubotu> Launchpad bug 134950 in partman-auto "auto-resize primary partition constraints are too strong" [High,Triaged] https://launchpad.net/bugs/134950
[10:18] <Riddell> pitti: those are kde 4, they're not in rosetta
[10:22] <pitti> Riddell: ok, not necessary then
[10:22] <lool> doko: Around?
[10:23] <doko> lool: yes
[10:23] <lool> doko: Someone uploaded a new python-twill a while ago which depends on python-mechanize (>= 0.1.7b-2)
[10:23] <doko> and that one doesn't exist, correct?
[10:23] <lool> doko: Do you think it would be possible to solve this by updating python-mechanize?
[10:23] <lool> doko: It does, but is too old
[10:23] <lool> I mailed the uploader some 10 days ago to no luck
[10:24] <lool> Michele Angrisano
[10:24] <doko> I would have to look, maybe email jinti (Brian Sutherland) if that version is ok for other packages (schooltool, zope)?
[10:24] <lool> slangasek: (Is it ok to push this to solve an uninstallability issue?)
[10:25] <lool> doko: Could you do it?  I don't know this guy and haven't played with zope things for a while
[10:25] <slangasek> lool: "this one" being python-twill?
[10:25] <lool> slangasek: Yes
[10:25] <slangasek> lool: it's in universe so not subject to alpha freeze, and it's a bugfix so not subject to feature freeze
[10:25] <lool> doko: python-twill is a dep of elisa, the media center
[10:26] <lool> Ah right, for some reason I thought it was in main
[10:26] <lool> slangasek: Thanks
[10:26] <slangasek> n/p
[10:29] <lool> doko: But if you're busy, I'll do it naturally
[10:45]  * ogra_cmpc mumbles about -o ControlPath= not working in sftp
[10:48] <ogra_cmpc> grrrr
[10:52] <soren> pitti: In https://bugs.edge.launchpad.net/ubuntu/+source/dnsmasq/+bug/190905/comments/3 you ask me to LSBify the dnsmasq init script.. I'm curious what that means? There's already the Provides:, Required-start:, etc. headers at the top. What else does LSBification entail?
[10:52] <ubotu> Launchpad bug 190905 in dnsmasq "Main inclusion report." [High,Incomplete]
[10:52] <tjaalton> slangasek: oo.o-voikko 2.2-1 build fine on a current pbuilder and works too
[10:52] <pitti> soren: using log_daemon_msg, log_end_msg, etc. instead of echo
[10:53] <soren> pitti: Ah, of course.
[10:53] <soren> pitti: Got it.
[10:53] <pitti> so that usplash, logging, etc. works
[10:53] <soren> Right, right. Got it :)
[10:54] <seb128> mvo, slangasek: hum, usershare is not working correctly, smbclient gets a NT_STATUS_ACCESS_DENIED when trying to browse the share in anonymous or NT_STATUS_LOGON_FAILURE when using my login and the samba log has a stat permission error
[10:55] <slangasek> seb128: hrm, strange :/
[10:57] <slangasek> seb128: oh, do you have smbpasswd set up?  There's no PAM integration there yet
[10:58] <slangasek> (was jdstrand taking care of that with auth-client-config??)
[10:58] <slangasek> s/\?//
[10:59] <pwnguin> well that was cute
[10:59] <pwnguin> i was playing a game and w decided to stick on
[10:59] <seb128> slangasek: no, I though that one thing netshare was going to bring us what to avoid the need to use smbpasswd
[10:59] <slangasek> seb128: er, no
[11:00] <seb128> slangasek: I'm using "guest_ok=y" in this share
[11:00] <slangasek> net usershare gets you easy setup of fileshares
[11:00] <seb128> shouldn't anonymous work?
[11:00] <slangasek> but modern Windows clients will *not* negotiate authentication with servers that require cleartext passwords
[11:00] <slangasek> one would think anonymous would work then, yes; let me see
[11:00] <soren> Using log_*_msg, what's the canonical why to give additional info about why a daemon is failing to start?
[11:01] <slangasek> $ smbclient //localhost/moo -N
[11:01] <slangasek> Anonymous login successful
[11:01] <slangasek> Domain=[MSHOME] OS=[Unix] Server=[Samba 3.0.28]
[11:01] <slangasek> tree connect failed: NT_STATUS_ACCESS_DENIED
[11:01] <seb128> slangasek: that's what I get too
[11:02] <soren> log_warning_msg perhaps?
[11:02] <seb128> slangasek: the /var/log/samba has a stat permission error on the corresponding usershares configuration
[11:02]  * ogra_cmpc doesnt get why ssh -S /tmp/ssh_socket <ip> works, but sshfs -o ControlPath=/tmp/ssh_socket <IP>:<dir> ./mnt/ doesnt ... :(
[11:02] <slangasek> seb128: yes; so either there's an upstream samba bug, or there's a bug in how we've set up the /var/lib/samba/usershares dir in the samba package
[11:03] <seb128> slangasek: ok, I'll open a bug then, thanks
[11:04] <soren> ogra_cmpc: Maybe sshfs only passes a certain set of options on to ssh.
[11:04] <soren> ogra_cmpc: You could make an alias in $HOME/.ssh/config with the proper configuration?
[11:04] <ogra_cmpc> soren, well, according to a lot of docs out there it should respect ControlPath from the confiog file
[11:05] <soren> ogra_cmpc: Yes, but you're not setting it from the config file, are you?
[11:05] <ogra_cmpc> but i want the socket to be created dynamically and want to be able to connect to it on the fly
[11:05] <ogra_cmpc> right
[11:05] <ogra_cmpc> my original connection is manually with -M and -S
[11:06] <soren> ogra_cmpc: I found the bug :)
[11:06] <ogra_cmpc> there is a bug ?
[11:07]  * ogra_cmpc thought he only uses it wrongly
[11:07] <soren> sshfs-fuse-1.7/sshfs.c has a ssh_opts array.
[11:07] <ogra_cmpc> heh
[11:07] <ogra_cmpc> mean
[11:07] <soren> It doesn't mention ControlPath.
[11:07] <soren> Er..
[11:07] <soren> No, forget that "er..".
[11:07] <soren> It's accurate.
[11:08] <soren> You just want to add that options and rebuild. Ok, go.
[11:08] <soren> :)
[11:08] <ogra_cmpc> weird, it seems to have nearly every other possible option
[11:09] <soren> I suppose it's a symptom of something when you've gotten to the point where you tend to just skip by the documentation and read the code. :/
[11:09] <soren> Not sure exactly of what it's a symptom.. I hope it's good!
[11:09] <ogra_cmpc> soren, thanks i owe you a beer, i wouldnt have thought of looking at a parser inside sshfs
[11:10] <ogra_cmpc> (i wouldnt even expected such a thing exists, ssh should cover security here anyway)
[11:20] <soren> ogra_cmpc: Well, it needs to divide the stuff it gets passed as -o options into a few groups.. Stuff that is for sshfs itself, stuff that's for mount, stuff that's for fuse, stuff that's for ssh, and everything else. I suppose it's debatable if the last to groups should be joined (and just expect that unknown options are for ssh). *shrug*
[11:20] <ogra_cmpc> well, i'd just add an extra option for ssh specific stuff
[11:21] <ogra_cmpc> it currently uses -o for eveything
[11:22] <soren> ogra_cmpc: I'm not sure if you can.
[11:23] <soren> ogra_cmpc: Unless you circumvent fuse's option parser thingie.
[11:27] <Hobbsee> Fujitsu: btw, have you had the dodgy key events since the hal upgrade?
[11:28] <ogra_cmpc> soren, hmm, recompileed works but i get no file listing in the mount ... seems they had reasons to disable it
[11:30] <soren> *shrug* :)
[11:41] <tkamppeter> hi pitti
[11:42] <pitti> hi tkamppeter
[11:43] <Fujitsu> Hobbsee: Yes.
[11:43] <Hobbsee> Fujitsu: pity
[11:43] <Fujitsu> Three times tonight, but not in a while before that.
[11:43] <Hobbsee> ah
[11:45] <Hobbsee> cjwatson: what dbmoodb was attempting to ask (and apologies for sending him here), is how his broadcom card worked after no internet connection, on a clean install
[11:46] <cjwatson> a most circumlocutory way to ask that question
[11:47] <cjwatson> and I don't know either since we don't ship Broadcom firmware
[11:47] <Hobbsee> cjwatson: well, exactly.
[11:47] <mjg59> Wireless or wired?
[11:48] <Hobbsee> wireless, i think.  he's not around to ask now
[11:48] <mjg59> Because Debian strip the firmware from the tg3 driver
[11:48] <mjg59> And we don't, because that would be ridiculous
[11:48] <Hobbsee> hardly any wired ports at uni, so very likely wireless
[11:48] <mjg59> The only way it could is if he's talking about wired
[11:49] <Amaranth> So he was asking about the dfsg because he thought we were doing something non-free?
[11:49] <Hobbsee> i'll bug him tomorrow about it.  or, if it's like normal, he'll bug *me* about it again.
[11:49] <Hobbsee> Amaranth: yeah, pretty much
[11:49] <Amaranth> make sure he doesn't look in restricted then :P
[11:49] <Hobbsee> wanted to see if ubuntu was actually free, and then never appeared to get to the second question
[11:49] <Hobbsee> heh
[11:50] <Hobbsee> yeah, well.  becaues making non-free hardware work at all is bad.
[11:50] <pwnguin> Hobbsee: you could just point him to gnewsense / gobuntu
[11:51] <Hobbsee> pwnguin: he's a debian user, so i don't know why he cares
[11:51] <pwnguin> heh
[11:51] <pwnguin> ah
[11:51]  * Hobbsee would say more, but won't, due to the logged nature of the channel
[11:51] <pwnguin> so thats why he was confused about the legal nature of the social contract
[11:51] <Hobbsee> i suspect so
[11:52]  * Mithrand1r tickles Hobbsee.
[11:52]  * Hobbsee tickles Mithrand1r with a pile of 1's
[11:52] <cjwatson> the reason people get confused about the legal nature of the social contract is because it is misnamed
[11:52] <ogra_cmpc> do you have to sign it in the NM process ?
[11:52] <mjg59> You have to state you agree to abide by it
[11:53]  * ogra_cmpc stil didnt invest time in that ...
[11:53] <mjg59> There's no formal signature
[11:53] <ogra_cmpc> ah
[11:53] <ogra_cmpc> well, then "contract" is indeed a bit much for it ...
[11:54] <cjwatson> ogra_cmpc: that wouldn't make it binding anyway; the contract is between Debian and the free software community, and the free software community never does anything to it
[11:55] <cjwatson> legal contracts are two-way
[11:56] <ogra_cmpc> yeah
[11:56] <ogra_cmpc> even though every DD is part of that community
[12:31] <ogra_cmpc> sigh ... jockey is so evil on the classmate
[12:35] <ogra_cmpc> if we really want to start doing stuff for the subnotebook market some day i guess we need to rework our "python for everything" directive
[12:41] <mvo> ogra_cmpc: what is the issue? speed? memory?
[12:41] <ogra_cmpc> mvo, both
[12:41] <ogra_cmpc> the first caused by the latter
[12:42] <\sh> grmpf...
[12:42] <jdong> how much RAM does the Classmate have?
[12:42] <ogra_cmpc> jdong, 256
[12:42] <\sh> wine will work again...when you reset LDFLAGS= and the bugreport was closed upstream as invalid...
[12:42] <jdong> hmm and it runs that badly?
[12:43] <ogra_cmpc> i recently wrote a little screenswitcher app that enables panning by cqalling xranrd -s 800x600 or 800x480 ... a simple switcher
[12:43] <ogra_cmpc> implemented in python with egg trayicon as a 10-15 line script that thing eats about 30M with all interpreter stuff loaded etc
[12:44] <ogra_cmpc> the same thing in C takes 5M
[12:44] <mjg59> ogra_cmpc: Is that really 30MB per-application?
[12:44] <mjg59> Or 30MB mostly shared with the rest of the python stack?
[12:44] <ogra_cmpc> mjg59, does that matter if you only run that one app ?
[12:45] <mjg59> ogra_cmpc: Is it really the only python app you're running?
[12:45] <ogra_cmpc> the thing is that with the printer applet, update-notifier and jockey running the desktop takes around 20min to start
[12:45] <mjg59> The printer applet is python
[12:45] <ogra_cmpc> eliminating all the python applets makes it slightly usable
[12:46] <mjg59> Eh. If "slightly usable" is what you get without python, then we've already lost
[12:46] <jdong> that's ridiculous... I've ran Ubuntu on 256MB RAM in VM's and it wasn't that bad
[12:46] <mjg59> jdong: UMA systems
[12:46] <jdong> mjg59: what's the difference? slower CPU right?
[12:46] <ogra_cmpc> mjg59, well, i suspect there will be more subnotebook HW like this one in the future
[12:46] <mjg59> So if 3D is enabled, you've already lost 20MB or so
[12:46] <ogra_cmpc> jdong, the classmate has no L2 chache
[12:46] <mjg59> jdong: RAM used for video
[12:46] <ogra_cmpc> so IO sucks by design already
[12:47] <jdong> ugh
[12:47] <jdong> lovely
[12:47] <ogra_cmpc> then you have no swap (would kill the flash)
[12:47] <jdong> and why should such things be expected to run GNOME?
[12:47] <mjg59> jdong: It shouldn't
[12:47] <ogra_cmpc> so 256M are already extremely tight for a gnome desktop
[12:47] <mjg59> Given the current state of gnome, anyway
[12:48] <ogra_cmpc> mjg59, :p tell that to our CTO
[12:48] <mjg59> Resource usage needs to be improved everywhere, rather than just worrying about python
[12:48] <jdong> indeed
[12:48] <mjg59> ogra_cmpc: Eh. Ubuntu is only marginally usable on a 256MB machine.
[12:48] <ogra_cmpc> i have order to use gnome here
[12:48] <mvo> ogra_cmpc: update-notifier is C
[12:48] <ogra_cmpc> so i cut down what i can ... its actually usable but crippled indeed
[12:48] <jdong> how the heck is that thing ever going to run a web browser?
[12:48] <mjg59> If you have no swap, it's not going to be usable
[12:49] <ogra_cmpc> jdong, starting slowly ... but with all caches disabled it workws fine once its up
[12:49] <jdong> ogra_cmpc: have you blacklisted all the restricted modules yet?
[12:49] <jdong> ogra_cmpc: the 3 nvidia ones will chew up 30MB RAM fast
[12:50] <ogra_cmpc> mjg59, i agree that we need a dedicated subnotebook desktop but thats not the problem i can attack atm :)
[12:50] <mjg59> Oh, yeah, if l-r-m is installed then you lose instantly
[12:50] <jdong> indeed :)
[12:50] <mjg59> jdong: It's not a matter of blacklisting - they won't be autoloaded. It's the fact that they get linked in a tmpfs.
[12:50] <mjg59> That's fine if you've got swap, failure if you haven't
[12:50] <laga> why are they linked in a tmpfs?
[12:50] <ogra_cmpc> jdong, ah, thanks i had that ripped out in my image build script originally, seems its back ...
[12:50] <jdong> mjg59: blacklisted modules don't get loaded into tmpfs for me
[12:51] <jdong> lrm                   505M  1.3M  504M   1% /lib/modules/2.6.22-14-generic/volatile
[12:51] <jdong> that's just with the 3 nvidia's and ath_hal
[12:51] <ogra_cmpc> thanks for the pointer, now i know why tadays image is slower than last weeks :p
[12:51] <jdong> blacklisted, that is
[12:51] <ogra_cmpc> *TODAYS
[12:51] <ogra_cmpc> oops
[12:51]  * mvo hands ogra_cmpc a new CAPSLOCK key
[12:51] <jdong> ogra_cmpc: shift and caps lock too scrunched? ;-)
[12:51] <ogra_cmpc> heh
[12:51] <ogra_cmpc> yeah, they are close together
[12:51] <hunger> OOo depends on OOo-writer2latex. Could somebody please add the later to the archive?
[12:52]  * jdong writes ogra_cmpc a python daemon to detect simultaneous shift/capslock presses, then sets it for bootup
[12:52] <ogra_cmpc> i can usually cope with the keyboard if i dont switch all the time
[12:52] <sladen> the lrm could be culled if the PCI IDs aren't there
[12:52] <mjg59> jdong: Uh. Do you mean disabled in /etc/default/linux-restricted-modules-common ?
[12:52] <ogra_cmpc> sladen++
[12:52] <jdong> mjg59: yes
[12:52] <jdong> mjg59: sorry if blacklisting's not the correct term for doing that :)
[12:52] <mjg59> jdong: Right. blacklisting generally refers to the udev blacklisting.
[12:52] <mjg59> s/udev/module-init-tools/
[12:53] <jdong> yeah, realized that in hindsight :)
[12:53] <hunger> jdong: Just use xmodmap to map capslock to something more useful;-)
[12:54] <jdong> hunger: I take it you're an emacs user. ;-)
[12:54] <ogra_cmpc> hmm, unmounting lrm on the fly doesnt free any ram ... intresting ... df reported 38M usage
[12:55] <hunger> jdong: Nope, but I have a thinkpad (no win key).
[12:55] <jdong> hunger: ah
[12:56] <hunger> ogra_cmpc: tmpfs tends to get pushed into swap really soon and usually stays there.
[12:56] <mjg59> hunger: There is no swap
[12:56] <jdong> hunger: no swap
[12:56] <jdong> that's half the problem :)
[12:56] <ogra_cmpc> hunger, no swap
[12:56] <hunger> Oh, sorry.
[12:56] <jdong> LRM is less of a problem when there is swap
[12:56] <ogra_cmpc> well, thats not really a problem if you dont hit the edge
[12:57] <ogra_cmpc> if i run my cusomized devel desktop with pcmanfm, cairo-dock, devilspie and metacity it never hits the edge actually
[12:57]  * hunger got swap mostly because of lrm.
[12:58] <jdong> you sure you can't swap out the GNOME with XFCE or something....
[12:58] <cjwatson> we already disable the nvidia modules (and others) on the live CD for exactly the memory reasons mentioned above
[12:58] <jdong> the default GNOME desktop is quite RAM hungry
[12:58] <ogra_cmpc> jdong, not for this image
[12:58] <jdong> cjwatson: would it be out of the question to use lrm-video to decide whether or not the nvidia modules should be loaded?
[12:58] <ogra_cmpc> i plan to start a subnotebook desktop project in intrepid ...
[12:59] <jdong> ogra_cmpc: I have a feeling even non-subnotebook users would be interested in a lightweight too :). That'll really take off
[12:59] <ogra_cmpc> seems bryce already started working on a lighter and better to use inkscape ...
[12:59] <cjwatson> jdong: not if somebody submits a patch for that to casper, no
[12:59] <mjg59> jdong: Though the situation is unlikely, it's valid to hotplug PCI cards
[13:00] <cjwatson> jdong: though I doubt it would be useful; surely xorg autoconfiguration will never pick the restricted drivers
[13:00] <jdong> mjg59: hmm sounds like it's time for a less static structure to lrm in that case
[13:00] <ogra_cmpc> jdong, well i thought about dedicated software that runs at the cut down resolution etc
[13:00] <jdong> cjwatson: yeah on the livecd it'd be less than useful
[13:00] <cjwatson> jdong: so lrm-video will never select any of those drivers during live CD boot
[13:00] <cjwatson> jdong: exactly, that's why :)
[13:00] <ogra_cmpc> not only performance but also UI improvements
[13:00] <cjwatson> jdong: oh, do you mean using lrm-video to decide whether they should be loaded on other systems?
[13:00] <jdong> cjwatson: jockey would also need some sort of ability to load
[13:00] <jdong> cjwatson: yeah my initial thought was for already installed systems
[13:01] <jdong> cjwatson: ogra_cmpc isn't the first time I've helped someone dramatically improve RAM problems by disalbing LRM
[13:01] <cjwatson> jdong: sounds reasonable, though I'm not volunteering :)
[13:01] <jdong> :)
[13:02] <mjg59> jdong: If you've got swap, l-r-m isn't really a problem. If you don't have swap, you're already running outside the standard setup :)
[13:02] <ogra_cmpc> jdong, well, i know about the issue (i think i was the first one to discover it in dapper with ltsp back then) ... i just didnt bother to look if the removal part of my image builder worked right :)
[13:02] <ogra_cmpc> since it worked last time (a week ago) and didnt install lrm first place
[13:02] <jdong> ogra_cmpc: yes, I trust that you'd know about the issue, but average new Ubuntu user with lightweight PC probably has no idea
[13:03] <ogra_cmpc> jdong, well, its our job to fix it for them ;)
[13:04] <ogra_cmpc> what would really be helpful for the low spec devices would be a module profiling mechanism that generates proper module lists for initramfs ...
[13:05] <ogra_cmpc> the onews we have atm are still loading a ton of extra stuff i actuall dont need
[13:06] <ogra_cmpc> if i only load the 10 modules i actually need for booting, the classmate boots in about 20% of the time it uses for probing the whole module list
[13:07]  * ogra_cmpc reboots
[13:13] <ogra_cmpc> hmm, intresting ... according to htop i didnt earn a byte with removing lrm ...
[13:13] <ogra_cmpc> but the system feels ten times more responsive
[13:23] <mvo> Riddell: do you happen to know if we have kde-guidance on the super-mirror as a svn import?
[13:25] <Riddell> mvo: I don't think we do
[13:26] <mvo> Riddell: do you know if someone is working on it to make it crash less with our current xorg.conf ?
[13:26] <Riddell> mvo: ScottK has patches
[13:26] <mvo> aha, nice
[13:27] <Riddell> mvo: he even uploaded to the archive I think but reverted because of freeze
[13:27] <ScottK> mvo and Riddell: But I don't know how much help it'll be with the no xorg problems
[13:27] <ScottK> Yes I did (urgh).  Thanks for reminding me
[13:27] <Riddell> mvo: here https://edge.launchpad.net/~kitterman/+archive
[13:28] <ScottK> If someone could suggest a strategy for dealing with the no Xorg, I can probably implement it.
[13:29] <ScottK> So far I've just patched stuff that I can reproduce locally or that I can see in the code how to catch with no regression risk.
[13:30] <ScottK> mvo: Point me in the right direction and I'll give it a shot.
[13:32] <mvo> ScottK: its a while since I touched it last. I was thinking of a) making it more robust b) making it return stuff like "unknown" or "auto-detect" when there is no section in the xorg.conf file so that the GUI can deal with it. but I'm currently looking at the bugreport first to see what the most common problems are
[13:34] <ScottK> mvo: OK.  My python is reasonably robust, but my xorg knowledge is very shallow, so I'll need some hand holding, but can get it done with some guidance (pun intended).
[13:35] <mjg59> bryce: Uh. Why did you remoe the entries for wacom tablets in the default xorg.conf? Now people need to edit text files to get their hardware to work.
[13:35] <mvo> ScottK: heh :) I come back to you when I have a slightly better idea, ok? do you have commit access to the upstream repository? I imagine we will want to put the changes upstream too
[13:36] <ScottK> mvo: No.  I've no involvement with upstream.  I figured to get some things sorted and then send patches.
[13:36]  * mvo nods
[13:42] <ScottK> mvo: One of the bugs I was looking at seems to have a guidance component and a maybe hal/policykit component.  It's Bug #183656.  Is that something you could take a look at?
[13:42] <ubotu> Launchpad bug 183656 in kde-guidance "Cancel button in kde-guidance-powermanager doesn't do anything" [Medium,In progress] https://launchpad.net/bugs/183656
[13:43] <Riddell> ScottK: that's not really ScottK's area
[13:43] <Riddell> ScottK: that's not really mvo's area
[13:43] <tjaalton> mjg59: that was done already in gutsy
[13:43] <tjaalton> mjg59: there were some issues with it too
[13:43] <ScottK> Riddell: OK.  Thanks.  WHo should I talk to about that?
[13:43] <Riddell> ooh tjaalton, X has started working again on my r40e!
[13:44] <tjaalton> Riddell: what happened?-)
[13:44] <mjg59> tjaalton: Yeah, but the bug only mentions an issue with gok that's never debugged
[13:45] <Riddell> ScottK: possibly see if Lure has some time?
[13:45] <ScottK> Riddell: Thanks.  Will do.
[13:45] <ScottK> Guidance shouldn't crash in any case (which I can fix), but that won't make it work.
[13:45] <tjaalton> mjg59: also kde-apps bug about missing input devices, although that's mostly cosmetic
[13:46] <mjg59> tjaalton: Yeah, that's easily fixable
[13:46] <tjaalton> mjg59: and tbh, by now we should've had input-hotplug with wacom support, but the world doesn't like us :P
[13:47] <mjg59> tjaalton: It's an unfortunate regression over pre-gutsy releases
[13:47] <tjaalton> mjg59: it is.. but could it be done in jockey or similar?
[13:49] <mjg59> tjaalton: Unf. Conceivably.
[13:55] <mvo> ScottK: I'm mostly interessted in the guidance-backend issues currently because they make both the kde and gnome frontends crash (stuff like #173762)
[13:56] <mvo> scottK, Riddell: how should I feed patches for guidance, should we have a shared bzr packaging repository so that we can easily work on it together?
[13:57]  * ogra_cmpc dances around mvo ...
[13:57] <ogra_cmpc> i got g-a-i working on the classmate in a usable speed :)
[13:58] <mvo> ogra_cmpc: woah! how did you manage that :P ?
[13:58] <Riddell> mvo: can do
[13:58] <ogra_cmpc> moving /var off the unionfs ;)
[13:58] <saispo> soren: ping ?
[13:59] <mvo> Riddell: do you currently use bzr for packaging?
[13:59] <laga> ogra_cmpc: does unionfs make things slower?
[13:59] <ogra_cmpc> laga, well, at least it makes db access slow it seems
[13:59] <laga> ogra_cmpc: i wonder if aufs would be faster
[13:59] <Riddell> mvo: not for guidance, some kde packages are in ~kubuntu-members
[13:59] <ogra_cmpc> which means apt, dpkg, g-a-i get extremly slow
[13:59] <laga> given that it's in lum, maybe you could try it :)
[14:00] <ogra_cmpc> laga, in intrepid
[14:00] <laga> ogra_cmpc: heh
[14:00] <ogra_cmpc> i dont have time to waste on the classmate atm
[14:01] <ogra_cmpc> hmm, i somehow trashed gdebi-gtk
[14:01] <ogra_cmpc> FATAL -> Failed to fork.
[14:02]  * ogra_cmpc wonders what it forks ... gdebi, synaptic, apt and dpkg work fine ...
[14:03] <mvo> ogra_cmpc: might be a memory issue
[14:03] <soren> saispo: Wazzup?
[14:03] <ogra_cmpc> mvo, hmm, all the others work
[14:04] <saispo> soren: an error on xen gutsy kernel when i create lvm volume, have you seen this ?
[14:05] <saispo> (2.6.22-14-xen) have you seen this ?
[14:05] <soren> saispo: No, but I've not tried either, so that's hardly surprising :)
[14:05] <saispo> :)
[14:05] <saispo> i create a lot of lvm volume with a python script and after some, the kernels oops
[14:06] <soren> saispo: You could try over in #ubuntu-xen
[14:06] <zul> or you could try hardy
[14:06] <saispo> ok thanks
[14:06] <saispo> zul: not possible
[14:07] <saispo> but thanks for your advice ;)
[14:07] <ogra_cmpc> mvo, it doesnt hit the edge, i just monitored it. it eats a *lot* of ram though
[14:10] <mvo> ogra_cmpc: it is (or should be) mostly mmaped stuff from the apt cache
[14:10] <ogra_cmpc> mvo, gdebi in a terminal seems to eat the same amount of ram and works, so i rule out ram here
[14:10] <_r1_> hi
[14:11] <_r1_> Is it known that gutsy alternate install CD make a kernel MD5SUM mismatch during an install ?
[14:12] <_r1_> (and I have a second issue few time after force this step...)
[14:15] <jdong> I've installed at least 5 gutsy systems from the alternate CD and none of them have any sort of mismatch
[14:15] <jdong> I suspect a bad download or burn
[14:15] <_r1_> I test 2 differents images (kubuntu/xubuntu) with exactly same error
[14:16] <_r1_> and It's my first gutsy error
[14:17] <_r1_> I'm now trying to install without any network connection
[14:19] <kagou> hi
[14:47] <TomaszD> hi, an easy fix if some has a moment https://bugs.launchpad.net/ubuntu/+source/wine/+bug/198761
[14:47] <ubotu> Launchpad bug 198761 in wine "Please include Polish translation for .desktop files (diffs included)" [Undecided,New]
[14:51] <cjwatson> _r1_: if you're seeing it with multiple images, then consider cleaning your CD drive; that's a common culprit
[14:51] <cjwatson> _r1_: drive cleaning kits are fairly cheap, and can save a lot of annoyance
[14:53] <tjaalton> still no new oo.o-l10n packages in the archive, needs a push?
[14:53] <\sh> bryce: bug #183922 ... shouldn't the status  "Triaged" until someone can debug X and send us the report?
[14:53] <ubotu> Launchpad bug 183922 in wine "Xorg crashes after using Microsoft Word 2003 in Wine." [Undecided,New] https://launchpad.net/bugs/183922
[14:56] <_r1_> cjwatson: It's appear it's actually a hardware problem you're right (iso and cd MD5 are both good)
[14:56] <_r1_> sorry for that...
[15:12] <tjaalton> mjg59: care to reply to bug 155937, I've given up ;)
[15:12] <ubotu> Launchpad bug 155937 in xserver-xorg-input-synaptics "SHMConfig should be enabled by default, and gsynaptics should be installed by default on laptops" [Undecided,New] https://launchpad.net/bugs/155937
[15:15] <mjg59> tjaalton: Not really. SHMConfig can't be enabled by default. Ever.
[15:15] <tjaalton> mjg59: I already closed it once as won'tfix
[15:15] <mjg59> tjaalton: Most of the features of gsynaptics aren't supported by the interface I added.
[15:15] <mjg59> tjaalton: I can't comment myself (don't have a launchpad account)
[15:16] <tjaalton> mjg59: oh
[15:19] <TomaszD> pitti, hi, I'm one of ubuntu-l10n-pl admins. I've heard there's a ppa for daily langpacks for hardy, could you share the url (in private, if need be)
[15:19] <TomaszD> ?
[15:25] <pitti> TomaszD: sure, it's not secret at all, to the contrary
[15:25] <ogra_cmpc> mjg59, you removed your LP account ?
[15:25] <pitti> TomaszD: https://launchpad.net/~ubuntu-langpack/+archive
[15:25] <TomaszD> ok, thanks, I was googling "pitti ppa"
[15:25] <TomaszD> pitti, no hardy?
[15:26] <pitti> TomaszD: no, we upload updates straight to hardy (automatically twice a week)
[15:26] <\sh> TomaszD: thx for the translation :)
[15:26] <TomaszD> pitti, oh ok :]
[15:27] <TomaszD> \sh, no problem, btw could someone look here https://bugs.launchpad.net/ubuntu/+source/paprefs/+bug/191854 ? :]
[15:27] <ubotu> Launchpad bug 191854 in paprefs "Please include Polish translation for paprefs (translation attached)" [Undecided,New]
[15:27] <TomaszD> it's a universe package, upstream vendor doesn't respond
[15:37] <\sh> TomaszD: taking care of it
[15:37] <TomaszD> \sh, awesome, thank you!
[15:40] <jdong> what's the commandline way of starting up the "partial upgrader" thing?
[15:41] <\sh> TomaszD: done
[15:48] <TomaszD> \sh, you rule!
[15:48]  * TomaszD hugs \sh
[15:49] <\sh> TomaszD: na you rule...thanks for making ubuntu rock even harder :)
[15:49] <TomaszD> :D
[16:21] <ScottK> pitti: Thank you for your comments on my DM application.
[16:48] <pitti> ScottK: my pleasure
[16:53] <LaserJock> yeah, ScottK seems to be getting all the love ;-)
[16:54] <ScottK> You just got a nice reply.
[16:54] <LaserJock> oh heah, I did!
[16:54]  * LaserJock hugs azeem 
[17:12] <keescook> heya
[17:12] <keescook> pitti: say, the virtual interface patch you applied from me -- I think it's causing a bigger headache than it solves.  can you pull it out after the alpha?
[17:13] <pitti> keescook: hi
[17:13] <pitti> keescook: hm, can do; can you reply to the upstream bug with improvements/ask to close the bug?
[17:14] <keescook> pitti: well, I think it _is_ correct -- the problem is that the client applications suddenly need additional logic and fixing all of those before release seems like a bad idea.
[17:14] <keescook> pitti: but I will comment on the bug about the behavior it creates
[17:14] <pitti> keescook: ah, ok
[17:16] <pitti> keescook: done in bzr head
[17:16] <pitti> keescook: I'm still waiting for slangasek's ack for uploading it
[17:17] <keescook> pitti: okay, thanks.
[18:37] <EtienneG> wondering about something, guys
[18:38] <EtienneG> I set a default boot option on an ext3 volume using tune2fs (as in, tune2fs -o acl /dev/...)
[18:38] <EtienneG> yet, the boot option is not used when mounting the volume
[18:39] <EtienneG> so either the tune2fs man page is incorrect in stating that it should, or the feature have been deprecated, or I am missing something
[18:39] <EtienneG> anybody have a clue on the subject?
[18:45] <EtienneG> forget above question, it just needs a reboot, and the option will not show up in the output of mount
[19:02] <wasabi> bryce: Yup. Latest upload fixed it.
[19:08] <slangase`> pitti: sorry, waiting for my ack before uploading which?
[19:36] <Tonio_> am I the only one having problem with his @ubuntu.com email redirection today ?
[19:36] <Tonio_> not any email arrives to my mailbox.... the mailbox itself works
[19:46] <Tonio_> I can see that the mail is correctly sent to mx.canonical.com
[19:46] <Tonio_> then nothing...
[19:48] <Amaranth> that'd be bad, all of my mailing list mail goes through my @ubuntu.com mail
[19:54] <mario_limonciell> well "bad" is a misnomer.  It may grant you a forced break from this stuff :)
[20:25] <bryce> \sh: no, I set to Incomplete for bugs where more info is needed from the reporter in order to troubleshoot it
[20:26] <\sh> bryce: ok...I just wanted to make sure, that we don't forget about this bug
[20:26] <bryce> \sh: since it's a crash when running a commercial app (MS Word 2003), we need someone with that app to gather an error message, backtrace, or etc.  Just knowing it crashes isn't enough to go on in this case.
[20:28] <bryce> mjg59: the wacom entries were causing breakage for certain accessibility applications; I removed them at heno's direction.
[20:28] <\sh> bryce: agreed..good that I don't run commercial apps.
[20:30] <bryce> ogra_: the inkscape-lite stuff I did was really just a demo to stimulate thinking in that direction, but it's inspired a few people to do a more "proper" implementation for inkscape 0.47 or later
[20:32] <bryce> \sh: yeah we do re-review incomplete bugs periodically and reprioritize as info becomes available
[20:32] <Kopfgeldjaeger> n8
[20:33] <slangasek> heh
[20:33] <slangasek> stgraber: You are here : QA Tracker -> ^Ubuntu \w* \w*$
[20:33] <slangasek> ? :)
[20:41] <stgraber> slangasek: argh ... :)
[20:42] <stgraber> slangasek: it's the result of using some more regexp, will ask for a code sync tomorrow :)
[20:43] <slangasek> ok :)
[20:45] <slangasek> mr_pouit: well, the OOo size fixes have brought xubuntu alternate down to size on amd64, but i386 is still oversized: 729M    xubuntu/daily/20080305.1/hardy-alternate-i386.iso
[20:46] <slangasek> mr_pouit: do you want to look at this so we can include xubuntu alternates in alpha-6?
[20:48] <stgraber> slangasek: btw, the tracker was updated so you now have Kubuntu-KDE4, the right Edubuntu images, Wubi and a now completely working download info window (I have entirely rewritten my cdimage.u.c parser)
[20:48] <slangasek> stgraber: saw that, thanks
[20:49] <slangasek> well, the image fix-ups; didn't notice the download info window changes :)
[20:49] <ScottK> slangasek: It looks like the fix for the postfix backport (depwait due to dep in Universe) fix only took on i386.  The other archs are still depwait ...
[20:50] <slangasek> ScottK: how... odd
[20:50] <lamont> ScottK: iirc, I gave back i386
[20:50] <slangasek> oh, there's your answer :)
[20:50] <ScottK> Ah
[20:50] <ScottK> lamont: Would you please give back all the other archs and all archs on Edgy?
[20:51] <slangasek> for edgy-backports, I hadn't moved the package to universe; that's a prereq, right?
[20:51] <ScottK> Ah.  Yes
[20:51] <ScottK> Sorry.  I thought you'd done them both.
[20:52] <slangasek> nah, the output after I did the dapper one scared me enough that I stopped there to see what happened after the next publishing run
[20:53] <ScottK> OK.  Well it seems to have worked out fine for Dapper i386.
[20:54] <lamont> Content-Type: text/plain; charset=ISO-8859-1
[20:54] <lamont> Message-ID:
[20:54] <lamont> Date: Wed, 05 Mar 2008 15:50:30 -0500
[20:54] <slangasek> right, edgy done now as well; I suppose it probably needs to wait a cycle before give-backs will work
[20:54] <lamont> what is wrong with that picture...???
[20:54] <ScottK> slangasek: I think this is something that ought to be fixed as it's just going to get more painful.
[20:54] <lamont> slangasek: what we want is --pretend-avail launchpad-style
[20:54] <ScottK> Slight bit of message ID missing there.
[20:54] <slangasek> lamont: --pretend-avail wouldn't fix the chroot's sources.list, though?
[20:55] <lamont> no
[20:55] <slangasek> lamont: wrong with that picture> the legacy charset!!
[20:55] <lamont> but the package build-depends: libcdb-dev | tinycdb
[20:55] <lamont> null msgid == all of their mail is a duplicate
[20:55] <slangasek> lamont: and which of those is in dapper/main?
[20:55] <lamont> uh... the dapper/i386 build worked....
[20:56] <slangasek> lamont: yes, because I moved the dapper backport to universe
[20:56] <lamont> right
[20:56] <slangasek> so maybe I'm confused about what you're saying should be fixed
[20:56] <lamont> so that just leaves the issue that the dapper package is dep-wait on a package that won't exist until edgy-backport
[20:56] <slangasek> oh
[20:56] <lamont> the dapper-backport is d-w the wrong package...  yeah ored deps
[20:57] <slangasek> surely the d-w was only set because *neither* package was available the first time it tried to build?
[20:57] <slangasek> so if it were given back now it should pick up tinycdb ok?
[20:57] <ScottK> That's what the i386 one appears to have done.
[20:58] <lamont> right
[20:58] <lamont> the d-w got set on the first package, since neither was available.
[20:59] <lamont> and the first package is the "right one for sid" :-)
[21:00] <ScottK> All I know is the 2.4.5 backport was painless.  I don't think anything has changed in the package to make it harder since then.
[21:03] <lamont> ScottK: it was painless because I did it, maybe?
[21:03]  * lamont goes looking
[21:04] <lamont> ... libcdb-dev | tinycdb
[21:04] <lamont> hrm
[21:05] <lamont> amusingly true for 2.4.5-3build1~dapper1 as well
[21:06] <ScottK> Without any data to prove it, I suspect it's easier because Launchapd has been 'improved' since.
[21:06] <emgent> good night people
[21:07] <ScottK> Of course that theory aligns well with my internal biases, so I may well be full of it.
[21:18] <mjg59> bryce: I'd rather have worked out what was causing the issues
[21:22] <slangasek> tjaalton: you milestoned bug #178292, is this something you're working on?
[21:22] <ubotu> Launchpad bug 178292 in mesa "3D-Accelerated Games cause X to crash with Intel Driver" [Unknown,Fix released] https://launchpad.net/bugs/178292
[21:33] <tjaalton> slangasek: oh yeah, assigning to myself
[21:33] <mdke> tkamppeter_: around?
[21:56] <slangasek> tjaalton: but I'm not thinking that you're still aiming to get it fixed for alpha-6? :)
[22:00] <tjaalton> slangasek: no, I noticed that you pushed it for beta, which is fine :)
[22:01] <\sh> bah..why are the virtualbox kernel modules not upgraded by default ? (for use with latest kernel?)
[22:02] <\sh> something for tomorrow...
[22:02] <\sh> good night folks
[22:17] <Tonio_> Amaranth: do you also have that mail redirection failure ?
[22:17] <Amaranth> Tonio_: i don't think so
[22:17] <Amaranth> No, I'm definitely getting emails from mailing lists still
[22:18] <Tonio_> Amaranth: any idea who to contact for this problem ?
[22:18] <Amaranth> Nope
[22:18] <Tonio_> Amaranth: the strange thing is that I deleted my standard email from launchpad and added it again, and received the launchpad email confrmation in my mailbox
[22:18] <Tonio_> but still no redirection...... that's crazy
[22:19] <Tonio_> another option is that my isp rejects redirected emails, which is another option....
[22:19] <Tonio_> hard to know what happens in fact......
[22:19] <Amaranth> the redirection is not automatic
[22:19] <Tonio_> Amaranth: you mean ?
[22:19] <Amaranth> although perhaps you've broken it
[22:19] <Amaranth> it doesn't get turned on automatically
[22:19] <Tonio_> Amaranth: didn't touch anithing for month
[22:19] <Amaranth> someone goes and does it
[22:20] <Amaranth> although i think it's a script
[22:20] <Amaranth> no clue then
[22:20] <Tonio_> Amaranth: so it was broken on the ubuntu side....
[22:20] <Tonio_> Amaranth: I'll try to ping a few people at canonical....
[23:43] <jdong> infinity: looks like backports is no longer ignoring the main-universe split like it's supposed to....
[23:43] <ScottK> See recent postfix depwaits in Dapper/Edgy and the soyuz foo slangesek had to use use make it work for an example.
[23:44] <jdong> ScottK: I poked infinity, who was the last person who helped way back then
[23:44] <jdong> ScottK: if that doesnt' work then I guess soyuz bug?
[23:44] <ScottK> jdong: I'd suggest file it.  I've given up on filing LP bugs.