[12:14] <pygi> hey mdz_ 
[12:16] <mdz_> hi
[12:36] <LordLimecat> is there a known bug whereby if ubuntu crashes, theres a chance syslog will have a line filled with "^@" on it, causing gnome-system-log to crash?
[12:37] <LordLimecat> its happened twice, and removing the offendign line (thru nano, since gedit is also unable to read the file) seems to fix the issue
[01:00] <LordLimecat> if its of any help, its writing 1745 or 1746 bytes worth of 0x0s to the following logs: /var/log/messages    /var/log/syslog     /var/log/kern.log
[01:07] <mdz> LordLimecat: I have never seen such behaviour; it could be caused by filesystem corruption
[01:07] <LordLimecat> yea, well, its possibly because upon returning to comp (both times) it wasnt responding, so i tried alt+sysrq+x, no response....
[01:07] <LordLimecat> so i did alt+sysrq+b
[01:07] <LordLimecat> .,....and rebooted
[01:08] <elmo> it's fairly common on a system crash, unless you use data=journal
[01:08] <elmo> and if you use xfs, it's basically a given
[01:08] <LordLimecat> but the exact same thing, same data written, same quantity
[01:08] <LordLimecat> 1745 bytes worth of 0s
[01:08] <LordLimecat> cant be random
[01:08] <LordLimecat> ...can it?
[01:08] <elmo> (it == the 0x0's in files that are open and being written to at time of crash)
[01:09] <LordLimecat> well, there was data written RIGHT before system went down, after the 0s--
[01:09] <LordLimecat> noting that a reboot was requested
[01:09] <mjg59> Which filesystem do you use?
[01:09] <LordLimecat> ext3
[01:09] <LordLimecat> i MAY have changed its writeback
[01:09] <LordLimecat> possibly
[01:09] <LordLimecat> how do i check quickly
[01:09] <mjg59> Eh. Data is certainly not guaranteed to be there if you don't reboot cleanly
[01:10] <mjg59> Before doing sysrq+b, do sysrq+s
[01:10] <LordLimecat> couldnt :( couldnt get to terminal
[01:10] <LordLimecat> oh, i generally do that
[01:10] <LordLimecat> ...but didnt this time
[01:10] <LordLimecat> is there a way to...like..bump it to init 1 with a system call?
[01:10] <kylem> the problem is likely that the oops output you see is being written
[01:11] <LordLimecat> so this isnt really a bug?
[01:11] <kylem> and since it's the same oops, will always be the same length...
[01:11] <kylem> it's a bug that gnome-system-log is crashing.
[01:11] <LordLimecat> lol, yea, it was a PITA to track it down
[01:11] <LordLimecat> luckily, gedit also refuses to open the files
[01:11] <LordLimecat> makes it easy to find
[01:12] <LordLimecat> ...is it a bad idea to make a script that finds and removes 1745 0s from those 3  logs?
[01:12] <LordLimecat> could that cause any damage?
[03:00] <thully> hi - I'm a MacBook user and wondered who I would get in contact with about getting some of the bugs relating to it fixed in Gutsy...
[03:01] <jml> thully: your best starting place is searching Launchpad's Ubuntu section for the specific bugs you've encountered.
[03:03] <thully> I've looked at the bugs, and responded, and heard nothing in months
[03:18] <thully> One bug is 92635 (MacBook doesn't sleep) - I've got a temporary kernel fix,  and it seems like something could be done for Gutsy
[03:23] <superm1> BenC, ping
[04:33] <thully> does anyone know how I can get in touch with the Ubuntu kernel/laptop team about getting the issues with macBooks - many of which I know the issue and have some ideas about solutions - fixed in Gutsy
[04:33] <thully> the bugs have all been reported long ago
[04:43] <mneptok> thully: LP is the mechanism by whcih such things are done
[04:43] <mneptok> *which
[04:49] <thully> I haven't managed to get any response via that channel...
[04:50] <mneptok> bug #?
[04:50] <persia> thully: If you have a solution, try attaching a patch against the ubuntu git repository to the bug, and adding the patch tag.
[04:51] <thully> well, the solution is kind of hackish at this point 
[04:52] <thully> 92635 is the bug # - me and some others have used the mentioned workaround patch to get suspend on first-generation MacBooks
[04:52] <thully> For some reason, 1g MacBooks are funky with their suspend...
[04:54] <thully> I also was going to comment on - but I can't find the bug # off hand, though it has been reported - the absolutely craptastic state of the appletouch driver
[04:55] <mneptok> that's not a bug, though
[04:55] <mneptok> that's a feature request
[04:55] <thully> it is a bug, as it is SO craptastic that you can't change the mouse pointer acceleration - something you can do even with dumb old usbhid
[04:57] <mneptok> upstream has acknowledged this as a bug?
[04:57] <thully> I haven't contacted upstream - all I know is that appletouch as shipped w/ Feisty doesn't let you change pointer acceleration
[04:58] <thully> right now, I'm actually running in VMware as I got sick of the issues - figure I may download gutsy and install on the bare metal tonight to check on these issues
[04:58] <mneptok> does it have the cntrols to do so, but just doesn't do it?
[04:59] <thully> yes - if you go into GNOME's mouse control panel - or Xorg.conf - and change the acceleration, nothing happens
[05:08] <mneptok> are you on the Macbook now?
[05:16] <thully> yes - I don't have a raw install right now, though, as I just got it back from repairs and it was wiped by Apple
[05:17] <thully> I could install Feisty now, or I could get a Gutsy ISO (would have to be later - am on satellite with strict bandwidth caps) and try that
[05:18] <thully> BTW, just reported the trackpad issue - 119964
[05:26] <mneptok> sudo rmmod appletouch && sudo modprobe appletouch
[05:27] <mneptok> that may clear up some Appletouch woes. try it next time you're in Ubuntu.
[05:28] <thully> I could try the Feisty live CD in a few minutes if that would help...
[05:29] <mneptok> up to you. i'm not a maintainer for any of that stuff. ;)
[05:30] <thully> OK
[05:30] <mneptok> just something to try.
[05:30] <mneptok> and if you narrow it to the kernel module, you're making progress.
[05:31] <thully> OK - I figure I can find out some from the Feisty live CD - I'll get the Gutsy one if it seems I may be able to learn more that way
[05:33] <johanbr> thully: It's possible you'll have more luck in #ubuntu-kernel .
[05:33] <thully> OK - wondered if there was a "kernel" channel...
[05:35] <thully> Also, on a (somewhat-unrelated) note, is VMware considered a supported configuration for running/testing Ubuntu in general?  I'm using it ATM because my hardware works better and I can switch OSes fast (still use OS X a lot - I like both OSes)
[05:36] <thully> obviously not for testing issues w/ MacBook hardware (like the aforementioned appletouch issues) but just in general
[05:41] <johanbr> thully: I don't know. My guess is that it would depend on the sort of bug you encounter. For higher-level bugs I'd think it'd be okay, but as you say not for kernel/hardware things.
[05:42] <thully> well, it does seem like kernel/hardware issues would be valid - though my hardware would basically be a VMware VM instead of the actual machine I'm running on
[05:45] <mneptok> thully: the kernel speaks to hardware. VMWare is not hardware.
[05:45] <mneptok> thully: an abstraction layer between the kernel and metal is nothing but a DIStraction layer when reporting bugs.
[05:46] <johanbr> Right. My guess would be that the kernel developers might just say "vmware is closed source, we have no way of knowing which bugs the virtualization introduces". If you really want to know, you should ask them, though.
[05:46] <mneptok> VMWare cannot keep accurate time. even with ntpd installed.
[05:47] <mneptok> let that inform your thinking about VMWare's relationship to hardware.
[05:47] <johanbr> If you really want to view vmware as hardware, it's not on the list of supported architectures, in any case.
[05:48] <mneptok> VMWare *is* hardware when it comes to its interactions with the kernel.
[05:48] <thully> I see, I knew that would come up.  
[05:48] <mneptok> (gross oversimplification, but the sentiment is valid)
[05:48] <thully> I wouldn't be filing many kernel bugs in any case - most of them I'd test would be bare metal bugs (like appletouch)
[05:49] <mneptok> thully: VMWare can't keep its clock straight. you want to report issues with input device timings?
[05:49] <mneptok> thully: Appletouch is hardware. the kernel talks to hardware. VMWare stands between the kernel and hardware ....
[05:50] <thully> appletouch isn't in vmware - those were two totally separate issues
[05:51] <thully> sorry for confusing everyone
[05:52] <thully> I just meant in general if I were to use VMware at some point and file bugs - not using vmware to test macbook hardware bugs
[05:52] <mneptok> eh, if everyone apologised every time i didn't understand coherent English, IRC would be nothing but "sorry, mnep"
[05:52] <mneptok> just be sure to mention VMWare's place in the recipe when appropriate. :)
[05:53] <thully> I realized that it was pretty much like its own hardware
[05:58] <thully> OK - thanks - figure I'll reboot onto bare metal Ubuntu and try some things with appletouch
[06:30] <desrt> http://mcmaster.facebook.com/group.php?gid=2207033242
[06:32] <thully> for those of you who were on when I was discussing my appletouch problem - I've discovered that an rmmod and modprobe of the module fixes the issue until X is restarted
[06:33] <thully> after X is restarted, you have to do it again if you want proper acceleration
[06:38] <fabbione> morning guys
[06:42] <pygi> morning fabbione 
[06:51] <fabbione> hi pygi 
[06:51] <fabbione> StevenK: you got mail
[06:51] <StevenK> fabbione: I'm not not so sure that tig and lyx are too blame.
[06:51] <fabbione> nope.. they are not
[06:51] <fabbione> you will have to ask sysadmin help here to see what's happening in the buildds
[06:52] <fabbione> and unfortunately i can't help you there
[06:52] <StevenK> I saw this problem a few days ago, with all buildds doing the same thing, spinning with no logs and not changing state. I'm suspecting a LP bug.
[06:53] <fabbione> oh well just ask for rescheduling
[06:53] <fabbione> it might have been the congestion thingy on LP
[06:53] <fabbione> anyway you know they build
[06:54] <StevenK> Okay, so bug $BUILDD_PERSON for a requeue of lyx and tig on sparc. That's fine.
[07:00] <Hobbsee> morning all!
[07:01] <desrt> word.
[07:02] <Hobbsee> hrm?
[07:03] <pygi> heya Hobbsee :)
[07:04] <Hobbsee> good luck with that.  walk? swim?
[07:05] <desrt> i wanted to take the train, but that's just ridiculous.
[07:05] <desrt> and i'll have some luggage.... so swimming is probably a bad idea.
[07:06] <Hobbsee> awww
[07:14] <Hobbsee> pygi: mpt is probably better to eat.
[07:14] <pygi> Hobbsee, but no!
[07:15] <Hobbsee> pygi: why no?
[07:15] <pygi> no idea, just because =)
[07:16] <pygi> your point? :P
[07:16] <Hobbsee> unless you're into bones, of course.
[07:16] <pygi> lol
[07:17] <pygi> I'll be back
[07:17] <pygi> math exam
[07:18] <Hobbsee> pygi: have fun.  make up lots of rubbish
[07:19] <mpt> Hobbsee, are you calling me fat?
[07:19] <Hobbsee> mpt: no, i'm calling you bigger than me.
[07:19] <Hobbsee> mpt: which, seeing as racarr was the only one smaller than me, isnt hard.
[07:19] <Hobbsee> (at UDS)
[07:19] <Hobbsee> there's a difference.
[07:25] <fabbione> on the node.. it's not difficult to be bigger than Hobbsee :)))
[07:25] <fabbione> the problem is if you are more thin than she is... you might consider a doctor appointment ;)
[07:26] <StevenK> Or a career as a supermodel.
[07:26] <Hobbsee> haha
[07:26] <Hobbsee> StevenK: i'm not pretty enough to do that :P
[07:27] <mpt> I wasn't at UDS, but I'm pretty small
[07:27] <fabbione> mpt: still slightly larger than Hobbsee :)
[07:28] <fabbione> mpt: i met both of you...
[07:28] <mpt> We shall find out for sure at the next UDS :-)
[07:28] <fabbione> mpt: you could probably handle my weight on you...
[07:28] <fabbione> she would crack :P
[07:28] <Hobbsee> mpt: not in boston
[07:28] <mpt> fabbione, not a chance
[07:28] <fabbione> ahha
[07:28] <Hobbsee> mpt: i'm thin enough that a person like seveas could easily break my wrist, if he tried hard enough
[07:28] <fabbione> mpt: i lost since last we met :)
[07:29] <mpt> Fatherhood is hard work?
[07:29] <fabbione> mpt: and another bunch of reasons
[07:29] <mpt> ah
[07:29] <fabbione> mpt: remember i haven't been feeling very well recently.. so that adds up
[08:40] <shawarma> I'm looking at the squid merge. Apart from the stuff that's mentioned in the last changelog, the patch that MoM has created also contains a bunch of translation releated stuff. Now, since the last patch (the one between our previous version and the debian version on which it's based) did not contain any of that stuff, I don't quite get where it came from? It may just be because I have absolutely no idea how all our translation stuff is handled.
[08:41] <Hobbsee> shawarma: i believe that launchpad automaticlaly updates the translations on build, or something.  it's thru launchpad, regardless.
[08:42] <shawarma> Hobbsee: But that does not interfere with source packages in any way, I suppose?
[08:42] <Hobbsee> i'm not sure
[08:42] <shawarma> I don't see how it could since they're signed and all that.
[08:42] <Burgundavia> shawarma: talk to pitti, he set up the language pack stuff
[08:43] <shawarma> Burgundavia: Right.
[08:45] <shawarma> Burgundavia: How's it going? New job yet?
[08:46] <Burgundavia> not yet
[08:46] <shawarma> Burgundavia: On purpose?
[08:46] <Burgundavia> sadly, not
[08:46] <Burgundavia> although quitting was very much "on purpose"
[08:47] <shawarma> Yes, my keen jedi senses told me that, too.
[08:54] <xipietotec_> are there any plans in ubuntu+x releases to use suspend2?
[08:54] <Hobbsee> xipietotec_: not unless it gets into the main kernel, iirc.
[08:54] <Hobbsee> check what the mailing lists say on it (ubuntu-devel, ubuntu-devel-discuss) - the archives are tehre
[08:55] <xipietotec_> ah, gotcha. duh, that makes sense. </me hopes it gets in...because I'm not really looking at running a patched kernel, pfft>
[09:02] <Burgundavia> xipietotec_: it is the kind of thing that needs to get upstream, unless it provided such amazing functionality as to require the huge delta
[09:03] <xipietotec_> Well, evidently it works *better* than normal hibernate
[09:04] <Burgundavia> given how much laptop support has been a priority for Ubuntu and the fact that it isn't in basically means it ain't comin' until upstream gets it
[09:06] <dholbach> good morning
[09:07] <Burgundavia> hey dholbach
[09:07] <dholbach> hiya Burgundavia
[09:18] <pygi> hey folks
[09:18] <Hobbsee> hiya pygi, how was maths?
[09:19] <pygi> Hobbsee, easy, but I won't pass sadly
[09:19] <pygi> I blame my complete of interest in the subject
[09:19] <pygi> Hobbsee, want to upload a debdiff so I don't have to bug mvo when he's around? ;)
[09:19] <Hobbsee> awww.  it's useful to pass
[09:19] <pygi> it is ofcourse completely acceptable and working :)
[09:19] <Hobbsee> and a debdiff for what?
[09:20] <pygi> no kidding :P
[09:20] <pygi> brasero package
[09:20] <Hobbsee> oh ick.
[09:21] <pygi> Hobbsee, then go ^_^
[09:21] <pygi> and pass things, unlike me :)
[09:23] <dholbach> hey mvo
[09:23] <mvo> hey dholbach
[09:23] <Hobbsee> hiya mvo 
[09:24] <Hobbsee> ooh, if mvo is here, i can ask him about my plans for dput.
[09:24] <StevenK> You have plans for dput?
[09:24] <mvo> hey Hobbsee!
[09:24] <Hobbsee> StevenK: i know, i saw :)
[09:25] <Hobbsee> mvo: it seems that no ubuntu system, including upload.ubuntu.com and revu, allow you to use dcut
[09:25] <pygi> dput*
[09:25] <Hobbsee> mvo: so siretart and myself are thinking of putting in a message saying that "this does not apply to ubuntu systems" or something
[09:26] <StevenK> That's do-able.
[09:26] <Hobbsee> that's what i thought
[09:26] <Hobbsee> some o fit's in bzr too, not the latest version though.  no idea why.
[09:35] <shawarma> Hobbsee: No ubuntu system allows you to use dput? Um... WhaT?
[09:35] <StevenK> shawarma: Not dput, *dcut*
[09:36] <Hobbsee> shawarma: dcut.
[09:36] <Hobbsee> oh yes, i did.
[09:36] <shawarma> StevenK: Ah, I just saw the "dput*" thing, and didn't notice it wasnt' Hobbsee saying it. :)
[09:36] <Hobbsee> hehe
[09:36] <Hobbsee> shawarma: i'm not *usually* an idiot.
[09:36] <pygi> Hobbsee, what did I do this time?!?!
[09:36] <Hobbsee> shawarma: so i wont usually say stupid stuff like that
[09:37] <shawarma> Hobbsee: I *was* kind of puzzled.
[09:37] <pygi> oh!
[09:37] <pygi> Hobbsee, nop, your fault
[09:38] <Hobbsee> shawarma: then again, i did ask "is a package still in the new queue" without just looking it up.
[09:38] <shawarma> Hobbsee: That's not stupid. That's just lazy, which is entirely different and entirely alright.
[09:39] <Hobbsee> shawarma: what's stupid about it is that i didnt even think of it.
[09:39] <Hobbsee> getting the rejected mail was a red herring, so confused me :P
[09:40] <Hobbsee> (and the powers that be say "we gave her core because...?")
[09:40] <shawarma> :)
[09:45] <pygi> hey giskard :0
[09:45] <giskard> hello pygi  :)
[09:46] <pygi> giskard, how is it going?
[09:47] <giskard> bad, in 10 days i have my final school exam
[09:48] <pygi> meh, I just had math exam
[09:48] <pygi> was bad :p
[09:54] <Keybuk> I am absolutely delighted with my discovery that there is such a thing as the "International Standard Atmosphere"
[09:55] <Hobbsee> the what?
[09:55] <cjwatson> shawarma: merge-o-matic does some translation merging with specialised tools, which is nice if you actually changed the translations but an interference if you didn't; if those diffs are pointless, ditch them
[09:55] <Hobbsee> haha, cool
[09:56] <seb128> hey Keybuk
[09:56] <cjwatson> mneptok: we use VMware fairly extensively internally for testing, so on a practical level it's a good idea for us to accept at least some number of bugs about it
[09:56] <shawarma> cjwatson: Cool. Thanks.
[09:56] <seb128> Keybuk: so you gave compiz to mvo? ;)
[09:56] <Keybuk> heh, was just /msg'ing you about that :p
[09:56] <Keybuk> Hobbsee: it's to do with how plane altimeters work
[09:56] <Hobbsee> yeah, i wikipedia'd.
[09:57] <Hobbsee> eventually
[09:57] <cjwatson> Hobbsee: in an ideal world, a reject would always be accompanied by a mail
[09:57] <cjwatson> an explanatory one rather than the LP standard "kthxbye" one
[09:58] <Hobbsee> cjwatson: indeed.
[09:58] <Hobbsee> cjwatson: but it makes enough sense, as is.  unless you screw it up originally
[09:58] <cjwatson> Hobbsee: unfortunately, there's a long-standing bug in soyuz noting that the reject interface doesn't let us give a reason, so it relies on the rejecting archive admin remembering to fish out all the e-mail addresses and send mails by hand
[09:58] <cjwatson> which, in the case of bulk things like de-duplication, is less likely
[09:58] <Hobbsee> cjwatson: ahhh, okay.  fair enough
[10:08] <tepsipakki> keyutils is in universe, is that why krb5 doesn't build?
[10:09] <Hobbsee> tepsipakki: yes
[10:09] <tepsipakki> Hobbsee: okay, I'll file a MIR
[10:29] <siretart> Hobbsee: I'd have no problems with removing that message completely
[10:29] <siretart> Hobbsee: because the set of people who would be using an ubuntu dput to upload to debian normally would know about dcut, I think
[10:30] <siretart> Hobbsee: but changing it is fine to me as well
[10:30] <Hobbsee> right....that's a point
[10:30] <Hobbsee> siretart: um, about REVU - what's the "official" way to get something out of the rejected queue?
[10:30] <Hobbsee> i've just been moving the changes file up a directory, but i've got no idea what's supposed to happen
[10:30] <dholbach> Keybuk: "Ow! You broke my nose!" - very funny :)
[10:30] <crimsun> I'll reprocess it
[10:31] <Hobbsee> siretart: seems to work, at least some of the time.
[10:32] <siretart> Hobbsee: the script who processes the incoming directory is /srv/revu1-production/scripts/process_uploads.sh. it is run from revu1's crontab every 5 minutes
[10:32] <Hobbsee> siretart: right
[10:33] <Keybuk> dholbach: I wasn't going to even start on the fact that using 1024 multiples for disk or storage devices is wrong anyway, and disks are measured in thousands, millions & billions of bytes
[10:33] <Hobbsee> siretart: persia probably wants/needs access to resync the keyring, etc, too - he's diong a lot of reviewing.
[10:33] <Hobbsee> siretart: i dont think you and him have actually been around at the same time, though
[10:34] <dholbach> Keybuk: seems like a good move as the topic is quite suitable for flame wars
[10:34] <Keybuk> it's cold today <g>
[10:35] <dholbach> right
[10:35] <dholbach> Keybuk: my dog love you for that, if it was true
[10:35] <cjwatson> Keybuk: you'd get on well with the partman author
[10:36] <Keybuk> cjwatson: heh
[10:36] <cjwatson> there's a special note in the ubiquity partman frontend that has to say "this is measured in 1000000, not 1048576" or words to that effect
[10:36] <Keybuk> it's true, disk manufactures do actually use 1000 byte multiple, not 1024
[10:36] <cjwatson> indeed
[10:36] <cjwatson> except sometimes they use a mix
[10:37] <cjwatson> 1024000 and that sort of thing
[10:37] <Keybuk> heh, yeah, sometimes they like to use thousands and millions of 1024 bytes
[10:37] <Keybuk> personally I think that kilo, mega, giga are the only way forward
[10:37] <Hobbsee> Keybuk: and rid the world of crappy imperial measurements, and timezones, while you're at it, please.
[10:37] <Keybuk> because they by saying "this drive has a capacity of 100GB (100 billion bytes)", you're guaranteeing the minimum number of bytes it is likely to have :p
[10:38] <Keybuk> trying to be more specific is just guess-work
[10:39] <hunger> Keybuk: KB is defined as 1000Byte (MB as 1000KB, and so forth).
[10:39] <hunger> Keybuk: No guesswork required.
[10:39] <hunger> Keybuk: 1024Bytes are a KiB.
[10:40] <cjwatson> that's a retcon though
[10:41] <hunger> There actually is a international standard about that stuff...
[10:41] <cjwatson> it is unarguably not what KB has always meant, and thus guesswork is required.
[10:41] <Keybuk> hunger: there's an international standard cup of tea, that doesn't mean you can't drink coffee
[10:41] <hunger> Keybuk: Of course not. But then you as the distribution guys need to fix it;-)
[10:42] <Keybuk> yeah, I think we should put this to the technical board ...
[10:42] <Keybuk> I vote for "use KB and MB and GB everywhere, and eradicate all uses of KiB, MiB and GiB because they cause confusion"
[10:42] <mpt> because we have nothing better to do?
[10:42] <hunger> Keybuk: Yes, rage against the standards!
[10:43] <Keybuk> hunger: stupid standards, yes
[10:43] <Keybuk> just because someone wrote a "standard", doesn't mean it's right
[10:43] <hunger> Keybuk: Well, it tries to end the confusion you complained about. Just sticking to "we always did it that way" will not do it.
[10:44] <Keybuk> especially when the person wrote a standard didn't reference the current practice
[10:44] <cjwatson> the "KiB" standard has caused more confusion than the prior practice did
[10:44] <Keybuk> that's like "I have a better idea how to do this, if I write a standard, then people will obey me!  muahahaha!"
[10:44] <Keybuk> a bit like the IRC standard, actually

