=== emma is now known as em [00:52] ari-tczew: the debian-ubuntu debdiff that you attached to #685345 is for fetchmail, not j-a-c-k. [00:53] crimsun: ah, late time... I'm on it [00:55] crimsun: fixed. wanna sponsor? [01:05] ari-tczew: uploaded, thanks! [01:05] crimsun: np. wanna sponsor also fetchmail? (: [01:06] bug # ? [01:07] crimsun: bug 685065 [01:07] Launchpad bug 685065 in fetchmail (Ubuntu) "Merge fetchmail 6.3.18-2 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/685065 [01:18] ari-tczew: uploaded, thanks! [01:18] crimsun: np, thanks me too === Zhenech_ is now known as Zhenech === Zhenech_ is now known as Zhenech [04:04] anyone interested in helping package up a ruby app this evening? === Amaranth_ is now known as Amaranth === em is now known as emma === Zhenech_ is now known as Zhenech [05:37] I submitted a patch using submittodebian tool [05:37] how do I confirm it has reached the BTS? [05:37] ssj6akshat: you should get an email? [05:38] micahg, in how much time? [05:38] ssj6akshat: a couple hours [05:39] * ssj6akshat doesn't like to wait [05:39] ssj6akshat: patience is very important :) [05:39] should I add the patch to the launchpad bug as well? [05:40] ssj6akshat: if you're using submittodebian I assume it's already been fixed in natty? [05:46] micahg, ah well, here is the debdiff http://paste.ubuntu.com/539895/ [05:47] bug #602671 [05:47] Launchpad bug 602671 in One Hundred Paper Cuts "Description: p7zip " [Low,Triaged] https://launchpad.net/bugs/602671 [05:49] ssj6akshat: first, you should target to natty instead of maverick, after that, yes you should attach it, also, I would think type of bug the change should be approved before forwarding [05:50] micahg, whoops it should be natty [05:52] * ssj6akshat spent a whole day learning how to fix this [06:07] ssj6akshat: please link the Debian bug when you have it [06:08] ok [06:09] ssj6akshat: also, see my comment in teh bug, your patch is lacking something that's in the current description === Zhenech_ is now known as Zhenech [06:13] micahg, I do not understand what you said in the bug [06:14] ssj6akshat: the description explains why you should install p7zip instead of p7zip-full [06:27] ssj6akshat: also, I think you misunderstood what the 2 sections in the description were for, the first paragraph was explaining what the current package does, the second about the alternative [06:36] micahg, p7zip doesn't appear in software center but rather p7zip-full does [06:36] ssj6akshat: they should both be available [06:45] micahg: it's hidden as a technical item.. [06:45] vish: but it's not [06:45] hmm.. /me not sure about that, maybe thats another bug we need to get fixed.. [06:46] seems someone decided p7zip-full is better than confusing users with too many options.. [06:46] vish: it's for people that only need 7zip archives and not the rest [06:47] * micahg is not in favor of hiding things [06:47] right, but the person needs to be technical enough to realize he will not ever need any of the other archive types. ;) [06:47] vish: also, we can't change the description just to look good in SC, it has to reflect the nature of the packages as well [06:48] micahg, software center shows Version:9.04~dfsg.1-1 (p7zip-full) for 7zip [06:48] micahg: yea, but what are we missing there? (which does not reflect good on the package) [06:49] vish: I commented in the bug on that, the current description shows what is in teh pacakge and what the other one does [06:49] * vish confused, reads comment again.. [06:51] vish: p7zip explains what p7zip is and why you might want p7zip-full, p7zip-full does the opposite [06:52] micahg: we are changing only the description for p7zip-full.. not touching p7zip now, since its hidden [06:52] vish: right, but you need to keep the explanation of what the 2 packages are [06:53] oh are you saying that the description needs to mention '-full' ? [06:53] vish: it's fine to clarify points in the description [06:53] vish: yes, and also a short summary of p7zip like the current description [06:59] micahg: i dont see why the user needs to know it is the -full , the package title itself is "7zip", the -full part is just a package details/packaging technicality . why bother the user with that? is it going to harm them? rather if this was a limited package then i see the need for stressing that "this package is $foo and no such options are here, look at the other $bar" [06:59] vish: because this description has to work for both distros [07:00] micahg: why would it be wrong in any other distro? [07:00] we just treat the p7zip-full package as the main package, just like there is only one 7zip [07:00] vish: right, but we can't do that since it's not and the description needs to work for cli users in Debian and Ubuntu as well [07:02] micahg: maybe i'm not understanding something here, why is it not the main package? is there any other main p7zip package? [07:02] for cli it does mention "Additionally, it provides you with the 7z and 7za commands at the command line." [07:02] vish: it's not about main vs not main, there's the full version and the one with just the 7z utils [07:03] micahg: p7zip is the one with just the utils? [07:04] vish: yes [07:09] micahg: so would "Complete list of supported formats handled in p7zip-full:" be better? [07:10] vish: yes, and also, we should keep the short description of p7zip [07:11] micahg: you mean this last line? "p7zip provides 7zr, a light version of 7za, and p7zip a gzip like wrapper around 7zr."" [07:11] vish: yes [07:14] nah.. then that just ends up being confusing. and user will wonder what is difference between p7zip and p7zip-full, rather we can probably make it better in the p7zip description [07:14] vish: it's common for descriptions to list alternative choices when appropriate, I don't think the Debian maintainer will drop it [07:15] micahg: well, let's try first.. :) [07:16] oh i so wish that they would just publish the SC usability testing data.. would save a lot of explaining :) [07:16] debian folks are too adamant at times :( [07:16] * vish hides [07:16] vish: SC is not the only package interface [07:16] vish: that's what I was trying to explain before [07:17] micahg: yea.. but still for whom are such packages meant for? [07:17] vish: anyone [07:17] micahg: remember we are not trying to fix every description out there. :) [07:18] and everyone needs to understand. and not get confused. [07:19] vish: yes, but you have to balance the casual user with the technical user [07:19] yup.. [07:19] and we can't hijack Debian's description because it's better for our users, we can enhance the description to make things clearer [07:19] hehe! ;) [07:20] micahg: no one said we would hijack, first we send them a description, if they are OK, we use it.. [07:20] else we tweak [07:21] vish: I'd rather send one they're less likely to reject, but c'est la vie [07:21] ;) [07:49] Hi guys [07:49] I noticed the packaging channel doesn't have a lot of activity. Should I just ask packaging questions in this channel instead? [07:50] spaceboy: well, it's the weekend, so it's a little slow, but I didn't see any questions there in the last several hours === Zhenech_ is now known as Zhenech [08:56] What was the dh tool for editing the changelog? [08:57] MTecknology: i think its "dch -i" [08:57] try it [08:57] thanks [08:57] hm.. it doesn't like me [08:58] it doesn't like that the upper level isn't the version number [08:58] looks like dch -e changelog 'should' work but it still complains [08:59] dch: fatal error at line 616: Found debian/changelog for package nginx in the directory /home/builder/collab-nginx/trunk but this directory name does not match the package name according to the regex PACKAGE(-.+)?. [08:59] MTecknology: to edit the current entry, use dch if it's your first time editing, or dch -e if you've edited it before, use dch -i to add a new entry on top [09:01] micahg: I tried -e to edit an existing entry but got the same error [09:02] micahg: http://paste.ubuntu.com/539919/ [09:02] MTecknology: no, in the trunk dir run dch -e [09:03] oh! [09:03] or dch if you're not the one in the changelog entry [09:11] thanks :) === Quintasan_ is now known as Quintasan [09:55] ricotz: why aren't you in uploaders for docky? [09:55] or can you not upload? [09:56] micahg, i cant upload [09:56] ricotz: I'm test building your sync request now BTW [09:56] micahg, thanks === yofel_ is now known as yofel [11:13] micahg, arent you going to upload docky? [11:13] why upload it if it's a sync? [11:14] Laney, i mean sync ;) [11:14] it will get processed by an archive admin as normal [11:14] micahg: you did forget to subscribe ubuntu-archive though [11:15] done [11:15] Laney, ok, that would have been my next question [11:16] Laney, thx [11:16] Laney: while you are here: do you have an idea what needs fixing here: http://launchpadlibrarian.net/58533827/buildlog_ubuntu-natty-armel.haskell-binary-shared_0.8-1_FAILEDTOBUILD.txt.gz [11:16] nps [11:17] ooh [11:17] I haven't looked at any haskell yet this cycle [11:17] I see that only in armel builds of haskell-* packages [11:18] seems like a toolchainish thing doesn't it [11:18] i386 and amd64 doesn't seem to be affected (at least the recent archive rebuild doesn't list haskell-* packages) [11:20] I don't know how linking of ghc6 programs works, so I don't have an idea if building hlibrary.setup needs the -lpthread or ghc6 itself when linking libHSunix-2.4.0.0.a [11:26] Me neither, let me check on my armel machine [11:26] might have to raise to glasgow-haskell-users [11:28] how can I leave memo msg? === Zhenech_ is now known as Zhenech [12:11] ari-tczew: /msg MemoServ HELP [12:22] geser: http://hackage.haskell.org/trac/ghc/ticket/4523#comment:1 [12:22] i'll test against ghc6 with that patch and then upload if it works [12:23] might take some time for ghc6/armel to build though… [12:24] thanks [12:50] urgh, bootstrapping problem === ssj6akshat is now known as ssj6akshat_afk [12:50] ghc6 build-depends ghc6 and builds a script as part of configure, which fails due to this problem [12:51] :( === ssj6akshat_afk is now known as ssj6akshat-afk === Zhenech_ is now known as Zhenech [13:35] bdrung: there? [13:38] RainCT: why did you change from Ubuntu binary package from zeitgeist-fts-extension to zeitgeist-extension-fts ? [14:12] apt-rdepends is enough to find depends on X package [14:13] ? [14:13] grep-available -FDepends $package -sPackage [14:14] apt-cache showpkg also show reverse depends === Zhenech_ is now known as Zhenech [14:15] depending on why you need it you might also need to check for rbuild-depends [14:19] Rhonda: grep-available: invalid option -- 'f' [14:19] Where did I say -f? [14:19] geser: ATM I'm looking for depends on binary package. [14:20] Rhonda: I used: $ grep-available -FDepends $zeitgeist-fts-extension -szeitgeis-fts-extension [14:20] erm … [14:20] That's not what I said. :) [14:20] ari-tczew: for that case it's unlikely that this package is used as a build-dependency [14:20] Only substiture $package with the package name. [14:20] ari-tczew: So grep-available -FDepends zeitgeist-fts-extension -sPackage === emma is now known as em [14:22] geser: I wanrt to sync zeitgeist-extensions, but RainCT has changed binary package name in Debian and if I want to sync it, I have to resolve Build-Depends and Depends. [14:22] s/wanrt/want [14:22] thanks Rhonda, now I got output [14:27] ari-tczew: Hey. There's not much point in syncing, the geolocation extensions which the Debian package includes isn't really useful yet and other than that I think they're the same. [14:28] RainCT: I'm really convinced to reduce delta between Debian and Ubuntu. (again I must start open the same discussion) [14:29] Delta by itself isn't bad. [14:29] RainCT: we prefer to manage package through Debian [14:32] Rhonda: can I use this command to find b-d? [14:35] Sure, though you would need grep-dctrl instead of grep-available and hand it the Sources file as argument. [14:35] Like grep-dctrl -FBuild-Depends,Build-Depends-Indep $package -sPackage /var/lib/apt/lists/*_Sources [14:36] * Rhonda . o O ( and again, *only* substiture $package with your search term, nothing else in that commandline ) [14:38] or use reverse-build-depends from u-d-t [14:41] geser: nice tool! do you have something similiar for looking for Depends field? [14:44] for that I usually use "apt-cache rdepends" [14:53] geser: thanks, it works! [14:57] I'm trying to use checkinstall (yeah, I know I should make a real package) but it fails because of missing dependencies, glib2 among them. I can't find a package named glib2 in the repositories and I am confused about how checkinstall determined a debian package dependency. [15:10] quidnunc: it probably didn't, please pastebin the exact messge you get === Zhenech__ is now known as Zhenech [15:33] Bachstelze: The error is [15:34] Bachstelze: "dpkg: dependency problems prevent configuration of xmonad-log-applet: [15:34] xmonad-log-applet depends on glib2; however: [15:34] Package glib2 is not installed." [15:34] Bachstelze: The full paste is http://pastebin.ca/2011207 [15:46] quidnunc: your pckages has dependencies, maybe the upstream tarball has a debian/ folder? [15:47] Bachstelze: no debian folder [15:47] it does have a .spec file [15:48] I have never seen that before [15:48] google search tells me it is for rpms [15:51] Is there a utility to build debs using .spec files? [15:54] quidnunc, glib2 is in main repos https://launchpad.net/ubuntu/+source/glib2.0/2.27.4-0ubuntu1 [15:55] quidnunc, glib2.0 package [15:57] quidnunc, you should look at installing libglib2.0-0 [16:00] coolbhavi: the ackage asks for glib2, so it won't find libglib2.0-0 [16:00] the problem is how the dependency got there in the first place [16:00] quidnunc: how about editing the .spec file, or deleting it altogether? [16:01] Bachstelze, hmm maybe i got the problem wrong === ssj6akshat-afk is now known as ssj6akshat [16:56] deleting the spec solved my problem, thanks [16:57] quidnunc, great! [17:33] mr_pouit: Seems that you're a XFCE master. my admiration! [17:41] Laney: thanks [17:42] ricotz: syncs are now processed regularly by archive admins, should happen Monday or Tuesday === ssj6akshat is now known as ssj6akshat|sleep [17:59] micahg, alright, i wasnt aware of this change [18:31] anyone there? [18:32] i looking at sponsor for lp:#63189 [18:44] Hello all. In Revu (http://revu.ubuntuwire.com/), some packages still need review and (as the site tells) have been uploaded almost 2 years now (the older was uploaded at 08 May 2009 11:39 ). So, I uploaded wallch (it is the last package now if you see). I would like to know when it will be reviewed. I am not in a hurry, but simply to know, because I find very strange all these packages than need review from 2009 and so. [18:45] udienz: it's in NEW right now, but I think there are still some issues [18:46] hakermania: yes, we don't have the people power to review large numbers of packages, that's why we usually suggest going through Debian [18:46] micahg: what issue? [18:47] micahg: So, when it will be reviewed ? [18:47] udienz: first, the version looks off, second there are some lintian warnings [18:47] hakermania: idk [18:49] But there is a MAIN problem: in the changelog i have given "natty". When my package is reviewed natty will have been released! So my package will go back to needs work!!!!!!! ? [18:50] Have anyone though about this? [18:50] hakermania: if that's the only issue it's easy enough to resolve, usually there are more issues than that with a package on REVU [18:51] How many people are working on revu? [18:51] hakermania: a handful I think [18:52] micahg: hm.. i see. so i want to fix "missing-debian-source-format " in lintian i must put "3.0 (native)" in debian/source/format? [18:52] udienz: I requested that an archive admin delete the package that was uploaded already since there are some changes and it's still going through churn for Debian [18:52] udienz: why is it native? [18:53] udienz: native means Debian or Ubuntu is the upstream [18:54] Ok, so what can I do so my package to be in the natty distro? You told something about Debian i think [18:55] micahg: hm.. thanks, so i must change version at debian/changelog to 1.2-0-1ubuntuX? [18:55] and sorry for my bad english :D [18:55] udienz: actually 0ubuntuX if it enters Ubuntu before Debian [18:55] udienz: not a problem :) [18:56] Ok, so what can I do so my package to be in the natty distro? You told something about Debian i think [18:57] udienz: if you don't have a rush need for it to be in Ubuntu immediately, you can finish up the work in Debian and it'll get sync'd, it just has to be in by Feb 24 2011 [18:57] hakermania: what type of application is it? [18:57] Accessory [18:57] (Utils) [18:58] micahg: ok i'll finishing it at debian [18:58] udienz: just keep that date in mind, you should make sure it's sync'd to Ubuntu by that date to insure it's in Natty [18:59] micahg: okay [19:00] micahg: ? [19:00] hakermania: maybe some of the other MOTUs have time, they'll read the backscroll and might take a look [19:01] micahg: no, you previously asked me what kind of program it is. Why? [19:01] hakermania: if one of the Debian teams fits your package, you can try to get it in through Debian and get it reviewed by that team, http://wiki.debian.org/Teams/ [19:02] hakermania: oh, I was going to try to see if it fits with a Debian team, offhand I'm not sure which one, hence I gave you the link to look for yourself to see if there's a good fit [19:03] Ok, does DEBIAN has e.g. GNOME Desktop? Supports gconftool, imagemagick ? [19:05] and something else, the Advocated Package libassuan2 by user jr was uploaded at 03 Dec 2010 16:18 at is already fully accepted!!!! What???? That's not fair! There are package waiting 2 years now to be reviewed and libassuan2 was reviewed in 2 days time! [19:05] IS THIS FAIR? [19:06] sorry for bad english [19:07] hakermania: the package was fine, and was adovcated and accepted [19:08] packages arent necessarily reviewed in order of first-uploaded...more like first-correct [19:08] hakermania: the uploader happens to be an Ubuntu developer, so it just needed review from one person [19:08] How do I become ubuntu developer/ [19:08] ? [19:09] or rather more specially user is a core-dev [19:09] unfair >:o unfair >:o unfair >:o unfair >:o unfair >:o unfair >:o unfair >:o unfair >:o unfair >:o unfair >:o [19:09] hakermania: that won't help your case [19:09] you become an ubuntu dev by demonstrating over the course of several months that you know what you're doing and need minimal supervision [19:09] I thought that only in Greece there are those things :@ [19:10] (several months to years, really) [19:10] hakermania: most of the reviewers are volunteers, they work on what they want to work on [19:10] And why in debian it's easier? [19:10] debian requires only one person to say "its good" [19:10] ubuntu requires wo [19:10] *two [19:11] also, debian has 10x as many developrs who can do reviews [19:11] hakermania: not necessarily easier, but they have more people power, we only have about 180 devs total [19:11] we're up to 180 now?? [19:11] and it's more easy to identify (groups of) people who might be inclined to review a particular package [19:11] 153 capable of advocating for packages [19:12] ohok that sounds more reasonable [19:12] 153 people are unable to handle 1-2 packages per day? [19:12] hakermania: who says they have time to review any? [19:13] hakermania: they're also responsible for 15k+ packages already in Ubuntu [19:13] .... [19:13] I spent 3 months to build my app :( [19:13] and to know if I have something wrong I have to wait 2 years or so... [19:14] ! [19:14] mad. :| [19:14] no... [19:14] the packages that are on there for 2 years are abandoned packages [19:14] it frequently occurs that soemone uploads something, they get one review telling them they did it wrong, and they dont bother fixing it [19:14] 2 years later, its still sitting there [19:15] yeah, because nobody wanted to review them. That's a kind of racism [19:15] A) its nothing to do with the uploader's race, so don't try that [19:15] B) they've generally been reviewed but *not* advocated -- the review said "wrong. start over" [19:15] if you upload something and are told you're doing it wrong, you should upload a fixed version [19:16] itll bump your package back up to the top of the queue, iirc [19:16] So why they aren't at Needs Work section? [19:16] if you never upload a fixed version, it will languish because reviewers are still waiting for you to get around to it [19:16] the whole unapproved thing *is* "needs work" [19:16] ok [19:17] Hmmm [19:18] ouao [19:18] my package has been reviewed [19:18] it is telling that there's not watch file [19:18] ouao [19:18] :) [19:18] I was wrong :) [19:18] So, if I retype dput revu *changes [19:18] it will say that wallch already exists [19:18] how do I force the upload? [19:19] rm the .upload file [19:19] but! [19:19] make sure you regenerate the .dsc and .changes and everything after adding the watch file [19:19] yes ok [19:20] ls -al doesn't show any .upload directory... :/ [19:20] or file [19:20] or something.. [19:21] found [19:21] -f, --force - force an upload of an already uploaded package. [19:24] Could you use enter a bit less, please? [19:31] micahg: thanks for last chat, i've successfully uploaded to mentors.d.o [19:32] udienz: np, let me know if I can help further [19:44] micahg: how to make lintian report at my PC [19:44] same like at revu [19:48] udienz: I'm not sure what REVU uses, but you can run lintian -iIEv --pedantic on a .changes or a .deb file [19:49] or a .dsc [19:50] it's work with *dsc, thanks [19:50] udienz: you'll get the full report if you run it on the .changes created after a binary build. [19:51] lfaraone: wonk fine too [19:51] but i still got debian-watch-file-in-native-package [19:51] but i still got error wthi "debian-watch-file-in-native-package" [19:52] how can i solved this problem? [19:52] udienz: is there a .orig.tar.gz or a similarly named file in the folder above where your debian/ folder is? [19:53] yes, aspell-id_1.2-0.orig.tar.gz is in above debian directory [19:54] udienz: what's your package's version number? [19:54] udienz: https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch [19:54] lfaraone: 1.2-0-4 [19:54] micahg: no, the issue is his package is building as native mistakenly. [19:55] hm, odd. [19:55] lfaraone: i try to build this package from Lucid and Lenny and got same error [19:56] the -0 might be throwing it off, idk [19:56] udienz: did you try setting 3.0 (quilt) in debian/source/format? [19:57] micahg: per Debian policy, "The upstream_version may contain only alphanumerics[33] and the characters . + - : ~ (full stop, plus, hyphen, colon, tilde) and should start with a digit." [19:57] lfaraone: in other words, should be fine :) [19:58] right. [19:59] micahg: if i put "3.0 (quilt: and re run debuild and checked wuth lintian. the error is gone [19:59] exciting. [19:59] * 3.0 (quilt) [19:59] udienz: and you get a .debian.tar.gz in the same dir as teh .orig.tar.gz that's smallish? [20:00] micahg: yes i got it: named aspell-id_1.2-0-4.debian.tar.gz [20:00] udienz: and it only has the debian dir in it and not the source? [20:01] micahg: yes only debian dir [20:02] udienz: \o/ [20:02] it that right? [20:02] udienz: yep :) [20:03] micahg, lfaraone: thanks advice.. [20:30] I'm trying to build a package which is failing with "fatal error: dbus/dbus.h: No such file or directory". I believe that file is provided in one of the following: "Setting up libglib2.0-dev (2.26.0-0ubuntu1) ... Setting up libdbus-glib-1-dev (0.88-2) .." which I added to build-depends. What am I doing wrong? [20:31] ? [20:32] it is maybe a linking error! [20:32] hakermania: Are you speaking to me? [20:32] Yes! [20:32] are you using qt? [20:32] hi guys, quick question, if I push changes via bzr push and then request merge, do I still need to attach the diff file to the bug report? [20:32] hakermania: How can it be a linking error the error suggests that the compiler didn't find a header file [20:33] you want libdbus-1-dev [20:33] hakermania: What? [20:33] http://packages.ubuntu.com/search?searchon=contents&keywords=dbus.h&mode=exactfilename&suite=natty&arch=any [20:33] Laney: I have that as well [20:33] Laney: I tried adding every single dbus dev package that I could find [20:33] then you probably aren't setting CFLAGS right [20:33] to build-depends [20:34] Laney: That may be it: I'm not setting CFLAGS at all [20:35] pastebin the build log [20:35] please :) [20:35] Where is that stored again? [20:35] depends how you are building [20:36] prevu [20:36] don't know :( [20:36] back soon [20:37] it just wraps pbuilder [20:39] I'll just paste stdout [20:39] + stderr [20:43] Laney: http://pastebin.ca/2011417 [20:48] quidnunc: Looks like the cflags are indeed missing. Try adding pkgconfig-depends: dbus-1 in the cabal file. === Pici` is now known as Pici [21:01] Laney: That didn't seem to help but thanks for the tip [21:01] how should I name the General Public License 3 in order not to get from REVU: 'The GNU General Public License is mentioned in debian/copyright but there seems to be no copy of it included in the source tarball, which is a requirement for it. (Note: The file may be there but have an uncommon name; please double-check before trusting this warning). ' I have tried GPL3 but it doesn't work [21:02] use COPYING for the file, it's one of the common names [21:02] if you already embed it, with another name, say so :) [21:04] dapal: Thank you. When it says in the source tarball it means inside the folder with the source, doesn't it? [21:04] yes [21:45] lucas: how often is the information about new Ubuntu uploads for http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi updated? I'm wondering why fbb is not in outdated already when I uploaded a fixed package to Ubuntu on Friday (the page lists no outdated packages at all yet). [21:56] how do i find which package libnotify belongs to ? [21:56] bcurtiswx: apt-file search? [21:56] dpkg -S filename [21:56] (if its installed) [21:57] micahg, maco thx [21:57] bcurtiswx: binary package to source package? or file to binary package? [21:57] geser, first [21:58] bcurtiswx: oh, hmm, apt-cache show PKG | grep ^Source [21:58] or apt-cache showsrc PKG | head -n1 [21:58] if you have a source repository configured (deb-src): "apt-cache madison" and look for the source line [21:59] maco: Source isn't the first line [21:59] its not? [22:00] not for me at least [22:00] yes it is [22:00] for showsrc the first line is Package: and shows the source package name [22:00] maybe it depends on the package :) [22:00] second line is Binary: and shows the binary package name [22:00] its the difference between show and showsrc [22:00] oh, sorry, I didn't notice you said showsrc :) [22:01] back, had connectivity issues [22:01] maco: you are correct :) [22:02] micahg: your line doesn't work as not every package has a Source entry (only those where the binary name != source name) [22:02] geser: you are also correct [22:02] bcurtiswx: did you see out replies? [22:03] not after i said "geser, first" [22:03] until micahg said "oh sorry, i ddin't notice..." [22:03] bcurtiswx: it should all be in the logs now [22:04] "apt-cache showsrc PKG | head -n1" or "apt-cache madison PKG" (for both you need a source repository (deb-src) entry) [22:04] OK, thx all [22:39] i did a bzr merge-upstream which gave a conflict. i see a BASE|OTHER|THIS file how do I "resolve" this conflict ? [22:40] Work out what the resolution should be, save it, then run “bzr resolve” [22:41] The BASE|OTHER|THIS files are just a part of the standard conflict resolution info; one is the BASE file, one is the BASE file + the changes made in THIS tree, one is the BASE file + the changes made in the OTHER tree. [22:41] RAOF, the next step to solving would be identifying the issue. the .BASE .OTHER .THIS file hold this information ? [22:43] Mostly you can ignore the .BASE/.OTHER/.THIS files, because bzr will put conflict markers in the file. Looking like <<<>>>other [22:44] OK, looking [22:46] found that section, lemme pastebin [22:47] RAOF, http://paste.ubuntu.com/540110/ how do I tell it which to keep ? i would assume the stuff after the ==== is more specific and is what should be kept [22:47] Working out what to keep requires understanding what was changed, both in the ubuntu branch and in the upstream branch. [22:48] In this case, the second branch (after the ====) looks like the right one. [22:48]