[00:30] <micahg> hi espen77
[00:30] <espen77> hi :)
[00:31] <espen77> is there a command to make a diff between .orig.tar.gz and unpacked directory?
[00:31] <micahg> 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] <micahg> espen77: the sponsorship page I linked you to should I have a guide to debdiffing
[00:32] <micahg> *have a link to a guide
[00:33] <espen77> micahg: atleast google have
[00:34] <micahg> espen77: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff#Creating%20A%20Debdiff
[00:35] <espen77> yeah, reading
[00:50] <freakabcd> 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] <freakabcd> 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] <paultag> freakabcd: yeah :)
[00:51] <paultag> freakabcd: I was using it the other day
[00:52] <paultag> 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] <freakabcd> 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] <paultag> oh you found it
[00:53] <freakabcd> why does the package python-opencv exist? it seems to happily install itself without any dependencies, etc!
[00:53] <paultag> freakabcd: the big ones: http://pastebin.com/u80TYmXM
[00:53] <paultag> freakabcd: it sure does
[00:53] <paultag> freakabcd: test it :)
[00:53] <freakabcd> ewww.. why is it libcv instead of libopencv ?
[00:54] <paultag> freakabcd: I have some example python-cv code on my blog: http://blog.pault.ag/post/1980116944/python-opencv
[00:55] <paultag> beware that haarcascades issue I ran into
[00:56] <freakabcd> paultag: err.. on that page you linked, there is no src code!
[00:56] <freakabcd> or is it because noscript blocked it for me?
[00:57] <paultag> freakabcd: yeah, let me get you the gist :)
[00:57] <paultag> freakabcd: https://gist.github.com/603819
[01:00] <freakabcd> lol indeed.. those should not be in the doc package
[01:01] <freakabcd> so what exactly is lookatme.py doing? simply tracking the head?
[01:01] <freakabcd> or heads
[01:01] <paultag> 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] <paultag> freakabcd: Who knows, mirite?
[01:02] <freakabcd> heh, but it immediately terminates on trying to run here :(         terminate called after throwing an instance of 'int' \n Aborted
[01:02] <freakabcd> i will ask in #opencv
[01:02] <paultag> freakabcd: sounds like you're missing the haarcascade stuff
[01:02] <freakabcd> but i have installed opencv-doc
[01:02] <paultag> 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] <freakabcd> oh, you mean its gone to the wrong dir
[01:03] <paultag> freakabcd: yeah, there was something dumb as hell about that package
[01:05] <freakabcd> paultag: whats in /usr/share/opencv ?
[01:05] <freakabcd> the haarcascades dir?
[01:05] <freakabcd> for me thereis nothing in that dir except for a cmake file lol
[01:05] <paultag> freakabcd: yeah, I think I had that issue too
[01:05] <paultag> freakabcd: just copy in files where they should be from the source
[01:06] <freakabcd> paultag: also do i need to gunzip the xml.gz files or can is work with the zipped ones?
[01:06] <paultag> freakabcd: I think they need to be "real" xml
[01:07] <freakabcd> 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] <paultag> freakabcd: I'm on a different machine -- I'm ssh'd in from work
[01:08] <paultag> freakabcd: sorry :) -- I put a link in that bug report as to where that stuff should be
[01:08] <freakabcd> so i can know the right path: i.e. /usr/share/opencv/haarcascades/*.xml or /usr/share/opencv/haarcascades/haarcascades/*.xml
[01:08] <paultag> freakabcd: ah, sec
[01:08] <freakabcd> yeah, but the non-unified diff hurts my eyes :D
[01:08] <paultag> /usr/share/opencv/haarcascades/*.xml <-- freakabcd
[01:09] <freakabcd> thanks
[01:09] <paultag> freakabcd: righto
[01:10] <freakabcd> right i wanted to do eye tracking and even lookatme.py seems not stable enough
[01:11] <freakabcd> i wanted to finally have pointer follow eye on my laptop
[01:11] <paultag> freakabcd: ah, haha. Good luck :)
[01:11] <freakabcd> did you manage to do something like this? i see there are some software that allegedly do this
[01:12] <paultag> 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] <paultag> or a high framerate, high quality camera that extracts where your eye is and uses that, but that seems hugely complex
[01:12] <freakabcd> grrr.. and i thought one could do this sort of tracking with cheapass webcams
[01:13] <paultag> :P
[01:13] <paultag> 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] <psusi> 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] <freakabcd> yeah, thanks. but someone needs to rename that package to be libopencv instead of libcv
[01:14] <slangasek> psusi: ok, great :)
[01:14] <paultag> freakabcd: why?
[01:14] <psusi> 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] <paultag> freakabcd: we don't have un-open software in Debian main ;)
[01:14] <slangasek> psusi: sure, by all means close them out now
[01:14] <freakabcd> because everywhere it says opencv all websites were saying opencv
[01:15] <psusi> slangasek, got any advice for how to do that batch style?
[01:15] <paultag> freakabcd: file a bug :)
[01:15] <freakabcd> and now if i had installed python-opencv, it installed without any deps
[01:15] <psusi> last time I just did each one on the lp web site by hand....
[01:15] <paultag> psusi: lplib not working for ya? ;)
[01:16] <psusi> paultag, wassat?
[01:16] <paultag> psusi: launchpadlib -- you know the python bindings to launchpad so you can batch operations (like, say, closing out a list of bugs)
[01:16] <psusi> I was thinking of just using the email interface but that would still require me typing in each of the bug numbers ;)
[01:16] <psusi> paultag, you mean roll my own python using the lib?  I have been learning python.... hrm...
[01:17] <paultag> psusi: go for it, dude. Are you trying to close out all the bugs against a package or something?
[01:17] <psusi> paultag, yea
[01:17] <paultag> 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] <psusi> hrm....
[01:18] <paultag> (tags might have done you some good)
[01:18] <psusi> well, they are all getting closed since the package has been dropped
[01:18] <paultag> psusi: lp should take care of that, yes?
[01:19] <psusi> hrm.. I can't find lplib...
[01:19] <psusi> paultag, doesn't look like it
[01:19] <paultag> psusi: python-launchpadlib
[01:44] <psusi> 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] <paultag> psusi: feel free to jack code from: http://launchpad.net/locolint
[01:48] <paultag> psusi: there's code in there that does some of what you need to do
[01:49] <paultag> 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] <MTecknology> Ampelbein: alrighty; thanks, I'll ask one more place and go to the mailing lists.
[01:53] <psusi> why does launchpad.projects['powernowd'] not get me the powernowd project?
[01:54] <paultag> psusi: https://launchpad.net/powernowd <-- because there's nothing with that name
[01:54] <paultag> psusi: you'll be using ubuntu, then loading bugs against that package
[01:54] <paultag> last I checked, anywho. I'm not handy with lplib
[01:54] <paultag> psusi: if you need more help, #launchpad might be the right place
[01:56] <paultag> psusi: ubuntu dev tools might help too
[02:03] <psusi> slangasek, should they be invalid, or wontfix do you think?
[02:11] <Ampelbein> psusi: if you want all bugs from a package, try something like lp.distributions['ubuntu'].getSourcePackage['name'].getBugTasks
[02:38] <slangasek> psusi: I'd say 'invalid'
[03:19] <c2tarun> Can anyone please help me with this error http://paste.ubuntu.com/574265/
[03:21] <Ampelbein> c2tarun: looks like you are missing a build-dep
[03:22] <c2tarun> 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] <Ampelbein> c2tarun: it complains about 'Qt qmake not found!' and the module is called (see line 5) findQt4
[03:24] <Ampelbein> c2tarun: so you make 'apt-cache search qt4 qmake'
[03:24] <Ampelbein> c2tarun: that would be my guess at least
[03:25] <c2tarun> Ampelbein: on searching I got qt4-make is it this one?
[03:25] <Ampelbein> c2tarun: I guess it is.
[03:25] <c2tarun> Ampelbein: thanks :)
[03:40] <c2tarun> 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] <Ampelbein> c2tarun: then I don't know :-(
[03:44] <MTecknology> Ampelbein: I'm still hoping to get a reply from the mailing list; because I'm utterly lost
[03:45] <Ampelbein> 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] <MTecknology> Ampelbein: yup; and in your first try it actually worked; somehow
[03:46] <MTecknology> I'm baffled
[03:46] <Ampelbein> MTecknology: I think that was because I did multiple tries without going back to a "clear" state before each try
[03:47] <MTecknology> oh
[03:47] <MTecknology> so then the answer should probably be very very simple
[04:36] <artfwo> is there any reason to use 3.0 source format for a new package, that has no patches yet?
[04:36] <paultag> artfwo: no sense in using something old, since if you don't have source/format, lintian will whine
[04:36] <paultag> artfwo: so why put anything besides it in there ;)
[04:37] <artfwo> hmm, lintian had not warned me about it (on a maverick machine)
[04:38] <paultag> artfwo: -IE --pedantic ?
[04:38] <ScottK> paultag: missing source/format is a fairly pointless whine.
[04:38] <paultag> I don't think it's E or W
[04:38] <paultag> ScottK: aye
[04:38] <paultag> ScottK: but it's also fixed without much work, so I hate seeing it :)
[04:38] <ScottK> I hate wasting time on pointless things.
[04:38] <ScottK> To each his own.
[04:40] <artfwo> well, there might be a reason, besides the lintian whine (paultag, it showed up with -IE)
[04:40] <paultag> artfwo: not really, narp.
[04:40] <micahg> 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] <paultag> artfwo: unless you need multi .tar.gz, then you need 3.0 :)
[04:40] <artfwo> oh, okay
[04:40] <artfwo> thanks for the explanation
[04:41] <artfwo> paultag: since you mentioned multi tar.gz I have another question :)
[04:42] <paultag> artfwo: yis. forewarning, I'm not MOTU. Just a casual hacker up in debian.
[04:42] <artfwo> I'm going to package a soundscape tool, called boodler (straight to debian, likely), and it has lots of tiny soundscape packages
[04:43] <paultag> artfwo: sure
[04:43] <artfwo> they're all distributed in separate files
[04:43] <paultag> 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] <artfwo> 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] <paultag> artfwo: might be worth packaging each on their own
[04:44] <paultag> but I don't know
[04:44] <paultag> I'd ask a DD
[04:44] <artfwo> there will be 54 packages then :)
[04:44] <paultag> oh jesus
[04:44] <paultag> might just need a -plugins package or something
[04:45] <artfwo> I was thinking about -plugins package, but what approach to choose?
[04:45] <paultag> artfwo: I don't know. I'd ask your friendly DD
[04:45] <artfwo> okay :)
[04:45] <paultag> :)
[05:05] <Ampelbein> 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:07] <micahg> Ampelbein: I would think fail gracefully and don't leave the system in an unusable state
[05:08] <Ampelbein> micahg: so you think, catch the error and give the user a "please run dpkg-reconfigure $package later"?
[05:10] <ScottK> I think better to figure out why useradd failed.
[05:11] <micahg> Ampelbein: idk, seems like dpkg already does that
[05:13]  * micahg thinks ScottK's suggestion is good
[05:14] <Ampelbein> ScottK: yes, in the case of useradd it's mostly a result of a stale *.lock file
[05:14] <Ampelbein> at least that's what I found on the matter
[05:16] <ScottK> Then running dpkg-reconfigure wouldn't help, would it?
[05:17] <Ampelbein> ScottK: in that case not until the root cause is removed.
[05:17] <ScottK> So I don't think that type of warning helps much.
[05:17] <Ampelbein> 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] <ScottK> I usually treat these things as configuration errors and convert them to questions.
[05:18] <ScottK> But that's just me.
[05:18] <ScottK> I think convert to question is way under utilized.
[05:19] <micahg> ScottK: it's currently partially broken
[05:19] <ScottK> micahg: What part of LP is not at least partially broken?
[05:19] <Ampelbein> 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] <micahg> ScottK: heh, I meant broke such that it's unusable for packages with large numbers of subscribers
[05:20] <ScottK> micahg: It's not unique in that regard.
[05:29] <c2tarun> can anyone please help me with this error http://paste.ubuntu.com/574265/
[05:29] <lifeless> ScottK: :(
[05:30] <lifeless> convert to question specifically is a disaster
[05:30] <lifeless> its on our hit list to fix in the short term
[05:30] <StevenK> ScottK: Could you go a few days without sticking the knife in and twisting?
[05:30] <ScottK> lifeless: I think you've been doing great work to make things better over there.
[05:30] <StevenK> lifeless: I want "Convert to forum post"
[05:31] <ScottK> 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] <lifeless> ScottK: thanks
[05:31] <lifeless> we should have some new capacity in the next week-or-mumble
[05:31] <lifeless> which will help
[05:31] <lifeless> one of lps failings is success
[05:32] <lifeless> StevenK: that could be nice
[05:33] <artfwo> c2tarun: did you install qt4-qmake or specify it as build dependency?
[05:33] <c2tarun> artfwo: yup, both
[05:34] <artfwo> c2tarun: you need to make sure qmake is in your PATH
[05:35] <artfwo> since it's install to /usr/share/qt4/bin/qmake
[05:35] <c2tarun> artfwo: how can I check qmakes path?
[05:35] <artfwo> perhaps you need to refresh your environment? (logout and login again)
[05:37] <c2tarun> artfwo: how can i check qmake is in my PATH?
[05:37] <artfwo> if it doesn't run, it isn't
[05:38] <c2tarun> ok, than how can i include it in my path?
[05:39] <artfwo> I think it's included by default
[05:39] <artfwo> you just need to refresh your environment, like logging out and logging in again (read above)
[05:39] <artfwo> I cannot guarantee it will work though, but it's worth a try
[05:39] <c2tarun> artfwo: already did that
[05:40]  * c2tarun I did it when you said. :( its not working
[05:40] <artfwo> hmm
[05:41] <artfwo> how did you remain online here then? :)
[05:41] <artfwo> (just curiuous)
[05:41] <c2tarun> artfwo: I am building it on chroot ;)
[05:41] <c2tarun> artfwo: I exited from chroot and entered again
[05:42] <artfwo> entering chroot does not reset your PATH, I recall
[05:42] <artfwo> you have to run something like source /etc/profile
[05:43] <c2tarun> artfwo: actually my home is not mounted on chroot's home. chroot have a separate home, so it will reset the path
[05:44] <artfwo> I'd still run "source /etc/profile" after entering chroot to be sure
[05:45] <c2tarun> artfwo: done :( same error.
[05:46] <artfwo> do you have a QTDIR environment variable?
[05:47] <c2tarun> artfwo: nope, what is it?
[05:47] <artfwo> it's where Qt is installed. cmake normally looks for qmake under PATH and QTDIR
[05:48] <artfwo> and I thought, these variables are updated automatically after installing appropriate dev-packages
[05:48] <c2tarun> let me check
[05:49] <c2tarun> artfwo: I dont have QTDIR set.
[05:53] <c2tarun> 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] <artfwo> wow, that's an erroneous error message
[05:56] <artfwo> it's thrown if QT4_INSTALLED_VERSION_TOO_NEW is true
[05:57] <c2tarun> are you sure, I mean i think Qt4_FIND_VERSION_EXACT and QT4_INSTALLED_VERSION_TOO_NEW both should be true.
[05:58] <artfwo> it evaluates the entire "Qt4_FIND_VERSION_EXACT and QT4_INSTALLED_VERSION_TOO_NEW" expression
[05:58] <artfwo> anyway, the qmake-related error message is out of sense here
[05:59] <c2tarun> artfwo: ya and with the AND in b/w both should be true then only we'll get the message
[05:59] <artfwo> if it's not an arithmetical AND :)
[05:59] <c2tarun> artfwo: oh.. :) sorry then
[06:00] <artfwo> what package are you trying to fix?
[06:00] <c2tarun> attica
[06:06] <artfwo> 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] <artfwo> but their fix looks non-revelant to us, I haven't investigated
[06:10] <c2tarun> artfwo: yup, they fixed something in any Portfile
[06:11] <c2tarun> do you know what a portgroup, that might be handy here.
[06:11] <artfwo> that's their specific build system I think
[06:12] <artfwo> but strangely, they fix it by switching some kind of build profile
[06:13] <c2tarun> yup, somehow some kde 1.0 doesn't support qt4 :/
[06:13] <artfwo> perhaps an environment check will do the trick?
[06:13] <artfwo> something like setting your PATH to include /usr/lib/qt4/bin perhaps?
[06:14] <artfwo> does the command qmake or qmake-qt4 run in your chroot?
[06:15] <c2tarun> yup
[06:15] <c2tarun> artfwo: http://paste.ubuntu.com/574306/
[06:16] <artfwo> right
[06:17] <artfwo> I cannot help you any further then, let's hope someone does :)
[06:18] <c2tarun> 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] <micahg> this all doesn't sound right
[06:19] <micahg> which package is this?
[06:19] <c2tarun> attica
[06:26] <micahg> c2tarun: you might want to ask in #kubuntu-devel if there are any tricks
[06:26] <c2tarun> 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] <c2tarun> 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] <micahg> c2tarun: did you check the Debian svn repo to see if any fixes have been committed?
[06:30]  * c2tarun checking
[06:31] <c2tarun> well I looked into rmadison and debian is a version behind the version I am working on
[06:31] <c2tarun> micahg: and there are not bug reports for this package :(
[06:31] <micahg> c2tarun: yes, but a new version can be in the repo unreleased
[06:32] <c2tarun> micahg: how to look into repo?
[06:32] <micahg> there should be a link on packages.qa,debian.org/attica
[06:35] <c2tarun> micahg: hey I think there is a patch, let me try
[06:36] <micahg> c2tarun: make sure to give proper attribution to the patch author and source (DEP-3)
[06:37] <c2tarun> micahg: umm.... I am familiar with DEP-3 but what do you mean by proper attribution?
[06:38] <micahg> c2tarun: author and other headers
[06:38] <micahg> !dep3 > c2tarun
[06:38] <micahg> ah, you're familiar, sorry
[06:39] <c2tarun> micahg: ok, I'll take care of dep3 headers :) and I'll show it here before any further steps, thank you
[06:42] <c2tarun> micahg: that patch is already applied :(
[07:44] <dholbach> good morning
[08:37] <artfwo> I'd like to split a cdbs package in two by putting, say, hello-first.install and hello-dev.install in debian
[08:38] <artfwo> hello-first.install contains a wildcard, like usr/bin/*
[08:38] <artfwo> hello-dev.install contains usr/bin/devscript
[08:38] <artfwo> devscript actually installs to both packages
[08:39] <artfwo> is there an elegant solution to this problem?
[09:13] <HPV> 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] <HPV> 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] <tdelv> How come?
[09:19] <HPV> what do you know?
[09:19] <HPV> master-debator
[09:19] <HPV> ?
[09:45] <seidos> compassion -> buddha
[09:45] <seidos> 1 xor 0?
[09:45] <seidos> 1
[14:44] <ari-tczew> 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] <tumbleweed> wow the sponsering queue is short! patch pilots ftw
[14:46] <tumbleweed> 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] <ari-tczew> yes, regards to pitti
[14:46] <ari-tczew> tumbleweed: would be nice to keep short url, so Bug-Ubuntu: https://launchpad.net/bugs/623342
[14:47] <ari-tczew> tumbleweed: does it really needed to have a link to bug in d/changelog entry if patch has got DEP3 headers?
[14:47] <tumbleweed> ari-tczew: yeah I normally shorten URLs, doesn't matter, though
[14:49] <tumbleweed> ari-tczew: that's how previous samba uploads had their changlog entries written. I didn't want to chagne the style
[14:54] <ari-tczew> tumbleweed: ok gotcha. nice work!
[14:54] <ari-tczew> bdrung: could you take tumbleweed's patches to sponsorship? then we could get less sponsors overview today
[15:08] <bdrung> ari-tczew: which patches?
[15:08] <ari-tczew> bdrung: samba SRUs
[15:26] <tumbleweed> 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] <Quintasan> dholbach: Is it okay to throw in daily builds of KDE as part of Project Lightning Talks?
[15:33] <dholbach> Quintasan, sure - that'd be great
[15:33] <Quintasan> awesome
[15:36] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 3 starting in 25 minutes in #ubuntu-classroom
[15:38] <acarpine> ready to go!
[15:49] <acarpine> I'm working on the bug 639955 which describes two different error in two different packages (both are related to nvidia pkg)
[15:49] <acarpine> Fixing the first error (in one of the pkg) editing the debian/changelog should I use the bug number (LP ...)
[15:50] <acarpine> ?
[16:01] <ari-tczew> acarpine: what's the question?
[16:02] <adamhorden> 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] <acarpine> ari-tczew: ops I saw only now because i'm in #..classroom
[16:18] <acarpine> 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] <ari-tczew> acarpine: it depends, in general every error = another bug
[16:19] <ari-tczew> if you mean two typos, please fix it in one place
[16:19] <acarpine> ari-tczew: also if they are in two diff pkgs?
[16:20] <ari-tczew> acarpine: then open task on two pkgs
[16:20] <ari-tczew> acarpine: however, I think it should be fixed debian/upstream
[16:20] <ari-tczew> upstream*
[16:20] <ari-tczew> typos are not important, if it doesn't cause FTBFS or something
[16:23] <acarpine> arii-tczew: So what do you think I should do?
[16:24] <acarpine> arii-tczew: I know the typos are not important, but is useful for me to understand the process of packaging...
[16:25] <acarpine> arii-tczew: that's why i'm choosing only easy bugs...
[16:30] <psusi> should quilt patches be applied, or not in the bzr branch?
[16:30] <psusi> seems to me like they should not be...
[16:30] <tumbleweed> psusi: UDD branch?
[16:30] <psusi> tumbleweed: yea
[16:31] <tumbleweed> if the package uses sourec format 3.0 (quilt), the importer will import with patches applied
[16:31] <psusi> hrm... why?
[16:31] <tumbleweed> if the package uses quilt in rules, the importer will import with patches unapplied
[16:31] <psusi> wait... what?
[16:31] <tumbleweed> because dpkg-source -x applies patches
[16:32] <psusi> 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] <psusi> seems like that just complicates merging and reviewing changes
[16:32] <tumbleweed> the importer takes uploads that aren't present in a branch, and adds them as new commits
[16:32] <tumbleweed> that's how the UDD branches stay up to date
[16:32] <psusi> right... and when it does so, it applies the packages in the process?
[16:33] <psusi> s/packages/patches
[16:33] <tumbleweed> 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] <psusi> 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] <tumbleweed> psusi: dpkg-source -x will apply patches for source format 3.0 (quilt) packages. That's part of the specification
[16:34] <tumbleweed> (although you can tell it not to)
[16:34] <psusi> and now you have to sort out what source change corresponds to what patch
[16:34] <psusi> tumbleweed: and the auto importer uses that, and so as a result, auto imports with the patches applied?
[16:34] <tumbleweed> yeah, as I said, I don't like applied patches. but they are a fact of life for most UDD branches
[16:35] <tumbleweed> psusi: yes, so you should stick to the same standard already in the branch
[16:35] <psusi> 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] <psusi> they also enlarge the branch by adding duplicate files under .pc/
[16:36] <tumbleweed> yup. Although only .pc/applied-patches needs to be in the branch
[16:36] <psusi> which you have to remember to bzr add when you add a new patch
[16:36] <psusi> ohh.. hrm...
[16:36] <tumbleweed> well, you have to do that, whenever you use any VCS
[16:37] <psusi> 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] <tumbleweed> IIRC you only need .pc/applied-patches
[16:38] <psusi> hrm...
[20:16] <bdrung> tumbleweed: can you incorporate the security update in your samba SRU fix branches?
[20:17] <tumbleweed> bdrung: oh, whoops, sure
[20:24] <bdrung> tumbleweed: debdiffs would be a bonus (smaller downloads for me)
[20:52] <tumbleweed> bdrung: debdiffs posted. That security update made the bzr merge proposals hard to read, anyway.
[21:42] <tumbleweed> bdrung: thanks
[21:42] <bdrung> 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] <bdrung> tumbleweed: yw
[21:43] <tumbleweed> bdrung: aah, that should be easy
[21:44]  * tumbleweed likse style changes that don't involve a 10 minute test-turnaround
[21:56] <bdrung> tumbleweed: the sponsor-overview needs only 4m22.899s for the short list
[21:56] <tumbleweed> heh
[21:57] <bdrung> tumbleweed: i am interested how long it takes for an empty queue
[21:58] <tumbleweed> there are almost certainly optimisation-possibilities in it
[22:01] <ari-tczew> what do you think about remove package from universe which has been removed from Debian as well?
[22:01] <bdrung> tumbleweed: thanks for fixing sponsoring.css. can you poke dholbach to pull it?
[22:01] <ari-tczew> !package  xsmbrowser
[22:01] <tumbleweed> ari-tczew: that's almost always a good idea.
[22:01] <tumbleweed> but the archive admins should do it themselves, most of the time
[22:01] <ari-tczew> tumbleweed: ok, will file a bug.
[22:01] <tumbleweed> (i.e. if there isn't a build-failure / urgent issue, don't worry)
[22:02] <bdrung> ari-tczew: check the removal reason in debian.
[22:02] <bdrung> 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] <tumbleweed> bdrung: sure
[22:03] <bdrung> barry: re bug #727988 - -dev packages shouldn't contain .la files any more.
[22:07] <ari-tczew> bdrung: RM: xsmbrowser -- RoQA; dead upstream, orphaned, better alternatives
[22:08] <ScottK> 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] <ari-tczew> ScottK: so don't tuch?
[22:10] <ari-tczew> touch *
[22:10]  * micahg hadn't seen much of the semi-automatic removals happening lately
[22:11] <ari-tczew> oh
[22:11] <ScottK> It's not wrong to suggest removal in such cases, but there's not a lot of benefit to it.
[22:13] <barry> 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] <barry> 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:16] <ScottK> barry: A better goal would be to get rid of the .la file in gpgme entirely.
[22:16] <barry> 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] <barry> otherwise i guess i'll just run the fixed claws out of my ppa
[22:18] <ScottK> No we should get the fix in the archive.
[22:51] <bdrung> barry: i will do the no-change rebuild. what should be changed by it?
[23:11] <bdrung> barry: done
[23:13] <broder> bdrung: since you're looking, can i harass you to twiddle the ubiquity mp at the top of the queue?
[23:14] <broder> (we're *so close* to emptying the queue that it just seems like a shame to not push through)
[23:15] <acarpine> raof: are you here for your 8 hours :-) ?
[23:15] <RAOF> acarpine: Ah, yes.
[23:16] <acarpine> Good for me :-) Just a couple a questions
[23:16] <barry> bdrung: thanks!  i will file that bug and work on a real fix -- after i push the claws fix
[23:16] <acarpine> 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:17] <broder> 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] <ari-tczew> broder: I only suggested. I didn't demand.
[23:18] <RAOF> 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] <broder> ari-tczew: but why suggest at all? from my perspective, it seems like it just introduces unnecessary skew
[23:19] <bdrung> broder: i looked at it and it isn't ready yet
[23:19] <ari-tczew> broder: so blame it
[23:19] <acarpine> ok. My second question is about the fix (that I imagine now is no longer useful).
[23:19] <acarpine> I saw that after I executed the bzr commit and I re-pushed the the changes to the same branch, the changes are now visible in my uploaded branch (the typos are fixed) but the comment about the number of different lines still says "0 lines".
[23:19] <broder> bdrung: err, sorry - mark it as "work in progress" so it fall off the queue :)
[23:20] <acarpine> raof: Is it only a missing update?
[23:20] <ari-tczew> ScottK: around?
[23:20] <ScottK> ari-tczew: Just barely.
[23:20] <RAOF> acarpine: It sometimes takes a while for the merge proposals to update, yes.
[23:21] <acarpine> raof: I pushed the branch yestarday...
[23:24] <acarpine> raof: anyway thank you very much for all your advices! They were all very precious!


[21:06] <jtaylor> is there a reason CONFIG_DM_CACHE is not y in the wily kernel?
[21:07] <jtaylor> it seems to be needed to use lvmcache
[21:12] <apw> jtaylor, why do you think it is not =y
[21:12] <apw> debian.master/config/config.common.ubuntu:CONFIG_DM_CACHE=m
[21:12] <apw> its enabled, as a module, so ?
[21:13] <jtaylor> it needs to be y for lvmcache to work
[21:14] <jtaylor> at least according to blog posts and my own experience in just trying it
[21:14] <jtaylor> didn't try compiling myself yet though


[16:26] <gneeriiloeepdeer> after upgrading to 21.04 my trash acts strange: if I delete items, the trash icon doesn't change and I must manually go into this directory to delete the files. Furthermore, some icons that used to be seen in the desktop are now gone. How do I solve this?g
[19:09] <Helmholtz> I know Xubuntu 18.04 is not longer supported
[19:10] <Helmholtz> but is it possible that a simple `sudo apt update && sudo apt upgrade` may mess up GRUB and boot options?
[19:10] <Helmholtz> I'm on a dual boot with win10. I haven't started win 10 in months so that did not mess it up
[19:11] <Helmholtz> Here are my configs:  https://dpaste.com/EXPL8Z6NW


[07:44] <vila> hi all !
[11:51] <geekosopher> immediately after I branch any lp repo to one of my hd partitions (outside /home), 'bzr st' shows all files of the repo in 'modified' category, and 'bzr diff' shows all file names with '(properties changed: -x to +x)' appended to them
[11:52] <Peng> Is this some fun file system?
[11:52] <geekosopher> the hd partition in question is set to automount by adding a line in fstab file
[11:52] <geekosopher> its vfat
[11:53] <Peng> Lovely.
[11:53] <vila> geekosopher: OS/version/file system involved ? This sounds like the underlying fs doesn't handle the exe bits properly
[11:53] <geekosopher> vila: kubuntu/10.10/vfat
[11:53] <geekosopher> Peng: that sounds like 'no'
[11:53] <geekosopher> *no solution
[11:55] <geekosopher> i tried changing the file system permissions, but either nothing or umask=0*** gives above error
[11:55] <maxb> I seem to recall seeing a bug about this? Yes, it's more or less expected behaviour for bzr on vfat on linux
[11:56] <geekosopher> and anything other than 0** causes inaccessibility
[11:56] <geekosopher> yes, this is typical of bzr only, git is working fine
[11:56] <maxb> Obviously it would be nicer if bzr ignored the modifications, but it's not behaving that unsurprisingly, given the underlying FS *has* modified the perms from what was in the repository
[11:57] <geekosopher> explicitly doing chmod is not working either
[11:57] <geekosopher> like 'chmod -x <repo directory>
[12:00] <maxb> Well, no, it wouldn't. The vfat fs is incapable of storing permission information.
[12:01] <geekosopher> >.<
[12:02]  * geekosopher wondering how bzr works on windows
[12:08] <geekosopher> oh yes, windows wouldn't even have permissions stuff
[12:10] <Peng> Windows has the execute bit, which is all Bazaar tracks.
[12:10] <geekosopher> hmm
[12:24] <vila> geekosopher: not to mention symlinks...
[12:27] <Mez> is there anywhere a good into ro using bzrlib?  I want to create a quick script that emails people about uncommitted changes in their branches.  But would prefer to do it using bzrlib rather than system calls.
[12:35] <jam> hey vila, I haven't gotten a chance to /wave at you in your timezone yet :)
[12:36] <vila> jam: hey !!!
[12:38] <jelmer> :)
[12:38] <jelmer> 'morning jam, vila
[12:38] <jelmer> vila: welcome back, I hope you had a nice vacation :)
[12:38] <vila> jelmer: wonderful !
[12:39] <jam> well, afternoon here, I hope :)
[12:40] <jam> either that, or I'm *really* confused
[12:41] <jelmer> jam: You're not :)
[12:41] <vila> :)
[12:41] <jelmer> Mez: I don't think there's anything like that, but this should get you started:
[12:42] <jelmer> Mez: from bzrlib.workingtree import WorkingTree; wt = WorkingTree.open("."); changes = wt.changes_from(wt.basis_tree())
[12:43] <Mez> jelmer: yeah - had just found that in the documentation.
[12:43] <Mez> Though for some reason, taht doesn't show files that have been created, but not added.
[12:44] <jelmer> Mez: wt.unknowns() will list those files
[12:44] <jam> geekosopher: on Windows, we know that we can't trust the fs, so we use the executable bit from the basis inventory. We don't have a good way to know that the FS is vfat, AFAIK.
[12:45] <jelmer> jam: We could add a check to see if we can set the executable bit correctly, like we do with case sensitivity
[12:45] <vila> jelmer: +1
[12:45] <jam> jelmer: case sensitivity only has to stat an existing file with a different path
[12:46] <jam> not actually do a mutation operation
[12:46] <jam> like chmod
[12:46] <jam> consider readonly systems
[12:46] <jam> It might be reasonable to check that during update, though
[12:46] <Mez> jelmer: what are delta.unchanged and delta.uncommitted for /
[12:46] <jam> I don't really want to do it on every 'bzr status'
[12:46] <jelmer> jam: fair enough
[12:46] <Mez> sorry, delta.unversioned
[12:46] <jam> Mez: unchanged == files that are versioned that have not changed
[12:46] <jam> only available if you pass include_unchanged
[12:47] <jelmer> jam: Perhaps just a setting in .bzr/checkout/checkout.conf that gets autoset upon checkout creation?
[12:47] <vila> jam: you can't have a wt on a readonly fs and run into the problem geekosopher is mentioning (IIUC)
[12:47] <jam> unversioned are files that exist, but have been marked for removale (such as with 'bzr rm')
[12:47] <jam> vila: I can do the checkout onto vfat, and you can run bzr st
[12:47] <jam> and you'll very likely have the problem
[12:47] <jam> because vfat only has 1 global user and group
[12:47] <jam> for the whole mount
[12:47] <jam> because linux fakes it
[12:47] <vila> jam: but that's not readonly then
[12:48] <jam> vila: it *is* readonly for you
[12:48] <jelmer> jam: We could rely on the fact that vfat always sets +x, and we never normally set it on e.g. .bzr/format, but that is.. dubious
[12:48] <jam> jelmer: right, a setting that gets set during a write operation would be ok for me
[12:48] <jam> jelmer: it doesn't, it sets the files to whatever you set in /etc/fstab
[12:48] <jam> I think the default includes +x
[12:48] <jam> but I often reset it to 0644
[12:48] <jam> because I don't want everything to be +x
[12:48] <jelmer> ah, I didn't realize you could override it
[12:49] <jam> user, group, mode bits are all mount-time flags
[12:49] <vila> jam: right, but that's not what geekosopher is encountering
[12:49] <jam> jelmer: https://code.launchpad.net/~dmitrij.ledkov/bzr-keywords/more-keywords/+merge/23626 are you just proxying for him?
[12:50] <vila> jelmer: the problem with a setting in a conf file is that it won't be updated if the whole tree is copied on a different fs (well, until the next update...)
[12:50] <jam> vila: my point is that there are a lot of remaining edge cases
[12:50] <jam> doing it 1 time during "initialize()" would handle a lot ofthem
[12:50] <jam> doing it during mutating operations would handle most of the rest
[12:50] <jam> so "bzr revert" could detect it.
[12:50] <jelmer> jam: I don't think I follow, I was just commenting on the MP.
[12:51] <jam> jelmer: I got an email "You have been requested to review the proposed merge of ..." with your name on it
[12:51] <jam> I was trying to figure out wether you were proposing it for him, or what
[12:51] <jelmer> jam: ah
[12:51] <jelmer> I added bzr-core as reviewer, as Ian was previously the owner of lp:bzr-keywords
[12:53] <jam> jelmer: https://code.launchpad.net/~jelmer/bzr/blackbox-upgrade-formats/+merge/51297
[12:53] <jam> for that one, I approved, but didn't look too closely
[12:53] <jam> I assume it is the same tests, just switching to knits, and adding one that upgrades from a fake format
[12:54] <jelmer> jam: Yeah, though changing the existing one that tested upgrading from a non-metadir format to a metadir format rather than adding a new one.
[12:55] <vila> jam, jelmer: Except for my huge mail backlog, are there events/decisions I should be aware of ?
[12:55] <jelmer> jam: There were already tests for e.g. just repository format upgrades
[12:55] <jelmer> vila: not that I recall
[12:57] <jam> vila: poolie was gone 2 weeks ago, and is gone again this week, so not a lot of big policy decisions going on
[12:58] <jam> We have a couple "Critical" bugs now, poolie was kind enough to set one and then leave :)
[12:58] <jam> I'll probably work on the repack inventories one soon.
[12:58] <jam> Just trying to finish getting my launchpad+loggerhead stuff flushed out of the pipe, first
[12:58] <vila> ok, thanks for the summary !
[13:20] <jam> jelmer: I'm getting OOPS trying to send email to launchpad. I'll try to submit to you directly.
[13:23] <jelmer> jam: ok
[14:01] <jam> jelmer: I think that is everything except for the repository_vf check_reconcile tests
[14:01] <jam> I'm a bit concerned that while the existing tests may not apply, we *should* still support some sort of reconciliation and checking on those repos.
[14:01] <jam> so it sounds more like some missing abstractions.
[14:07] <jelmer> jam: Thanks!
[14:08]  * maxb grimaces at python-central deprecation notice
[14:08] <maxb> that's going to make PPA builds fun
[14:08] <jelmer> jam: All of our current reconciliation seems specific to VersionedFiles, so while I think reconcilation would apply to e.g. Subversion repositories it would be for completely different issues.
[14:08] <jelmer> maxb: Yeah - for everything except Natty (and Maverick?)
[14:10] <maxb> I wonder if we drop Hardy support once Natty is out. It'll be at partial-EOL state then (server only0
[14:10] <maxb> Still, someone probably still wants bzr core for it
[14:10] <jam> maxb: so is that python-central vs python-support?
[14:11] <maxb> python-central vs. dh_python2
[14:11] <jam> which itself was from python-support way back when
[14:11] <maxb> the latter being something new that I have not learnt about yet
[14:11] <jam> something like dapper
[14:11] <jam> which did, indeed, cause some large headache in its time
[14:12] <jam> lovely we get to revisit them
[14:13] <jelmer> at least we now have a single python module support mechanism rather than 2
[14:28] <kyleN> Hello. I seem to have a lock file on LP that prevents me from pushing a branch. Can anyone assist me?
[14:28] <kyleN> I have tried bzr break-lock locally before pushing and running it with a bzr+ssh:// url to the server branch. still cannot push.
[14:29] <Peng> It's always possible someone really is using the branch, of course.
[14:29] <Peng> If not, "bzr break-lock bzr+ssh://..." should take care of it.
[14:29] <kyleN> it has been locked since Saturday and I think I am the only one working on the branch right now
[14:29] <vila> jam: why is bug #716777 against bzr ? Did you mean loggerhead or history-db instead ?
[14:41] <jam> vila: it should be against loggerhead, yes
[15:38] <jelmer> jam: did you have any thoughts on the per_repository_vf MP?
[15:38] <jelmer> (the one that is a prerequisite for the check_reconcile MP)
[15:38] <jam> (3:00:52 PM) jam: jelmer: I think that is everything except for the repository_vf check_reconcile tests
[15:38] <jam> (3:01:11 PM) jam: I'm a bit concerned that while the existing tests may not apply, we *should* still support some sort of reconciliation and checking on those repos.
[15:38] <jam> (3:01:19 PM) jam: so it sounds more like some missing abstractions.
[15:39] <jam> maybe I missed a patch in there, though
[15:39] <jelmer> jam: I mean https://code.launchpad.net/~jelmer/bzr/per-repository-vf/+merge/51150 rather than https://code.launchpad.net/~jelmer/bzr/per-repository-vf-reconcile/+merge/52283
[15:39] <jam> jelmer: locally, the diff is empty
[15:40] <Peng> /1/6
[15:40] <jam> but seems to be populated in the web ui
[15:40] <Peng> eep
[15:40] <jelmer> Peng: Hi :) Or whatever the proper response to that is :)
[15:41] <Peng> The peroper response is "Peng, learn how to type your aliases properly!"
[15:42] <Peng> Hi, but I was just checkin' IRC before giving the laptop -- and maybe myself -- some sleep. Bye. <3
[15:42] <jelmer> g'night
[15:44] <jam> jelmer: It seems ok, but since you aren't removing any tests, I'm not really sure what it is getting you. Just the precursor to moving stuff over?
[15:44] <jam> the config is all correct
[15:44] <jelmer> jam: It's moving a couple of tests to per_repository_vf, so those will no longer run against bzr-svn/bzr-git/bzr-hg
[15:45] <jam> jelmer: there are no '-' lines that would indicate that
[15:45] <jam> at least, that I can see
[15:45] <jam> certainly it does add some tests
[15:45] <jam> but none are removed from elsewhere to be "moved"
[15:46] <jam> anyway, time to pick up my wife. I *think* things are ok, but I think I also need to think about implications in the long term.
[15:46] <jam> I'm a bit worried about us expecting new functionality is working, only to have the tests not testing against all implementations they should be, etc.
[15:47] <jelmer> jam: Those tests need to be moved rather than copied, I'll update the MP.
[15:47] <jelmer> jam: That's one of the reasons I've added the format attribute tests and made the format attributes default to None, so format implementations explicitly have to indicate whether they support something.
[15:48] <jelmer> I'm not sure what to do about code that relies on functionality that is a part of the VersionedFileRepository API but not of the smaller Repository API, it would be nice to somehow check that sort of thing.
[15:49] <jelmer> s/it would be/I agree it would be/
[16:38] <tgall_foo> users of bzr-git  :  what's the syntax to pull from a branch of a remote repo (IE from other than master)
[16:39] <jelmer> tgall_foo: That's not possible at the moment, as there's no UI in Bazaar for addressing colocated branches
[16:39] <jelmer> It's high on my todo list to finish that work. In the mean time, you can import all branches in a repository using "bzr git-import"
[16:40] <tgall_foo> thanks jelmer
[16:46] <tgall_foo> jelmer, followup,  I guess I was expected bzr git-import then to do an effective bzr branch for all the remote git branches..   after the bzr git-import least down the new refs directory it's empty
[16:46] <jelmer> tgall_foo, it creates workingtree-less branches
[16:46] <jelmer> tgall_foo, try running "bzr log" in one of them
[16:46] <jelmer> tgall_foo, you can pull from them, or create a working tree by running "bzr checkout ."
[16:48] <tgall_foo> thanks jelmer
[17:09] <teamgbc> hey all
[17:09] <jelmer> hi teamgbc
[17:09] <teamgbc> i'm new to bzr
[17:10] <teamgbc> and i want to do something simple, but for i'm having trouble
[17:10] <teamgbc> i got bzr installed on 2 machines.... and one is supposed to be server
[17:10] <teamgbc> but i can't connect ( get a project source) from the server
[17:10] <teamgbc> i'm reading through some documentation, but i'm getting lost in the links
[17:12] <teamgbc> i've gone through the setup tutorial
[17:12] <teamgbc> when i do bzr push --create-prefix sftp://localhost/teamgbc/
[17:13] <teamgbc> i get bzr ERROR not a branch '/home/teamgbc/"
[17:13] <teamgbc> just wondering if there is some tutorial somewhere
[17:13] <teamgbc> that exists for almost complete newbies
[17:14] <jelmer> teamgbc, have you seen http://doc.bazaar.canonical.com/bzr.dev/en/?
[17:15] <teamgbc> i guess i was thinking that i placed the trunk inside var/www
[17:15] <teamgbc> if i, i should be able to access the files via http...
[17:16] <teamgbc> Jelmer, yup i've gone through it a little, and ended up starting it all with bzr explorer
[17:16] <teamgbc> and followed the tutorial for that
[17:17] <teamgbc> i guess i should just start over eh?
[17:25] <jelmer> sorry, distracted there for a bit
[17:25] <jelmer> teamgbc: pushing to sftp://localhost/teamgbc/ will push to /teamgbc on your local machine
[17:25] <teamgbc> so how am I supposed to reach my server then?
[17:26] <teamgbc> i'm going to go back through the initial tutorial and do everything via the command line
[17:26] <teamgbc> then i'll come back if i have issues, better than waste anyone's time
[17:26] <jelmer> teamgbc: well, localhost is your local machine :)
[17:26] <teamgbc> cheers jelmer, much appreciated
[17:26] <teamgbc> sorry
[17:26] <teamgbc> haha
[17:26] <teamgbc> i mean i was trying /<IP_ADDRESS>
[17:27] <teamgbc> which is the server in the local network
[17:27] <jelmer> teamgbc: it'll push to the /teamgbc directory on that machine, are you sure that's where you want to push?
[17:28] <teamgbc> interesting, no, that doesn't make much sense
[17:28] <teamgbc> hah
[17:29] <teamgbc> ok, i'm going to run through the command line tutorial.  I though the GUI would be easy enough to just create the trunk in a specified directory
[17:29] <teamgbc> and then type in that director location in the remote machine
[17:29] <teamgbc> to access the source or  open the remote location
[17:30] <teamgbc> thanks jelmer
[17:45] <dpm> hey jelmer, around?
[17:45] <jelmer> dpm: Hi David
[17:46] <dpm> jelmer, thanks a lot for merging my branch
[17:46] <dpm> I was wondering if you've got a few minutes if we could set up translations in the LP project
[17:46] <jelmer> np, thanks for adding i18n support in the first place
[17:46] <jelmer> dpm: Sure
[17:48] <dpm> ok, cool, so it's basically here -> https://translations.launchpad.net/bzr-gtk/+configure-translations . The first thing is to set permissions, focus, and a couple of other things. My recommendations:
[17:48] <dpm> * Launchpad
[17:48] <dpm> * trunk
[17:48] <dpm> * launchpad-translators
[17:48] <dpm> * Restricted
[17:49] <jelmer> what's the difference between Launchpad and Ubuntu translators?
[17:50] <dpm> The reason I suggest to assign it to the Launchpad Translators group is simply because bzr-gtk is not an Ubuntu-specific project, so Launchpad Translators makes more sense
[17:50] <dpm> they are simply two translation groups
[17:50] <dpm> a translation group contains translation teams, one per language
[17:50] <dpm> and they take care of translating particular projects
[17:51] <dpm> Launchpad Translators is an umbrella for translating any project hosted in Launchpad for translation
[17:51] <jelmer> ah, ok
[17:51] <dpm> Ubuntu Translators, the same, but for any project specific to Ubuntu, or for the distro itself
[17:51] <jelmer> Thanks - I've configured that page with the settings you suggested
[17:52] <dpm> cool, let me see what the next step is, probably translation imports
[17:53] <dpm> ah, yeah, imports for the trunk branch
[17:54] <dpm> So here: https://translations.launchpad.net/bzr-gtk/trunk/+translations-settings I'd suggest simply choosing "Import template files"
[17:55] <dpm> That will import the bzr-gtk.pot template in the branch and expose it in the UI every time you update it and commit it
[17:56] <dpm> I'd also recommend updating it and committing it at least a few days before a release, so that translators see the latest strings and have time to translate it
[17:56] <dpm> (but that's got nothing to do with the settings, just a suggestion)
[17:58] <jelmer> dpm: done
[17:58] <dpm> cool thanks, so now for the final step: automatic exports, to get translations committed automatically to a branch of your choice
[18:01] <dpm> You simply have to choose the branch where you want them committed here: https://translations.launchpad.net/bzr-gtk/trunk/+link-translations-branch - you can have a separate branch (if you want to keep it separate and merge it back to trunk regularly) or the main branch (if you just want to let LP do the right thing and forget about committing translations, and if you don't mind having automatic commits in the tree)
[18:02] <dpm> * A caveat: you might hit bug 407260 when trying to choose the branch, but it's got an easy workaround: "At the moment, team-owned branches don't work as expected. To work around this, make yourself the owner of the branch, set it as the translations branch, and then make the team the owner of the branch again."
[18:04] <jelmer> hmm
[18:04] <jelmer> for the moment I'm more comfortable with a separate branch
[18:05] <dpm> sure, just laying out the options. You should choose the workflow that best suit your needs
[18:05] <dpm> suits
[18:05] <jelmer> dpm: Cool - set
[18:05] <dpm> then I think we're all done \o/
[18:05] <dpm> I'll be testing it in the next few days, thanks!
[18:06] <jelmer> you - thanks for adding i18n support to bzr-gtk :)
[18:06] <jelmer> s/you/you too/
[18:06] <dpm> no worries, my pleasure :)
[18:07] <jelmer> dpm: I guess it's still an issue that bzr itself doesn't support i18n? I.e. errors and warnings may come directly from bzr
[18:08] <dpm> oh, yeah, I hadn't thought of that. I'd be happy to help on that as well, but I'm not sure there are any plans to i18n'ize bzr?
[18:09] <dpm> Has this ever been discussed at all?
[18:09] <jelmer> I'm not aware of any. There's an open bug somewhere..
[18:09] <dpm> At least SVN is internationalized, we could aim to beat that as well :)
[18:10] <jelmer> https://bugs.launchpad.net/bzr/+bug/83941
[18:10] <jelmer> with a comment from myself from 2007 :)
[18:11] <jelmer> it's been discussed offline a couple of times. From what I recall the main concern is that adding i18n support should not have a performance impact
[18:13] <jelmer> blindly gettexting all strings that might be user visible will add a significant overhead, as some of those get raised pretty often but are then not shown to the user
[18:13] <jelmer> it's not impossible but needs some thought
[18:13] <dpm> yeah, that's what I thought that'd be the main concern. AFAIK, gettext is really fast, so I don't think it should incur a performance drop, but only tests can tell
[18:15] <dpm> well, I'll be happy to have a go at it and submit a MP for i18n'izing bzr itself, and then you guys can have a look.
[18:15] <jelmer> that'd be awesome
[18:15] <dpm> I don't know when though, but I'll definitely look into it
[18:38] <vanguard> is there some way to save push/merge locations with a name like "origin" like one can in git?
[18:39] <jelmer> I think the bzr-bookmarks plugin is intended to work like that
[18:50] <vanguard> jelmer: k, I'll check it out
[19:42] <vanguard> can I check out some revision without loosing everything after that revison?
[19:45] <maxb> sure
[19:49] <LeoNerd> The version that a checkout is at doesn't have to be the head revision in a branch...
[19:51] <vanguard> LeoNerd: So I do it the same way as in git, with a checkout command?
[19:52] <LeoNerd> bzr co -r123
[19:52]  * LeoNerd dosen't know git
[19:52] <LeoNerd> I find it odd... people in here asking abuot git, people in #vim asking about emacs...
[19:53] <LeoNerd> You can't just presume that people in #{$TOOL} would understand references to $OTHERTOOL  :)
[20:01] <vanguard> LeoNerd: People asked about some distro in #kubuntu ... that is the way it works. And where should I go if I want to get optinions from people who have experience with bzr and git?
[20:02] <LeoNerd> Ah, well one -and- the other, is a different problem again
[20:49] <jasonlife> How can I update my module to a old revision ?  "bzr update -r xxx" doesn't work..
[20:50] <maxb> jasonlife: doesn't work?
[20:50] <jasonlife> yes..
[20:50] <maxb> explain
[20:50] <jasonlife> after I do this, I just checked revno, but it is still same..
[20:51] <jasonlife> "bzr  revno" show the same as before
[20:51] <jasonlife> and bzr log shows all the logs too..
[20:51] <maxb> please pastebin a transcript of the commands and responses
[20:52] <jasonlife> maxb: so, "bzr update -r xxx" should work.. right?
[20:52] <maxb> yrs, it should
[20:52] <maxb> yes, even
[20:52] <jasonlife> I will try this again and I will paste them again..
[20:52] <jasonlife> ok.. thanks..
[20:52] <maxb> though it's a relatively new feature
[20:53] <maxb> what is your bzr version?
[20:53] <jasonlife> oh
[20:54] <jasonlife> 2.1.0
[20:54] <mtaylor> given two branch urls, is there an _easy_ way to determine if one is contained within another?
[20:55] <jasonlife> "bzr --version" shows 2.1.0
[20:58] <jasonlife> it happens on both 2.1.0 and 2.1.1
[20:59] <jasonlife> when I run "bzr update -r xxx" , it actually revert the files to old revision, but "bzr revno" and "bzr log" shows the current revno and logs..
[21:38] <knighthawk> help I'm trying to prevent having to go back to svn. My team has been adapting pretty well to bzr however we have 3 party programmers who aren't used to bazaar and are running into major problems. at the heart of my problems is that they are using eclipse and the eclipse plugin doesn't seem to work all that well.
[21:39] <knighthawk> I guess I'm looking for idea's on the best way to handle this. (I don't want to go backwards) but I may have to set something up so that the 3rd party can use subversion. I keep hearing about a svn-bzr bridge will this help me any?
[22:03] <knighthawk> how hard is it to move a bzr repo over to hg?
[22:04] <beuno_> knighthawk, pretty easy
[22:04] <beuno_> there's a bzr-hs plugin
[22:04] <beuno_> *bzr-hg
[22:04] <beuno_> and there's fastimport, which is probablt best for a one-time import
[22:06] <knighthawk> thanks. I don't really know hg but it looks like if I switch now. I might be able to keep all the things I like about bzr and use their eclipse plugin.
[22:06] <jelmer> bzr-hg isn't really useful for bzr->hg, only for hg->bzr
[22:34] <fullermd> jasonlife: 'bzr revno' shows the revno of the _branch_; 'update' affects the _working tree_.  Try 'bzr revno --tree'.
[22:46] <jasonlife> fullermd: thank you very much
[23:25] <jelmer> lifeless: hi
[23:25] <lifeless> hi
[23:26] <jelmer> lifeless: I've been meaning to move get_{branch,workingtree,repository}_transport from ControlDir to BzrDir, as they don't really make sense for foreign formats.
[23:27] <jelmer> lifeless: Do you think that would that make sense? John mentioned you might have had another goal with them other than using them for metadir component initialization / opening.
[23:27] <lifeless> I have no idea
[23:28] <lifeless> check plugins all work as part of your pre-proposal-qa, and I'm sure you'll find any issues
[23:29] <jelmer> lifeless: of course