[02:47] <ebroder> Does anybody know if there's a D-Bus method or some way for me, as root, to force the GDM greeter to login as a particular user (on demand, so not something like auto-login)
[06:47] <dholbach> good morning
[06:47] <orangey> hello all
[06:47] <orangey> I'm trying to compile a new kernel
[06:48] <orangey> and I'm doing it with: sudo make -C /usr/src/linux-headers-`uname -r`  M=`pwd`
[06:48] <orangey> however, it will NOT compile this new file!
[06:48] <orangey> it DOES compile properly all the OLD files, though
[06:49] <dholbach> https://wiki.ubuntu.com/KernelTeam/GitKernelBuild might be helpful
[06:49] <dholbach> and #ubuntu-kernel
[06:50] <orangey> dholbach: thank you
[06:50] <orangey> i've already been through that page
[06:50] <dholbach> there's nothing about "sudo make" in there :)
[06:51] <orangey> right.. make would work too : )
[06:52] <dholbach> and you don't seem to use mak-kpkg
[06:52] <dholbach> make-kpkg
[06:53] <dholbach> but I should shut up now, I haven't built a kernel for like 10 years now, never necessary
[06:54] <jussi> hahah!
[06:55] <orangey> ; )
[06:55] <orangey> dholbach: a lot of that is the obviously ill-fated attempt to compile a single directory instead of every part of the damned kernel
[06:56] <orangey> sadly, time-saving elegance will take me way more time than if I would have just done it the hard way
[08:23] <pitti> Good morning
[09:15] <seb128> mr_pouit, hi
[09:16] <seb128> mr_pouit, you could maybe send the goffice intltool update change to the debian bts, usually they take such changes it doesn't cost them a lot and it allows to sync between distros
[09:17] <seb128> ScottK, hi, what is cpp doing in poppler exactly? and I would appreciate you pinging before doing such changes to it next time
[09:18] <Cheery> what's the reason for: 64-bit - Not recommended for daily desktop usage ?
[09:19] <Cheery> oh. google told me already
[09:19] <Cheery> cya.
[09:20] <seb128> ScottK, you also added tons of html documentation changes to the diff.gz
[09:20] <seb128> ScottK, the diff also has a cdbs-package-list which is not described in the changelog
[09:20] <mr_pouit> seb128: yeah, it's on my todo list, but I didn't have the time yesterday
[09:21] <seb128> mr_pouit, ok, I've noticed that like 2 cycles ago when doing merges but I forgot about it since, thanks
[09:24] <seb128> directhex, Laney: I'm not sure uploading the new f-spot to ubuntu without the ubuntu changes was something we want to do
[09:25] <seb128> didrocks, Laney: Debian might not care about Ubuntu changes but we do...
[09:25] <Laney> seb128: RAOF is already prepping them for upstream
[09:25] <Laney> I do care about those changes :)
[09:25] <directhex> Laney asked me to sync! :(
[09:25] <directhex> brb minibus
[09:25] <seb128> Laney, well they are dropped now though
[09:25] <Laney> yeah it was all me, not him guvna
[09:26] <seb128> wouldn't it make sense to still include the updated version in Ubuntu until he manages to get those in git?
[09:26] <Laney> they required porting for the new upstream release
[09:26] <Laney> and it seemed sensible for only one of us to do that
[09:28] <seb128> yeah, not discussing
[09:28] <seb128> I would just have waited for those to be ported and did a merge on debian
[09:28] <seb128> but I guess that's fine to have those off for a short time
[09:28] <Laney> I thought it was a win to get the new release some testing given that we will get the other changes back very soon anyway
[09:29] <seb128> I just wouldn't like that to stay they way for half the cycle because it takes time to get things upstream
[09:29] <seb128> ok, fair enough
[09:29] <seb128> Laney, thanks
[09:29] <Laney> no problem
[09:32] <bigon> robert_ancell: hi, is this change http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550478 really needed? Josselin is not really happy with putting things for thesting only to production pkg
[09:39]  * RAOF stops wrangling the intel DDX and switches to f-spot hacking mode…
[09:40] <directhex> i'll do mono 2.6 as soon as 2.6.4 is in debian
[09:41] <directhex> there are no major changes this time, it's a straight update
[09:41] <directhex> i.e. no need to worry about transition stress
[10:31] <tseliot> cjwatson: do you know how I can make sure that the following parameter show up as it is in grub.cfg (without any of the backslashes or of the quotation marks being escaped) if I put it in /etc/default/grub ? acpi_osi=\"!Windows 2009\"
[10:35] <cjwatson> tseliot: there's a bug about that somewhere, I think you have to doubly-quote it or something stupid
[10:35] <cjwatson> oh, or maybe not even that
[10:35] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550319
[10:36] <cjwatson> we need to sort it out upstream, I don't think there's a good answer right now
[10:37] <tseliot> cjwatson: ok, thanks
[10:41] <tseliot> cjwatson: acpi_osi=\\"\""!Windows 2009\\\"" did it (the last quotation marks are meant to end the line)
[11:30] <ScottK> seb128: I packaged it because a KDE upstream developer was here over the weekend asking that it be added.  I didn't get the impression from your debian/changelog entry that there was any reason not to.  I did have him verify that the library works in the package before I uploaded it.
[11:30] <zyga> anyone else sees problems running current virtualbox 3.2.4 on Lucid?
[11:30] <zyga> I keep getting my VMs crash on disk issues
[11:30] <ScottK> I'm not sure why there are html documentation changes and cdbs-package-list now in the diff.gz.  I didn't make any changes related to those.
[11:33] <seb128> ScottK, you likely build it twice without cleaning the source and the clean target is buggy
[11:33] <seb128> ScottK, what is the cpp backend doing exactly?
[11:42] <ScottK> seb128: As I understand it it's just a different library you can build with if that's your preferred interface.  He was specifically concerned that developers would avoid this new library if it wasn't available in Ubuntu.  Sorry about the clean problem.
[11:43] <ScottK> If you want to discuss it, I'll ping him when he's online.
[11:45] <seb128> ScottK, no, I planned to chat with poppler upstream about the new lib that's why I didn't active it in the first upload
[11:45] <seb128> ScottK, thanks for working on the change, I would still appreciate if you could ping on IRC about such changes next time
[11:45] <seb128> ScottK, there is often a reason why changes are done a way
[11:46] <ScottK> seb128: I did look and you weren't online.  I didn't get a hint from debian/changelog that there was a reason to wait.  Sorry for any confusion.
[11:46] <seb128> that's ok
[11:46] <seb128> lunch time; bbl
[11:47] <didrocks> seb128: enjoy
[11:59] <baptistemm> hello
[12:03] <IdleOne> When doing apt-cache policy package. Shows if package is installed or not and version, it also shows a repository, is that the repository it was downloaded from or is that info contained in the package ( meaning the repo can be faked)?
[12:04] <IdleOne> I am asking because I want to know if that information can be used to authenticate (for myself) if the package is trustworthy
[12:07] <cjwatson> IdleOne: it's the repository that it would be downloaded from if you were to install it now
[12:08] <cjwatson> it's not information from the package
[12:08] <IdleOne> cjohnston: is there a way of finding out what repo a package was installed from?
[12:08] <maco> apt-cache policy <package> ?
[12:08] <maco> oh wait you already said that
[12:09] <maco> IdleOne: zgrep through /var/log/apt/term*
[12:09] <IdleOne> Someone just asked about Gparted in #u I asked where he got it from and he seemed unsure. He said it spit out an error about possibly malicious software
[12:09] <maco> IdleOne: you can see the path from which it wget'd
[12:10] <IdleOne> maco: thank you :)
[12:11] <cjwatson> IdleOne: other than log files as maco suggested, that information is not stored anywhere machine-parseable
[12:11] <cjwatson> the error you mention could be an attack, or it could be fixed by running 'sudo apt-get update'
[12:11] <maco> cjwatson: you should see the chain of pipes i concocted to get the date the current version was installed like rpm -qi gives!
[12:12] <IdleOne> maco: example command for zgrep?
[12:13] <IdleOne> I did zgrep gparted zgrep through /var/log/apt/term* but it did not return useful info
[12:13] <maco> IdleOne: just use it like grep
[12:13] <IdleOne> errr
[12:13] <maco> zgrep is grep for .gz's
[12:13] <IdleOne> zgrep gparted /var/log/apt/term*
[12:14] <maco> IdleOne: do you have it installed?
[12:14] <IdleOne> yes
[12:14] <maco> er sudo that too
[12:14] <IdleOne> yup
[12:15] <IdleOne> gives me 3 lines of output but nothing about wget info
[12:16] <maco> :-/ youre right. term.log just has the unpacking process
[12:18] <IdleOne> I guess my question is How can I be sure that a package came from a secure repository?
[12:18] <IdleOne> not for my personal systems. I know what repos I use but more for support of other users in #u
[12:19] <jpds> IdleOne: Check the sha1 of the package in /var/cache/apt/archives/ ?
[12:20] <siretart> seb128: hi. last week you said that you "will see if we can find somebody interested" to write a MIR vor libvpx. Did you find someone?
[12:20] <seb128> siretart, no
[12:20] <seb128> siretart, hi btw ;-)
[12:20] <siretart> :-)
[12:20] <IdleOne> jpds: I guess so.
[12:21] <IdleOne> thanks for the answers folks
[13:19] <baptistemm> hello, anyone to review lp:~bluetooth/ubuntu/maverick/bluez/main and lp:~bluetooth/ubuntu/maverick/obexd/main? :)
[13:38] <ScottK> doko: Did you plan to merge python-defaults and python3-defaults soon?  We've got packages depwaiting on the newer versions for dh_python{2,3}.
[13:39] <doko> ScottK: later this week, go ahead with merging if you like
[13:40] <ScottK> doko: Is it OK to use the current python2.6 version as the minimum required?
[13:42] <doko> ScottK: no, but python2.6 is almost syncable, just the version numbers in the maintainer scripts have to taken from the ubuntu packages
[13:42] <ScottK> So 2.6 needs updating first.
[13:53] <ccheney> doko, will you be looking at the OOo related MIRs from a few weeks ago? :)
[15:22] <ScottK> slangasek: I see at least one package in Debian using the Boost MPI bits.  We've been stripping them out as "not used" and that's no longer true.  Any thoughts on how to deal with this?
[15:46] <dabaR> Anyone seen SVN conflicts now creating a .u1conflict file?
[15:46] <dabaR> Oh, is it an UbuntuOne thing?
[15:49] <dabaR> Yes it is.
[18:44] <hunger> cd
[18:44] <hunger> Sorry:-/
[18:44] <smoser> james_w, or other, when i use quilt 3.0 format in a packaging bzr branch, I think that I"m supposed to commit with patches applied (ie, 'quilt push -a' rather than 'quilt pop -a').  Is that correct ?
[18:44] <james_w> smoser: yeah
[18:44] <cjwatson> that's what I do
[18:45] <smoser> hm..
[18:45] <smoser> so i commited some i know (have to think about which ones)
[18:45] <smoser> and pushed to the packaging brnach (lp:ubuntu/maverick/<package>) with the patches *not* applied
[18:46] <smoser> would that cause issues ?
[18:47] <slangasek> it gives you a branch there that doesn't match what the importer would create
[18:47] <slangasek> best to fix it up when you have a chance
[18:49] <smoser> ok. thanks.
[19:39] <Nhdb> why is it so hard to create a deb-package of a simple application? :/
[19:39] <ion> It’s not that hard.
[19:39] <Nhdb> dh_make, pbuilder, debhelper, everyone seems to do it in a different way
[19:40] <azeem> those three are orthogonal
[19:40] <Nhdb> yeah, but they are all optional it seems
[19:40] <azeem> the stress being on "optional"
[19:40] <ion> You better use debhelper rather than NIH it.
[19:41] <Nhdb> I've got a simple python I want to package, but I'm stuk on the debian/rules (seems to be the hardest part)
[19:41] <Nhdb> currently it contains only "%:     dh $@"
[19:42] <Nhdb> how can I fill it so my application will go to /usr/share/?
[19:42] <azeem> applications go to /usr/bin
[19:42] <Nhdb> the program I have has multiple (python) source files
[19:42] <Nhdb> so that should go to /usr/share/ right?
[19:43] <azeem> depends
[19:43] <Nhdb> on what?
[19:43] <azeem> on your application
[19:44] <azeem> does it have a setup.py?
[19:44] <ion> See the python-central package and dh_pycentral
[19:44] <Nhdb> yeah ok, I've got multiple python files, and 1 is called main.py and is executable, I don't have a setup.py
[19:45] <azeem> Nhdb: how is your application started?
[19:45] <Nhdb> azeem: "./main.py" or "python main.py"
[19:48] <ion> nhdb: See e.g. debian/rules in the source package of apturl.
[19:49] <Nhdb> ion: thanks, got it
[19:49] <cjwatson> the intent of that tiny debian/rules is that most standard packages should never need to touch it at all; that includes packages with a working reasonably standard setup.py
[19:49] <azeem> btw, does it also support cmake?
[19:50] <cjwatson> yes
[19:50] <cjwatson> /usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm
[19:50] <azeem> cool, thanks
[19:51] <Nhdb> so I'm a bit confused about what my debian/rules should actually do, how does the system know what to put where?
[19:51] <azeem> if you don't have a standard build system, you need to do it manually
[19:51] <cjwatson> long story but the short form is don't worry about it and write a working setup.py and it'll figure it out
[19:52] <azeem> also, consider renaming your application to something else than "main.py"
[19:52] <cjwatson> but what actually happens is that dpkg-buildpackage calls 'debian/rules build', which that debian/rules expands to 'dh build', and then you can read 'man dh' for what happens next; likewise, it then calls 'debian/rules binary'
[19:53] <cjwatson> 'dh <target>' expands to a bunch of individual commands, which you'll see output in the build log when you build a package that uses that tiny debian/rules
[19:53] <cjwatson> and you can read the man page for each command to find out what it does
[19:53] <Nhdb> hm okay, I think I'll go find some docs on how to write a setup.py and go that route
[19:54] <cjwatson> for instance dh_auto_install knows to call 'setup.py install --force --root=$destdir --no-compile -O0' or something along those lines
[19:54] <cjwatson> but it's easier to let dh_auto_install do it for you unless you have some unusual requirements
[19:54] <cjwatson> if you need to install individual simple extra files, 'man dh_install'
[19:54] <cjwatson> etc.
[19:54] <Nhdb> cjwatson: hmm oke thanks
[19:55] <Nhdb> cjwatson: sounds like a ton of work :)
[20:32] <cjwatson> Nhdb: nah, pretty easy really, certainly quicker than crafting it all by hand at least once you're used to it
[21:24] <ebroder> Does anybody know how I, as root, can force GDM to login as a particular user?
[21:24] <ebroder> (from the greeter)
[21:26] <geser> as a last resort: configure temporarily an auto-login for that user
[21:26] <micahg> pitti: are the retracers working?
[21:26] <ebroder> geser: Hmm...do you know if I do that without restarting GDM?
[21:46] <Cheery> do you know how to install opencl development stuff for ubuntu?
[21:47] <Cheery> I have CL -directory, but there's not headers here.
[22:14] <slangasek> superm1: a mythbuntu test build completed, so it seems you're consistently running into the mirror skew bug on antimony.  I guess we'd better find a resolution to that...
[22:24] <cjwatson> skew> might be able to avoid it by rescheduling
[22:25] <slangasek> maybe, but if it's a problem now when it wasn't before, that means builds are now overlapping that previously weren't; I think we should bite the bullet and get proper locking in that script
[22:37] <gaurav> https://help.ubuntu.com/community/Kernel/Compile is this documentation still valid for 10.04 ?
[22:38] <gaurav> ignore i got the answer :p
[22:43] <ScottK> cjwatson: Would you have a little time later in the week to talk with me about Germinate?  For Kubuntu in 10.10 we are trying to build two metapackage variants out of main/restricted and one out of main/restricted/universe.  The only way I found to do this so far is too ugly to even describe in public.
[22:56] <cjwatson> ScottK: I don't have much synchronous time, but I should have plenty of asynchronous time (mail or whatever)
[22:57] <ScottK> cjwatson: OK.  Thanks.  I'll try to write it down and mail you,
[23:16] <jjardon> Hello, seems that the glade documentation is not packaged. Should I fille a bug?
[23:16] <jjardon> (the user manual and the developer manual, both included in the tarball)
[23:19] <seb128> jjardon, the user documentation is in the binary?
[23:21] <jjardon> seb128, in the glade tarball, yes
[23:21] <seb128> jjardon, in the installed deb as well
[23:23] <jjardon> oh. Maybe a bug in glade itself then
[23:27] <jjardon> The not installed doc It's the devel doc, sorry
[23:27] <jjardon> http://library.gnome.org/devel/gladeui/
[23:28] <seb128> jjardon, it's in libgladeui-1-dev
[23:30] <jjardon> oh, yeah. Sorry for the noise