[00:18] hallyn, it's not required to have a bug for merges [00:19] hallyn, generally you'd file a bug for a merge if you're seeking sponsorship [00:25] ok, can anyone remember how ssh-agent/gnome-keyring/seahorse is supposed to work in Lucid? :-/ [00:25] automagically? [00:26] seahorse-agent should cover both ssh & gpg -agent stuff iirc === dendrobates is now known as dendro-afk [00:27] (but seahorse-agent isnt api compatible with them so kmail falls over if its running instead of gpg-agent, but anyway...) === dendro-afk is now known as dendrobates [00:30] maco: well, so I have seahorse agent [00:30] but seahorse agent is only exporting GPG agent environment [00:30] not SSH agent [00:30] that miiight be right... i dont have a .... hang on i might have a vm [00:31] i have a maverick vm [00:32] so where does the ssh agent come from? [00:32] on my maverick it is running [00:33] but...wow maverick's confusing when you havent used gnome since hardy... [00:33] seahorse isnt in the menu anymore [00:33] ok i think seahorse just covers gpg [00:34] but it should offer to remember your ssh key passphrase for the rest of the session [00:35] hmm [00:35] right [00:35] 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] kubuntu user? [00:35] yep [00:36] 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] you mean, "launcher on the side with big buttons" ;) [00:37] nah he sticks to lts [00:37] 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] ooh, sneaky [00:39] * Keybuk blames Caesar [00:39] i found seahorse btw. its in system -> preferences now [00:39] Keybuk: who? === sconklin is now known as sconklin-gone [00:40] or was that metaphorical? [00:40] maco: no, it was directed ;-) [00:40] discovery: the first thing that happens when i click on ubuntu software center is that i get a crash notification. shiny [00:40] (the computer with the vm has no network access, so no i'll not be sending a crash report) [00:41] (for all i know its fixed in an update anyway) [00:41] alpha 4...yeah probably fixed by now [00:51] that's some old vm :) [00:52] 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] jcastro: ping [00:58] 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] previously, i have files like dirs, install, postrm, postinst, prerm, etc. [00:59] achiang: you rename them to (binary package name).dirs etc. [00:59] must i create foo.dirs, bar.dirs ; foo.install, bar.install? [00:59] what if there is some commonality? [01:00] say dirs remains the same, but install should be different [01:00] barry: I suggest you for merge package nipy from Debian @universe. I could have a look on it then. [01:00] can i just keep dirs, but then create foo.install and bar.install? [01:00] achiang: no idea, but you can try doing that ans seeing what happens [01:00] heh [01:01] the less obvious files to me are compat, copyright, and this odd one named gconf-defaults [01:01] i think those can remain as-is, right? [01:02] i think compat and copyright should be fine, but gconf-defaults should be named foo.gconf-defaults [01:02] 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] kklimonda: thank you [01:42] 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] 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] seems rather anti-DRY [01:44] I’d suggest using dh 7 and not copying a plethora of dh_* commands anywhere. [01:44] achiang: no, dh7 should take care of that unless you need to override [01:44] ah, i will go read about dh7, thank you ion and micahg [01:45] achiang, The conventional DRY way is to use rules.tiny and only vary from the defaults when using debhelper support files. [01:45] List binary packages in debian/control and for each package create debian/$PACKAGE.install to describe which files go into it. [01:46] 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] even though the config file is present in both foo.install and bar.install [01:46] s/present/listed/ [01:47] 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] 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] (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] They'll have to Conflict: [01:50] so i have been trying: echo file.conf /etc > foo.install ; echo file.conf / etc > bar.install [01:50] And that file exists at the root of the packaging directory? [01:51] 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] well, for this example, yes. i mean, in reality, i specify the full path to file.conf in [foo|bar].install [01:52] Full path? It ought only take a relative path (but I'll presume that is what you meant) [01:52] Is the configuration file created by the build system, or just pulled from the source? [01:53] just pulled from source (and yes, sorry, relative path) [01:55] hm, changing debian/compat to say 7 (from 5) didn't really help [01:55] 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] persia: which configuration? [01:58] Whatever configuration you want in both packages. [01:59] override_dh_auto_install:\n\tdh_auto_install\n\tinstall -m 644 -d ${DEST} ${FILE} [02:01] 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] Commonly that's done with a -common package containing all the shared stuff. [02:06] 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] 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] persia: yes, thank you for the guidance. and i'll use #ubuntu-packaging for questions like this in the future. :) [02:08] Heh, that's why it's there :) [02:33] slangasek, was you aware that yesterdays sqlite upload broke ABI? [02:34] sqlite3_unlock_notify has gone [02:34] chrisccoulson: the 3.7.4-2ubuntu1 upload? [02:34] slangasek, yeah, i just updated it now [02:34] chrisccoulson: updated as in uploaded? [02:35] slangasek, sorry, i meant i just updated to the version you uploaded yesterday [02:35] ah [02:35] 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] it wasn't yesterday, though, it was only 2 hours ago [02:35] so i just checked it locally too [02:36] oh, yeah. it was yesterday my time ;) [02:36] * chrisccoulson should get some sleep [02:36] heh :) [02:37] ok, looking to see what's going on here, because nothing in that should've been an ABI-changer [02:37] thanks [02:43] I wonder if this is a cdbs behavior change [02:44] the bits that went missing are controlled by a define passed in DEB_OPT_FLAG [02:46] 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] slangasek, oh, DEB_OPT_FLAGS doesn't seem to be used anywhere by cdbs :/ [02:49] * Deprecate DEB_OPT_FLAG (if ever used it should be done differently). [02:49] cdbs 0.4.90 [02:50] works fine with previous cdbs, yay === asac_ is now known as asac [03:02] chrisccoulson: thanks for letting me know; fixed sqlite3 uploaded [03:02] slangasek, excellent, thanks for fixing it quickly too :) [03:46] 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] bug 712898 just filed for removing a group of packages with todays natty updates [04:02] Launchpad bug 712898 in update-manager "Updates removed many applications" [Undecided,New] https://launchpad.net/bugs/712898 [04:03] seems to have taken over 20 applications [04:05] 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] If they all complain about python-gtk2, it's probably a problem with python-gtk2 [04:06] how about python-gtk2 [04:06] I just went by the debugging page for updates [04:07] last update was weeks ago [04:08] it's not neccessarily python-gtk2, but it is python related [04:08] 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] I suspect there's some library that had an incomplete transition, and some conflicts that cannot be resolved currently. [04:15] charlie-tca / persia : I _thought_ it was related to python-gobject (saw it too an hour ago or so) [04:15] Could well be [04:15] * persia is trying to sort out git trees, and hasn't looked into this at all [04:15] ah, in that case, I think there might be a bug already [04:16] bug 712734 [04:16] Launchpad bug 712734 in pygobject (Ubuntu) "Natty-alfa2 pygobject has incorrect dependencies" [Undecided,Confirmed] https://launchpad.net/bugs/712734 [04:17] err, maybe not [04:17] nope [04:17] that is just something with python2.6 installing [04:18] I hope it was okay to post that here. Normally I will not do that, but the weekend is coming fast... [04:21] -bugs would have gotten a similar response, I think :) [04:25] I get an even weirder error on apt-get upgrade: abrowser : Depends: abrowser-branding (= 4.0~b10+build1+nobinonly-0ubuntu2) [04:26] kklimonda: that's not so weird [04:27] micahg: I don't really remember installing it [04:28] kklimonda: if firefox was removed like charlie-tca had, it might have tried to install abrowser to fix deps [04:28] micahg: ah.. that makes sense [04:29] 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] charlie-tca: there is still a whole day to fix it :) [04:30] yup [04:30] it does seem to be related to bug 712734 [04:30] Launchpad bug 712734 in pygobject (Ubuntu) "Natty-alfa2 pygobject has incorrect dependencies" [Undecided,Confirmed] https://launchpad.net/bugs/712734 [04:30] just as micahg was saying [04:30] but I got another person in #ubuntu+1 with the same thing already [04:35] 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] jono, i sent you an email about acire. will it be included in natty? [04:39] wildfire, You might ask the team in #launchpad [04:50] 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] Ok, python-gtk2 depends on python2.6-gobject, which doesn't exist. [04:56] So I and there might be more packages in the same position. [07:57] good morning [08:01] Good morning [08:01] * bryceh waves [08:05] pitti: a few people were running into bug 712734 last night [08:05] Launchpad bug 712734 in pygobject (Ubuntu) "Natty-alfa2 pygobject has incorrect dependencies" [Undecided,Confirmed] https://launchpad.net/bugs/712734 [08:05] just saw it [08:05] pitti: have a good day :) [08:06] seems this kind of forces us to bring back python2.6 on the CDs, unless we drop 2.6 support completely [08:06] pitti: discussion on ubuntu-devel about dropping it completely [08:08] I'll re-add py26 support for now to fix the archive, and then investigate more closely === tkamppeter_ is now known as tkamppeter [08:09] 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] persia: not with the way we currently package python apps [08:10] python-foo has the extensions for all supported versions [08:10] Oh, right. [08:10] and recently pygobject just started to use functions from libpython [08:10] there isn't much that I can do about it [08:10] I'll check it more closely later on, but I suppose it's necessary [08:11] 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] yeah, an early version of the python policy involved doing that [08:12] persia: rebuilds for all pacakges are still required, but it avoids tons of binary NEWing/removing old packages [08:13] Right. [08:14] hi everyone...i'm interested in kernel programming...can anyone guide as to where should i start [08:19] good morning === smb` is now known as smb [08:47] 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] rigved, http://lwn.net/Kernel/LDD3/ [08:48] 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] old-releases? [09:20] http://old-releases.ubuntu.com/releases/ [09:21] <\sh> persia: Tm_T: yepp found it [09:21] goodie [09:22] <\sh> grmpf..debugging regressions is time consuming [09:22] 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] we do [09:25] http://old-releases.ubuntu.com/ubuntu/ [09:25] <\sh> very good [09:41] persia: I think Kees' CD collection is pretty complete, if you actually need it. [10:06] 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. === hunger_ is now known as hunger [10:43] persia: Oh, ok :( [10:43] :), I mean. [10:43] Darned keymap. === _LibertyZero is now known as LibertyZero === MacSlow is now known as MacSlow|lunch [11:37] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: chrisccoulson [12:04] 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] Launchpad bug 712859 in libv8 (Ubuntu) "Sync libv8 2.5.9.9-2 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/712859 [12:04] cjwatson, I'll look [12:05] thanks [12:08] chrisccoulson: ping [12:08] hi c2tarun [12:08] hi chrisccoulson [12:08] you looking at that bug? [12:09] c2tarun, yeah [12:09] chrisccoulson: thanks :) i am right here, just tell me about any error, i'll try to remove it. [12:09] thanks [12:24] 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] janimo: ok [12:27] thanks === oubiwann_ is now known as oubiwann [12:43] 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] 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] and the changes aren't in the upstream source [12:44] it looks like you deleted the original patch whilst it was applied, thinking that the changes existed in the upstream source ;) === diwic is now known as diwic_afk [13:12] 3.0 (quilt) yay! [13:15] I actually find it more disturbing that they are applied by default, in the lp:ubuntu/pkg branches [13:17] 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] well, but having that in bzr completely breaks e. g. merge-upstream [13:17] you need to unapply before m-u, but then you can't do m-u because you have uncommitted changes [13:17] I think it makes sense for bigger more complex packages, but less so for simple ones [13:17] so you need to unapply, commit, m-u, update patches, re-apply, commit again [13:18] 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] chrisccoulson: ping [13:18] hi c2tarun [13:18] pitti: you ought to be able to use m-u --force [13:19] if that doesn't work, I'd say it's a bug in m-u; it works with plain merge [13:19] 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] --force Merge even if the destination tree has uncommitted [13:19] changes. [13:19] 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] 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] 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] persia: well, in the end it is [13:20] 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] persia: conceptually it's really wrong to have debian/patches/* files when everything else is in revision control [13:20] chrisccoulson: can I PM you ? [13:20] persia: i. e. what we really need is loom, or "pipelines" as they seem to be called today [13:20] ricotz: no, it's not going to work, libquvi is in universe and totem-pl-parser is in main. needs an MIR [13:20] pitti, Well, if one is going to use bzr for everything, one ought put things in 3.0 (bzr). [13:20] c2tarun, sure [13:20] persia: I wrote 3.0 (bzr) and even I don't really advocate it :) [13:21] it was an experiment, mostly for parity with 3.0 (git) [13:21] cjwatson: i. e. unapply, mu, and rebase patches all in one commit? I guess that's what it comes down to then [13:21] cjwatson, ok, i see [13:21] 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] sure, I wrote it eons ago :) [13:21] cjwatson: (and then hoping that you don't screw up while rebasing the patches and have to start over :) ) [13:21] pitti: that's what I do, albeit with merge [13:22] I agree it could use better tooling [13:22] 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] 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] also shallow history would make a big difference to how sane it is === MacSlow|lunch is now known as MacSlow [13:44] lifeless: pong [13:52] chrisccoulson: around? [13:52] ari-tczew, yes [13:53] chrisccoulson: could you upload this one? bug 708401 [13:53] Launchpad bug 708401 in gedit (Ubuntu) "Merge gedit 2.30.4-2 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/708401 [13:53] ari-tczew, in a bit, i'm looking at something else right now [13:53] chrisccoulson: Understood. === oubiwann is now known as oubiwann_ [13:59] 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? === oubiwann is now known as oubiwann_ [14:02] hallyn: it'd be easier if we could see literal error messages [14:02] I don't believe that it means 'apt-get update -f'. Perhaps 'apt-get dist-upgrade -f' [14:03] done that, bunch of times. i'll pb [14:06] 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] https://pastebin.canonical.com/42878/ [14:07] I suspect those drivers need to be rebuilt against the current server ABI [14:07] they probably didn't get picked up by the mega rebuild we did earlier, since they've been demoted to universe [14:07] hm, no, that isn't so [14:08] RAOF: might be worth going through 'grep-aptavail -FDepends xorg-video-abi-8.0' for more stuff to rebuild? [14:08] not sure that's hallyn's problem though. [14:09] hallyn: so what does 'apt-get -f install' say? [14:09] (no other args) [14:16] 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] pitti: any idea what could cause bug #713115? I don't know where to start looking... [14:19] Launchpad bug 713115 in virt-manager (Ubuntu) "[natty] virt-manager no longer starts with recent updates" [Undecided,New] https://launchpad.net/bugs/713115 [14:20] pitti: something changed with the recent pygobject [14:20] looking [14:21] mdeslaur: doesn't ring a bell right now, I'll try to reproduce [14:22] mdeslaur: does this happen right at program start? [14:22] pitti: yes [14:22] pitti: launch virt-manager with --debug [14:22] ah, can reproduce [14:23] mdeslaur: still busy with something else, but I'll have a look later on then [14:23] pitti: thanks a bunch :) [14:28] 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] 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] hallyn: *nod* [14:34] sconklin-gone: for maverick, lucid, or both? === sconklin-gone is now known as sconklin [14:34] sconklin-gone: I think wrt. lucid -proposed is by and large unfrozen again, just not -updates [14:35] pitti: for both please [14:36] 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] eh, found a workaround that doesn't involve patching automake or vala, but is a bit nasty. :-/ [14:36] nevermind then [14:36] pitti: tgardner prepped those, I don't know [14:37] sconklin: ok, I'll check then [14:37] sorry [14:37] * jdstrand finds it curious that he has a defunct metacity process when he is using compiz... [14:37] pitti: if lucid -proposed is unfrozen, then those packages from our ppa can go as well [14:38] beware that there is one higher version of a meta package sitting in there I think [14:38] 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] pitti: ack [14:45] chrisccoulson: when you have done gedit would be nice to have a look on bug 420387 as well === dholbach__ is now known as dholbcah [14:45] Launchpad bug 420387 in bittornado (Ubuntu) "[PATCH] DeprecationWarning: the sha module is deprecated; use the hashlib module instead" [Undecided,Confirmed] https://launchpad.net/bugs/420387 === dholbcah is now known as dholbach [14:50] 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] sconklin: does *-meta take the ABI from the version number in debian/changelog? [14:51] 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] sconklin: ah, so it does parse the changelog [14:53] linux-meta-mvl-dove (2.6.32.414.4) [14:53] yes [14:53] sconklin: i. e. it strips off the .4, and turns that into 2.6.32-414? [14:53] sconklin: ah, thanks; I was always wondering whether I need to wait with accepting -meta until the actual kernel has built [14:53] pitti: I assume so based on the fact that the only place we change a version is in the changelog [14:53] that would have brought a lot of speedup for the old-style "accept from -proposed" workflow [14:54] The worry is that if there is a publisher run, the -meta update is uninstallable until the kernel binaries are published. [14:54] I have never had to dig into the meta package makefiles, so I'm not very familiar with them [14:57] sconklin: hm, the current -29.57 upload changelog refers to bug 705565 [14:57] Launchpad bug 705565 in linux (Ubuntu) "linux: 2.6.32-28.56 -proposed tracker" [Undecided,Incomplete] https://launchpad.net/bugs/705565 [14:57] that's a bit confusing [14:57] looking [14:57] ah, it's built with -v and two changelogs [14:57] so it's kind of obsolete [14:58] bug updated === herton is now known as herton_lunch [15:02] sconklin: I think Jeremy should update his overzealous "please confirm with upstream kernel" auto bug replies to not cover trackign bugs :) [15:02] pitti: we've discussed this, and a change is coming soon ;-) [15:03] sconklin: mvl-dove uses the same tracking bug 712610 for lucid and maverick; was that intended? [15:04] Launchpad bug 712610 in linux-mvl-dove (Ubuntu Maverick) "linux-mvl-dove:2.6.32-214.30 -proposed tracker" [Undecided,Fix committed] https://launchpad.net/bugs/712610 [15:05] 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] *nod* [15:05] thanks for noticing. It will probably break our status display === kshadeslayer is now known as shadeslayer [15:09] sconklin: I think I caught everything now; please let me know if something is still missing in 2 hours [15:09] pitti: thanks! [15:09] sconklin: (your status display complains then?) [15:10] 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] sconklin: ah, you don't have something that shows newer packages in your PPA? [15:11] that should ideally be empty now [15:11] pitti: I've been writing that tool yesterday and today [15:11] actually, now that you use launchpadlib this should already be updated, as lplib doesn't depend on the publisher [15:12] we're not using lplib yet - I've been putting all that new functionality into our tools module base classes [15:12] https://kernel-tools.canonical.com/srus.html [15:13] There's the display, but it still doesn't show lucid because the cron jobs haven't run yet. [15:13] and I think that it currently does not show arm anyway - that's another thing on my list === zyga is now known as zyga-food [15:39] 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] Launchpad bug 713115 in pygobject (Ubuntu Natty) "[natty] virt-manager no longer starts with recent updates" [High,In progress] https://launchpad.net/bugs/713115 [15:39] Bug 713135 on http://launchpad.net/bugs/713135 is private [15:39] meh [15:39] jdstrand: yep, currenlty debugging 713115 [15:39] jdstrand: feel free to make 35 a dupe of 15 [15:40] pitti: ok, I unprivated bug #713135 [15:40] Launchpad bug 713135 in hamster-applet (Ubuntu) "hamster-applet crashed with OperationalError in execute(): no such module: fts3" [Undecided,New] https://launchpad.net/bugs/713135 [15:40] pitti: ack [15:40] ah, so that one isn't virt-manager [15:40] pitti: no. virt-manager, hamster and meld I know are affected, with downgrading fixing it [15:41] OperationalError: no such module: fts3 [15:41] * jdstrand nods [15:41] that doesn't look at all like the segfault that virtmanager gets, though? [15:41] no, it doesn't, but again, if I downgrade it works [15:42] pitti: meld has yet a different error [15:42] ah, bisected the fix for virt-manager [15:42] meh, I was afraid of that [15:42] it fixed reference leaks [15:42] but that uncovered tons of bugs in GTK [15:42] so if I revert the reference leak fix, it'll probably work again, but we'll keep the mem leaks forever [15:43] the hamster line in question is: self.execute("""CREATE VIRTUAL TABLE fact_index USING fts3(id, name, category, description, tag)""") [15:43] I see [15:43] so, I'll file the meld one then too [15:43] 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] and undupe the hamster one [15:45] jdstrand: hm, does the applet work for you if you just start it with [15:45] /usr/lib/hamster-applet/hamster-applet [15:45] ? [15:45] it doesn't crash here (with the downgraded pygobject) [15:45] but doesn't do anything eiterh [15:45] pitti, well applet you need to run on the command line and then add to gnome-panel in the ui [15:45] it will use the running instance [15:45] ah [15:46] pitti: maybe try hamster-time-tracker [15:46] that will launch a non-panelized hamster [15:46] crashes with a dbus error [15:46] dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name :1.534 was not provided by any .service files [15:47] maybe that worked here because the panel applet was already running [15:48] I see in the desktop file: /usr/lib/hamster-applet/hamster-applet -s over [15:48] searching for "hamster" in the applet list doesn't bring up anything [15:48] jdstrand: already tried that [15:48] I'm under standard gnome now [15:48] pitti: I think it is Time Tracker [15:48] pitti, try to send a sigHUP to gnome-panel or restart it [15:48] or maybe what jdstrand said rather [15:49] pitti: yes, that's it [15:49] * pitti tries restarting panel [15:49] ah, that helped [15:49] except that it's still crashing :/ [15:50] pitti: I needed to restart my session after downgrading to have hamster work [15:50] aah - /var/crash/_usr_bin_hamster-service.1000.crash [15:50] OperationalError: duplicate column name: search_name [15:50] presumably because there is hamster-service and hamster-applet that are running, and I only managed to restart one of them [15:51] did that actually ever work? [15:51] pitti: I use it every day. it is an integral piece of my daily work flow [15:51] 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] $ /usr/bin/hamster-service [15:51] sqlite3.OperationalError: no such module: fts3 [15:51] ah, I think I get closer now [15:52] jdstrand: I think what you saw just bounced the backend exceptino back to the client through dbus [15:53] k [15:53] jdstrand: but it doesn't work with the old pygobject eitehr [15:53] pitti: well, I downgraded, restarted my session, and I am using it as we speak [15:53] pitti: I promise I am not lying :) [15:54] of course not, just trying to reproduce [15:54] * jdstrand was just kidding === herton_lunch is now known as herton [15:54] pitti: these are what I downgraded- python-gobject python-gobject-cairo python-gobject-dev [15:55] and with the exception of bzrtools (unrelated- just floated in), I am fully up to date [15:55] ah, perhaps cairo, too [15:57] Anyone know if *.tar.xz tarballs are accepted in the archives? [15:57] jdstrand: bug updated with a question for you (let's keep it there to have a better debug record) [15:57] jdstrand: I'll check virt-manager in the meantime; can you please sub me to the meld bug? [15:58]