[00:18] <bryceh> hallyn, it's not required to have a bug for merges
[00:19] <bryceh> hallyn, generally you'd file a bug for a merge if you're seeking sponsorship
[00:25] <Keybuk> ok, can anyone remember how ssh-agent/gnome-keyring/seahorse is supposed to work in Lucid? :-/
[00:25] <maco> automagically?
[00:26] <maco> seahorse-agent should cover both ssh & gpg -agent stuff iirc
[00:27] <maco> (but seahorse-agent isnt api compatible with them so kmail falls over if its running instead of gpg-agent, but anyway...)
[00:30] <Keybuk> maco: well, so I have seahorse agent
[00:30] <Keybuk> but seahorse agent is only exporting GPG agent environment
[00:30] <Keybuk> not SSH agent
[00:30] <maco> that miiight be right... i dont have a .... hang on i might have a vm
[00:31] <maco> i have a maverick vm
[00:32] <Keybuk> so where does the ssh agent come from?
[00:32] <maco> on my maverick it is running
[00:33] <maco> but...wow maverick's confusing when you havent used gnome since hardy...
[00:33] <maco> seahorse isnt in the menu anymore
[00:33] <maco> ok i think seahorse just covers gpg
[00:34] <maco> but it should offer to remember your ssh key passphrase for the rest of the session
[00:35] <Keybuk> hmm
[00:35] <Keybuk> right
[00:35] <maco> gnome-search-tool? when did this replace beagle or tracker or whatever...  wah this is like when i tried to use windows after years of not using it!
[00:35] <achiang> kubuntu user?
[00:35] <maco> yep
[00:36] <maco> i think i need to play with this vm a bit so next time i get a support call from my brother i know what's on his screen beyond "there's a menu at the top instead of bottom"
[00:37] <achiang> you mean, "launcher on the side with big buttons" ;)
[00:37] <maco> nah he sticks to lts
[00:37] <maco> i dont have to worry about unity for another year with him. and then it can be "so they totally changed the UI around on you. wanna switch to the one i know how to use since you have to relearn anyway?!"
[00:38] <achiang> ooh, sneaky
[00:39]  * Keybuk blames Caesar
[00:39] <maco> i found seahorse btw. its in system -> preferences now
[00:39] <maco> Keybuk: who?
[00:40] <maco> or was that metaphorical?
[00:40] <Keybuk> maco: no, it was directed ;-)
[00:40] <maco> discovery: the first thing that happens when i click on ubuntu software center is that i get a crash notification. shiny
[00:40] <maco> (the computer with the vm has no network access, so no i'll not be sending a crash report)
[00:41] <maco> (for all i know its fixed in an update anyway)
[00:41] <maco> alpha 4...yeah probably fixed by now
[00:51] <kklimonda> that's some old vm :)
[00:52] <kklimonda> great, I've been wondering why I can't use keyboard to change the volume.. apparently PA died on me, and I can't revive it. Probably an indication I should restart my computer ;)
[00:57] <lifeless> jcastro: ping
[00:58] <achiang> let's say i've got a package whose control file was very simple: source package, binary package. now, i want to use the same source package to generate two binary packages, so i create an entry for foo and an entry for bar
[00:58] <achiang> previously, i have files like dirs, install, postrm, postinst, prerm, etc.
[00:59] <kklimonda> achiang: you rename them to (binary package name).dirs etc.
[00:59] <achiang> must i create foo.dirs, bar.dirs ; foo.install, bar.install?
[00:59] <achiang> what if there is some commonality?
[01:00] <achiang> say dirs remains the same, but install should be different
[01:00] <ari-tczew> barry: I suggest you for merge package nipy from Debian @universe. I could have a look on it then.
[01:00] <achiang> can i just keep dirs, but then create foo.install and bar.install?
[01:00] <kklimonda> achiang: no idea, but you can try doing that ans seeing what happens
[01:00] <achiang> heh
[01:01] <achiang> the less obvious files to me are compat, copyright, and this odd one named gconf-defaults
[01:01] <achiang> i think those can remain as-is, right?
[01:02] <achiang> i think compat and copyright should be fine, but gconf-defaults should be named foo.gconf-defaults
[01:02] <kklimonda> gconf-defauls should be renamed so it's used for the binary package that ships gconf files, compat and copyright are not related to binary packages, so you don't have to rename them.
[01:04] <achiang> kklimonda: thank you
[01:42] <achiang> going back to previous conversation about splitting an existing source package into several binary packages... i've read through: http://wiki.debian.org/PkgSplit
[01:42] <achiang> new question is, must i create a target in debian/rules for each binary i want to create and copy/paste all the dh_* commands for each target?
[01:43] <achiang> seems rather anti-DRY
[01:44] <ion> I’d suggest using dh 7 and not copying a plethora of dh_* commands anywhere.
[01:44] <micahg> achiang: no, dh7 should take care of that unless you need to override
[01:44] <achiang> ah, i will go read about dh7, thank you ion and micahg
[01:45] <persia> achiang, The conventional DRY way is to use rules.tiny and only vary from the defaults when using debhelper support files.
[01:45] <ion> List binary packages in debian/control and for each package create debian/$PACKAGE.install to describe which files go into it.
[01:46] <achiang> ion: right, that is what i did; maybe one complication is that say i have a config file that i want each binary package to install; after building the debs, i only see the config file present in the first binary package described in debian/control
[01:46] <achiang> even though the config file is present in both foo.install and bar.install
[01:46] <achiang> s/present/listed/
[01:47] <persia> You want the same file to be produced by multiple packages, or the same content to be stored in multiple files in multiple packages?
[01:48] <achiang> say the source package has "file.conf" ; debian/control has 2 binary package targets foo.deb and bar.deb ; i want file.conf to be installed into /etc/ when either foo.deb or bar.deb is installed
[01:49] <achiang> (in my case, i know for sure that foo.deb and bar.deb are mutually exclusive; they'll *never* appear in the system together)
[01:49] <persia> They'll have to Conflict:
[01:50] <achiang> so i have been trying: echo file.conf /etc > foo.install ; echo file.conf / etc > bar.install
[01:50] <persia> And that file exists at the root of the packaging directory?
[01:51] <achiang> but after building, i see that only foo.deb delivers file.conf ; bar.deb is more or less empty (foo was the first target in debian/control)
[01:51] <achiang> well, for this example, yes. i mean, in reality, i specify the full path to file.conf in [foo|bar].install
[01:52] <persia> Full path?  It ought only take a relative path (but I'll presume that is what you meant)
[01:52] <persia> Is the configuration file created by the build system, or just pulled from the source?
[01:53] <achiang> just pulled from source (and yes, sorry, relative path)
[01:55] <achiang> hm, changing debian/compat to say 7 (from 5) didn't really help
[01:55] <persia> Ah, yes, seems that dh_install assumes that you don't want to install the same thing twice.  You can work around this by copying the configuration so that you have two relative paths, but that may be annoying.
[01:57] <achiang> persia: which configuration?
[01:58] <persia> Whatever configuration you want in both packages.
[01:59] <persia> override_dh_auto_install:\n\tdh_auto_install\n\tinstall -m 644 -d ${DEST} ${FILE}
[02:01] <achiang> hm, that is rather annoying. sorry i didn't say this earlier, but the entire point of this package is to install config files in various spots, and there are many of them; between foo.deb and bar.deb they are 95% similar, so that is a lot of repetition.
[02:02] <persia> Commonly that's done with a -common package containing all the shared stuff.
[02:06] <achiang> persia: ah! i could just create a third package in debian/control that contains the actual common stuff, then split out foo and bar appropriately
[02:07] <persia> Indeed.  Then have the differing packages conflict, and both depend on the -common package.  That's how it's usually done.  If it's just one file, it seems heavyweight, but if it's 95% of the files, it's the better thing to do.
[02:08] <achiang> persia: yes, thank you for the guidance. and i'll use #ubuntu-packaging for questions like this in the future. :)
[02:08] <persia> Heh, that's why it's there :)
[02:33] <chrisccoulson> slangasek, was you aware that yesterdays sqlite upload broke ABI?
[02:34] <chrisccoulson> sqlite3_unlock_notify has gone
[02:34] <slangasek> chrisccoulson: the 3.7.4-2ubuntu1 upload?
[02:34] <chrisccoulson> slangasek, yeah, i just updated it now
[02:34] <slangasek> chrisccoulson: updated as in uploaded?
[02:35] <chrisccoulson> slangasek, sorry, i meant i just updated to the version you uploaded yesterday
[02:35] <slangasek> ah
[02:35] <chrisccoulson> slangasek, i only noticed because of this: http://launchpadlibrarian.net/63523237/buildlog_ubuntu-natty-i386.globalmenu-extension_0.3-0ubuntu1~pre1_FAILEDTOBUILD.txt.gz
[02:35] <slangasek> it wasn't yesterday, though, it was only 2 hours ago
[02:35] <chrisccoulson> so i just checked it locally too
[02:36] <chrisccoulson> oh, yeah. it was yesterday my time ;)
[02:36]  * chrisccoulson should get some sleep
[02:36] <slangasek> heh :)
[02:37] <slangasek> ok, looking to see what's going on here, because nothing in that should've been an ABI-changer
[02:37] <chrisccoulson> thanks
[02:43] <slangasek> I wonder if this is a cdbs behavior change
[02:44] <slangasek> the bits that went missing are controlled by a define passed in DEB_OPT_FLAG
[02:46] <chrisccoulson> slangasek, yeah, that's what i'm thinking. i just compared the 2 build logs and noticed that -DSQLITE_ENABLE_UNLOCK_NOTIFY is missing
[02:48] <chrisccoulson> slangasek, oh, DEB_OPT_FLAGS doesn't seem to be used anywhere by cdbs :/
[02:49] <slangasek>   * Deprecate DEB_OPT_FLAG (if ever used it should be done differently).
[02:49] <slangasek> cdbs 0.4.90
[02:50] <slangasek> works fine with previous cdbs, yay
[03:02] <slangasek> chrisccoulson: thanks for letting me know; fixed sqlite3 uploaded
[03:02] <chrisccoulson> slangasek, excellent, thanks for fixing it quickly too :)
[03:46] <psusi> has anyone done any testing yet with uefi?  I finally got a new system that can do it but I can't figure out where to get a uefi shell and maybe other uefi applications and set them up
[04:02] <charlie-tca> bug 712898 just filed for removing a group of packages with todays natty updates
[04:03] <charlie-tca> seems to have taken over 20 applications
[04:05] <persia> I'm not convinced that's an update-manager bug: I suspect it's a bug in the applications, or in one of the libraries upon which they depend.
[04:06] <persia> If they all complain about python-gtk2, it's probably a problem with python-gtk2
[04:06] <charlie-tca> how about python-gtk2
[04:06] <charlie-tca> I just went by the debugging page for updates
[04:07] <micahg> last update was weeks ago
[04:08] <charlie-tca> it's not neccessarily python-gtk2, but it is python related
[04:08] <persia> Finding the actual problem is a matter of running down the chain of "but it is not going to be installed" until you end up with some sensible reason why you can't install something.
[04:09] <persia> I suspect there's some library that had an incomplete transition, and some conflicts that cannot be resolved currently.
[04:15] <JanC> charlie-tca / persia : I _thought_ it was related to python-gobject (saw it too an hour ago or so)
[04:15] <persia> Could well be
[04:15]  * persia is trying to sort out git trees, and hasn't looked into this at all
[04:15] <micahg> ah, in that case, I think there might be a bug already
[04:16] <micahg> bug 712734
[04:17] <micahg> err, maybe not
[04:17] <charlie-tca> nope
[04:17] <charlie-tca> that is just something with python2.6 installing
[04:18] <charlie-tca> I hope it was okay to post that here. Normally I will not do that, but the weekend is coming fast...
[04:21] <persia> -bugs would have gotten a similar response, I think :)
[04:25] <kklimonda> I get an even weirder error on apt-get upgrade: abrowser : Depends: abrowser-branding (= 4.0~b10+build1+nobinonly-0ubuntu2)
[04:26] <micahg> kklimonda: that's not so weird
[04:27] <kklimonda> micahg: I don't really remember installing it
[04:28] <micahg> kklimonda: if firefox was removed like charlie-tca had, it might have tried to install abrowser to fix deps
[04:28] <kklimonda> micahg: ah.. that makes sense
[04:29] <charlie-tca> I can't another bug, but now I am wondering how many will get filed for each application when someone finds it missing
[04:30] <kklimonda> charlie-tca: there is still a whole day to fix it :)
[04:30] <charlie-tca> yup
[04:30] <kklimonda> it does seem to be related to bug 712734
[04:30] <kklimonda> just as micahg was saying
[04:30] <charlie-tca> but I got another person in #ubuntu+1 with the same thing already
[04:35] <wildfire> I'm uploading to a ppa (lp.net/~wildfire/+archive/yate) - and the first email I had back indicated an error (I uploaded a binary rather than source) but my subsequent uploads have not resulted in any email back at all. Any hints on what to do next?
[04:36] <jfer> jono, i sent you an email about acire. will it be included in natty?
[04:39] <persia> wildfire, You might ask the team in #launchpad
[04:50] <TheMuso> Yeah I just went to update and saw heeps of packages wanting to be removed. I just ran a regular upgrade, and am willing to have packages held back, whic were only a handfull, python-gobject* being one of them.
[04:55] <TheMuso> Ok, python-gtk2 depends on python2.6-gobject, which doesn't exist.
[04:56] <TheMuso> So I and there might be more packages in the same position.
[07:57] <didrocks> good morning
[08:01] <pitti> Good morning
[08:01]  * bryceh waves
[08:05] <micahg> pitti: a few people were running into bug 712734 last night
[08:05] <pitti> just saw it
[08:05] <micahg> pitti: have a good day :)
[08:06] <pitti> seems this kind of forces us to bring back python2.6 on the CDs, unless we drop 2.6 support completely
[08:06] <micahg> pitti: discussion on ubuntu-devel about dropping it completely
[08:08] <pitti> I'll re-add py26 support for now to fix the archive, and then investigate more closely
[08:09] <persia> pitti, Is it not possible to just ensure that nothing actually on the CD requires python-2.6, and let it be pulled by updates if (and only if) required?
[08:10] <pitti> persia: not with the way we currently package python apps
[08:10] <pitti> python-foo has the extensions for all supported versions
[08:10] <persia> Oh, right.
[08:10] <pitti> and recently pygobject just started to use functions from libpython
[08:10] <pitti> there isn't much that I can do about it
[08:10] <pitti> I'll check it more closely later on, but I suppose it's necessary
[08:11] <persia> Indeed.  I seem to recall having separate versioned python packages at one point, but in some ways it is good that this is no longer the case.
[08:12] <broder> yeah, an early version of the python policy involved doing that
[08:12] <pitti> persia: rebuilds for all pacakges are still required, but it avoids tons of binary NEWing/removing old packages
[08:13] <persia> Right.
[08:14] <rigved> hi everyone...i'm interested in kernel programming...can anyone guide as to where should i start
[08:19] <dholbach> good morning
[08:47] <diwic> rigved, for general helping out JFo might help you out in #ubuntu-kernel (once he's awake), for actual development reading the "Linux Device Drivers" book (available online, I believe) can be a good start. Or; find something that needs fixing and try to fix it.
[08:48] <diwic> rigved, http://lwn.net/Kernel/LDD3/
[08:48] <rigved> diwic: hmmm...ok...thanks for your help
[09:20] <\sh> hmm..are there any archives of isoimages from non supported releases somewhere? I need a jaunty iso ;)
[09:20] <\sh> jaunty server to be more precise
[09:20] <\sh> ah got them
[09:20] <persia> old-releases?
[09:20] <Tm_T> http://old-releases.ubuntu.com/releases/
[09:21] <\sh> persia: Tm_T: yepp found it
[09:21] <Tm_T> goodie
[09:22] <\sh> grmpf..debugging regressions is time consuming
[09:22] <persia> Some stuff gets lost though: it's tricky to find a feisty Ubuntu Desktop/powerpc CD these days
[09:24] <\sh> do we also have old-archive.ubuntu.com? ,-)
[09:25] <Tm_T> we do
[09:25] <persia> http://old-releases.ubuntu.com/ubuntu/
[09:25] <\sh> very good
[09:41] <soren> persia: I think Kees' CD collection is pretty complete, if you actually need it.
[10:06] <persia> soren, I don't believe anything that is not available on old-releases.ubuntu.com/releases was ever formally pressed in a way that would qualify for that collection.
[10:43] <soren> persia: Oh, ok :(
[10:43] <soren> :), I mean.
[10:43] <soren> Darned keymap.
[11:37] <chrisccoulson> @pilot in
[12:04] <cjwatson> janimo: could you check bug 712859, please?  It looks unclear to me - the Debian side drops -march=armv4t -mno-thumb-interwork, but I don't know whether the compiler defaults are then sufficient
[12:04] <janimo> cjwatson, I'll look
[12:05] <cjwatson> thanks
[12:08] <c2tarun> chrisccoulson: ping
[12:08] <chrisccoulson> hi c2tarun
[12:08] <c2tarun> hi chrisccoulson
[12:08] <c2tarun> you looking at that bug?
[12:09] <chrisccoulson> c2tarun, yeah
[12:09] <c2tarun> chrisccoulson: thanks :) i am right here, just tell me about any error, i'll try to remove it.
[12:09] <chrisccoulson> thanks
[12:24] <janimo> cjwatson, looks safe, they removed the two flags that were not ok for us. In the case there is a new error I can fix it after sync
[12:27] <cjwatson> janimo: ok
[12:27] <cjwatson> thanks
[12:43] <chrisccoulson> c2tarun, i see you dropped debian/patches/01-sigc_namespace.patch from bibshelf, saying that it has been merged upstream, but are you sure that's the case?
[12:44] <chrisccoulson> c2tarun, your new source package contains debian/patches/debian-changes-1.6.0-0ubuntu1, which has the same contents as the patch you dropped
[12:44] <chrisccoulson> and the changes aren't in the upstream source
[12:44] <chrisccoulson> it looks like you deleted the original patch whilst it was applied, thinking that the changes existed in the upstream source ;)
[13:12] <Laney> 3.0 (quilt) yay!
[13:15] <pitti> I actually find it more disturbing that they are applied by default, in the lp:ubuntu/pkg branches
[13:17] <persia> I thought applied-by-default was the preferred presentation format these days, after heaps of complaints about confusion related to unpacked source not matching built source.
[13:17] <pitti> well, but having that in bzr completely breaks e. g. merge-upstream
[13:17] <pitti> you need to unapply before m-u, but then you can't do m-u because you have uncommitted changes
[13:17] <tumbleweed> I think it makes sense for bigger more complex packages, but less so for simple ones
[13:17] <pitti> so you need to unapply, commit, m-u, update patches, re-apply, commit again
[13:18] <tumbleweed> what's also confiusing (to newbies) is that src format 1.0 quilt packages don't have them applied but 3.0 (quilt) do
[13:18] <c2tarun> chrisccoulson: ping
[13:18] <chrisccoulson> hi c2tarun
[13:18] <cjwatson> pitti: you ought to be able to use m-u --force
[13:19] <cjwatson> if that doesn't work, I'd say it's a bug in m-u; it works with plain merge
[13:19] <c2tarun> hi chrisccoulson, I actually copied the debian folder from the older version, how can it be not possible that patches are not applied?
[13:19] <cjwatson>   --force               Merge even if the destination tree has uncommitted
[13:19] <cjwatson>                         changes.
[13:19] <persia> pitti, I'm not sure that's not a tool issue: a merge ought merge smoothly, and then a rebuild ought rebase the patches reported so they go away.
[13:19] <ricotz> cjwatson,  hi, could you restart this build? https://launchpad.net/ubuntu/+source/totem-pl-parser/2.32.2-1 -- it builds fine in natty pbuilder now
[13:19] <bigon> http://launchpadlibrarian.net/63538845/buildlog_ubuntu-natty-amd64.empathy_2.91.6.1-1~ppa11.04%2B1_FAILEDTOBUILD.txt.gz << why doesn't it find the dep, the dep is available in the gnome3 ppa and this ppa is linked with
[13:20] <pitti> persia: well, in the end it is
[13:20] <chrisccoulson> c2tarun, i'm not entirely sure what you did. i'm just pointing out that the patch you dropped hasn't yet been merged upstream ;)
[13:20] <pitti> persia: conceptually it's really wrong to have debian/patches/* files when everything else is in revision control
[13:20] <c2tarun> chrisccoulson: can I PM you ?
[13:20] <pitti> persia: i. e. what we really need is loom, or "pipelines" as they seem to be called today
[13:20] <cjwatson> ricotz: no, it's not going to work, libquvi is in universe and totem-pl-parser is in main.  needs an MIR
[13:20] <persia> pitti, Well, if one is going to use bzr for everything, one ought put things in 3.0 (bzr).
[13:20] <chrisccoulson> c2tarun, sure
[13:20] <cjwatson> persia: I wrote 3.0 (bzr) and even I don't really advocate it :)
[13:21] <cjwatson> it was an experiment, mostly for parity with 3.0 (git)
[13:21] <pitti> cjwatson: i. e. unapply, mu, and rebase patches all in one commit? I guess that's what it comes down to then
[13:21] <ricotz> cjwatson, ok, i see
[13:21] <persia> cjwatson, The feedback I received from some bzr folk last month was that it ought be reimplemented if it was to be adopted.  I don't consider this reflection on your work, but rather emerging understanding of methods of representation.
[13:21] <cjwatson> sure, I wrote it eons ago :)
[13:21] <pitti> cjwatson: (and then hoping that you don't screw up while rebasing the patches and have to start over :) )
[13:21] <cjwatson> pitti: that's what I do, albeit with merge
[13:22] <cjwatson> I agree it could use better tooling
[13:22] <cjwatson> persia: we talked about it at debconf - I think the consensus there was that it was an interesting experiment but basically an upside-down model.  (I forget the details of that argument though.)
[13:24] <persia> I suspect it's worthy of future discussion, but I think it's not worth it until parallel import is implemented in bzr: otherwise it's too hard to sensibly reconcile data from tarballs.
[13:25] <cjwatson> also shallow history would make a big difference to how sane it is
[13:44] <jcastro> lifeless: pong
[13:52] <ari-tczew> chrisccoulson: around?
[13:52] <chrisccoulson> ari-tczew, yes
[13:53] <ari-tczew> chrisccoulson: could you upload this one? bug 708401
[13:53] <chrisccoulson> ari-tczew, in a bit, i'm looking at something else right now
[13:53] <ari-tczew> chrisccoulson: Understood.
[13:59] <hallyn> all right my archive seems pretty messed up.  I can't get past warnings about xorg packages.  it wants me to apt-get update -f, but that doesn't work either.  so i'm quite stuck.  how do i tell it to go bugger off and just install new packages?
[14:02] <cjwatson> hallyn: it'd be easier if we could see literal error messages
[14:02] <cjwatson> I don't believe that it means 'apt-get update -f'.  Perhaps 'apt-get dist-upgrade -f'
[14:03] <hallyn> done that, bunch of times.  i'll pb
[14:06] <hallyn> cjwatson: actually maybe i'tll go better this time.  yesterday it would break.  this morning it kept downloading google-chrome .deb over and over (as file 1, file 2, file 3, etc ) now it's actually downloading files.  i nuked my apt-cache-ng archive, so it's in desparation, so it's going to go slow.
[14:06] <hallyn> https://pastebin.canonical.com/42878/
[14:07] <cjwatson> I suspect those drivers need to be rebuilt against the current server ABI
[14:07] <cjwatson> they probably didn't get picked up by the mega rebuild we did earlier, since they've been demoted to universe
[14:07] <cjwatson> hm, no, that isn't so
[14:08] <cjwatson> RAOF: might be worth going through 'grep-aptavail -FDepends xorg-video-abi-8.0' for more stuff to rebuild?
[14:08] <cjwatson> not sure that's hallyn's problem though.
[14:09] <cjwatson> hallyn: so what does 'apt-get -f install' say?
[14:09] <cjwatson> (no other args)
[14:16] <dobey> hey all, anyone around to discuss a probable automake bug? i'd like to discuss to determine if it's a bug to be fixed in automake, or just some annoying behavior i have to figure out an insane workaround for
[14:19] <mdeslaur> pitti: any idea what could cause bug #713115? I don't know where to start looking...
[14:20] <mdeslaur> pitti: something changed with the recent pygobject
[14:20] <pitti> looking
[14:21] <pitti> mdeslaur: doesn't ring a bell right now, I'll try to reproduce
[14:22] <pitti> mdeslaur: does this happen right at program start?
[14:22] <mdeslaur> pitti: yes
[14:22] <mdeslaur> pitti: launch virt-manager with --debug
[14:22] <pitti> ah, can reproduce
[14:23] <pitti> mdeslaur: still busy with something else, but I'll have a look later on then
[14:23] <mdeslaur> pitti: thanks a bunch :)
[14:28] <hallyn> cjwatson: it's possible that corrupt apt-cacher cache was my problem.  i nuked that, and nuked /var/cache/apt/archive as well, and apt-get -f install looked better.  However, as I'm on 3G right now, and am trying to also get work done, I had to cancel the upgrade for now.  I don't know if it'll succeed after d/l everything, but it's looking better than it was before
[14:31] <sconklin-gone> pitti: when it's convenient for you, could you please copy the mvl-dove kernel and meta packages from our PPA to -proposed?
[14:32] <cjwatson> hallyn: *nod*
[14:34] <pitti> sconklin-gone: for maverick, lucid, or both?
[14:34] <pitti> sconklin-gone: I think wrt. lucid -proposed is by and large unfrozen again, just not -updates
[14:35] <sconklin> pitti: for both please
[14:36] <pitti> sconklin: are there any -dove specific patches in there? (before I start trawling through all the bugs which were just merged from linux)
[14:36] <dobey> eh, found a workaround that doesn't involve patching automake or vala, but is a bit nasty. :-/
[14:36] <dobey> nevermind then
[14:36] <sconklin> pitti: tgardner prepped those, I don't know
[14:37] <pitti> sconklin: ok, I'll check then
[14:37] <sconklin> sorry
[14:37]  * jdstrand finds it curious that he has a defunct metacity process when he is using compiz...
[14:37] <sconklin> pitti: if lucid -proposed is unfrozen, then those packages from our ppa can go as well
[14:38] <sconklin> beware that there is one higher version of a meta package sitting in there I think
[14:38] <pitti> sconklin: https://launchpad.net/~canonical-kernel-team/+archive/ppa/+packages?field.name_filter=&field.status_filter=published&field.series_filter=lucid -> all of those?
[14:39] <sconklin> pitti: ack
[14:45] <ari-tczew> chrisccoulson: when you have done gedit would be nice to have a look on bug 420387 as well
[14:50] <pitti> sconklin: The -meta packages don't actually build depend on the kernel API, right? what keeps me wondering is how a diff like http://launchpadlibrarian.net/63502545/linux-meta-mvl-dove_2.6.32.410.2_2.6.32.414.4.diff.gz (i. e. no changes) can ever actually bump the dependencies to the current ABI if it gets uploaded at the same time as the actual kernel
[14:50] <pitti> sconklin: does *-meta take the ABI from the version number in debian/changelog?
[14:51] <sconklin> if you mean does the meta package take the ABI from the kernel package, no. The version is manually changed in the meta package changelog by someone when required by an ABI bump in the kernel package
[14:52] <pitti> sconklin: ah, so it does parse the changelog
[14:53] <pitti> linux-meta-mvl-dove (2.6.32.414.4)
[14:53] <sconklin> yes
[14:53] <pitti> sconklin: i. e. it strips off the .4, and turns that into 2.6.32-414?
[14:53] <pitti> sconklin: ah, thanks; I was always wondering whether I need to wait with accepting -meta until the actual kernel has built
[14:53] <sconklin> pitti: I assume so based on the fact that the only place we change a version is in the changelog
[14:53] <pitti> that would have brought a lot of speedup for the old-style "accept from -proposed" workflow
[14:54] <persia> The worry is that if there is a publisher run, the -meta update is uninstallable until the kernel binaries are published.
[14:54] <sconklin> I have never had to dig into the meta package makefiles, so I'm not very familiar with them
[14:57] <pitti> sconklin: hm, the current -29.57 upload changelog refers to bug 705565
[14:57] <pitti>  that's a bit confusing
[14:57] <sconklin> looking
[14:57] <pitti> ah, it's built with -v and two changelogs
[14:57] <pitti> so it's kind of obsolete
[14:58] <pitti> bug updated
[15:02] <pitti> sconklin: I think Jeremy should update his overzealous "please confirm with upstream kernel" auto bug replies to not cover trackign bugs :)
[15:02] <sconklin> pitti: we've discussed this, and a change is coming soon ;-)
[15:03] <pitti> sconklin: mvl-dove uses the same tracking bug 712610  for lucid and maverick; was that intended?
[15:05] <sconklin> pitti: that's not normally the way we do it. I'll make sure our documentation is complete on that and make sure Tim knows for next time. For this time we can probably just deal with it
[15:05] <pitti> *nod*
[15:05] <sconklin> thanks for noticing. It will probably break our status display
[15:09] <pitti> sconklin: I think I caught everything now; please let me know if something is still missing in 2 hours
[15:09] <sconklin> pitti: thanks!
[15:09] <pitti> sconklin: (your status display complains then?)
[15:10] <sconklin> our status display just lists kernels by series and then whether the tracking bug is set to verified. So the information for those two series will be conflated in the display
[15:11] <pitti> sconklin: ah, you don't have something that shows newer packages in your PPA?
[15:11] <pitti> that should ideally be empty now
[15:11] <sconklin> pitti: I've been writing that tool yesterday and today
[15:11] <pitti> actually, now that you use launchpadlib this should already be updated, as lplib doesn't depend on the publisher
[15:12] <sconklin> we're not using lplib yet - I've been putting all that new functionality into our tools module base classes
[15:12] <sconklin> https://kernel-tools.canonical.com/srus.html
[15:13] <sconklin> There's the display, but it still doesn't show lucid because the cron jobs haven't run yet.
[15:13] <sconklin> and I think that it currently does not show arm anyway - that's another thing on my list
[15:39] <jdstrand> pitti: hi! not sure if you've seen this but bug #713115 and bug #713135 have been filed. downgrading to pygobject 2.27.0+git20110108-0ubuntu1 fixes the issue. meld is also affected (and I don't know what else)
[15:39] <jdstrand> meh
[15:39] <pitti> jdstrand: yep, currenlty debugging 713115
[15:39] <pitti> jdstrand: feel free to make 35 a dupe of 15
[15:40] <jdstrand> pitti: ok, I unprivated bug #713135
[15:40] <jdstrand> pitti: ack
[15:40] <pitti> ah, so that one isn't virt-manager
[15:40] <jdstrand> pitti: no. virt-manager, hamster and meld I know are affected, with downgrading fixing it
[15:41] <pitti> OperationalError: no such module: fts3
[15:41]  * jdstrand nods
[15:41] <pitti> that doesn't look at all like the segfault that virtmanager gets, though?
[15:41] <jdstrand> no, it doesn't, but again, if I downgrade it works
[15:42] <jdstrand> pitti: meld has yet a different error
[15:42] <pitti> ah, bisected the fix for virt-manager
[15:42] <pitti> meh, I was afraid of that
[15:42] <pitti> it fixed reference leaks
[15:42] <pitti> but that uncovered tons of bugs in GTK
[15:42] <pitti> so if I revert the reference leak fix, it'll probably work again, but we'll keep the mem leaks forever
[15:43] <jdstrand> the hamster line in question is: self.execute("""CREATE VIRTUAL TABLE fact_index USING fts3(id, name, category, description, tag)""")
[15:43] <jdstrand> I see
[15:43] <jdstrand> so, I'll file the meld one then too
[15:43] <pitti> I'll check first if (a) this is the reason for hamster-applet as well, and then check if i can fix it in GTK rather
[15:43] <jdstrand> and undupe the hamster one
[15:45] <pitti> jdstrand: hm, does the applet work for you if you just start it with
[15:45] <pitti> /usr/lib/hamster-applet/hamster-applet
[15:45] <pitti> ?
[15:45] <pitti> it doesn't crash here (with the downgraded pygobject)
[15:45] <pitti> but doesn't do anything eiterh
[15:45] <seb128> pitti, well applet you need to run on the command line and then add to gnome-panel in the ui
[15:45] <seb128> it will use the running instance
[15:45] <pitti> ah
[15:46] <jdstrand> pitti: maybe try hamster-time-tracker
[15:46] <jdstrand> that will launch a non-panelized hamster
[15:46] <pitti> crashes with a dbus error
[15:46] <pitti> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name :1.534 was not provided by any .service files
[15:47] <jdstrand> maybe that worked here because the panel applet was already running
[15:48] <jdstrand> I see in the desktop file: /usr/lib/hamster-applet/hamster-applet -s over
[15:48] <pitti> searching for "hamster" in the applet list doesn't bring up anything
[15:48] <pitti> jdstrand: already tried that
[15:48] <pitti> I'm under standard gnome now
[15:48] <jdstrand> pitti: I think it is Time Tracker
[15:48] <seb128> pitti, try to send a sigHUP to gnome-panel or restart it
[15:48] <seb128> or maybe what jdstrand said rather
[15:49] <jdstrand> pitti: yes, that's it
[15:49]  * pitti tries restarting panel
[15:49] <pitti> ah, that helped
[15:49] <pitti> except that it's still crashing :/
[15:50] <jdstrand> pitti: I needed to restart my session after downgrading to have hamster work
[15:50] <pitti> aah - /var/crash/_usr_bin_hamster-service.1000.crash
[15:50] <pitti>  OperationalError: duplicate column name: search_name
[15:50] <jdstrand> presumably because there is hamster-service and hamster-applet that are running, and I only managed to restart one of them
[15:51] <pitti> did that actually ever work?
[15:51] <jdstrand> pitti: I use it every day. it is an integral piece of my daily work flow
[15:51] <bigon> anybody understand why it doesn't find the dep? http://launchpadlibrarian.net/63550283/buildlog_ubuntu-natty-i386.empathy_2.91.6.1-1~ppa11.04%2B1_FAILEDTOBUILD.txt.gz it's linked to the GNOME3 ppa with nautilus 1:2.91.7-0ubuntu1~build1
[15:51] <pitti> $ /usr/bin/hamster-service
[15:51] <pitti> sqlite3.OperationalError: no such module: fts3
[15:51] <pitti> ah, I think I get closer now
[15:52] <pitti> jdstrand: I think what you saw just bounced the backend exceptino back to the client through dbus
[15:53] <jdstrand> k
[15:53] <pitti> jdstrand: but it doesn't work with the old pygobject eitehr
[15:53] <jdstrand> pitti: well, I downgraded, restarted my session, and I am using it as we speak
[15:53] <jdstrand> pitti: I promise I am not lying :)
[15:54] <pitti> of course not, just trying to reproduce
[15:54]  * jdstrand was just kidding
[15:54] <jdstrand> pitti: these are what I downgraded- python-gobject python-gobject-cairo python-gobject-dev
[15:55] <jdstrand> and with the exception of bzrtools (unrelated- just floated in), I am fully up to date
[15:55] <pitti> ah, perhaps cairo, too
[15:57] <RoAkSoAx> Anyone know if *.tar.xz tarballs are accepted in the archives?
[15:57] <pitti> jdstrand: bug updated with a question for you (let's keep it there to have a better debug record)
[15:57] <pitti> jdstrand: I'll check virt-manager in the meantime; can you please sub me to the meld bug?
[15:58] <jdstrand> pitti: sure, filing it now
[15:59] <geser> bigon: probably because of "Conflicts: libnautilus2-2, libnautilus2-dev, nautilus-sendto" from nautilus (from the gnome3 PPA)
[16:00] <shadeslayer> RoAkSoAx: afaik no
[16:01] <shadeslayer> but if they are .... lemme know .. i'd like to use them for Project Neon
[16:01] <jdstrand> pitti: subscribed you to bug 713172 (meld)
[16:01] <RoAkSoAx> shadeslayer: i know PPA's don't. Not sure about official archives
[16:02] <shadeslayer> ah ..
[16:02] <shadeslayer> we use PPA's ... so thats out of the question then :P
[16:03] <RoAkSoAx> shadeslayer: you might wanna ping someone from LP and ask for the support though
[16:03] <shadeslayer> alrighty :)
[16:03] <bigon> geser: yeah just saw it, I'm an idiot
[16:03] <bigon> thx :)
[16:05]  * bigon is still not sure why the Conflicts
[16:06] <RoAkSoAx> jdstrand pitti Do Ubuntu archives support .tar.xz tarballs?
[16:06] <pitti> I don't know
[16:06] <RoAkSoAx> pitti: who do you think I might now :)?
[16:06] <pitti> just try to upload to a PPA?
[16:06] <RoAkSoAx> pitti: PPA's don't
[16:06] <pitti> RoAkSoAx: the soyuz guys
[16:06] <pitti> (sorry, in meeting)
[16:06] <jmarsden> RoAkSoAx: Didn't bigjools just tell you "no" in #ubuntu-server ?
[16:07] <RoAkSoAx> jmarsden: sry wasn't paying attention ther :)
[16:10] <pitti> jdstrand: hm, so hamster is a miracle to me
[16:11] <jdstrand> pitti: I responded to your question in the bug
[16:13] <pitti> jdstrand: me too again
[16:13] <jdstrand> pitti: on it
[16:23] <pitti> chrisccoulson: meh ^ can you please do @pilot in again to fix it?
[16:24] <pitti> oh, hang on
[16:24] <pitti> I'll fix it
[16:24] <chrisccoulson> oh, what happened?
[16:24] <pitti> IRC vanalism
[16:31] <ogra> could someone ban him ?
[16:31] <ogra> thanks Pici
[16:31] <Pici> ogra: np
[16:33] <cjwatson> I'd have banned him the first time but didn't think it was worth it since he'd already left ...
[16:34] <smoser> cjwatson, i seem to be unable to get the 'shift' key passed through to kvm (or something else is wrong), and thus, i can't get to a grub menu on boot
[16:35] <smoser> do you have suggestion? reading grub.cfg it looks to me like i might have 3 seconds of 'sleep --interruptable', but i'm not sure how to interupt that either.
[16:36] <pitti> smoser: did you try with grabbing keyboard/mouse (ctrl+alt)?
[16:36] <smoser> maybe i'm just not fast enough
[16:36] <smoser> i do get the it grabbed. but maybe its something else, as i'm working off a uec-image that might for some reason be slightly different.
[16:37] <cjwatson> smoser: I've never been able to.  I think it's a kvm bug
[16:37] <SpamapS> Hmm.. interesting conundrum ... since we disable insserv .. any package from Debian that uses insserv overrides to affect the boot introduces a boot ordering bug...
[16:38] <SpamapS> for instance, bug #652433
[16:38] <cjwatson> smoser: personally I turn off GRUB_HIDDEN_TIMEOUT and GRUB_HIDDEN_TIMEOUT_QUIET in kvm, but I appreciate that this is awkward if you can't even get that far
[16:38] <smoser> so just comment those out ?
[16:38] <cjwatson> you won't have three seconds of 'sleep --interruptible', no - that's a case that isn't used
[16:38] <cjwatson> comment the first out, change the second to =false
[16:39] <smoser> danke
[16:39] <smoser> next question, then... can i do that in a uec build ?
[16:39] <smoser> and not be prompted on a grub upgrade?
[16:40] <smoser> i seem to remember some issues with me changing defaults and being prompted on grub upgrade (i can search for more info from logs if i'm not clear enough)
[16:40] <cjwatson> it might depend on the exact way you disable it - you should definitely test
[16:41] <cjwatson> I don't honestly know off the top of my head
[16:41] <smoser> :)
[16:41] <smoser> fair enough. thanks.
[16:42] <smoser> and also, since we're here, GRUB_GFXMODE=text is reasonable ?
[16:48] <cjwatson> smoser: GRUB_TERMINAL=console would be more usual, if you just want to not use the graphical terminal
[16:48] <smoser> thanks.
[16:57] <jdstrand> pitti: applying your pygobject patch made meld and hamster work again
[16:57] <pitti> jdstrand: ok, as I suspected; thanks
[16:58] <pitti> not that it would help much yet, except to confirm that we have this bad workaround
[16:58] <pitti> but thanks a lot for testing
[16:58] <pitti> jdstrand: I can perfectly reproduce virt-manager and meld, but still not hamster, though
[16:58] <jdstrand> pitti: sure, np
[16:59] <jdstrand> pitti: well, if you get those fixed via an underlying library, I'm more than happy to test hamster
[16:59] <kees> soren, persia: only missing 2 CD, to my knowledge.
[16:59] <kees> *CDs
[17:01] <pitti> jdstrand, kenvandine: ok, will upload the workaround, to keep things working, and test against upstream to replicate the crashes
[17:01] <seb128> is there a way to read from a C program running a system service the input from a device?
[17:03] <seb128> got asked by someone who try to get a usb barcode reader working, the thing seems to be seen as a standard input
[17:03] <seb128> i.e chars got printed on the command line when the reader reads something while being on a vt
[17:03] <kenvandine> pitti, thx
[17:12] <stgraber> seb128: you should be able to get that by reading /dev/input/<something>
[17:12] <stgraber> seb128: for example on my laptop: /dev/input/by-path/platform-i8042-serio-0-event-kbd
[17:13] <stgraber> seb128: for the keyboard, though there might be cleaner ways of doing it ;)
[17:16] <seb128> stgraber, right, but it seems to give you non decoded input
[17:16] <seb128> stgraber, i.e if you do it on your keyboard you will not get what you type
[17:17] <stgraber> seb128: indeed. I don't know of any /dev/<something> device that gives you the decoded output, so you may have to do the decoding yourself ...
[17:17] <stgraber> I'm guessing that what we see is essentially keycodes, so using the US keymap (or similar) it should be possible to get the ASCII value
[17:17] <seb128> one way to get it work would be to get the box to autologin, run the code and read stdin
[17:18] <seb128> but that's not really elegant
[17:18] <seb128> would work though since the computer has that as only task, reading from this usb reader and doing what the code tells it
[17:23] <soren> kees: Which ones?
[17:29] <kees> soren: 7.04 Feisty Fawn Edubuntu i386 http://commons.wikimedia.org/wiki/File:Edubuntu_7.04.jpg
[17:29] <kees> soren: 4.10 Warty Warthog Ubuntu amd64
[17:29] <kees> soren: 5.04 Hoary Hedgehog Ubuntu amd64
[17:29] <kees> but I haven't confirmed that the last two even exist
[17:30] <kees> soren: and if this isn't a hand-made CD, http://commons.wikimedia.org/wiki/File:Kubuntu_6.06_CD.jpg I need the entire 6.06.1 set
[17:32] <soren> kees: Looks pretty convincing if it is.
[17:32] <kees> soren: yeah. :(
[17:32] <kees> soren: but I can not find anyone who has ever seen those.
[17:33] <kees> so, I'm almost certain Hoary came with amd64. dunno about warty.
[17:36] <kees> but maybe breezy was the first with amd64 CDs
[17:38] <soren> kees: http://ubuntuforums.org/showthread.php?t=233444
[17:39] <soren> kees: Specifically, "Shipit will be updated within approximately the next month with Ubuntu
[17:39] <soren> 6.06.1 LTS."
[17:40] <soren> kees: It seems legit.
[17:42] <stgraber> seb128: I did a quick test writting modifying the code of evtest and it seems quite easy to use that to decode whatever is being typed on any /dev/input/* device
[17:43] <seb128> stgraber, ok thanks, I found some examples of code decoding the input stream as well
[17:46] <kees> soren: aaargh, now I'm even further behind. :)
[17:50] <stgraber> seb128: apt-get install logkeys
[17:51] <seb128> stgraber, thanks
[17:51] <stgraber> seb128: though if you need 64bit, you'll need a new upstream version (http://logkeys.googlecode.com/files/logkeys-0.1.1a.tar.gz)
[17:51] <stgraber> you can give it an input device and it'll log in a file, should be simple enough to interface wiht that
[17:52] <seb128> right
[17:54] <cjwatson> kees: Warty had amd64, but only for the install CD (today's "alternate").  Hoary had amd64 across the board.
[18:01] <kees> cjwatson: that's what I feared. :)
[18:02]  * kees needs to visit London to get the missing CDs. :)
[18:04] <achiang> can anyone answer a germinate question? if i create a STRUCTURE file that "overrides" a seed, what is the behavior? does my statement replace the prior one? or is there multiple inheritance?
[18:04] <achiang> for instance, i say: standard: my-new-minimal-seed
[18:04] <achiang> will the standard seed then only be based on my-new-minimal-seed, or will it be a combo of both minimal and my-new-minimal-seed ?
[18:05] <achiang> my theory is that "last statement wins, no multiple inheritance"
[19:05] <chrisccoulson> @pilot out
[19:08] <jdstrand> seb128: hey, have you seen how strange evolution is with unity-2d?
[19:09] <alexbligh> I'm making a package using dh_make (not pbuilder). How do I specify that I want a file to be owned by something other than root?
[19:43] <lifeless> jcastro: see mail
[20:04] <seb128> jdstrand, no
[20:05] <nxvl> stgraber: ping
[20:06] <bryceh> @pilot in
[20:06] <ohsix> what's a pilot? standby guy that's gonna be around for a bit?
[20:08] <bryceh> patch sponsor
[20:09] <chrisccoulson> ohsix, https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#Patch%20Pilots
[20:19] <stgraber> nxvl: pong
[20:22] <nxvl> stgraber: is there any easy howto for LTSP
[20:23] <nxvl> stgraber: a friend of mine wants to use it for a call center and asked me for help
[20:23] <nxvl> stgraber: but i've no idea
[20:24] <stgraber> nxvl: https://help.ubuntu.com/community/UbuntuLTSP would be a good start. Installation is usually as simple as having a machine with two NICs and using the LTSP option of the alternate CD
[20:25] <stgraber> nxvl: depending on how powerful the clients are, your friend might want to run some software locally, for that look at the documentation for "localapps". It's basically about installing the extra software in the chroot and recompressing it
[20:26] <nxvl> stgraber: so, basically it works out of the box with the alternate installer?
[20:26] <stgraber> yep, just find a server with two NICs, on the CD boot menu, press F4 et choose LTSP
[20:26] <stgraber> then at install time, choose the NIC that's connected to the internet, the other will be setup as the LTSP interface and a DHCP server will be started on it
[20:26] <nxvl> stgraber: the clients only need an asterisk client
[20:26] <nxvl> stgraber: and that's it
[20:27] <nxvl> stgraber: ok, thanks for the info, will take a look
[20:27] <stgraber> ok, so you'll probably want to install twinkle or something like that in the chroot then: https://wiki.ubuntu.com/LTSPLocalAppSetup
[20:28] <stgraber> let me know if you have any problem with it, but usually getting the server running is very easy
[20:29] <nxvl> stgraber: sure, will let you know, thanks for the info!
[20:33] <cjwatson> achiang: your theory is correct - last entry for a given name in STRUCTURE wins
[20:33] <achiang> cjwatson: thank you
[20:42] <bobg> i am trying to find where policy is defined for upstart -- i.e. should you use /etc/defaults/mypackage, how should you allow your service to be disabled (not started at startup). anyone know?
[20:43] <soreau> Hello, I have an AR5008 (pci atheros chip) that uses the ath9k driver. All had been working fine up until 2.6.35 kernels. Now, the monitor function of the card gets stuck in channel -1 and you must build/install a patched compat-wireless. While this fixes the faulty channel issue, it also introduces kernel panics soon after connecting to an ap with managed mode. How can I find more information about this?
[20:43] <broder> bobg: with upstart, the recommended way to do that is to tell the admin to just comment out the "start on" line
[20:44] <soreau> Specifically, I want to make sure this problem gets fixed upstream but I don't know where to find whoever works on ath9k and related mac80211 drivers
[20:47] <debfx> bryceh: could you please sponsor the debdiff for maverick-proposed on bug #400851
[20:50] <bobg> broder, thanks. is there anything like the "Debian Policy Manual " for ubuntu specific policies?
[20:50] <bryceh> debfx, on it
[20:51] <broder> bobg: there's an ubuntu policy manual, but it's not actually different from debian policy (as it should be). i know that the server team is putting together docs during this release cycle for things like upstart idioms
[20:52] <bobg> broder, ok, thanks
[20:53] <debfx> bryceh: thanks
[20:56] <bryceh> debfx, uploaded
[20:57] <cjwatson> broder: well, it's somewhat different, just needs to be more so
[20:57] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2008-August/026160.html
[20:58] <cjwatson> I would ask the server team to consider whether the documentation they're putting together includes policy-relevant sections, and if so to seek to merge them into policy rather than creating entirely new documents
[20:59] <broder> cjwatson: the only difference right now is that Ubuntu Policy includes our maintainer policy, right?
[21:00] <broder> but in any case, i feel like the things bobg is asking about are more about convention and idiom than policy
[21:04] <cjwatson> broder: there are a few more differences than that
[21:04] <cjwatson> http://paste.ubuntu.com/562749/
[21:05] <cjwatson> (it could use a merge, though)
[21:05] <bobg> at this moment it seems that debian policy on providing services is different than ubuntu policy. It depends on whether that is a temporary situation or a long term divergence
[21:05] <broder> bobg: it's still completely ok to ship sysvinit-style jobs in ubuntu
[21:06] <broder> and there's also some ongoing work to add upstart awareness to debian policy
[21:06] <broder> which i think will help bridge some of the gap on these kinds of things
[21:11] <bobg> broder, upstart coexisting with sysv is just a transition thing, right? Are debian and ubuntu working toward the  same service implementation policy but only at different speeds?
[21:16] <broder> bobg: debian isn't going to be interested in forcing users to use a single init daemon when there are multiple options, so anything debian does will give users the choice of switching between sysvinit, upstart, and probably systemd
[21:16] <broder> so their version of the policy will be about letting a package, e.g., use upstart if it's available and fall back on sysvinit otherwise
[21:19] <bobg> broder, do you think ubuntu policy will be different? Or are you saying that sysvinit is here for the long haul on both ubuntu and debian?
[21:20] <broder> bobg: no, i don't think ubuntu will ever let you switch back to sysvinit, but we'll take advantage of the fact that packages can support upstart and sysvinit simultaneously
[21:23] <ohsix> it should be noted that the alternate init systems can use sysvinit type scripts as a lowest common denominator
[21:24] <ohsix> so you can work from there and specialize if the package can take advantage of it
[21:24] <broder> ohsix: right, which is basically what the debian policy changes are about codifying
[21:27] <bobg> broder, thanks.  BTW, i like upstart, but find the lack of information, lack of command completion, and lack of a clear method of mapping tasks that you could do with sysvinit,  frustrating.  However I chalk all that up to it being new.
[21:28] <broder> bobg: yeah, i know where you're coming from. i'm hoping that that'll get better this release with some of the documentation that's getting pulled together
[21:32] <bobg> i keep meaning to figure out that confusing command completion syntax. I feel like its going to be a big learning curve,
[21:41] <gurkan> hi all mates
[21:42] <gurkan> is it normal that my utmp file is in /var/run
[21:43] <broder> yes
[21:45] <gurkan> why
[21:45] <gurkan> it is not in /var/log ?
[21:46] <broder> because the fhs says that it must go in /var/run?
[21:46] <broder> http://www.pathname.com/fhs/pub/fhs-2.3.html#REQUIREMENTS14
[21:48] <gurkan> how it is possible that susch a logfile could be in /var/run ?
[21:53] <cody-somerville> gurkan, /var/run/utmp is not a logfile.
[21:54] <ion> utmp(5)
[21:57] <Keybuk> cody-somerville: false
[21:57] <Keybuk> it's kiiiinda a log file
[21:57] <Keybuk> but /var/log/wtmp is a log file
[21:58] <broder> Keubuk: utmp, not wtmp
[21:58] <Keybuk> broder: yes, I know
[21:58] <broder> oh, never mind - misread
[21:58] <Keybuk> but utmp is also a log\
[21:58] <broder> yeah, sure
[21:58] <Keybuk> as well as a state file
[21:58] <Keybuk> some of the things you put in utmp are still log entries
[21:58] <Keybuk> but all of the things you put in wtmp are log entries
[21:58] <Keybuk> it's the kind of cluster-fuck that comes from being compatible with something nobody cares about
[22:00] <gurkan> cody-somerville ok i understand , but where do you find your utmp log file ? i have /var/log/wtmp but not utmp
[22:00] <Keybuk> also most of utmp(5) is a lie, since init on ubuntu doesn't bother writing to utmp ;-)
[22:00] <Keybuk> gurkan: utmp is in /var/run
[22:01] <gurkan> <Keybuk ok <cody-somerville will not be agree with u i think
[22:01] <Keybuk> /var/run/utmp is created by /etc/init/mounted-varrun.conf
[22:01] <Keybuk> which is run as a result of /var/run being mounted as a tmpfs
[22:02] <Keybuk> you can munt a system sufficiently that it won't be run
[22:02] <Keybuk> but then lots of things will probably break, not just the existance of that file
[22:03] <gurkan> then with utmp.h i could code an acces code to /var/run/utmp ?
[22:03] <Keybuk> yes
[22:03] <gurkan> ok thank keybuk
[22:04] <Keybuk> good rule of thumb - things in /var/run don't survive a reboot
[22:04] <Keybuk> and that's basically the difference between utmp and wtmp
[22:04] <Keybuk> utmp is a "this boot only" log
[22:05] <Keybuk> whereas wtmp is historic
[22:05] <Keybuk> utmp also holds current state
[22:06] <gurkan> this /var/run/utmp file stores like wtmp ?
[22:06] <Keybuk> yes, they're similar formats
[22:06] <Keybuk> but not identical
[22:08] <gurkan> and in other nix this is not the same implementation ?  you said it store the current state but until the next boot of the machine ?
[22:09] <Keybuk> it's broadly the same as SysV and BSD
[22:09] <Keybuk> formats and details vary
[22:09] <gurkan> for resume his contents are volatile
[22:25] <agronholm> has anyone here been able to install ubuntu natty?
[22:25] <agronholm> alpha2 that is
[22:25] <agronholm> the installer crashes, and typing anything is difficult because it disables most keys on the keyboard
[22:26] <bryceh> installed it on two different machines yesterday
[22:26] <ohsix> can you still press a key during the bootloader to pick a keymap?
[22:26] <ohsix> (like in 10.10)
[22:26] <agronholm> not sure, it picked the default keymap based on the install language
[22:27] <agronholm> if I type "qwertyuiop" all I get is "ertp"
[22:27] <agronholm> most character keys are disabled
[22:27] <agronholm> makes typing kinda difficult
[22:28] <agronholm> I'm installing on a Virtualbox 4.0.2 VM on a linux host
[22:28] <jono_> what is the installer package that I can file a bug against with ubuntu-bug?
[22:28] <agronholm> hm
[22:29] <agronholm> if I go back and manually select "Finnish", then the keyboard works as expected
[22:30] <agronholm> "The installer encountered an unrecoverable error. A desktop session will now be run so that you may investigate the problem or try installing again."
[22:30] <agronholm> jono_: having similar problems?
[22:30] <jono_> agronholm, nope
[22:31] <agronholm> what kind of trouble are you having?
[22:31] <charlie-tca> jono_: which image, desktop or alternate?
[22:31] <jono_> charlie-tca, desktop
[22:31] <charlie-tca> jono_: ubuntu-bug ubiquity
[22:31] <jono> thanks charlie
[22:31] <jono> thanks charlie-tca
[22:31] <charlie-tca> You are welcome
[22:32] <agronholm> ok now out of the blue, a dialog popped up "System program problem detected"
[22:32] <agronholm> wasn't even doing anything
[22:32] <agronholm> Report problem...
[22:32] <charlie-tca> agronholm: you are trying to install natty in VBOX?
[22:32] <agronholm> yes
[22:32] <agronholm> "Sorry, the program "plugininstall.py" closed unexpectedly"
[22:33] <agronholm> charlie-tca: I don't have real workstations to spare for testing out something like this :)
[22:33] <charlie-tca> there was a workaround we used for 64bit images, if that is what you are installing.
[22:33] <agronholm> yes
[22:34] <agronholm> this would be more productive if it actually told me something about the error
[22:34] <charlie-tca> try this - https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview#Boot,%20installation%20and%20post-install
[22:34] <agronholm> I see
[22:35] <agronholm> thanks
[22:35] <charlie-tca> each distro has to change it slightly, but it works
[22:35] <agronholm> change what
[22:35] <charlie-tca> You are welcome
[22:36] <charlie-tca> that workaround, purging "ubiquity-slideshow-ubuntu"
[22:36] <charlie-tca> changed ubuntu to xubuntu, edubuntu, kubuntu, all work
[22:37] <agronholm> well I hope it's fixed before alpha 3
[23:05] <DJKorbit> good evening
[23:06] <DJKorbit> i'm trying to compile eye of gnome but i'm getting an error, i don't know if this is the right place to post this question
[23:06] <DJKorbit> eog-window.c:70:35: fatal error: launchpad-integration.h: No such file or directory
[23:06] <DJKorbit> compilation terminated.
[23:07] <bryceh> DJKorbit, see topic
[23:07] <DJKorbit> i did and apt-get source eog
[23:07] <bryceh> DJKorbit, maybe apt-get build-dep eog ?
[23:08] <DJKorbit> ./configure ran fine so i guess this error shouldn't have happened
[23:08] <DJKorbit> but i'll try that anyway
[23:16] <DJKorbit> bryceh, it fails to compile even after build-dep
[23:16] <DJKorbit> with the same error
[23:20] <bryceh> DJKorbit, dunno then
[23:23] <DJKorbit> bryceh, i'll try an apt-file search launchpad-integration.h
[23:26] <DJKorbit> i've changed the include line from <launchpad-integration.h> to <launchpad-integration/launchpad-integration.h>
[23:26] <DJKorbit> it compiled but now is breaking on linking
[23:32] <broder> DJKorbit: do you have liblaunchpad-integration-dev or whatever installed?
[23:33] <broder> that usually means that the CFLAGS for launchpad-integration aren't getting injected correctly
[23:33] <DJKorbit> yes, i have them installed
[23:33] <DJKorbit> now it's failing to link so i might have a problem in the LDFLAGS
[23:34] <broder> oh - you probably didn't apply the patch series
[23:34] <DJKorbit> i didn't how can i do that?
[23:34] <broder> hmm, nope - it's 3.0 (quilt) so that doesn't matter
[23:34] <DJKorbit> i didn't, how can i do that?
[23:34] <bryceh> ./debian/rules patch
[23:34] <broder> ah, got it - you need to re-run 'autoreconf'
[23:35] <bryceh> or just run `debuild` in the source tree, that should do everything automatically and give you a .deb
[23:36] <DJKorbit> i don't want a deb, i just want to fix a bug but i want to compile first to see if the latest version has the bug i'm experiencing
[23:39] <bryceh> DJKorbit, in that case then I think this is not the right channel ;-)
[23:39] <DJKorbit> broder, with your autoreconf i get a version mismatch error from intltool
[23:40] <DJKorbit> i guess i'll have to work with the upstream version in eog's git repository
[23:40] <DJKorbit> if it also has the bug, it will eventually get into gnome once i fix it
[23:41] <DJKorbit> and i could also try to learn how to contribute fixed packages to ubuntu
[23:58] <DJKorbit> broder, how can i apply the patch series?
[23:59] <broder> DJKorbit: i was wrong - that happens automatically. you just need to run autoreconf
[23:59] <DJKorbit> autoreconf and run make again?