[10:45] <hunger> Well, do whatever you want. You'll do so anyway;-)
[10:45] <Keybuk> hunger: in general, I've found that places that refer to things as KiB are using the wrong unit anyway
[10:45] <Keybuk> worst offenders using it to refer to disk space, or bandwidth, etc.
[10:46] <hunger> Keybuk: I have not made that experience yet.
[10:46] <Keybuk> the primary advantage to KB is that, in the worst case, it slightly under-estimates
[10:46] <Keybuk> hunger: the main place I see it is in ifconfig
[10:46] <hunger> Keybuk: Diskspace is traditionally in MB/GB... which started the whole mess.
[10:46] <Keybuk> to measure bandwidth
[10:46] <Keybuk> which is so utterly bogus, it's funny
[10:46] <Keybuk> bandwidth should be measured in thousands, millions, etc. of bytes
[10:47] <Burgundavia> what shocks me is just how much effort people have put into this whole thing
[10:47] <Burgundavia> there are huge threads on both ubuntu and debian-devel
[10:47] <hunger> Keybuk: Why is it bogus? If it is the proper unit for the thing they measure it is fine.
[10:47] <Keybuk> hunger: that's the point, it isn;t
[10:47] <seb128> Burgundavia: "huge"? you don't read debian-devel often, do you? ;)
[10:47] <Burgundavia> seb128: right, moderately large :)
[10:47] <Burgundavia> huge would be an Ubuntu flamewar
[10:48] <Burgundavia> anti-ubuntu, that is
[10:48] <hunger> Keybuk: Yes. I don't care how it is measured, as long as the proper unit of measurement is given.
[10:48] <Keybuk> hunger: and in this case, the wrong unit of measurement is given
[10:48] <Keybuk> hunger: which is the case with every instance of Ki I've ever seen
[10:49] <hunger> Keybuk: So far I had no trouble with that. All Ki I noticed so far (and that does *not* include ifconfig;-) seemed to be properly 1024 based.
[10:49] <Keybuk> hunger: inappropriately 1024 basde
[10:49] <Keybuk> hunger: ie. using multiples of 1024 for things that should be multiples of 1000
[10:50] <hunger> Keybuk: This discussion is a bit like using inches or centimeters.
[10:50] <Keybuk> exactly ;)  let's standardise on centimetres!
[10:50] <Keybuk> (and spell it right :p)
[10:51] <hunger> Keybuk: As long as the proper unit is attached I do not really care. I just don't like the KiB on 1000 based values (never encountered those) or KB being based on 1024 (happens a lot).
[10:51] <Keybuk> it shouldn't be KiB anyway
[10:51] <Keybuk> it should by kiB
[10:52] <hunger> Keybuk: right.
[10:52] <Keybuk> we could solve this with Unicode!
[10:52] <Keybuk> B!
[10:53] <hunger> Actually I usually do not even care wether 1000 or 1024 is the base... as long as enough free space is available to store my stuff;-)
[10:53] <Keybuk> hunger: right, in which case you should always use 1000 as the base, because then in the worst case you have more space than quoted
[10:53] <Keybuk> using 1024 or 1024000 means you could have less space than quoted
[10:53] <Keybuk> :p
[10:54] <xipietotec_> !seveas
[10:54] <xipietotec_> oops
[10:54] <ubotu> Seveas has a popular 3rd party repository for several packages. More info (and mirrors) on http://wiki.ubuntu.com/SeveasPackages
[10:55] <hunger> Only ignorant US citizens speak up against unicode;-)
[10:56] <shawarma> hunger: You'd be surprised..
[10:56] <Keybuk> I never said anything bad about Univode
[10:56] <Keybuk> uh, code
[10:56] <shawarma> hunger: I know a handful of {free,open}bsd people who absolutely refuse to use anything but iso-8859-*
[10:57] <Keybuk> shawarma: well, they use BSD, they're already swimming against the tides of inevitability ;)
[10:57] <hunger> shawarma: ignarant bastards... "I do not need more than 256letters, why should anybody else?"
[10:58] <cjwatson> easy
[11:00] <shawarma> hunger: It's a *very* frustrating discussion. I've had it with them many times now. Their argument always goes something like "Whaaaa! I once saw one of my 's that didn't look right because someone used utf-8.. Whaaa!"
[11:00] <hunger> shawarma: I can imagine:-(
[11:02] <tepsipakki> then there are applications that don't work with utf.. like Tectia ssh-client for windows
[11:03] <tepsipakki> which is maybe the biggest obstacle for utf adoption here
[11:04] <mjr> There's putty...
[11:05] <tepsipakki> mjr: true, it works
[11:05] <pitti> Good morning
[11:05] <Hobbsee> copy/pasting is just weird in it, though
[11:05] <Hobbsee> hiya pitti!
[11:05] <hunger> tepsipakki: Yes, let's head back to stoneage... at least everything worked back then.
[11:05] <tepsipakki> now, it has to be decided do we change tectia to putty&winscp and modify all the documentation there is
[11:05] <cjwatson> copy/pasting in putty is X normal
[11:06] <tepsipakki> hunger: rather, stay there :)
[11:06] <cjwatson> there's a configuration option to switch it to a more Windows-ish behaviour if you prefer that
[11:06] <Hobbsee> cjwatson: ahhh.  i must find that.  actually, i tihnk i did, one day
[11:06] <tepsipakki> cjwatson: yep
[11:06] <fabbione> mvo: ping?
[11:07] <tepsipakki> tectia will be fixed early next year, but it's too late if we are to adopt nfsv4
[11:07] <tepsipakki> anyway, offtopic :)
[11:08] <tepsipakki> mvo: I just confirmed the app-install-data install failure bug
[11:08] <mvo> hello fabbione
[11:08] <mvo> tepsipakki: what bugnumber?
[11:08] <fabbione> mvo: hey dude..
[11:08] <fabbione> mvo: Accepted redhat-cluster-suite 2.20070503-0ubuntu3 (source)
[11:08] <fabbione> mvo:    * Kill libccs-dev binary package. Nothing B-D on it anymore and it will be
[11:08] <fabbione>      killed upstream too at somepoint.
[11:08] <tepsipakki> mvo: a sec, didn't subscribe to it :P
[11:08] <fabbione> mvo: have fun :)
[11:09] <fabbione> mvo: just give it time to build and you should be good
[11:09] <tepsipakki> mvo: bug 118740
[11:09] <ubotu> Launchpad bug 118740 in app-install-data-ubuntu "app-install-data :  Can't import AppInstall.CoreMenu, aborting" [Medium,Confirmed]  https://launchpad.net/bugs/118740
[11:09] <mvo> fabbione: cool! my upstream change the name for libccs as well :) 
[11:09] <fabbione> mvo: perfect...
[11:10] <mvo> tepsipakki: you get a postinst failure ?
[11:10] <mvo> tepsipakki: can you please put the exact error output from dpkg into the bugreport
[11:11] <tepsipakki> mvo: that's all I see (netboot)
[11:11] <tepsipakki> the same message, that is
[11:12] <tepsipakki> mvo: um, actually the package apparently installs fine, but pkgsel fails
[11:14] <mvo> tepsipakki: so this happens when you try to install a fresh gutsy? ok, I will try to reproduce
[11:14] <cjwatson> why would pkgsel be involved in an upgrade?
[11:14] <tepsipakki> cjwatson: this was a fresh install
[11:14] <cjwatson> you said "During the upgrade process" in the bug report
[11:14] <tepsipakki> but the original reporter had an upgrade
[11:14] <cjwatson> ok, sounds like your problem is different then
[11:14] <cjwatson> can you put the syslog somewhere I can see it?
[11:15] <tepsipakki> cjwatson: yes, a sec
[11:17] <tepsipakki> ah, found it
[11:17] <tepsipakki> a traceback from app-install-data
[11:18] <tepsipakki> but the syslog is here: http://users.tkk.fi/~tjaalton/dpkg/syslog
[11:18] <cjwatson> app-install-data probably needs to Depends: gnome-app-install if it uses python modules from there
[11:18] <tepsipakki> yep, "No module named xdg.DesktopEntry"
[11:18] <cjwatson> which of course means a circular dependency so that's tricky
[11:41] <mvo> tepsipakki: I wonder how that triggers a failure to install, the postinst should run fine and g-a-i works even when the data is not cached, this is really just a optimization
[11:44] <cjwatson> tepsipakki: http://users.tkk.fi/~tjaalton/dpkg/syslog is 403
[11:45] <tepsipakki> uh
[11:46] <tepsipakki> try now
[11:46] <cjwatson> ok
[11:47] <cjwatson> ok, definitely mvo's problem :)
[11:47] <cjwatson> mvo: there's no try/except around import xdg.DesktopEntry
[11:48] <pitti> heno: https://wiki.ubuntu.com/UbuntuBugDay/20070613 says that the lists were generated by bughelper; are we supposed to add some bite-sized bugs there manually or will that be clobbered?
[11:48] <cjwatson> if you just want to ignore all errors from update-app-install, maybe just put || true after it in the postinst?
[11:49] <heno> pitti: if they are generated by bughelper I'm sure they are still manually pasted in, so I don't think anything will be clobbered
[11:50] <heno> pitti: yo might want to use a separate heading or something
[11:50] <heno> I'll coordinate more with Brian when he wakes up
[11:51] <Hobbsee> pitti: did you have plans to give some love to https://bugs.launchpad.net/ubuntu/+source/ia32-libs/ ? it's broken in various areas, including updates, and you appear to be the last uploader
[11:51] <pitti> Hobbsee: oh, right; siretart wanted to send me his patch
[11:51] <siretart> pitti: oh, I didn't? damn
[11:52] <mvo> cjwatson: indeed, that one if for me 
[11:52] <siretart> pitti: but I can explain it it you, might be more easy than the patch itself: I moved the commented out packages in the list and added the packages from ia32-libs-sdl
[11:53] <Hobbsee> pitti: siretart ditto https://bugs.launchpad.net/ubuntu/+source/ia32-libs-gtk
[11:53] <Hobbsee> (more file conflicts)
[11:53] <Hobbsee> it's been left unfixed for a month or so - presumably us mere mortals dont know how this stuff is supposed to work. 
[11:53] <siretart> yes, we should merge them all in one package
[11:55] <Hobbsee> siretart: that'd be cool.  various stuff is failing to build due to this lot, etc.
[11:56] <Hobbsee> so fixing is good, if youv'e got the wish & required skills
[11:57] <pitti> Hobbsee: 'k, I have them open in ffox tabs now (my short-term todo list)
[11:57] <Hobbsee> pitti: woo :)
[11:59] <pitti> heno: btw, the third column on the hug day wiki page says 'hugger', but is supposed to be used by the one working on the bug; shoulnd't that be 'huggee' then? :)
[12:00] <pitti> I wonder what would happen if I marked an ia32-libs bug (324 MB orig.tar.gz) as 'bitesize'
[12:00] <Hobbsee> hahahhaa
[12:00] <Hobbsee> you'd get shot.
[12:00] <Hobbsee> pitti: the original tarball isnt seriously that big, is it?
[12:00] <Keybuk> wasabi, iwj: so today I learned that fsync() doesn't actually have to sync ...
[12:01] <Keybuk> int fsync (int fd) { return 0; } is a valid implementation according to POSIX
[12:01] <pitti> Hobbsee: sure it is
[12:04] <heno> pitti: yes, probably. sounds a bit like a brand of underwear though :)
[12:04] <Hobbsee> pitti: twitch.
[12:04] <pitti> -rw-r--r-- 1 pitti warthogs 324361425 2007-05-22 17:05 ia32-libs_1.19ubuntu1.tar.gz
[12:04] <pitti> Hobbsee: after all, it's much like a complete debootstrap including sources
[12:04] <pitti> and tons of desktop libs, too
[12:05] <Hobbsee> pitti: true that
[12:05] <ogra> pitti, ltsp seems to be done o sparc as well now :)
[12:05] <ogra> *on
[12:05] <pitti> ogra: ah, cool
[12:05] <pitti> ogra: NEWed (assuming that you'll clean up the lintian bits somewhat)
[12:05] <ogra> willdo ...
[12:05] <ogra> btw, the debconf template is for a question asked in the preinst on debian it seems 
[12:05] <ogra> i'll ping them to fix it
[12:16] <glatzor> mvo: bryyce: hello, I just pushed some unittests for displayconfig
[12:16] <mvo> glatzor: cool, that is great news!
[12:27] <iwj> Keybuk: fsync> Nice.
[12:35] <pygi> Zdra, wake up ^_^
[12:37] <siretart> pygi: do you manage your changes to libisofs and libburn in a bzr branch?
[12:38] <pygi> siretart, nop, but I could if I'd register ssh keys with LP :)
[12:38] <pygi> (I know you're interested in bzr-builddeb, yes)
[12:42] <pygi> I could commit changes if we really have to keep that bzr branch
[12:42] <siretart> oh, I'm rather curious, if you are not comfortable with it, I'd be interested in knowing why
[12:42] <siretart> for all fans of patch systems, please have a look at http://wiki.tauware.de/misc:vcs-packaging2
[12:42] <siretart> pitti: I've seen that ecryptfs is in source NEW for quite some time now. Do you happen to know if there's a problem with the package?
[12:42] <pitti> siretart: no, there's just a lack of people doing source NEW :/
[12:42] <siretart> ah
[12:42] <pygi> siretart, it's not that I'm not comfortable, it's just the time it would take me for it to become routine task would better be spent fixing other things :)
[12:43] <pitti> siretart: tomorrow it's seb128's day, friday is mine; I'll coordinate with Seb to get to it eventually
[12:43] <siretart> pygi: oh, sure
[12:43] <pygi> siretart, mvo has one debdiff for me to upload, and then brasero will be in pretty good shape
[12:43] <pygi> need to find a fix for ppc & sparc build fail, but that's low priority right now
[12:43] <siretart> pitti: its just because it is a package of xxxxx1, which I'm mentoring. he was asking me yesterday about it
[12:43] <mjg59> Keybuk: ?
[12:44] <mjg59> Keybuk: "The fsync() function shall request that all data for the open file descriptor named by fildes is to be transferred to the storage device associated with the file described by fildes. The nature of the transfer is implementation-defined. The fsync() function shall not return until the system has completed that action or until an error is detected."
[12:44] <cjwatson> mjg59: read the rationale too
[12:44] <cjwatson> "If _POSIX_SYNCHRONIZED_IO is not defined, the wording relies heavily on the conformance document to tell the user what can be expected from the system. It is explicitly intended that a null implementation is permitted."
[12:44] <cjwatson> (I don't know whether we define _POSIX_SYNCHRONIZED_IO)
[12:44] <pygi> siretart, did you manage to think up of a sane solution for cdrecord/wodim/cdrskin whatever mess?
[12:45] <pygi> I mean how will we solve it
[12:45] <pygi> (update-alternatives, or just link wodim/cdrecord against cdrskin (the solution which I prefer))
[12:45] <mjg59> cjwatson: That seems to effectively state that the null implementation would only be valid in the case where there's no way to guarantee persistant storage anyway
[12:46] <mjg59> (Or where write() is synchronous)
[12:46] <cjwatson> "file system is on a network" is a not-wholly-unreasonable case where that is true
[12:47] <cjwatson> and where locking is interesting
[12:48] <Keybuk> mjg59: Mac OS X is the interesting case here; it's fsync doesn't
[12:50] <mjg59> cjwatson: Well, _POSIX_SYNCHRONIZED_IO is defined on Linux, so it's not an issue for us
[12:50] <mjg59> So (assuming we conform...) it can't be an issue for any of the network filesystems supported on Linux :)
[12:52] <mjg59> Keybuk: It looks like MacOS fsync() transfers it to the storage device, but doesn't ensure that it's hit the platters
[01:23] <ogra> pitti, are you sure you NEWed the ltsp stuff ? there is still no trace ... 
[01:24] <pitti> ogra: yes, but I NEWed it at 12:04, so it missed the 12:03 cron.daily by one minute
[01:24] <pitti> ogra: it should be published right now (check in about 10 minutes)
[01:24] <ogra> ah, k 
[01:24] <ogra> i thought they run in 30min frequency
[01:24] <pitti> no, it's still too slow for that
[01:24] <ogra> sorry for being pushy
[01:25] <pitti> np
[01:29] <Hobbsee> mvo: got any qualms about me fixing some of the bugs in ubuntu-restricted-manager?  
[01:30] <pitti> Hobbsee: you mean restricted-manager? or ubuntu-restricted-extras?
[01:30] <Hobbsee> sorry, extras
[01:30] <pitti> Hobbsee: I would have been glad about r-m bug fixes from you :)
[01:31] <Hobbsee> pitti: haha, good luck with that
[01:31] <Hobbsee> pitti: but there's talk of a kubuntu version
[01:31] <pitti> yes, I discussed it with Riddell on UDS
[01:31] <pitti> AFAIR there's a SoC project?
[01:32] <Riddell> pitti: yes
[01:32] <Riddell> if he gets gdebi done in time
[01:39] <Keybuk> siretart: that's cool
[01:39] <Keybuk> someone should write a plugin to do that for bzr ;)
[01:39] <Keybuk> lifeless: ^ :p
[01:42] <Hobbsee> pitti: wow.  i underestimated the amount of gstreamer0.10 plugins there were here.
[01:43] <pygi> :)
[01:43] <Hobbsee> oh impressive.  and adding all of -bad* and -ugly* still wouldnt catch them all
[01:44] <pygi> :)
[01:48] <pitti> siretart: re ia32-libs-gtk merge> so everything else except for the fetch-and-build list can be dropped? like the file shuffling in debian/rules?
[01:49] <pitti> siretart: or the separation of -dev bits
[02:09] <pitti> siretart: oh, hmm, -gtk is still in Debian
[02:10] <racarr> mvo__: Ping
[02:27] <mvo__> racarr: hello! 
[02:38] <Hobbsee> mvo: ping
[02:38] <racarr> mvo: Did you see what I posted on the compiz bug you asked about yesterday?
[02:38] <racarr> Nevermind, just saw your PM
[02:39] <mvo> racarr: yes, thanks again for the help!
[02:39] <mvo> hello Hobbsee
[02:40] <Hobbsee> mvo: i warn you now, i'm doing nasty things to a package of yours.
[02:40] <mvo> Hobbsee: you did already, no? I just got a changes mail
[02:40] <Hobbsee> mvo: okay, *more* nasty things than that :)
[02:41] <Hobbsee> mvo: "so, uh, why would we be distribuitng a separate kubuntu-restricted-extras source for this, when it's almost hte same?"
[02:42] <mvo> Hobbsee: hm, kubuntu-r-e would need the xine extra codecs?
[02:43] <Hobbsee> mvo: yes
[02:43] <Hobbsee> mvo: it's got them
[02:43] <Hobbsee> that package got renamed, etc.
[02:43] <pitti> mvo: (note that Hobbsee questions the existence of a separate *source*; separate binaries are fine and necessary)
[02:44] <mvo> pitti: aha, thanks. I was confused for a moment
[02:44] <Hobbsee> :)
[02:44] <pitti> Hobbsee: so, tell me if/when I should kill the source again; I won't NEW the binaries for nwo
[02:44] <mvo> I had no idea there was a seperate kubuntu-r-e package so unifring them into the same source sounds like a good plan
[02:44] <pitti> now, too
[02:44] <Hobbsee> pitti: please go ahead and kill the source.
[02:45] <Hobbsee> pitti: i'm getting help with some bash-foo, and then i'll upload
[02:45] <Hobbsee> of k-r-e
[02:45] <Hobbsee> mvo: there wasnt, until a copule of days ago
[02:45] <pitti> Hobbsee: *flush*
[02:46] <pitti> Hobbsee: I wonder whether this was the shortest lifetime of a source package *ever*
[02:46] <Hobbsee> haha, sorry
[02:47] <mvo> pitti: I can think of one ..
[02:48] <wasabi> Keybuk: Makes me wonder what the real chances of having transations in our file systmes in the next few years are.
[02:48] <pitti> mvo: which?
[02:50] <Hobbsee> pitti: at least it was small, and didnt require you to check licencing :P
[02:51] <mvo> pitti: ccs-settings, hasen't seen the light of the archive at all
[02:52] <pitti> mvo: it's in NEW; I thought you wanted to disambiguate the name?
[02:53] <seb128> pitti: I'm rejecting it
[02:53] <pitti> mvo: oh, I mean 'in the archive'
[02:53] <pitti> mvo: now the '<mvo> pitti: I can think of one ..' becomes clear; I thought you refered to reasons to keep k-r-e as separate source :)
[02:54] <mvo> pitti: sorry, misunderstanding
[03:01] <heno> how well do we support USB microphones generally?
[03:01] <heno> (they tend to be better for voice recognition use)
[03:03] <Treenaks> heno: USB soundcards tend to work OK
[03:04] <Treenaks> (and most USB headsets are USB soundcards)
[03:04] <Treenaks> (at least, the ones I've seen)
[03:04] <heno> Treenaks: great, thanks!
[03:04] <pitti> heno: not sure in general, but my logitech USB headset "just works"
[03:05] <Treenaks> pitti: USB Audio is a "standard" profile, lots of devices support it (unlike, say, video/webcams, where every device has its own vendor-specific interface)
[03:05] <broonie> There's a well-defined and generally well implemented generic USB audio class.
[03:05] <heno> pitti: ok, as long as we have a few types we can recommend we are in good shape
[03:06] <Treenaks> we use them for VoIP stuff here at work
[03:06] <Treenaks> the Logitechs
[03:11] <pitti> siretart: ok, I have the package merged; I want to sort out the gnutls13 FTBFS first, otherwise we cannot update to gutsy debs
[03:11] <indraveni> hi al
[03:11] <indraveni> hi all
[03:11] <indraveni> could someone please let me know, where is the coding or designing of ubutnu shutdown/logout image is present
[03:18] <indraveni> is it i gnome-human-themes
[03:19] <cjwatson> indraveni: usplash-theme-ubuntu
[03:19] <cjwatson> shutdown != logout, BTW; those are two separate themes
[03:20] <siretart> pitti: great! ok
[03:20] <indraveni> cjwatson, the image which is appeared when we click on system -> Quit
[03:20] <indraveni> cjwatson, is that the one done in usplash-theme-ubuntu?
[03:22] <indraveni> cjwatson, I want to know, where the gui part of the image which is appeared when we click on System -> quit
[03:23] <pitti> doko: can I remind you about the zope3 merge? it's still assigned to me, but we traded it
[03:24] <cjwatson> indraveni: oh, ok, no, I think that's in gnome-session
[03:24] <indraveni> cjwatson, oh
[03:29] <indraveni> cjwatson, is the desining of the image is done in C language?
[03:32] <indraveni> cjwatson, what does this uue file mean?
[03:41] <cjwatson> indraveni: language> no idea
[03:41] <cjwatson> indraveni: uue sounds like something that's been run through uuencode; you can use uudecode to reverse that
[03:42] <seb128> indraveni: what image?
[03:42] <seb128> there is no image when you click there, it's a dialog with button and fading around it
[03:43] <indraveni> seb128, yes a dialog window which has, shutdown, logout, hibernate and other options with respective icons in it
[03:43] <seb128> that's an application dialog, not a image
[03:43] <Hobbsee> pitti: yay, uploaded :)
[03:43] <indraveni> seb128, how is the desining of that is done in ubuntu? in debian we dont have any such dislog window 
[03:44] <indraveni> seb128, how that dialog is invoked, what is the desktop file responsible for this System -> Quit
[03:45] <seb128> indraveni: it's debian/patches/11_session_dialog.patch and there has been discussion in the Debian gnome-pkg team but no consensus to use it
[03:45] <seb128> indraveni: it's the logout dialog, it's coded and not used a desktop
[03:45] <seb128> s/used/using
[03:46] <seb128> indraveni: what are you trying to do?
[03:46] <indraveni> seb128, I am tring to create a debian based distro on my own
[03:46] <indraveni> seb128, and I am seeing that the debian shutdown and logout images are not very good to see 
[03:46] <indraveni> seb128, where as ubutnu has a good look and feel for this
[03:46] <seb128> maybe base it on Ubuntu if you like the desktop changes there ;)
[03:47] <indraveni> seb128, I am trying to do a similar kind of images for my distro
[03:47] <seb128> have a look to the patch I mentioned then
[03:47] <indraveni> seb128, ha, that will be next option, initially I want to learn how the things have been changed from debian to ubutnu
[03:47] <indraveni> s/ubutnu/ubuntu
[03:48] <seb128> good luck then
[03:48] <seb128> brb, restarting to try some change
[03:51] <shawarma> I'm looking at https://bugs.launchpad.net/ubuntu/+source/sysklogd/+bug/19889 which looks like a strong candidate for an SRU. However, as well documented the issue *and* the fix seems to be, it feels funny to file an SRU without properly testing it first, but I don't have the hardware to do that.. Does anyone have a Dapper machine with a few GB (or GiB or whatever) space in /var/log that they would consider testing this on?
[03:51] <ubotu> Launchpad bug 19889 in sysklogd "sysklogd: Large file support is broken in dapper" [High,Confirmed]  
[03:58] <shawarma> Hmm.. tough room.
[03:58] <Keybuk> shawarma: actually, it's neither 2GB or 2GiB
[03:58] <Keybuk> the maximum size of the file is 2^9-1 :p
[03:59] <shawarma> Keybuk: 511 bytes? wow
[03:59] <Keybuk> uh, 2^31-1 :p
[03:59] <shawarma> Keybuk: Well, yes, so I need 2 GiB in order to make sure it's not just because I *actually* have run out of space. :)
[04:00] <elmo> shawarma: I have an in use package that I know fixes the problem
[04:00] <shawarma> elmo: Just with the shell bits added?
[04:00] <shawarma> elmo: I'll just refer to you then, shall I?
[04:00] <Keybuk> debdiff showdown? :p
[04:01] <elmo> shawarma: yes, let me just find the source for  package I'm using
[04:01] <elmo> oh right, that'd be the 'HATEYOUALL' directory on ronne
[04:01] <Hobbsee> ...that exists?
[04:02] <Hobbsee> that's pure awesomeness.
[04:02] <Keybuk> I think that's unfair
[04:02] <Keybuk> HATECHMJ would be better
[04:02] <shawarma> elmo: http://www.linux2go.dk/19889.diff <-- the proposed patch.
[04:02] <elmo> shawarma: ronne:~james/HATEYOUALL - give it 5-10 minutes for your account to propagate
[04:02] <shawarma> Alright, then.
[04:02] <StevenK> He's a sysadmin, he's *supposed* to hate everyone.
[04:03] <Hobbsee> Keybuk: what's CHMJ?
[04:03] <lousygarua> /joing #ubuntu-bugs
[04:03] <lousygarua> oops
[04:03] <Keybuk> Hobbsee: who-touched-it-alst
[04:03] <Keybuk> last too
[04:03] <Hobbsee> ahhhh
[04:05] <seb128> Hobbsee: bug #119842, could you describe the Ubuntu changes and why they can be dropped?
[04:05] <ubotu> Launchpad bug 119842 in shntool "Please sync shntool (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/119842
[04:05] <Hobbsee> seb128: mumble mumble thought i did...
[04:06] <seb128> ;)
[04:06] <Hobbsee> seb128: -ENOUBUNTUCHANGES,THOUGHTTHEAUTOSYNCWASOFFNOW
[04:07] <seb128> k, that's what I was wondering
[04:07] <Hobbsee> i know it's close to off - thought it went off a copule of days ago
[04:07] <persia> Autosync is one more week, right?
[04:07] <Hobbsee> (btw, what was the result on getting the universe autosync to run later?)
[04:08] <cjwatson> we discuss this every release
[04:08] <seb128> persia: schedule is on the wiki ;)
[04:08] <pitti> until June 21st
[04:08] <cjwatson> every release the answer is the same: it's risky because Debian don't honour our main/universe separation when making complicated changes
[04:08] <persia> seb128: Just checking validity :)
[04:08] <Hobbsee> cjwatson: apologies, i'm not sure i ever saw that discussion - or at least the outcome
[04:08] <Hobbsee> oh right, that, yes.
[04:13] <pitti>    * Added myself to Uploaders, as i'm maintaining the Kubuntu side
[04:13] <pitti> Hobbsee: ^ nevermind about Uploaders: in Ubuntu
[04:13] <Hobbsee> pitti: i know.  i just wanted to be there.  *shrugs*
[04:14] <Hobbsee> and apparently one cant have multiple maintainers.
[04:14] <Hobbsee> figured that they might figure to ask me for the kubuntu side, seeing as it has the kubuntu address in there and all, isntead of going to mvo for all of it.
[04:15] <pitti> Hobbsee: right, as a hint about whom to contact that's fine
[04:15] <Hobbsee> :)
[04:16] <asac> if i am in debian Uploader for a package that is ment to go into main, should I use my address as Maintainer or Ubuntu Core Developers <ubuntu-devel-discuss@lists.ubuntu.com> ?
[04:17] <asac> s/if i am in/if i am a/
[04:17] <Hobbsee> asac: i believe the answer is "whichever"
[04:17] <asac> :9
[04:17] <asac> ok
[04:18] <Hobbsee> asac: as it was only to stop annoying the debian developers who were getting ubuntu bugs
[04:18] <Hobbsee> but clearly you wont be annoyued, as you're also the ubuntu maintainer
[04:18] <asac> ;)
[04:21] <geser> seb128: could you run the script that fetches NEW source packages from Debian on your next archive day? it would be good if we get claws-mail as we already have claws-mail-extra-plugins but are missing the main package
[04:22] <pitti> BenC, keescook: did you see the latest response in bug 117314 wrt. 'nvidia'? did the recent -security upload change the ABI unnoticed?
[04:22] <ubotu> Launchpad bug 117314 in linux-source-2.6.20 "latest kernel(2.6.20-16.28) update gives boot problems" [Critical,In progress]  https://launchpad.net/bugs/117314
[04:24] <seb128> geser: hum, will try
[04:24] <asac> geser: you did the xulrunner python2.5 patch at some point, right?
[04:24] <BenC> pitti: sounds less like a ABI change, and more like a failure somehow for nvidia.ko to be linked
[04:25] <BenC> pitti: considering the guy could not boot the first -16 kernel because of the device name changes, it's more likely that something just didn't complete in his update (depmod maybe?)
[04:25] <geser> asac: no, that was \sh, I only merged xulrunner
[04:25] <pitti> ah
[04:26] <asac> geser: we have to do it differently ... it might cause access of uninitialised memory
[04:26] <BenC> pitti: also, we had quite a few people complain about nvidia breaking, mainly because they had their own locally compiled version
[04:27] <pitti> Hobbsee: IIRC I rejected it because we'll auto-import it anyway
[04:27] <Hobbsee> pitti: and you removed it from the blacklist, too?
[04:27] <Hobbsee> i believe someone mentioned that it was on there
[04:28] <pitti> Hobbsee: I did
[04:28] <seb128> BenC: somebody I know complained to me this morning that the linux update broke his nvidia and he said he only used restricted-manager to install the driver
[04:28] <Hobbsee> cool.  i thought so.  just i would have expected it to be synced by now, in which case geser wouldnt be asking.  whether it actually *has* or not, i've not checked.
[04:29] <BenC> seb128: If running "sudo /etc/init.d/linux-restricted-modules-common" fixes it, then it's something in the install scripts
[04:29] <seb128> BenC: I'll ask him later when he'll be around and let you know
[04:29] <pitti> seb128: see above bug (117314)
[04:30] <seb128> pitti: yeah, I added that a piece of information because BenC was saying breakage are mainly due to compiled versions
[04:30] <geser> asac: if you have a better patch for the FTBFS let's use it
[04:31] <asac> geser: no ... wanted to help developing it :) ... haven't looked into it in detail so far :)
[04:31] <asac> geser: its on my TODO list though :)
[04:40] <doko> pitti: thanks for the reminder, but still waiting for the package in debian NEW to be synced
[04:41] <pitti> doko: oh, we can sync zope3 from Debian's NEW?
[04:41] <doko> pitti: try it, I'm not an archive admin ;-P
[04:42] <pitti> doko: can == we can ditch the ubuntu changes, not how to technically do it
[04:42] <seb128> BenC, pittiit looks like the linux security update also reintroduced bug #109762
[04:42] <ubotu> Launchpad bug 109762 in linux-source-2.6.20 "resume from suspend to Ram only works once - I/O error the second time (Samsung X20 and IBM T40p - feisty)" [Wishlist,Fix released]  https://launchpad.net/bugs/109762
[04:43] <doko> pitti: yes, the changes can be dropped with 3.3.1-3
[04:45] <pitti> doko: cool
[04:46] <pitti> doko: unfortunately Debian's NEW queue doesn't provide the packages in it
[04:48] <pitti> doko: if you can put the .dsc and diff.gz somewhere, we can manually sync it
[04:48] <doko> pitti: well, we should not do that ...
[04:51] <shawarma> If someone with stronger perl-fu than me could take a peek at (and possibly upload the patch) https://bugs.launchpad.net/ubuntu/+source/lintian/+bug/120040 it would be much appreciated.
[04:51] <ubotu> Launchpad bug 120040 in lintian "Should not accept debian distros for ubuntu packages and vice versa" [Undecided,Unconfirmed]  
[04:54] <BenC> seb128: lesser of two evils...the revert of that allowed people to actually boot :)
[04:55] <seb128> BenC: ah, k
[04:55] <seb128> BenC: thank you for the information ;)
[04:58] <asac> how can i find-out if gstreamer0.10-plugins-base is currently shipped on CD (e.g. without downloading an iso)?
[04:58] <Hobbsee> asac: check if it's in the seeds
[04:58] <cjwatson> asac: (http://wiki.ubuntu.com/SeedManagement)
[04:59] <Hobbsee> asac: and apt-cache show ubuntu-desktop | grep gstreamer0.10-plugins-base will also tell you, as a starting point
[04:59] <cjwatson> the seeds aren't dependency-expanded, though, so it may be easier to check the .list/.manifest files on http://releases.ubuntu.com/
[05:00] <asac> cjwatson: cool thanks a lot ... looking at .list files is a nice trick
[05:02] <pitti> thekorn: I created a Bug.mark_duplicate() function (branched off 'main'); will this disrupt your work on the api.changes.gsoc branch in any way?
[05:04] <thekorn> pitti: no, i don't think so
[05:04] <pitti> thekorn: ok, thanks; I'll finish and test it and put it into my own branch on LP, and then ask dholbach to merge to main
[05:05] <seb128> can anybody confirm bug #119528
[05:05] <ubotu> Launchpad bug 119528 in laptop-mode "Please remove laptop-mode from the Ubuntu archives" [Wishlist,Confirmed]  https://launchpad.net/bugs/119528
[05:06] <seb128> that looks correct to me but I would like an another opinion just to be sure ;)
[05:06] <thekorn> pitti: ok, cool; other question: How are you testing your code in launchpad? did you open bugs for testing or is there a kind of sandbox?
[05:07] <pitti> thekorn: I usually just test them on the live LP on an old test bug of mine
[05:08] <pitti> thekorn: but if you want to do large-scale or even automated testing (yummy), then https://dogfood.launchpad.net/ might be better
[05:08] <seb128> persia: heh ;)
[05:09] <desrt> seb128; why are there no internation airports in the north of france?
[05:10] <seb128> desrt: because France is not big enough to justify it? ;)
[05:10] <thekorn> pitti: ok, thanks, will have a look at it
[05:10] <desrt> seb128; there are tonnes in the south
[05:10] <johanbr> Everybody wants to go to the Riviera. :)
[05:10] <persia> seb128: You might also be interested in bug 6676, which was a previous attempt to do the same thing.
[05:10] <ubotu> Launchpad bug 6676 in laptop-mode "Laptop-mode should be replace by laptop-mode-tools" [Wishlist,Rejected]  https://launchpad.net/bugs/6676
[05:11] <seb128> persia: ok
[05:11] <desrt> seb128; how far are you from lens?
[05:12] <seb128> desrt: ~400km
[05:12] <desrt> holy crap
[05:12] <seb128> what?
[05:12] <desrt> farther than i'd have guessed :)
[05:13] <desrt> i'm trying very hard to visit vimy
[05:15] <seb128> desrt: going to enjoy Europe again? ;)
[05:15] <desrt> well
[05:15] <desrt> if possible
[05:15] <desrt> but it's looking pretty impossible right now
[05:19] <desrt> i plan to fly into manchester before guadec and take the train (8) to birmingham and then back to manchester to leave.  looks cheapest.
[05:19] <desrt> but... instead of taking a train from manchester to birmingham i was thinking maybe a flight to paris then various trains to work my way north to nijmegen and eventually leave via schiphol
[05:19] <pbn> Hi there... when I got a bug number, how can I find out to what release of ubuntu it applies ?
[05:19] <pbn> For instance bug 6655
[05:19] <ubotu> Launchpad bug 6655 in rgl "rgl: merge new debian version" [Medium,Fix released]  https://launchpad.net/bugs/6655
[05:19] <pbn> oops
[05:19] <desrt> :)
[05:19] <pbn> For instance bug 36655
[05:19] <ubotu> Launchpad bug 36655 in kdenetwork "pppd dies on connection" [High,Confirmed]  https://launchpad.net/bugs/36655
[05:19] <desrt> Kubuntu Flight 5 == before dapper
[05:19] <desrt> but it's still open so it probably affects dapper, edgy, feisty, gutsy...
[05:22] <pbn> desrt: thank you
[05:22] <pbn> desrt: well I just installed kubuntu 6.06 on my neighbour's computer, and it's two days I see pppd crash just after kppp has completed the connection
[05:23] <pitti> dholbach: would you mind merging (or just pulling) my p-lp-bugs branch to fix bug 119874? (I attached the branch there)
[05:23] <pbn> I guess this might be another case of a bug in Ubuntu 6.06 that the ubuntu teams will not fix :(
[05:23] <ubotu> Launchpad bug 119874 in python-launchpad-bugs "please support marking a bug as duplicate" [Wishlist,Fix committed]  https://launchpad.net/bugs/119874
[05:23] <pitti> dholbach: NB that the package version number in my branch is not yet suitable for upload
[05:24] <dholbach> pitti: yep, will do
[05:24] <pitti> dholbach: *hug*, thanks
[05:24] <dholbach> np
[05:25] <pbn> Is there some way to tell kppp to start pppd with strace ?
[05:25] <pbn> I'd like to do that 
[05:25] <pbn> after that I guess I'll file a bug report with that information
[05:25] <desrt> no... but you can attach strace after the fact,  using -p
[05:25] <desrt> and if it's the same bug, just attach the information rather than filing a new one
[05:26] <desrt> have you tried using feisty?
[05:26] <pbn> desrt: well no... 
[05:26] <desrt> that should be your first stop :)
[05:26] <pbn> desrt: sorry but I suppose this is gonna be again the very same debate
[05:27] <pbn> I already had the same kind of problem with kvpnc
[05:27] <pbn> A bug which is "as huge as a barn"
[05:27] <pbn> bug number 77950
[05:28] <pbn> bug 77950
[05:28] <ubotu> Launchpad bug 77950 in kvpnc "kvpnc crashes with SIGSEGV when trying to import a Cisco .pcf file" [Undecided,Fix released]  https://launchpad.net/bugs/77950
[05:28] <pbn> I opened that bug in january 2007
[05:28] <pbn> on ubuntu 6.06
[05:29] <pbn> the bug is supposedly fixed in edgy and feisty
[05:29] <pbn> but not in 6.06 LTS
[05:29] <pbn> Now I guess it's gonna be the same thing again
[05:29] <pbn> That you folks won't fix it in 6.06 LTS and just say "Use feisty"
[05:29] <pbn> sorry to tell you that but LTS means Long Term Support, not No Support, sorry
[05:30] <pbn> I'm using 6.06 LTS for "average users" in a corporate environment, or some "newcomers" who have never had a computer
[05:30] <pbn> I can't just go to eeach of these machines every six months to do apt-get dist-upgrade and pray that nothing breaks
[05:30] <pbn> That's why I'm installing 6.06 LTS for those people 
[05:31] <seb128> StevenK: is something in main using python-qt4-dbus or should it go to universe?
[05:31] <pbn> In my case I'm using Debian GNU/Linux, but I will not bring Debian in the debate...
[05:31] <seb128> pbn: dapper is supported, we can't fix every single bug there though
[05:32] <seb128> pbn: Debian stable doesn't do that neither nor any other distro
[05:32] <pbn> seb128: well the solution to that kind of problem was to switch *my* machines to Debian
[05:32] <pbn> seb128: sorry but Debian DOES fix bugs in the stable release
[05:32] <seb128> we do too
[05:33] <seb128> we can't fix every bug though
[05:33] <seb128> there is lot of bugs and limited manpower, stable updates takes quite some ressources for regressing testing, etc
[05:33] <pitti> (Debian does much fewer bug fixes to stables than we do, FWIW)
[05:33] <pbn> seb128: yes, I understand it can be difficult to fix every single bug, especially in "old" releases like 6.06
[05:34] <seb128> bug #77950 you pointed has no duplicate and few comments and almost no subscriber
[05:34] <ubotu> Launchpad bug 77950 in kvpnc "kvpnc crashes with SIGSEGV when trying to import a Cisco .pcf file" [Undecided,Fix released]  https://launchpad.net/bugs/77950
[05:34] <pbn> seb128: but I find it counter-productive to have release 6.06 LTS which is supposed to have LTS .... and when there's a bug in 6.06 LTS, the only solution is to upgrade to 7.0.x !
[05:34] <seb128> doesn't look something that needs to be fixed to stable
[05:35] <pbn> well right now I'm adding comments to 36655
[05:35] <seb128> not to mention it's an universe package
[05:35] <pbn> uhhh did someone say something about how to run pppd with strace from kppp ?
[05:35] <pbn> seb128: which one is an universe package ? kpvnc or kppp ?
[05:35] <pitti> pbn: another option is to just use one or two backports on dapper
[05:36] <seb128> the other one has 2 duplicates and few comments, doesn't look like something blocker many users neither
[05:36] <seb128> pbn: kpvnc
[05:36] <Hobbsee> pbn: did you ever find the particular patches that fixed the issue?
[05:36] <pbn> seb128: well I found a workaround to the kvpnc issue
[05:36] <pbn> Hobbsee: alas, no
[05:36] <Hobbsee> i seem to remember that was the outcome last time
[05:36] <dholbach> pitti: http://daniel.holba.ch/temp/pylpbugs.error
[05:36] <pbn> Hobbsee: for kvpnc, I tried looking into whte source of Debian packages
[05:37] <pitti> pbn: and yet another option, if you want to drive a stable release update for this bug, you are most welcome to :)
[05:37] <pbn> Hobbsee: but the version of kvpnc in Debian is much too new compared to the one in 6.06
[05:37] <Hobbsee> tbh, i wouldnt mind just backporting the entire source package.
[05:37] <Hobbsee> pbn: exactly
[05:37] <Hobbsee> which is why no one's done the work.
[05:37] <pbn> pitti: yes, it's always good if the person reporting the bug can fix it :)
[05:37] <pitti> dholbach: oh, that's a Python 2.5ism, sorry
[05:37] <Hobbsee> pbn: LTS or no, unless someone does the work, it will not happen.
[05:38] <Hobbsee> seb128: StevenK has gone to bed, FYI
[05:38] <pitti> dholbach: let me fix this quickly
[05:38] <pbn> Hobbsee: I know...
[05:38] <pbn> So there might be a backport of kppp for 6.06 somewhere ?
[05:38] <Hobbsee> if someone requests one, and it actually builds.
[05:38] <seb128> Hobbsee: do you know if the package is required to main? otherwise I'll direct it to universe, we can still change that later if required ...
[05:38] <Hobbsee> hang on, are you talking kppp or kvpnc?
[05:38] <pbn> Hobbsee: kppp, sorry
[05:39] <Hobbsee> seb128: i'm not positive, but it looks like a kde4-necessary thing
[05:39] <Hobbsee> seb128: so main eventually, if not now
[05:39] <seb128> Hobbsee: I'll direct it to universe, if anything starts depending on it we will promote it then
[05:40] <iwj> Yay!
[05:40] <seb128> otherwise it'll be on the "demote list"
[05:40] <Hobbsee> seb128: cool.  it'll be with the whole "promote kde4 to main" which is a later thing.
[05:40] <iwj> gcc-4.1 -fno-stack-protector [... 2000 characters more of command line] 
[05:40] <iwj> collect2: ld returned 1 exit status
[05:40] <iwj> And that's it.
[05:40] <Hobbsee> pbn: bug #?
[05:41] <pbn> Hobbsee: I'd be happy to find a backport of kppp ( bug 36655 ) :)
[05:41] <ubotu> Launchpad bug 36655 in kdenetwork "pppd dies on connection" [High,Confirmed]  https://launchpad.net/bugs/36655
[05:41] <pitti> dholbach: pushed
[05:41] <dholbach> pitti: rock
[05:41] <Hobbsee> anyone found a solution to it yet?
[05:41] <Riddell> pbn: what do you have in /etc/ppp/peers/kppp-options ?
[05:41] <pitti> dholbach: the ternary operator is such a nice thing :)
[05:41] <iwj> [pid  5017]  write(2, " ", 1)            = -1 ENOSPC (No space left on device)
[05:41] <iwj> Aha!"
[05:41] <iwj> And there's me trying to do disk-full debugging ...
[05:42] <pitti> iwj: with hacked preload lib wrapping write(2) or so? :)
[05:42] <cjwatson> ooh, looks like openssh upstream now puts non-standard port numbers in known_hosts
[05:42] <tepsipakki> are packages allowed to install stuff in /home?
[05:42] <iwj> pitti: No, this is while I'm trying to build the lib wrapping write ...
[05:42] <pitti> tepsipakki: absolutely not
[05:42] <persia> tepsipakki: No.
[05:42] <pbn> Riddell: don't know, it's my neighbours computer... is that information important ?
[05:42] <iwj> As in, my disk randomly filled up so I can't build my disk full debugger.
[05:43] <iwj> And I find a bug in the linker where it doesn't say why.
[05:43] <tepsipakki> ok, kubuntu-default-settings is buggy, then
[05:43] <pitti> iwj: heh; nice cycle
[05:43] <cjwatson> iwj: I think that's *some* kind of result
[05:43] <pbn> Riddell: /etc/ppp/options is untouched for sure, that I have checked
[05:47] <Riddell> pbn: it should have "noauth", if it has "#noauth" then it won't work.  not sure which dapper had
[05:47] <tepsipakki> it creates a symlink /home/.directory -> /etc/kubuntu-default-settings/directory-home
[05:47] <tepsipakki> and this in feisty
[05:47] <cjwatson> tepsipakki: some systems have /home NFS-mounted and that will break on such systems
[05:47] <tepsipakki> cjwatson: you don't say ;)
[05:47] <Hobbsee> tepsipakki: i believe that's in edgy too :S
[05:47] <pbn> Riddell: hmmm thanks I'll check that. You said in /etc/ppp/peers/kppp-options there must be noauth and sure not #noauth
[05:47] <tepsipakki> Hobbsee: could be, we didn't use edgy
[05:47] <cjwatson> tepsipakki: I thought you'd probably know that ;)
[05:47] <Hobbsee> it was supposed to be gone on feisty
[05:47] <Hobbsee> iirc
[05:47] <Riddell> Hobbsee: it's the / one we got rid of, /home is there for a nice icon
[05:47] <Hobbsee> Riddell: ahhh....right.  i thought they were both there for the same thing
[05:47] <tepsipakki> cjwatson: yeah, well.. usually /home is not used here, but the math department has used it so that's why it has gone unnoticed until now
[05:47] <cjwatson>  * These macros demonstrate the property of C whereby it can be
[05:47] <cjwatson>  * portable or it can be elegant but rarely both.
[05:47] <cjwatson> (openssh/openbsd-compat/getrrsetbyname.c)
[05:47] <dholbach> pitti: rock on
[05:47] <pitti> dholbach: works now? (it builds here)
[05:47] <dholbach> yep
[05:47] <dholbach> uploaded
[05:47] <tepsipakki> Riddell: so, shouldn't this be fixed with an update?
[05:47] <pitti> dholbach: danke sehr
[05:47] <pitti> dholbach: I'll close the bug once I see the -changes mail
[05:47] <Riddell> tepsipakki: if we can find a suitable "fix"
[05:47] <cjwatson> efforts to munge /home like that should be done in the postinst with a version guard and || true
[05:47] <cjwatson> Riddell: ^--
[05:48] <tepsipakki> it is in the postinst
[05:48] <tepsipakki> but /home is a normal directory during install
[05:48] <Riddell> cjwatson: it is actually
[05:48] <tepsipakki> so I'm not sure there is a way to go around that
[05:49] <Riddell> I'm sure I consulted on this when adding it to the package, although I can't remember who with now
[05:50] <pbn> okay folks when I'll have time tomorrow or later I'll go check my neighbour's computer and try that trick Riddell told me ... thank you, Riddell :)
[05:51] <cjwatson> Riddell: ok ...
[05:52] <superm1_> any archive admins about?  it appears that libpostproc0d is no longer in the archive, but several apps (vlc-nox & transcode come to mind) depended on it.  It appears to be superseeded by libpostproc1d.  Should a bug just be filed across any app that comes up like that to rebuild it?
[05:52] <pygi> how do I kick upstream's ass if they play with endians too much? :P
[05:53] <persia> superm1: Yep, and a -build1 uploaded.  It's nice to have all the relevant packages as separate tasks in a single bug.
[05:55] <superm1_> persia, any easy way to find all the ones that need a rebuild?  apt-cache rdepends isn't handling it
[05:55] <seb128> superm1_: use grep-dctrl
[05:55] <superm1_> k thx seb128 
[05:55] <seb128> dholbach: is there some recipes for that on the wiki?
[05:56] <dholbach> seb128: unfortunately not
[05:56] <persia> seb128: They disappeared in the UDS WIki cleanup.
[05:56] <dholbach> http://wiki.ubuntu.com/MOTU/Recipes
[05:56] <seb128> dholbach: I'll write one if nobody does it first then ;)
[05:56] <pbn> also, where should I search for a possible backport of a "working" kppp for Ubuntu 6.06 ?
[05:56] <dholbach> seb128, persia: https://wiki.ubuntu.com/UbuntuDevelopment?action=fullsearch&context=180&value=grep-dctrl&fullsearch=Text
[05:56] <dholbach> that's all I can find
[05:57] <dholbach> seb128: that's very nice of you
[05:57] <pitti> superm1_, persia: apt-cache unmet perhaps?
[05:57] <pygi> seb128  is alive, seb128 is alive :)
[05:57] <seb128> hey pygi
[05:57] <pygi> hey seb128 ^_^
[05:57] <pygi> how are you doing?
[05:58] <seb128> pbn: maybe open a bug on https://launchpad.net/dapper-backports
[05:58] <seb128> pygi: good, thanks, catching up with everything which happened while I was on holidays ;)
[05:58] <superm1_> persia, who should i subscribe after I make the bug? u-u-s?
[05:58] <persia> dholbach: Thanks.
[05:59] <pygi> seb128, ok, I uploaded new libisofs, libburn, and brasero packages
[05:59] <persia> superm1: U-U-S should only be subscribed once there are debdiffs for each package.  I'll get an example in a moment.
[06:00] <superm1_> just a debdiff bumping the version number with a build1 applied to the end?
[06:00] <pygi> seb128, ^_^
[06:00] <pygi> seb128, now brasero actually works =)
[06:00] <seb128> ah, nice
[06:01] <pygi> with libburn & libisofs even :)
[06:01] <seb128> I'll try that then ;)
[06:01] <seb128> waouh
[06:01] <pygi> newest versions of both ofcourse
[06:02] <geser> superm1: yes (if there is no ubuntuX already), but please check if it builds
[06:02] <pygi> gotta bug upstream to fix src/scsi tho as I can't build on ppc & sparc because of that, and patching would be big probably
[06:02] <superm1_> geser, ok thanks
[06:02] <Keybuk> ooh
[06:02] <Keybuk> seb128: we patched gnome-system-tools to avoid using GiB? :p
[06:02] <superm1_> geser if there is already an ubuntuX, should it be ubuntuXbuild1 still then?
[06:03] <seb128> Keybuk: gnome-system-monitor you mean? yes
[06:03] <geser> superm1: ubuntu(X+1)
[06:03] <superm1_> k
[06:03] <Keybuk> \o/
[06:03] <Keybuk> wonder if I can get away with patching ifconfig? :p
[06:03] <Keybuk> seb128: does it divide by 1024 or 1000? :p
[06:04] <seb128> Keybuk: 1024
[06:07] <ion_> The ugliest thing is that the Finnish locales use Mt, which is of course totally wrong. Its just something Windows and Finnish computer magazines have been using for years, so many think its a correct way to put it, as if standard units were somehow translatable.
[06:09] <Hobbsee> sigh.  why do people *always* end up attacking launchpad when the admins arent around to deal with it?
[06:10] <Keybuk> Hobbsee: verbally or physically? :p
[06:10] <Hobbsee> Keybuk: er, physically
[06:10] <Keybuk> Hobbsee: WFM?
[06:10] <Hobbsee> Keybuk: https://bugs.launchpad.net/bugs/119467
[06:10] <ubotu> Launchpad bug 119467 in kubuntu-meta "make non-essential packages Recommends and not Depends" [Undecided,Unconfirmed]  
[06:11] <thully> hi - I've identified an issue with the MacBook trackpad on feisty and gutsy tribe 1 - you can't change pointer acceleration *at all*
[06:11] <Keybuk> thully: please use launchpad.net to file a bug
[06:11] <thully> however, doing rmmod appletouch and modprobe appletouch fixes it until the next time you restart X
[06:12] <persia> thully: DId you comment on the relevant bug after the last time this was discussed?
[06:12] <thully> I did that - wondering if anyone may have a clue where this issue is...
[06:12] <cjwatson> thully: (FWIW, you asked about whether there was a team concentrating on MacBook issues; I think that MacBooks are sufficiently mainstream now and well enough supported by stuff like the installer that they don't urgently need a separate team)
[06:13] <Keybuk> thully: those people are more likely to respond to your bug report than answer questions here, this is not a support channel
[06:13] <persia> thully: Wait then.  Someone will look at it as soon as they have time.
[06:14] <thully> I just came here to confirm that doing an rmmod and modprobe of the appletouch module resolves the problem until X is restarted
[06:15] <thully> which would seem to narrow things down a bit
[06:15] <pygi> seb128, let me know if you got any troubles ^_^ I've fixed that libisofs error you reported
[06:15] <Keybuk> thully: please add that information to the bug report
[06:16] <thully> OK - is there anything else that may help to test in order to narrow down the issue?
[06:17] <thully> I realize this is not a support channel - I actually wanted to help get this resolved (though diving TOO deep into the kernel source may be above me)
[06:18] <bryyce> glatzor, excellent, I'll check them out
[06:18] <seb128> pygi: k, will do
[06:21] <thully> in general I'd just like to find a way to help fix these issues besides just filing the report - I can do a lot of experimenting here
[06:22] <persia> thully: Also note that in the bug report - the developers may contact you to help test.
[06:23] <thully> thanks - I figure I'll load up the gutsy tribe 1 iso I just downloaded and try a few things...
[06:24] <mneptok> cjwatson: understood (re: VMWare). my concern is kernel/module questions as filtered through VMWare.
[06:25] <thully> I'm not using VMware to test this one...
[06:27] <thully> that was talking about general use - as I had resorted to VMware to AVOID issues like the aforementioned appletouch issue
[06:29] <keescook> pitti: have others confirmed nvidia breakage with the kernel update?
[06:29] <pitti> keescook: someone seb128 talked to apparently
[06:30] <seb128> keescook: somebody I know mentioned it this morning, I'm not sure if he had to reboot a new kernel because the new was not booting though
[06:31] <seb128> keescook: would it work in this case, or did the ABI or something changed which means the new restricted module would not work with the previous linux?
[06:31] <keescook> seb128: afaiu, the ABI was bumped with 16.28 (two updates ago).  current update is 16.29 and didn't bump the ABI
[06:35] <seb128> I'll ask for details and let you know
[06:35] <keescook> I tested it with fglrx and it was okay -- I didn't have a feisty nvidia machine.
[06:35] <seb128> he has an nvidia
[06:35] <seb128> and the bug happened this week while I was on holiday, dunno when
[06:35] <seb128> he told me he had to switch to nv to have xorg working again after the linux update
[06:35] <mjg59> bryyce: Any objection to me uploading libpciaccess?
[06:36] <bryyce> mjg59: not offhand - what's it for?
[06:37] <mjg59> bryyce: Not at liberty to say yet :)
[06:37] <jdong> can I get a core-dev sponsor for bug 110881?
[06:37] <ubotu> Launchpad bug 110881 in ktorrent "[SRU]  Citical bug cherrypicks from SVN" [Undecided,In progress]  https://launchpad.net/bugs/110881
[06:37] <jdong> u-m-s has been subscribed for almost two weeks to no avail
[06:37] <bryyce> mjg59: is that a new package or does it go by a different name in launchpad?
[06:37] <mjg59> New package
[06:38] <mjg59> X is moving towards using it rather than hand-rolled PCI access
[06:38] <mjg59> Since it has an API that doesn't suck
[06:39] <bryyce> mjg59: cool, sounds good to me.  Thanks for letting me know about it :-)
[06:40] <tepsipakki> mjg59: you'll grab it from master?
[06:40] <mjg59> tepsipakki: Yeah
[06:40] <mjg59> tepsipakki: ABI is supposed to be pretty much stable now
[06:41] <tepsipakki> mjg59: ok, good
[06:50] <seb128> keescook: I've asked him, -15 didn't boot and -16 doesn't work with nvidia, restricted-manager says there is no driver for the card
[06:50] <pitti> dholbach: ^ I might require your pull/upload service again
[06:50] <keescook> seb128: if he went from -15.27 to -16.29 he'll need to update l-r-m too.
[06:51] <dholbach> pitti: rock and roll
[06:51] <dholbach> pitti: looking in a bit
[06:51] <pitti> dholbach: sorry, originally I thought it was too complicated and thus already asked you for the previous upload
[06:51] <dholbach> pitti: no problem
[06:52] <dholbach> is any work being done to get the new network-manager in? :)
[06:54] <dholbach> pitti: did you push already?
[06:55] <pitti> dholbach: pushed now
[06:56] <pitti> yay, that paves the way for mass-deleting CoreDump.gz attachments
[06:57] <dholbach> pitti: got it
[07:00] <giskard> dholbach, how much new?
[07:04] <dholbach> hey giskard - how's it going?
[07:07] <giskard> dholbach, bad, in 1 week i will start exams
[07:07] <dholbach> giskard: oh man - I wish you all the best with those!
[07:07] <giskard> and i don't know something 
[07:07] <giskard> http://www4.autistici.org/giskard/file/tesina/mappa_concettuale_tesina.html
[07:07] <giskard> ops wrong paste but maybe you can understand what is this
[07:07] <dholbach> looks like you have a bunch of things to do :)
[07:08] <Hobbsee> erk.  dont mention exams.
[07:08] <dholbach> pitti: uploaded
[07:08] <dholbach> pitti: thanks a lot
[07:09] <pitti> dholbach: thanks to you
[07:11] <seb128> keescook: no, he went from 15.27 to 16.28 which didn't boot, kept using -15 then until the updates some days ago
[07:11] <seb128> keescook: the new 16.29 boots fine again for him
[07:11] <seb128> but then there is no nvidia working
[07:12] <seb128> so it's using 16.29 with nv now
[07:12] <pitti> yay stables :(
[07:13] <cjwatson> pitti: interesting - what's the security on delete_attachment?
[07:13] <seb128> pitti: I've just read the changelog quickly, I'm surprised by the number of changes going to security updates
[07:13] <pitti> cjwatson: no idea really
[07:13] <pitti> seb128: so was I
[07:13] <keescook> seb128: I'm upgrading an nvidia feisty machine I found.
[07:14] <cjwatson> seb128: see distro-team@ ..
[07:15] <pbn> do you people know if there is  a non-broken pppd and/or kppp for 6.06 on this site: http://be.archive.ubuntu.com/ubuntu/dists/dapper-backports/
[07:15] <pbn> I cannot add that line to sources.list and apt-get upgrade because obviously the machine cannot connect to the Internet ...
[07:16] <pitti> pbn: neither ppp nor kppp have been put into any backports
[07:16] <pbn> pitti: ouch, then it's a pain 
[07:17] <pitti> pbn: it's easy to create one once it gets tested
[07:17] <pbn> pitti: easy ? ah ?
[07:17] <pitti> pbn: https://wiki.ubuntu.com/BackportRequestProcess
[07:19] <Hobbsee> kppp is in main
[07:19] <Hobbsee> there's a reason why noauth is usually commented though, in debian.README.
[07:19] <Hobbsee> or was last i checked
[07:20] <pbn> https://bugs.launchpad.net/dapper-backports/+bug/120054
[07:20] <ubotu> Launchpad bug 120054 in dapper-backports "kppp: pppd crashes with return value 1 when called by kppp" [Undecided,Unconfirmed]  
[07:21] <pbn> with that bug 120054 ... will someone make a backport of kppp to 6.06 ?
[07:21] <ubotu> Launchpad bug 120054 in dapper-backports "kppp: pppd crashes with return value 1 when called by kppp" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120054
[07:21] <pitti> pbn: now you need to test whether the gutsy, feisty, and/or edgy version fixes the bug, and confirm that the package works on dapper
[07:22] <Hobbsee> it's fixed in gutsy
[07:22] <pitti> pbn: and write the test results into those bugs
[07:22] <Hobbsee> at least the noauth part is
[07:22] <Hobbsee> touching /etc/resolv.conf is trivial, also
[07:22] <pitti> pbn: after that's done, siretart or jdong will need to approve the backport (test it themselves)
[07:22] <Hobbsee> pitti: if it's just uncommenting noauth, that's a SRU candidate
[07:22] <pbn> yes but... if I install the gutsy or feisty version of kppp on 6.06 ... won't stuff break ? You know, different versions of many packages ?
[07:22] <Hobbsee> no need to backport entire kde for it.
[07:23] <pitti> Hobbsee: right
[07:23] <Hobbsee> but there's a reason it's not done by default
[07:23] <Hobbsee> or didnt used to be
[07:23] <pitti> pbn: you need to build the source package on dapper, not install the feisty deb
[07:23] <Hobbsee> i looked at this bug ages and ages ago
[07:23] <pbn> pitti: ah. and where do I get the sources ? apt-get source ?
[07:23] <pitti> pbn: apt-get source works if you have deb-src lines for feisty
[07:24] <pitti> pbn: otherwise you just download it from archive.ubuntu.com (orig.tar.gz, diff.gz, and dsc)
[07:24] <pbn> pitti: ... from a machine which does not have an internet connection ?
[07:24] <Hobbsee> ah, here it is
[07:24] <pitti> pbn: tricky :)
[07:24] <Hobbsee> pitti: pbn http://rafb.net/p/MXHXgT95.html
[07:25] <Hobbsee> for "security reasons"
[07:25] <pbn> Hobbsee: thank you
[07:26] <pbn> Hobbsee: ok so the "quick fix" is to uncomment noauth in /etc/ppp/kppp-options ?
[07:26] <keescook> pitti, seb128: I'm not able to reproduce the nvidia problems locally.  -16.29 + nvidia binary driver works fine for me.
[07:26] <Hobbsee> yeah
[07:26] <Hobbsee> well, seems to be
[07:26] <Hobbsee> read the entire readme for more info
[07:27] <jdong> Hobbsee: how are you feeling to sponsor a ktorrent SRU today? :)
[07:27] <Hobbsee> jdong: er...i'm not?
[07:27] <jdong> lol
[07:28] <heno> Where can I find a list of packages that have been removed completely from the archive?
[07:28] <Hobbsee> heno: http://people.ubuntu.com/~ubuntu-archive/removals.txt
[07:28] <Hobbsee> :D
[07:28] <Hobbsee> (yay, i knew the answer to something) 
[07:28] <heno> Hobbsee: thanks!
[07:29] <Hobbsee> no problem
[07:29] <pygi> Hobbsee, meh, stop that :p
[07:29] <Hobbsee> pygi: stop what?  *looks around innocently*
[07:32] <Hobbsee> rmadison's...seriously cool.
[07:32] <Hobbsee> cant decide whiihc i prefer -that, or madison-lite
[07:50] <Skynet1984> clear
[07:52] <JanC> I think it might be a good idea to put a warning in fstab in gutsy, that tells people to use UUID or LABEL, and not device names...
[07:57] <pbn> you mean gutsy will no longer support device names ?
[07:59] <slomo_> pitti: anything we can do about gs? :)
[07:59] <Hobbsee> JanC: i hope grub2 handles UUIDS and such then
[07:59] <pitti> slomo_: no idea really; I forwarded the mail to Till
[08:00] <geser> pbn: they are still used in the background but it's not guaranteed that they stay stable across reboots
[08:00] <slomo_> pitti: interesting that it built fine locally for me... let me retry with a clean source tree :)
[08:02] <pitti> slomo_: ugh, indeed
[08:02] <pitti> slomo_: it attempted to build three times today
[08:02] <pitti> (on the buildd)
[08:03] <slomo_> pitti: i saw it :) i got a mail for each try :P
[08:05] <doko> pitti: the ia32-libs merge sounds like a pain ... any reason that you did merge the gtk bits?
[08:06] <pitti> doko: some people asked for it, and having it in one package is much easier to maintain and keep in sync
[08:06] <pitti> doko: the most painful part was to compare the horribly old rules from -sdl and -gtk against the current rules from ia32-libs
[08:07] <doko> pitti: then why not kde as well?
[08:07] <pitti> doko: OMG, there's yet another one?
[08:07] <pitti> doko: yeah, we can merge that as well
[08:07] <doko> yes, and then the source really gets a bit unmanagable ...
[08:08] <doko> and you have to update the resulting source more often
[08:08] <doko> I don't like it
[08:08] <pitti> doko: -kde is not even in Debian, so it is like -sdl
[08:08] <doko> anyway, leaving now ...
[08:08] <pitti> doko: as if we had updated -kde and -gtk that often... once or twice per release should be enough, though (in any case)
[08:09] <slomo_> pitti: still builds with everything up to date :)
[08:09] <pitti> slomo_: weird
[08:10] <slomo_> pitti: does gs require some fonts or whatever that might be missing in the buildds chroots but not on my system?
[08:10] <pitti> anyway, dinner, bbl
[08:10] <pitti> slomo_: does it work in a pbuilder?
[08:10] <slomo_> no idea yet
[08:20] <shawarma> I still need a core-dev with perl skills to check out https://bugs.launchpad.net/ubuntu/+source/lintian/+bug/120040
[08:20] <ubotu> Launchpad bug 120040 in lintian "Should not accept debian distros for ubuntu packages and vice versa" [Undecided,Unconfirmed]  
[08:23] <geser> shawarma: I'm no core-dev but I looked at the patch
[08:24] <shawarma> geser: Alright. I'm ready for the shouting. Let me have it. :)
[08:24] <geser> if I'm not mistaken you broke some valid Debian distributions
[08:24] <shawarma> Entirely possible. Which?
[08:25] <cjwatson> shawarma: yeah, it's not quite right, although the Perl is fine
[08:25] <elmo> you realise there are a bunch of packages in debian with ubuntu in the version string right?
[08:25] <shawarma> Alright then. Well, my Debian-fu is not very strong either :)
[08:25] <cjwatson> shawarma: -proposed-updates shouldn't be allowed for Ubuntu (just -proposed and the rest), but -proposed-updates, -updates, -backports, -security are fine for Debian
[08:25] <shawarma> elmo: No, I didn't.
[08:26] <geser> shawarma: stable-proposed-updates
[08:26] <cjwatson> elmo: this is just Ubuntu's lintian though. (There is a bug somewhere about having it have two modes)
[08:26] <shawarma> cjwatson: I just closed that one, actually.
[08:26] <cjwatson> shawarma: haven't looked at your closing message, but I sort of think that should stay open
[08:26] <shawarma> cjwatson: It suggested to do that in order to remove nmu warnings for Ubuntu packages, but that was fixed in some other way.
[08:26] <cjwatson> it would be nice to get it properly merged upstream
[08:27] <shawarma> elmo: I remember someone (in Debian) felt really offended that he had an package in his Debian system with "ubuntu" in the version string. I just assumed they "took care of it" after that.
[08:31] <shawarma> elmo: I can't find any in unstable main..
[08:31] <elmo> shawarma: I looked at rejecting the packages in dak, but there was too many examples already in the archive, and it seemed pointlessly harsh, esp. since Debian started treating Ubuntu as the upstream for some packages
[08:31] <elmo> shawarma: update-manager
[08:31] <shawarma> elmo: Yes. I'm an idiot.
[08:31] <shawarma> elmo: That seems to be the only one, though. At least in main.
[08:31] <iwj> Hah!  It built!
[08:31] <shawarma> elmo: Anyhow, do you have any good ideas on how to detect it otherwise?
[08:32] <iwj> Finally, after only fourteen zillion hours!
[08:32] <shawarma> iwj: What did?
[08:32] <iwj> My glibc hack for disk full testing logging.
[08:32] <iwj> Who knows whether it'll actually work.
[08:33] <elmo> shawarma: it's the only one now, there use to be more
[08:33] <elmo> shawarma: I'm not sure there is a 'better' way to detect it - I don't have any solutions and also don't care what you end up doing to ubuntu's lintian - just pointing out it may be a problem
[08:34] <ogra> shawarma, ltsp 
[08:34] <shawarma> ogra: No.
[08:35] <shawarma> ogra: It contains "debian", though.
[08:35] <geser> shawarma: what about doing something similar to dpkg-buildpackage? it checks with lsb_release if it runs on Debian and Ubuntu (can be overwritten with a commandline option)
[08:35] <ogra> oh, right, its the other way round tere
[08:35] <shawarma> geser: The trouble is that there a many DD's that run Ubuntu. I want to acommodate their needs as well..
[08:35] <shawarma> geser: automatically, that is.
[08:36] <shawarma> geser: I thought this was sufficient, but once again, I'm back at square one. 
[08:38] <geser> shawarma: don't forget that Ubuntu has also packages which are specific to Ubuntu and doesn't have a ubuntu in the version
[08:40] <shawarma> cjwatson: My closing message just reads "it was fixed in version blah". The changelog of said version says (among other things) "checks/nmu: Don't set nmu flag if version has "ubuntu"".
[08:41] <shawarma> geser: Really? Like what?
[08:41] <cjwatson> shawarma: I think the version check is perfectly good, TBH
[08:41] <cjwatson> shawarma: (random example) ubiquity
[08:41] <shawarma> cjwatson: Ok.
[08:42] <cjwatson> lintian doesn't have to be utterly perfect here ...
[08:42] <shawarma> cjwatson: Well, it's not like a warning from lintian makes anything fail..
[08:42] <shawarma> Ok, so the ubuntu distro-regex is fine, agreed?
[08:43] <shawarma> then I'll just use whatever's in Debian's lintian for the debian checks.
[08:45] <cjwatson> shawarma: it's not ideal, but I think it'll be an improveent
[08:45] <cjwatson> s/ee/eme/
[08:50] <shawarma> cjwatson: Indeed. I've just uploaded a new patch to the bug report http://launchpadlibrarian.net/8068335/split_ubuntu_debian.diff
[08:50] <slomo_> pitti: fails in pbuilder :) so it's a build dependency
[08:51] <slomo_> pitti: damn
[08:51] <pitti> slomo_: weird, only on i386?
[08:51] <slomo_> pitti: the doc package is arch all
[08:51] <pitti> slomo_: ah, -doc package
[08:51] <geser> shawarma: more examples: ubuntu-calendar-*, ubuntu-{desktop,standard}
[08:51] <shawarma> cjwatson: It looks weird, because it's the previous ubuntu version mixed the ubuntu and debian checks, and I'm now splitting them entirely again.
[08:51] <shawarma> geser: Yes, and the kernel packages..
[08:51] <slomo_> pitti: any idea what it could be? i don't feel like testing every single of my packages that i have installed :)
[08:52] <pitti> slomo_: still, unless it's some really exotic font, shouldn't gs itself depend on fonts?
[08:52] <cjwatson> shawarma: still looks wrong; -updates and -security should be allowed for Debian
[08:52] <cjwatson> shawarma: hmm, not -updates apparently, sorry
[08:52] <cjwatson> Debian's lintian has:
[08:52] <cjwatson>                        or ($data->{distribution} =~ /\w+-proposed-updates/)
[08:52] <cjwatson>                        or ($data->{distribution} =~ /\w+-security/))
[08:53] <cjwatson> shawarma: so I'm on crack and you can ignore me :)
[08:53] <shawarma> cjwatson: Feel like uploading it?
[08:53] <cjwatson> sure, give me a minute
[08:53] <shawarma> Super. Thanks!
[08:54] <slomo_> pitti: probably :) and i don't think it's exotic... at least it worked with older gs :)
[08:54] <geser> shawarma: there is no -proposed-updates in Ubuntu, only -proposed or -updates
[08:55] <pitti> slomo_: that should be fixed in gs itself then; if you find out the package, please file a bug against ghostscript and milestone it
[08:55] <shawarma> cjwatson: Did you upload it yet?
[08:55] <carlos> Riddell: hi, around?
[08:55] <Riddell> hi carlos 
[08:56] <slomo_> pitti: is something frozen or why can't i just upload the fix? :)
[08:56] <carlos> Riddell: I wonder whether there is any problem with digikam translations
[08:56] <carlos> Riddell: we got .pot updates for Gutsy but no translation updates
[08:56] <pitti> slomo_: oh, sure you can :)
[08:56] <carlos> for Feisty, I think I had to do a manual upload
[08:56] <cjwatson> shawarma: not yet?
[08:57] <cjwatson> shawarma: fixing in place
[08:57] <carlos> Riddell: forget that
[08:57] <carlos> we got them and we imported them too
[08:57] <cjwatson> +                   if ( $data->{distribution} !~ /^(gutsy|feisty|edgy|dapper|breezy|hoary|warty)(-(proposed|updates|backports|security))?$/ ) {
[08:58] <slomo_> pitti: hah! gsfonts could be it... it's only recommended now :) let's test
[08:58] <pitti> cjwatson: is that for something like dpkg-source, or vim?
[08:58] <cjwatson> pitti: lintian
[08:58] <Riddell> carlos: all sorted?
[08:58] <cjwatson> shawarma: uploaded now with that change
[08:58] <pitti> cjwatson: ah, ok; for vim I'd like to have UNRELEASED, too
[08:59] <cjwatson> vim already does AFAIK
[08:59] <shawarma> cjwatson: excellent. thanks.
[08:59] <cjwatson> ICBW
[08:59] <carlos> Riddell: not exactly, Jannick Kuhr says that we have old translations for it
[08:59] <carlos> Riddell: and I thought we didn't import any .po file for gutsy
[08:59] <pitti> cjwatson: UNRELEASED always appears in inverted red in vim, so I guess not
[08:59] <cjwatson> looks like I am wrong
[08:59] <pitti> (but *shrug*, not a biggie at all)
[08:59] <carlos> Riddell: but I just checked our logs and found that we indeed imported the files for Gutsy
[09:00] <pitti> cjwatson: let's just call that a feature then :)
[09:00] <shawarma> pitti: Do we really not want it highlighted that way?
[09:00] <shawarma> pitti: Exactly. I'd rather consider it a feature, actually.
[09:00] <carlos> Riddell: so maybe we imported old files. Is that possible? that we didn't take latest KDE version for the source code in Gutsy?
[09:00] <pitti> shawarma: it could be ... green!
[09:01] <slomo_> pitti: if it is gsfonts shall i really depend on it in gs? :)
[09:02] <cjwatson> pitti: I sort of like it that way. It helps me to remember to un-UNRELEASED it
[09:02] <pitti> slomo_: in earlier days, gs-common pulled it in, so I guess that the lack of a direct depends is just an inadvertent side effect
[09:03] <slomo_> pitti: ok... if it is gsfonts' fault i'll readd it :)
[09:03] <pitti> slomo_: thanks muchly
[09:03] <pitti> slomo_: I'll give back gstreamer tomorrow morning when the new gs is in the archive
[09:04] <slomo_> pitti: thanks
[09:05] <shawarma> pitti: *g* Yes, it could.
[09:07] <cjwatson> iwj: did you ever get anywhere with getting debug output for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393704 ?
[09:08] <ubotu> Debian bug 393704 in openssh-client "interactive client dies on ill-timed SIGWINCH" [Normal,Open]  
[09:13] <slomo_> pitti: yep, works :)
[09:14] <pitti> slomo_: awesome
[09:15] <slomo_> pitti: i love it when guessing works that good ;)
[09:15] <Riddell> carlos: digikam source package seems to contain all the .po files
[09:15] <Riddell> carlos: 0.9.2 was only uploaded at the end of may
[09:16] <Lure> carlos: digikamimageplugins were merged into digikam with 0.9.2 - this means that also translations are now in single file
[09:16] <slomo_> pitti: uploaded :) maybe you can give back gstreamer later today already? :) or are you going to bed soon?
[09:16] <Lure> carlos: digikamimageplugins (0.9.1) was recently removed from archive
[09:17] <carlos> Riddell: yeah, my question is just whether it's up to date or not
[09:17] <pitti> slomo_: binaries will need 2 hours 15 minutes to get into the archive
[09:17] <carlos> Lure: oh, thanks for telling me it that way I don't approve the missing .pot files
[09:17] <slomo_> pitti: ok, then tomorrow :)
[09:17] <pitti> slomo_: at that time I'm probably already asleep, but you can also ask infinity 
[09:21] <Lure> carlos: for refence (if needed): http://mail.kde.org/pipermail/digikam-devel/2007-March/011383.html
[09:22] <carlos> Lure: well, the complain was more related to out dated .po files based on the .pot file that we have imported
[09:33] <Riddell> pitti: is there a way to fix https://bugs.launchpad.net/ubuntu/+source/kde-i18n-nds/+bug/54581
[09:33] <ubotu> Launchpad bug 54581 in kde-i18n-nds "missing language-pack-kde-nds for kde-i18n-nds_4:3.5.4-0ubuntu1" [Undecided,Confirmed]  
[09:33] <Riddell> language-support-nds needs creating, or the recommends removing
[09:34] <pitti> Riddell: hm, it's a valid locale, I wonder why it doesn't exist yet
[09:34] <pitti> Riddell: please assign it to me and milestone it for tribe-2, I'll have a look later
[09:35] <pitti> Riddell: only reason that I can see is that there are no po files for that package
[09:35] <pitti> so it doesn't get created
[09:47] <tepsipakki> mjg59: does xf86-video-avivo use libpciaccess? :)
[09:49] <mjg59> tepsipakki: No comment :)
[09:50] <tepsipakki> mjg59: hey, it was announced already :)
[09:52] <mjg59> Oh, so it was
[09:52] <mjg59> Heh. In that case, yes
[09:52] <mjg59> It's in NEW
[09:55] <tepsipakki> excellent
[09:56] <mjg59> Unaccelerated right now
[09:57] <agoliveira> Is someone there who can give me hand with d-bus? We're trying to figure out a problem here at Montain View.
[09:58] <seb128> agoliveira: you have better chances to get a reply if you actually ask your question
[10:01] <agoliveira> seb128: Sorry, I forgot to send the question itself but I think I got it.
[10:02] <pygi> siretart, I'm back when you're around :)
[10:04] <tepsipakki> mjg59: can't find it from the queue..
[10:05] <mjg59> tepsipakki: Hm.
[10:06] <cjwatson> mjg59: you forgot -sa
[10:06] <mjg59> D'oh.
[10:06] <tepsipakki> :)
[10:06] <mjg59> Probably noobed that with pciaccess as well
[10:06] <mjg59> I'll fix later
[10:06] <cjwatson> looks like it mailed Matthew Garrett <mjg59@codon.org.uk> about it
[10:07] <mjg59> Yeah, got the mail
[10:07] <cjwatson> yes, same problem with libpciaccess
[10:07] <mjg59> Ok. I suck :)
[10:14] <tepsipakki> mjg59: I could push the packaging to git.d.o
[10:14] <tepsipakki> ..tomorrow
[10:15] <tepsipakki> bryyce: did you read the announcement on xorg@l.fd.o? :)
[10:16] <bryyce> no (dealing with a raid failure this morning) which one?
[10:16] <bryyce> ah, the r500 announcement
[10:19] <bryyce> tepsipakkii, very cool :-)
[10:23] <tepsipakki> yeah
[10:36] <pitti> seb128: apport-retrace just closed its very first bug as duplicate automatically
[10:36] <pitti> desrt: bah, I want to get this finished
[10:36] <seb128> pitti: waouh ;)
[10:36] <seb128> pitti: which one?
[10:37] <pitti> seb128: just a test bug, nothing interesting yet
[10:37] <seb128> k
[10:37] <pitti> seb128: gutsy doesn't give us crashes, so I have to file my own :)
[10:38] <pitti> and the dup detection will only automatically work for newly filed crashes
[10:38] <pitti> mneptok: :(
[10:38] <pbn> heh duplicate hugs
[10:38] <pbn> not bugs, hugs
[10:38] <seb128> pitti: rock on ;)
[10:38] <mneptok> pitti: the LTS hug from last June still gets critical updates
[10:40] <mneptok> you and me both.
[10:40] <pitti> lol
[10:40] <mneptok> not a dupe!
[10:41] <pitti> yay!
[10:41] <mneptok> 2 g's! not a dupe!
[10:43] <pygi> seb128, are you around?
[10:45] <seb128> pygi: sort of, going to stop the computer soon, why?
[10:46] <pygi> seb128, just wanted to discuss one tiny thing
[10:46] <seb128> sure ;)
[10:46] <pygi> seb128, I think we should open iso files with nautilus-cd-burner by default instead of file-roller
[10:46] <pygi> imho it's completely weird and unexpected behaviour
[10:46] <seb128> good idea
[10:46] <xhaker> crimsun, you there?
[10:47] <pygi> seb128, what exactly do we need to patch to do that?
[10:52] <seb128> pygi: need to change the defaults.list, I've just uploaded a new desktop-file-utils with the change
[10:56] <gnomefreak> is Ubuntu Installer an automatic accept/decline for NEW packages?
[10:56] <crimsun> xhaker: yes
[10:57] <xhaker> ati sb450 regression from feisty 15 -> 16
[10:57] <crimsun> xhaker: I need your alsa-info.sh url/output
[10:58] <crimsun> (http://www.linux-sound.info/alsa/index.php?task=scripts)
[10:58] <pygi> seb128, ok, thank you :)
[10:58] <seb128> pygi: you're welcome
[10:58] <xhaker> will do crimsun.. 
[10:58] <pygi> seb128, imho much better now, and sorry for bugging ;)
[10:58] <crimsun> xhaker: this belongs in #ubuntu, or open a query, please
[10:59] <seb128> pygi: no problem, thank you for pointing it, it's better this way indeed :)
[11:00] <pygi> seb128, ^_^
[11:04] <mikmorg> does anyone know where i can find the Casper project source?
[11:04] <pitti> mikmorg: 'apt-cache show-src casper' claims Vcs-Bzr: http://bazaar.launchpad.net/~ubuntu-core-dev/casper/trunk
[11:05] <mikmorg> pitti: Thanks a million :)
[11:05] <pitti> which should really be https://code.launchpad.net/casper/trunk nowadays
[11:06] <mikmorg> seems there is an issue with my driver update deb not loading
[11:06] <mikmorg> from the wiki, i assume the loader is part of casper itself, not ubiquity
[11:41] <mikmorg> \
[11:43] <mikmorg> does ubiquity lay on top of casper, or vice versa?
[11:43] <mikmorg> i'm very confused by some of the things i'm seeing :/
[11:44] <evand> mikmorg: casper sets up the environment for ubiquity
[11:44] <mikmorg> evand: ok, that helps. thanks.
[11:45] <superm1_> evand, jetsradiem had been talking to you about a possible merge up of mythbuntu ubiquity changes if we cleaned them up to be more modular.  I havent spoken to him in a few days, what eventually came of that?
[11:47] <evand> superm1_: Ubiquity isn't really set up for accepting such merges (that is, items that are not going to be the default), but I told him I'd look over the mythbuntu code
[11:48] <superm1_> evand, Well my thought was having a third UI for us available, mythbuntu-ui that was a child based upon gtk-ui so as to not break things.  if the main ubiquity start script received something like ubiquity --mythbuntu then we could be started, otherwise follow as normal
[11:49] <superm1_> and then we could use our own glade file and still be able to source all normal functions that are part of gtk-ui and still get all the partitioning changes that are going in
[11:49] <superm1_> and override as necessary for our things
[12:01] <evand> hrmm, you still have the problem of keeping things in sync, but that might be easier now that everything is built off of BaseFrontend.
[12:01] <evand> cjwatson: thoughts?
[12:02] <evand> erm, ignore most of what I just said.  I wasn't thinking.  It's still an interesting idea though.
[12:04] <superm1_> evand, there are a few items that would still need to be sorted out if we did it that way (install.py has a few changes specific to us)
[12:05] <superm1_> I'm a bit new to inheritance in python, but if its like C, I would imagine that the derived class would be able to override the base class functions (and hence override things like say a run() function that would normally be in gtkui.py.  things wouldn't be too bad to keep in sync then I dont think)
[12:06] <pitti> superm1_: sure, you can override methods in Python classes
[12:07] <evand> superm1_: take a look at frontend/base.py in Ubiquity for a rough idea.
[12:09] <mikmorg> ok, after reading source for a while.. i'm officially stumped with my driver update deb
[12:09] <superm1_> evand, ah then this would be a functional way for us to do things that are overridden in gtk-ui.py.  If we followed the same methodology with overriding the Install class in install.py, this could be feasible
[12:10] <superm1_> evand, have you looked over the types of changes that we have yet in a debdiff or no?
[12:11] <evand> superm1_: I glanced over the code briefly.  I'll take a much more thorough look tomorrow, though.
[12:11] <evand> hopefully
[12:11] <mikmorg> i have a disk with /ubuntu-drivers/2.6.20/tg3_i386.deb which i need to use with Feisty. If I insert the disk when told, and enter the live environment, and type dpkg -i /var/cache/driver-updates/tg3_i386.deb, it installs perfectly. However, casper is not installing it automatically as it is supposed to..
[12:12] <superm1_> evand, i'll make a clean debdiff ( I just merged to your 1.5.3 release yesterday
[12:12] <mikmorg> Is anyone familiar enough with casper to help me with this issue?
[12:12] <superm1_> i'll give you a link in a few minutes 
[12:12] <evand> superm1_: thanks