=== funkyHat_ is now known as funkyHat
=== JackyAlcine is now known as [Jacky]
=== [Jacky] is now known as JackyAlcine
=== EvilResistance is now known as Resistance
=== funkyHat_ is now known as funkyHat
=== funkyHat_ is now known as funkyHat
=== funkyHat1 is now known as funkyHat
[03:37] <Resistance> is there a way for me to specify to the computer to *not* update a package if the package update does not originate from the main repos?
[03:41] <broder> https://help.ubuntu.com/community/UbuntuBackports#Configuring_Backports_for_Manual_Install walks through the general idea of the process
[03:42] <broder> i don't know any way to do it for all archives
[03:42] <broder> but you can list them out
[03:42] <broder> if you run apt-cache policy you'll see a bunch of "v=blah,o=blah,etc" strings; you can steal bits and pieces of those for the preferences file
[03:43] <Resistance> broder:  #ubuntu-server gave me a link to apt pinning
[03:43] <Resistance> broder:  could, in theory, if i want to pin php5* to *not* update unless it comes from the ubuntu archives/repos (i.e. us.archive.ubuntu.com), would the pinning work, and not update php* from the ppa?
[03:44] <Resistance> (as you can tell, i'm trying to backport php5, but i dont want to update in the production environment yet, only in dev/testing)
[03:44] <broder> the Package: field in a preferences file can only be a list of package names or "*"
[03:44] <broder> no php5* or anything
[03:44] <Resistance> hm
[03:44] <Resistance> oh i know
[03:44] <Resistance> *grabs the list of binaries generated by the backported source*(
[03:44] <Resistance> :P
[03:45] <broder> why are you configuring the PPA if you don't want packages from it?
[03:45] <Resistance> broder:  the PPA is already configured
[03:45] <Resistance> it holds *all* my backports
[03:45] <Resistance> just...
[03:45] <Resistance> this one system i dont want to update php5 yet
[03:45] <Resistance> (I eventually will after i run vigorous testing)
[03:45] <broder> you could stage in another PPA then pocket-copy the packages later
[03:45] <Resistance> i could
[03:45]  * Resistance will consider that
[03:45] <Resistance> actually i'll do that now assumign lp lets me
[03:49] <Resistance> broder:  within LP, i can copy the package source and have it rebuilt, or just copy the binaries.  if i want to copy stuff from staging ppa -> deployment ppa, i wouldnt need to copy/rebuild the source, if its a <release> -> <samerelease> copy, right?
[03:49] <broder> correct
[03:50] <Resistance> because staging would technically be the building environment, and the copied binaries would be sufficient?
[03:50] <broder> yes
[03:50] <Resistance> ah good
[03:51] <Resistance> thanks
[03:51]  * Resistance never thought to have one ppa for staging and one for deployment :p
[04:07] <psusi> why can't I bzr diff against the debian branch I just merged from?
[04:07] <psusi> bzr diff . ../sid
[04:07] <psusi> bzr: ERROR: Path "/home/psusi/gparted/sid" is not a child of path "/home/psusi/gparted/ubuntu"
[04:09] <broder> bzr diff --from ../sid --to .
[04:09] <psusi> no such option : --from
[04:10] <psusi> ahh, --old and --new
=== stalcup is now known as v
=== jibel_ is now known as jibel
[09:28] <Laney> morning
[09:41] <ajmitch> morning mr Laney
[09:41] <Laney> ow do?
[09:42] <ajmitch> just uploaded a package to my PPA, 9h build queue :(
[09:42] <Laney> ouch
[09:43] <ajmitch> LP had some hardware issues to cause a bit of a backlog
[09:44] <ajmitch> what fun are you up to today?
[09:46] <Laney> oral exams for undergrads
[09:46] <ajmitch> oh joy
=== almaisan-away is now known as al-maisan
=== dupondje_ is now known as dupondje
[12:42] <keffie_jayx_> hello all
[12:42] <keffie_jayx_> I am working on a daily-build ppa
[12:43] <keffie_jayx_> should I ask about it here or #launchpad
[12:48] <keffie_jayx_> I was wondering what happens to debian/changelog  when the merging of to branches happens. My guess it is not used at all
[13:17] <geser> keffie_jayx_: you might have better chances to get answers about recipes in #launchpad
[13:18] <keffie_jayx_> thans
=== yofel_ is now known as yofel
=== Tonio__ is now known as Tonio_
[14:03] <andzaytsev> Hello, can anybody help me to find support? I want to participate in Ubuntu by packaging. Where can I find a mentor or a person who can teach me?
[14:03] <tumbleweed> andzaytsev: we don't have a mentoring program, but you're welcome to ask questions here whenever you need to
[14:04] <andzaytsev> thank you, how can I start learning packaging?
[14:06] <tumbleweed> have you seen https://wiki.ubuntu.com/MOTU/GettingStarted ?
[14:06] <tumbleweed> I suggest playing around, and trying to fix some bugs
[14:07] <gnomefreak> !packaging
[14:07] <ubottu> The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[14:07] <andzaytsev> thanks
[14:11] <andzaytsev> and where can I learn to write patches?
[15:06] <Laney> dang, no dholbach
[16:30] <wendar> I'm editing the docs on REVU, anyone got a sec for a quick sanity check?
[16:33] <Laney> wendar: yeah sure
[16:34] <Laney> the tone should be like "you can use it, but make sure you have a reviewer lined up beforehand because MOTU will probably not give you one"
[16:34] <wendar> for the MOTU process, I'm substituting "upload to your PPA or a Launchpad branch" instead of "upload to REVU"
[16:34] <wendar> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[16:35] <wendar> Laney: sounds good, will add that
[16:35] <Laney> could you just link to http://developer.ubuntu.com/packaging/html/packaging-new-software.html ?
[16:35] <wendar> in fact, I did
=== al-maisan is now known as almaisan-away
[16:35] <wendar> but, only for the "Launchpad branch"
[16:36] <Laney> that page misses all of the information about debian
[16:38] <Laney> I don't really think "Going through MOTU" is going to produce happiness
[16:38] <wendar>  * Once you have an initial package, follow the [[http://developer.ubuntu.com/packaging/html/packaging-new-software.html#next-steps|New Packaging instructions]] to upload it to your PPA or a Launchpad branch, then add a link to the package in the description of the bug. Requests for changes or other communication about your package will be made as comments on your bug.
[16:40] <wendar> Laney: the developer.ubuntu.com page, or the "NewPackages" page?
[16:40] <Laney> the former
[16:40] <Laney> I mean in that it can't replace the wiki page completely yet
[16:40] <Laney> because not all of the information there is ported over
[16:40] <wendar> yeah, agreed
[16:41] <Laney> anyway, we should be wary about directing people into black holes
[16:41] <ScottK> Is developer.ubuntu.com for the development OF Ubuntu or development ON Ubuntu?
[16:42] <Laney> it's due to be renamed to something like the ubuntu developers guide
[16:42] <Laney> so, the former
[16:42] <ScottK> Well I thought the problem it was supposed to solve was the latter one.
[16:43] <wendar> later down the doc, I'm moving the "two MOTUs advocate the package" from the "alternative workflows" section into the main steps for the package
[16:43] <wendar> as, it seems like useful information
[16:43] <wendar> and, I'm deleting the rest of alternative workflows, which was largely just a warning that you should always use REVU
[16:44] <wendar> (which isn't true anymore)
[16:44] <Laney> yep
[16:44] <Laney> "Deadline" needs refreshing too
[16:48] <wendar> got it. refresh page https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[16:49] <Laney> cool
[16:49] <wendar> next up https://wiki.ubuntu.com/MOTU/Packages/REVU
[16:49] <Laney> The references to Debian in that section kind of come out of nowhere imo
[16:50] <Laney> and it still has the black hole problem
[16:50] <Laney> "come spam on #ubuntu-motu (but be prepared to justify why you can't upload to Debian)"
[16:51] <wendar> yeah, it kind of needs the same reversal as the NewPackages page
[16:51] <wendar> promoting Debian first
=== Quintasan_ is now known as Quintasan
[16:52] <Laney> I was talking about NewPackages :P
[17:00] <wendar> Laney: I've reworked the first bits on  https://wiki.ubuntu.com/MOTU/Packages/REVU
[17:00] <wendar> strongly pointing them off to Debian with sync to Ubuntu
[17:00] <wendar> then MOTU via PPA/Launchpad branch
[17:01] <wendar> and suggesting to use REVU only if a mentor asks them to
[17:01] <tumbleweed> I suspect that still isn't strong enough
[17:01] <tumbleweed> there are a fair number of people who "don't want to contribute to Debian, I want to contribute to Ubuntu"
[17:02] <wendar> so, we need to put in the explanation that contributing to Debian *is* contributing to Ubuntu, because it benefits Ubuntu
[17:03] <wendar> (as well as a pile of other derivatives)
[17:03] <tumbleweed> yeah, and make it clearer that submitting through MOTU isn't going to be easy because there is a shortage of reviewers
[17:03] <tumbleweed> although it is a bit of an intentional shortage...
[17:04] <wendar> Laney: so, back to NewPackages, should we make it stronger towards Debian too?
[17:05]  * tumbleweed now has to run off to a pub quiz. Thanks for doing this, wendar.
[17:06] <wendar> how much of this process is still relevant/actively used? https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages#Going_through_MOTU
[17:07] <wendar> is it basically accurate, and we just want to encourage people to do Debian first
[17:08] <wendar> or, opposite extreme, do we want to remove it from the page?
[17:08] <wendar> or, middle-ground, move it to a separate page, and just provide a link here for "well, if you *have* to submit it to Ubuntu..."
[17:11] <Laney> wendar: it looks right, just needs discouraging
[17:11] <Laney> Unless you have a really good reason, do not do this
[17:12] <Laney> it should also direct people to this channel for reviews
[17:20] <wendar> Laney: how's this for the second step of the MOTU workflow
[17:20] <wendar>  * Join the #ubuntu-motu channel on irc.freenode.net and talk with the MOTU. It's good to do this early on, to get advice on how to package (avoid common mistakes), to find out if your package is likely to be accepted (before you invest a lot of work in packaging it), and to find a mentor or mentors willing to sponsor your package.
[17:23] <Laney> "and to find mentors willing to sponsor your package or to point you in the right direction"
[17:26] <wendar> Laney: good, better, updated
[17:27] <wendar> oh, I'm going to move that to the first step
[17:28] <wendar>  before filing a bug
[17:28] <wendar> I also added a little paragraph to the beginning of "Going through MOTU"
[17:28] <wendar> Submitting new packages through Debian is the preferred path. But, if your package is Ubuntu-specific or can't go into Debian for some other reason, you can submit it directly to MOTU. There are a limited number of available reviewers, so you may encounter delays here.
[17:39] <wendar> this page looks like it's on the way toward deletion, may not be worth editiing out REVU https://wiki.ubuntu.com/MOTU/Launchpad/Guide
=== tubadaz is now known as tubadaz_
=== tubadaz_ is now known as tubadaz
[17:48] <Laney> going climbing, pick it up later
[17:48] <Laney> bye!
[17:48] <wendar> Laney: thanks!
[18:17] <wendar> interesting question where to put a notice on REVU itself. In theory, somewhere prominent in the submission process... but that's just dput.
[18:27] <jtaylor> tumbleweed: wrap-and-sort needs a change for the new dh_install feature
[18:28] <jtaylor> ignore executable .install files
[19:06] <broder> wendar: you could possibly try to figure out how LP does their feedback on dput, but that might be too much work
[19:10] <wendar> broder: my first stab is to put a little red text blurb in the header for the whole site, so every page says:
[19:10] <wendar> REVU is no longer the primary path for submitting new packages for Ubuntu, though it is still used by some mentors as a tool to assist in package reviews. If your mentor hasn't specifically requested you to submit your package here as part of an ongoing review, please follow the new package instructions instead.
[19:10] <wendar> I've got that in a branch of the revu code, which I'll submit to the revu-hackers
[19:10] <wendar> (where "new package instructions" is a link to the page we just edited)
[19:10] <broder> that lgtm, though i'm less opinionated on the exact form the text should take than others
[19:16] <broder> fwiw, it looks like lp's ftp daemon is returning a 500-something error in response to the .changes file being uploaded, and dput is printing out the text of that error
[19:19] <wendar> broder: ah, cool. I found some "rejection" text in some of the revu scripts. I may be able to add onto that for "accepted" packages too. Probably need to ask a revu-hacker the best way to do it.
[19:45] <RainCT> wendar: check RVU
[19:45] <RainCT> *REVU
=== PabloRubianes_ is now known as PabloRubianes
[20:29] <tumbleweed> jtaylor: right, thanks for the poke
[20:31] <blair> debian just got llvm-3.0 and boost 1.48, these are brand new packages with new names, will these be automatically synced to ubuntu or should i submit sync requests?
[20:33] <jtaylor> blais: ubuntu precise already has llvm 3
[20:34] <blair> jtaylor, ok, i was looking in main, found it in universe
[20:34] <blair> what has a package in universe get "promoted" (if that's the right word) to main?
[20:35] <tumbleweed> bdrung: the trivial solution: http://paste.debian.net/148644/
[20:49] <blair> boost1.46 has packages in main and universe, so a single source package can have it's binary packages in both locations?
[20:52] <ajmitch> yes, you can have source packages in main build packages for universe
[20:56] <blair> ajmitch, thanks, looking through debian/, i don't see where that's set, is it set outside the package?
[20:57] <ajmitch> yeah, promotions to main are done on LP by archive admins, iirc
[20:58] <blair> any advice on working with a non-responsive debian maintainer?  i've submitted a patch to update the rbtools package to debian that i'm hoping will be synced to ubuntu for 12.04
[21:23] <ScottK> blair: After Debian Import Freeze, if it's not in Debian, feel free to ping me and I'll look at sponsoring it for Ubuntu.
[21:25] <blair> ScottK, thanks, I appreciate it
[21:36] <psusi> I thought there was a line in the control file somewhere that specified the source format, but I can't find it now... what tells dpkg this is a 3.0 (quilt) package?
[21:36] <ajmitch> psusi: a file named debian/source/format
[21:38] <psusi> I'm not seeing that anywhere...
[21:38] <ajmitch> for which package?
[21:38] <psusi> does that mean the packages I'm working on are older than that, even though they are using quilt?
[21:38] <ajmitch> yes, you can have a 1.0 package using quilt itself, rather than relying on dpkg to handle it
[21:39] <psusi> dmraid
[21:39] <psusi> hrm... I wonder if I should update it
[21:39] <psusi> ok, next question... why does debuild thing this is a native package?
[21:40] <ajmitch> no matching orig.tar.gz for the version in debian/changelog?
[21:40] <Ampelbein> psusi: Because the version isnt written as upstream-XubuntuY?
[21:40] <psusi> ohh, is it because I used -0ubuntu1?
[21:40] <ajmitch> psusi: depends, what's the full version in debian/changelog & what's your tarball named?
[21:41] <psusi> wtf?  I had it finding it earlier... hrm..
[21:42] <psusi> tarball is dmraid_1.0.0.rc16.3.orig.tar.bz2, changelog ver is 1.0.0.rc16.3-0ubuntu1
[21:42] <ajmitch> right, tar.bz2
[21:42] <psusi> ?
[21:42]  * ajmitch tries to remember if that's allowed with source format 1.0
[21:43] <psusi> ohh, crap... probably not
[21:43] <ajmitch> I had that problem last night
[21:43] <ScottK> It's not.
[21:43] <psusi> hrm.. wonder how hard it would be to convert this to 3.0
[21:45] <ajmitch> probably not very hard, but it'd be an additional delta from debian
[21:45] <ajmitch> though dmraid is orphaned there
[21:45] <Laney> evening
[21:45] <ajmitch> hi Laney
[21:45] <Laney> alright?
[21:46] <ajmitch> still waiting on a ppa build I uploaded before I went to bed last night :)
[21:46] <ajmitch> the build queue is growing, too
[21:46] <Laney> some hardware was borrowed afaik
[21:47] <ajmitch> there are a couple of kernel builds & a firefox daily build on i386 ppa builders at the moment
[21:47] <ajmitch> they should be killed off :P
[21:48] <psusi> oh, it is?  well that explains some things
[21:52] <stgraber> ajmitch: link to your build?
[21:52] <ajmitch> stgraber: sorry?
[21:53] <ajmitch> https://launchpad.net/~ajmitch/+archive/ppa/+build/2993935
[21:53] <stgraber> ajmitch: if you give me the link to your build that's still pending, I can bump it a bit to go before all the daily build stuff
[21:53] <ajmitch> thanks, though it probably doesn't have too much longer to go
[21:53] <ajmitch> with my luck I'll need to upload a fixed version once it fails
[21:54] <stgraber> ajmitch: indeed, a small bump improved things quite a bit (down to a minute now)
[21:55] <ajmitch> thanks
[21:56] <Laney> tech board powah
[21:56]  * ajmitch did have an offer before to have it rescored to -1
[21:57] <ajmitch> that's probably because I told him that it was php that I was building
[21:57] <Laney> O_O
[22:24] <bdrung> tumbleweed: solution for what?
[22:49] <stgraber> Laney: yeah :) I try not to abuse it too much, though when you want some work done and don't want to break the main archive, rescoring or asking someone to rescore is usually fine :)
[22:51] <ajmitch> stgraber: it is appreciated, anyway :)
[22:59] <astraljava> Anyone have a clue? http://paste.ubuntu.com/764336/
[23:03] <psusi> so I came up with an interesting way to deal with quilt problems doing bzr merge-package... I did the merge, then passed the quilt patch to patch -R, replaced the quilt pristine files with the current files, then ran the quilt patch through patch again, then quilt could cleanly pop it
[23:03] <ajmitch> astraljava: a possible conflict between 1.42 & 1.46 there?
[23:03] <ajmitch> though boost versions are meant to be parallel-installable afaik
[23:04] <astraljava> ajmitch: Yeah. And the weird part is that version dependency, which looks like being a perfect match.
[23:04] <ajmitch> astraljava: there's an explicit Conflicts: libboost1.42-dev  on libboost1.46-dev
[23:06] <astraljava> ajmitch: Right. But no 1.42 packages are installed.
[23:06] <ajmitch> but you're trying to install one
[23:06] <astraljava> ajmitch: And it says libboost1.46-dev is not going to be installed, but I _could_ install it separately.
[23:06] <astraljava> ajmitch: Cr*p. So I am.
[23:07] <astraljava> Sorry for the noise.
[23:07] <ajmitch> no problem
[23:08] <astraljava> Yes, I see what the problem was. Blind c&p from the apt-cache search listing.
[23:08] <ScottK> The runtime boost packages are co-installable, but the -dev ones aren't.
[23:09] <ajmitch> ScottK: right, for some reason I thought they were installed into a versioned path
[23:21] <Resistance> question regarding backportpackage... its signing the changelog with user@computerhostname, rather than User <Email>.  How can I tell it to always use a specific name and a specific email address
[23:22] <Resistance> rather than using myUser@mySystem
[23:22] <broder> set DEBFULLNAME and DEBEMAIL
[23:23] <Resistance> broder:  env-vars?
[23:23] <broder> yes
[23:24] <Resistance> (as in, set via .bashrc or something?)
[23:24] <broder> yes
[23:24] <Resistance> ok
[23:24] <Resistance> thanks