[00:30] hi espen77 [00:30] hi :) [00:31] is there a command to make a diff between .orig.tar.gz and unpacked directory? [00:31] so, you can create a new source build and debdiff the two, to create a new source build, you add a changelog entry (dch -i), and then create a source build (debuild -S) [00:31] espen77: the sponsorship page I linked you to should I have a guide to debdiffing [00:32] *have a link to a guide [00:33] micahg: atleast google have [00:34] espen77: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff#Creating%20A%20Debdiff [00:35] yeah, reading [00:50] hi all.. i'm not really sure if this is the right place to ask, but i'll attempt anyway: is there a package for the openCV library ? [00:51] https://launchpad.net/ubuntu/maverick/+source/opencv/2.1.0-2 <-- I found this. but its for a source package? and searching maverick repos there is a python-opencv and opencv-doc package. [00:51] freakabcd: yeah :) [00:51] freakabcd: I was using it the other day [00:52] freakabcd: I can't reacall what it's called. I filed a bug with it up in debian. Let me look it up [00:52] i'm trying hard to understand how the python-opencv package that provides py bindings to the lib) is supposed to without being able to install the library itself! [00:52] oh you found it === broder_ is now known as broder [00:53] why does the package python-opencv exist? it seems to happily install itself without any dependencies, etc! [00:53] freakabcd: the big ones: http://pastebin.com/u80TYmXM [00:53] freakabcd: it sure does [00:53] freakabcd: test it :) [00:53] ewww.. why is it libcv instead of libopencv ? [00:54] freakabcd: I have some example python-cv code on my blog: http://blog.pault.ag/post/1980116944/python-opencv [00:55] beware that haarcascades issue I ran into [00:56] paultag: err.. on that page you linked, there is no src code! [00:56] or is it because noscript blocked it for me? [00:57] freakabcd: yeah, let me get you the gist :) [00:57] freakabcd: https://gist.github.com/603819 [01:00] lol indeed.. those should not be in the doc package [01:01] so what exactly is lookatme.py doing? simply tracking the head? [01:01] or heads [01:01] freakabcd: right. I was just goofing around. Eventually I might use that for a display in my wall or something, turn on when you face it. [01:01] freakabcd: Who knows, mirite? [01:02] heh, but it immediately terminates on trying to run here :( terminate called after throwing an instance of 'int' \n Aborted [01:02] i will ask in #opencv [01:02] freakabcd: sounds like you're missing the haarcascade stuff [01:02] but i have installed opencv-doc [01:02] freakabcd: check to make sure it exists. I had to take the files out of the sourceball and place it in the tree [01:03] oh, you mean its gone to the wrong dir [01:03] freakabcd: yeah, there was something dumb as hell about that package [01:05] paultag: whats in /usr/share/opencv ? [01:05] the haarcascades dir? [01:05] for me thereis nothing in that dir except for a cmake file lol [01:05] freakabcd: yeah, I think I had that issue too [01:05] freakabcd: just copy in files where they should be from the source [01:06] paultag: also do i need to gunzip the xml.gz files or can is work with the zipped ones? [01:06] freakabcd: I think they need to be "real" xml [01:07] paultag: did you happen to remove your installation or are you on a different machine now? easiest is to check /usr/share/opencv on your system [01:08] freakabcd: I'm on a different machine -- I'm ssh'd in from work [01:08] freakabcd: sorry :) -- I put a link in that bug report as to where that stuff should be [01:08] so i can know the right path: i.e. /usr/share/opencv/haarcascades/*.xml or /usr/share/opencv/haarcascades/haarcascades/*.xml [01:08] freakabcd: ah, sec [01:08] yeah, but the non-unified diff hurts my eyes :D [01:08] /usr/share/opencv/haarcascades/*.xml <-- freakabcd [01:09] thanks [01:09] freakabcd: righto [01:10] right i wanted to do eye tracking and even lookatme.py seems not stable enough [01:11] i wanted to finally have pointer follow eye on my laptop [01:11] freakabcd: ah, haha. Good luck :) [01:11] did you manage to do something like this? i see there are some software that allegedly do this [01:12] freakabcd: you need a high framerate camera mounted close to the eye, so it can see your eye move, not where you eye is in relation to the screen [01:12] or a high framerate, high quality camera that extracts where your eye is and uses that, but that seems hugely complex [01:12] grrr.. and i thought one could do this sort of tracking with cheapass webcams [01:13] :P [01:13] anywho, I think we're a bit off topic :) -- freakabcd if you need any more help, the kind folks in #opencv, or I might be able to help (but I've not touched it in a while) [01:13] slangasek, ping. Remember the powernowd package you said I should get removed from the archive before invalidating its bugs? well.. it's been removed ;) [01:13] yeah, thanks. but someone needs to rename that package to be libopencv instead of libcv [01:14] psusi: ok, great :) [01:14] freakabcd: why? [01:14] slangasek, so now good to clear out the bugs? I've been looking for a better way to do it this time... just tried using bughugger, but it apparently can't find the package now that it's been dropped [01:14] freakabcd: we don't have un-open software in Debian main ;) [01:14] psusi: sure, by all means close them out now [01:14] because everywhere it says opencv all websites were saying opencv [01:15] slangasek, got any advice for how to do that batch style? [01:15] freakabcd: file a bug :) [01:15] and now if i had installed python-opencv, it installed without any deps [01:15] last time I just did each one on the lp web site by hand.... [01:15] psusi: lplib not working for ya? ;) [01:16] paultag, wassat? [01:16] psusi: launchpadlib -- you know the python bindings to launchpad so you can batch operations (like, say, closing out a list of bugs) [01:16] I was thinking of just using the email interface but that would still require me typing in each of the bug numbers ;) [01:16] paultag, you mean roll my own python using the lib? I have been learning python.... hrm... [01:17] psusi: go for it, dude. Are you trying to close out all the bugs against a package or something? [01:17] paultag, yea [01:17] psusi: yeah, just use lplib to get a list of bugs, then change status to fix-released or invalid or whatever. Just be sure not to close valid bugs [01:18] hrm.... [01:18] (tags might have done you some good) [01:18] well, they are all getting closed since the package has been dropped [01:18] psusi: lp should take care of that, yes? [01:19] hrm.. I can't find lplib... [01:19] paultag, doesn't look like it [01:19] psusi: python-launchpadlib [01:44] I can not figure this api out... lp.bugs[id] seems to get me a bug by id number, but I can't manage to search for distribution/package bugs [01:48] psusi: feel free to jack code from: http://launchpad.net/locolint [01:48] psusi: there's code in there that does some of what you need to do [01:49] psusi: http://bazaar.launchpad.net/~ubuntu-lococouncil/locolint/trunk/view/head:/locolint/functions/pending-apps.py <-- that has the bug listing against a project [01:49] Ampelbein: alrighty; thanks, I'll ask one more place and go to the mailing lists. [01:53] why does launchpad.projects['powernowd'] not get me the powernowd project? [01:54] psusi: https://launchpad.net/powernowd <-- because there's nothing with that name [01:54] psusi: you'll be using ubuntu, then loading bugs against that package [01:54] last I checked, anywho. I'm not handy with lplib [01:54] psusi: if you need more help, #launchpad might be the right place [01:56] psusi: ubuntu dev tools might help too [02:03] slangasek, should they be invalid, or wontfix do you think? [02:11] psusi: if you want all bugs from a package, try something like lp.distributions['ubuntu'].getSourcePackage['name'].getBugTasks [02:38] psusi: I'd say 'invalid' [03:19] Can anyone please help me with this error http://paste.ubuntu.com/574265/ [03:21] c2tarun: looks like you are missing a build-dep [03:22] Ampelbein: Can you please tell what is missing and how you figured it out? something related to Qt4 is missing but I am not able to get what to add in build-Depends [03:24] c2tarun: it complains about 'Qt qmake not found!' and the module is called (see line 5) findQt4 [03:24] c2tarun: so you make 'apt-cache search qt4 qmake' [03:24] c2tarun: that would be my guess at least [03:25] Ampelbein: on searching I got qt4-make is it this one? [03:25] c2tarun: I guess it is. [03:25] Ampelbein: thanks :) [03:40] Ampelbein: problem is still there. :( I installed qt4-qmake and added it to build-depends as well, again I am getting the same error. I checked manually file FindQt4.cmake is in the location required. its the message thrown by that file. its looking for something which is no found :( [03:40] c2tarun: then I don't know :-( [03:44] Ampelbein: I'm still hoping to get a reply from the mailing list; because I'm utterly lost [03:45] MTecknology: I can understand that. I don't see a reason why it doesn't work, dpkg-maintscript-helper is there for exactly that case :-( [03:45] Ampelbein: yup; and in your first try it actually worked; somehow [03:46] I'm baffled [03:46] MTecknology: I think that was because I did multiple tries without going back to a "clear" state before each try [03:47] oh [03:47] so then the answer should probably be very very simple [04:36] is there any reason to use 3.0 source format for a new package, that has no patches yet? [04:36] artfwo: no sense in using something old, since if you don't have source/format, lintian will whine [04:36] artfwo: so why put anything besides it in there ;) [04:37] hmm, lintian had not warned me about it (on a maverick machine) [04:38] artfwo: -IE --pedantic ? [04:38] paultag: missing source/format is a fairly pointless whine. [04:38] I don't think it's E or W [04:38] ScottK: aye [04:38] ScottK: but it's also fixed without much work, so I hate seeing it :) [04:38] I hate wasting time on pointless things. [04:38] To each his own. [04:40] well, there might be a reason, besides the lintian whine (paultag, it showed up with -IE) [04:40] artfwo: not really, narp. [04:40] in this case, it can save oneself from accidental modifications to the build as debuild will say if there were changes to the orig files [04:40] artfwo: unless you need multi .tar.gz, then you need 3.0 :) [04:40] oh, okay [04:40] thanks for the explanation [04:41] paultag: since you mentioned multi tar.gz I have another question :) [04:42] artfwo: yis. forewarning, I'm not MOTU. Just a casual hacker up in debian. [04:42] I'm going to package a soundscape tool, called boodler (straight to debian, likely), and it has lots of tiny soundscape packages [04:43] artfwo: sure [04:43] they're all distributed in separate files [04:43] artfwo: it might be a pita to upload all those .tar.gz files, esp if one updates independent of the main package, you won't be able to upload it if it's part of the "master" source package [04:43] does it make sense to use multi tar.gz here, or is it better to pack them all in a handcreated .orig.tar.gz? [04:44] artfwo: might be worth packaging each on their own [04:44] but I don't know [04:44] I'd ask a DD [04:44] there will be 54 packages then :) [04:44] oh jesus [04:44] might just need a -plugins package or something [04:45] I was thinking about -plugins package, but what approach to choose? [04:45] artfwo: I don't know. I'd ask your friendly DD [04:45] okay :) [04:45] :) [05:05] question: what is the general opinion about bugs like bug 572091? How should a debian package handle errors that are out of it's direct control? [05:05] Launchpad bug 572091 in festival (Ubuntu) "package festival (not installed) failed to install/upgrade: exit status 1 - useradd: cannot lock /etc/passwd; try again later." [Medium,Confirmed] https://launchpad.net/bugs/572091 [05:07] Ampelbein: I would think fail gracefully and don't leave the system in an unusable state === tarun is now known as Guest86968 [05:08] micahg: so you think, catch the error and give the user a "please run dpkg-reconfigure $package later"? [05:10] I think better to figure out why useradd failed. [05:11] Ampelbein: idk, seems like dpkg already does that [05:13] * micahg thinks ScottK's suggestion is good [05:14] ScottK: yes, in the case of useradd it's mostly a result of a stale *.lock file [05:14] at least that's what I found on the matter [05:16] Then running dpkg-reconfigure wouldn't help, would it? === Guest86968 is now known as c2tarun [05:17] ScottK: in that case not until the root cause is removed. [05:17] So I don't think that type of warning helps much. [05:17] what I'm trying to figure out is: should these report be treated as a bug in the package or a user configuration error? [05:18] I usually treat these things as configuration errors and convert them to questions. [05:18] But that's just me. [05:18] I think convert to question is way under utilized. [05:19] ScottK: it's currently partially broken [05:19] micahg: What part of LP is not at least partially broken? [05:19] ScottK: good idea. I would have set to invalid and just put a information about how to fix in. But convert to question is good! thank you. [05:20] ScottK: heh, I meant broke such that it's unusable for packages with large numbers of subscribers [05:20] micahg: It's not unique in that regard. [05:29] can anyone please help me with this error http://paste.ubuntu.com/574265/ [05:29] ScottK: :( [05:30] convert to question specifically is a disaster [05:30] its on our hit list to fix in the short term [05:30] ScottK: Could you go a few days without sticking the knife in and twisting? [05:30] lifeless: I think you've been doing great work to make things better over there. [05:30] lifeless: I want "Convert to forum post" [05:31] StevenK: It's been quite some time since I said anything bad a LP. IIRC I even managed to refrain from comment when it was announced that U/I was going to be "imporoved" once again. [05:31] ScottK: thanks [05:31] we should have some new capacity in the next week-or-mumble [05:31] which will help [05:31] one of lps failings is success [05:32] StevenK: that could be nice [05:33] c2tarun: did you install qt4-qmake or specify it as build dependency? [05:33] artfwo: yup, both [05:34] c2tarun: you need to make sure qmake is in your PATH [05:35] since it's install to /usr/share/qt4/bin/qmake [05:35] artfwo: how can I check qmakes path? [05:35] perhaps you need to refresh your environment? (logout and login again) [05:37] artfwo: how can i check qmake is in my PATH? [05:37] if it doesn't run, it isn't [05:38] ok, than how can i include it in my path? [05:39] I think it's included by default [05:39] you just need to refresh your environment, like logging out and logging in again (read above) [05:39] I cannot guarantee it will work though, but it's worth a try [05:39] artfwo: already did that [05:40] * c2tarun I did it when you said. :( its not working [05:40] hmm [05:41] how did you remain online here then? :) [05:41] (just curiuous) [05:41] artfwo: I am building it on chroot ;) [05:41] artfwo: I exited from chroot and entered again [05:42] entering chroot does not reset your PATH, I recall [05:42] you have to run something like source /etc/profile [05:43] artfwo: actually my home is not mounted on chroot's home. chroot have a separate home, so it will reset the path [05:44] I'd still run "source /etc/profile" after entering chroot to be sure [05:45] artfwo: done :( same error. [05:46] do you have a QTDIR environment variable? [05:47] artfwo: nope, what is it? [05:47] it's where Qt is installed. cmake normally looks for qmake under PATH and QTDIR [05:48] and I thought, these variables are updated automatically after installing appropriate dev-packages [05:48] let me check [05:49] artfwo: I dont have QTDIR set. [05:53] artfwo: I looked into FindQt4.cmake file and found these lines throwing error http://paste.ubuntu.com/574298/ can it be of any help? [05:55] wow, that's an erroneous error message [05:56] it's thrown if QT4_INSTALLED_VERSION_TOO_NEW is true [05:57] are you sure, I mean i think Qt4_FIND_VERSION_EXACT and QT4_INSTALLED_VERSION_TOO_NEW both should be true. [05:58] it evaluates the entire "Qt4_FIND_VERSION_EXACT and QT4_INSTALLED_VERSION_TOO_NEW" expression [05:58] anyway, the qmake-related error message is out of sense here [05:59] artfwo: ya and with the AND in b/w both should be true then only we'll get the message [05:59] if it's not an arithmetical AND :) [05:59] artfwo: oh.. :) sorry then [06:00] what package are you trying to fix? [06:00] attica [06:06] the macports project had the same error I think, found by googling http://lists.macosforge.org/pipermail/macports-dev/2010-October/013025.html [06:08] * c2tarun looking [06:08] but their fix looks non-revelant to us, I haven't investigated [06:10] artfwo: yup, they fixed something in any Portfile [06:11] do you know what a portgroup, that might be handy here. [06:11] that's their specific build system I think [06:12] but strangely, they fix it by switching some kind of build profile [06:13] yup, somehow some kde 1.0 doesn't support qt4 :/ [06:13] perhaps an environment check will do the trick? [06:13] something like setting your PATH to include /usr/lib/qt4/bin perhaps? [06:14] does the command qmake or qmake-qt4 run in your chroot? [06:15] yup [06:15] artfwo: http://paste.ubuntu.com/574306/ [06:16] right [06:17] I cannot help you any further then, let's hope someone does :) [06:18] ok, one last help please. /usr/lib* is not declared in my PATH var, can you please tell me how to set that [06:19] this all doesn't sound right [06:19] which package is this? [06:19] attica [06:26] c2tarun: you might want to ask in #kubuntu-devel if there are any tricks [06:26] micahg: I asked there :) geeks might be sleeping right now ;) [06:27] * micahg would hope there would be a cleaner way than setting LD_LIBRARY_PATH [06:29] micahg: I tried on two different packages and got the same, may I'll wake for kubuntu-ninjas to wake up :) anyway, thanks for looking [06:29] c2tarun: did you check the Debian svn repo to see if any fixes have been committed? [06:30] * c2tarun checking [06:31] well I looked into rmadison and debian is a version behind the version I am working on [06:31] micahg: and there are not bug reports for this package :( [06:31] c2tarun: yes, but a new version can be in the repo unreleased [06:32] micahg: how to look into repo? [06:32] there should be a link on packages.qa,debian.org/attica [06:35] micahg: hey I think there is a patch, let me try [06:36] c2tarun: make sure to give proper attribution to the patch author and source (DEP-3) [06:37] micahg: umm.... I am familiar with DEP-3 but what do you mean by proper attribution? [06:38] c2tarun: author and other headers [06:38] !dep3 > c2tarun [06:38] ah, you're familiar, sorry [06:39] micahg: ok, I'll take care of dep3 headers :) and I'll show it here before any further steps, thank you [06:42] micahg: that patch is already applied :( [07:44] good morning === fabo_ is now known as fabo [08:37] I'd like to split a cdbs package in two by putting, say, hello-first.install and hello-dev.install in debian [08:38] hello-first.install contains a wildcard, like usr/bin/* [08:38] hello-dev.install contains usr/bin/devscript [08:38] devscript actually installs to both packages [08:39] is there an elegant solution to this problem? [09:13] if i had a job paying more than $10/hr i would spend the money to hire another person to work on ubuntu [09:18] k0p: if i had a job paying more than $10/hr i would spend 1/2 the money to hire another person to work on ubuntu [09:18] How come? [09:19] what do you know? [09:19] master-debator [09:19] ? === HPV is now known as seidos [09:45] compassion -> buddha [09:45] 1 xor 0? [09:45] 1 === aalex is now known as aalex-home === andreserl is now known as RoAkSoAx_ === RoAkSoAx is now known as andreserl === RoAkSoAx_ is now known as RoAkSoAx [14:44] tumbleweed: on branch https://code.launchpad.net/~stefanor/ubuntu/lucid/samba/ntlm-auth-623342/+merge/51560 in d/p/series is blank line before your patch, is it correct? [14:45] wow the sponsering queue is short! patch pilots ftw [14:46] ari-tczew: aah. I don't think blank lines matter, but I don't know why that blank line is there (I didn't add it) [14:46] yes, regards to pitti [14:46] tumbleweed: would be nice to keep short url, so Bug-Ubuntu: https://launchpad.net/bugs/623342 [14:46] Ubuntu bug 623342 in samba (Ubuntu Maverick) "ntlm_auth returns invalid NT_KEY" [Low,In progress] [14:47] tumbleweed: does it really needed to have a link to bug in d/changelog entry if patch has got DEP3 headers? [14:47] ari-tczew: yeah I normally shorten URLs, doesn't matter, though [14:49] ari-tczew: that's how previous samba uploads had their changlog entries written. I didn't want to chagne the style [14:54] tumbleweed: ok gotcha. nice work! [14:54] bdrung: could you take tumbleweed's patches to sponsorship? then we could get less sponsors overview today [15:08] ari-tczew: which patches? [15:08] bdrung: samba SRUs [15:26] bdrung: I didn't spend any time actually understanding those patches (although they are quite small). Just grabbed from the samba bugtracker, and got our sysadmin to test my lucid proposed backage. [15:33] dholbach: Is it okay to throw in daily builds of KDE as part of Project Lightning Talks? [15:33] Quintasan, sure - that'd be great [15:33] awesome [15:36] https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 3 starting in 25 minutes in #ubuntu-classroom [15:38] ready to go! [15:49] I'm working on the bug 639955 which describes two different error in two different packages (both are related to nvidia pkg) [15:49] Launchpad bug 639955 in Package Descriptions for Ubuntu "Typo in package description: Geforce should be GeForce" [Low,Triaged] https://launchpad.net/bugs/639955 [15:49] Fixing the first error (in one of the pkg) editing the debian/changelog should I use the bug number (LP ...) [15:50] ? [16:01] acarpine: what's the question? [16:02] Hi all, I am having a few issues with dependencies in my PPA, I am building packages for a cross compiler and binutils built successfully when I try to build gcc that depends on binutils I get Missing build dependencies: msp430-binutils (>= 2.21) but that exists in my ppa? any ideas? the binutils packages is called msp430-binutils - 2.21~git20110302r20110213-0ubuntu1~msp231~maverick [16:18] ari-tczew: ops I saw only now because i'm in #..classroom [16:18] the question: is it correct put the LP XXX voice in the changelog file also if my patch fix only one of the two errors? [16:18] acarpine: it depends, in general every error = another bug [16:19] if you mean two typos, please fix it in one place [16:19] ari-tczew: also if they are in two diff pkgs? [16:20] acarpine: then open task on two pkgs [16:20] acarpine: however, I think it should be fixed debian/upstream [16:20] upstream* [16:20] typos are not important, if it doesn't cause FTBFS or something [16:23] arii-tczew: So what do you think I should do? [16:24] arii-tczew: I know the typos are not important, but is useful for me to understand the process of packaging... [16:25] arii-tczew: that's why i'm choosing only easy bugs... [16:30] should quilt patches be applied, or not in the bzr branch? [16:30] seems to me like they should not be... [16:30] psusi: UDD branch? [16:30] tumbleweed: yea [16:31] if the package uses sourec format 3.0 (quilt), the importer will import with patches applied [16:31] hrm... why? [16:31] if the package uses quilt in rules, the importer will import with patches unapplied [16:31] wait... what? [16:31] because dpkg-source -x applies patches [16:32] right... so they will be applied when you build a package from the branch, so why should they already be applied in the branch? [16:32] seems like that just complicates merging and reviewing changes [16:32] the importer takes uploads that aren't present in a branch, and adds them as new commits [16:32] that's how the UDD branches stay up to date [16:32] right... and when it does so, it applies the packages in the process? [16:33] s/packages/patches [16:33] yeah I'd personally prefer unapplied patches, but people who work on big packages seem to like patches applied, as it helps them to see the patched history [16:33] it makes it harder to see the history since you have changes to the patch file, and to the rest of the sources [16:34] psusi: dpkg-source -x will apply patches for source format 3.0 (quilt) packages. That's part of the specification [16:34] (although you can tell it not to) [16:34] and now you have to sort out what source change corresponds to what patch [16:34] tumbleweed: and the auto importer uses that, and so as a result, auto imports with the patches applied? [16:34] yeah, as I said, I don't like applied patches. but they are a fact of life for most UDD branches [16:35] psusi: yes, so you should stick to the same standard already in the branch [16:35] hrm... yea, I find them annoying and so am trying to figure out why they seem to be there, and whether I should add new patches applied or not [16:35] they also enlarge the branch by adding duplicate files under .pc/ [16:36] yup. Although only .pc/applied-patches needs to be in the branch [16:36] which you have to remember to bzr add when you add a new patch [16:36] ohh.. hrm... [16:36] well, you have to do that, whenever you use any VCS [16:37] no... you have to bzr add debian/patches/foo only if you don't apply it... if you want it applied in the branch, then you also have to add the stuff that gets shoved into .pc/ when it's applied [16:38] IIRC you only need .pc/applied-patches [16:38] hrm... === andreserl is now known as RoAkSoAx === ogra is now known as Guest42737 === Guest42737 is now known as ogra_ === debfx_ is now known as debfx [20:16] tumbleweed: can you incorporate the security update in your samba SRU fix branches? [20:17] bdrung: oh, whoops, sure [20:24] tumbleweed: debdiffs would be a bonus (smaller downloads for me) === neversfelde_ is now known as neversfelde [20:52] bdrung: debdiffs posted. That security update made the bzr merge proposals hard to read, anyway. === medberry is now known as Guest57670 [21:42] bdrung: thanks [21:42] tumbleweed: the multicolumn footer on http://reports.qa.ubuntu.com/reports/sponsoring/ has a bug: "More sponsoring stats" is in the "Package Sets" column [21:42] tumbleweed: yw [21:43] bdrung: aah, that should be easy [21:44] * tumbleweed likse style changes that don't involve a 10 minute test-turnaround [21:56] tumbleweed: the sponsor-overview needs only 4m22.899s for the short list [21:56] heh [21:57] tumbleweed: i am interested how long it takes for an empty queue [21:58] there are almost certainly optimisation-possibilities in it [22:01] what do you think about remove package from universe which has been removed from Debian as well? [22:01] tumbleweed: thanks for fixing sponsoring.css. can you poke dholbach to pull it? [22:01] !package xsmbrowser [22:01] ari-tczew: that's almost always a good idea. [22:01] but the archive admins should do it themselves, most of the time [22:01] tumbleweed: ok, will file a bug. [22:01] (i.e. if there isn't a build-failure / urgent issue, don't worry) [22:02] ari-tczew: check the removal reason in debian. [22:02] in most cases it's a good idea, but in some cases not (e.g. package still works and has a few user) [22:03] bdrung: sure [22:03] barry: re bug #727988 - -dev packages shouldn't contain .la files any more. [22:03] Launchpad bug 727988 in gpgme1.0 (Ubuntu) "/usr/lib/libgpgme.la has broken dependency_libs entry" [Undecided,New] https://launchpad.net/bugs/727988 [22:07] bdrung: RM: xsmbrowser -- RoQA; dead upstream, orphaned, better alternatives [22:08] ari-tczew: The package will have to be supported in Lucid longer than Natty, so there's no rush. There is a semi-automatic process for Ubuntu following Debian removals. My recommendation would be just to let that handle these kinds of things. [22:10] ScottK: so don't tuch? [22:10] touch * [22:10] * micahg hadn't seen much of the semi-automatic removals happening lately [22:11] oh [22:11] It's not wrong to suggest removal in such cases, but there's not a lot of benefit to it. [22:13] bdrung: can you do a no-change upload to at least get the reference correct now, and i'll file a bug on the package to get the .la out of there? [22:13] bdrung: bug 727988 is a blocker for a claws-mail bug i'd dearly love to get fixed (and will be pushing a branch for momentarily) [22:13] Launchpad bug 727988 in gpgme1.0 (Ubuntu) "/usr/lib/libgpgme.la has broken dependency_libs entry" [Undecided,In progress] https://launchpad.net/bugs/727988 [22:16] barry: A better goal would be to get rid of the .la file in gpgme entirely. [22:16] ScottK: sure, but they don't have to be mutually exclusive ;). i'm happy to file that bug next, work on a fix and even submittodebian [22:17] otherwise i guess i'll just run the fixed claws out of my ppa [22:18] No we should get the fix in the archive. [22:51] barry: i will do the no-change rebuild. what should be changed by it? [23:11] barry: done [23:13] bdrung: since you're looking, can i harass you to twiddle the ubiquity mp at the top of the queue? [23:14] (we're *so close* to emptying the queue that it just seems like a shame to not push through) [23:15] raof: are you here for your 8 hours :-) ? [23:15] acarpine: Ah, yes. [23:16] Good for me :-) Just a couple a questions [23:16] bdrung: thanks! i will file that bug and work on a real fix -- after i push the claws fix [23:16] raof: I'm curious about how should be treated the bug 719379 after the comment in https://code.launchpad.net/~acarpine/ubuntu/natty/python-fstab/fix-719379-round2/+merge/51661 which say that "Debian doesn't have the package anymore..." [23:16] Launchpad bug 719379 in python-fstab (Ubuntu) "Typos in Exception and docstring" [Undecided,Confirmed] https://launchpad.net/bugs/719379 [23:17] ari-tczew: i'm a bit confused by your request to wrap-and-sort samba4 (lp:~jelmer/ubuntu/natty/samba4/various-fixes). does that really make sense for a package that we're merging from debian? [23:18] broder: I only suggested. I didn't demand. [23:18] acarpine: Yeah. It turns out that nothing actually *uses* python-fstab (you can use “apt-cache rdepends python-fstab” to check the list of things depending on python-fstab). What we should probably do is check that it's removed in Debian, and why it hasn't been removed from Ubuntu yet, and then ask for it to be removed. [23:19] ari-tczew: but why suggest at all? from my perspective, it seems like it just introduces unnecessary skew [23:19]