[00:20] <sebner> geser: fails as well
[02:27] <vhenry93> Hi, developer newbie here who would like to contribute. Question, is MOTU or bugsquad best place to start?
[02:33] <vhenry93> disregard, found the answer.
=== emma is now known as em
[06:02] <simar> Hello everyone
[06:02] <simar> I have a doubt..
[06:03] <simar> https://wiki.ubuntu.com/PbuilderHowto pbuilder sets up a chroot environment for for building source packages for ubuntu..
[06:07] <RAOF> simar: Do you have a question?
[06:07] <paultag> simar: yes?
[06:08] <simar> So how this is different from.. https://wiki.ubuntu.com/DebootstrapChroot
[06:08] <paultag> simar: check /var/cache/pbuilder/
[06:08] <simar> I mean do I also need a chroot enviroment for building source packages..
[06:08] <paultag> simar: it stores it in a .tar.gz and cleans it after use to ensure a clean build (and good to check if it's deps are right)
[06:09] <paultag> simar: pbuilder builds source packages
[06:09] <paultag> last I checked, anyway :)
[06:09] <RAOF> No, but it can be useful to have a chroot environment if you want to check that it'll build in the archive.
[06:10] <simar> No chroot creats binary packages .. but when i have to create source packaes by debuild -S then should i do that in a chroot
[06:10] <simar> *No pbuilder creats ....*
[06:12] <RAOF> Ah, no.
[06:12] <RAOF> There's no reason to create source packages in a chroot.
[06:14] <simar> paultag, Does it means something like pbuilder also creates a chroot but handles it nicely in a tar.. So can we make binary packages without pbuilder but with a simple chroot .. I will be happy if you can tell me what are all the ways to create a chroot enviroment .. tha will make it more clear
[06:15] <cdbs> simar: Why would you avoid using pbuilder?
[06:15] <cdbs> simar: it speeds up the chroot creating, extracting and building, and automates it all
[06:15] <paultag> simar: pbuilder just creates a chroot of your choosing, puts it into a tar, and automates extracting it, updating it, and so forth without builds klobbering ( such as leaving old deps that may "save" a ftbfs )
[06:15] <paultag> cdbs: +1
[06:15] <simar> RAOF, But if I want to create source packages for natty and I'm currently using maverick won't dependies gonno conflict..
[06:15] <RAOF> Fundamentally, creating a chroot is not much more than running debootstrap on a directory.  But pbuilder and sbuild are two tools that make managing build chroots easy.
[06:16] <cdbs> simar: of course not
[06:16] <paultag> simar: you can create a natty pbuilder env
[06:16] <cdbs> simar: install the package ubuntu-dev-tools and then use the pbuilder-dist script as a front-end of pbuilder, it will make life easier
[06:16] <cdbs> simar: eg pbuilder-dist natty create
[06:16] <paultag> +1 there
[06:16] <cdbs> simar: then pbuilder-dist natty build foo.dsc
[06:16] <RAOF> simar: If you're making a *source* package you generally don't care about the build-dependencies, because you're *not* building the code.
[06:16] <simar> oh..
[06:17] <RAOF> simar: The only dependencies you need to care about for source packages are the packaging tool dependencies - quilt, dpkg, debhelper, cdbs, etc.
[06:17]  * cdbs is a dependency :)
[06:17] <RAOF> cdbs: Only for annoying packages :P
[06:18] <cdbs> RAOF: exactly. Even I prefer dh7/8 over cdbs
[06:18] <simar> cdbs, I use pbuilder but don't understand what is it.. n I get confused when I read something like 'Chroot enviroment' in packaging guide..
[06:18] <paultag> simar: play with it
[06:19] <simar> cdbs, I should use pbuilder thats for sure
[06:19] <paultag> simar: you'll grab the idea after you try to hack it into normal usage (and read the man page)
[06:19] <cdbs> simar: pbuilder builds in a chroot environment. When they ask you to build in one, just build using pbuilder
[06:19] <cdbs> simar: so, you have a natty pbuilder chroot already?
[06:19] <RAOF> simar: Basically, pbuilder is a way of turning a source package into a binary package, while not polluting your regular install.
[06:20] <simar> cdbs, No but I will have one .. today .. using the command pbuilder-dist
[06:20] <cdbs> simar: yes, that's the way to go
[06:21] <simar> RAOF, I understand that .. but when I create source packages .. then can I do that in my regular directory of maverick...
[06:21] <simar> I will be creating source packages for natty
[06:21] <RAOF> simar: Right*.  (* Unless the source package uses *packaging* tools available in Natty but not Maverick; there aren't a lot of those, but they exist)
[06:22] <RAOF> There's no need to do anything special for source packages.
[06:22] <simar> RAOF, Sould this be a point of worry for a beginner...??
[06:23] <RAOF> No.  The cases where it matters are very rare.
[06:23] <RAOF> And you'll know when it happens.
[06:24] <simar> @everyone Thanks for help. I think I got most of the stuff. But I want to know what usually developers do. I can do all this in virtual machine as well. So should I use pbuilder or virtual machine..
[06:24] <RAOF> I use sbuild personally; others use pbuilder.
[06:25] <cdbs> simar: I 'd recommend pbuilder whether you use in a VM or outside it
[06:25] <simar> RAOF, why si
[06:25] <simar> *so
[06:25] <simar> cdbs, ok.. that sounds more clear..
[06:25] <cdbs> simar: the main point of a pbuilder is to check whether the build-depends are okay and the package builds well in the target distro
[06:26] <simar> cdbs, ya i understand that..
[06:26] <RAOF> sbuild is (closer to) what's used on the buildds, so it sometimes picks up problems that pbuilder wouldn't.  It's also more powerful, so I can do funky things with it.  pbuilder (and particularly pbuilder-dist) are plenty good, though.
[06:26] <cdbs> simar: I am using natty for daily use (mind you its buggy) and even after that I use pbuilder, not sane building using debuild
[06:28] <paultag> The issue is that it will pick up system deps that might not be on a build machine -- let's say you forget libfoo-dev in your build-deps, but you have it installed locally. Your build will be fine, but when you upload it will FTBFS
[06:29] <paultag> That's why we use chroots to test -- and pbuilder to keep up sane
[06:29] <simar> paultag, ok..
[06:30] <simar> and what exactly is a debootstrap? thats a term related to these i think..
[06:30] <paultag> simar: it's what creates a chroot -- layered under levels of sanity it's called for pbuilder
[06:31] <paultag> simar: because you can't just chroot into ./chroot-dir, you also have to have ./chroot-dir/proc, dev and a few other fun things before you have a sane env
[06:32] <paultag> "One does not simply chroot into mordor"
[06:32] <paultag> if you will
[06:32] <RAOF> debootstrap is DEbian Bootstrap - it basically downloads and unpacks all the packages you need to set up a debian environment (you need a shell, libc, dpkg, etc) without needing any of the tools in there.
[06:32] <broder> paultag: +1 :)
[06:32] <paultag> ;)
[06:33] <simar> i got it .. so much thanks for help ... :))
[06:33] <paultag> simar: godspeed!
[06:33] <simar> paultag, ;)
=== almaisan-away is now known as al-maisan
=== Guest20469 is now known as Lutin
[08:01] <dholbach> good morning
[09:07] <RainCT> morning dholbach :)
[09:08] <dholbach> hola RainCT - Feliz Cumpleaños! :)
[09:09] <RainCT> dholbach: thanks :)
[09:51] <iulian> Morning dholbach, RainCT.
[09:51] <iulian> Uhmm.
[09:51] <dholbach> hi iulian
[09:51] <iulian> Happy what?
[09:51] <dholbach> Birthday!
[09:52] <iulian> Uh oh!
[09:52] <iulian> RainCT: Happy birthday mate!
[10:00] <RainCT> iulian: thanks!
[10:01] <sebner> RainCT: happy birthday! :)
[10:01] <sebner> ~o~ ~o~ ~o~ ~o~ ~o~
[10:18] <cdbs> RainCT: Happy Birthday
[10:25] <RainCT> sebner, cdbs: ~o~ thanks ~o~
=== al-maisan is now known as almaisan-away
=== evilvish is now known as vish
=== almaisan-away is now known as al-maisan
[13:32] <Raydiation> hi ive written something like ampache, just in django and with a better userinterface plus ogg vorbis support (its in HTML5). you can see a preview on http://laudio-player.org/
[13:33] <Raydiation> ive also done the packaging (was a lot of work) and now its in revu http://revu.ubuntuwire.com/p/laudio
[13:33] <Raydiation> if someone is interested :)
[13:33] <Raydiation> after install its available under http://localhost/laudio
=== yofel_ is now known as yofel
=== Quintasan_ is now known as Quintasan
=== makl is now known as ximion
=== ximion is now known as makl
=== makl is now known as ximion
=== al-maisan is now known as almaisan-away
[16:12] <gondoi> blueyed: morning! I think that branch is all ready to go for #699967 SRU.  Do I need to propose merge again?
[16:40] <ari-tczew> bug 699967
[16:40] <ubottu> Launchpad bug 699967 in munin (Debian) "Empty list of plugins/services with hostname containing uppercase letters" [Unknown,Confirmed] https://launchpad.net/bugs/699967
[16:41] <ari-tczew> gondoi: You don't need to propose again. However, there are still some issues.
[16:41] <gondoi> :-(
[16:41] <gondoi> okay
[16:41] <ari-tczew> I'll comment.
[16:41] <gondoi> thanks
[16:58] <ari-tczew> gondoi: done
[16:59] <gondoi> ari-tczew: thanks, I'll have a look
[17:25] <ari-tczew> siretart: ping
[17:31] <gondoi> ari-tczew: I'm not seeing where the DEP-3 info needs to go
[17:32] <gondoi> oh wait, I think I do now
[17:32] <gondoi> is there a tool to embed that? or is it manually created?
[17:33] <ari-tczew> gondoi: manually
[17:33] <ari-tczew> gondoi: but tool in future is a good idea
[18:03] <grunthus> Hi cyphermox.
[18:05] <micahg> gondoi: source format 3 can create most of what you need if the package supports it and you're creating the patch
[18:09] <cyphermox> grunthus, hey
[18:10] <grunthus> Hi cyphermox, I was pleased with how the fix went overall!
[18:10] <ari-tczew> micahg: do you encourage to change source format in Ubuntu instead Debian?
[18:10] <micahg> ari-tczew: no
[18:10] <micahg> that's why I said, if the package supports it :)
[18:10] <grunthus> cyphermox: Funny issue with my DEBFULLNAME etc however as those are set in .bashrc
[18:13] <grunthus> cyphermox: I have to go out now for 2 hours. Speak later if you are around!
[18:17] <grunthus> cyphermox: fixed DEBEMAIL, just had to export!
=== arand__ is now known as arand
[18:19] <cyphermox> grunthus, great :)
[19:05] <bcurtiswx> i downgraded a package from the gnome3 PPA to natty (nautilus), but it still links to libgtk-3.0.so.0 => /usr/lib/libgtk-3.0.so.0 (0x00007fd03e47b000).. how can i change that back to -2.0 ?
[19:06] <geser> bcurtiswx: this is from ldd nautilus?
[19:06] <bcurtiswx> geser, correct
[19:06] <geser> bcurtiswx: is it nautilus linking against libgtk3 or one of the libs it uses?
[19:07] <geser> I guess the later
[19:07] <bcurtiswx> geser, the later probably. how would I find out which?
[19:07] <geser> try and error with ldd
[19:08] <geser> or see which packages will be gone too if you remove it (the package for libgtk3) and check those
[19:10] <blueyed> ari-tczew, micahg: gondoi is working on a SRU with a patch that has been applied upstream already - I do not think he should edit the patch to make it match DEP-3. After all, that would have been the job of the committer for the Natty package (which is me).
[19:11] <gondoi> blueyed, ari-tczew: i pushed up the changes earlier
[19:11] <bcurtiswx> geser, apt-cache rdepends was my savior
[19:11] <bcurtiswx> it was libnautilus-extension1 that i didn't downgrade too
[19:11] <bcurtiswx> geser, thx for the help :)
[19:12] <micahg> blueyed: I was just answering a question that was asked, not commenting on relevance of the headers
[19:13] <blueyed> micahg: you are right, of course. thanks.
[19:13] <micahg> blueyed: also, is there a good chance to get the new upstream version in natty (in which case the patch would disappear?), in any case, a new upload is a good chance to get that recorded somewhere, and in an SRU, if there are any problem with the patch, it's probably best to have all the info right there
[19:16] <blueyed> micahg: there's no new release yet (AFAIK), would be munin 1.4.6. Of course, additional info won't hurt. And it was added by gondoi.
[19:16] <ari-tczew> blueyed: patch should be included in devel (natty) first, then SRU
[19:16] <blueyed> gondoi: the author lines appear to be wrong: we are both not the author of the patch.
[19:17] <blueyed> ari-tczew: it is in natty already.
[19:17] <ari-tczew> blueyed: a lot of patches are go through SRU and everyone has got DEP3 tags. why gondoi's case should be special?
[19:17] <blueyed> gondoi: that is quite pedantic though, but should be easy for you to remove those lines and push again.
[19:18] <blueyed> ari-tczew: there are no DEP3 tags in the natty patch. so it differs from natty. While this is only meta info, it is better to use the same patch as with the devel version, isn't it?
[19:19] <ari-tczew> blueyed: I won't click 'Approve', dunno how about you.
[19:19] <blueyed> ari-tczew: just because, or because of some reason?
[19:19] <blueyed> ari-tczew: there are DEP3 tags now.
[19:20] <ari-tczew> blueyed: that's policy. every patch which is going to Ubuntu archive should be described by DEP3 tags
[19:20] <ari-tczew> Debian should as well
[19:20] <gondoi> blueyed, ari-tczew: DEP3 modified
[19:21] <micahg> blueyed: if there's a problem with the headers, that should be caught test building the SRU, otherwise, it is the same patch
[19:22] <geser> ari-tczew: is the DEP3 requirement documented somewhere?
[19:23] <ari-tczew> geser: https://wiki.ubuntu.com/PackagingGuide/PatchSystems#Patch Tagging Guidelines
[19:23]  * micahg was thinking about asking that
[19:23] <ari-tczew> merged from https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines
[19:24] <blueyed> gondoi: approved, thanks so far.
[19:24] <micahg> it seems to be a suggestion (a very good one) as opposed to a hard requirement though
[19:25] <ari-tczew> micahg: nitpick
[19:25] <geser> I read also it as "nice-to-have" but no requirement
[19:25] <geser> I've never added any DEP3 headers when fixing any FTBFS till now
[19:26] <gondoi> blueyed: thanks
[19:45] <ari-tczew> gondoi: is this line not necessary? $node = lc($node);
[19:45] <ari-tczew> looking from http://munin-monitoring.org/changeset/3404#file19
[19:48] <gondoi> ari-tczew: it's already there from the 1.4.5 release src
[19:48] <gondoi> that's what started the bug
[19:50] <ari-tczew> gondoi: you don't understand me.
[19:50] <gondoi> that view is a bit odd, but it looks like the _list_services line had the correct code, but somehow regressed in a later revision
[20:04] <ari-tczew> gondoi: look on the patches:
[20:05] <ari-tczew> gondoi: natty: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/munin/natty/view/head:/debian/patches/upstream_bug_952.patch
[20:05] <ari-tczew> gondoi: upstream: http://munin-monitoring.org/changeset/3404#file19
[20:05] <ari-tczew> changes on file Server.pm are not the same
[20:05] <ari-tczew> is it correct?
[20:06] <ari-tczew> blueyed: do you have PPU for munin?
[20:07] <ari-tczew> blueyed: ok nevermind
[20:08] <gondoi> ari-tczew: that line is already there... no need to patch it
[20:08] <gondoi> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/munin/maverick/view/head:/node/lib/Munin/Node/Server.pm#L93
[20:09] <gondoi> L174 is the one that is patched and incorrect
[20:10] <ari-tczew> gondoi: ok, some concerns about DEP3, will quickly comment
[20:18] <ari-tczew> gondoi: done. please fix rapidly and I'll ask patch pilot to upload it today ;-)
[20:27] <bcurtiswx> what are the basic steps in a sync, is this documented well in the wiki?
[20:27] <Rhonda> Yes.
[20:27] <maco> bcurtiswx: just request one on launchpad. subscribe archive admins
[20:27] <maco> theyre the only people who can do them
[20:27] <bcurtiswx> maco, OK
[20:28] <Rhonda> The requestsync tool is extremely helpful for that
[20:28] <Rhonda> No need to extract and write it up all yourself.
[20:28] <maco> dont use the rogue script some people use for syncing around the archive admins
[20:28] <maco> it apparently breaks stuff
[20:29] <maco> (yeah, i got told this /after/ using that script...)
[20:29] <ari-tczew> bcurtiswx: https://wiki.ubuntu.com/SyncRequestProcess
[20:30] <bcurtiswx> ty ty ty :)
[20:34] <ari-tczew> np
[20:35] <siretart> ari-tczew: this is a contentless pong.
[20:36] <ari-tczew> siretart: FTBFS in libva wasn't fixed
[20:36] <siretart> ari-tczew: pardon me?
[20:36] <siretart> what's missing?
[20:37] <ari-tczew> siretart: debian bug 609554
[20:37] <ubottu> Debian bug 609554 in libva "Fix FTBFS with ld --no-add-needed" [Important,Fixed] http://bugs.debian.org/609554
[20:37] <ari-tczew> I tried to build it on natty and it still fails to build due to linking
=== mok01 is now known as mok0
=== effie-jayx is now known as effie_jayx
[20:41] <siretart> ari-tczew: so you're basically saying that http://git.debian.org/?p=pkg-multimedia/libva.git;a=blob;f=debian/patches/remove-unneeded-dep2.patch is incomplete or broken, right?
[20:43] <ari-tczew> siretart: probably yes
[20:44] <siretart> in this case that patch needs to be revised/fixed
[20:54] <ari-tczew> siretart: I could help you fix it, but not today.
[21:19] <geser> TrudEev4
[21:19] <geser> crap, wrong window :(
[21:19] <Laney> :(
[22:53] <grunthus> hi cyphermox again,
[22:53] <grunthus> you probably got my email...
[22:54] <grunthus> now I need to find another task.
[23:11] <cyphermox> grunthus, I sent you links for two ways to find new stuff to do -- LP bugs (bitesize), and Harvest. but one other way is to find something that annoys you and try to fix it :)
[23:12] <grunthus> Thanks cyphermox, I see that now.
[23:16] <cyphermox> grunthus, now just like yesterday, I'll need to travel from the office to back home, so I'd be back in hopefully about an hour
[23:16] <grunthus> Well, cyphermox, the next hour will be midnight for me.
[23:16] <cyphermox> ah
[23:16] <cyphermox> those pesky timezones
[23:17] <grunthus> I hope to be in bed! What timezone are you?
[23:17] <cyphermox> EST
[23:17] <grunthus> GMT+5
[23:17] <cyphermox> -5
[23:17] <grunthus> I'm UT
[23:18] <grunthus> EST is GMT-5
[23:18] <grunthus> ?
[23:18] <cyphermox> yes
[23:18] <grunthus> of course!
[23:36] <grunthus> Hi, bzr branch is showing port 22:Connection refused. Is that down to maintenance mode?
[23:51] <micahg> grunthus: yep, LP is read-only at the moment (bzr down), should be about 45 more minutes
[23:53] <grunthus> micahg: thanks for info.