[12:20] <paul_d> wish bug status is gone?
[12:21] <gnomefreak> paul_d: no
[12:21] <gnomefreak> i just marked one as a wishlist like 10 minutes ago
[12:22] <paul_d> maybe inaccessible to bug squad?
[12:23] <gnomefreak> paul_d: you have to be part of the qa team please continue this in #ubuntu-bugs
[12:26] <bdmurray> paul_d: yes, you need to be in ubuntu-qa to set bug importance
[12:26] <sladen> pitti: there's broken issues with gdb at the moment on 2.6.?? kernels
[12:28] <sladen> pitti: google for "Failed to read a valid object file image from memory."
[01:31] <bdmurray> sladen: what is the status of bug 32150?
[01:31] <ubotu> Launchpad bug 32150 in acpi-support "/etc/acpi/hibernate.sh should bail out if /sys/power/resume is 0:0" [Medium,Incomplete]  https://launchpad.net/bugs/32150
[01:47] <sladen> bdmurray: I've assigned it to me, I suspect it might actually want to go into pmi instead
[01:48] <sladen> or even both
[01:48] <bdmurray> sladen: okay thanks!
[01:48] <bdmurray> it ended up on the list of hug day bugs
[01:49] <sladen> bdmurray: oooh, funky.  It is a year old
[01:49] <bdmurray> well, I / we've been trying to do some cleanup
[02:04] <bathym> hi gang
[02:09] <rproenca> hi mpt, I just replied by email your comment at my blog
[02:42] <mpt> oh wait, he/she replied by e-mail
[02:42] <enrico> fabbione: I've uploaded in Debian a new libept that should work on sparc as well as ia64 and hppa
[02:43] <pygi> mpt, he
[02:45] <mpt> yes, found it :-)
[02:47] <Detron> Hi. I'm a software engineer, and I'd like to help Ubuntu out. Any pointers?
[02:49] <crimsun> https://wiki.ubuntu.com/MOTU/Contributing
[02:49] <RAOF> Detron: Depends on what you want to do.  Just helping out an upstream project (Gnome, KDE, whatever) helps us.
[02:49] <RAOF> Or you can listen to crimsun :)
[02:50] <Detron> hmm.
[02:51] <RAOF> Basically, if you want to code, find (or found) a project that interests you and start contributing (patches to fix bugs, new features, etc).
[02:51] <Detron> Probably would be best to help out an upstream project. I've had my eye on Network Manager. Wireless support is the only thing holding me back laptop wise.
[02:52] <Detron> Ideally I'd like to switch back to linux entirely once my 3 year update cycle hits again.
[02:54] <RAOF> Go for network manager :).  Although what it does now, it does pretty well (and support now seems limited by wireless drivers rather than n-m bugs), but there's some cool stuff to work on there (connection sharing, multiple active devices, networking-before-login).
[02:55] <Detron> I'll probably try to work on a variety of projects. Unfortunately I'm interning this summer and the apartment the company provided doesn't offer internet (and it's silly to try to get broadband set up for a month).
[02:55] <crimsun> http://www.gnome.org/projects/NetworkManager/developers/
[02:55] <Detron> It's painful using linux without apt-get...lol.
[02:55] <Detron> yup, there now.
[02:56] <crimsun> you'll also want to speak with Lure, asac, and giskard.
[02:56] <crimsun> they've touched it recently in Ubuntu.
[02:56] <Detron> Alright.
[02:58] <Detron> Do you know if they've decided to drop PPC support or what? I'm grabbing an iso now that's fiesty ppc.
[02:58] <Detron> Or is it community supported now?
[02:58] <RAOF> Community supported.
[02:58] <Detron> bummer.
[02:58] <Detron> Guess it makes sense though.
[03:15] <vlowther> /who BenC
[03:27] <mjg59> iwj_: Have you confused glx and xgl?
[04:07] <pdenapo> Hi, I would like to attract your atention
[04:07] <pdenapo> to an issue that has been reported a long time ago
[04:07] <pdenapo> that ubuntu cannot detect a serial mouse
[04:07] <RAOF> bug #?
[04:07] <pdenapo> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/9068
[04:07] <ubotu> Launchpad bug 9068 in xorg "Serial mice are not autodetected" [Medium,Confirmed]  
[04:08] <pdenapo> I think this issue is very important for usability
[04:08] <pdenapo> Advanced user like myself can edit the xorg.conf file by hand
[04:08] <pdenapo> and kill the X server process
[04:08] <pdenapo> but we cannot ask this to newbbies
[04:09] <pdenapo> it is not acceptable in a distribution intended to be user-friendly for non-technical users
[04:09] <pdenapo> I would suggest to add an option to use a serial mouse
[04:09] <pdenapo> at boot time
[04:10] <pdenapo> Otherwise, if autodection fails, the live CD is useless
[04:11] <pdenapo> computers with serial mouse are still common in undeveloped countries I think
[04:11] <pdenapo> and Ubuntu is supposed to suport them
[04:16] <RAOF> So, (as someone who's not even a MOTU) it seems that what that bug is waiting for is for someone to offer a full solution.  So, the problem seems to be "autodetection cannot work"
[04:17] <pdenapo> I really don't know, Knoppix for example works fine with serial mouse. I don't know how they do that
[04:18] <pdenapo> seems to be an mdetect problem
[04:18] <pdenapo> But I think that autodetection is great when it work
[04:19] <pdenapo> but it is catastofic when it fails
[04:19] <pdenapo> so it is not good to depend on it at 100% for something critical
[04:20] <pdenapo> that results in imposibility to use the system
[04:20] <pdenapo> so I suggest to provide a way to by pass it
[04:21] <RAOF> There already is, right?  There's manually editing xorg.conf, and I think that dpkg-reconfigure will offer mouse options.
[04:23] <Chipzz> pdenapo: serial mice were uncommon 8 or 9 years ago ;)
[04:24] <Chipzz> pdenapo: everything above 486, and some 486's use ps/2 instead of serial
[04:24] <Chipzz> and you really don't want to run ubuntu on that kind of hardware I think ;)
[04:25] <Chipzz> (Xubuntu maybe; big maybe though)
[04:25] <RAOF> I think the reason why that bug isn't fixed is that its not obvious how to fix it.  The best solution offered seems to be "check whether any mice are detected, and if not assume serial", but it seems that there are different variants of serial-protocols, and it's not possible to autodetect them.
[04:28] <pdenapo> I'm runnig an AMD athlon K7 with serial mouse!
[04:28] <pdenapo> (My PS/2 port is broken)
[04:28] <pdenapo> I insist, if no autodection is possible,
[04:29] <pdenapo> just offer an option to select at boot time
[04:29] <pdenapo> like you do with other special hardware
[04:29] <RAOF> Um, do we?
[04:30] <RAOF> So what exactly is your solution?  You start the LiveCD and... ?
[04:30] <evand> pdenapo: Are you suggesting a new line in isolinux ("Start with serial mouse support"), or a kernel parameter?
[04:31] <LaserJock> I'm guessing kernel parameter
[04:31] <pdenapo> a kernel parameter would be enougth
[04:31] <pdenapo> to pass to the init scripts
[04:32] <LaserJock> although I don't know if that really accomplishes much
[04:32] <pdenapo> I thik this is already done for some hardware
[04:32] <RAOF> It doesn't sound much easier than editing xorg.conf
[04:32] <pdenapo> for some laptops for example
[04:32] <LaserJock> yeah
[04:32] <RAOF> pdenapo: You're thinking of the "noapci", etc, yes?
[04:32] <pdenapo> I'm not sure
[04:33] <pdenapo> I think there are options for some toshiba laptops
[04:33] <pdenapo> for example
[04:33] <pdenapo> but I see this is perhaps not intuitive for end-users
[04:33] <pdenapo> anyhow seems to be easier than editing xorg.conf and killing a process
[04:34] <pdenapo> specially if you have to do that every time you boot the live CD
[04:34] <LaserJock> but you have to set the kernel paramater everytime
[04:35] <LaserJock> seems like documenting using dpkg-reconfigure would be the best way
[04:36] <pdenapo> perhaps
[04:38] <Chipzz> pdenapo: actually I think your case of a blown up ps2 port is extremely uncommon; also, there's a difference between an isolinux option to work around broken chipsets, and an option to work around broken hardare (ie, you broke the hardware, we're not expected to supported that, ergo it is not unreasonable for you to edit Xorg.conf and kill the relevant processes)
[04:38] <Chipzz> but that's just my 2 cents
[04:39] <Chipzz> the problem is
[04:39] <Chipzz> serial does not provide any way at all to probe what hardware is behind it
[04:39] <Chipzz> USB does
[04:40] <pdenapo> Chipzz: So your idea is that serial mouse is something out of date, even if modern computers still can work with them?
[04:40] <Chipzz> and PS2 only has mice and keyboards
[04:40] <Chipzz> pdenapo: not only my idea; most current motherboards do not even *have* a serial port anymore
[04:40] <pdenapo> I think that an SO should support all the hardware available
[04:40] <Chipzz> pdenapo: and you have to look real hard to even *find* a serial mouse
[04:41] <Chipzz> let me tell you, I actually looked for a serial mouse 8 years ago; the only thing I could find were ps/2 mice with a ps/2 -> serial convertor
[04:41] <pdenapo> I'm really disapointed with ubuntu
[04:42] <pdenapo> I should say, because of this issue
[04:42] <Chipzz> pdenapo: but again, I'm not a developer, and it's just my 2 cents
[04:42] <pdenapo> I cannot pass it to a friend and tell him for sure
[04:42] <pdenapo> that it will work for him
[04:42] <LaserJock> pdenapo: well, you can ask him if he has a serial mouse
[04:43] <RAOF> But you never can.  Theres a bunch of hardware that we don't support well.
[04:43] <LaserJock> and if so point him in the right direction anyway
[04:43] <pdenapo> but believe me, here in Argentina, are still common
[04:43] <pdenapo> ok, we still have many old computers
[04:43] <LaserJock> pdenapo: I'm not saying we shouldn't support serial mice, I'm just saying that all is not lost
[04:43] <LaserJock> there doesn't seem to be a straightforward way to fix the issue
[04:44] <Chipzz> anyway, the issue at hand is that you *cannot* probe serial mice; you have to try all protocols, some of which conflict with each other, and there's no way to tell if the protocol you're testing actually works apart from moving the mouse and not see it jump around on the screen
[04:44] <LaserJock> as it is inherently difficult to automatically detect hardware that doesn't have automatic detection
[04:45] <pdenapo> There would be no problem
[04:45] <pdenapo> if anyhow you had an usable desktop
[04:45] <LaserJock> well, the point is that we can't necessarily give a person that
[04:45] <pdenapo> but the mouse seems to be critical in order to be able to use the desktop
[04:45] <LaserJock> from what it sounds
[04:47] <Chipzz> pdenapo: anyway, for the sake of argument, lets say an option to ""detect"" serial mice was included; your friend would still have to pick a protocol from a list of over 10 different protocols, and he wouldn't know what to pick. How is that any better?
[04:48] <pdenapo> I don't know, I just wanted to rause your attention on this issue because I thimk that it is important
[04:49] <pdenapo> but I really don't know the optimal solution
[04:50] <RAOF> Which is why it hasn't been fixed yet :)
[04:50] <pdenapo> perpaps in the mean-time, documenting how to use dpkg
[04:50] <pdenapo> -reconfigure
[04:51] <pdenapo> in the release notes would be the more reasonable thing to do
[04:51] <Chipzz> the only alternative show a dialog on X startup among the lines of: you specified you have a serial mouse; we cannot autodetect this, but this is the list of protocols we already tried, and we're currently testing protocol X. Try moving your mouse around, and if it moves around correctly, press Yes, or press esc if it jumps around.
[04:51] <Chipzz> and if the user presses esc restart X and try with next protocol
[04:51] <LaserJock> pdenapo: something like https://help.ubuntu.com/community/SerialMouseHowto
[04:52] <StevenK> Chipzz: That sounds like an awful lot of work.
[04:53] <Chipzz> StevenK: I didn't say we should implement that; but I think it's the "most userfriendly" option available at all ;)
[04:53] <pdenapo> another question: why there is no section "how to install Ubuntu" in the oficial docmentation https://help.ubuntu.com/
[04:53] <pdenapo> ?
[04:53] <Chipzz> that is, if the user only has one serial port (because you don't know which serial port the mouse is attached to otherwise, and again, there is no way to tell...)
[04:54] <LaserJock> pdenapo: the idea is there shouldn't need to be one
[04:54] <pdenapo> I think it is the first thing that the user will search gor..
[04:54] <pdenapo> for...
[04:54] <pdenapo> (sorry)
[04:55] <pdenapo> But issues like this shows that might be necesary...
[04:55] <pdenapo> if the user has some hardware that won't be autodetected
[04:55] <Chipzz> the only alternative I guess is to hope X can make better guesses wrt serial mice in the future, and just rely on that
[04:55] <pdenapo> he needs to be aware of
[04:56] <pdenapo> Another minor usability issue: I've seen that for ADSL conections
[04:56] <pdenapo> there is the ppoeconf utility
[04:56] <pdenapo> that works fine, but knoppix has a similar utility with a nicer GUI
[04:56] <pdenapo> perhaps you want to take a look
[04:58] <poningru> whats the name?
[05:06] <pdenapo> Sorry I don't know the name
[05:07] <pdenapo> I was searching in google
[05:07] <pdenapo> is the same utility but with a Qt based GUI
[05:07] <pdenapo> it would be nicer to have something like this in Ubuntu
[05:15] <wolfeon> argh.
[05:15] <wolfeon> well I gues I should ask motu first :)
[05:17] <pdenapo> well everybody thank you very much for your listening, good bye
[06:07] <fabbione> enrico: ok cool
[07:12] <dholbach> good morning
[07:12] <pygi> morning dholbach 
[07:15] <poningru> as in what his nick is
[07:15] <StevenK> pitti
[07:16] <poningru> grr guess he isnt here
[07:16] <Hobbsee> correct
[07:16] <Hobbsee> he does sleep occasionally
[07:16] <Hobbsee> poningru: what did you need?
[07:16] <pygi> Hobbsee, correct
[07:16] <pygi> good morning
[07:16] <poningru> well to the release people: almost done with release notes, will finish up kernel stuff tomorrow after bugging them
[07:17] <poningru> Hobbsee: just needed extra eyes over https://wiki.ubuntu.com/GutsyGibbon/Testing/Tribe2
[07:17] <Hobbsee> poningru: right.  looking
[07:18] <poningru> Hobbsee: havent finished kernel stuff
[07:19] <Hobbsee> poningru: please dont refer to it as malone
[07:19] <Hobbsee> Gutsy Gibbon has bugs! (I bet you're not surprised). Your comments, bug reports, patches and suggestions will help fix bugs and improve future releases. Please report bugs through [WWW]  Malone
[07:19] <Hobbsee> poningru: please use "the ubuntu bugtracker"
[07:19] <poningru> k
[07:20] <pygi> Hobbsee, let's first bug we know of :)
[07:20] <pygi> there's enough of those :)
[07:20] <Hobbsee> hehe
[07:20] <pygi> ;)
[07:21] <Hobbsee> poningru: s/by gnu just/by the GNU project/
[07:22] <poningru> Hobbsee: err I was instructed to use that... by the gnu people
[07:22] <StevenK> It auto detects if the system is capable of runing compiz and if not the "metacity" window manager is used. -> "It auto detects if the system is capable of runing compiz and if not, falls back to using the "metacity" window manager." ?
[07:22] <Hobbsee> poningru: ahhh okay
[07:22] <Hobbsee> poningru: i just checked their website, and saw the other version
[07:22] <poningru> yeah I asked them specifically because of that
[07:22] <Hobbsee> poningru: neat.  taht's fine :)
[07:22] <poningru> though the capitalization is something I didnt ask
[07:23] <poningru> StevenK: k
[07:23] <poningru> sounds better
[07:24] <poningru> ok going to sleep nn and please continue editing
[07:26] <StevenK> Yeah, Bart found that Compiz doesn't talk when you Alt-Tab between windows.
[07:27] <TheMuso> StevenK: Ah ok, so it does get enabled.
[07:27] <TheMuso> Will have to work on a fix for that post tribe 2.
[07:27] <fabbione> hmmmm
[07:27] <fabbione> i wonder why "Move to another workspace" doesn't work properly anymore
[07:27] <Hobbsee> poningru: s/Allowing the users /Allows the users/ .  Or fix the other tenses, etc.
[07:27] <fabbione> it works once and then stop
[07:28] <StevenK> TheMuso: Oh sorry, that was for Feisty. Not sure if it's the case for Gutsy.
[07:28] <TheMuso> StevenK: Ah ok. Will have a look in a while.
[07:59] <fabbione> cjwatson_, evand: i would like to upload os-prober after tribe2 to fix a stupid bug on sparc that would spawn (only in certain partition layouts) an extra entry (see #122756). The fix is already in bzr.
[09:01] <pitti> Good morning
[09:01] <fabbione> hey pitti
[09:02] <fabbione> pitti: sparc-server 27 tested.
[09:02] <fabbione> pitti: all good.. 2 minor bugs tho
[09:02] <fabbione> pitti: one sparc, one generic
[09:02] <dholbach> hey pitti!
[09:02] <pitti> fabbione: yay, any problems?
[09:02] <fabbione> pitti: nothing major. and one has a fix in bzr already. waiting main to open to upload
[09:03] <pitti> fabbione: good to hear that the kernel issue is fixed at least :)
[09:03] <Hobbsee> morning pitti!
[09:03] <Hobbsee> pitti: i've just discovered the most gorgeous set of icons in the world :)
[09:03] <fabbione> pitti: yeah that too.. 
[09:04] <pitti> Hobbsee: :)
[09:04] <Hobbsee> pitti: http://everaldo.com/crystal/?action=preview :)
[09:05] <pitti> hello StevenK!
[09:05] <pitti> Hobbsee: schweeeeet
[09:05] <Hobbsee> pitti: oh yes.  oh yes.  this is kubuntu-default material, when a package is made :)
[09:25] <Hobbsee> :)
[09:31] <mvo> hey pitti :)
[09:32] <gnomefreak> mvo and pitti the bugs i filied i may close in next few days since i reinstalled and nothing has crashed nor has frozen so something on my system was messed up
[09:33] <fabbione> dholbach: ping?
[09:33] <pitti> gnomefreak: the ones about crashing compiz?
[09:34] <gnomefreak> pitti: yes and gnome-appearance and apport-gtk crash
[09:35] <pitti> gnomefreak: sweet
[09:38] <pygi> dholbach, you're spamming me :P
[09:42] <pitti> LaserJock, ogra: can you, or do you know someone who can give edubuntu server/i386 some testing?
[09:44] <pygi> hey phoenix24 
[09:44] <phoenix24> hey pygi 
[09:44] <stgraber> pitti: I'll once at home, if 11:30 CEST isn't too late for you
[09:45] <pitti> stgraber: no, that's fine; thank you!
[09:46] <pitti> stgraber: maybe ogra already tested them and just didn't report the results yet, let's wait for him as well
[09:48] <stgraber> pitti: Last time I checked we had bug 121547
[09:48] <ubotu> Launchpad bug 121547 in ltsp "[Gutsy]  LTSP chroot building process hangs at 50% on Tribe1 CD" [Undecided,Confirmed]  https://launchpad.net/bugs/121547
[09:48] <stgraber> (debian-installer had some problem with the new squashfs ltsp image)
[09:50] <pitti> stgraber: erk; that sounds, like, RC?
[09:52] <StevenK> pitti: No fair listing cruft if the replacement hasn't cleared NEW yet. :-P
[09:53] <pitti> StevenK: heh :)
[09:53] <dholbach> fabbione: pong
[09:54] <nixternal> I am creating a package for an icon them, the root dir has no license file, the website the package is from states it is lgpl. how do I go about packaging this correctly/legally? put the LICENSE file in the debian/ dir and add it to the debian/docs file, create a patch to add the LGPL file to the root dir?
[09:54] <dholbach> pygi: you could have set those bugs to 'incomplete' yourself ;-)
[09:55] <pygi> dholbach, that's not an excuse :) Just leave the cd-recording bugs to me if you want, I can handle mostly :) Also, I'll take some time next week to look over telepathy bugs
[09:55] <StevenK> nixternal: Sounds like what Hobbsee was talking about.
[09:55] <pygi> perhaps I can sort something out ... not as knowledgable in that area, but ...
[09:56] <nixternal> hehe
[09:56] <dholbach> pygi: thanks - that nice of you
[09:56] <nixternal> I asked her first and she said ask here :)
[09:56] <pygi> dholbach, if you don't mind ofcourse ^_^
[09:56] <dholbach> pygi: just mark them as 'incomplete' if you ask for more info
[09:56] <pygi> dholbach, ofcourse :) Sorry, closed 50 bugs in two days, that was too much :)
[09:56] <pygi> well, fixed some, and stuff =)
[09:57] <dholbach> no problem :)
[09:57] <dholbach> good work
[09:57] <pygi> heh, don't tell me good work
[09:57] <pygi> tell it to yourself and every else here :)
[10:03] <fabbione> dholbach: hey dude.. i am having a problem with gnome i think.. just wondering if it's known already.. basically any window i open, the "Move to anotehr workspace -> Desk N" doesn't work
[10:04] <fabbione> dholbach: this is gutsy very latest bla bla bla
[10:04] <dholbach> fabbione: is that with compiz?
[10:04] <fabbione> dholbach: how can i help to look into this?
[10:04] <fabbione> dholbach: i didn't enable compiz myself.. let me check
[10:04] <dholbach> ps afxvw | grep compiz
[10:04] <pygi> fabbione, compiz is auto-enabled
[10:05] <fabbione> dholbach: no compiz
[10:05] <pygi> if hardware supports it AFAIK
[10:05] <fabbione> dholbach: the "Desktop effects" confirm that it is not enabled
[10:05] <fabbione> pygi: i already had compiz before the switch and manually switched it off..
[10:05] <dholbach> alright, because compiz has lots of known issues with workspaces/viewports
[10:05] <fabbione> pygi: if my settings have been changed, that'd be another serious bug
[10:06] <dholbach> does it work with a new user? (you could test in gdmflexiserver --xnest)
[10:06] <pitti> fabbione: confirmed (with metacity)
[10:06] <pitti> dholbach: ^
[10:06] <fabbione> pitti: ok thanks.
[10:06] <dholbach> pitti: weird - it works nicely for me
[10:06] <dholbach> pitti: do you know the bug number? if not, I'll look it up myself
[10:06] <pitti> dholbach: it stopped working a few days ago, but I didn't find the time to report it yet
[10:06] <fabbione> pitti: i noticed only yesterday with a few windows.. after a logout/login all of them
[10:06] <fabbione> so i want to believe it's some library that did change
[10:07] <pitti> dholbach: 'move one workspace right' works, but not 'move to nth workspace'
[10:07] <fabbione> dholbach: i didn't report it either.. wanted to check with you first to spare you a dupe
[10:07] <fabbione> pitti: confirmed that too
[10:07] <dholbach> pitti: move to workspace n works for me
[10:07] <dholbach> I just tried xchat-gnome and gnome-terminal
[10:07] <fabbione> dholbach: even more than once?
[10:07] <pitti> dholbach: I want the fix, too
[10:07] <pitti> dholbach: do you use compiz?
[10:08] <fabbione> dholbach: sometimes it did work the first time and stopped at the second
[10:08] <dholbach> pitti: no
[10:08] <dholbach> fabbione: yes
[10:09] <dholbach> it's broken with compiz
[10:09] <pitti> well, compiz breaks *everything* wrt. workspaces, that one is the least of all evils :)
[10:11] <dholbach> no ubuntu bug filed yet - I'll look for upstream bugs
[10:14] <dholbach> hrm... b.g.o seems down
[10:16] <Admiral_Chicago> pitti: release notes are done to a level i am satistied with
[10:16] <pitti> Admiral_Chicago: thanks for putting this together!
[10:17] <Admiral_Chicago> no problem. good luck on the release. i need sleep now
[10:21] <pitti> seb128: did you see something like this in yesterday's apport tests: "warning: Memory read failed for corefile section, 4096 bytes at 0xffffe000." ?
[10:23] <seb128> pitti: "<seb128>	Test add_gdb_info() with a script. ... Failed to read a valid object file image from memory."
[10:23] <seb128> pitti: "<seb128>	warning: Memory read failed for corefile section, 4096 bytes at 0xffffe000."
[10:23] <seb128> "<seb128>	FAIL: Test add_gdb_info() with a script."
[10:23] <seb128> 
[10:23] <seb128> that's from yesterday evening
[10:24] <pitti> seb128: that very; was this on a live CD or your production system? IOW, did you have build-essential installed?
[10:24] <seb128> on my desktop
[10:24] <seb128> and it has everything required to build the GNOME stack
[10:24] <pitti> seb128: ok, so that's not it; I got some logs to bug 122688, and one didn't have libc6-dev installed, but that memory read error was on all of them
[10:24] <ubotu> Launchpad bug 122688 in gnome-speech "produces empty core dumps" [Undecided,New]  https://launchpad.net/bugs/122688
[10:25] <pitti> seb128: something is fundamentally wrong on i386; I guess I just have to do an i386 installation to figure this out
[10:25] <pitti> seb128: at least I perfectly reproduced the symptoms of the bug reports; it's really from 0-byte core dumps (as opposed to some wrapping/formatting bugs in apport)
[10:26] <pitti> seb128: so I'll (1) make apport not create reports for those, and (2) install i386 to find out why that happens 
[10:27] <seb128> pitti: I can do remote debugging for you if you want or try to make some forwarding and create you an account if that's easier than doing an install
[10:27] <pitti> seb128: install should be fine
[10:49] <_spin> how difficult is it to join the team and start fixing bugs?
[10:50] <pitti> _spin: not at all; we specifically maintain a list of bugs which are easy to fix, for new contributors
[10:50] <pitti> _spin: in principle, you can always attach patches to bugs; this is heavily appreciated
[10:51] <_spin> how does the integration process work?
[10:51] <pitti> _spin: after patching a bug you should contact a developer about applying it; you can mail the maintainer (if there is one), or generally just ask in #ubuntu-motu
[10:52] <pitti> _spin: people in #ubuntu-motu should be able to direct you to the appropriate person, or just upload it themselves
[10:52] <pitti> _spin: and when you learned the Ubuntu specific processes, you can become a developer yourself
[10:53] <pitti> _spin: https://wiki.ubuntu.com/HelpingWithBugs and https://wiki.ubuntu.com/UbuntuDevelopment are good entry points for learning more
[10:54] <cjwatson> fabbione: sure, though please commit it upstream as well if you haven't already
[10:55] <fabbione> cjwatson: sure i can do that, but silo-installer in Debian doesn't use os-prober yet.. 
[10:57] <_spin> pitti: thanks for the help
[10:58] <pitti> you're wel... disappeared already
[10:58] <cjwatson> fabbione: you could commit that too while you're at it ;-)
[11:00] <fabbione> cjwatson: ok.. i guess i will need to show up on #debian-installer again
[11:01] <cjwatson> (that's #debian-boot)
[11:01] <fabbione> yeah noticed :)
[11:16] <geser> pitti: Hi. I started looking at the rdepends for apache. The order of alternatives doesn't matter, right? So something like "Depends: ..., apache-common | apache2-common | apache2.2-common, ..." is no problem?
[11:17] <pitti> geser: right
[11:17] <pitti> geser: it's not ideal, but works
[11:17] <pitti> geser: and they'll eventually be fixed in Debian
[11:18] <geser> that's my hope too
[11:18] <geser> the first blocker I found is slash, Debian bug #429071
[11:18] <ubotu> Debian bug 429071 in slash "please update/request removal of your package" [Serious,Open]  http://bugs.debian.org/429071
[11:28] <iwj> mjg59: Yes.
[11:32] <Keybuk> Nafallo: "start" :-)
[11:34] <Nafallo> Keybuk: something like that.
[11:35] <Nafallo> :-)
[11:36] <ajmitch> geser: yes, there are plenty of bugs filed in debian, I've found a few that can just be synced
[11:37] <ajmitch> see the rc bugs list that I generated, a few of them are apache-related
[11:50] <stgraber> pitti: starting edubuntu i386 server testing now, you should have the result in something like 30 minutes
[11:51] <pitti> stgraber: great! wow, that's fast
[11:54] <iwj> Hmm.  I wonder if I'm just unlucky with this i810-based board, or whether VC switching is generally not reliable nowadays.
[11:55] <sladen> iwj: i810-based board with an ATI video chip sitting on it?
[11:56] <pitti> iwj: I have problems when using composite (switchign back to X -> black screen and hang), but not with metacity
[11:57] <pitti> seb128: I might have an idea about apport: I just use a single read() call for reading the core from stdin; if the kernel isn't fast enough, this delivers 0 bytes and I stop reading
[11:57] <iwj> sladen: Err, no, the i810's built in graphics.  I assume it's actually intel; at least none of the logs etc. say anything about ATI.
[11:58] <pitti> seb128: this has never actually caused any trouble with 2.6.20, but maybe some internal stuff changed in .22 to make it more prone to race conditions
[11:58] <iwj> pitti: Hmm.  Maybe I should turn off compositing and see if that helps.
[11:58] <seb128> pitti: ah
[11:58] <pitti> seb128: I just committed some patches which ignore 0-byte core dumps as a bandaid
[11:58] <seb128> ok, good
[11:58] <pitti> seb128: after tribe-2 I'll write a test case for delayed stdio feeding, fix problem_report accordingly and upload
[11:59] <pitti> seb128: of course we'll don't see empty cores any more anyway, but it might help
[11:59] <pitti> seb128: but I don't want to rebuild CDs for that TBH; let's rather clean up the broken bugs automatically (I'll write a script); do you agree?
[12:00] <seb128> pitti: yeah, no need to roll new CD, I want to unfreeze so we can work again now :p
[12:00] <pitti> seb128: feel free to upload stuff, it'll pile up in the queue
[12:00] <stgraber> heno: didn't you see a bug with the "You are here" path on the tracker ? it seems it doesn't show the testcase part when you are on the test results list ...
[12:01] <seb128> pitti: right, I don't like to pile too many changes though, I prefer progressive testing ;)
[12:01] <stgraber> heno: this function will definitely need a big rewrite :), it was ugly but at least it worked which seems to be no longer the case :)
[12:02] <heno> stgraber: indeed, I've been making a list :)
[12:03] <stgraber> I've also the "milestone report" drop-down menu which should show the current milestone by default rather than the first (sorted by name), will add the _getpath function in my need a quick fix todolist :)
[12:03] <pitti> ogra: here?
[12:04] <ogra> pitti, i tested all former isos, but not the current one, thats currently running
[12:04] <pitti> ogra: ah, ok; you are testing edubuntu/i386?
[12:04] <pitti> ogra: server, I mean?
[12:04] <ogra> yep
[12:04] <sladen> iwj: actually, I was looking at a machine yesterday with Intel graphics and VC switching issue.  The solution was to C-M-F7 C-M-KP- C-M-KP+  to flip the mode and back again
[12:04] <pitti> ogra: stgraber does as well, maybe you can coordinate
[12:05] <ogra> sure
[12:05] <pitti> ogra: well, autoresize etc. is already covered by the other ISOs, so I guess there's no need to test every variant
[12:05] <pitti> ogra: thanks *hug*
[12:05] <ogra> :)
[12:05] <stgraber> ogra: It's currently installing the desktop packages on an "erase all" install
[12:06] <pitti> asac: https://wiki.ubuntu.com/GutsyGibbon/Testing/Tribe2 calls the ffox 3 alpha 'Minefield'; I thought this was 'Gran Paradiso'?
[12:06] <ogra> stgraber, there is one ltsp bug i didnt file yet, you need to comment next-server in the dhcpd.conf (fixed in my local branch already) debian cant do without it it seems :)
[12:07] <stgraber> ok :)
[12:07] <pitti> ogra: WDYT about bug 121547? does it affect everyone?
[12:07] <ubotu> Launchpad bug 121547 in ltsp "[Gutsy]  LTSP chroot building process hangs at 50% on Tribe1 CD" [Undecided,Confirmed]  https://launchpad.net/bugs/121547
[12:07] <ogra> pitti, yes, every server install
[12:07] <pitti> ogra: ah, that's the "unresponsive" issue
[12:07] <pitti> ?
[12:08] <ogra> (...of edubuntu)
[12:08] <ogra> yeps
[12:08] <asac> pitti: yes thats granparadiso
[12:08] <pitti> ogra: that sounds worth mentioning in the release notes
[12:08] <ogra> it takes 8min here for me for the mksquashfs run ... during that time you dont have disk activity or so as you usually have once in a while in d-i
[12:08] <ogra> yeah
[12:08] <pitti> asac: ok, I'll change that
[12:09] <pitti> ogra: can this be fixed (progress bar or so) for tribe-3?
[12:09] <ogra> yep
[12:09] <ogra> planned
[12:09] <asac> pitti: thanks ... is freeze lifted?
[12:09] <pitti> asac: no, we haven't released yet
[12:09] <asac> ok
[12:10] <stgraber> davmor2: hi, you spoke about bug 121547 on your edubuntu "erase disk" test but not with "manual partitioning", you also had it with this one right ?
[12:10] <ubotu> Launchpad bug 121547 in ltsp "[Gutsy]  LTSP chroot building process hangs at 50% on Tribe1 CD" [Undecided,Confirmed]  https://launchpad.net/bugs/121547
[12:11] <davmor2> stgraber:  yes but it was so late by the time I finished that I was going to look for it today.
[12:12] <pitti> can some interested people and also native English speakers please have a look at https://wiki.ubuntu.com/GutsyGibbon/Testing/Tribe2 and point out missing things and typos?
[12:13] <stgraber> davmor2: I've updated your test result adding the bugnumber
[12:14] <iwj> sladen: Hmm.  I'm not really looking for a workaround.  It's related to UnifiedLoginUnlock which will involve a lot more VC switching.
[12:14] <davmor2> Yes I noticed ta I was about to
[12:15] <iwj> pitti: The section on GNOME 2.19.4 uses the word `release' too many times.
[12:16] <iwj> pitti: The `,' after `easier to install' in the Gnash section should be a colon or full stop.
[12:16] <iwj> pitti: Do you want me to edit it ?
[12:16] <iwj> Urgh!  `utilize'!
[12:16] <iwj> Excuse me.
[12:17] <pitti> iwj: I'm at it
[12:17] <pitti> iwj: apparently this was written at late night by Corey :)
[12:17] <iwj> pitti: OK :-).
[12:17] <iwj> pitti: Punctuation in the Gnash section is generally a bit odd.
[12:17] <pitti> iwj: I fixed your first two issues, but I won't save the page for every small change
[12:17] <iwj> OK
[12:18] <iwj> pitti: Change `utilize' to `use'.  (in XDG)
[12:18] <pitti> iwj: I saved the page now, so if you have more changes, it might indeed be easier if you edit them, right
[12:18] <iwj> OK
[12:19] <iwj> Is there some house style that prefers `_The_ Gutsy Gibbon Tribe 2' ?  It reads oddly to me.
[12:19] <davmor2> pitti: barreling looks wrong shouldn't it be double l
[12:20] <iwj> davmor2: Fixing.
[12:21] <pitti> sladen: ah, thanks for your mail re gdb on 2.6.22; I'll have a look
[12:21] <pitti> iwj: I'm not picky about the article :)
[12:24] <wolfeon> you guys are stuck with me ;) I'll keep fixing bugs when I see them until bug #1 is done. 
[12:24] <ubotu> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress]  https://launchpad.net/bugs/1
[12:26] <davmor2> pitti: what extra effects are enabled when you tick the box I see no difference?
[12:26] <iwj> pitti: I've edited it a bit.  I think it's improved but someone other than me should do a final proofread.
[12:26] <stgraber> davmor2: mainly wobbly windows
[12:27] <pitti> davmor2: the only thing I see is wobbling wins
[12:27] <pitti> iwj: thanks a lot
[12:28] <pitti> seb128, dholbach, asac, mvo: any other features you'd like to see mentioned on https://wiki.ubuntu.com/GutsyGibbon/Testing/Tribe2?
[12:29] <seb128> pitti: no, that's ok for me
[12:29] <dholbach> for me too
[12:29] <asac> seb128: me too
[12:29] <asac> pitti: me too
[12:29] <asac> :)
[12:29] <gicmo> seb128: ALTER
[12:30] <dholbach> gicmo: ALTER
[12:30] <gicmo> seb128: dude, which products is the file selector in?
[12:30] <seb128> gicmo: Alter!
[12:30] <gicmo> dholbach: ALTER!
[12:30] <seb128> gicmo: gtk+2.0
[12:30] <gicmo> dholbach: dude, long time no see, how is stuff going?
[12:30] <dholbach> gicmo: very well - how are you?
[12:30] <seb128> gicmo: or libgnomeui for the vfs backend
[12:31] <davmor2> query then how do you enable the water effects?  Do you need to use gconf-editor?  if so what do I need to put in
[12:31] <gicmo> dholbach: a little headache .. had to give 3 lectures this monday and tuesday so a bit "burned out"
[12:31] <dholbach> ouch :-(
[12:31] <gicmo> seb128: hmm I guess libgnomeui then
[12:32] <dholbach> hope you have time to relax on the weekend
[12:32] <seb128> gicmo: what is the bug?
[12:32] <mathiaz> pitti: isn't tribe2 the second alpha release of Ubuntu 7.10 ?
[12:32] <gicmo> seb128: 2 things, first I have two Desktop entries there (seems like a xdg-folder thingy) but the bug indeed is that clicking on recently used stuff blocks
[12:33] <gicmo> I mean not really blocking but if you then click away from form recently used to another folder it wont refresh instantly but still populating recently used
[12:33] <gicmo> (did I get the point through now?)
[12:34] <stgraber> ogra: ouch, mksquashfs is flooding tty4 :), you didn't add this -no-progress option finally ?
[12:35] <pitti> mathiaz: it is
[12:35] <mathiaz> pitti: the wiki page says it's the first alpha release
[12:35] <pitti> iwj: I added two stanzas about restricted-manager and apport, can you please have a quick proofread?
[12:35] <pitti> mathiaz: good catch, thank you!
[12:36] <pitti> fixed
[12:38] <seb128> gicmo: we already have a bug about the duplicate Desktop entry
[12:38] <seb128> gicmo: recently used works fine for me
[12:39] <gicmo> seb128: maybe my list is much biggern then yours
[12:39] <gicmo> seb128: here it populates the list and while it is populating you cant switch to another folder
[12:39] <iwj> pitti: Sure.
[12:39] <mathiaz> pitti: in "Reporting Bugs" section, "a copy for /var/log/Xorg.0.log" should be "a copy of /var/log/Xorg.0.log" ?
[12:39] <gicmo> seb128: a propos, is there any ui planed to set the folders for the xdg folder stuff
[12:40] <pitti> mathiaz: right, fixing
[12:40] <gicmo> since I have Movies here instead of Videos and Pix instead of Pictures
[12:41] <seb128> gicmo: not that I know but it's likely somebody will write one ;)
[12:41] <seb128> gicmo: for now gedit .config/user-dirs.dirs
[12:42] <mathiaz> pitti: and may be not put too many "and" in the sentence.
[12:42] <mathiaz> pitti: ~/.xsession-errors, /var/log/Xorg.0.log
[12:42] <pitti> mathiaz: I cleaned up, please have a look
[12:43] <gicmo> seb128: ohh, I also have Photos != Pictures
[12:43] <gicmo> hmm
[12:43] <gicmo> isnt there a place with all folders mentioned that can be set?
[12:43] <iwj> pitti: Edited, but again you'll want a seperate proofreader perhaps.
[12:44] <stgraber> ogra: apport also report a nbd-server crash (something tried to start it the incorrect way ?) but it seems to be working fine (LTSP boots)
[12:44] <ogra> stgraber, i guess we need to supress starting by initscript 
[12:44] <seb128> gicmo: .config/user-dirs.dirs
[12:45] <seb128> gicmo: /etc/xdg/user-dirs.defaults
[12:45] <pitti> iwj: weird, I don't see another edit from you
[12:45] <gicmo> seb128: so thats all that are available?
[12:45] <ogra> with an /etc/default setting ...
[12:45] <gicmo> seb128: thnaks
[12:45] <seb128> np
[12:46] <stgraber> ogra: Unable to log in, I see ldm, enter my login/pass, then blackscreen with a waiting cursor ... (May that be related that I'm using an external DHCP and different IPs (172.16.0.0/255.255.255.248) ?)
[12:46] <iwj> Oh, edit conflict and the wiki has just come back to me.
[12:46] <iwj> pitti: Fixed now.
[12:47] <ogra> stgraber, check .xsession-errors
[12:47] <pitti> iwj: cheers, appreciated
[12:50] <stgraber> ogra: no ssh connection received on the server ...
[12:51] <ogra> hmm
[12:51] <ajmitch> does merges.ubuntu.com still update the suggested merges for packages?
[12:51] <stgraber> ogra: ok, directly connected to the server I've a different result, I see gnome starting, then the gnome splash for 2s and no more Xorg ...
[12:51] <pitti> ajmitch: yes, it's usually not taken down at all
[12:52] <ajmitch> ok
[12:52] <ogra> that sounds like a crasher ... any traces in .xsession-errors there ? 
[12:52] <stgraber> ***MEMORY-WARNING***: metacity[20351] : GSlice: g_thread_init() must be called before all other GLib functions; memory corruption due to late invocation of g_thread_init() has been detected; this program is likely to crash, leak or unexpectedly abort soon...
[12:52] <stgraber> Window manager error: Unable to open X display localhost:11.0
[12:52] <ogra> ugh
[12:52] <ajmitch> each time I go back to it, there's a new version
[12:52] <gicmo> stgraber: the memory warning is a know issue
[12:53] <stgraber> ogra: I'm boot a real client to check if it's not a vmware issue
[12:53] <ogra> why isnt the display set ... thats pretty weird
[12:53] <ogra> s/set/accessible/
[12:53] <mathiaz> pitti: in the compiz fusion section, there is a repetition of "going to". Should I update the wiki page ?
[12:53] <ogra> stgraber, oh, vmware ... indeed, that could be an issue
[12:53] <pitti> mathiaz: please do, thanks
[12:54] <ogra> stgraber, LaserJock had display issues in the liveCD with vmware where he couldnt log in ... not sure thats the same issue though
[12:55] <stgraber> ogra: working on a real thin client (even if I still have the GSlice error in the .xsession-errors)
[12:55] <ogra> good
[12:55] <stgraber> so there is an issue with having an external DHCP server (or a different IP class) and a vmware bug
[12:56] <ogra> so lets blame vmware for now :P
[12:57] <stgraber> ogra: what's exactly the problem with this next-server thing ?
[12:57] <ogra> stgraber, we dont need it and its ignored if its unset .... if you set it, tftp will only work wih the set ip
[12:58] <stgraber> ok, I'm trying to understand why I can boot the client, see LDM but not login with an external DHCP/different IP
[12:58] <ogra> debians dhcpd needs that option to work at all ... so they added a line with hardcoded ip to the defailt config (which they dnt even use)
[12:58] <stgraber> ogra: SSH key thing I think
[12:58] <pitti> ogra: do you happen to know if 'sudo ubiquity' avoids the manual partition hang as well? I don't want to propose --debug in the release notes for password exposure
[12:58] <pitti> ogra: nevermind, I'll just try it here
[12:58] <ogra> pitti, i'D have to test that, but currently there is still a manual partitioning install of server running
[12:59] <ogra> stgraber, very likely, yes
[01:00] <ogra> stgraber, you could create an lts.conf in your tftp dir  ... and set SERVER as well as SCREEN_02=shell and SCREEN_07=ldm ... that way you get a commandline to check the client logs
[01:00] <ogra> (/var/lib/tftpboot/ltsp/i386/lts.conf)
[01:01] <stgraber> ogra: ok, will do
[01:04] <ogra> also check whats in /opt/ltsp/i386/etc/ssh/ssh_known_hosts
[01:13] <stgraber> ogra: Can I put the server ISOs as looking good ?
[01:13] <ubotu> Launchpad bug 122094 in gnome-power-manager "Disable compiz/beryl on switch to battery" [Undecided,New]  https://launchpad.net/bugs/122094
[01:13] <stgraber> pitti: report for edubuntu i386 server is on the tracker
[01:13] <ogra> stgraber, yep, with the errata for the progress hang and the next-server thing it should be fine
[01:15] <pitti> StevenK: great
[01:15] <mjg59> ogra: I'd disagree that it's a bug
[01:15] <pitti> ogra: what's the bug for the next-server thing?
[01:16] <stgraber> has anyone tested edubuntu server add-on ? (the WinFOSS part has been done and is ok)
[01:17] <pitti> ogra: do you want the serveraddons be released at all?
[01:17] <stgraber> pitti: hehe, yes that's the first question :)
[01:18] <ogra> pitti, sure
[01:18] <ogra> even though ...
[01:18] <siretart> keescook: around? what do you currently use for additional bind mounts in schroot? your patch in debian bug #395062, or have you edited /etc/schroot/*?
[01:18] <ubotu> Debian bug 395062 in schroot "add additional bind mount points to chroot" [Wishlist,Open]  http://bugs.debian.org/395062
[01:18] <pitti> ogra: we didn't release them for tribe1 AFAIR, because there hadn't been any changes
[01:19] <ogra> pitti, well ... i know LaserJoc is working on changes that arent in anyway yet, so we can even skip them this time
[01:19] <pitti> ogra: I'd like to have a bug about the next-server thing, for referring to in the release notes
[01:19] <ogra> right, there are no other changes yet
[01:19] <ogra> pitti, i just hit enter on bug #122796 :)
[01:19] <ubotu> Launchpad bug 122796 in ltsp "dhcpd.conf broken on tribe2 installs" [Undecided,New]  https://launchpad.net/bugs/122796
[01:20] <ogra> hmm ... 
[01:20] <pitti> ogra: splendid, thanks
[01:20] <ogra> that looks better :)
[01:20] <pitti> ogra: so the next-server option needs to be commented out? I'd like to have some understandable recipe in the bug for people wanting to fix it
[01:21] <ogra> pitti, i'll add that, yes it needs to be commented
[01:21] <ogra> (i'd love it to be not there at all, but then debian moans for months)
[01:24] <pitti> ogra: is this serious enough for the release notes? I. e. will it break for all people who install it?
[01:24] <ogra> for all ltsp people
[01:25] <ogra> it breaks client booting unless you occasionally use 192.168.0.1 as IP 
[01:25] <ogra> (for the server)
[01:26] <pitti> ok
[01:26] <pitti> ogra: so, what do people have to do to fix this?
[01:27] <ogra> comment the line in /etc/ltsp/dhcpd.conf
[01:28] <ogra> and restart the dhcp server
[01:28] <ogra> indeed
[01:28] <pitti> ogra: restart -> "sudo /etc/init.d/dhcp3-server restart" ?
[01:30] <ogra> pitti, added the info to the bug
[01:34] <pitti> Mithrandir, iwj, mvo, ogra: can you please take a look at http://people.ubuntu.com/~pitti/tmp/tribe2-announcement.txt and proofread/verify the known issues and their workarounds?
[01:35] <ogra> pitti, fine
[01:36] <Mithrandir> somehow, pointing people to gutsy-changes doesn't really seem very useful?
[01:37] <pitti> Mithrandir: it says what it is for
[01:38] <pitti> and it's aimed for developers (u-devel-announce)
[01:38] <Mithrandir> still, it's like pointing people at a firehose
[01:38] <ogra> you should notice that its high traffic
[01:40] <pitti> updated
[01:41] <ogra> better
[01:45] <cjwatson> pitti: xpdyinfo -> xdpyinfo
[01:45] <cjwatson> pitti: wide-scale -> large-scale
[01:45] <pitti> cjwatson: thanks; that's wrong on the wiki as well then, fixing
[01:46] <pitti> updates
[01:47] <pitti> updated, even
[02:09] <ogra> doko, running oowriter starts a openoffice shel as well for me every time ...
[02:09] <ogra> *shell
[02:09] <ogra> is that intentional ?
[02:09] <ogra> or known
[02:10] <doko> ogra: on the live CD?
[02:11] <ogra> no, on a fresh tribe2 install
[02:12] <doko> ogra: anyway, calc is your man =)
[02:12] <ogra> oh, right, i forgot :)
[02:25] <pitti> nixternal: ping
[02:35] <enrico> fabbione: uploading now to debian a new libept which fixed yet another alignment problem
[02:35] <enrico> fabbione: with this one, it should be all
[02:42] <jab00> Hi, I'm running 64bit edgy and I need to run a 32bit binary that depends on some 32bit libraries which only exist in 64bit form. Is there a magic combination of options I can pass to apt-get to get it to download the sources to the libraries and build 32bit versions for use on my local machine?
[02:51] <realist_> jab00: I wouldn't have thought 32bit binaries would run on a 64bit system, without some sort of 'compatibility mode', how difficult this is to do, I wouldn't know, unfortunately.
[02:51] <jab00> they run fine when the libraries are there
[02:51] <jab00> unfortunately by default there are only a few pre-compiled 32bit libraries in the 64bit disutribution
[02:52] <jab00> unless i have missed something...
[02:52] <ijuz_> realist_: lots of people are running 32bit userspace on a 64 bit kernel
[02:52] <ijuz_> jab00: probably you should just try to debootstrap a chroot, but this is not a -devel problem
[02:52] <realist_> ijuz_: I'm sure they are, but as I said, I wouldn't know how
[02:53] <jab00> i know but deboostrap chroot is overkill and this question really would be best answered by a developer
[02:53] <jab00> sorry
[02:53] <pitti> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-June/000311.html
[02:53] <Mithrandir> jab00: no, just use a chroot for it.
[02:53] <pitti> *phew* :)
[02:53] <Mithrandir> pitti: \o/
[02:55] <realist> So a 32bit chroot, would run fine on a vanilla 64bit kernel?
[02:55] <realist> And, for what architectures?
[02:55] <cjwatson> realist: Yes. We don't have another good answer right now.
[02:55] <cjwatson> I'm assuming you're on a PC, so i386 is 32-bit and amd64 is 64-bit
[02:55] <Hobbsee> yay, pitti!
[02:56] <realist> So a 64bit kernel will run on an Intel 32bit CPU?
[02:56] <Mithrandir> realist: no
[02:57] <Mithrandir> but the reverse is true
[02:57] <realist> So we're talking IA64, and AMD64?
[02:57] <ijuz_> a 32 bit CPU will run on a 64bit kernel? ;-))
[02:59] <ijuz_> realist: why don't you real wikipedia or something? intel IA64 is some dead legacy arch (itanic) that is or was able to run i386 code (also from a chroot possible); AMD64 can run 64 bit kernels for AMD64 and i386 kernels; AMD64 has nothing to do with IA64
[03:01] <JanDM_> can I ask questions here about the website too? www.ubuntu.com/testing, the link to tribe 2 does not work
[03:01] <doko> pitti: the queue is still in manual mode?
[03:01] <pitti> doko: not since 5 seconds ago any more
[03:02] <doko> pitti: dpkg seems to be stuck?
[03:06] <pitti> doko: accepted now, it came between flushing the queue and thawing gutsy
[03:06] <mjg59> ijuz_: IA64 is (sadly) far from dead
[03:11] <cjwatson> shawarma: re your question in last week's distro team meeting, I have no objection to kbd-chooser being removed from the archive
[03:11] <cjwatson> though it would also need to be blacklisted since Debian haven't yet switched to console-setup
[03:12] <shawarma> cjwatson: Alright. It's been at the top of the universe merge list (in red even) bugging me for a loong time now. I'll be glad to see it go. :)
[03:13] <TheMuso> [4~/c
[03:14] <Hobbsee> TheMuso: 42.
[03:14] <TheMuso> ugh
[03:14] <Hobbsee> heh
[03:14] <TheMuso> Damn evil soft/hardware combination.
[03:14] <Hobbsee> :)
[03:17] <stgraber> heno: How do you want to proceed with Tribe-2 release on the tracker ? Add a new ISO set called Tribe-2 and swizch Tribe-2 from testing to released (+setting daily CDs as default milestone) ?
[03:33] <shawarma> cjwatson: Will you take care of having it removed? I have no clue where to start.
[03:34] <pitti> shawarma: I can kill it from the archive if you want
[03:34] <pitti> (and blacklist as well)
[03:34] <shawarma> Yes, please. Only ubuntu-archive can do that, right?
[03:34] <pitti> right
[03:34] <pitti> shawarma: what's the rationale for it? it's only a universe pacakge
[03:35] <pitti> shawarma: no reverse dependencies at all, good
[03:35] <shawarma> pitti: It's completely useless.
[03:35] <shawarma> pitti: It's for the installer and we don't use it there anymore.
[03:35] <shawarma> pitti: It's just cruft now.
[03:35] <pitti> shawarma: ok, fine for me
[03:37] <pitti> shawarma: *flush*
[03:38] <shawarma> \o/
[03:38] <shawarma> pitti: Thanks.
[03:38] <hunger> pitti: I think you can flush the vmware-player stuff as well. Its terribly outdated.
[03:38] <pitti> hunger: hm, but wouldn't it be better to update it rather than kill it?
[03:38] <hunger> pitti: No need to blacklist it:-)
[03:39] <hunger> pitti: But I'm probably wrong, I have no clue about all the archives and how you manage them.
[03:39] <hunger> I just find it confusing to find stuff that won't install.
[03:39] <ogra> hunger, well, its gutsy :)
[03:39] <pitti> hunger: right, but still I think it would be nice to update it :)
[03:40] <hunger> pitti: I do agree.
[03:41] <hunger> ogra: That's no excuse for having stale stuff... that could get filtered out by scripts.
[03:42] <ogra> hunger, well, i rather like to put time into fixing stuff instead of investing into working around the breakage ... its a fact that things break for a while if you update code in an OS
[03:43] <hunger> ogra: sure. I just assumed you'd have scripts that try to fix the broken stuff or draw develop attention to it. That does not seem to be the case as everybody seems to be surprised when I ask about some broken package or another after a couple of days where they won't work.
[03:43] <ogra> hunger, we call these scripts bugs.launchpad.net ;)
[03:43] <hunger> ogra: Anyway, you guys are doing a great distro. I'll better just shut up and let you work your magic.
[03:44] <Hobbsee> hunger: apt-cache unmet -i | less
[03:44] <Hobbsee> hunger: that's the main script
[03:44] <hunger> Hobbsee: And there is nothing trying to rebuild the broken stuff, etc.?
[03:45] <Hobbsee> hunger: depends how it's broken.
[03:45] <Hobbsee> hunger: the fixing is not automatic, no
[03:45] <hunger> Hobbsee: Like some deb gets updated with some namechange and there is nothing rebuilding it?
[03:45] <hunger> Hobbsee: Wow, you guys are better than I thought! Keeping up with all that manually...
[03:46] <fabbione> enrico: cool thanks
[03:47] <Hobbsee> hunger: i didnt say that.  i said "depending on how it's broken"
[03:47] <ogra> woah, not rebooting after na upgrade if you have the3 reboot sign in the systray can make apport really angry it seems 
[03:47] <hunger>  Hobbsee: Oh, I see.
[03:48] <pitti> ogra: why apport?
[03:48] <ogra> pitti, isnt apport the thing that makes the little orange start with crach messages appear ?
[03:48] <ogra> *star
[03:48] <pitti> ogra: ah, just because there are actually so many crashes? :)
[03:48] <pitti> ogra: yep
[03:48] <ogra> yeah
[03:49] <ogra> atd seems not to run very stable ...
[03:49] <hunger> pitti: I guess you can nuke: xen-restricted-modules-2.6.17-6-generic-xen0 from gutsy. One item less in the apt-cache unmet list:-)
[03:49] <ogra> and gnome-mount crashes every several minutes ... as well as gnome panel ... 
[03:49] <ogra> funny is that actually nothing of these really crashed ...
[03:49] <Enola_Gay> hi all
[03:49] <seb128> ogra: do you use nautilus?
[03:49] <ogra> seb128, yup
[03:50] <seb128> there is a known gnome-mount crash when closing the properties of a non local drive
[03:50] <ogra> well, i didnt touch anything :)
[03:50] <Enola_Gay> ntfs-3g still seems to be universe in Gutsy. Are there no plans to ship Ubuntu Gutsy with ntfs write support?
[03:50] <ogra> it just sent several crash messages ... gnome-panel as well, but it works fine and didnt crash
[03:51] <ogra> i should just reboot :)
[03:51] <pitti> seb128: darn; my suspicion about not waiting hard enough for stdin flushing was wrong apparently
[03:52] <seb128> pitti: oh, how do you know?
[03:52] <pitti> seb128: I wrote a test case
[03:52] <heno> stgraber: let's mark it released and keep Tribe-2 as the active release for a few days
[03:53] <pitti> seb128: (http://paste.stgraber.org/1920 FYI)
[03:53] <evand> Enola_Gay: https://blueprints.launchpad.net/ubuntu/+spec/write-support-for-ntfs
[03:53] <stgraber> heno: ok, and do we keep the current build for Tribe-2 or add an empty one called Tribe-2 ?
[03:54] <Enola_Gay> evand: Thanks. How can I search this specs. Is there a special page for this. Launchpad is very huge :)
[03:54] <heno> stgraber: ok, to separate out the test stats. agree
[03:55] <Enola_Gay> thx
[03:55] <RainCT> hi, can some main sponsor check bug 49443? I attached a debdiff I month ago there and have not heard anything about it..
[03:55] <ubotu> Launchpad bug 49443 in defoma "dfontmgr ships no .desktop" [Wishlist,Confirmed]  https://launchpad.net/bugs/49443
[03:57] <pitti> BenC: is it possible in theory that apport reading from stdin can hit a EOF, although not all data has been written yet?
[04:01] <asac> any opinions on whether we want a single flashplugin-alternative for all nsplugin-host applications ... or one alternative for each nsplugin-host application?
[04:02] <asac> fwiw, nsplugin-host application == firefox, mozilla, et al
[04:05] <BenC> pitti: shouldn't be, that's what my pipe changes were for
[04:05] <BenC> we had that problem in Oslo and I fixed it in feisty, and that patch is in gutsy
[04:06] <pitti> BenC: ok, thanks; I'm still baffled why I sometimes get 0-byte cores
[04:07] <BenC> pitti: could be something screwy in the logic for resetting the core size for the pipe action
[04:07] <BenC> maybe check there
[04:07] <BenC> I remember we had that problem before as well
[04:07] <BenC> depends if the user had core size set themselves
[04:07] <pitti> BenC: neither seb128 nor I can reproduce this, it's just the bug reports we get
[04:08] <BenC> pitti: the case I fixed in Oslo showed as short core sizes too, not zero-size
[04:08] <pitti> right
[04:08] <cjwatson> shawarma: for how to get packages removed, see https://wiki.ubuntu.com/UbuntuDevelopment#head-def358a3275878d6188c3daabb36cd868c1f2c49
[04:09] <cjwatson> Enola_Gay: see https://blueprints.launchpad.net/ubuntu/gutsy
[04:10] <Enola_Gay> cjwatson: thx
[04:13] <nixternal> pitti: pong?
[04:13] <pitti> nixternal: I wanted to ask you whether you were fine with the Kubuntu tribe-2 page
[04:14] <pitti> nixternal: it's released now in the meantime, though :) ; thanks for it
[04:14] <nixternal> hehe, no problem the release page should be good, unless someone added something :)
[04:15] <Riddell> as usual nixternal's page is a work of perfection
[04:15] <nixternal> why thank you, actually I see a booboo, didn't close a '' tag
[04:16] <nixternal> and of course I hadn't realised, after looking 2 or 3 times, that today is the 28th :)
[04:19] <pitti> seb128: can you still reproduce bug 74691 on current kernel?
[04:19] <ubotu> Launchpad bug 74691 in linux-source-2.6.20 "Unable to debug under 2.6.19: Failed to read a valid object file image from memory" [High,Fix released]  https://launchpad.net/bugs/74691
[04:20] <stgraber> ogra: argh, my thin client problem isn't related to the ssh key, it's correct in /opt/ltsp/i386/etc/ssh/ and a : chroot /opt/ltsp/i386 then ssh root@172.16.1.2 just work fine ...
[04:20] <seb128> pitti: yes
[04:21] <pitti> seb128: oooh, yay regressions
[04:21] <seb128> pitti: well, not sure what should happen since non-debug backtrace seems to be broken since Oslo sprint
[04:21] <seb128> "Failed to read a valid object file image from memory." is printed
[04:22] <seb128> Program received signal SIGINT, Interrupt.
[04:22] <seb128> 0xffffe410 in ?? ()
[04:22] <seb128> (gdb) bt
[04:22] <seb128> #0  0xffffe410 in ?? ()
[04:22] <seb128> #1  0xbffe9ef8 in ?? ()
[04:22] <seb128> #2  0xb7dbe68c in ?? ()
[04:22] <seb128> #3  0x00000000 in ?? ()
[04:22] <seb128> also
[04:22] <pitti> seb128: right, but "Failed to read a valid object file image from memory." shouldn't be there
[04:22] <pitti> seb128: and on amd64, I have nanosleep() and __libc_start_main() in the trace
[04:23] <seb128> ah
[04:23] <seb128> lucky you ;)
[04:23] <pitti> seb128: so, I guess it's time to reopen that bug
[04:23] <pitti> seb128: fortunately the retracers run on a stable kernel :)
[04:23] <seb128> ;)
[04:24] <shawarma> cjwatson: Thanks. I actually meant the act of removing it, not requesting the removal, but clearly that's not my conern. :)
[04:25] <pitti> BenC: so I opened a gutsy task for bug 74691
[04:25] <ubotu> Launchpad bug 74691 in linux-source-2.6.20 "Unable to debug under 2.6.19: Failed to read a valid object file image from memory" [High,Fix released]  https://launchpad.net/bugs/74691
[04:25] <pitti> BenC: it's not the reason for the 0-byte core dumps, but still important
[04:25] <pitti> BenC: well, gutsy task -> task for 2.6.22
[04:29] <Nicke_> Speaking of broken packages earlier. The recent security updates for kerberos in feisty broke krb5-user (dependency problems)
[04:30] <Nicke_> (possible other too).. Any fix in sight? :O
[04:30] <pitti> Nicke_: shot in the dark: you don't have feisty-security enabled for universe?
[04:30] <stgraber> ogra: when I try ssh from the thin client I got : 2x "Permission denied, please try again." and 1x "Permission denied (publickey,password)."
[04:30] <stgraber> ogra: any idea ?
[04:31] <pitti> Nicke_: (it's not that dark, that's the most common problem)
[04:31] <Nicke_> pitti: Ah, true.. that fixed it yes
[04:31] <Nicke_> tu
[04:31] <Nicke_> ty*
[04:32] <Nicke_> I should remember to check that next time.
[04:32] <ion_> keybuk: Youre still using the compiz wallpaper plugin, right? Is it packaged?
[04:32] <cjwatson> shawarma: indeed, you can't
[04:33] <cjwatson> stgraber: what version of openssh-server on the server?
[04:34] <stgraber> 4.6p1-2
[04:35] <cjwatson> should be ok
[04:37] <stgraber> cjwatson: yes, I doubt it's openssh related as it works if I'm directly connected to the server (with its DHCP server and on the 192.168.0.0 net), it just doesn't work when I connect from the outside (172.16.0.0) ...
[04:37] <asac> crimsun: http://paste.ubuntu-nl.org/27622/ ... will go up
[04:38] <asac> crimsun: please take a quick look ... if you want check debdiff first, i can provide it too
[04:53] <ogra> stgraber, run ltsp-update-sshkeys and ltsp-update-image (in that order)
[04:53] <ogra> then reboot the client 
[05:06] <Mithrandir> bryce: and chance you could do an xorg-server upload in the not-too-distant future?  I'd like to have debug symbols for xephyr. :-)
[05:07] <bryce> sure, in fact I have xorg-server ready to go now, but was waiting for tribe2 freeze to be over + need a sponsor to upload
[05:07] <bryce> also I have new xorg, xauth, xinit and hopefully today xrandr
[05:07] <Hobbsee> :P
[05:08] <Hobbsee> wow
[05:08] <Mithrandir> see, both of those sorted now.
[05:08] <Mithrandir> Hobbsee just volunteered to sponsor you
[05:08] <Mithrandir> :-)
[05:08] <Hobbsee> hey now, i never said that
[05:08] <bryce> Mithrandir: I got a patch for xephyr yesterday
[05:08] <ogra> you are voluntold 
[05:08] <Hobbsee> ogra: no, it doesnt work like that.
[05:08] <Hobbsee> ogra: i'm Hobbsee, remember?  :P
[05:08] <Mithrandir> Hobbsee: sure you did.
[05:09] <Hobbsee> Mithrandir: nono i'm sure i didnt
[05:09] <ogra> Hobbsee, it always worked like that ... :)
[05:09] <Hobbsee> ogra: voluntold doesnt work for people with Long Pointy Stick of DOOM!!!!!!!!!!!!!!! 
[05:09] <Hobbsee> 's
[05:09] <Mithrandir> Hobbsee: I have it here, in grey on black.
[05:10] <Hobbsee> Mithrandir: i was pondering.  not offering :P
[05:10] <ogra> pondering loud is half the offer :P
[05:11] <Hobbsee> heh
[05:11] <Hobbsee> yes, but only half
[05:11] <Hobbsee> the problem with sponsoring it is that i wouldnt really understand *what* i was sponsoring, on a code-level.
[05:11] <bryce> yesterday I found a small but serious bug that debian introduced to dexconfig in xorg, so I'm thinking these packages need to be tested a good bit before uploading
[05:11] <Hobbsee> bryce: got a repository somewhere?
[05:12] <bryce> not yet, I need to rebuild packages
[05:12] <ogra> Hobbsee, being voluntold is the other half here indeed :)
[05:12] <Hobbsee> heh
[05:12] <bryce> Hobbsee: but I do have installing/reverting instructions this time :-)
[05:13] <Hobbsee> bryce: the dpkg shouldnt be buggered up enough to need them :P
[05:13] <Hobbsee> bryce: it should all "just work"
[05:14] <kylem> ogra, ping?
[05:15] <ogra> kylem, pong
[05:15] <bryce> well then I may need some advice on better ways to revert back to feisty
[05:16] <bryce> er, gutsy
[05:16] <Hobbsee> bryce: you're not suddenly running another release due to an updated X.  i'm presuming you mean back to the previous X packages?
[05:16] <Hobbsee> bryce: sudo dpkg -i <list of debs>.deb
[05:17] <Hobbsee> usually sudo dpkg -i /var/cache/apt/archives/<listofdebs*version*>.deb
[05:17] <bryce> right.  here's my instructions so far -- http://people.ubuntu.com/~bryce/Testing/xorg-server/
[05:20] <bryce> (that is the xorg-server before adding the composite-no-clipping patch for xephyr; the latter I'm building now and will get up to Testing shortly)
[05:24] <bryce> (this time I'm *not* building mesa at the same time ^o^)
[05:24] <Hobbsee> haha
[05:24] <Mithrandir> just get a real machine and you won't feel the pain. ;-)
[05:26] <Hobbsee> i hear building in the DC is also effective
[05:26] <bryce> Mithrandir: the problem wasn't performance but debs getting mixed up with each other (I think...)
[05:27] <bryce> yeah I need to experiment around with faster ways of doing builds (and getting them onto rookery)
[05:28] <bryce> btw, here's the current state of X packages.  http://people.ubuntu.com/~bryce/Xorg/versions_current.html
[05:28] <pitti> mvo: btw, I guess bug 115959 can be closed now? the wart about -Browser has a separate bug after all
[05:28] <ubotu> Launchpad bug 115959 in apt "apt-get source should check the Vcs-Bzr field" [Medium,Fix committed]  https://launchpad.net/bugs/115959
[05:28] <kylem> bryce, dput is a pretty useful way of getting things into the dc for building
[05:28] <bryce> my hope is to get all the reds and yellows in the right column turned to green before things freeze up
[05:28] <mvo> pitti: oh yes, closed. thanks
[05:29] <kylem> i use dput + rsync to blat stuff into the dc (so the .orig.tar.gz only gets rsync once)
[05:30] <bryce> kylem: ah cool
[05:30] <kylem> as soon as i figure out which machine has that config, i'll send you the dput.cf snippet
[05:30] <bryce> great, thanks!
[05:31] <bryce> are there directions somewhere for logging into / using the DC?
[05:32] <cjwatson> bryce: you already put stuff on rookery, don't you?
[05:32] <cjwatson> there's https://wiki.canonical.com/MachineOverview, but I'm sure you must be doing that already
[05:33] <bryce> cjwatson: yup, yup
[05:33] <cjwatson> bryce: (you correctly expanded DC to "datacentre", right?)
[05:34] <bryce> ah, no, thanks, I was guessing Development something
[05:36] <cjwatson> I thought that might have been it
[05:46] <pitti> mvo: ergh, the i386 desktop CD fails to start the session in vmware (the usual compiz crash); I didn't have that on amd64
[05:47] <mvo> pitti: *sigh* I will upload a new compiz now that blacklist vmware too, I had hoped to get along with little blacklisting but if glxinfo kills the session (could you please check that with failsafe?) then I guess there is no choice. or is that a different version of vmware?
[05:47] <pitti> mvo: no, very same one. vmware 6 x86, with the amd64 and i386 live CDs as guests
[05:48] <pitti> mvo: I just downloaded it now to finally debug the apport/gdb brokenness on (only) i386
[05:48] <pitti> mvo: checking what on failsafe?
[05:48] <pitti> mvo: btw, no hurry to upload for just this change
[05:48] <mvo> pitti: sorry, could you please log into a failsafe session and run "glxinfo" ?
[05:48] <mvo> pitti: failsafe X terminal
[05:49] <pitti> mvo: ah, sure
[05:49] <mvo> seb128, pitti: what do you think about making "failsafe gnome" not run compiz but metacity?
[05:49] <mvo> seb128: how hard would that be?
[05:49] <pitti> mvo: well, that would make sense
[05:50] <seb128> mvo: seems to be a good idea, open a bug and I'll look at doing it
[05:50] <mvo> seb128: cool, will do that
[05:51] <seb128> danke
[05:51] <bryce> mvo, btw, I have been poking around more looking for ways to get a listing of loaded drivers from X
[05:52] <bryce> I've found the data structure where the info is kept, but so far haven't found an api that'd let us retrieve it
[05:54] <bryce> so adding it to xset would probably require first adding an api to X for it.  don't know how involved that'd be...  I'd be very interested in your opinion on how good/bad the parse-from-Xorg.0.log approach is working
[05:55] <pitti> mvo: failsave gnome or failsave terminal? 
[05:56] <mvo> pitti: please failsafe terminal
[05:56] <pitti> mvo: meh, failsafe terminal only brings a black box and hangs X; I guess I'll go with hackign /usr/bin/compiz again to make it start metaity and run glxinfo then
[05:57] <mvo> bryce: I poked a bit too and my impression is that xf86misc is responsible for it (the extension) and that it would require that the extension grows some more data members and a new protocol version
[05:57] <pitti> mvo: btw, does the gfxboot option 'start in failsafe graphics mode' influence this? it shouldn't start compiz either
[05:57] <bryce> mvo, yup, that's where I found it too
[05:57] <mvo> bryce: look like it something that should first be discussed with upstream, the log reading approach seems reasonsable for now
[05:58] <mvo> pitti: yes, it will run with vesa and that means that compiz will not run
[06:00] <pitti> mvo: ok, blacklisting vmware in /u/b/compiz works, and glxinfo reliably kills X
[06:01] <mvo> pitti: thanks! 
[06:01] <pitti> mvo: hmm, I'm a bit confused
[06:02] <pitti> mvo: xorg.conf doesn't have a Modules section, but Xorg.0.log shows that the glx module gets loaded
[06:02] <pitti> bryce: ^ should that actually happen for drivers which don't support glx? like vga/vesa/vmware?
[06:02] <pitti> bryce: or will that make mesa software rendering work usually? (but cause glxinfo to crash)
[06:02] <Treenaks> pitti: x shouldn't crash in it, surely?
[06:03] <Treenaks> in=because of
[06:03] <pitti> Treenaks: true, but I'm looking for some details :)
[06:03] <mjg59> pitti: No, it shouldn't happen
[06:03] <mjg59> glxinfo should work fine
[06:03] <bryce> pitti, yes it should; the new xorg is able to autoload modules
[06:03] <mjg59> pitti: Oh, sorry, I see what you mean
[06:04] <bryce> pitti, xorg seems to be moving rapidly towards hotplugging everything.  I suspect one day here soon our xorg.conf's are going to be empty except for overrides
[06:04] <pitti> bryce: right
[06:04] <bryce> oops, sorry misread
[06:04] <pygi> bryce, true that
[06:04] <pitti> bryce: what I meant is, is 'glx' actually supposed to autoload on vesa/vga/vmware?
[06:04] <bryce> re, loading glx for drivers that don't support glx... that I'm not sure.  I'll investigate today
[06:05] <bryce> I would guess that is a bug in the module hotplugger
[06:05] <pitti> bryce: I'd be interested in whether loading glx is the bug or is ok, and glxinfo just triggers a bug in mesa softrendering
[06:05] <pitti> bryce: if I add a manual Module section without glx, it won't autoload, I figure?
[06:08] <bryce> pitti, btw a new mesa 7.0.0 is in gutsy (thanks hobbsee!)  It would be interesting to see if it has the same bug
[06:09] <Hobbsee> :)
[06:09] <pitti> bryce: indeed
[06:09] <pitti> bryce: hm, if I supply a Module section, glx is still autoloaded
[06:09] <pitti> bryce: is there a way to tell X not to load a module?
[06:09] <bryce> ah, I suspected as much
[06:09] <bryce> I will find out
[06:09] <pitti> well, sudo rm I guess :)
[06:10] <pitti> it's just a live CD after all
[06:11] <mvo> bryce: did you tested the current tribe-2 live CD on your amazing range of hardware ? any problems with compiz-by-default that you noticed?
[06:12] <pitti> bryce, mvo: heh, rm libglx.so was blunt, but effective; glxinfo doesn't crash any more, but glxgears doesn't work, so this breaks mesa softrendering 
[06:13] <bryce> mvo, don't know about amazing...  ;-)  I tested tribe1, but not tribe2
[06:14] <bryce> pitti, mailed Q to xorg list
[06:15] <bryce> mvo, is testing just the desktop x86 cd sufficient?
[06:17] <mvo> bryce: yes, it should enable compiz automatically if the HW supports it (radeon, intel, ..) or fallback to metacity if the HW is not capable of runing compiz
[06:17] <bryce> ok
[06:19] <pitti> bryce: right, so if I leave glx turned on, glxgears works on vesa/vmware without crashing; it's just glxinfo that crashes
[06:19] <pitti> bryce: so, I'll try this with the new mesa once it's in the archive
[06:19] <pitti> bryce: and apparently glx loading is correct then
[06:19] <pitti> (might still be a bug in libglx.so itself, of course)
[06:19] <tkamppeter> Is there no devel team meeting currently? Noone is talking on #ubuntu-meeting.
[06:20] <pitti> tkamppeter: it was 1.5 hours ago
[06:21] <bryce> ok cool
[06:21] <tkamppeter> Sorry.
[06:22] <bryce> pitti: this is the same glxinfo bug we bumped from tribe2, right?  I should do more digging into this.
[06:22] <pitti> bryce: ooh, it's built everywhere
[06:22] <pitti> bryce: the one mentioning a particular graphics card? yes, I think so
[06:22] <pitti> bryce: I left a comment there saying 'me too on my hw ...'
[06:23] <bryce> I seem to recall I was able to replicate it on at least one of my machines
[06:24] <pitti> meh, tribe2 is two hours old, and already 20 MB of stuff to upgrade
[06:24] <kylem> pitti, the eternal sound of progress.
[06:25] <bryce> heh, I suppose a goodly chunk of that must be mesa
[06:25] <pitti> yes
[06:25] <pitti> -mesa-dri is 12 MB alone
[06:26] <ogra> mesa is da evil ... (size wise)
[06:26] <pitti> well, but -dri actually got SMALLER by 2 MB; nice
[06:27] <Amaranth> pitti: compared to what?
[06:27] <ogra> still leaves me 10M oversized :P
[06:27] <Amaranth> feisty?
[06:27] <ogra> Amaranth, last package
[06:27] <pitti> Amaranth: to the previous version
[06:27] <Amaranth> graphics drivers are pretty big :P
[06:28] <pitti> Amaranth: still, I guess all the intel ones have a good deal of common code in their 2 MB driver blob
[06:28] <Amaranth> whoa, what'd you remove?
[06:32] <pitti> bryce: nope, still crashes with new mesa
[06:32] <bryce> rats
[06:33] <pitti> mvo: so maybe you can blacklist vmware as well for now, to allow us poor testers some sanity :)
[06:33] <mvo> pitti: done
[06:33] <pitti> mvo: I just wonder why it works on amd64
[06:34] <pitti> mvo: ah, because glxinfo doesn't crash the X server, but just crashes itself :)
[06:34] <mvo> haha
[06:36] <pitti> bryce: http://people.ubuntu.com/~pitti/tmp/glxinfo-vmware-crash-amd64.png
[06:37] <pitti> bryce: the same command crashes on i386 in the very same environment
[06:37] <pitti> bryce: is that error message on amd64 helpful in any way?
[06:37] <pitti> mvo: however, just pure luck I guess; it did crash on the previous CD
[06:38] <pitti> bryce: 'BadAlloc' -> does that sound like a bug calculating a buffer size? int wrapping or so?
[06:39] <bryce> ahh, I saw a bunch of reports of that
[06:39] <mvo> pitti: right, I had this one too
[06:39] <mvo> pitti: and I have seen it on LP a couple of times
[06:39] <bryce> I'll see if I can find one matching the opcode
[06:44] <bryce> pitti, what video card are you using?
[06:45] <iwj> BadAlloc is an X protocol error which is nothing to do with memory management.
[06:46] <iwj> It's for stuff like `you can't allocate a colourmap like that' or whatever.
[06:46] <iwj> Semantic errors.
[06:46] <iwj> pitti: ^
[06:47] <pitti> bryce: host: radeon 5200 with nvidia proprietary driver; vmware guest: vmware X driver
[06:48] <mjg59> pitti: So it doesn't take down the server?
[06:48] <pitti> iwj: ah, ok
[06:48] <mjg59> How weird
[06:48] <pitti> mjg59: not on amd64, no; just on i386
[06:48] <mjg59> pitti: It's certainly the X_GLXCreateContext that's the issue, if I remember the backtrace properly
[06:48] <bryce> hmm, sounds like this bug:  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364233
[06:48] <ubotu> Debian bug 364233 in xorg-server "mesa-swx11-source: indirect rendering broken on 64-bit platforms" [Important,Open]  
[06:48] <pitti> mjg59: well, to be precise: for my particular vmware and the tribe-2 desktop CDs
[06:49] <pitti> bryce: hm, but our crash affects i386, too, and that one was fixed long ago
[06:50] <bryce> hmm
[06:50] <davmor2> pitti:  I am still having issues with the way nm-applet is working
[06:52] <davmor2> but I actually am wondering if it is gnome-keyring rather than nm-applet  is there a way to tell?
[06:53] <pitti> davmor2: depends on the behaviour that you see; asac?
[06:53] <pitti> hi sabdfl
[06:53] <sabdfl> howdy
[06:54] <davmor2> asac?
[06:56] <Hobbsee> morning sabdfl 
[06:56] <Hobbsee> er...3am is morning, isnt it?
[06:56] <xxxxx1> join #ubuntu-bugs
[06:56] <xxxxx1> oops
[06:59] <davmor2> asac:  In tribe 1.  You selected your network typed in the passphrase then created a password for gnome-keyring then when you restart the machine you type in the keyring password.  Now however I get a thing that says allow nm-applet to conect to keyring then nm-applet puts up the network passphrase window again.
[07:00] <pitti> davmor2: sounds like the same bug asac and seb128 have already discussed in #u-desktop
[07:00] <pitti> davmor2: essentially 'g-keyring never remembers any password'
[07:00] <Hobbsee> bryce: i was about to offer to test X.  on the other hand...if this is my only linux partition, on my only machine, perhpas that's not so wise
[07:01] <pitti> davmor2: gicmo and seb128, actually, but nevermind
[07:01] <pitti> Hobbsee: live CDs rock :)
[07:01] <Hobbsee> pitti: that they do
[07:01] <gicmo> davmor2: yep, I have that bug here ;-)
[07:02] <davmor2> gicmo:  Thank god I thought I was going mad
[07:02] <gicmo> pitti: and the latest keyring update doesnt help either ;-/
[07:04] <bryce> Hobbsee: yeah I make sure to do X testing on my non-main box just in case
[07:04] <Hobbsee> heh :)
[07:04] <bryce> Hobbsee: although so far I've been lucky
[07:04] <bryce> Hobbsee: but I know from experience that won't last ;-)
[07:05] <Hobbsee> bryce: haha
[07:05] <Hobbsee> bryce: i dont remember an X breakage since dapper.  so i think i've been lucky here too
[07:05] <Hobbsee> maybe it was edgy
[07:05] <Hobbsee> yes, i think it was.  dapper was just well known for apt segfaulting.
[07:05] <LaserJock> dapper-updates was the infamous one
[07:06] <Hobbsee> i stopped running dapper when -updates were being pushed thru
[07:06] <Hobbsee> LaserJock: i was meaning during development
[07:06] <Hobbsee> and feisty was known for the ZOMG My kernel doesnt boot breakage
[07:06] <Amaranth> and non-working cdrom drives
[07:08] <Hobbsee> i never heard much of that one
[07:36] <mlots> What tool(s) was(/were) used to create start.exe?
[08:09] <ulaas> asac, living?
[08:29] <geser> Mithrandir: which debian-mirror is used when packages are synced from Debian?
[08:31] <mikmorg> hello.
[08:34] <pygi> geser, just archive.debian.org ?
[08:36] <keescook> hunh.  network manager is spawning "ifconfig" as fast as it can...
[08:38] <geser> pygi: archive.debian.org aka ftp.debian.org is missing the package I want to sync but e.g. ftp.de.debian.org has it
[08:38] <pygi> geser, aha :-/
[08:39] <keescook> ah, root filled up and freaked NM out.  odd
[08:45] <LaserJock> geser: like completely removed?
[08:45] <LaserJock> or just that version/
[08:49] <geser> LaserJock: only the last version
[08:58] <LaserJock> geser: is .de newer? as in, are they just in the middle of a sync?
[08:59] <geser> the package was uploaded 4 days ago
[09:09] <Amaranth> i love how every bug that mentions 'compiz' in the name is automatically reassigned to compiz when someone looks at it
[09:09] <Amaranth> s/name/description/
[09:13] <LaserJock> why not?
[09:13] <LaserJock> it's the weak link ;-)
[09:14] <crimsun> asac: yes, of course.  In the future, please go ahead.  I'm moving presently.
[09:30] <glatzor> how can I find all packages that have got a build dependency on python-distutils-extra? The latest version includes some api breaks and I would like to provide fixes for every package.
[09:30] <glatzor> I only now only of the packages that I converted myself to python-distutils-extra
[09:31] <LaserJock> glatzor: apt-cache rdepends ?
[09:32] <glatzor> LaserJock: this only returns binary packages, but I need build dependencies.
[09:33] <LaserJock> oh, sorry
[09:33] <LaserJock> apt-cache showsrc python-distutils-extra | grep Build-Depends
[09:35] <seb128> glatzor: http://people.ubuntu.com/~ubuntu-archive/germinate-output/gutsy/rdepends/python-distutils-extra/python-distutils-extra
[09:35] <bryce> heya glatzor!  welcome back :-)
[09:35] <geser> LaserJock: he looks for rbuilddepends
[09:35] <asac> crimsun: already done
[09:36] <geser> glatzor: http://damianv.com.ar/downloads/rbuildepend
[09:36] <LaserJock> geser: blah, I need no glasses or something, or maybe not waking up at 6:00am anymore
[09:36] <LaserJock> s/no/new/
[09:36] <seb128> geser: what is that?
[09:36] <seb128> geser: have you seen the url I copied ? ;)
[09:37] <glatzor> seb128: thanks
[09:37] <seb128> you're welcome
[09:37] <glatzor> you are my personal hero :)
[09:37] <geser> seb128: does it also work for universe packages?
[09:38] <geser> seb128: that url is a small script around grep-dctrl to find packages which build-depend on the argument(s)
[09:38] <seb128> geser: no, I think it's main only
[09:41] <geser> seb128: do you know which debian mirror is used for syncing packages?
[09:41] <seb128> geser: ftp.debian.org I think, but we stopped autosync now
[09:41] <seb128> geser: why?
[09:42] <geser> I want to file a sync request for libapache-mod-jk but the last version is missing on ftp.debian.org (but ftp.de.debian.org has it)
[09:42] <seb128> there is some syncs open already about which are in this case
[09:42] <seb128> open them anyway and let archive team deal with it
[09:43] <seb128> we will sync from an another mirror if required
[09:56] <davmor2> quick query.  I think I have an issue with synaptic but I'm not sure if it is synaptic or compiz causing the issue.  When you select a package and want to "mark recommended packages"  it doesn't.  so my question is it compiz or synaptic or a mixture of the 2
[09:58] <sn-> davmor2 this channel isn't really for support, please ask in #ubuntu
[09:59] <davmor2> sn-: I'm trying to track which so I can bug report it
[10:00] <sn-> davmor2 have you seen http://www.ubuntu.com/community/reportproblem ?
[10:02] <asac> any idea why my upload of flashplugin-nonfree hasn't been tried to build on amd64?
[10:02] <asac> https://launchpad.net/ubuntu/gutsy/+source/flashplugin-nonfree
[10:02] <asac> ?
[10:02] <asac> its Architecture: i386 amd64 now
[10:04] <sn-> asac i would assume because there is no 64bit flash currently
[10:04] <asac> haha
[10:04] <sn-> maybe gnash? im not sure
[10:04] <asac> no sorry ... i uploaded it in order to build it on amd64 :)
[10:05] <asac> look at .dsc file
[10:05] <asac> Architecture: i386 amd64
[10:05] <ajmitch> asac: maybe P-a-s?
[10:05] <ajmitch> I think there's an equivalent ubuntu blacklist
[10:05] <asac> ?
[10:06] <ajmitch> packages-arch-specific
[10:10] <ajmitch> asac: I think an archive admin needs to change it in soyuz, you'll have to dig one up :)
[10:13] <asac> ajmitch: ok ... will figure out. thanks
[10:57] <pygi> seb128, poke
[10:57] <seb128> pygi: hi
[10:57] <pygi> seb128, more questions for you if you have some time?
[10:57] <seb128> depend of the question, just ask ;)
[10:57] <pygi> what's the chance of dropping graveman and such completely unmaintained apps from the repos?
[10:57] <pygi> unmaintained = upstream unmaintained
[10:58] <seb128> what is the interest?
[10:58] <pygi> (and yes, I know you'll probably say they have the user base, and we can't drop, and such)
[10:58] <seb128> if they have no security bugs we have no workload
[10:58] <pygi> seb128, well, to stop explaining on all those countless bugs :-/
[10:58] <seb128> and some users might be using those
[10:58] <seb128> well, you can ignore bugs
[10:58] <pygi> seb128, as I said above, I knew you'd say that :P
[10:58] <pygi> oh wel, oki
[10:59] <seb128> maybe mail ubuntu-devel-discuss or ask on an user list if there is somebody using it
[10:59] <seb128> and if they would complain loud if we remove it
[10:59] <seb128> and make sure they have something to use in replacement covering all their usecases
[11:00] <pygi> seb128, let's just leave it for gutsy, and don't make such changes
[11:00] <pygi> for gutsy+1 we'll see what to do
[11:00] <seb128> k
[11:01] <seb128> what situation? lot of softwares, none so good?
[11:01] <seb128> nautilus-cd-burner works fine for what I've to do ;)
[11:03] <pygi> seb128, it works for you, but it doesn't for many others :)
[11:03] <seb128> we get very few complains about n-c-b nor working
[11:03] <seb128> it just lacks features for some usecases
[11:03] <pygi> seb128, do we have all those "features it's lacking" on malone?
[11:04] <seb128> not sure
[11:04] <seb128> upstream rejected some ideas, they want to keep it simple
[11:04] <seb128> not start adding option for multi-session, etc
[11:04] <pygi> meh, upstream isn't even responding :-/
[11:04] <pygi> right, right
[11:04] <seb128> it's a "right click on an iso and record it"
[11:05] <seb128> and "dnd your datas and record"
[11:05] <pygi> yes, mostly
[11:06] <seb128> graveman doesn't get that many bugs it looks like
[11:06] <pygi> that's a lot of notes that I have :-/
[11:07] <pygi> seb128, true, but probably mostly due to fact that it's not used much
[11:08] <pygi> no idea tho, as I said ... it's fine for now
[11:08] <pygi> I'll need to see what (if anything) I can do for gnome cd-recording software for gutsy+1 or so
[11:08] <seb128> are you trying to keep only on CD burning software in the archive? ;)
[11:09] <pygi> seb128, no, I have my plans for the future in other areas as well. 
[11:09] <pygi> seb128, but this is where currently I have most influence and I can solve this mess :)
[11:10] <seb128> the easy way to solve it is to write a rocking software
[11:10] <seb128> so people stop using old unmaintained one
[11:10] <pygi> well, what do you think I've been doing all this time? :)
[11:10] <seb128> and we can clean everything
[11:10] <seb128> don't bother too much about cleaning other ones
[11:11] <seb128> just get yours on the default desktop
[11:11] <seb128> and have user happily using it
[11:11] <seb128> and then other ones will be easy to clean
[11:11] <pygi> seb128, hehe, well I'm working on gtk cd-recording app :)
[11:11] <pygi> patience tho :)
[11:13] <pygi> seb128, any other area you need solved/fixed? ^_^
[11:13] <pygi> I think we'll be able to package redesigned-nautilus for gutsy+1 as well :)
[11:14] <seb128> pygi: "we" being?
[11:14] <seb128> pygi: gvfs will be nice ;)
[11:14] <pygi> seb128, the ubuntu folks? :)
[11:15] <seb128> pygi: you can try to solve the windows network integration
[11:15] <seb128> easy samba sharing and browsing
[11:15] <pygi> seb128, ergh, gvfs is still amoving target :-/
[11:15] <pygi> seb128, that's no fun. How to test it without windows? :)
[11:15] <pygi> a moving*
[11:15] <geser> pygi: have you seen Debian bug #427064?
[11:15] <ubotu> Debian bug 427064 in ftp.debian.org "RM: graveman -- RoM; abandoned upstream; unmaintained; has alternatives" [Wishlist,Open]  http://bugs.debian.org/427064
[11:16] <pygi> geser, no, thank you
[11:18] <pygi> geser, oh well, we can leave for gutsy as far as I'm concerned
[11:18] <pygi> for gutsy+1 we'll push forward something else as desktop's default
[11:19] <ScottLij> How does one get involved with Ubuntu development?
[11:20] <geser> What's the policy for packages removed from Debian? I usually file remove requests when I find such packages
[11:20] <pygi> ScottLij, http://www.ubuntu.com/contribute
[11:21] <seb128> geser: we tend to remove them when Debian do
[11:21] <pygi> or something :)
[11:21] <geser> ScottLij: see https://wiki.ubuntu.com/MOTU and join #ubuntu-motu
[11:21] <ScottLij> pygi, thanks, I was reading that but I can't find a page on how to get a "sponsor"
[11:21] <pygi> ScottLij, http://www.ubuntu.com/community/participate
[11:21] <persia> seb128: Is that automated in some way?
[11:21] <pygi> ScottLij, go to #ubuntu-motu
[11:21] <ScottLij> Thanks
[11:22] <seb128> persia: no
[11:22] <persia> seb128: Thanks.
[11:22] <seb128> you're welcome
[11:22] <pygi> persia, he gets too many "thanks" :P
[11:23] <pygi> seb128, I'll work next week to help dholbach with telepathy bits a bit
[11:23] <geser> pygi: if you want to get graveman removed you have with the Debian bug a good argument for it
[11:23] <pygi> geser, it's not about the argument here. It's about users.
[11:25] <seb128> pygi: excellent ;)
[11:25] <geser> pygi: does it help our users if we ship abandoned software in gutsy?
[11:25] <seb128> geser: if there is no better alternative, yes
[11:25] <geser> we probably won't be able to fix any reported bugs in it
[11:25] <pygi> geser, not probably, but surely
[11:26] <pygi> seb128, Brasero is supposed to be that (a better alternative) but they messed up big time with newest version
[11:27] <seb128> pygi: I'm not convinced many people use brasero yet
[11:27] <seb128> that's why I said that having a mail on an user list would be nice ;)
[11:27] <pygi> seb128, I kindof am, but I do agree it's not ready for default
[11:27] <seb128> just to know what users are doing
[11:27] <pygi> seb128, sure, I'll send a mail, don't worry :)
[11:28] <pygi> seb128, https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/91043
[11:28] <ubotu> Launchpad bug 91043 in brasero "Install Brasero by default" [Wishlist,New]  
[11:28] <pygi> I do assume you saw this?
[11:29] <seb128> pygi: yes, bugs are not the right place for such requests though
[11:29] <seb128> pygi: better to mail ubuntu-devel ;)
[11:29] <pygi> geser, graveman is unmaintained. *I* won't take care of it's bugs.
[11:29] <pygi> geser, good enough? :)
[11:29] <pygi> seb128, hehe, right :)
[11:30] <pygi> Well, I'll mail the users list tomorrow
[11:30] <seb128> the comments are not nice though
[11:30] <seb128> "Right now brasero isn't really maintained "
[11:30] <pygi> seb128, that's what I said :P
[11:30] <pygi> read who said it :)
[11:30] <seb128> yeah
[11:31] <pygi> seb128, don't worry, when I have something I believe is worth of main ... I'll have strong reasons :)
[11:32] <seb128> ;)
[11:32] <pygi> seb128, for example, xfburn is not worth of main currently, although it is in it
[11:32] <pygi> it's not even worth of universe in such state
[11:33] <pygi> i.e. it can't really burn a cd
[11:33] <seb128> pygi: it's a xubuntu decision ...
[11:33] <pygi> seb128, yea, I talked with Jani :-/
[11:33] <pygi> he wanted me to propose a replacement, but ergh ... no real lightweight solution for them :(
[11:34] <Aladin> Why is the package for the netbeans application named "netbeans5.5"? I think it has to be named just "netbeans". Like firefox, etc...
[11:35] <pygi> Tonio_, hey!
[11:35] <pygi> you got my mail about k3b?
[11:36] <Tonio_> yop pygi :)
[11:36] <Tonio_> pygi: yeah, that's on my todo for tomorrow
[11:36] <Tonio_> pygi: but I have other emergencies to work one unfortunatelly...
[11:36] <Tonio_> pygi: I'm very very late on my kubuntu work
[11:36] <pygi> Tonio_, don't worry, really
[11:36] <LaserJock> Aladin: some things are named that way when there could be multiple versions in the archive
[11:36] <pygi> I'll be happy if you could get time any day to answer my mail
[11:37] <pygi> Tonio_, I'd really like to get that rocking :)
[11:38] <LaserJock> Aladin: for instance sun-java5 and sun-java6
[11:39] <Tonio_> pygi: will do tomorrow, no pb :
[11:39] <Tonio_> :)
[11:40] <pygi> Tonio_, yay, fantastic :)
[11:40] <pygi> Tonio_, then we can discuss and work on that :)
[11:41] <Tonio_> yup :)
[11:42] <Tonio_> pygi: but I prefer to be honnest, that'll not be the priority
[11:42] <pygi> Tonio_, look ... it'll be my priority :)
[11:42] <Tonio_> pygi: I have work on network-manager, I have to repackage kdepim, including opensync/syncml support, and then also finish the kdesudo integration to kubuntu
[11:42] <pygi> Tonio_, basically I wanted ack's to work on it :)
[11:42] <Tonio_> pygi: all of that is very important stuff :)
[11:42] <pygi> Tonio_, do look what I just said :p
[11:43] <Tonio_> pygi: but I'm perfectly fine following you and helping you on this
[11:43] <Tonio_> pygi: read it don't mind
[11:43] <pygi> Tonio_, ok, but I just need the way how to do it
[11:43] <pygi> Tonio_, would you agree on completely repackaging and diverging from debian?
[11:43] <pygi> and you did saw in my mail where I state that patches aren't working, although they're supposed to :-/
[11:44] <Tonio_> pygi: I'd say no, sorry....
[11:44] <pygi> Tonio_, ah :(
[11:44] <pygi> Tonio_, so I gotta fix the current package to make it work?
[11:44] <Tonio_> pygi: best would be to take contact with debian and try to get your changes synced with debian
[11:44] <Tonio_> pygi: no problem to change the all packaging as long as you do the required stuff to get it merge with debian :)
[11:44] <pygi> Tonio_, ubuntu package diverges a lot from debian already
[11:44] <pygi> Tonio_, haha, ok, I'll mail k3b maintainer :)
[11:45] <pygi> that's what I did when I wanted cdrskin support built directly into k3b ^_^
[11:47] <pygi> Tonio_, afaik I'm not sure our patches get applied at all :-/
[11:47] <pygi> perhaps the patching procedure is bad since that's what we added
[11:47] <pygi> (i.e. no idea who specifically but ...)
[11:48] <Tonio_> pygi: no problem concerning the patches as long as you propose them
[11:48] <Tonio_> pygi: they can have their own reasons to reject
[11:48] <Tonio_> pygi: but it is important to keep the same packaging style and structure
[11:49] <Tonio_> pygi: means, don't change the packages naming/splitting, don't change the patch system used etc....
[11:50] <Tonio_> pygi: there is no problem having our own patches, but we should at least propose them to the debian maintainer, for less work on package maintaining in the future :)
[11:50] <pygi> Tonio_, ergh, you don't get it
[11:50] <pygi> Tonio_, a)we already diverge in a lot of stuff regarding packaging methods (i.e. patching methods)
[11:51] <pygi> b)we ship tons of packages, none seem to work (i.e. I assume they don't applied at all due to buggy patching methods)
[11:51] <pygi> that's the state how I got k3b. Did not touch it at all before, so didn't knew that
[11:51] <pygi> but it's messy :P
[11:51] <Tonio_> pygi: hum interesting.....
[11:51] <Tonio_> pygi: lemme have a look at the package...
[11:52] <pygi> Tonio_, ergh, the b) was supposed to state that we ship a lot of patches, not packages :p
[11:52] <Tonio_> pygi: is the packaging cdbs based ?
[11:52] <pygi> Tonio_, debhelper
[11:52] <Tonio_> pygi: I switched the packaging to cdbs a long time ago
[11:52] <pygi> Tonio_, ergh?
[11:53] <Tonio_> pygi: argh.... that's due to the sync with debian for the 1.0 version....
[11:53] <Tonio_> pygi: I didn't do that one....
[11:53] <pygi> Tonio_, meh!
[11:53] <pygi> Tonio_, this k3b package is *broken*
[11:53] <pygi> and afaik, we should just blacklist k3b
[11:53] <pygi> same thing I did for brasero
[11:54] <Tonio_> pygi: best thing would be to first switch the packagint to cdbs then, and propose that to debian
[11:54] <Tonio_> pygi: the way the patches are applied is just ugly....
[11:54] <pygi> Tonio_, yay, you agree with me!!!
[11:54] <Tonio_> pygi: I'm not even sure all the patches are level 1 by the way
[11:54] <pygi> Tonio_, well, they don't get applied :P
[11:55] <Tonio_> pygi: there is absolutly no reason to package with debhelper only nowaday
[11:55] <Tonio_> cdbs is much better
[11:55] <pygi> Tonio_, see? We agree then ^_^
[11:55] <pygi> Tonio_, what was the package where you introduced cdbs?
[11:56] <Tonio_> pygi: apt-get source k3b
[11:56] <Tonio_> then go in the sources root, and do a fakeroot debian/rules configure
[11:56] <pygi> Tonio_, I'll see what I can do to it next week, fix, upgrade, and such ... temporary blacklist, and talk with debian
[11:57] <Tonio_> pygi: you'll see why the patches don't apply, that's not a problem with the rules file, it's a problem with the patches, they need to be rewritten
[11:57] <Tonio_> pygi: okay I don't want to waste my time on this
[11:57] <pygi> Tonio_, hehe, ok
[11:57] <Tonio_> pygi: I have an hour, do you want me to switch to cdbs, fix the patches and let you finish that ?
[11:57] <pygi> don't worry :)
[11:57] <pygi> Tonio_, if you want, sure
[11:58] <Tonio_> let's go :)
[11:58] <pygi> great :)
[11:58] <Tonio_> pygi: just one thing I don't understand.... how can the package build if the patches fail to apply ?
[11:58] <Tonio_> pygi: the package should ftbfs on the buildd
[11:59] <pygi> Tonio_, I'm not *officially* sure that they fail to apply, but the effect is missing
[11:59] <pygi> for example the patch which removes cdrecord suid stuff ... it's still shown on gutsy
[11:59] <pygi> and it shouldn't be due to that patch
[11:59] <pygi> Tonio_, looking at the patch reveals that it should work since those lines are commented out
[11:59] <Tonio_> pygi: I can confirm they fail to apply
[12:00] <pygi> Tonio_, well, as I said ... messy debian/rules?
[12:00] <Tonio_> http://paste.tonio.homelinux.org/120
[12:01] <Tonio_> pygi: strange btw, the build should fail.... let's go with a modern packaging.... I'm sick of seeing modern apps using such an obsolete packaging structure :)
[12:01] <pygi> Tonio_, o and yes ... that normalize stuff effect is missing as well
[12:01] <pygi> Tonio_, great :)
[12:01] <Tonio_> pygi: that's a patch right ?
[12:01] <pygi> Tonio_, yes
[12:01] <Tonio_> i they don't apply, no reason for that to work :)
[12:02] <pygi> #
[12:02] <pygi> APPLYING PATCH: kubuntu_101_rename_normalize.diff
[12:02] <pygi> #
[12:02] <pygi> patching file libk3b/core/k3bdefaultexternalprograms.cpp
[12:02] <pygi> #
[12:02] <pygi> Hunk #1 succeeded at 702 (offset -13 lines).
[12:02] <pygi> #
[12:02] <pygi> Hunk #2 succeeded at 717 (offset -13 lines).
[12:02] <pygi> #
[12:02] <pygi> Hunk #3 succeeded at 731 (offset -13 lines).
[12:02] <pygi> that patch does apply, but it's wrong IMHO
[12:02] <pygi> I think I have a sane solution
[12:02] <pygi> Tonio_, switch to cdbs, clean it up, rewrite some patches if you can, and lemme handle the rest then
[12:02] <pygi> I'll additionally clean it up, rewrite/fix some patches, add new ones I think should be there, talk with debian and such
[12:03] <Tonio_> pygi: will do
[12:03] <Tonio_> pygi: I think we are in freeze atm right ? so I'll have to wait a bit for uploading :)
[12:03] <pygi> Tonio_, don't worry about upload
[12:03] <pygi> you'll just mail me all the files I need :)
[12:03] <pygi> i.e. debdiff will do just fine :)
[12:03] <Tonio_> pygi: I'll probably create a packaging branch on code.launchpad.net/~kubutu-members then
[12:03] <Tonio_> pygi: just watch there what happens
[12:03] <pygi> k