[00:06] <persia> kklimonda, So, we use a namespace on IRC.  We say that a nick identifies a person.
[00:06] <persia> So a nick is really an IPI (IRC Person Identifier)
[00:06] <persia> Similarly, a URI is a Universal Resource Identifier.
[00:07] <persia> And so should not be able to exist without there being a Resource behind it.
[00:07] <kklimonda> so your question is "what does really magnet identify?"
[00:07] <persia> I don't care, but I believe the answer to that question is required in order to use MIME handling, and that without that answer, magnet: is abusing the semantics of URI.
[00:14] <kklimonda> mhm, makes sense. and yeah, I know you don't care about it, I used this figure of speach as a shortcut of sort. I guess the problem is mime-type is not the right right way of doing that.. but KDE's way has its own problems. So we end up with something that is ugly but works.
[00:17] <persia> KDE's is cleaner than Bastien's
[00:18] <persia> Doing it right is extra complicated, and requires writing a bundle of code and migrating all the legacy applications.
[00:18] <persia> But if you can define the nature of the resource, you can then construct a file/stream/whatever that matches, and then have a MIME type for that resource, and things ought just work without too many hacks.
[00:23] <kklimonda> persia: then I can only assume that magnet is abusing uri specification because not all magnet uris can be translated into resources (by resource I mean for example a torrent file you download knowing its hash). Some hashes are just used by p2p clients to ask all peers whether they have the file in question or do they know anyone who has it.
[00:24] <persia> kklimonda, That's why I asked if the resource was a hash.
[00:25] <persia> And remember my "Moby Dick" example: there's no reason a URI can't supply multiple formats (although only a subset may be available for any given resource).
[07:15] <simar> persia, hi
[07:15] <simar> persia, remember
[07:23] <napster> Hello friends
[07:23] <napster> I would like to contribute to ubuntu-natty-gnomeutils-gnomescreenshot project
[07:23] <napster> How can I do that?
[07:24] <persia> simar, Yes.
[07:24] <persia> napster, Where did you get the name of that project?
[07:24] <napster> How to get a branch for natty/ubunu-utils?
[07:24] <napster> persia: https://launchpad.net/ubuntu/natty/+source/gnome-utils
[07:26] <persia> napster, What are you trying to do?
[07:26] <napster> persia: I would like to change the way screeshot program names files while saving
[07:26] <persia> Ah, OK.
[07:27] <persia> napster, So, there's two ways to do this: best is to work on http://live.gnome.org/GnomeUtils upstream: anything in the next release *will* be part of Natty.
[07:28] <napster> persia: And the other way?
[07:28] <simar> persia, How can I contribute to the development release, natty, without getting into merging and syncs .. I mean what are the other ways to contribute?
[07:28] <persia> Second best is to work with the folks in #ubuntu-desktop to get a local patch in Ubuntu.  I don't suspect you'll have much luck with this, as that team really doesn't like patches unless upstream is ignoring them for some reason.
[07:29] <persia> simar, There's a few things that would be great just now.  Fixing some of the bugs.  Working on UEHS to get stuff not in Debian up-to-date.  Cleaning up old Ubuntu-local source packages.
[07:29] <napster> persia: OK, thank you
[07:29] <persia> simar, And more work on FTBFS is always good.
[07:30] <simar> persia, but I think FTBFS, havn't come up for natty yet?
[07:30] <simar> UEHS?
[07:31] <persia> http://qa.ubuntuwire.com/ftbfs/ shows a couple hundred
[07:31] <persia> http://qa.ubuntuwire.com/uehs/ are packages not maintained in Debian, many of which need to be reviewed to either be updated to newer upstream or removed from Ubuntu.
[07:36] <simar> persia, so for UESH, should we get these packages into debian..
[07:36] <persia> Maybe, but probably not now, as squeeze is freezing.
[07:37] <persia> Better to just check for new upstreams, update the packaging, check for bugs and close as many as you can, check other distributions to see if anyone else has cool patches we want, and upload.
[07:38] <persia> Note that lots of UEHS stuff is already in Debian, but just doesn't have a maintainer there.
[07:39] <simar> persia, ok fine, but how to get started i don't know.. But I know somewhat about fixing FTBFS. Should I get to them first?
[07:40] <persia> simar, Sounds like a reasonable plan.  I think it's best to do what you know first, and do what you don't know as you get annoyed enough to learn.
[07:40] <persia> So someone like you should concentrate on FTBFS because you know it, and not worry about new shiny upstream stuff until there's some feature you simply cannot do without that needs one, giving you motivation to learn.
[07:41] <persia> Or one of your FTBFS uploads ends up causing a merge, at which point you have to merge your work, etc.
[07:42] <simar> persia, :)) , ya i get that,  are all these FTBFS for natty ?
[07:42] <simar> persia, ah! the are
[07:42] <persia> On the natty page, yes.
[07:43] <simar> persia, thanks .. then i have the pbuilder for natty and i will get started now ..
[07:43] <persia> And thanks a lot for working on them.  Just because they are easy for you, don't think they are easy for other folk (I find them fairly hard, myself).
[07:45] <simar> persia, perhaps not easy for me either .... last time i had a taste that was bitter that ever.. haha
[07:46] <simar> persia, Infact this is a problem .. I don't know how to choose easy ones. Is there a way out?
[07:46] <persia> My general attitude towards picking things is to look for things that aren't too hard, and then do them.  If they look really hard, I look for something else until there's only the ones I find hard left.
[07:55] <simar> persia, so you say, pick randomly and then look into them and analyse them .. if you can handle them..
[07:56] <simar> persia, i think this is a simple one..
[07:56] <simar> https://launchpad.net/ubuntu/+source/tea
[08:01] <simar> persia, i think this is a simple one.
[08:01] <simar> https://launchpad.net/ubuntu/+source/tea
[08:02] <dholbach> Good morning!
[08:02] <simar> dholbach, same to you  :))
[08:02] <dholbach> hi simar
[08:03] <simar> dholbach, hi
[08:03] <simar> dholbach, actually I was looking forward to fix some FTBFS before getting on to merging..
[08:04] <persia> simar, I suspect you're right.  Looks like the sort of thing mentioned in the natty open announcement.
[08:05] <simar> natty open announcement?? how to see that
[08:07] <persia> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-October/000772.html
[08:13] <simar> persia, i have subscribed to natty-changes
[08:14] <simar> persia, I make a note of gcc4.5
[08:16] <simar> persia, as well as to ubuntu-devel-announce
[08:39] <simar> Does anyone here knows how to install a pbuilder for natty in karmic
[08:40] <persia> You probably want to upgrade to at least lucid to get the snazzy tools.
[08:40] <persia> That said, you'll either have to install backports, or make a slightly updated pbuilder, and dist-upgrade it.
[08:42] <dholbach> maybe backport debootstrap yourself (karmic only has 1.0.20), then use pbuilder-dist from ubuntu-dev-tools?
[08:43] <simar> persia, my display goes totally off in lucid and higher . due to incorrect EDID ..
[08:43] <simar> dholbach, what does backport debootstrap yourself means
[08:44] <simar> otherwise i tried using
[08:44] <persia> Newer debootstrap probably runs on older installs fine, although rebuilding from source isn't that hard.
[08:44] <simar> sudo pbuilder create
[08:44] <dholbach> on the karmich machine: dget -xu https://launchpad.net/ubuntu/+archive/primary/+files/debootstrap_1.0.25.dsc; cd debootstrap-1.0.25; debuild && sudo debi
[08:44] <simar> sudo pbuilder update distribution natty ...
[08:45] <dholbach> simar, and then   pbuilder-dist natty create
[08:46] <simar> all this I have do without uninstalling the previous pbuilder tarball
[08:46] <persia> Well, you want the karmic one to do the backport, really.
[08:47] <persia> Also, you may want to devote some time to tracking down the EDID issue: karmic will be unsupported soon, and you'll want to be able to upgrade.
[08:47] <tumbleweed> I doubt you need a newer debootstrap. Ubuntu has been using the same rules since gutsy. I just "ln -s natty gutsy" (I have my pbuilders on debian boxes)
[08:47] <persia> Lots to learn if you chase EDID, but worst case, there's ways to hardcode around it.
[08:47] <persia> tumbleweed, the newer debootstraps have the symlink predefined, and have little workarounds for stuff like installing the mailserver, etc.
[08:48] <tumbleweed> persia: right. Anyway getting past karmic is highly recommended :)
[08:48]  * persia has one machine still sadly stuck on jaunty, and is *really* hoping to get it upgraded in the next week.
[09:13] <simar> persia, i want to fix that EDID thing .. I have also filed a bug in this regard. Could you help me in doing that//
[09:16] <simar> persia, i think this has some relation to my problem https://blueprints.edge.launchpad.net/ubuntu/+spec/hardware-desktop-n-xorg-configuration-the-final-ten-percent
[09:21] <persia> simar, Most undoubtably :)  Can't you do something with xorg.conf to work around that?
[09:22] <simar> persia, It works in karmic but does not work in lucid may be due to nouveau..
[09:23] <persia> Probably needs a slightly different xorg.conf
[09:24] <simar> persia, Also if I install nvidia drivers in karmic for 3d, still i have blank display. But yes I can fix that using a EDID information exported from windows but then I can't switch my VT using Ctrl+alt+f2..
[09:25] <simar> persia, I have to configure to use the exported EDID in xorg.conf
[09:29] <simar> persia, also I can't change my display brightness in ubuntu. I can see the indicator moving but nothing happens
[09:30] <persia> Sure.  It's a bug.  Only you can balance the bug against having more recent development tools.
[09:32] <simar> persia,  Only you can balance the bug against having more recent development tools. .. i did't get this ..
[09:33] <simar> persia, I see, i'm a very beginner in ubuntu after meeting you.. :((
[09:33] <persia>  It's up to you.  I'd probably try to upgrade anyway, and deal with the brightness issue.  You have to decide whether it's more important to have limited X or to have newer tools.
[09:36] <simar> persia, I too would like to upgrade but have no idea where this EDID information comes from and what to explore but I hope i can learn that, I have been working in input subsystem(touchpad in general) so I know somewhat about debugging X.. and kernel.)
[09:36] <simar> persia, I have also written some documentation work like https://wiki.ubuntu.com/DebuggingTouchpadDetection
[09:37] <simar> persia, I hope you can give me a start like telling me the package name
[09:37] <persia> I don't know enough about it to help you with that.
[09:39] <simar> persia, ok.. :((
[09:56] <simar> persia, I will work myself, on this first. So that I can upgrade to Maverick, using pen drive live installations
[09:57] <simar> persia, Is using pen drive live installation a good idea to test this problem or there is a better idea??
[09:58] <simar> persia, I mean display going completely off at boot time... I don't to spoil my current installation..
[11:42] <ara> Once I proposed a merge on a new upstream upload (I am waiting for sponsorship), shall I mark this as Fix Committed? bug 662583
[11:46] <tumbleweed> ara: no, sponsors tend to look at bugs marked New or Confirmed. https://wiki.ubuntu.com/Bugs/Status Although in this case it's a bzr merge proposal, so sponsors won't even see the bug.
[11:49] <ara> tumbleweed, but they will see the merge proposal, won't they?
[11:52] <tumbleweed> ara: it should show up here on the next update: http://reports.qa.ubuntu.com/reports/sponsoring/
[11:53] <ara> tumbleweed, OK, thanks
[13:38] <micahg> ara: no, Confirmed is the correct status for Merge requests
[14:11] <micahg> are we supposed to accept the deb src 3.0 patch name and headers or make an appropriate patch name and add/delete dep-3 headers as appropriate?
[14:40] <ScottK> micahg: It's better to do the latter.
[14:40] <Rhonda> The later, the former is just an effort to offer something useful, more a template.
[14:41] <Rhonda> And I guess you edit the template debhelper files in debian/ after dh_make too, right? ;)
[16:03] <till_> anyone have time to answer a short maintainer q? (debhelper related)
[16:07] <ximion_> till_: Just ask :P (maybe I can answer it)
[16:07] <Rhonda> Noone can answer your question if you don't ask it.
[16:08] <till_> :D
[16:08] <till_> ok, so basically, i'm using override_dh_auto_configure in my debian/rules
[16:08] <till_> when i do, "dh_auto_configure -- --my-opts"
[16:08] <till_> it doesn't really override, but append
[16:09] <till_> is the only solution to do, ./configure --my-opts there?
[16:15] <ximion_> till_: What do you want to archive?
[16:15] <ximion_> never call ./configure directly in debian/rules, it just causes pain.
[16:16] <ximion_> if you call dh_auto_configure -- <flags> the flags get appendet to the ./configure call - why do you want to leave out the default options?
[16:19] <till_> ximion: well, they don't make sense for me
[16:19] <ximion> till_: why?
[16:19] <till_> e.g., it assumes a prefix i don't want
[16:19] <till_> i could probably override prefix
[16:19] <till_> let me check this
[16:21] <ximion> till_: You mean prefi=/usr ? This is a necessary option to make make install install all files to currect destinations
[16:21] <till_> i want /usr/local though
[16:21] <ximion> also all libexec and other prefixes are set automagically to follow the packaging guidelines
[16:21] <till_> don't seem to be able to change that
[16:22] <ximion> till_: Why do you want this strange, policy-incompliant behavior?
[16:22] <till_> ximion: a lot of other related resides in /usr/local etc.
[16:22] <till_> i wanted to keep it close
[16:23] <till_> besides, i didn't want my package to conflict with the regular package
[16:23] <Rhonda> till_: Debian packages though don't install to /usr/local, so if you override that the package clearly won't be included in Ubuntu or Debian.
[16:24] <ximion> till_: Prefix always should be /usr, otherwise it won't be included into any distro
[16:24] <till_> that's not a problem
[16:24] <ximion> yep ^^
[16:24] <ScottK> If you aren't working on a package intended for Ubuntu, #ubuntu-packaging is a better channel.
[16:24] <till_> i'm just trying to create a custom .deb
[16:24] <ximion> If you want to avoid conflicts with existing software, install into /opt
[16:24] <till_> how do i set the prefix to /opt ?
[16:24] <Rhonda> And for installint to /usr/local you maybe want to do it without packaging, or use something like checkinstall or stash.
[16:25] <till_> tried checkinstall already
[16:25] <till_> i wanted something that can track dependencies ;)
[16:25] <Rhonda> This channel though is like ScottK pointed out for packaging work that is meant to go into the distribution.
[16:25] <ScottK> It's off topic for this channel in any case.
[16:26] <ximion> till_: Okay. You will need to run ./configure manually then.
[16:26] <till_> ximion: thanks :)
[16:26] <till_> appreciate the help, none the less
[16:27] <ximion> apropos packages which go into distributions ^^
[16:28] <ximion> (now I have a question)
[16:30] <ximion> I packaged "packagekit" for Debian, the package was reviewed three times and considered as really good, but no DD had enough time to sponsor it... As Ubuntu/Kubuntu uses PK, it would be nice for Ubuntu to have this in Debian too.
[16:30] <ximion> Is anyone interested in sponsoring this package for Debian?
[16:30] <ximion> and if not, can I merge the Ubuntu changes into my package and suggest it for Natty?
[16:31] <Rhonda> You might want to ask in #debian-ubuntu on OFTC network. :)
[16:32] <ximion> Rhonda: Thanks, I'll try :)
[19:00] <RoAkSoAx> jcastro: ping
[19:41] <xteejx> Hi all, what's the procedure for fixing FTBFS packages?
[19:41] <xteejx> I'm relatively new to it and trying apparmor
[19:48] <ScottK> xteejx: That's probably not a good one to start with.  It actually needs a kernel fix.
[19:49] <ScottK> xteejx: I'd recommend starting with Universe packages since that's what we tend to focus on here.
[19:49] <ScottK> http://qa.ubuntuwire.com/ftbfs/#universe
[19:49] <xteejx> Oops hehe thougth I was on universe :)
[19:59] <xteejx> I've seen this in a couple of ftbfs build logs: "collect2: ld returned 1 exit status"
[19:59] <xteejx> Is there a known problem or workaround?
[19:59] <azeem_> it's a summary, the error is earlier
[19:59] <azeem_> it means linking failed
[19:59] <xteejx> the new gcc?
[20:00] <azeem_> hrm?
[20:01] <xteejx> It's the ftbfs of zvbi I'm looking at
[20:01] <azeem_> so what is the error?
[20:02] <xteejx> It could be the second line "sh: gcc: not found" and then it reverts to native compile
[20:02] <azeem_> sounds possible
[20:03] <xteejx> Anyone able to walk me through this one so I can learn?
[20:03] <xteejx> please :)
[20:05] <ScottK> xteejx: What package is it?
[20:05] <ScottK> Ah.  zvbi
[20:05] <xteejx> yeah scott :)
[20:06] <ScottK> ../src/.libs/libzvbi.so: undefined reference to `S_ISCHR' is the actual error.
[20:07] <xteejx> I see it, in proxyd.c
[20:07] <ScottK> So the trick is to figure out what library provides that symbol and add it to build-depends if it's missing or add it to the linker flags if it's already present, but not found.
[20:07] <azeem_> looks like a macro to me
[20:08] <ScottK> OK.
[20:08] <ScottK> azeem_: I'm about 98% sure you understand this one better than me.
[20:08] <azeem_> hrm
[20:08] <azeem_> I'm not :)
[20:08] <ScottK> Please carry on ...
[20:08] <xteejx> i'm 100% that everyone here undertsnads it ALL better than me :P
[20:10] <azeem_> it's a V4L thing
[20:10] <xteejx> vlc came up a lot on google
[20:10] <ScottK> http://launchpadlibrarian.net/57799542/buildlog_ubuntu-natty-i386.tiled-qt_0.5.1-1_FAILEDTOBUILD.txt.gz is an example of missing LDFLAGS.
[20:11] <xteejx> /usr/bin/ld ... undefined reference ?
[20:12] <azeem_> xteejx: S_ISCHR i used in the source code (and referenced in one of the included header files), but none of the libraries which get linked in provide it
[20:12] <azeem_> -> undefined referenced
[20:12] <azeem_> reference*
[20:15] <xteejx> azeem_: I don't understand
[20:15] <xteejx> I'm kinda new to this kinda stuff
[20:24] <xteejx> Ok, it looks like sys/stat.h is missing but not quite sure where that should go
[20:54] <xteejyx> How do you go about fixing linker errors? i.e. undefined reference to symbol XXXX?
[20:54] <xteejyx> It's a FTBFS package
[20:55] <azeem_> I don't think there's a recipe
[20:55] <xteejyx> the build log says "try adding it to the linker command line" but I'm not quite sure what that means can someone explain it?
[20:56] <azeem_> are you still looking at zvbi?
[20:56] <xteejyx> No I gave up on it, now on wwwoffle
[20:56] <xteejyx> It seems more understandable to me
[20:56] <azeem_> ok
[20:57] <azeem_> then figure out which library package ships the XXXX symbol
[20:57] <azeem_> sometimes it's enough to just add it to the Build-Depends
[20:57] <xteejyx> it's libgcrypt11, but it's alredy in the build-deps
[20:57] <xteejyx> well -dev
[20:58] <tumbleweed> azeem_: this looks like a binutils-gold issue, so it'll need -lgcrypt (or something like that)
[20:58] <azeem_> ok
[20:58] <xteejyx> Is that added to the debian/control file? is it control
[20:59] <xteejyx> rules even
[20:59] <xteejyx> sorry, half asleep here :)
[21:00] <geser> xteejyx: upstream Makefile
[21:00] <xteejyx> geser: Thanks :)
[21:01] <tumbleweed> xteejyx: looks like that'll do the trick. Don't forget to forward the patch upstream :)
[21:02] <xteejyx> So add -lgcrypt to the end to make "install : compile -lgcrypt" ?
[21:02] <xteejyx> in Makefile.in
[21:02] <azeem_> no, to the linker line
[21:02] <azeem_> usually the variable i called LDFLAGS
[21:02] <azeem_> or LIBS
[21:03] <xteejyx> there isn't any :S
[21:03] <xteejyx> But I'v learnt what LDFLAGS is now at least, makes a lot of sense
[21:04] <xteejyx> There is "LIBS="$LIBS $ETR_SOCKET_LIBS"" in line 48 of configure.in ... ?
[21:05] <azeem_> it's hard to say where the correct place for the addition is without looking at the source
[21:05] <azeem_> does it use automake?
[21:06] <xteejyx> azeem_: it does
[21:07] <geser> xteejyx: you might need to check how the software checks for other libs and see if you can adapt it for the missing library too
[21:07] <xteejyx> I'm looking around for those strings $LIBS, maybe in an include somewhere
[21:09] <geser> it might not be necessarily $LIBS in the Makefile.am
[21:09] <xteejyx> I'm looking at configure.in
[21:09] <tumbleweed> xteejyx: as gcrypt is a dependancy of gnutls, how about getting it to add it to th elibs it links with for gnutls?
[21:10] <xteejyx> That means absolutely nothing to me, sorry :(
[21:10] <tumbleweed> also, doesn't look like this package regenerates configure from configure.in
[21:10] <xteejyx> I thought that, since it's already there, but...
[21:11] <tumbleweed> you'll see what I mean when you find the bit I'm talking about
[21:11] <xteejyx> I found ac_subst_vars=<insert loads of stuff here> - it include those strings
[21:12] <xteejyx> s/include/includes
[21:12] <tumbleweed> xteejyx: hint, look for -lgnutls
[21:13] <tumbleweed> alternatively, you can probably provide it to configure in debian/rules (which is a smaller change, but less upstreamable)
[21:14] <xteejyx> I see line 4525 in configure
[21:14] <xteejyx> Looks like a place I could slot a -command in
[21:14] <xteejyx> I *think*
[21:14] <xteejyx> -option even
[21:15] <xteejyx> tumbleweed: Would that work? ^^
[21:16] <tumbleweed> xteejyx: I was thinking more like 4493, but didn't test that
[21:16] <tumbleweed> xteejyx: you asking me? How about a test build :P
[21:16] <xteejyx> I'm tired..that's my excuse and I'm sticking to it ;)
[21:17] <xteejyx> -lgcrypt is it?
[21:21] <xteejyx> what's the debuild option I forgot
[21:21] <alkisg> Hi, how can I tell `debuild -S -sa` to exclude by .bzr directory? `DH_ALWAYS_EXCLUDE=.bzr debuild -S -sa` doesn't exclude it from the .tar.gz file..
[21:22] <alkisg> (so I end up uploading 2.5 Mb to launchpad instead of some Kb)
[21:22] <micahg> alkisg: try using bzr-builddeb
[21:22] <xteejyx> tumbleweed: ok I did debuild -S I'm really stumped now..brain freeze
[21:22] <alkisg> micahg: ty, trying...
[21:23] <xteejyx> micahg: How do I build? I've done debuild -S forgot what the next one was
[21:23] <azeem_> debuild -S builds a source package
[21:24] <azeem_> check the debuild documentation or --help output
[21:24] <tumbleweed> xteejyx: now you feed the .dsc to a natty pbuilder / sbuild (but maybe I was leading you down the wrong path here, my test failed)
[21:24] <micahg> xteejyx: that makes a source package, you can then use that in pbuilder
[21:24] <xteejyx> pbuilder with .dsc that sit
[21:24] <xteejyx> thanks micahg
[21:24] <micahg> xteejyx: tumbleweed beat me by a second :)
[21:25] <xteejyx> thanks tumbleweed as well I just saw your message, but no point building it lol
[21:25] <tumbleweed> err I made a typo
[21:26] <xteejyx> tumbleweed: How so?
[21:27] <tumbleweed> xteejyx: in my test. Keep working on it, and I'll see what I did wrong
[21:27] <xteejyx> It is -lgcrypt isn't it?
[21:31] <tumbleweed> xteejyx: yes
[21:32] <xteejyx> ok :)
[21:32] <xteejyx> just create pbuilder and then build dsc
[21:34] <xteejyx> *creating
[21:36] <alkisg> I didn't manage to exclude the .bzr directory from the tar.gz file by using bzr-buildpackage, any other hints welcome :)
[21:37] <micahg> alkisg: bzr bd --builder 'debuild -S -sa'
[21:37]  * tumbleweed does bzr bd -S -- -sa
[21:38] <micahg> ah, that's probably the shorthand :)
[21:39] <alkisg> Thank you guys, that worked fine :)
[21:41] <micahg> tumbleweed: you have time to sponsor something?
[21:46] <tumbleweed> micahg: yeah
[21:52] <micahg> tumbleweed: bug 634798, thanks
[22:00] <tumbleweed> micahg: still going to sort out those gjs SRUs?
[22:02] <micahg> tumbleweed: yeah, I should do that tonight
[22:02] <tumbleweed> :)
[22:21] <xteejyx> In natty I tried to run "sudo pbuilder create" and I got this at the end "W: Failure trying to run: chroot /var/cache/pbuilder/build/16738/. dpkg --force-overwrite --force-confold --skip-same-version --install" - it downloaded installed and configured and then done that
[22:27] <tumbleweed> xteejyx: sorry no idea. (you don't need a natty host to pbuild with natty)
[22:28] <xteejyx> tumbleweed: I'm in vbox with natty installed, is there something other than pbuilder to use for now?
[22:28] <tumbleweed> yeah if you have a natty box, just build it in there
[22:29] <tumbleweed> there's also PPAs
[22:29] <xteejyx> that's where I'm having the pbuilder problem
[22:29] <xteejyx> sudo pbuilder create is right isn't it? no extra options needed?
[22:29] <tumbleweed> no I mean just build outside the pbuilder
[22:30] <xteejyx> how?
[22:31] <tumbleweed> xteejyx: debuild -uc -us ?
[22:31] <xteejyx> Ahh ok :)
[22:32] <xteejyx> So many commands it's hard to remember all of them
[22:34] <ari-tczew> pbuilder-dist ?
[22:34] <xteejyx> I'll try that in a minute, for now normal debuild -us -uc is working
[22:37] <xteejyx> ftbfs wwwoffle - I tried adding -lgcrypt, didn't work, -libgcrypt appears to and actually gets past certificates.*, but new problem comes up:
[22:37] <xteejyx> wwwoffle-checkcert.c:48:33: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘LoadPrivateKey’
[22:37] <xteejyx> I think I'm gonna give up on this one as well lol
[22:40] <tumbleweed> xteejyx: did you use quotes like this?: GNUTLS_LIB="-lgnutls -lgcrypt"
[22:43] <xteejyx> tumbleweed: I actually put it in line 4525 to make LIBS="-lgnutls -libgcrypt $GNUTLS_LIB $LIBS"
[22:43] <xteejyx> and lgcrypt I tried
[22:43] <xteejyx> neither worked
[22:44] <xteejyx> but that should still have worked
[22:45] <tumbleweed> xteejyx: worked-for-me: http://pastebin.com/Lih6MrhF
[22:46] <xteejyx> thats where I've messed up then. How come it couldn't go where I put it?
[22:48] <tumbleweed> xteejyx: what does the line before that one do?
[22:49] <xteejyx> ac_check_lib_save_LIBS=$LIBS  checks libraries? I dunno
[22:49] <tumbleweed> xteejyx: (look at line 4551)
[22:50] <xteejyx> d'oh
[22:50] <xteejyx> Yeah I see that now :) stupid me
[22:51] <xteejyx> tumbleweed: I take it you've diffed this one up etc? Any problems with me leaving this one if you've done it?
[22:52] <tumbleweed> xteejyx: you're welcome to it. Please pass the bug upstream
[22:53] <xteejyx> tumbleweed: Ok :) Thank you for all the help, and the nudges to get me to learn myself - much prefer that to just answers
[22:53] <tumbleweed> xteejyx: yeah, I learn more by diving in the deep end and working out what's going on, but it can be hard :)
[22:54] <xteejyx> tumbleweed: Much the same with me, learn the hard way, but it gets results...eventually :)
[23:20] <xteejyx> bug 662986 does this look ok?
[23:20] <xteejyx> tumbleweed: ? ^^
[23:21] <tumbleweed> xteejyx: we use debdiffs for sponsorship, not complete source packages
[23:21] <xteejyx> oops :) ill fix it in a bit
[23:22] <tumbleweed> xteejyx: the changelog entry isn't very descriptive
[23:23] <xteejyx> ?
[23:23] <tumbleweed> xteejyx: it doesn't say what was changed, just that an FTBFS was fixed
[23:23] <tumbleweed> it doesn't even say why it FTBFSed
[23:24] <xteejyx> linker wit gcrypt?
[23:25] <tumbleweed> xteejyx: I would say "Explicitly linked with gcrypt for binutils-gold"
[23:25] <xteejyx> binutils-gold?
[23:26] <tumbleweed> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-October/000772.html
[23:27] <xteejyx> why that name though?
[23:27] <tumbleweed> xteejyx: read http://wiki.debian.org/ToolChain/DSOLinking
[23:28] <xteejyx> ok thankyou :)
[23:52] <xteejyx> did my last message go through I got disconnected?
[23:55] <xteejyx> anyone able to help?