[00:10] <Laney> ScottK: what do you think of he latest revision in http://packages.debian.org/changelogs/pool/main/g/gnome-do/current/changelog ? Would it need freeze approval?
[00:11] <Laney> (and consequent removal of the gnome-do-docklets package)
=== ivoks is now known as ivoks-afk
[03:15] <persia> bdrung, ari-tczew : please don't split sponsoring by component again: we recently spent months *undoing* the split.  If working as a MOTU, one should only be working on "unseeded".  If there is something in that category which cannot be uploaded, please file a bug, as it ought be uploadable (or be seeded).
[03:15] <persia> Split by packageset is the correct split.
[03:17] <persia> kklimonda, The two-ACK guideline is to encourage peer review.  It gets confusing because so much of the documentation is now written with the assumption that the person working on stuff is not a member of ~ubuntu-dev.  The entire point of all the "two ACKs" and "don't confirm your own change" rules throughout Ubuntu is to have two qualified sets of eyes on major or significant changes.
[03:18] <persia> Ideally we'd do that for every change, but it would slow workflow down too much for most uploads.
[04:08] <achiang> hello, quick question on ubuntu practices... i just filed: https://bugs.freedesktop.org/show_bug.cgi?id=30527
[04:08] <ubottu> Freedesktop bug 30527 in Lib/Xlib "XKB keygrabs broken" [Normal,New]
[04:08] <achiang> should i also open launchpad bugs as well and point that one as upstream?
[04:08] <achiang> it affects both lucid and maverick
[04:08] <achiang> i didn't check older releases
[04:09] <persia> Either way works.
[04:10] <achiang> persia: erm, sorry? :)
[04:10] <persia> The goal is to get it fixed upstream, really.  If lots of folks are noticing or reporting, it's useful to have in LP as a reference.  If it's in LP and not upstream, needs go upstream (if it isn't the result of an Ubuntu patch).
[04:11] <achiang> ah, makes sense. in that case, i won't open an LP then
[04:11] <persia> If it's in the upstream tracker and not LP, and there isn't a bundle of users complaining about it, it's fine to just leave upstream (although you might want to also have an LP bug if necessary for discussing a potential fix, etc.)
[04:12] <achiang> I don't think this issue is widespread enough to have lots of folks complaining about it. It's rather esoteric, afaict.
[04:12] <persia> If there's a fix, and it's sensibly backportable to Lucid or Maverick, and it would qualify for SRU (would need a use case showing how it can cause apps to crash, data loss, etc.), then it's worth opening a bug for the SRU review.
[04:13] <persia> But, yeah, for the regular run of esoteric upstream bugs, best to just fix them upstream and let distributions (including Ubuntu) inherit the fix when it becomes available.
[04:13] <achiang> nod, ok. i'll continue to track upstream and see how they respond to see whether it warrants a backport
[04:13] <achiang> an OEM customer discovered this because their workaround for another bug broke (https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/224475)
[04:13] <ubottu> Launchpad bug 224475 in flashplugin-nonfree (Ubuntu) "[MASTER] Volume/brightness/eject key briefly changes window focus (e.g. makes Flash exit full screen)" [Low,Triaged]
[04:14] <achiang> see comment #32 if you're interested... i haven't checked to see if Flash still suffers from the same papercut
[04:15] <persia> Ah, yeah, there's another reason to open a bug in LP: if you're doing commercial support of some sort and want somewhere to point your customer :)
[04:16] <achiang> well, they originally opened a private LP bug, but we decided to close it after they figured out another workaround. so sending this test case upstream is just trying to be a good citizen, because in practice, the customer has a [different] fix
[04:17] <achiang> anyhow, thank you for the guidance, persia
[04:30] <ScottK> Laney: Do we have the Dockey package it mentions?  If so, I think it's all clearly bugfix.
[04:32] <RAOF> We do.
[06:34] <dholbach> good morning
[07:06] <bilalakhtar> bdrung: around?
[07:50] <AnAnt> Hello
[08:21] <kklimonda> hmm, is it possible to disable network in pbuilder? basically recreate, in a cheap way, a buildd? removing/replacing resolv.conf isn't enough obviously.
[08:23] <tumbleweed> kklimonda: my hack is: iptables -A OUTPUT \! -o lo -m owner --uid-owner 1234 -j REJECT
[08:24] <kklimonda> tumbleweed: hmm, interesting
[08:25] <kklimonda> tumbleweed: have you had any problems with that?
[08:25] <kklimonda> if not I'll steal that idea :)
[08:25] <tumbleweed> no, it seems to work pretty well (assuming you have no users with that ID)
[08:27] <kklimonda> do you use hooks for that or do you have a local mirror?
[08:29] <tumbleweed> kklimonda: the apt-getting happens as root, not the pbuilder user
[08:34] <persia> kklimonda, It's a far better thing to patch the code not to try to access the network during build.
[08:35] <persia> Otherwise it makes it hard for folks who don't have the replicated environment to testbuild, etc.
[08:35] <kklimonda> persia: yes, I know - but it's a good idea to catch such a code earlier then later
[08:35] <persia> It's usually obvious from build-logs, but OK :)
[08:35] <tumbleweed> persia: I do that to help catch such broken builds before they get to buildds
[08:36] <kklimonda> persia: well, some of django tests require network connection and fail when it's not available.
[08:36] <persia> kklimonda, Why on earth do they need network connection?
[08:36] <kklimonda> persia: so you risk uploading a package that builds just fine on your machine but fails in buildd
[08:37] <kklimonda> persia: for example URLField checks if the url is proper (working and existing domain, an existing file etc.)
[08:39] <persia> kklimonda, I believe the buildds to have DNS, although I don't know if they have full DNS.
[08:39] <bilalakhtar> Does anyone over here know how to get pbuilder to log builds? --logfile doesn't seem to work, it doesn't create any file
[08:39] <persia> Also, the test should be rewritten to create sufficient local environment to verify things.
[08:40]  * persia bugs sbuild more
[08:40] <persia> s/bugs/hugs/
[08:40] <kklimonda> persia: sure, either that or not failing with errors (just warnings)
[08:41] <kklimonda> persia: and creating a sufficient local environment to test it would be a lot of work.
[08:41] <tumbleweed> bilalakhtar: my pbuilder logs just fine
[08:41] <bilalakhtar> tumbleweed: How do you actually use its --logfile option?
[08:41] <tumbleweed> bilalakhtar: err I have PKGNAME_LOGFILE=yes
[08:41] <bilalakhtar> okay
[08:43] <persia> kklimonda, Not failing, just warnings makes the test useless.
[08:43] <persia> It's work to get testing right, but it's worth it: users expect that we provide them with reliable code.
[08:43] <kklimonda> persia: gah, it's ran by developers and maintainers anyway.
[08:44] <kklimonda> persia: your solution, while obviously superior, is just way too complicated to implement - upstream wouldn't be interested in doing this work and there are so many packages to work on.. :/
[08:44] <persia> kklimonda, Think broader: consider, for example, a dicoweb installation done by someone completely unfamiliar with python.
[08:46] <persia> kklimonda, You'd be surprised.  Most upstreams are happy to look at that sort of thing, especially if you can tell them things like "I'll make sure the updated testsuite is run daily against your codetrunk if you do this", which you can do with an LP recipe.
[08:46] <persia> But, yeah, lots of packages.  If you have only passing interest in this one: leave that discussion for someone else.
[08:47] <kklimonda> persia: well, it's not that I'm not interested in either package or the discussion per se
[08:48] <persia> kklimonda, the rationale behind my objections would be satisfied if you disabled the tests and filed a bug on the package about the tests being disabled.  Extra points for filing upstream and explaining why they are disabled.
[08:49] <kklimonda> persia: but what you are describing is a long-term solution that would involve at least 3 sides - sure, a great project but not something I can do this week. I'll have to think about it and ask django-devs
[08:50] <persia> Right, which is why I suggest filing a bug about it (for tracking) and disabling the tests :)  If it was something you could do quickly, I'd hope you'd just do it, but if you can't... :)
[08:50] <kklimonda> persia: the upstream is aware of this problem, so is Debian and so are we - a few of tests have been disabled during django MIR process and now, in 1.2.3 a new one has been added - that one I've missed.
[08:50] <kklimonda> (I've missed it because it didn't fail in my pbuilder ;) )
[08:51] <kklimonda> so the whole discussion has been more about finding such problems early in process and not how to disable tests and hide the fact
[08:51] <kklimonda> persia: you are thinking about a specific "Django tests that require internet connection fail" bug?
[08:52] <persia> kklimonda, Yes, and that broad: list all the tests you had to disable there.
[08:52] <kklimonda> (I actually agree that we could probably help Django developers to run those tests on a daily basis - last release has a few failing and I had to backport fixes from the trunk.
[08:52] <persia> Point being that we know we aren't testing that, and should track the problem: even if we can't fix it right away, it remains a defect in the software we provide.
[08:53] <kklimonda> persia: makes sense
[08:53] <persia> Right.  Getting a whole continuous-integration environment up and running, as well as setting up all the tests to do full mocks, is a project larger than between now and maverick release :)
[08:53] <kklimonda> well, that's for sure
[08:54] <kklimonda> It would be nice if we at least got a 1.2.3 before release.
[10:48] <bdrung> bilalakhtar: hi
[10:48] <bilalakhtar> bdrung: hi
[10:48] <bilalakhtar> bdrung: What is the main reason why you want to give away audacious?
[10:53] <bdrung> bilalakhtar: as i wrote yesterday (you went offline too soon): upstream is not the reason for giving the package away. i maintain too many packages and that consumes too much time.
[10:53] <bilalakhtar> bdrung: Do you maintain it in Debian? ah, you are uploader there
[10:53] <bilalakhtar> bdrung: okay, I agree
[10:54] <bdrung> bilalakhtar: yes, it's maintained in debian. our ubuntu version is the same with the version we have in the git experimental branch
[10:54] <bilalakhtar> ah
[10:54] <bilalakhtar> so the git experimental branch is hosted on alioth, right?
[10:55] <bdrung> (only the debian/changelog file differs for obvious reasons)
[10:55] <bdrung> bilalakhtar: yes
[10:55] <bdrung> bilalakhtar: http://git.debian.org/?p=pkg-audacious/audacious.git;a=summary
[10:55] <bilalakhtar> ah
[10:56] <bilalakhtar> bdrung: so what's the process of taking over? Can you upload to this package?
[10:56] <dholbach> thanks bdrung
[10:57] <bdrung> dholbach: you're welcome
[10:58] <bdrung> dholbach: btw, we have a bug in sponsors overview.
[10:58] <dholbach> bdrung, aha?
[10:58] <bdrung> bilalakhtar: get upload rights to the alioth git repository. i can't upload the package in debian (only ctaylor can do that).
[10:59] <bilalakhtar> bdrung: and how to do that?
[11:00] <bdrung> dholbach: SponsoringItem.get_components -> "self.components.add('universe') # let's assume universe" is wrong in some cases like git-core.
[11:00] <bdrung> bilalakhtar: get an alioth account.
[11:00] <bilalakhtar> bdrung: done
[11:01] <bdrung> bilalakhtar: now request to join the pkg-audacious group.
[11:03] <bilalakhtar> argh, alioth is so slow
[11:03] <bdrung> bilalakhtar: only sometimes
[11:05] <bilalakhtar> angelabad: get your client to wait a bit before joining channels
[11:05] <bilalakhtar> bdrung: requested
[11:06] <bilalakhtar> Why does alioth add -guest at the end of my name?
[11:07] <bdrung> bilalakhtar: because every DD gets an alioth account and the names shouldn't clash
[11:07] <bilalakhtar> bdrung: ah
[11:08] <bilalakhtar> bdrung: It would have definitely been better if such a thing existed in LP. I need the LP account name ~bilal but someone has taken it, and now I have the long ~bilalakhtar which creates a long e-mail alias bilalakhtar@ubuntu.com
[11:08] <bdrung> bilalakhtar: now write a mail to ctaylor (CCing me) that you want to co-maintain the package
[11:09] <bdrung> bilalakhtar: alioth is only for debian, but launchpad is not only for ubuntu
[11:09] <kklimonda> bilalakhtar: it's a different thing - alioth is mostly (if not only) a debian service and LP hosts hundreds of projects
[11:09] <bdrung> kklimonda: :)
[11:09] <bilalakhtar> lol
[11:09] <bilalakhtar> and ~bilal has 0 karma
[11:10] <bilalakhtar> mailing
[11:10] <bilalakhtar> s/mailing/mailing ctaylor/
[11:10] <bdrung> bilalakhtar: you could ask if you can get the launchpad name
[11:10] <bilalakhtar> bdrung: unresponsive
[11:10] <bdrung> bilalakhtar: the LP admins :)
[11:11] <bilalakhtar> bdrung: that would be rude :)
[11:11] <kklimonda> I'm not sure it's worth an effort at this point
[11:12] <kklimonda> bilalakhtar has PPAs on his account, it's linked to various projects, he's using his alias already. It may not be that easy to migrate all that to another account
[11:12] <bilalakhtar> kklimonda: I migrated from a longer one to this just before becoming UM
[11:14] <kklimonda> bilalakhtar: it's woth asking LP admins if its possible then. I'm not sure if they can keep your current @u.c alias though.
[11:14] <bilalakhtar> kklimonda: forget it, I have too many sites that have this address
[11:16] <bilalakhtar> bdrung: sent
[11:33] <bdrung> bilalakhtar: do you want to know what's on the todo list?
[11:34] <bilalakhtar> bdrung: yes, please, what is there?
[11:34] <bilalakhtar> bdrung: too many bugs in maverick?
[11:36] <bdrung> bilalakhtar: 1) get these extension work with 2.4.0: http://people.canonical.com/~ubuntu-archive/NBS/libmowgli1
[11:36] <bilalakhtar> hell!
[11:38] <bdrung> bilalakhtar: 2) debian/copyright needs an update (in squeeze 2.3-2 and maverick). a complete license check is required. one big question: are the files licensed under GPL2 only (GPL2 and GPL3 are incompatible)?
[11:39] <bdrung> bilalakhtar: debian bug #594519
[11:39] <ubottu> Debian bug 594519 in audacious-plugins "multiple copyright problems make software non-redistributable as currently packaged" [Serious,Open] http://bugs.debian.org/594519
[11:39] <bilalakhtar> oh
[11:40] <bdrung> after these things sorted out, you can start working on getting bug fixed. ;)
[11:41] <bdrung> bilalakhtar: if you find licence problems, check if upstream trunk branch is affected, too
[11:42] <bilalakhtar> right now, I am working on an empathy bug, will see today evening
[11:57] <ScottK> ScottL: There is s new musescore in the queue: http://launchpadlibrarian.net/56895273/musescore_0.9.6.2%2Bdfsg-1ubuntu1_0.9.6.3%2Bdfsg-0ubuntu1.diff.gz - Do you all want it in (It's in the Studio package set)?
[12:20] <ScottL> LP: #652276
[12:20] <ScottL> but 652276
[12:20] <Rhonda> bug #652276
[12:20] <ubottu> Launchpad bug 652276 in musescore (Ubuntu) "Freeze exception and upload of new bug-fix release" [Undecided,Fix committed] https://launchpad.net/bugs/652276
[12:20]  * Rhonda helps ScottL :)
[12:20] <ScottL> too early in the morning ;)
[12:24] <ScottL> ScottK, this has a lot of bug fixes so it certainly is desirable but i would like to test it first
[12:25] <ScottL> ScottK, i should be able to test it within the next 8 hours, is that an acceptable time frame in which to have an answer?
[12:30] <ScottK> ScottL: That should be fine.  Thanks for looking into it.
[12:30] <ScottL> ScottK, my pleasure, thank you
=== ivoks-afk is now known as ivoks
=== ivoks is now known as ivoks-afk
[15:26] <ari-tczew> where can I find a source code of qa.ubuntuwire.org ?
[15:33] <ScottK> ari-tczew: You can join #ubuntuwire and ask wgrant or geser.  They would both know.
[15:34] <bilalakhtar> ari-tczew: Do you want to be a reviewer on REVU?
[15:36] <ari-tczew> bilalakhtar: huh, today I've looked on some packages. why you aks?
[15:36] <ari-tczew> ask *
[15:37] <bilalakhtar> ari-tczew: I mean, REVU doesn't recognize a person as ubuntu-dev until an admin marks it
[15:37] <ari-tczew> then I have to be marked
[16:03] <ari-tczew> bilalakhtar: who is an admin?
[16:06] <RainCT> ari-tczew: Done.
[16:06] <RainCT> (patches welcome, btw.)
[16:06] <ari-tczew> RainCT: thanks.
[16:06] <ari-tczew> RainCT: patches to revu?
[16:07] <RainCT> ari-tczew: Yup, for example to automatically set people as reviewer
[16:08] <ari-tczew> RainCT: I think that wgrant, tumbleweed or bdrung could help.
[16:09] <RainCT> ari-tczew: Yeah, there's enough people capable of writing this (me included). I'm just mentioning it in case someone is bored enough and wants to do it ;).
[16:13] <ari-tczew> ScottK: could you look at this one? bug 636277
[16:13] <ubottu> Launchpad bug 636277 in cdbs (Ubuntu) "cannot quickly package if spaces in parent folder name" [Undecided,Confirmed] https://launchpad.net/bugs/636277
[16:14] <ScottK> ari-tczew: We aren't changing cdbs this late in the cycle.
[16:14] <ari-tczew> ScottK: oh, I missed bug number. bug 470550
[16:15] <ubottu> Launchpad bug 470550 in coreutils (Ubuntu) "uname -p and uname -i reporting `unknown'" [Low,Triaged] https://launchpad.net/bugs/470550
[16:17] <ScottK> ari-tczew: Too late for that one too.
[16:20] <bdrung> ari-tczew: it's too late and i don't think that this patch should be applied.
[16:21] <ari-tczew> bdrung: why?
[16:21] <bdrung> if(!strncmp(cinfo, "vendor_id", 9))
[16:21] <bdrung> if(strstr(cinfo, "AuthenticAMD"))
[16:21] <bdrung> it's not universal enough
[16:22] <bdrung> and instead of applying the patch, it should be accepted by upstream first.
[16:23] <ari-tczew> ScottK: so I think that I'm wasting a time if I want a prepare FFe for new package to universe?
[16:23] <ScottK> ari-tczew: Yes.  You are.
[16:24] <bdrung> ari-tczew: try to get it into debian
[16:25] <bilalakhtar> RainCT: I can contribute patch to make it set reviewers automatically
[16:26] <ari-tczew> bdrung: patch or new package?
[16:26] <bdrung> ari-tczew: the new package.
[16:27] <bdrung> ari-tczew: and for the uname patch: get it accepted by upstream before adding to the ubuntu package
[16:27]  * ari-tczew is driving crazy due to tons of procedures.
[16:28] <bilalakhtar> BTW, does ari-tczew need advocation to upload a new package? He is MOTU, right?
[16:28] <bdrung> ari-tczew: general rule: we don't have enough man power to maintain a bunch of patches. so try to get the patches accepted by upstream or debian.
[16:29] <ari-tczew> bilalakhtar: 2 ACK are needed for approve new package. As MOTU, 1st ACK is mine. Then I need 2nd ACK, which is granted by bdrung.
[16:29] <tumbleweed> and: new packages need approval from archive-admins, and post-freeze from release team too.
[16:29] <bilalakhtar> tumbleweed: That is of course needed
[16:29] <bilalakhtar> and a new package a week before the release is too late
[16:29] <bilalakhtar> there was a discussion on this yesterday
[16:29] <tumbleweed> way too late
[16:30] <ari-tczew> the one possibly way is backport from natty
[16:30] <bdrung> tumbleweed: the approval from archive-admins is after the upload (so it doesn't count as procedure burden)
[16:30] <bilalakhtar> ari-tczew: one cannot backport new packages
[16:30] <tumbleweed> ari-tczew: or give ARB a spin
[16:30] <tumbleweed> bdrung: yeah, but you don't do an upload that won't get approval
[16:30] <ari-tczew> tumbleweed: ARB?
[16:31] <bdrung> tumbleweed: Chicken or egg dilemma
[16:31] <tumbleweed> ari-tczew: application review board (see the recent flamefests on ubuntu-devel and the planet)
[16:32] <ari-tczew> tumbleweed: which way do you preffer? backport or this ARB?
[16:33] <tumbleweed> ari-tczew: as an Ubuntu developer, you probably prefer backports
[16:33] <ScottK> bilalakhtar: Why do you spread misinformation.  You can backport new packages.
[16:34] <bilalakhtar> ScottK: really? I never playes with -backports, so sorry
[16:34] <bilalakhtar> *played
[16:34] <ScottK> bilalakhtar: Then don't make statements about things you don't know about.
[16:34] <tumbleweed> ari-tczew: ARB is outside the normal development process (and also requires different package layouts)
[16:34] <bilalakhtar> ScottK: If this was the case, then why was I barred a few months ago to get my new package backported to Lucid?
[16:35] <ari-tczew> tumbleweed: I think that I'm too lazy to get knowledge about ARB.
[16:35] <bilalakhtar> Others said 'too late'
[16:35] <ScottK> bilalakhtar: What bug?
[16:35] <bilalakhtar> ScottK: just a discussion here, no bug
[16:35] <ScottK> bilalakhtar: You weren't barred from getting anything backported.  Please don't make stuff up.
[16:35] <bilalakhtar> ScottK: I am not
[16:36] <ScottK> bilalakhtar: OK.  Who told you you can't backport a new package?
[16:36] <bilalakhtar> ScottK: Probably why it wasn't backported was because of its name, since the package has a misleading name, which was a major problem in getting the package in as well
[16:37] <ScottK> bilalakhtar: I ask again: Who said you couldn't backport it?
[16:37] <bilalakhtar> I guess it was someone whose nick started with s, don't remember, it was 5 months back
[16:38] <ScottK> bilalakhtar: OK.  Claiming something can't be done because someone you don't know who it was said you couldn't half a year ago and you never even made a proper request is not much of a basis for anything.
[16:39] <bilalakhtar> ScottK: okay, sorry then
[16:41] <tumbleweed> bilalakhtar: when you are unsure about something like that, it's best to find the policy and read it for yourself
[16:43] <bilalakhtar> tumbleweed: Things that happen once with a person are like engraved stones inside him/her. I try to avoid backports, and since that was the only case in which I thought of it, I thought that might be the case, which isn't, so I apologise .
[16:45] <tumbleweed> bilalakhtar: no worries (ScottK was being quite hard on you :) )
[16:45] <bilalakhtar> No, ScottK wasn't hard, he just thought I might be making up. OTherwise, he said fine
[16:45] <ScottK> bilalakhtar: It's fine.  Now you know and we'll move on from here.
[16:46] <bilalakhtar> hmm
[16:46] <bilalakhtar> yes
[16:46] <ari-tczew> heh, very culturally discussion, instead "if you don't know, STFU" ;)
[16:47] <bilalakhtar> !language | ari-tczew
[16:47] <ubottu> ari-tczew: Please watch your language and topic to help keep this channel family friendly.
[16:48] <ari-tczew> omg...
[16:51] <ScottK> ari-tczew: In a global project that involves people from many cultures, you have to bend over backwards not to offend or the project just doesn't work.
[16:55] <ari-tczew> ScottK: sure, I understand. I said what I've noticed. but bilalakhtar took it too seriously.
[16:55] <bilalakhtar> ari-tczew: I am serious when it comes to offensive words. Just ask Rhonda about it!
[16:56] <tumbleweed> can we just call it a day and end this conversation? it isn't going anywhere useful
[16:56] <ari-tczew> +1 ^^
=== ivoks-afk is now known as ivoks
[18:16] <blueyed> If a package depends on libboost-filesystem1.34.1 can I make it work with libboost-filesystem1.42.0 ? I am about to edit the binary deb, but I would have to change the package name rather than some version only.
[18:16] <blueyed> It's about amazonmp3.
[18:19] <Bachstelze> blueyed: try to build it against 1.42 and see if it works
[18:19] <blueyed> Bachstelze: it's a binary deb from amazon.. :P
[18:20] <Bachstelze> well, same idea, try with 1.42 and see if it works
[18:20] <blueyed> I have changed DEBIAN/control in the binary package (accroding to http://daniel.hahler.de/binaeres-debian-paket-manipulieren)
[18:20] <Bachstelze> hard to tell beforehand
[18:20] <blueyed> It will work prolly.
[18:20] <blueyed> But I wonder why boost has the version in the package name?!
[18:21] <Bachstelze> so that different versions can be installed at the same time
[18:21] <Bachstelze> if a program requires a specific version
[18:21] <Bachstelze> all libraries have the API number if the package name
[18:22] <blueyed> well, but that makes a package depending on 1 fail if only 2 is available.. amazon.de provided amazonmp3 for 8.10, I have 10.10 - not working!!
[18:22] <blueyed> And I cannot rebuild.
[18:23] <blueyed> Obviously, changing only deps for the binary package will fail.
[18:23] <blueyed> Great. downloaded digital music, but cannot install.
[18:23] <Bachstelze> you can try to extrac the deb to e.g. /opt (sudo dpkg -x foo.deb /opt) and run the binary from there
[18:24] <Bachstelze> extract*
[18:24] <blueyed> % amazonmp3
[18:24] <blueyed> amazonmp3: error while loading shared libraries: libboost_filesystem-gcc42-1_34_1.so.1.34.1: cannot open shared object file: No such file or directory
[18:24] <Bachstelze> ouch
[18:24] <blueyed> so how do I get 1_34 now ?!
=== jcfp is now known as Guest81041
[18:24] <Bachstelze> you can install it from the Hardy repos
=== Guest81041 is now known as jcfp`
[18:29] <blueyed> oh well.. might be worth a try, but I need a break now.
[18:33] <blueyed> Bachstelze: are you sure it's hardy? at least the download was not for hardy (8.04), but intrepid (8.10).
[18:38] <Bachstelze> IIRC Hardy has 1.34 too
[18:38] <Bachstelze> and Intrepid is not supported anymore
[18:42] <blueyed> Yes, I've added the hardy repos and could install the the deb for 8.10.
[18:43] <blueyed> They must have a very high failure ratio on amazon though: nobody is using intrepid or hardy currently on a desktop anymore.
[18:46] <blueyed> Thanks, Bachstelze! - it worked.. currently downloading the album.. but nevertheless; the Amazon MP3 download process could get improved..
[19:24] <c_korn> is there some template which can be pasted into debian/rules to make it use multiple cpu cores automatically? like passing the correct -j value to make?
=== You're now known as ubuntulog
[19:43] <tumbleweed> c_korn: if you are using dh, pass --parallel, then it will build with the parallelism specified in DEB_BUILD_OPTIONS
[19:47] <c_korn> tumbleweed: ah, so I have to define the DEB_BUILD_OPTIONS first ?
[19:47] <tumbleweed> c_korn: no, the person building specifies that, see http://www.debian.org/doc/debian-policy/ch-source.html
[19:49] <c_korn> ok, thanks
=== ivoks is now known as ivoks-afk
=== ivoks-afk is now known as ivoks
[21:09] <Rhonda> I don't get what bilalakhtar is refering to when he hilighted me, but then I guess I shouldn't care too much. :)
[21:21] <devildante> hello everybody :)
[21:21] <devildante> I want to apply for universe-contributors, but I never did any syncs and I'm not experienced with them. Is it still okay? :)
[21:26] <Rhonda> What does the wiki say about the role? I guess you did read it, didn't you?
[21:26] <iulian> devildante: Take a look at https://wiki.ubuntu.com/UbuntuDevelopers and scroll down to Ubuntu Contributing Developers.
[21:26]  * Rhonda . o O ( Actually, this question means that I haven't read it, or rather not know it by heart  ;) )
[21:26] <devildante> "merge new versions from Debian"
[21:26] <devildante> I'm doomed then :p
[21:27] <Rhonda> As job or as requirement?
[21:27]  * Rhonda goes and scans herself :)
[21:27] <devildante> as job
[21:27] <devildante> at least, it's not in requirements :p
[21:29] <iulian> OK, I'm definitely confused now.  What job and what requirement, Rhonda?
[21:29] <Rhonda> Right. Usually the roles as I understand it are meant top-down. So if you are familiar with the Prospective Developers role and how it works, and started to read the documentation for the Contributing Developer's things, that should be fine as prequesite.
[21:30] <devildante> Rhonda: great, thanks :)
[21:31] <Rhonda> iulian: job as in what people in that position usually do
[21:31] <iulian> Ah-ha.  That makes sense now.
[21:36] <ScottK> UCD just means "made enough of a contribution to become an Ubuntu member via packaging/development work".
[21:37] <devildante> ScottK: I think you'll have to determine that via my application
[21:37] <devildante> :)
[21:37] <ScottK> Yep.
[21:38] <ScottK> The requirements are broadly defined, but since I'm not on the DMB, it's not me who has to determine it (fortunately)
[21:41] <kklimonda> yeah, we would have a shortage of developers at our disposal with ScottK in the DMB ;)
[21:42] <ScottK> kklimonda: I doubt it would be much worse.
[21:42]  * iulian nods.
[21:42]  * devildante looks at the word "worse"...
[21:43] <devildante> it's already bad then :p
[21:43] <ari-tczew> ajmitch: around?
[21:44] <ScottK> devildante: Certainly.  We could definitely use more qualified developers.
[21:45] <kklimonda> ScottK: would -backports be a good way to prepare new upstream releases for all supported ubuntu versions once it can be set to install packages from it only on request?
[21:45] <ScottK> kklimonda: Defiintely.
[21:46] <ScottK> I think it's already a good way to do it, but it'd be better then.
[21:46] <ScottK> You can ~ do that now with pinning. It's only a problem when you need to pull an updated depends via backports.
[21:48] <kklimonda> ScottK: hmm.. so as long as we consider the leaf packages there is nothing preventing as from using -backports right now? As -backports aren't pinned right now by defualt would enabling them update all packages?
[21:48] <kklimonda> preventing us from*
[21:48] <ScottK> It would, but you can set the pinning locally too.
[21:48] <kklimonda> damn, where are my glasses :)
[21:49] <ScottK> I don't think we want it not automatic by default until the apt resolver can deal with this situation, but for individuals, pinning is already a good solution.
[21:49] <kklimonda> right
[21:50] <kklimonda> it's just harder for new users to set up pinning (even by copy-pasting) then to enable ppa at the moment.
[21:52] <ScottK> Yes.  That's where Canonical has chosed to invest it's engineering resources.
[21:53] <kklimonda> ScottK: btw, I was under the impression that -bacports are completely understaffed and that it's the main reason for not backporting all the stuff but from a brief look at the ML there aren't that many requests.
[21:53] <ScottK> kklimonda: We are looking for more volunteers.
[21:54] <kklimonda> ScottK: well, sure (and I'm going to help you once I have rights as I find -backports really important) - but it looks like whole idea isn't that well known to the community.
[21:56]  * kklimonda finds the current state when new version of software has to be pulled from completely untrusted sources.. wrong
[22:28] <ari-tczew> bdrung: ping
=== yofel_ is now known as yofel
[23:06] <ScottK> kklimonda: Backports has atrophied a bit.  It used to be more used.  I'd like to get help reinvigorating it.
[23:46] <paissad_> is there a way to build a package for i386 from an amd64 arch ?
[23:52] <kklimonda> paissad_: using chroot