[02:27] <ProN00b> can anyone file a bug for me ? vino-server (and other vnc servers) aparently depend on an US keyboard layout to work correctly
[02:27] <lamont> same story with splix and cupsddk
[02:33] <ScottK> lamont, why?
[02:33] <lamont> ScottK: because main packages aren't allowed to build-depend on universe packages...
[02:34] <ScottK> Understand that, but why drac-dev?
[02:34] <lamont> nfc why dovecot build-depends drac-dev
[02:34] <ScottK> Ah
[02:34] <ScottK> I misread.
[02:35] <ScottK> I missed the not.
[02:35] <ScottK> Nevermind.
[02:35] <lamont> ah, ok.
[02:35] <lamont> you had me wondering about your mentation there fir a minute... :-)
[02:35] <lamont> ScottK: I wonder if they fixed the getty tty issue
[02:36] <lamont> s/they/someone/
[02:36] <ScottK> Which one is that?
[02:36] <ScottK> My Gutsy hard drive died on Friday so I haven't seen anything on the last few days of development.
[02:37] <ScottK> I had a Dapper CD handy after I got a replacement, thus my experiment.
[02:37] <lamont> dapper-> feisty would leave you with getty not listening on any serial ttys
[02:37] <ScottK> Ah.
[02:38] <ScottK> I've had to remove a lot of stuff to get past the conflicts.
[02:39] <ScottK> Transitioning to using Upstart seems to be the lowest level sticking point.
[02:39] <ScottK> Mostly I'm taking notes and I'll try and understand it later.
[02:40] <xhaker> ScottK, what should i write in a package where the changes were bringing back and fixing a dpatch to fix FTBFS
[02:41] <ScottK> Do you mean in debian/changelog?
[02:41] <xhaker> oh, yes.. sorry.
[02:42] <ScottK> I'd put something like "  * Resurrected nameofpatch.dpact to fix FTBFS (LP: #nnnn)
[02:42] <ScottK> .dpact/.dpatch
[02:45] <jwendell> does anybody know what package is responsible for manage the network connections located at Places->Connect to server ?
[02:48] <lamont> Unpacking x11-common (from .../x11-common_1%3a7.2-5ubuntu6_hppa.deb) ...
[02:48] <lamont> Can't exec "locale": No such file or directory at /usr/share/perl5/Debconf/Encoding.pm line 16.
[02:48] <lamont> neato
[02:48] <lamont> enigmail needs some love, too: thunderbird-dev(inst 2.0.0.6-0ubuntu1 ! << wanted 2.0.0.0.0)
[03:10] <johanbr_> jwendell: Appears to be nautilus.
[03:10] <jwendell> johanbr_, yep, thanks
[03:23] <Chipzz> ScottK: but you should know that upgrades from dapper to gutsy are not supported? ;)
[03:24] <ScottK> Chipzz: Absolutely.
[03:24] <Chipzz> so why do you bother? :)
[03:24] <ScottK> Eventually upgrades from LTS to LTS +1 will be supported.
[03:24] <Chipzz> that was the one reason I could see idd
[03:24] <ScottK> I was curious how ugly it was already.
[03:24] <Chipzz> but isn't that something to worry about after gutsy is released?
[03:25] <ScottK> Worry more, yes, but if there was something that could be dealt with now, why not?
[03:25] <ScottK> I wouldn't have bothered, but I had a hard drive die and needed to do a fresh install anyway.
[03:26] <Chipzz> well if you bother now chances are it will break again, so why bother? :)
[03:26] <ScottK> On the off chance I'd learn something.
[03:26] <Chipzz> ok
[03:26] <LaserJock> knowing that what things are likely to break is a good thing
[03:26] <ScottK> It appears to fall in the catagory of painful but doable.
[03:26] <Chipzz> it's your time anyway ;)
[03:27] <ScottK> Yep.
[03:27] <ScottK> I had to remove ubuntu-minimal.  That was kind of interesting.  Fortunately not for anything I was actually using.
[03:28] <Chipzz> this is growing out of proportion
[03:29] <Chipzz> 110MB for linux-image + linux-restricted modules + linux-ubuntu-modules 2.6.22
[03:31] <mjg59> Drivers are large.
[03:31] <mjg59> Hard drives are larger.
[03:31] <desrt> mjg59; found the problem i was having earlier
[03:31] <mjg59> desrt: Mm?
[03:32] <desrt> mjg59; the dynamic linker does mprotect() to make the code read-write then does mprotect() again to make it readonly for purposes of performing relocations against the text section
[03:32] <desrt> so you see "dirty private readonly" pages as a result of that strange sequence of events
[03:32] <mjg59> Hm. I'm not entirely clear on why that follows.
[03:33] <desrt> well... it wants to be able to write to code to perform relocations... but it also wants the code readonly at runtime
[03:33] <desrt> so it's a fairly reasonable thing to do
[03:33] <mjg59> Oh, so the dirty pages are just relocation data?
[03:33] <desrt> ya
[03:33] <LaserJock> Chipzz: yeah, I've found that my usual 100MB for /boot doesn't work so well anymore
[03:33] <mjg59> Makes sense
[03:33] <desrt> i accidentally linked some stuff in that wasn't -fpic
[03:35] <Chipzz> mjg59: like LaserJock pointed out, some people have seperate / or /boot 's
[03:35] <mjg59> /boot is unimportant. The core kernel size has increased by an insignificant amount.
[03:36] <Chipzz> well it's /lib that's taking up all the space for me
[03:36] <Chipzz> I was just looking through the list of linux-image when my laptop crashed hard
[03:36] <Chipzz> it just shut down power with no warning at all
[03:37] <Chipzz> like an empty battery, except it's plugged in to an outlet
[03:37] <mjg59> Or broken hardware
[03:37] <Chipzz> just had an oops with the previous kernel
[03:37] <mjg59> Oopses don't shut your machine down
[03:37] <Chipzz> they don't
[03:37] <mjg59> PCI bus errors don't shut your machine down
[03:37] <Chipzz> but the bug can manifest itself in some other way in a different kernel version
[03:38] <Chipzz> like a kernel panic
[03:38] <Chipzz> which still shouldn't have shut down the hw
[03:38] <mjg59> There's no especially plausible way for a driver bug to shut your machine down
[03:38] <desrt> reboot is easy... shutdown is quite difficult
[03:38] <Chipzz> anyway
[03:39] <mjg59> Oh, yeah, at least half a dozen different ways of triggering a reboot
[03:39] <mjg59> Power off requires specific writes to specific io ports
[03:39] <Chipzz> most likely broken power connector or something
[03:39] <mjg59> Or memory registers
[03:39] <Chipzz> anyway
[03:40] <Chipzz> why do we have atm or watchdog modules in the -generic kernel?
[03:40] <Chipzz> shouldn't that be something for the -server kernel?
[03:40] <mjg59> No?
[03:40] <mjg59> The -server kernel is about tuning, not (for the most part) functionality
[03:40] <mjg59> But we could remove "inappropriate" modules, which might save you 10MB or so
[03:41] <mjg59> (The 1980s called, they'd like their hard drive back)
[03:42] <mjg59> 1.8" is still limited to 80GB or so
[03:42] <ScottK> This was 2.5"
[03:42] <Chipzz> ScottK: this is more about the size of partitions than the size of the hard-disk as a whole
[03:43] <LaserJock> ScottK: the smallest?? That's what my desktop hard drive was :-)
[03:43] <LaserJock> Chipzz: yeah, but Ubuntu defaults to just /
[03:43] <ScottK> Yeah.  That's the smallest they had in 2.5".
[03:43] <mjg59> Chipzz: People who partition their hard drive are (in general) going to lose
[03:43] <LaserJock> I guess it's my fault for partitioning my hard drive up
[03:43] <mjg59> If you partition your drive manually, you're claiming that you have a good idea about what the future is going to involve
[03:44] <LaserJock> which I don't like, but that's the way it is these days
[03:44] <Chipzz> still not a valid reason to discard the size of the kernel etc is irrelevant
[03:44] <LaserJock> Chipzz: I'm guessing it's not discarded
[03:44] <LaserJock> but less of a factor
[03:44] <mjg59> Chipzz: Given the choice between functionality and 1% of your hard drive, we're going to choose functionality
[03:44] <LaserJock> right
[03:44] <Chipzz> a lot could be done with a little intelligent splitting of linux-restricted-modules I think
[03:45] <mjg59> No.
[03:45] <mjg59> Splittling packages requires a huge increase in maintenance load.
[03:45] <Chipzz> mjg59: I'm notg suggesting dropping functionality; I'm suggesting looking at the split we have wrt udeb's and consider to use at least some of it for the regular debs too
[03:45] <ScottK> What matters is how much goes into RAM, not what's on the HD.
[03:46] <mjg59> Chipzz: And, as I said, that would require significant extra effort
[03:46] <Chipzz> mjg59: how so? like I said, we already have that split for the udebs anyway
[03:46] <mjg59> Chipzz: Not in an especially useful way for restricted, no
[03:47] <mjg59> I think you underestimate just how stupidly big the modules in restricted are
[03:47] <Chipzz> mjg59: consider this: a very common scenario is a laptop with ipw* + nvidia chipset
[03:47] <Chipzz> but ipw* is in linux-ubuntu-modules and nvidia is in linux-restricted-modules
[03:47] <mjg59> And the consequence is that the user has ~100MB less hard drive space than they did previously
[03:47] <mjg59> Assuming that they have multiple kernels installed
[03:48] <mjg59> (I'll freely admit that our tendancy to leave kernel images around is a bug)
[03:48] <Chipzz> if you apply a little common sense to packaging, you could reduce the space requirements drastically
[03:49] <Chipzz> for example split all the wireless drivers into one package, split nvidia + ati into a seperate package
[03:49] <mjg59> Your complaint that the kernel team lack common sense is noted, thanks.
[03:49] <Chipzz> it was not meant that way
[03:50] <mjg59> Really. The current split is based on a balance of sanity and ability to maintain it
[03:50] <mjg59> It's not like we decided to waste people's hard drive space
[03:51] <mjg59> But there's a reason why the default installer doesn't partition your drive
[03:51] <Chipzz> my point is, this is not going to get any better at all
[03:51] <Chipzz> it's only going to grow
[03:51] <RAOF> But so will harddrives
[03:51] <mjg59> And so are hard drives
[03:51] <mjg59> So it's really not an issue
[03:51] <mjg59> The entire distribution is growing
[03:52] <mjg59> We can only fit it on a CD because of magic nowadays
[03:52] <Chipzz> the point is that in maybe a year or so 2 kernels may take up about half a gigabyte of space
[03:52] <Chipzz> do you still think that would be acceptable?
[03:53] <kylem> i don't think you're in any position to speculate on the size increase of modules in the kernel.
[03:53] <kylem> so this whole discussion is rather pointless and i'd rather it stop.
[03:54] <Chipzz> *sigh*
[03:54] <mjg59> Chipzz: The rate of increase in size of the kernel is commensurate with the rate of increase in size of the distribution as a whole
[03:54] <kylem> i'm willing to put money on the growth rate being barely linear.
[03:55] <mjg59> So when it requires 40GB to install Ubuntu, then yes, I'm not going to be especially unhappy about 500MB kernel images
[03:55] <mjg59> If people repartition their drives in non-standard ways, we can't be expected to support it well
[03:57] <kylem> linux-image-2.6.15-23-686_2.6.15-23.39_i386.deb                             23-May-2006 19:08   21M
[03:57] <kylem> linux-image-2.6.22-9-generic_2.6.22-9.25_amd64.deb                        03-Aug-2007 03:03   17M
[03:57] <kylem> linux-ubuntu-modules-2.6.22-9-generic_2.6.22-9.22_i386.deb          29-Jul-2007 17:03  2.4M
[03:57] <kylem> end of discussion...
[03:57] <Chipzz> kylem: you should be looking at the whole of linux-image + linux-restricted-modules + linux-ubuntu-modules
[03:58] <kylem> lrm is irrelevant to me.
[03:58] <kylem> and we didn't have lum in dapper.
[03:58] <Chipzz> kylem: 03:29 < Chipzz> 110MB for linux-image + linux-restricted modules + linux-ubuntu-modules 2.6.22
[03:58] <Chipzz> (installed size)
[03:59] <kylem> so, lrm packaged size doubeld
[03:59] <kylem> but we're shipping 3 nvidiot drivers.
[04:01] <Chipzz> ok, what this most likely boils down to is adding a few *.install files; would a patch be accepted if I made the effort of coming up with one?
[04:01] <kylem> nope.
[04:01] <Chipzz> (*.install files + meta-packages)
[04:02] <mjg59> Plus the extra dependency handling, plus the increased opportunity for random upgrade breakage
[04:03] <kylem> besides, i just proved that the size only grew by 8M compressed, across 7 kernel revisions. so seriously, stop making mountains out of molehills.
[04:03] <Chipzz> kylem: I wasn't arguing about compressed size, which should have been clear
[04:04] <Chipzz> kylem: no offence, but you're clearly trying to discard the issue with irrelevant arguments
[04:04] <mjg59> Chipzz: Working code doesn't actually tend to compress by an especially imrpessive amount
[04:04] <Chipzz> 03:57 < kylem> linux-image-2.6.22-9-generic_2.6.22-9.25_amd64.deb                        03-Aug-2007 03:03   17M
[04:04] <mjg59> Chipzz: And, y'know, telling half the kernel team that they're inept isn't an especially useful way to convince them to change things
[04:04] <Chipzz> chipzz@Vertex:/lib/modules/2.6.22-9-generic$ dpkg -s linux-image-2.6.22-9-generic | grep Installed
[04:05] <Chipzz> Installed-Size: 62504
[04:05] <Chipzz> it's 3 times the size uncompressed than it's compressed...
[04:05] <kylem> guess what, the compressability didn't change from dapper.
[04:05] <mjg59> Which results in an increase of 24MB
[04:05] <mjg59> Would you care to guess how much ubuntu-desktop grew by in the same period?
[04:06] <Chipzz> probably a lot more
[04:07] <Chipzz> mjg59: I did offer to put some time in it myself
[04:07] <mjg59> So the kernel issue is basically unimportant
[04:07] <mjg59> Hard drive usage increases between releases
[04:10] <Chipzz> mjg59: anyway, I'm not trying to insult or be rude to the kernel team here, but I think the issue is being discarded off-hand and too easily
[04:10] <ion_> Perhaps a good measure would be the size of ubuntu-desktop per the size of a hard disk one can buy at the time of release for the price of 150 bottles of beer. :-)
[04:11] <mjg59> Chipzz: Well, so far you haven't made any sort of compelling argument whatsoever
[04:11] <mjg59> The installed kernel size is increasing significantly less slowly than the size of the full installed system
[04:11] <mjg59> s/slowly/quickly/
[04:11] <Chipzz> mjg59: this is not meant personally, but I think for example your argument about dependency handling is totally bogus
[04:12] <mjg59> Chipzz: That's clearly because you've never had to handle packaging l-r-m
[04:12] <Chipzz> I think it can be handled perfectly well in control by using the right substitution variables
[04:12] <Chipzz> s;control;debian/control
[04:13] <mjg59> Chipzz: We've gained 30MB from 6.06 to 7.10. That's ~10MB a release.
[04:14] <mjg59> Really, that isn't a quantity to care about
[04:14] <kylem> blame nvidia.
[04:14] <Chipzz> say you split off linux-wireless-drivers from linux-restricted-drivers; that something which can be handled perfectly by editting debian/control and adding 1 .install file
[04:14] <mjg59> Chipzz: You still haven't explained /why/
[04:16] <Chipzz> because the kernel is an ever-growing package, which for the most part stems from adding drivers, only a tiny fraction of which is actually used
[04:16] <Chipzz> for linux-restricted-modules this also pulls in a lot of firmware
[04:16] <Chipzz> most of which is not used either
[04:16] <mjg59> Chipzz: We're talking about 10MB a release. How do you actually see this being a problem in the real world? How much hard drive space do you believe would be saved?
[04:17] <LaserJock> In a lot of ways I want to have all of lrm available
[04:17] <Chipzz> depends on how much you split it, but depending on fine you split, a wild guess is you could reduce the installed size frmo 110MB to say 70 or 80MB
[04:17] <Chipzz> s/on fine/on how fine/
[04:18] <Chipzz> per installed kernel
[04:18] <LaserJock> if I add hardware, etc. I don't want to worry about installing some other package
[04:18] <mjg59> Chipzz: Look. I've spent this evening convincing someone not to kill themselves. I think that was more important to them than the size of LRM was to you, so do you really think you're going to win this argument?
[04:19] <Chipzz> mjg59: convincing some-one not to kill themselves is a very noble thing, and I applaud you for that
[04:19] <mjg59> Convincing people not to complain about unimportant aspects of the distribution is also a noble thing
[04:19] <Chipzz> I can understand something like that tires you, so I guess I'll let the issue rest not to annoy you
[04:20] <LaserJock> Chipzz: I'm guessing the best way to go would be to send a proposal with some numbers, taking into account maintenance overhead to the kernel list
[04:21] <Chipzz> LaserJock: I was already told a patch would not be accepted
[04:21] <LaserJock> Chipzz: you were? I didn't really see that
[04:22] <Chipzz> 04:01 < Chipzz> ok, what this most likely boils down to is adding a few *.install files; would a patch be accepted if I made the effort of coming up with one?
[04:22] <Chipzz> 04:02 < Chipzz> (*.install files + meta-packages)
[04:22] <Chipzz> 04:01 < kylem> nope.
[04:22] <Chipzz> sorry
[04:22] <Chipzz> pasted out of order
[04:22] <mjg59> Chipzz: No, that's based on your false assertion that it would just be a few .install files
[04:22] <LaserJock> well, you'd want to get the proposal accepted before the patch
[04:23] <Chipzz> LaserJock: from my experience with open source the best way to get something done is to put your money (patch :P) where your mouth is ;)
[04:23] <mjg59> If you could demonstrate that we could save a significant amount of installed disk space with approximately no overhead, then we'd probably go for that
[04:23] <mjg59> But I think it's unlikely that you could
[04:24] <LaserJock> Chipzz: yeah, but's also good to discuss methodology and feasibility before hand
[04:25] <Chipzz> mjg59: but if you still think size is irrelevant, how do you marry that with use-cases where space *is* relevant, like embedded use cases, which ubuntu is clearly going for (the lpia architecture)?
[04:25] <LaserJock> but complaint is with l-r-m
[04:25] <mjg59> Chipzz: We build the kernels with different config options
[04:26] <mjg59> Bear in mind that lpia is not an embedded platform in any real way
[04:28] <Chipzz> I'm not completely up-to-date on the whole lpia thing, but as far as I understand it is related to an embedded spec?
[04:28] <mjg59> No
[04:28] <mjg59> lpia has a 900MHz CPU (at least) and more than a GB of storage by default
[04:28] <mjg59> That's not embedded in any real sense of the word
[04:29] <LaserJock> hmm, that's about lie my new oscilloscope
[04:29] <LaserJock> *like
[04:29] <Chipzz> mjg59: anyway, I do respect you for a lot of the things you do, so I'm going to stop arguing since I'm clearly just annoying you
[04:30] <Chipzz> I may take a look at this in the future and see if something is possible
[04:30] <kylem> why don't you just add something like localepurge?
[04:30] <kylem> and rm modules you don't care about
[04:30] <kylem> and not make my life much more difficult?
[04:31] <Chipzz> kylem: I'm not intent on making anyones life more difficult on purpose
[04:32] <kylem> have you looked at how the linux-image package works? adding install files would make our lives quite a bit more difficult...
[04:32] <Chipzz> those can most likely be automatically generated, right?
[04:32] <kylem> right now we just blat them all into one place...
[04:33] <Chipzz> kylem: correct me if I'm wrong, but you're already doing that for the udebs anyway, right?
[04:35] <kylem> that's more complicated since the udebs are only done for a single flavour, and only for certain modules.
[04:35] <Chipzz> so it would involve adding a couple of extra steps similar to the steps necessary for the udebs
[04:35] <ScottK> Well it looks like I got from Dapper to Gutsy OK and with no extra rebooting along that way.  It was interesting.  I don't think I'll do it again.
[04:36] <kylem> we only add things to udeb when they're needed for the installer, having to muck about with where modules go everytime a new one is added is a pain in the arse.
[04:37] <Chipzz> kylem: anyway, if I were to look into it, and come up with a solution that would not involve to much pain on your end, woudl that be acceptable?
[04:37] <Chipzz> s/to/too
[04:37] <kylem> so, something like localepurge would be the better solution.
[04:37] <kylem> i can't stop you from doing anything, nor am i the only person who makes decisions
[04:37] <kylem> this is a community project...
[04:38] <Chipzz> but you are clearly opposed to it :P
[04:38] <Chipzz> anyway something like localepurge sounds like it will mess with the packaging system, ie a very dirty hack
[04:39] <mjg59> Chipzz: Something like linux-wireless-modules is clearly impossible, given that wireless drivers come from three different source packages
[04:40] <mjg59> The only significant space-saving you could do would be to split out the nvidia drivers, which becomes a nightmare for different reasons
[04:40] <Chipzz> mjg59: ok I'm probably too ignorant, but how do they all end up in lrm then?
[04:40] <mjg59> Chipzz: They, uh, don't?
[04:40] <mjg59> The only wireless driver in l-r-m is ath_pci
[04:40] <mjg59> The rest are in l-u-m and l-k
[04:40] <Chipzz> ipw* used to be in lrm, right?
[04:41] <kylem> no. never.
[04:41] <kylem> the userspace daemon is in lrm.
[04:41] <kylem> s/lrm/& src/
[04:42] <mjg59> ipw2100 and ipw2200 have always been in l-k
[05:46] <fabbione> morning
[05:55] <lifeless> hi fabbione
[05:55] <lifeless> hey does anyone know if trackerd is expected to honour the 'indexing preferences' control panel?
[06:47] <RAOF> lifeless: I believe that it should, but that it requires a restart of trackerd
[06:49] <ion_> That should be easy to fix.
[06:50] <ion_> Make trackerd track the config file, make the preferences program kill -HUP trackerd (and make trackerd support reloading config on signal if necessary), or just kill and restart trackerd.
[06:51] <lifeless> a reboot counts :)
[06:52] <lifeless> and it ignored the 'dont index' setting :(
[06:52] <lifeless> I realised this when it used all my memory and VM
[06:53] <ion_> Wow. Thats a bad bug.
[06:54] <LaserJock> Hobbsee!
[06:55] <Hobbsee> LaserJock!!!
[06:55] <ajmitch> that's when I just removed tracker
[06:56] <Hobbsee> hiya ajmitch
[06:56] <ajmitch> hello Hobbsee
[06:57] <LaserJock> hmm, I don't even notice tracker on my computer
[06:57] <lifeless> yeah, I just removed it too
[06:57] <lifeless> i have a laptop
[06:58] <RAOF> It'd be nice if it didn't exhaustively trawl ~/ on every login.
[06:58] <LaserJock> I wonder if it depends a lot on how much is being indexed
[06:58] <lifeless> I only have 70G in ~
[06:58] <StevenK> I daresay most developers have very large $HOME directories.
[06:58] <LaserJock> I have a 360MB cache and trackerd takes 11MB memory
[06:58] <lifeless> reading my entire disk basically on every login in is a terrible idea
[07:00] <LaserJock> trackerd doesn't bug me so far, but I have no use for it either
[07:05] <TheMuso> On notebook speed HDs, it is noticable.
[07:05] <TheMuso> Don't know about 3.5 drives yet, but I will soon.
[07:15] <StevenK> Morning pitti!
[07:15] <StevenK> pitti: How's married life?
[07:15] <pitti> Good morning
[07:15] <pitti> StevenK: wonderful! we had a great weekend
[07:15] <ajmitch> hey pitti
[07:16] <fabbione> pitti: that was also the last one :P
[07:16] <ajmitch> congrats
[07:16] <pitti> fabbione: hehe
[07:16] <StevenK> pitti: My answer to that for the first 3 months or so was, "It's the same, except I no longer have a wedding to plan."
[07:16] <LaserJock> pitti: congrats!
[07:17] <pitti> StevenK: heh, indeed; that kept us busy for a long time
[07:17] <pitti> LaserJock: thanks!
[07:17] <Hobbsee> pitti!
[07:18] <StevenK> Hrm. Nice. Ex Falso segv's on my laptop.
[07:18] <Hobbsee> morning fabbione
[07:19] <StevenK> Actually, I'm wrong. It segfaults if $DISPLAY is unset.
[07:20] <StevenK> pitti: Are you back officially? IE, can I bug you about NBS stuff. :-)
[07:21] <pitti> StevenK: give me some 20 minutes to look for some first photos for the curious folks, then I will
[07:22] <fabbione> hey Hobbsee
[07:22] <Hobbsee> pitti: :)
[07:23] <StevenK> pitti: Sure. Point me at the photos too. :-)
[07:37] <pitti> ok, first six photos: http://www.piware.de/fotos/Hochzeit-Vorschau/ (I have a real mountain of pics to dig through, and lots are still missing)
[07:38] <StevenK> Woodchopping!?
[07:38] <dholbach> good morning
[07:39] <Hobbsee> dholbach!!!
[07:39] <Hobbsee> pitti: nice!
[07:39] <dholbach> how much wood would a woodchuck chuck if a woodchuck would chuck wood?
[07:39] <StevenK> Agreed
[07:39] <dholbach> hey Hobbsee
[07:39] <pitti> StevenK: yeah, that's a rite in Germany at least -- the new couple proves that it can achieve something together
[07:39] <StevenK> dholbach: A woodchuck would chuck all the wood if a woodchuck could chuck wood
[07:40] <dholbach> StevenK: ahhh, good to know ;-)
[07:40] <fabbione> pitti: eheh funny
[07:40] <StevenK> dholbach: And s/would chuck wood\?/could chuck wood?/
[07:41] <dholbach> maybe
[07:47] <LaserJock> hmm, is mvo around?
[07:47] <Hobbsee> LaserJock: maybe a little early for th
[07:48] <Hobbsee> at
[07:49] <LaserJock> k, but he's not on vacation or anything
[07:51] <Hobbsee> not to my knowledge, but i dont know such things :)
[07:56] <pitwalker> have anyone ATI RADEOX X550? !!!
[07:56] <Hobbsee> pitwalker: i think you want #ubuntu
[07:56] <pitwalker> no
[07:57] <pitwalker> current ATI driver is so bad
[07:57] <pitwalker> I run currentlz xfce4
[07:57] <pitwalker> and my keyboard map also crashed (y->z, 0->)
[07:58] <pitwalker> and my console characterset
[08:00] <Chipzz> pitwalker: this is not the correct place to come complain about bugs in packages; you're probably better off filing a bug
[08:01] <pitwalker> ok
[08:01] <ajmitch> hey dholbach
[08:01] <Chipzz> (besides the fact that you don't mention the version of ubuntu you're running)
[08:01] <dholbach> hey ajmitch :)
[08:01] <ajmitch> have a good holiday? :)
[08:01] <pitwalker> this morning is painfullz for me (apt-get * 6) , kernel stops
[08:02] <pitwalker> I run 7.04 with all updates
[08:02] <dholbach> ajmitch: absolutely - once I'm through my 30000 new emails, I'll probably write something up about it and post some pictures :)
[08:02] <pitwalker> AMD 64
[08:03] <Hobbsee> pitwalker: you know that AMD distribute their drivers, and not us?  if you want to complain about the video drivers, you'd r eally have to go to them.
[08:03] <pitwalker> i write to AMD
[08:03] <pitwalker> i'm very sad :-(
[08:03] <Chipzz> Hobbsee: though I doubt his keyboard settings are related to the ATI driver ;)
[08:03] <Hobbsee> Chipzz: indeed :)
[08:04] <Hobbsee> Chipzz: i was merely commenting on the one that hadnt anything to do with us
[08:04] <pitwalker> before laters ATI driver, these thinks works good
[08:04] <pitwalker> things
[08:04] <Chipzz> pitwalker: but even then there's little we can do about the quality of the ATI drivers
[08:04] <pitwalker> I drop mz ATI card.... Thank for answers, thats all folks :-)
[08:06] <Chipzz> pitwalker: the big vendors (ATI, NVidia) most likely care more about complaints of big vendors (like dell etc) than about complaints frm individual users or linux distributions
[08:06] <pitwalker> (Chipzz: sorry I dont understand everything correctly, my english is so bad)
[08:08] <pitwalker> I hope: the time can solve this issue
[08:08] <Chipzz> pitwalker: what I'm saying is that big hardware vendors (like dell and ibm etc), which do buy hardware from ati in large quantities, most likely have more leverage in getting bugs fixed (though this is quite off-topic)
[08:08] <pitwalker> :-)
[08:46] <StevenK> pitti: At your leisure, bonfire, gaphor-lib, iceape-calendar, libgig3c2 and libmtp5 can be NBS'd out.
[08:51] <pitti> StevenK: thanks, done
[08:53] <Hobbsee> morning sabdfl
[08:53] <sabdfl> hey Hobbsee
[08:53] <sabdfl> i'm always envious of people in timezones further ahead
[08:54] <sabdfl> feels like they are somehow getting a peek at the future all the time
[08:54] <Hobbsee> sabdfl: just move to australia.
[08:54] <sabdfl> not sure they would have me
[08:54] <Hobbsee> sabdfl: incidently, it makes me very good at predicting the future :P
[08:54] <sabdfl> i understand they disapprove of gentlemen's clubs
[08:54] <Hobbsee> sabdfl: the long plane flights long take away any of hte timezone benefits
[08:54] <Hobbsee> sabdfl: you're all turning up now, and it's 5pm.
[08:55] <Hobbsee> i'd find it hard to know about the gentleman's clubs, oddly enough :P
[08:55] <StevenK> pitti: Thanks
[09:50] <pygi> Hobbsee, dont grumble
[09:50] <dholbach> hey mvo!
[09:50] <mvo> hey dholbach!
[09:50] <Hobbsee> pygi: apparently alt+q is a shortcut for quit.
[09:50] <Hobbsee> i really should disable that.
[09:51] <pygi> dholbach is alive!
[09:58] <\sh> dholbach: moins..how was your holiday? :)
[09:58] <dholbach> \sh: absolutely fantastic - thank you
[10:31] <Riddell> Mithrandir: could you give back kdepim?
[10:33] <pitti> Riddell: nothing to give back, it's in depwait
[10:35] <Riddell> pitti: manual dep wait, and has been all weekend
[10:44] <infinity> Riddell: "manual" dep wait means the buildds put it on dep-wait because the package isn't available.
[10:44] <Riddell> infinity: it's now available
[10:44] <infinity> Riddell: Without even looking, I'll give 20-to-1 odds you have a main source dep-waiting on a universe binary.
[10:44] <infinity> Riddell: If it's available, it'll be retried, no intervention required.
[10:44] <Riddell> libopensync-dev installs fine for me with only main packages
[10:44] <Riddell> it's a provides from libopensync0-dev, could that confuse it?
[10:45] <infinity> Oh, hrm, that could be broken code in soyuz.
[10:45] <infinity> Alright, I'll hand it back manually for now.
[10:45] <Hobbsee> what, more of it?  :P
[10:52] <StevenK> infinity: Ping!
[11:07] <StevenK> infinity: libnss-db, etc, etc, after UVF, etc, etc. :-P
[11:19] <Kopfgeldjaeger> pitti: what's the state of this "mirror" system (wl_apsta.o)? i am not sure if i want to keep this all the time on the server (i do not have unlimited traffic ;) ) *g
[11:19] <pitti> Kopfgeldjaeger: oh, that was your's?
[11:19] <pitti> Kopfgeldjaeger: Debian changed the URL, I'll probably use that then
[11:19] <Kopfgeldjaeger> pitti: yes, atm it is not a problem (only 1 gb in some days, i have 20GB free traffic)
[11:20] <pitti> that's quite big indeed
[11:30] <spike> hi
[11:30] <spike> Package: ubuntu-xen-desktop-amd64
[11:30] <spike> Description: Xen software for running on desktops. This package will install a suite of software for running Xen on servers.
[11:30] <spike> that's slightly confusing to me
[11:30] <spike> should that be filed as a bug?
[11:31] <spike> this is ubuntu-server, feisty
[11:31] <Mithrandir> yes
[11:31] <Mithrandir> it's the same in gutsy
[11:31] <geser> spike: already filed as a bug
[11:32] <geser> I've an updated package ready any will upload it in a few minutes
[11:32] <spike> oh, awesome
[11:32] <Lutin> pitti: can you give-back foptions and gmult please ?
[11:33] <pitti> Lutin: done
[11:33] <Lutin> thanks
[11:35] <spike> geser: uhm, ok, so that fixes the description, but leaves out the problem of xen on servers... is there anything palnned for it? an ubuntu-xen-server would be nice
[11:37] <Lutin> pitti: can you also give-back mozilla-bonobo please ?
[11:37] <spike> uhm, it's actually in universe... I wonder why it doesnt show up with search
[11:42] <pitti> Lutin: done
[11:43] <Lutin> pitti: thanks
[11:47] <mdz> mvo_: for some reason, switch to workspace doesn't seem to work on my laptop, though it works on my desktop
[11:49] <mvo_> mdz: could you please check if gotovp is part of your plugins on the laptop? either in gconf-editor (/apps/compiz/general/allscreens/options/active_plugins) or with ccsm (compizconfig-settings-manager)?
[11:49] <mdz> mvo_: ok, will check it tonight
[11:49] <mvo_> mdz: thanks!
[11:50] <geser> Mithrandir: can you also move ion3-mod-ionflux to multiverse?
[11:52] <Mithrandir> geser: I thought I did, redoing
[11:53] <geser> thanks
[11:53] <Mithrandir> geser: done
[11:56] <spike> ok, problem is ubuntu-xen-server doesnt exist for amd64, that's why it wasnt showing up
[12:06] <mvo_> asac: I use network-manager in manual configuration mode and it displays "no connection" again (this worked a couple of days ago). do you know about this?
[12:08] <asac> mvo_: hmm ... how many interfaces do you have?
[12:10] <mvo_> asac: two
[12:11] <asac> mvo_: which one does it map to the applet when it works?
[12:13] <asac> mvo_: i don't know exactly about manual configuration ... but otherwise it cannot really deal with two active connections.
[12:14] <mvo_> asac: it worked with a older versions, there it was assuming that manual connection is a different state and that it means the machine is connected
[12:14] <mvo_> asac: currently e.g. pidin does not login
[12:14] <mvo_> asac: it says "waiting for network"
[12:16] <asac> mvo_: do you remember with which version it worked reliably?
[12:18] <mvo_> asac: no I can try to figure it out from my upgrade logs, I just remember that I have seen a patch for manual configuration some time ago that used to be part of the package
[12:18] <asac> ah
[12:18] <asac> let me look
[12:18] <asac> but that patch is still in there iirc
[12:19] <asac> hmm its still applied
[12:20] <asac> mvo_: http://people.ubuntu.com/~asac/21_manual_means_always_online.diff
[12:20] <asac> mvo_: interesting is that again ... people fail to initialize fields ... not that it should matter here
[12:21] <asac> mvo_: i will take a closer look now ... this patch looks interesting ;)
[12:25] <mvo_> asac: I think it was in Preparing to replace network-manager 0.6.5-0ubuntu7 (using .../network-manager_0.6.5-0ubuntu9_i386.deb) ...
[12:27] <asac> mvo_: can you say that it never works now ... or is there some randomness in it?
[12:27] <asac> mvo_: can you say that i always worked with ubuntu7 ... or is there some randomness ;) ?
[12:27] <mvo_> asac: it seems to never work now
[12:28] <asac> ok ... did you try to restart network-manager?
[12:28] <asac> (i think you did ... just asking to confirm)
[12:28] <mvo_> asac: I'm not sure about the exact version when it worked, but I think when it worked, it worked (take it with a grain of salt, I suspend/resume this machine a lot, so there might have been a old version runing)
[12:29] <mvo_> asac: restarting seems to have no effect
[12:29] <asac> damn ... can you try ubuntu7 ?
[12:39] <mvo_> asac: I ca do that, give me a bit
[12:42] <Utnubu> hi all
[12:42] <asac> mvo_: both interfaces configured static?
[12:42] <asac> mvo_: whatever i do it works for me here ... hmm
[12:42] <mvo_> asac: yes
[12:42] <asac> mvo_: let me reboot with that configuration
[12:42] <mvo_> asac: I see "no network connection" in the applet
[12:43] <Utnubu> Is the bug known that it isn't possible to restart gdm on Gutsy live cd?
[12:43] <seb128> Utnubu: yes
[12:43] <seb128> Utnubu: is there any need to restart gdm there?
[12:43] <Utnubu> ok, it happens since some weeks
[12:44] <Utnubu> Yes, if I change the graphic driver
[12:44] <pitti> Utnubu: ctrl+alt+backspace should do
[12:44] <Utnubu> Not if X crashes because it doesn't work with the settings.
[12:44] <seb128> ?
[12:45] <Utnubu> the problem is, that the latest daily uses vesa per default. The standard one uses i810 but I need intel driver for external monitor.
[12:45] <seb128> switch to a vt1, edit the config, switch to gdm, ctrl-alt-backspace?
[12:45] <Utnubu> If I restart X with ctrl + alt + backspace and X couldn't start because of some problems I couldn't restart X after xorg.conf change in console
[12:46] <mvo_> asac: joy! ubuntu7 does not build for me ./
[12:46] <asac> mvo_: build? can't you try the debs?
[12:47] <asac> mvo_: anyway ... how does it fail?
[12:47] <mvo_> asac: I can't find  them
[12:48] <mvo_> asac: http://paste.ubuntu-nl.org/34383/
[12:48] <pitti> hi Yagisan
[12:49] <infinity> mvo_: (No, I don't need this, this is for if you ever mainline the bi-arch feature) How hard would it be to make apt be able to pin on an arch?
[12:49] <mvo_> infinity: no idea
[12:50] <infinity> mvo_: So, if lpia and i386 both have the package, but i386's is newer, I still get the lpia one.
[12:50] <Yagisan> pitti, I'm really wishing I had an intel pcie card right now. my evil nvidia card isn'y supported by any of gutsys drivers
[12:50] <asac> mvo_: ah
[12:50] <infinity> mvo_: Academic currently, cause I'm removing the bi-arch apt from production today, but I think it'd be required for mainlining the feature (which I'd like to do)
[12:50] <mvo_> infinity: I think it should be not very hard, it could be done in a similar way as experimental, but adding the non-automatic attribute
[12:50] <asac> mvo_: you need a patch ... because druid was deprecated in gnome
[12:51] <mvo_> infinity: I'm currently a bit busy, but I would like to get biarch done nicely at some point too
[12:51] <infinity> mvo_: Yeah, it's hardly critical, like I said, I'm pulling it out of production today anyway.
[12:52] <infinity> mvo_: But if you can mail me a pointer to the branch the bi-arch stuff is on, I could perhaps mull it over in my copious "free time" and clean some bits up.
[12:52] <asac> mvo_: http://people.ubuntu.com/~asac/41e_fix_vpn_ftbfs_dont_disable_gnome_deprecated.patch ... just drop that in patches
[12:54] <mvo_> infinity: ok, will do :)
[12:55] <cjwatson> triggers got implemented!
[12:58] <tseliot> hi! Can I bother you for a second about a bug I think I have solved?
[12:59] <infinity> iwj: Say, do you know anything about dpkg? :P
[01:00] <tseliot> the bug I'm talking about affects nvidia-glx-new
[01:01] <infinity> tseliot: Is the bug filed?
[01:01] <infinity> tseliot: If so, you can follow up to the bug with your solution.  If not, you can file the bug, and then do so...
[01:01] <tseliot> Sure, and I have provided 2 patches as well:
[01:01] <tseliot> https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/98641
[01:01] <ubotu> Launchpad bug 98641 in linux-restricted-modules-2.6.20 "[nvidia-glx-new]  NVidia driver missing libwfb" [High,Confirmed] 
[01:02] <tseliot> It affects both Feisty and Gutsy
[01:03] <ogra> bryce, seb128, i seem to not be able to use gnome-screensaver recently on thin clients ...
[01:03] <seb128> ogra: what happens when you try?
[01:04] <ogra> grr, my copy paste is broken it seeem
[01:05] <ogra> seb128, i get an 'XF86VidModeClientNotLocal'  gdk/X error
[01:05] <seb128> looks like an xorg issue
[01:06] <ogra> thats why i had bryce in the ping ;)
[01:06] <ogra> seb128, i was wondering if consolekit could have any influence here
[01:07] <seb128> not likely
[01:07] <cjwatson> iwj: is anyone writing a man page for dpkg-trigger already?
[01:09] <asac> mvo_: if you need amd64 packages ... just let me know ... the build just finished ;)
[01:09] <mvo_> asac: building now
[01:11] <cjwatson> iwj: if you'd like a test case, I'd be happy to try it out in man-db; that's just a file trigger on /usr/share/man and I don't think any package creates anything there in maintainer scripts so it should be entirely straightforward
[01:12] <cjwatson> (and it's not essential for system boot or anything like that)
[01:12] <ImNOTcesarefranc> mvo: I hope there was not misunderstanding Michael? My last email was meant to help you
[01:12] <mvo> asac: no, same problem with -7
[01:13] <mvo> ImNOTcesarefranc: the one about the mentoring? no problem, I don't think there was a misunderstanding :)
[01:13] <ImNOTcesarefranc> mvo: cool! thanks
[01:17] <cjwatson> iwj: since trigger support in man-db is optional (in the sense that it just puts us back to the state we're in now where your apropos database is sometimes out of date and occasionally people get a bit confused but it's not a disaster), do you have any objection if I omit the versioned dependency on the trigger-supporting dpkg?
[01:18] <asac> mvo: wierd ... did you edit your interfaces file by hand or through nm-applet?
[01:18] <mvo> asac: I think manually
[01:19] <asac> can you post it?
[01:22] <keyes> mpt, are you here ? :)
[01:30] <iwj> cjwatson: No, that's entirely fine.
[01:30] <iwj> cjwatson: You can omit that dependency if your update script thingy works anyway.
[01:31] <iwj> man page> No, I should do that.  It won't be very long.
[01:32] <mpt> keyes, hi
[01:59] <mpt> keyes_, what's up?
[01:59] <cjwatson> forgotten how to route to Freenode
[01:59] <Hobbsee> cjwatson: dont.  it behaves worse.
[01:59] <Hobbsee> cjwatson: trust me.
[01:59] <keyes_> mpt, have you received my messages ?
[02:00] <Hobbsee> cjwatson: it's more fun when it makes your phone fall over as well, though.
[02:01] <mpt> keyes_, messages to where?
[02:02] <keyes_> here but i've network issues
[02:02] <keyes_> i've copy / Pasted them in private
[02:03] <mpt> keyes_, perhaps when you reconnected you didn't identify with NickServ again
[02:03] <keyes_> sure
[02:03] <cjwatson> iwj: thanks. Does http://people.debian.org/~cjwatson/tmp/man-db.triggers.diff look reasonable?
[02:04] <keyes> i must go away for some minutes i'll be back ^^
[02:09] <cjwatson> iwj: I noticed in today's upgrade that I got the following sequence of events near the end: configure initramfs-tools, "update-initramfs: Generating /boot/initrd.img-2.6.22-9-powerpc"; configure udev, apparmor, usplash, each gives "update-initramfs: deferring update (trigger activated)", and then "Processing triggers for initramfs-tools ..." "update-initramfs: Generating /boot/initrd.img-2.6.22-9-powerpc"
[02:10] <cjwatson> iwj: should initramfs-tools make use of its own trigger?
[02:10] <cjwatson> iwj: definitely a huge improvement already though
[02:13] <infinity> cjwatson: I imagine it should use its own trigger, yes.
[02:13] <cjwatson> iwj: (i.e. the test plan in the spec will currently fail since update-initramfs happens twice rather than once)
[02:27] <xhaker> iwj: good work. I've seen triggers mentioned on dpkg changelog but didn't know it was that cool :D
[02:31] <cjwatson> W: man-db: unknown-control-file triggers
[02:31] <cjwatson> hah
[02:31] <cjwatson> iwj: (I'll fix that in lintian once it lands in Debian dpkg)
[02:32] <iwj> cjwatson: What does your postinst do if it's not "triggered" ?
[02:32] <elmo> hi Hobbsee
[02:32] <iwj> You still need to run mandb on configuration.
[02:32] <cjwatson> iwj: yes, it does that
[02:32] <cjwatson> that's subject to debconf though for various reasons
[02:32] <iwj> cjwatson: OIC what you mean.
[02:32] <cjwatson> and also doesn't necessarily need to be done on every upgrade
[02:33] <iwj> Hmm.  I think there's a problem here which is that a package isn't considered interested in triggers until the postinst completes.
[02:34] <cjwatson> iwj: is that "while state is unpacked" or "until the package has been configured at least once"?
[02:34] <iwj> Maybe I should change that.
[02:35] <cjwatson> iwj: perhaps consider it interested, but defer the activation of the trigger until after the postinst completes
[02:35] <cjwatson> iwj: I can see why you might not want to run triggers while the package is only unpacked ...
[02:38] <ion_> dholbach: Whats the reason for Tangerine not inheriting Tango anymore?
[02:39] <iwj> The former.
[02:39] <iwj> (And the relevant state is `half-configured or any worse state'.
[02:39] <iwj> No, the question is whether they're even recorded.
[02:40] <iwj> I had the idea that running the postinst would do all of the triggers and that therefore there was no point tracking them if we're going to postinst configure.
[02:41] <dholbach> ion_: lapo thinks that the tangerine icons look better with the new gnome ones
[02:41] <dholbach> ion_: I did it on his request
[02:41] <iwj> If successful `postinst configure' doesn't mean there are now no triggers pending then it's not at all clear why the triggers script is the postinst script at all ...
[02:42] <ion_> dholbach: Alright, thanks.
[02:43] <iwj> To avoid the double-activation I can make the is-interested criterion include `half-unpacked because we are running the postinst'.
[02:43] <iwj> I think in fact I may already have done that.
[02:44] <iwj> I mean, half-configured of course.
[02:45] <ion_> Not only an away nick, but one for being *right back*? What is the world coming to? :-)
[02:46] <iwj> Oh dear, ENOSPC.
[02:46] <iwj> Well I suppose Monday after FF is a good time to install that new 300G disk.
[02:46] <cjwatson> iwj: making configure not a superset of triggers would be useful for the update-initramfs case above
[02:46] <cjwatson> err triggered
[02:47] <iwj> Yes.
[02:48] <cjwatson> triggered made sense in postinst, but more because it's a step beyond configuration than because it's a step that's part of configuration
[02:48] <cjwatson> I'm not sure that makes sense to anyone else
[02:48] <ion_> I take it having dpkg run package.postinst trigger name-of-trigger was considered and deemed bad?
[02:48] <cjwatson> ion_: modulo spelling, that's what it does
[02:49] <iwj> initramfs's postinst configure already is a superset of its triggers; the problem is just that it would be nice to do it only once.
[02:49] <iwj> Your problem with mandb is that your postinst wants not to be a superset of the triggers - ie, sometimes not run mandb.
[02:50] <cjwatson> initramfs-tools> yes, it is, but I suggest that perhaps it should not be if triggers are active
[02:50] <cjwatson> it's possible that nowadays it would be OK to run mandb -pq on all upgrades
[02:51] <cjwatson> (or -cq if the db format changes)
[02:51] <cjwatson> it used to be a lot slower than it is now
[02:51] <iwj> Changing this fact about triggers would involve some thought.
[02:52] <cjwatson> hmm, still takes 18s of real time here though
[02:52] <iwj> I think I would rather leave that to a later occasionl.
[02:52] <iwj> s/ionl/
[02:52] <iwj> s/occas/&ion
[02:52] <cjwatson> though if there's nothing to do, it takes 0.4s
[02:52] <cjwatson> so perhaps it is indeed man-db that should change
[02:53] <iwj> Certainly if you have a way of telling whether you need to do anything then my proposal above (enabling a package to trigger itself) would be sufficient.
[02:54] <iwj> (sufficient for being able to write code in the package which always runs things the minimum number of times)
[02:55] <cjwatson> also I wish man-db did not have to use that perl splat to drop privileges
[02:55] <iwj> Depends: chiark-really   :-)
[02:57] <cjwatson> maybe I should. Or just get really into debianutils and then I wouldn't have to worry about promoting yet another package to Priority: important ;-)
[02:57] <cjwatson> BTW surely really does not work properly on Ubuntu at the moment
[02:57] <cjwatson> at least new installations where /etc/inittab won't exist
[02:58] <iwj> cjwatson: It won't work for escalation, but that's probably OK.  It will work for what you want to do.
[02:58] <iwj> You want to get with-lock-ex into debianutils too.
[02:58] <iwj> If you go that route.
[02:59] <cjwatson> I won't go that route for now, but maybe at a later date yes
[02:59] <cjwatson> another copy of that code has been in man-db for five years so nobody will care much if it stays there a while longer
[03:00] <cjwatson> what would the right fix for really+upstart be? Write permissions to /etc/event.d/ ?
[03:00] <iwj> *snort*
[03:00] <cjwatson> seems roughly equivalent
[03:00] <iwj> Tempting to say `write permissions to /'.
[03:01] <iwj> I just picked inittam because it was likely to be (a) preserved and (b) not liable to accidents in the way that `/' or `/etc' would be.
[03:01] <iwj> accidents>  rm -rf *  in the wrong directory
[03:06] <cjwatson> I think I'll remove the stuff that sometimes starts mandb in the background too. It can only happen when not running from debootstrap, and nearly always man-db will be installed from debootstrap or else when very few packages are installed so it won't take very long anyway.
[03:25] <asac> hmmm ... is ooo again broken in gutsy?
[03:28] <ImNOTcesarefranc> asac: you mean things like bug 133484 or something more important?
[03:28] <ubotu> Launchpad bug 133484 in openoffice.org-voikko "Problems upgrading in gutsy current (as of 2007-08-19)" [Undecided,In progress]  https://launchpad.net/bugs/133484
[03:30] <asac> ImNOTcesarefranc: ... no i don't see upgrade problems ... for me oowriter doesn't start at all and girlfriend needs to work on my laptop :/
[03:32] <ImNOTcesarefranc> asac: I see, mine starts just fine.
[03:33] <asac> wierd
[03:34] <asac> calc: already awake?
[03:45] <geser> asac: oowriter starts fine for me too (2.3.0~src680m224-1ubuntu2, AMD64)
[03:46] <seb128> asac: to you have openoffice.org-gnome installed?
[03:49] <asac> seb128: i can take a look ... in a few minutes
[03:50] <asac> thanks for the hint
[03:50] <seb128> asac: you're welcome
[03:51] <asac> is it required?
[03:55] <seb128> asac: it's a workaround for the hang issue which is happening recently
[03:56] <seb128> the real bug is that openoffice uses gdk functions without calling gdk_init()
[04:00] <asac> is it so difficult to add that line?
[04:01] <asac> e.g. so difficult that a workaround is worth it?
[04:02] <seb128> asac: from what I read calc has a patch ready
[04:02] <seb128> asac: adding the line is not hard, what takes time is likely to build openoffice to test a change
[04:03] <asac> seb128: ok.
[04:03] <seb128> I don't maintain openoffice nor use it, I was just giving the workaround in case it helps you ;)
[04:03] <asac> seb128: sure ;)
[04:14] <DaBonBon> can someone please look at this bug - https://bugs.launchpad.net/bugs/132603
[04:14] <ubotu> Launchpad bug 132603 in uswsusp "Please update the uswsusp package" [Wishlist,Triaged] 
[04:15] <DaBonBon> it's almost time
[04:15] <DaBonBon> i'm sure this small change would pass through the freeze :(
[04:17] <ScottK> DaBonBon: It's a Universe package, so #ubuntu-motu would be the channel for that.
[04:17] <DaBonBon> thanks ,ScottK
[04:18] <mjg59> DaBonBon: No. It's not a trivial merge, and given that uswsusp isn't installed by default it's not clear to me how it could influence out of the box behaviour
[04:19] <DaBonBon> mjg59: err, why is not a trivial merge ?
[04:20] <DaBonBon> mjg59: it won't influence out of the box behaviour. it influences behaviour once installed, the whitelist
[04:20] <asac> seb128: it worked ... my gf is now happy ... thanks!!!
[04:20] <seb128> you're welcome
[04:20] <ogra> seb128 makes our GFs happy :
[04:20] <ogra> :)
[04:21] <ogra> *g*
[04:21] <seb128> heh
[04:21] <mjg59> DaBonBon: Because we carry heavy local patches
[04:21] <mjg59> DaBonBon: Ideally our uswsusp package wouldn't ship the s2ram binary
[04:22] <DaBonBon> mjg59: but just updating whitelist.c ?
[04:22] <mjg59> No. If you have machines where s2ram works and our existing code doesn't, please file bugs.
[04:22] <DaBonBon> s2both is really weird.. it does a full hibernate
[04:22] <DaBonBon> mjg59: yes, i've got such machines
[04:22] <mjg59> DaBonBon: Bug numbers?
[04:22] <DaBonBon> not filed, because it works with s2ram
[04:22] <mjg59> No. That's not the correct answer.
[04:23] <mjg59> Please file bugs.
[04:23] <mjg59> And I'll upload a new uswsusp without s2ram
[04:23] <cypherbios> mvo: thanks for sponsoring that upload
[04:23] <DaBonBon> i don't see the point - kernel suspend and hibernate breaks with every point release
[04:23] <mjg59> ?
[04:23] <DaBonBon> never worked for me, except on some lucky days
[04:23] <mjg59> s2ram uses exactly the same codepaths
[04:23] <Hobbsee> DaBonBon: and no one will bother fixing it without you filing decent bugs about it.
[04:24] <Hobbsee> DaBonBon: someone stole the psychic pony
[04:24] <DaBonBon> and i don't see why ubuntu can't use uswsusp by default ?
[04:24] <DaBonBon> mjg59: it works once in a while, but usually just resumes with screwed up xorg .. which leaves the machine unresponsive
[04:25] <cypherbios> mvo: I'm upgrading my system now and I've noticed that ubunfox (which is in main and is dependency of ubuntu-desktop) depends on apturl (which is currently in universe). Isn't it a problem?
[04:25] <mjg59> DaBonBon: Bug number?
[04:25] <DaBonBon> mjg59: you're repeating yourself .. really, now that you've told me, i'll diagnose a bit and file a bug
[04:25] <mvo> cypherbios: it needs to be prompted
[04:25] <mjg59> Thank you
[04:26] <mjg59> Oh, wow.
[04:26] <DaBonBon> mjg59: and when you say code paths that ubuntu uses, you really just mean cat disk > /sys/power/state" don't you ?
[04:26] <mjg59> This package seems to be very broken.
[04:26] <mjg59> DaBonBon: No, I meant suspend to ram.
[04:26] <DaBonBon> ok, cat mem > /sys/power/state then
[04:26] <mjg59> No, I meant the code in /etc/acpi
[04:26] <DaBonBon> oh, i see
[04:27] <DaBonBon> i do just that .. replace the cat > .. line by s2ram
[04:27] <mjg59> No, that's broken.
[04:28] <DaBonBon> oh well .. god knows when kernel suspend will improve .. i don't understand why they just don't merge suspend2 in .. anyway, i'll file a bug, mjg59
[04:28] <mjg59> s2ram *is* kernel suspend
[04:28] <Mithrandir> uswsusp seems kinda pointless for suspend to ram.
[04:29] <DaBonBon> mjg59: i meant the normal way of cat .. i'm sorry if i'm using the wrong terminology ..
[04:29] <DaBonBon> Mithrandir: why ?
[04:29] <mjg59> DaBonBon: It's *the same code*
[04:29] <DaBonBon> mjg59: then how come s2ram always works, and cat mem > never does ?
[04:29] <mjg59> DaBonBon: I don't know. When you've filed the bug report I might have some idea.
[04:29] <DaBonBon> well, i should file a bug
[04:29] <DaBonBon> mjg59: i've modified some files in /etc/acpi .. can you please tell me how do i revert them to original ?
[04:30] <Mithrandir> DaBonBon: what does it buy you in the s2ram case?  It's meaningful for hibernate because you can do stuff like add a progress bar or add support for aborting, but you can't really about a suspend as it takes a second or two.
[04:30] <DaBonBon> oh, never mind .. i had backups
[04:30] <DaBonBon> Mithrandir: oh i really don't care about bars and other bling bling .. it's just that it _works_
[04:31] <DaBonBon> ok, while we're at it, let me file the bug :)
[04:31] <DaBonBon> though i think it's too late for gutsy already ?
[04:32] <DaBonBon> please note i am using kubuntu .. though i wonder if it really makes any difference
[04:32] <DaBonBon> mjg59: what package shall i file it agains /
[04:32] <mjg59> If it works with s2ram but not the standard stuff, against acpi-support
[04:32] <DaBonBon> thank you
[04:32] <mjg59> Then try altering the settings in /etc/default/acpi-support
[04:33] <cjwatson> DaBonBon: as far as 'cat mem >' goes, you're not attempting to do 'sudo cat mem > /sys/power/state' are you?
[04:33] <mjg59> Also, s/cat/echo/
[04:33] <cjwatson> er yes
[04:33] <mjg59> cjwatson: No, it's done in the script
[04:33] <DaBonBon> cjwatson: no, i'm using the gui to suspend
[04:34] <DaBonBon> cjwatson: the kubuntu kde's gui
[04:35] <DaBonBon> mjg59: my bug is not at all different from https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/43708 .. shall i go ahead and comment in that one, or file a new one ?
[04:35] <ubotu> Launchpad bug 43708 in acpi-support "Resume from suspend and hibernate fail when X is running on Fujitsu amilo 7440" [Low,Confirmed] 
[04:36] <mjg59> If you've got a Fujitsu Amilo 7400, file it there
[04:36] <mjg59> Otherwise file it separately
[04:37] <DaBonBon> ok, mjg59 , i'll file it separately and follow both the debugging guides on the wiki
[04:37] <DaBonBon> pity i need to quit irc to try it out :-/
[04:37] <mjg59> Oh argh. This package is utterly broken.
[04:38] <DaBonBon> mjg59: which one ? uswsusp ?
[04:38] <mjg59> Yes
[04:38] <DaBonBon> oh well :-/
[04:46] <annodomini> If I have a feature request which I would like to submit and track, where is the right place to do that?
[04:46] <annodomini> Should I submit a Blueprint, or just file it as a bug against the appropriate component?
[04:47] <ogra> annodomini, i'd start with a whishlist bug
[04:48] <annodomini> ogra: thanks, will do
[04:48] <cjwatson> annodomini: blueprints should generally be written by developers after it's determined that the feature is complex enough to require one
[04:49] <cjwatson> we haven't been very clear about this in the past, and so there are an awful lot of inappropriate blueprints
[04:50] <DaBonBon> mjg59: https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/133677
[04:50] <ubotu> Launchpad bug 133677 in acpi-support "System unusable after resume from suspend or hibernate" [Undecided,New] 
[04:51] <annodomini> I'm pretty sure that this feature would be complex enough to require one (ability to edit partition labels from nautilus, for renaming removable media)
[04:51] <cjwatson> Setting up intercal (0.26-1) ...
[04:51] <cjwatson> Processing triggers for man-db ...
[04:51] <cjwatson> Updating database of manual pages ...
[04:51] <cjwatson> <cjwatson@cairhien ~/src/debian/man-db/trunk>$ whatis ick
[04:51] <cjwatson> ick (1)              - intercal compiler
[04:51] <cjwatson> iwj: ^--
[04:51] <cjwatson> annodomini: complex in this case often means interaction between multiple packages
[04:51] <cjwatson> annodomini: in any case, best left to the developer IMO
[04:52] <mjg59> DaBonBon: Try disabling SAVE_VBE_STATE
[04:53] <annodomini> cjwatson: sure thing, just wanted to check
[04:54] <annodomini> Another question is should I try and track down the bug systems for each upstream package, or just report them in the Ubuntu bug tracker and hope that if necessary they get pushed upstream?
[04:57] <cjwatson> we generally only ask for the latter, but the former is appreciated if you have skill and time
[04:57] <DaBonBon> mjg59: all the various bulleted points here which require output - https://wiki.ubuntu.com/DebuggingACPI - should i attach tem as different files
[04:57] <DaBonBon> or in a single file ?
[04:59] <mjg59> DaBonBon: No, just try what I've asked you to do please
[05:03] <DaBonBon> mjg59: ok
[05:04] <iwj> cjwatson: That looks good to me.  Do you agree ? :-)
[05:07] <DaBonBon> mjg59: SAVE_VBE_STATE=false
[05:07] <DaBonBon> rigjt ?
[05:07] <mjg59> Yup
[05:08] <DaBonBon> thanks, i'll brb
[05:08] <cjwatson> iwj: yep
[05:09] <cjwatson> iwj: (wasn't a complaint, rather a demonstration)
[05:12] <iwj> cjwatson: Ah, good :-).
[05:13] <iwj> Sorry, I'm wrestling with airline websites and everything looks like a problem ...
[05:16] <DaBonBon> mjg59: ping
[05:16] <DaBonBon> mjg59: that fix makes suspend work correctly
[05:16] <DaBonBon> but now hibernate doesn't work at all
[05:23] <mjg59> DaBonBon: Ok. Could you attach the output of sudo dmidecode to the bug, plese?
[05:30] <DaBonBon> mjg59: already attached
[05:31] <DaBonBon> shall i attach anything more ?
[05:33] <mjg59> DaBonBon: Nope, that should be good
[05:34] <DaBonBon> ok mjg59 , i just updated the bug .. thanks a lot
[05:35] <mjg59> No problem
[05:35] <DaBonBon> mjg59: and if i was a bit rude earlier with s2ram and others, i apologize .. i should've realized that i'm getting wonderful software for free :)
[05:35] <mjg59> That's ok
[05:35] <mjg59> The number of different ways to do this is confusing
[05:35] <ogra> its all about choice :P
[05:36] <mjg59> Well, I've just limited some of that choice :)
[05:36] <ogra> yay
[05:36] <DaBonBon> exactly, and to me as a guy who has no knowledge of kernel and related software, when s2ram works perfectly, i didn't realize that ubuntu uses the same code base
[05:45] <DaBonBon> mjg59: i'll be off .. thanks for the help .. please tell me if i can provide any more info
[05:45] <DaBonBon> solving this bug for gutsy would be amazing
[05:57] <cjwatson> Unable to open binary database %s: %s /usr/share/command-not-found/programs.d/all-multiverse.db (22, 'Invalid argument')
[05:57] <cjwatson> blink
[06:01] <nixternal> iwj: I am adding autoconf to the build-dep for kvkbd as that should fix your issue. I just ran the same commands you did on it and it built fine here...sorry for the inconvenience there
[06:08] <Riddell> carlos: is there anything that can be done about bug 106772, the translation team doesn't seem to be doing it
[06:08] <ubotu> Launchpad bug 106772 in amarok "Errors in Amarok's .po file cause issues with unparsed HTML" [Low,Confirmed]  https://launchpad.net/bugs/106772
[06:12] <iwj> nixternal: Ah, IC.  Right.
[06:14] <pitti> seb128: bug 132143 approved FYI
[06:14] <ubotu> Launchpad bug 132143 in gimp "GIMP in 64bit Feisty corrupts PSD files" [Medium,Confirmed]  https://launchpad.net/bugs/132143
[06:14] <seb128> pitti: thanks
[06:39] <beuno> hello, I'm working on the Tribe5 release page, does anyone know what has changed in Gnome from Tribe4 to Tribe5?   (or anything else you can think of)  D:
[06:40] <mdz> mvo: urgh, after running CCSM on my desktop it stopped working there as well
[06:43] <mdz> mvo: ah, it only works when I enable Rotate Cube
[06:45] <mvo> mdz: keybindings stopped working? and work only with rotate cube, but not wall?
[06:58] <Riddell> "sun-dlj-v1-1 license could not be presented" is there a way to work around that for a package which build-deps on sun-java6-jdk?
[07:05] <cjwatson> I thought the buildds were meant to have that preanswered
[07:05] <cjwatson> infinity: do I remember correctly?
[07:06] <Riddell> it's in ppa, so could be an issue only there
[07:08] <geser> Riddell: packages build-depending on the sun jvm have also this problem on the normal buildds
[07:10] <Riddell> I'd expect so, it's the same buildds after all
[07:10] <cjwatson> yeah, different chroots though so it was entirely possible
[07:14] <mdz> mvo: I had rotate cube on, and they were working.  I switched to wall, and it stopped working.  back to rotate cube, and they work again
[07:28] <carlos> Riddell: as an exception, please, file a bug report on bugs.launchpad.net/rosetta and any of us (Danilo, Jeroen or I) will fix it. Please, add concrete links to the messages you want fixed and with the new translation so we just need to do copy & paste
[07:28] <Riddell>  /win 20
[07:28] <Riddell> hmm
[07:28] <Riddell> carlos: ok, will do
[07:29] <carlos> Riddell: I guess you already contacted directly with the translation teams for those languages, right?
[07:31] <Riddell> carlos: the bug is assigned to them
[07:32] <carlos> ok
[07:32] <carlos> I didn't look at that field O:-)
[07:40] <glatzor> beuno: displayconfig-gtk is now part of the desktop seed
[08:00] <beuno> glatzor: added, thanks, https://wiki.ubuntu.com/GutsyGibbon/Tribe5
[08:02] <mvo> mdz: thanks, I have a look now
[08:05] <glatzor> beuno: perhaps it would be nice to use screenshots with the default ubuntu theme only
[08:07] <beuno> glatzor: unfortunately I'm not running Gutsy, so that's basically what I could get my hands on
[10:00] <highvoltage> !seen Burgandavia
[10:07] <bryce> ogra, btw, I wasn't able to find anything upstream referring to XF86VidModeClientNotLocal, but if you file a bug (with xorg.conf, Xorg.0.log, lspci -vvnn, and exact steps to reproduce), I can forward it upstream for you
[10:07] <geser> highvoltage: you mean Burgundavia? Last Seen: 1 week 2 days (11h 4m 47s) ago
[10:08] <highvoltage> geser: aah, thanks
[10:10] <ogra> bryce, well i fixed it in gnome-screensaver, fading (at least this way) is a very very bad idea anyway on thin clients
[10:11] <bryce> ah ok cool
[10:21] <Riddell> evand: ubiquity upload to come later today?
[10:21] <Riddell> calc: openoffice upload too?
[10:22] <evand> Riddell: indeed, quite shortly actually as I'm wrapping up some changes.
[10:23] <calc> Riddell: hopefully, i'm doing the last bit of testing and then have to update the changelog
[10:33] <Riddell> you guys rock
[10:35] <ogra> bryce, indeed that doesnt solve the X issue, i'll have a deeper look after tribe release into that
[10:36] <bryce> ok
[10:49] <silvertip257> I'm trying to follow the how-to for making a custom live cd.  rsync is having issues.  "some files could not be transferred (code 23) at main.c(977) [sender=2.6.9] "
[11:06] <mathiaz> kylem: is there any point to keep the apparmor-source-module package ?
[11:07] <mathiaz> kylem: it was used to compile the module by hand with modass.
[11:07] <kylem> no, not really. we can't support people loading things we don't distribute anyway.
[11:29] <mneptok> kylem: jury's still out on whether we support things we *do* distribute.
[11:30] <ajmitch> mneptok: up a brown creek?
[11:31] <mneptok> ajmitch: i like you, but only as a friend.
[11:32] <bhale> mneptok: whoa
[11:47] <evand> anyone want to sponsor an upload to main for me?
[11:56] <calc> grr this build is taking forever even with ccache
[12:00] <evand> if anyone is able to sponsor: http://people.ubuntu.com/~evand/upload/ubiquity_1.5.11_source.changes