[00:00] <seb128> I think that's the reason why GNOME did it the way it's done now
[00:00] <kees> I totally hear you, and I understand their reasoning.  I just happen to disagree.
[00:00] <seb128> do we have any upgrade plan to not let those users down?
[00:01] <kees> pitti was pondering things like modification time, but that's likely to be fragile.
[00:01] <seb128> I don't like much dictating things to user without letting them decide if they really have a reason to do what they are doing
[00:02] <seb128> it's like saying you don't want to let user delete files because they could delete something they don't want to ;-)
[00:03] <kees> I come down on the side I do because of: http://www.codinghorror.com/blog/archives/000347.html
[00:03] <jcastro> kees: is there a discussion in upstream gnome someplace that you are aware of?
[00:04] <kees> jcastro: not this part.  Gnome had their discussion and implemented what's currently in nautilus.  they felt it was a good middle ground.
[00:04] <kees> It probably is a good middle ground, but it's not one I agree with.
[00:04] <kees> and note that Gnome is only a small part of this.  it also affects wine, sun-java6, and openjdk-6.
[00:04] <kees> and probably KDE, but I haven't looked there yet.
[00:04] <jcastro> well, it's our right to do what we want. I think it just needs to be communicated properly
[00:04] <jcastro> like, in the patch tags or whatever.
[00:05] <seb128> well I think we should engage with upstream because deciding we disagree with them without trying to talk to them first
[00:05] <seb128> because -> before
[00:05] <jcastro> so that it's clear to an upstream that we think X and Y are better default behaviors
[00:05] <kees> seb128: yup, agreed.
[00:06] <seb128> though for the record I'm leaning toward of the side of what GNOME did right know
[00:06] <jcastro> seb128: really? I personally hate that button
[00:06] <seb128> your change will just annoy users who have good reason to run things they run
[00:06] <seb128> and will not stop those who want to run cracks to chmod the files anyway to get there
[00:07] <seb128> jcastro, why would you click on a .desktop if that's not to use it?
[00:07] <kees> it's a matter of decided how high to make the barrier to see the dancing bunnies.
[00:07] <kees> a single button click is way too low.
[00:07] <seb128> jcastro, or do you get many people who try to screwed you by sending fake softwares this way?
[00:07] <jcastro> seb128: all the .desktops I click on come with the distro
[00:07] <seb128> jcastro, so you should never see that button
[00:07] <jcastro> seb128: no but you get people starting to post random debs on the internet, etc.
[00:08] <seb128> well the button should not be displayed for system path
[00:08] <seb128> because if somebody got right to write to usr you are screwed anyway
[00:08]  * jcastro nods
[00:08] <seb128> not sure when you get the button display or why you hate it ;-)
[00:08] <seb128> it should just be there is weird cases
[00:09] <seb128> those being files you have in your user dir since before the change to make things +x
[00:09] <seb128> or things people emailed you to trick you in doing something
[00:10] <jcastro> wel we could argue all day, I just think it needs to be documented in the patch, pointing to rationale, our policy, etc. and also mentioned in the release notes and all that
[00:10] <seb128> jcastro, I've no personal strong opinion, I don't think I ever got that dialog
[00:10] <cjwatson> bryyce: is there any revision control for the changes between xorg-server 1.6.4-2 and 1.6.4-2ubuntu4?
[00:10] <cjwatson> bryyce: (exactly why I want that is a long story ...)
[00:10] <seb128> but alex is a pretty reasonable guy usually and did the design they have know for a reason
[00:10] <jcastro> as long as it's clear to people that we've decided to make it behave that way
[00:11] <seb128> the discussed started because I didn't know about the change and I don't agree with it
[00:11] <seb128> I've understood by now that I'm going to be overruled there though ;-)
[00:11] <jcastro> seb128: also, if it's been talked about for like 3 UDSes and no one has had a discussion with upstream then we should fix that
[00:12] <kees> jcastro: to be honest, there wasn't a decision about Ubuntu's policy until today.
[00:12] <seb128> jcastro, neither with community desktopers in ubuntu apparently
[00:12] <seb128> anyway I've annoyed people enough about that
[00:12] <seb128> kees, sorry for complaining, thanks for getting me updated on that
[00:12] <jcastro> kees: yeah, we just need to remember that upstreams typicall won't read all our UDS notes, and it doesn't hurt to tell them early when we're considering things
[00:13] <seb128> I will talk to pitti about communications issues on the change tomorrow
[00:13] <slangasek> cjwatson: should all be in git, AIUI
[00:13] <kees> seb128: sure, no problem.  there's still plenty to be further discussed.
[00:13] <cjwatson> slangasek: I did look and couldn't find that particular set of revisions
[00:13] <bryyce> cjwatson, I believe so; it should be in our git repo
[00:14] <cjwatson> bryyce: if you could give me a SHA-1 for the head of that particular series, I'd appreciate it
[00:14] <bryyce> cjwatson, what's the issue?
[00:14] <kees> jcastro: right, and seb128's right, I need to open an upstream bug.  that said, i'd like to hear what pitti has been thinking about.
[00:14] <cjwatson> bryyce: I've got git+ssh://git.debian.org/git/pkg-xorg/xserver/xorg-server.git, but haven't been able to track it down
[00:14] <cjwatson> bryyce: revision control import for another project
[00:15] <jcastro> kees: it's a weird line to walk, sometimes they're like "don't bother me with this little stuff" and then it'll be "why didn't you tell me about this?"
[00:15] <jcastro> kees: so I err on the spammy side. :p
[00:16] <ScottK> Having been in some of the discussions at various UDS sessions, I think this is a good change.  Part of the evolution from thinking of a secure system as protecting the root to protecting the user data too.
[00:16] <kees> jcastro: sounds good to me.
[00:19] <bryyce> cjwatson, a2b67de0ce18b71895ec210b74095f9d41042070 looks like it is the head for the 1.6.4-2ubuntu1 release
[00:23] <bryyce> cjwatson, hmm looks like I don't have git history for the subsequent changes in 1.6.4
[00:24] <Bsims> I am trying to launch openvasd it can't download the plugins any help I am on ubuntu and using the packaged debs
[00:24] <cjwatson> bryyce: ok.  thanks!
[00:24] <Bsims> should I go ahead and file a bug report
[00:24] <bryyce> mm e6693c767e1a3fe2f02ae93fa7a6f7886d3fdebd is the ubuntu5
[00:24] <bryyce> there we go, that's what you probably want; that includes kees' fix to xvfb
[00:25] <Bsims> openvas-nvt-sync does not exist nor is findable by synaptic or locate
[00:26] <bryyce> cjwatson, ah nevermind, yes all the 1.6.4-2ubuntuX changes are in there.  that e6693 is what you want
[00:27] <cjwatson> bryyce: looks like a few revs back from that
[00:28] <cjwatson> bryyce: 3a4400f0193c413f57c6109afe80c6a1142b31bf AFAICS
[00:29] <cjwatson> bryyce: but perfect, thanks
[00:29] <bryyce> great
[00:31] <slangasek> Bsims: you probably want #ubuntu; this is not a help channel
[00:31]  * Bsims nods fair enough, just debating filing a bug report on it... and was double checking here first
[00:46] <functionofxy> hello--I'm a member of ubuntu manual, but I've got a general bzr question
[00:46] <functionofxy> I branched, edited, committed, pulled, merged, committed
[00:47] <functionofxy> now do i push or send?
[00:47] <slangasek> functionofxy: 'push', if you have commit access
[00:48] <functionofxy> bzr: ERROR: No push location known or specified.
[00:48] <cjwatson> bzr push :parent
[00:49] <cjwatson> (the first time; it'll remember it for later tries, so 'bzr push' will be sufficient afterwards)
[00:49] <functionofxy> fantastic
[00:49] <functionofxy> thanks
[00:49] <cjwatson> that rune means "push to where you branched from"
[00:50] <functionofxy> got it! so easy
[01:06] <TheMuso> Well you learn something new every day. I didn't know you could do that with bzr.
[01:08]  * micahg is glad to know that as well :)
[01:18] <Riddell> pitti, cody-somerville: could you argue over bug 476530 and decide if it deserves an SRU?
[02:58] <genii> Interesting. http://linux.dell.com/files/ubuntu/ has a Lucid directory
[04:09] <Flannel> Hey guys, why's sreadahead -> ureadahead taking place mid-release in karmic?
[07:14] <wolter> Hi, I come in behalf of the ubuntu manual project. We would like to know whether there will be or not a synaptic package manager in Ubuntu 10.04 (Lucid Lynx)
[07:16] <Tm_T> in ubuntu-desktop install or in repositories?
[07:17] <wolter> In the ubuntu-desktop install
[07:18] <Tm_T> then I don't know for sure (:
[07:18] <wolter> Oh, thank you anyway. I will wait around here in case somebody can answer my question.
[07:19] <micahg> wolter: why don't you post to ubuntu-devel ML?
[07:20] <persia> wolter: It's very likely to be present, but until FeatureFreeze it cannot be said for sure, and even thereafter there is a chance of a Freeze Exception.
[07:20] <wolter> oh ok
[07:20] <wolter> When is FeatureFreeze?
[07:20] <persia> But last I checked, several other things that are expected to be present depended on synaptic, so it would be some work to have it not present.
[07:21] <persia> https://wiki.ubuntu.com/LucidReleaseSchedule
[07:23] <sladen> at /the moment/, synaptic is still pulled in my ubuntu-desktop, and gnome-app-install, and ... and ...  (see  apt-cache rdepends synaptic)
[07:24] <persia> Yeah.  It's rather unlikely to be removed.
[07:34] <pitti> Good morning
[07:36] <StevenK> Hi pitti!
[07:38] <pitti> hey StevenK
[07:42] <pitti> cody-somerville, Riddell: replied in SRU bug, waiting for Cody's answer
[07:44] <dholbach> good morning
[07:48] <cemc> I saw this bug #96850 on here http://qa.ubuntu.com/reports/sponsoring/ , and make a comment with a debdiff, if anybody wants to take a look.
[08:49] <lucas> hi, does someone make some sense out of https://bugs.launchpad.net/ubuntu/+source/ruby1.8/+bug/498758 ?
[08:57] <MacSlow> slangasek, bryyce, tseliot: any (positive) news on the GL/GLX/mesa issue?
[08:57] <tseliot> MacSlow: what issue?
[08:58] <tseliot> bug #506547 ?
[08:58] <tseliot> or maybe something else?
[08:58] <MacSlow> tseliot, yup and https://bugs.edge.launchpad.net/ubuntu/+source/mesa/+bug/258038
[08:59] <persia> lucas: It looks like an incomplete update to me, where the users are trying to install ri1.8 from karmic-updates and rdoc1.8 from karmic
[08:59] <MacSlow> tseliot, which is related according to bryyce
[08:59] <lucas> persia: yup, I just figured out that one is in universe and the other in main
[08:59] <lucas> persia: which could explain
[08:59] <persia> That would definitely explain it, yes.
[08:59] <slangasek> MacSlow: 258038> err, that bug number's a little old to be related to the current problems?
[09:00] <tseliot> MacSlow: 258038 should be fixed. The other bug can be fixed with a symlink until I fix it in the package
[09:00] <MacSlow> tseliot, I currently cannot run any GL-apps I compiled on my system
[09:00] <tseliot> MacSlow: what's the error?
[09:01] <MacSlow> tseliot, "BadMatch"-error when trying to run any compiled GL-apps
[09:01]  * MacSlow -> conf-call
[09:01] <slangasek> MacSlow: what version of xserver-xorg-core do you have installed?
[09:01] <persia> lucas: The confusing bit is that jackerran reports that ri1.8 is hunting rdoc1.8, but a version that isn't available.  I don't understand why someone would have universe-updates enabled and not main-updates.
[09:02] <tseliot> MacSlow: do they work if you recompile them? We have switched to a new version of mesa
[09:02] <slangasek> "if you recompile them" - eew? :)
[09:02] <lucas> persia: user error? :-)
[09:02] <tseliot> slangasek: BTW I'll fix 506547 and other mesa bugs after alpha 2. I'll focus on the release notes now
[09:03] <tseliot> slangasek: yes, if he rebuilds them against the new mesa
[09:03] <MacSlow> tseliot, after two days of getting my system working again (after I upgraded from Karmic to Lucid) I'm a bit (actually very) afraid to pull anything else from the repo... haven't been able to do real work due to all the fixing (not only GL-related though)
[09:03] <persia> lucas: heh.  Quite possibly.
[09:03] <slangasek> tseliot: having to rebuild anything would make this a non-starter option
[09:04] <tseliot> slangasek: I was just asking ;)
[09:04] <slangasek> tseliot: but if you're fixing 506547, then ok - but how/why is this still broken at all?
[09:04] <MacSlow> slangasek, xserver-xorg 1:7.5+1ubuntu1
[09:04] <slangasek> MacSlow: xserver-xorg-core, not xserver-xorg
[09:05] <tseliot> slangasek: because libGLU was not supposed to be moved to /usr/lib/mesa. When you switch to nvidia, /usr/lib/GL won't point to /usr/lib/mesa anymore and you will lose libGLU :-/
[09:05] <slangasek> ah
[09:05] <tseliot> but it's ok with open drivers
[09:06] <slangasek> tseliot: that sounds like the sort of bug that we ought to have the fix for uploaded before alpha-2 (even if not included on the ISOs), because otherwise we're going to get a lot more noise resulting from users trying to fix it themselves
[09:06] <slangasek> hmm, maybe not though; I guess dpkg would correctly overwrite the "quick fix" proposed in that bug
[09:07] <MacSlow> slangasek,  2:1.7.3.902-1ubuntu4
[09:08] <MacSlow> njpatel, ping
[09:08] <tseliot> slangasek: as you prefer
[09:09] <slangasek> tseliot: if the fix for this is solid, I still think getting it uploaded will save a lot of tester / triager time
[09:09] <slangasek> it's likely to generate a lot of duplicate bugs despite being in the errata
[09:10] <tseliot> MacSlow: I would like to see the output of "ldconfig -p |grep GL" and ls -l "/usr/lib/ |grep GL"
[09:10] <tseliot> slangasek: by when should this be ready?
[09:11] <slangasek> tseliot: getting it right on the first (well... next ;) upload is more important than having it fast; I'm not concerned about getting this on the CD, just in the archive before tomorrow
[09:11] <MacSlow> tseliot, one sec
[09:12] <slangasek> MacSlow: you're behind a version on the server, then; you should definitely upgrade to -1ubuntu5, though it may not fix this particular problem
[09:13] <MacSlow> tseliot, https://pastebin.canonical.com/26466 https://pastebin.canonical.com/26467
[09:13] <MacSlow> slangasek, when was -1ubuntu5 uploaded?
[09:16] <tseliot> slangasek: ok
[09:16] <slangasek> MacSlow: yesterday
[09:17] <tseliot> MacSlow: what happens if you uninstall nvidia-current-dev and do a "sudo ldconfig"?
[09:18] <tseliot> MacSlow: also, are the programs that fail compiled for 32bit?
[09:21] <ttx> ara: hey -- what does the "Started" result mean in the ISO tracker ?
[09:22] <ttx> ara: are we supposed to set that status when starting a test ?
[09:24] <AnAnt> Hello, is any of apport devs here ?
[09:26] <tseliot> AnAnt: maybe ask pitti?
[09:28] <AnAnt> pitti: ping
[09:28] <AnAnt> I am trying to make apport-collect be able to read crash report from a file
[09:29] <pitti> AnAnt: hi
[09:30] <pitti> AnAnt: and attach it to an existing bug?
[09:30] <AnAnt> pitti: yup
[09:30] <pitti> AnAnt: because for reporting a new one you'd just do ubuntu-bug foo.crash
[09:30] <AnAnt> I am pastebin'ing thd diff now
[09:31] <AnAnt> Here http://pastebin.com/f3d6ecdbe
[09:31] <AnAnt> yet I get an error when running it
[09:31] <AnAnt> that's the error: http://pastebin.com/f651c145
[09:32] <AnAnt> can you help with what is wrong ?
[09:40] <pitti> AnAnt: you shouldn't call add_hooks_info() there; it should already be in the .crash file
[09:40] <AnAnt> ah
[09:41] <pitti> AnAnt: hm, but still the crash ought to have a ProblemType: field
[09:41] <pitti> AnAnt: also, apport-collect calls crashdb.download(); it should not do that when reading the info from a file
[09:42] <pitti> AnAnt: hmm
[09:42] <pitti> AnAnt: so, usually you need to open a crash file with apport-gtk first, so that it adds Package:/Dependencies:/hook info, etc.
[09:42] <AnAnt> ok, I removed report.add_hooks_info(None) line
[09:43] <pitti> AnAnt: if you want to use apport-collect on a freshly produced .crash file, then you'd need to do all of those, not just hooks
[09:43] <pitti> but then you can only report it from the same machine
[09:43] <pitti> AnAnt: what's the use case, btw? I didn't get a request for calling apport-collect on a crash report yet
[09:44] <pitti> since it should all be there in the original report
[09:45] <AnAnt> pitti: the same use case of reporting a new bug on LP , but this time I want to add info to an already existing bug
[09:45] <pitti> AnAnt: but this is not a bug, it's a crash report
[09:47] <AnAnt_> sorry, I got disconnected
[09:47] <AnAnt_> 11:45 <AnAnt> pitti: it is a report created by manually running: ubuntu-bug <pid>
[09:47] <pitti> AnAnt_: ah, I see; with --save ?
[09:47] <pitti> but those also shold have a ProblemType: field
[09:48] <AnAnt_> pitti: I didn't run it with --save, I just run ubuntu-bug <pid> , then when it asked to submit/view/keep/quit, I chose keep
[09:48] <pitti> AnAnt_: at some point I wonder whether to completely drop apport-collect and integrate it into apport-bug with a -b/--bug 12345 option
[09:48] <pitti> AnAnt_: right, that's the same result
[09:49] <MacSlow> tseliot, I currently can't "play around" with uninstalling stuff etc. but the failing programs are compiled for 64bit
[09:49] <AnAnt_> pitti: I just opened the crash file with vim, it does have a ProblemType field: ProblemType: Bug
[09:49] <AnAnt_> pitti: does the load() method require a full path to file ?
[09:50] <tseliot> MacSlow: is Badmatch error all you get? Can I see the full error, please? Also does the nvidia driver work for you (with compiz, etc.)?
[09:51] <AnAnt_> pitti: no, it's not a full path problem
[09:52] <pitti> AnAnt_: ah, you need to do .load(open(crash_file))
[09:52] <pitti> it takes an fd
[09:52] <AnAnt_> thanks !
[09:53] <MacSlow> tseliot, https://pastebin.canonical.com/26468
[09:53] <AnAnt_> pitti: it works \o/ thanks a lot !
[09:54] <tseliot> MacSlow: you shouldn't use LD_LIBRARY_PATH=/usr/lib/mesa because you're using nvidia
[09:54] <tseliot> and ldconfig should know where to find the right libraries
[09:54] <MacSlow> tseliot, it does not
[09:54] <AnAnt> pitti: the result is in LP #492271
[09:55] <tseliot> MacSlow: ldconfig -p seems to think otherwise ;)
[09:55] <AnAnt> persia: thanks to you too for the tip on -bugs
[09:55] <tseliot> MacSlow: anyway, since you're using that variable, try this: LD_LIBRARY_PATH=/usr/lib/nvidia-current ./gl-particles
[09:55] <MacSlow> tseliot, ./gl-particles
[09:55] <MacSlow> ./gl-particles: error while loading shared libraries: libGLU.so.1: cannot open shared object file: No such file or directory
[09:56] <tseliot> MacSlow: that's where I wanted to get. Which is the bug I was discussing with slangasek
[09:56] <MacSlow> 1> LD_LIBRARY_PATH=/usr/lib/nvidia-current ./gl-particles
[09:56] <MacSlow> ./gl-particles: error while loading shared libraries: libGLU.so.1: cannot open shared object file: No such file or directory
[09:56] <tseliot> MacSlow: there's a quick fix for that
[09:56] <tseliot> MacSlow: ln -s /usr/lib/mesa/libGLU.so.1 /usr/lib
[09:57] <tseliot> then try again (there's no need to use LD_LIBRARY_PATH)
[09:57] <MacSlow> tseliot, ok worked
[09:57] <tseliot> oh and do a "sudo ldconfig" just in case
[09:57] <tseliot> good
[10:01] <AnAnt_> pitti: btw, I've put the patch on LP #506885
[10:05] <pitti> AnAnt_: can you please assign it to me? Thanks1
[10:06] <AnAnt_> pitti: done
[10:17] <ogra> pitti, "Das Programm 'scsi' wurde unerwartet beended" ... is that something from devkit ?
[10:23] <pitti> ogra: no, sounds like a kernel thread?
[10:23] <ogra> ok
[10:23] <ogra> intrestingly scsi works fine :)
[10:24] <ogra> my rootfs is on a scsi disk
[10:30] <slangasek> NCommander: what's the status of dove for alpha-2?  bug #505772 is marked critical for a2, but I see no activity on it; and ogra says there are other problems?
[10:31] <ogra> slangasek, it will definately not be fixed in time since nobody really knows what the issue is yet
[10:32] <ogra> so i guess milestone can be moved already
[10:32] <slangasek> if that's so, please change the milestone
[10:32]  * ogra does
[10:33] <ogra> done
[10:34]  * jussi01 waves to ogra and wonders if ogra remembers him :D
[10:35] <ogra> bring my mind up to speed :)
[10:36] <jussi01> ogra: http://www.flickr.com/photos/8413078@N02/4126318257/in/set-72157622726510357/
[10:36] <ogra> thats not you ! :)
[10:36] <jussi01> *g*
[10:36] <jussi01> no, I was there though...
[10:36] <ogra> yeah
[10:37] <jussi01> have you seen that photo set before?
[10:37] <ogra> yep
[10:39] <slangasek> pitti, ArneGoetje: language-support-translations-{mk,oc} have deps on the corresponding NBS evolution-documentation-* packages - could this be fixed?  (I'm nuking the evolution-documentation-* packages from the archive, because they break kubuntu DVD building)
[10:40] <slangasek> language-support-translations-oc has no other deps, perhaps it should just be removed from the archive?
[10:49] <cjwatson> Flannel: we chose to do that, even though it was outside the usual pattern, because otherwise karmic was a significant boot speed regression from jaunty on many systems
[10:49] <cjwatson> Flannel: those systems being ones with rotational hard drives, i.e. the most common - and ureadahead was a really dramatic improvement on a lot of those systems with fairly minimal maintenance overhead (unlike readahead-list)
[10:56] <pitti> slangasek: yes, removing them soudns sensible to me; should I do this now?
[10:57] <pitti> slangasek: they are orphans indeed, langpack-o-matic doesn't have the packages any more
[10:57] <pitti> slangasek: removing
[10:58] <ev> Lucid very much hates me today. Can't get into X with plymouth, lots of graphical corruption in X, random resets, etc. :-/
[11:05] <pitti> ev: X> do you have /usr/lib/xorg/modules/extensions/libglx.so ? if not -> sudo apt-get install --reinstall xserver-xorg-core
[11:05] <pitti> ev: corruption> njpatel had that this morning, solved by dist-upgrading (mesa issue)
[11:12] <ev> pitti: Ill give it a shot. Thanks.
[11:16] <ogra> mumble, sshd doesnt log me out on reboots :(
[11:22] <ev> pitti: You're a star. Thanks, that worked.
[11:35] <yofel> pitti: bash completion for ubuntu/apport-bug updated, anything else you would like? (and is apport-cli broken?)
[11:59] <didrocks> cjwatson: hey o/ I'm trying to debug the "randomely starting UNE session on UNE". I saw that /etc/gdm/custom.conf file exists on the squashfs and have the good default session bit.
[11:59] <didrocks> cjwatson: but in the live system, there is no more the default session one. I retested in a sandbox my bottom-scripts 15autologin on casper and it seems to be correct
[12:00] <didrocks> cjwatson: I changed on that /root/etc/gdm/custom.conf thinking that /root is mounted from squashfs in the initramfs phase. Is that correct?
[12:00] <cjwatson> didrocks: I think I would benefit from a clear description of the observed bug.  Is there a bug report open for this?
[12:01] <pitti> yofel: thanks! will look at the bug mail soon
[12:01] <cjwatson> didrocks: by the time casper-bottom scripts are running, /root is a union filesystem composed of the squashfs and a copy-on-write tmpfs.
[12:02] <didrocks> cjwatson: not yet, but pitti and seb128 experiences it randomely (sometimes the UNE session is started, other time, we have the default GNOME session, without the DefaultSession key in custom.conf
[12:02] <cjwatson> didrocks: changes there are preserved for the duration of the live session, but are (of course) not written back on reboot
[12:02] <didrocks> ok, so, the logic seems good, I'll introspect this a little bit more, so. Thanks :)
[12:10] <crimsun> is it okay to upload a fix for abiword's FTBFS? (would only affect Xubuntu as far as images are concerned)
[12:12] <geser> pitti: Hi, I'm attempting to merge fuse and stuck on the .fdi file. I assume that it shouldn't be kept but replaced with udev rules, right?
[12:14] <pitti> geser: oh, /dev/fuse? this should have stopped working in karmic already
[12:14] <pitti> geser: is the .fdi a delta of our's, or in Debian? Just drop it in the former case
[12:14] <pitti> geser: if we need it, we need to fix it in udev
[12:15] <geser> yes, /dev/fuse and the .fdi file is ours (Ubuntu)
[12:16] <pitti> geser: great, so this delta can just go away then (until someone complains, anyway)
[12:28] <geser> pitti: so the remaining change from the previous "Dynamic foreground user access" changes is to keep /bin/fusermount world executable (perms are 4755). As I understand it the .fdi file previously granted access to /dev/fuse and /dev/fuse seems have perms 666 in karmic, so no real access control anymore. It this ok this way and the change should be kept?
[12:30] <pitti> geser: hmm; I think just keep the debian setup for now
[12:39] <geser> pitti: so revert all Ubuntu changes for this? If I understand the packaging correct, the user then has to be in the group "fuse" to be able to use fusermount. (but as I'm not familiar with fuse usage, I don't know if this is a problem or not)
[12:39] <geser> ogra: as you're bug contact for fuse, do you know more if this will cause problems? ^^
[12:47] <pitti> geser: ah, right, Debian installs the fusermount program as 774 root:fuse, right?
[12:48] <pitti> geser: right, we should keep it as 4755 then
[12:48] <pitti> geser: sorry (I'm just here with 1/4 a brain, I'm on a sprint)
[12:54] <ogra> geser, i havent touched fuse since several releases
[12:55] <ogra> and i dont see myself mentioned anywhere in the package
[12:57] <persia> ogra: https://launchpad.net/ubuntu/+source/fuse shows you listed as a bug subscriber.  Perhaps you don't wish to be one anymore?
[12:57] <ogra> sure i do, but i shouldnt be a default contact
[12:57]  * ogra checks
[12:58] <geser> pitti: last question before I unburden your ¼ brain: The Ubuntu package sets 4755 directly in debian/rules while the Debian package uses 0755 in debian/rules and overwrites it in the postinst to 4754 if it's not listed in dpkg-statoverride. Which way is preferred? The old Ubuntu way or use the Debian way but use 4755 as permissions?
[12:58] <persia> ogra: You're the *only* default contact :)
[12:58] <ogra> yeah, i see that
[12:59] <ogra> i'm intrested in fuse bugs but dont want to be "the contact"
[12:59] <pitti> geser: I think debian/rules is much easier; the postinst is only necessary because the "camera" (or plugdev?) group isn't a static one
[12:59] <ogra> the funniest thing is that i see a "subscribe to bugmail" link at the top
[12:59] <geser> ogra: sorry to question you but as you are listed as "Bug subscriber" I assumed you had some interested in the package and know what's going on with it
[12:59] <ogra> but apparently no way to unsubscribe at all
[13:00] <persia> ogra: Click on the little circle with a bar next to your name.
[13:00] <ogra> there is none :P
[13:00] <ogra> you mean the yellow one with a pen
[13:00] <ogra> i only have one at the "subscribe to bugmail"
[13:00] <ogra> but nothing near my name
[13:01] <ogra> ok
[13:01] <ogra> apparently i have to click "subscribe to bugmail" to unlsubscribe
[13:01] <ogra> *unsubscribe
[13:02] <ogra> sigh, we're getting worse than windows in some areas
[13:02] <persia> Yes, there's an invisible {un,} in front of "subscribe" everywhere it appears in LP :)
[13:02] <ogra> click "start" to stop :P
[13:02] <persia> Precisely :)
[13:13] <DktrKranz> mvo: hi! Did you have time to look at the gdebi merge proposal which addresses usage of --always-ask-pass?
[13:13] <mvo> DktrKranz: not yet, doing that now
[13:14] <DktrKranz> thanks!
[13:24] <J_P> hi all
[13:28] <J_P> people, are there a iso of 10.04 for tests? I have a All In ONE DEsktop (but is not a normal/usual AIO) Is a industrial machine for specific use) and touch scren is not possible to calibrate. I install ubuntu, and after install packagexserver-xorg-input-evtouch, restart machine and try run   gksu /usr/bin/calibrate_touchscreen but show this message : http://189.2.146.45/tmp/touch01.png
[13:28] <J_P> So I would like to try a develoment version of test..
[13:29] <persia> J_P: If you'd like to help test candidates for the next release, #ubuntu-testing is the best place to get help getting involved.
[13:54] <freeflying> ArneGoetje: arounds?
[13:55] <ArneGoetje> freeflying: yes
[13:55] <mvo> DktrKranz: it sounds like once this is merge we can upload to debian and do a sync on it? it should work just fine on both then, right?
[13:56] <freeflying> ArneGoetje: do u think we can use microhei to replace zenhei, for microhei is smaller than zenhei
[14:01] <ArneGoetje> freeflying: I need to take a closer look at microhei. Last time I looked (and that's already a while ago) the glyph shapes were not consistent.
[14:02] <mvo> DktrKranz: many thanks for the branch, merged now (with a small simplification)
[14:02] <freeflying> ArneGoetje: Qianqian is going to release another version
[14:03] <ArneGoetje> freeflying: ping me when that's the case, then I'll take a look at it again
[14:10] <DktrKranz> mvo: thanks! I think I'm done with this round of patches. If you think, feel free to upload at your convenience :)
[14:11] <zul> lool: ping
[14:14] <mvo> DktrKranz: cool, thanks. I created a team for it now and added you and moved the bzr to a shared upstream trunk branch - it should be much nicer now :)
[14:14] <mvo> DktrKranz: ~gdebi-developers
[14:14] <DktrKranz> mvo: yeah, I saw the email, thanks!
[14:18] <lool> zul: Hey
[14:19] <lool> zul: debian/patches/99-fix-gcc-warnings.diff last hunk of first patched file has a double free
[14:19] <lool> -               write(log_state->fd, s, strlen(s));
[14:19] <lool> +               if (write(log_state->fd, s, strlen(s)) != strlen(s))
[14:19] <lool> +                       free(s); free(s);
[14:19] <zul> lool: ok ill fix
[14:20] <lool> BTW it shouldn't be an error for write() to return less than what was requested ot be written; one is supposed to retry partial writes, they might occur in legitimate conditions
[14:20] <lool> But it's still better to fail than to not do anything
[14:20] <lool> -                       write(state->fd[1], &cc, 1);
[14:20] <lool> +                       if (write(state->fd[1], &cc, 1) != 1)
[14:20] <lool> +                               break;
[14:21] <lool> Why not return -1 here too?
[14:21] <lool> (ctdb-1.0.108/server/ctdb_recover.c)
[14:21] <lool> same for ctdb-1.0.108/server/ctdb_recoverd.c; you use return in one half of the cases and _exit in the other
[14:21] <lool> It might be correct, I just don't know
[14:22] <lool> +       if (system(buf) != -1 ) {
[14:22] <lool> +               printf("system() failed");
[14:22] <zul> that break is in a while loop
[14:22] <lool> Yes
[14:22] <zul> k
[14:22] <lool> Which goes to _exit()
[14:23] <lool> You might want to LOG instad of printf
[14:24] <lool> In one of the writes you return -errno
[14:24] <lool> but in plenty of reads you return -1
[14:24] <lool> zul: Otherwise this indeed looks more like error handling now
[14:25] <zul> lool: ok ill have another pass at it thanks
[14:25] <lool> zul: Please subscribe to bug mail
[14:25] <lool> zul: Please change Vcs-* to XS-Debian-Vcs-* when you diverge from Debian
[14:26] <lool> (otherwise debcheckout picks the wrong source)
[14:42] <cody-somerville> Did someone ping me?
[14:43]  * sebner not but waves at cody-somerville nevertheless :)
[14:43]  * cody-somerville waves. :)
[14:47] <Riddell> cody-somerville: yes, you need to argue your case on bug 476530
[14:48] <Riddell> ArneGoetje: I'm told I can save valuable CD space by using ttf-wqy-microhei instead of ttf-wqy-zenhei and ttf-arphic-uming so I'd like to do that if the two better fonts get pulled in when the user installs chinese language support
[14:48] <Riddell> for Kubuntu anyway
[14:59] <mathiaz> cr3: does checkbox support autotest?
[14:59] <cr3> mathiaz: it used to, but it needs to be updated to the more recent code base. ogasawara has also requested this, so I'll try to pull it off today
[15:00] <mathiaz> soren:
[15:00] <mathiaz> ^^
[15:00] <soren> Neat.
[15:10] <ArneGoetje> Riddell: they do get pulled in with the language-support-fonts-zh-han{s|t} packages. So, feel free to use ttf-wqy-microhei in the seeds.
[15:15] <pgquiles> I'm following https://help.ubuntu.com/community/LiveCDCustomizationFromScratch (with Karmic) but after boot, ubiquity is not started and I only see the command line. Is there any step missing/wrong?
[15:35] <superm1> slangasek, 20100113 isn't showing up on the iso tracker for mythbuntu (i just tried it, and the one bug that was reported for 20100112 is fixed)
[15:57] <slangasek> pitti: cheers!
[15:57] <slangasek> superm1: yep, 20100113 posted to the tracker now
[15:57] <superm1> thanks
[15:57] <pitti> slangasek: good morning!
[16:03] <slangasek> pitti: morning
[16:03] <slangasek> pitti: bah; "  language-support-mk: Depends: language-support-translations-mk but it is not installable"
[16:04] <pitti> slangasek: same for -oc, I take it?
[16:04] <slangasek> pitti: yes
[16:05] <pitti> slangasek: removed those, sorry
[16:05] <pitti> of course it's 2 mins past the publisher, darn
[16:05] <slangasek> right :)
[16:06] <pitti> perhaps it's faster to unseed them and only seed a couple?
[16:08] <slangasek> pitti: only used on DVD builds, and it should be exceptional that the packages are broken, yes?
[16:08] <pitti> slangasek: right, they just weren't removed in time
[16:24] <cjwatson> pitti: please tell me we're not going to reset the work items lines any more :)
[16:24] <cjwatson> pitti: I realise it was probably sort of necessary with the rewritten tracker code, but http://www.piware.de/workitems/foundations/lucid/report.html was really rather more informative than http://macaroni.ubuntu.com/~pitti/workitems/canonical-foundations.html currently is :(
[16:26] <pitti> cjwatson: lool just pinged me; indeed I stopped those cronjobs for the entire cycle
[16:26] <pitti> I can start them again
[16:26] <cjwatson> I know, but the fact that we lost the historical trend is a bit of a problem
[16:26] <pitti> but I definitively won't add another 50 cronjobs for alpha-3/beta-1/etc
[16:27] <cjwatson> understood
[16:27] <pitti> if it's useful in any way I can keep the old tracker for the final
[16:27] <pitti> or adjust the trend line on the new tracker
[16:27] <pitti> ^ woudl that actually be enough?
[16:27] <pitti> or is there more missing?
[16:27] <cjwatson> moving to the new graphs just makes it much harder to judge whether we need to reprioritise
[16:27] <cjwatson> maybe, but what would you adjust it to?  it has a quite different list of WIs due to the global scan
[16:27] <pitti> right
[16:28] <cjwatson> I think it would be OK to keep the old tracker running for this release as a workaround
[16:28] <ion> I wonder when Keybuk’s gonna come online?
[16:28] <pitti> reenabled for mobile/server/foundations
[16:28] <cjwatson> ion: he's on holiday
[16:28] <cjwatson> pitti: thanks!
[16:29] <ion> cjwatson: Ok, thanks
[16:31] <pitti> cjwatson: probably in a month or so the trend line and actual daily work item change will be exact enough to switch to the new tracker entirely
[16:31] <pitti> but I'll leave them running for now
[16:31] <cjwatson> yeah, could be
[16:36] <slangasek> zul: did you see my earlier ping about bug #445958?
[16:37] <zul> slangasek: no i missed it
[16:37] <slangasek> zul: can you clarify what you meant in bug #445958 by "no longer being maintained"?  The package was removed from karmic, but has shown back up in lucid via auto-sync because it is maintained in Debian and there was a new version uploaded.  Is there really a reason to blacklist this package, or does it just need to be unseeded from server-ship (...which never happened when the package was removed from the archive)?
[16:38] <zul> checking
[16:39] <milanbv> slangasek: I'd like to talk with you about bug #393854
[16:40] <milanbv> I asked seb128 who said me he had no strong opinion about it
[16:40] <zul> slangasek: i asked it to be removed because of f #130099
[16:42] <zul> it should probably be blacklisted and removed from the seeds
[16:44] <NCommander> slangasek, pong, sorry, didn't see your ping. Dove is fairly unstable at the moment, but I've managed to install at least the ARM alternate dailies
[16:45] <slangasek> milanbv: perhaps you could discuss it with kees instead?  He also weighed in on the question, and I'm rather tied up with alpha 2 right now
[16:46] <slangasek> milanbv: I begrudgingly concede that the point about being able to still require a password for other services is a valid one, so if kees agrees, I'm ok with the change
[16:47] <slangasek> milanbv: (though architecturally, I still dislike having a magic group name...)
[16:47] <slangasek> zul: the corresponding Debian bug has users claiming it works for them, and that there's no replacement available?
[16:47] <milanbv> slangasek: OK, I'll grab Kees
[16:48] <milanbv> kees: ping?
[16:48] <zul> slangasek: hmm ok it should be fine then i havent tested it out myself
[16:48] <slangasek> zul: ok.  should it still be unseeded?
[16:48] <zul> slangasek: i think so
[16:49] <slangasek> zul: ok - could you make that change?
[16:49] <zul> slangasek: of course
[16:50] <slangasek> NCommander: ARM alternate isn't what we would include in alpha-2, though; I've posted the desktop images to the ISO tracker for testing
[16:50] <slangasek> NCommander: when are the new, non-desktop images going to arrive?
[16:51] <kees> milanbv: I'm fine with it.  I hate the idea of auto-login, but people are set on it.
[16:51] <kees> milanbv: this actually makes it better in that they actually have a password.
[16:53] <milanbv> kees: that was my thought when I implemented that
[16:54] <milanbv> we still need to adress a more general issue with keyrings when password is not typed
[16:54] <milanbv> but that's not specific to that patch
[16:54] <milanbv> who should commit that patch?
[16:56] <kees> milanbv: whoever normally handles gdm, I think.
[16:58] <milanbv> no idea who does that - I'll look for him
[16:58] <milanbv> thanks anyway!
[16:58] <milanbv> kees: oh, and you'll be happy to hear that the new version of the system-tools-backends/liboobs no longer encrypts passwords on its own
[16:58] <milanbv> we use standard chpass, without the -S option
[16:59] <kees> milanbv: oh? how?
[17:00] <milanbv> I've completely changed the D-Bus protocol
[17:00] <kees> ah, okay.  is that in lucid currently?
[17:00] <milanbv> we now send passwords in clear text (appears to be fine with D-Bus)
[17:00] <milanbv> that should be in soon
[17:01] <milanbv> chris has opened a bug about that
[17:01] <kees> I thought the bus could be sniffed?
[17:01] <milanbv> according to people on dbus-list, that's safe
[17:01] <milanbv> (for local bus)
[17:01] <milanbv> my main concern is about perl, which doesn't allow clearing memory
[17:04] <NCommander> slangasek, that was planned for A3 AFAIK. We should be tracking alternates though, it was decided at UDS we were going to do so
[17:05] <slangasek> NCommander: what do you mean by "tracking"?
[17:05] <NCommander> slangasek, having alternates on the tracker and testing themper normal
[17:06] <milanbv> seb128: slangasek is OK with the GDM password-less patch - do you know who's reponsible for committing there?
[17:06] <seb128> nobody
[17:06] <seb128> we don't have strict maintainer assignement in ubuntu
[17:06] <seb128> slangasek can do it if he wants
[17:07] <slangasek> NCommander: nobody has mentioned this to me up to now; who made this decision?
[17:07] <NCommander> slangasek, https://blueprints.launchpad.net/ubuntu/+spec/mobile-lucid-arm-alternate-images
[17:08] <milanbv> seb128: hmm, I should be more precise
[17:08] <milanbv> he said he didn't care either, and told me to ask kees, who's OK
[17:08] <milanbv> :-)
[17:10] <slangasek> NCommander: oh, right; now I remember catching sight of this outstanding work item in the last release meeting and claiming it...
[17:10] <slangasek> NCommander: is this alternate for both flavors?
[17:11] <NCommander> slangasek, as far as I know, but I'm unsure if imx51 alternates work at all. ogra ?
[17:12] <ogra> NCommander, no idea, GrueMaster is the testing guy ;)
[17:12] <ogra> NCommander, i'm busy with other stuff, i only test live images
[17:16] <kees> milanbv: "undef" seems to work for me, experimentally, in perl.
[17:17] <kees> milanbv: all file descriptors that carried the password should be closed, and then the variable that held it undefed
[17:18] <kees> milanbv: http://pastebin.com/f39fc278e  when I kill -SEGV the script and look at the core from each shell, the second shell doesn't show the string.
[17:18] <sebner> kees: wondering about what you bleeding edge session will be about :)
[17:18] <milanbv> kees: actually, I've found many threads explaining how clearing memory was very hard in perl
[17:18] <kees> sebner: http://outflux.net/ul07/bleeding-edge.odp <- this, in IRC form
[17:19] <milanbv> I'll use undef, but I'm not sure that's a 100% warranty
[17:19] <milanbv> (we don't actually open files, since chpasswd does this for us)
[17:19] <kees> milanbv: it's hard if you splash the variable around, but if keep it limited, it shouldn't be too bad.  you can experimentally test it by using ulimit -c unlimited; rm core; *run*; kill -SEGV $pid; strings -a core | grep $password
[17:20] <milanbv> yeah, I'll try that
[17:20] <sebner> kees: cool, seems a little bit like "for beginners"?
[17:20] <milanbv> anyway, there's an important security: an attacker doesn't know what he should grep for, since the password is unknown
[17:21] <kees> sebner: a bit, yeah.  but there are some good bits of advice.
[17:21] <kees> milanbv: well, that's just to make your test easy.  it's relatively trivia to reconstruct the process memory and find the variable directly.
[17:21] <sebner> kees: nice, I'll be there then, maybe I hear something new :)
[17:21] <milanbv> and I suspect the D-Bus binding could be playing with values around, leaving them in memory
[17:21] <kees> sebner: cool!
[17:22] <kees> milanbv: if so, it's a bug in the dbus module.  :)
[17:22] <kees> anyway, give it a try, see what it looks like.
[17:22] <milanbv> not sure - it seems that as long as you perform some string operations in perl, data hangs around without any way of finding it
[17:22] <milanbv> I'll try
[17:23] <milanbv> do you have commit access to GDM?
[17:23] <milanbv> I mean, in Ubuntu
[18:08] <sivang> hi all
[18:08] <sivang> how bad is Lucid right now? can it be used for webapp development and audio ouput on a plani intel borad ?
[18:09] <chrisccoulson> sivang - you might be better off asking in #ubuntu+1
[18:09] <sivang> chrisccoulson: ?
[18:10] <sivang> chrisccoulson: why is that?
[18:10] <sivang> -devel is no longer for the currently being eveloped branch ?
[18:10] <chrisccoulson> this channel is for discussing ubuntu development. #ubuntu+1 is the channel where people running the development branch communicate with each other
[18:10] <sivang> chrisccoulson: ah koay
[18:11] <sivang> cool
[18:15] <geser> chrisccoulson: Hi, as you filed bug #427595 and as libipoddevice is back in lucid, do you know if it should be removed again or if it should stay (in that case we would need to re-apply our old Ubuntu change to fix bug #505336)?
[18:16] <chrisccoulson> geser - yeah, it seems like it should be removed again
[20:17] <sivang> anybody know how I can request to renew mu ubuntu membership ?
[20:19] <jcastro> sivang: you just renew yourself when it sends you the mail
[20:32] <mneptok> jcastro: i got that e-mail, and i thought "renew yourself" meant a nap and a shower.
[20:32] <jcastro> yeah but we know you don't shower.
[20:34] <mneptok> jcastro: that's why i was going to let my Ubuntu membership lapse, and switch to Slackware.
[20:35] <mneptok> gcc has no personal hygiene requirements.
[20:46] <sivang> jcastro: I forgot
[20:46] <sivang> jcastro: that's the problem
[20:47] <jcastro> I did that once, I just mailed someone on the CC
[20:47] <sivang> jcastro: I'm nwo more into loco team and talks I'm giving
[20:47] <sivang> jcastro: okay
[20:47] <sivang> jcastro: whom to mail ?
[20:48] <jcastro> no idea, can you join #ubuntu-community-team and we'll sort it
[20:49] <ScottK> mneptok: That's for the blog on the Google stuff.  Very interesting.
[20:49]  * mneptok bows
[20:51] <ScottK> That's/Thanks in any case.
[20:51]  * ScottK goes to look for moar coffeeeee
[21:06] <sivang> jcastro: hhehe
[21:06] <sivang> jcastro: joining now
[21:58] <ari-tczew> anybody will work on merges for main?
[21:58] <ari-tczew> there is no support from sponsors
[22:02] <ari-tczew> thanks!
[22:11] <Kmos>  /quit
[22:18] <ScottK> ari-tczew: There are people to do it, but a lot of people are busy with Alpha 2 preps right now.
[22:20] <ari-tczew> wow
[22:42] <mathiaz> does anyone see a use case for having / on a raid0 (stripped) array?
[22:43] <elmo> err, yeah, me?
[22:44] <elmo> I've done that several times before when I needed space for a machine with trivially replacable contents (e.g. an Ubuntu mirror)
[22:44] <q3aiml> Would this be the correct place for a packaging question?
[22:44] <highvoltage> q3aiml: #ubuntu-motu
[22:45] <q3aiml> thanks
[22:45] <highvoltage> you're welcome
[22:45] <elmo> mathiaz: ^--
[22:47] <mathiaz> elmo: right - so you'd just use raid0 for the whole system instead of raid0 for the partition that hold the replacable data and raid1 for /?
[22:48] <elmo> mathiaz: it's easier for me to RAID 0 / than to alter my auto-installer to setup a separate RAID 0 partition
[22:48] <elmo> that may just be me, but *shrug*
[22:49] <mathiaz> elmo: fair enough - and if you loose one drive, you loose your data anyway - which renders the system unusable
[22:49] <elmo> right