[00:11] <blackmoon> hi, ubuntu use "XSBC-Original-Maintainer" or "X-Original-Maintainer" in the control file?
[00:16] <micahg> blackmoon: there's an update-maintainer script that takes care of that
[00:17] <blackmoon> micahg: where can i find it?
[00:17] <micahg>  ubuntu-dev-tools
[00:17] <blackmoon> micahg: thanks you
[00:19] <micahg> blackmoon: you're welcome
[00:49] <ScottK> ajmitch: They are supported for Kubuntu.  We also supported Hardy -> Intrepid without a lot of trouble.
[00:50] <ajmitch> ScottK: it's more the various small things that may have been dropped over the last 18 months, I just think there'll be a lot of upgrade testing to try & do
[00:51] <ScottK> Agreed.
[02:31] <ScottK> jdong: How about Bug #471775
[03:51] <jdong> ScottK: looking...
[03:52] <jdong> ScottK: ACKED; looks good to me
[04:19] <ScottK> jdong: Thanks.
[04:19] <jdong> sure thing
[04:22] <ScottK> Accepted.
[04:22] <ScottK> jdong: Got any more Universe SRU's needed accept?
[04:24] <jdong> to be honest I haven't been following them once they leave the ack stage
[04:24] <ScottK> OK.
[04:24] <jdong> I noticed in my past two days buried under homework, my LP bugmail is up to 300 unread again :)
[04:25] <ScottK> jdong: How about Bug 460280
[04:26] <jdong> ScottK: is there a patch/upload associated with it?
[04:26] <ScottK> jdong: There's an upload in the queue
[04:26] <ScottK> I'm reviewing the queue, not bugs.
[04:27] <jdong> *grumble* mmmph the one place I don't watch
[04:27] <jdong> got a link handy?
[04:27] <jdong> is the SRU page saying to upload without debdiff'ing and let the SRU team dig out the diff?
[04:28] <ScottK> jdong: https://launchpad.net/ubuntu/karmic/+queue?queue_state=1
[04:29] <ScottK> Yes, since the Main reviewers have command line access to the queue, it's trivial for them to look at the diff in the queue.
[04:29] <ScottK> This has always been appropriate for Main
[04:29] <jdong> *nods*
[04:29] <ScottK> Now that there is no Universe process ....
[04:29] <jdong> heh indeed. *grabs the two dscs and debdiffs*
[04:33] <jdong> ScottK: ACKed it; debdiff looks good
[04:34] <ScottK> OK.  Let me know if you want any of the others.
[04:35] <jdong> d4x is badly versioned; reject.
[04:51] <ScottK> OK.
[04:52] <ScottK> Done
[04:56] <fabrice_sp> jdong, about SRU for Universe: should I then also subscribe motu-sru?
[04:56] <jdong> fabrice_sp: yes please
[04:56] <jdong> that gets you on my bugmail radar
[04:56] <jdong> which means you might be one of 305 lucky winners to be read on any given day!
[04:56] <jdong> :)
[04:57] <fabrice_sp> That's what I understood reading your email :-) Thanks ;-)
[04:58] <jdong> sure thing :)
[05:08] <wgrant> jdong, ScottK: You know you should be able to use queuediff from ubuntu-archive-tools to get a diff easily?
[05:10] <jdong> what's ubuntu-archive-tools? :)
[05:10] <ScottK> I didn't.  Trying now.
[05:11] <jdong> google :)
[05:11] <wgrant> http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/annotate/head%3A/queuediff
[05:11] <wgrant> A few things in there depend on cocoplum access, but others don't.
[05:12] <jdong> *nods* that certainly is nice
[05:12] <jdong> never knew about that before
[06:31] <jgoppert> if you have a package in your ppa can another package you create depend on that package?
[06:32] <jgoppert> will the ubuntu server know to include your ppa when it users pbuilder?
[06:33] <noodles775> jgoppert: see the 'Edit PPA dependencies' on your PPA page - you can add other PPAs there.
[06:34] <jgoppert> ok, and how do i fix my pbuilder, is there a  way to tell it to use my ppa, i can install my package through apt-get so that part is setup correctly
[06:35] <noodles775> jgoppert: afaik you'll have to add a pbuilder hook to update your sources.list before building - but someone else is probably in a better position to comment on that.
[06:37] <jgoppert> i tried telling my ppa that is depends on itself but launchpad doesn't like that so how will it find my package?
[06:38] <jgoppert> i guess i could create another ppa ?, do you usually create one per package?
[06:40] <noodles775> It's certainly a good idea to keep them focused - not necessarily one per package, but more in terms of, if a user added this ppa, what would they expect to be updated on their system.
[06:40] <jgoppert> oh i see
[06:45] <jgoppert> noodles775: found it 'OTHERMIRROR="<sources.list deb line>"'
[06:48] <noodles775> jgoppert: also, found this: https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#Dependencies
[06:48] <noodles775> so it should automatically be using versions from your PPA.
[06:51] <jgoppert> oh nice, thanks, so i'm free from having to create a new ppa
[07:44] <LucidFox> Gah. Another orig.tar.gz mismatch.
[07:44] <LucidFox> And this version has been in Ubuntu long before Debian - you'd think the Debian maintainer would have taken the orig.tar.gz from us.
[07:47] <dholbach> good morning
[07:47]  * LucidFox waves
[07:48] <dholbach> hi LucidFox
[07:48] <LucidFox> Is there a diff tool for tar.gz archives, or do I need to unpack them first?
[07:49] <dholbach> debdiff does it for .dsc + .tar.gz, other than that I don't know
[07:53] <LucidFox> Gah, these orig.tar.gzs have identical content, but are different. No sync for us.
[07:53] <LucidFox> Judging by the changelog, the debian uploader for kplayer took the package directly from debian-multimedia without considerations for Ubuntu.
[08:10] <LucidFox> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473205
[08:10] <LucidFox> Last post has been a year ago.
[08:10] <LucidFox> I wonder if it's okay to just reassign this to myself, or if I should contact the current owner first
[08:11] <hyperair> if it's O: i think it's fine if you just reassign this to yourself
[08:11] <hyperair> and mark it A:
[08:11] <hyperair> i think
[08:11] <hyperair> lemme go check how i adopted nautilus-share..
[08:12] <hyperair> ITA
[08:12] <hyperair> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501938
[08:13] <hyperair> i think if the previous maintainer wanted to know, he/she'd CC him/herself to the bug.
[08:13] <hyperair> or subscribe, or whatever you choose to call i
[08:13] <hyperair> t
[08:21] <Elbrus> hyperair: so you actually forgot to retitle that bug to ITA ;)
[08:21] <hyperair> Elbrus: eh what?
[08:22] <Elbrus> the last one you mentioned
[08:22] <hyperair> Changed Bug title to `ITA: nautilus-share -- Nautilus extension to share folder using Samba' from `O: nautilus-share -- Nautilus extension to share folder using Samba'. Request was from Chow Loong Jin <hyperair@gmail.com> to control@bugs.debian.org. (Mon, 16 Mar 2009 18:54:07 GMT) Full text and rfc822 format available.
[08:22] <hyperair> i did!
[08:22] <Elbrus> strange
[08:22] <hyperair> what's strange?
[08:22] <Elbrus> ubottu displays as O: ...
[08:23] <Elbrus> sorry ubottu :)
[08:24] <hyperair> Elbrus: oh yeah, it does
[08:25] <Elbrus> hyperair: any idea, should I report this as bug somewhere?
[08:26] <hyperair> Elbrus: dunno. who maintains ubottu?
[08:26] <Elbrus> I don't know, I'll try and find out (unless somebody here knows the answer)
[08:47] <Elbrus> hyperair: FYI bug 475194 is reported
[09:03] <mok0> More bad karmic press: http://www.linux-mag.com/cache/7600/1.html
[09:14] <gaspa> mok0: bah. i'm quite annoyed, frankly. (from bad press, not 'bad linuxes')
[09:15] <mok0> gaspa: yeah it's dumb but it reached Google News
[09:16] <gaspa> urgh
[09:50] <highvoltage> a MOTU class on http://wiki.debian.org/Projects/DebSrc3.0 would be quite nice
[09:51] <siretart`> highvoltage: it's actually dead easy and convinient to use.
[09:52] <siretart`> the main advantage I see is that debdiffs finally show a proper diff, no longer diff-of-diffs.
[09:52] <wgrant> It's pretty nice.
[09:53] <wgrant> Although we're still some way from supporting it.
[09:54] <highvoltage> siretart`: what's the difference between 'quilt' and 'native'? Is quilt just some rules for backwards compatibility? they don't seem to explain it on that page
[09:54] <LucidFox> wgrant> But Debian does support it now?
[09:54] <wgrant> highvoltage: 3.0 (quilt) is the replacement for the non-native 1.0 format.
[09:54] <wgrant> highvoltage: 3.0 (native) is for native packages.
[09:54] <siretart`> highvoltage: think of 'v3 (native)' of pretty much the same as we currently have, with the exception that a) orig.tar.bz2 are allowed, and multiple orig.tarballs are possible
[09:54] <wgrant> LucidFox: Correct.
[09:55] <wgrant> siretart`: Um, does 3.0 (native) really allow multiple orig tarballs?
[09:55]  * wgrant checks.
[09:55] <wgrant> if so, I have a bug.
[09:55]  * siretart` rereads the manpage
[09:55] <wgrant> No, just one tarball.
[09:55] <siretart`> no, you're right. my bad
[09:56] <wgrant> The only different between native 1.0 and 3.0 (native) is support for bz2 and lzma tar.gz.
[09:56] <wgrant> However, neither dak nor LP will support lzma.
[09:56] <highvoltage> siretart`, wgrant: thanks!
[09:56] <siretart`> highvoltage: in essence: if you have a package that uses quilt, use 3.0 (quilt). dpkg has basic quilt functionality built in
[09:56] <LucidFox> wgrant> Any reason?
[09:57] <wgrant> LucidFox: For what? The lack of lzma support?
[09:57]  * LucidFox nods
[09:57] <wgrant> Not sure about Debian's rationale, but our rationale was a lack of rationale for diverging from Debian.
[09:58] <siretart`> highvoltage: oh, and v3 no longer build an .diff.gz, but rather an .debian.tar.gz. that means you can finally have binary files in debian/*
[09:59] <highvoltage> siretart`: yes I saw \o/
[10:01] <directhex> wgrant, so how much of 3.0 is supported in ubuntu? none at all? bz2 orig?
[10:01] <wgrant> directhex: None at all.
[10:01] <wgrant> directhex: Didn't make it in time for this LP release, sadly.
[10:02] <wgrant> Although the code is done.
[10:02] <directhex> well, i hope it's in before lucid freezes
[10:02] <wgrant> Oh yes.
[10:02] <wgrant> LP 3.1.11 at the latest.
[10:03] <wgrant> (which, despite the name, is actually due on 2009-12-05)
[10:03] <directhex> and automatic syncs are still switched off until your branch is merged?
[10:03] <wgrant> No.
[10:03] <wgrant> The current LP rollout will cause the autosyncer to just skip v3 packages.
[10:04] <wgrant> So autosyncing can continue even after testing gets its first v3 package (a day or two away), but those packages will be omitted.
[10:06] <LucidFox> So we do autosync from testing now?
[10:06] <Laney> yes
[10:06]  * LucidFox scratches her head
[10:07] <highvoltage> LucidFox: LTS releases will be synced from testing from now on
[10:07] <highvoltage> LucidFox: there's a big thread about it on the ubuntu-devel list
[10:09] <LucidFox> Yah, I read about it.
[10:09] <LucidFox> Still sounds odd to me to use untested practices for LTS.
[10:09] <wgrant> If it starts going wrong, it's easy to fix. Going the other way is not.
[10:14]  * siretart` is unsure how hard we should follow this "only merge from testing" requirement.
[10:15] <siretart`> e.g. I've already merged emacs-goodies-el which was uploaded only
[10:15] <siretart`> yesterday. I"m using the package myself and notice a lot of bugfixes in debian.
[10:15] <Laney> probably harder for main than universe
[10:15] <siretart`> so shall I uploaded it or wait until it migrates to testing? and how
[10:15] <siretart`> shall I communicate to other motus that I have that merge ready so that
[10:15] <siretart`> no one else waste time merging the squeeze package
[10:16] <Laney> file a workflow bug
[10:16] <ice_cream> hi, the other day i inquired about the slim dm not being in karmic -->   according to https://bugs.launchpad.net/ubuntu/+source/slim/+bug/391805  a person was assigned to maintain it at the end of sept... what does this mean for the package?
[10:16] <siretart`> Laney: what is the helper of the day for workflow bugs?
[10:16] <Laney> siretart`: There isn't one that I know of
[10:17] <Laney> just: title Merge xxx from Debian yyy, body: changelog, status: In Progress, assignee: you
[10:19] <Laney> siretart`: But really I would say that you shouldn't block on this, if you feel there's a reason to merge from sid then do it
[10:20]  * siretart` feels that tool support for workflow bugs might be useful anyway
[11:06] <siretart`> Laney: oh, fun. emacs-goodies-el is in main anyway :-)
[11:43] <\sh> siretart, do we have a list of all merges , while MoM is down?
[11:45] <slytherin> \sh: may be multidistrotools will help you
[11:49] <gaspa> slytherin: no one (mdt output) available on the net?
[11:50] <gaspa> ubuntuwire refers to squeeze
[11:50] <slytherin> gaspa: it is section wise.
[11:51] <slytherin> gaspa: and why referring to squeeze is problem?
[11:52] <gaspa> slytherin: I'd like a replacing of MoM, while it's down.... and squeeze is not testing.
[11:52] <gaspa> :P
[11:53] <slytherin> gaspa: even I would like that too but for now mdt is sufficient for me.
[11:56] <\sh> slytherin, where is the source of mdt? the bzr branch from w.u.c. (http://ox.blop.info/bazaar/multidistrotools/) is not available
[11:56] <gaspa> \sh: isn't there a package?
[11:57] <\sh> apt-cache search multi|grep distro -> nothing
[11:58] <gaspa> I recall of a ... but... perhaps I recall wrong :P
[11:58] <\sh> wgrant, mdt is where? ;)
[11:59] <\sh> https://code.edge.launchpad.net/multidistrotools
[11:59] <\sh> I hope that's it
[12:00] <wgrant> gaspa: "squeeze is not testing"?
[12:00] <gaspa> svn://svn.debian.org/pkg-multidistrotools
[12:00] <gaspa> \sh: I've that.
[12:00] <wgrant> So, there are two main versions of mdt.
[12:00] <wgrant> Debian's, and mine.
[12:00] <\sh> wgrant, which is better? ;)
[12:01] <wgrant> I think the branch on LP is pretty much up to date, but let me check..
[12:01] <gaspa> ... wgrant, ah. ops... I said a bigdumbthing, right
[12:02] <wgrant> \sh: The copy on LP is the latest version of mine. I don't remember what changes Debian's has, but it was nothing important.
[12:02] <\sh> wgrant, ok...so i think that I have to build the package first and then install and then use?
[12:03] <wgrant> \sh: You don't have to build a package.
[12:03] <wgrant> \sh: But you can.
[12:04] <\sh> wgrant, well some paths are wrong
[12:04] <\sh> shermann@wz-pc-010:~/mdt/ubuntuwire$ ./mdt dist-create sid http://ftp.debian.org/debian unstable main contrib non-free
[12:04] <\sh> ./mdt:57:in `exec': No such file or directory - /usr/share/multidistrotools/dist-create.bash (Errno::ENOENT)
[12:04] <soren> Do any of you guys know how much space a Debian source/i386/amd64,testing/unstable,main/contrib mirror takes?
[12:04] <\sh> use the source \sh export MDT_SCRIPTSDIR
[12:05] <wgrant> \sh: Hrm.
[12:05] <wgrant> \sh: My memory is probably foggy.
[12:07] <wgrant> \sh: My cron scripts set MDT_SCRIPTSDIR. I wonder if that is related.
[12:07] <\sh> wgrant, as said, use the source and set MDT_SCRIPTSDIR ;)
[12:07] <ripps> soren: http://www.debian.org/mirror/size
[12:08] <siretart`> \sh: no, I've started merging some of my pet packages anyway. I felt
[12:08] <siretart`> like exploring how to merge packages with bzr and the lp package imports
[12:08] <siretart`> it works out pretty cool, btw
[12:08] <\sh> siretart, time to elaborate a bit of your experiences?
[12:09] <siretart`> \sh: I'm still refining my workflow, but the general idea is this:
[12:09] <soren> ripps: Ah, neat, thanks.
[12:09] <siretart`> bzr get lp:debian/$package/sid lucid ; cd lucid; bzr merge lp:ubuntu/$package/karmic
[12:09] <wgrant> soren: debmirror says slightly under 75GB
[12:10] <soren> wgrant: It can estimate?
[12:10] <siretart`> then go throuh all conflicts, 'bzr revert' the spurious conflicts
[12:10] <wgrant> soren: It tells me how much it is going to download.
[12:10] <siretart`> at the end, 'bzr diff' shows you the remaining changes, these are then
[12:10] <siretart`> noted in debian/changelog.
[12:10] <siretart`> done
[12:10] <soren> wgrant: Oh. I never noticed. thanks.
[12:10] <\sh> siretart, oh you mean we do have sid somehow on our bzr server?
[12:10] <wgrant> soren: Right before it starts downloading it'll tell you.
[12:11] <siretart`> \sh: yes, we do have (at least) some debian package in our bzr imports
[12:11] <joaopinto> where can we find some docs about the new package source format ?
[12:11] <soren> wgrant: It usually either runs from cron or in a screen session for me :/
[12:11] <siretart`> however the importer fails with a number of packages. you'd need to
[12:11] <siretart`> ask james_w for statistics
[12:11] <\sh> siretart, thx :)
[12:12] <siretart`> anyway, if a branch is missing on lp, importing them with 'bzr
[12:12] <siretart`> import-dsc' is pretty straight forward as well
[12:12] <james_w> siretart`: you want to use "bzr merge-package"
[12:12]  * siretart` looks
[12:12] <james_w> siretart`: in case there is a new upstream version included in Debian
[12:12] <siretart`> No help could be found for 'merge-package'
[12:12] <siretart`> where is that command from?
[12:13] <siretart`> ah, dammit, wrong machine. now I've found it
[12:14] <siretart`> james_w: so, how is this command supposed to be used? before or
[12:14] <siretart`> instead the 'bzr merge lp:ubuntu/$package/karmic'?
[12:14] <james_w> instead of
[12:15] <james_w> in the exact same way
[12:15] <siretart`> Oh, I see
[12:15] <siretart`> this would have saved me some 'bzr reverts'
[12:16] <slytherin> james_w: Do you have some time to look up the reason why excalibur-logkit was put into main?
[12:17] <james_w> slytherin: that information is not available
[12:21] <slytherin> hmm
[12:33] <james_w> slytherin: if it has rdepends in main then that will be why
[12:33] <james_w> if it doesn't then check the seeds
[12:34] <james_w> there's also http://people.canonical.com/~ubuntu-archive/germinate-output/
[12:34] <slytherin> james_w: It doesn't have rdepends in main. And it has a build-dep in universe.
[12:34] <james_w> which says eucalyptus-java-common
[12:35] <james_w> so that's why
[12:35] <slytherin> wait, did I miss this?
[12:37] <slytherin> james_w: right, so probably ttx requested the promotion to main.
[12:47] <ttx> slytherin: yes, it's a eucalyptus dependency.
[13:02] <slytherin> ttx: problem is that I removed geronimo build-dep from excalibur-logkit because the package does not exist in Debian where is libjboss-j2ee-java was available. So now excalibur-logkit FTBFS in lucid since libjboss-j2ee-java is in universe.
[13:05] <ttx> slytherin: that should be fixed in a merge
[13:06] <ttx> the geronimo build-deps were introduced to get a lighter dependency (JBoss can't make it into main right now)
[13:06] <slytherin> ttx: it is not a merge. The package is in sync with Debian. So we need to add geronimo build-dep again.
[13:07] <ttx> slytherin: then,yes
[13:07] <slytherin> ttx: or you could put geronimo packages in Debian. :-)
[13:07] <ttx> slytherin: well, I proposed them
[14:00] <Laney> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554573
[14:00] <Laney> heh heh
[14:07] <slytherin> that's a nice one. :-)
[14:45] <\sh> what was the right tag for bugreports with patches?
[14:50] <dholbach> https://wiki.ubuntu.com/UbuntuOpenWeek Day 4 starting in 11m on #ubuntu-classroom
[15:04] <ttx> anything specific to do to make a pbuilder pull from karmic-updates / proposed ?
[15:13] <Ryan52> what's karmic+1 called?
[15:13] <Pici> !lucid
[15:13] <Ryan52> thanks
[15:15] <Ryan52> hm, and when will syncs start happening again?
[15:15] <Ryan52> or do I have to request syncs?
[15:22] <Ryan52> libnokogiri-ruby |    1.3.3-2 |       testing | source, all
[15:22] <Ryan52> libnokogiri-ruby |    1.3.1-1 | lucid/universe | source, all
[15:22] <Ryan52> http://packages.qa.debian.org/libn/libnokogiri-ruby/news/20090926T163926Z.html
[15:23] <Ryan52> 1.3.3-2 has been in testing for over a month, and yet it's still not in lucid.
[15:23] <Ryan52> Kmos: so I don't think it's syncing correctly then..
[15:23] <ScottK> Ryan52: The autosync should start next week.  We weren't quite ready for the v3 package formats
[15:24] <ScottK> Kmos is probably about the last person to go to for advice on Ubuntu development.
[15:25] <Ryan52> yes, obviously I know that now since he said the complete opposite of whats true.
[15:25] <Ryan52> anyways, thanks ScottK.
[16:06] <bddebian> Heya gang
[16:55] <al-maisan> Hello there! How do I tell 'debuild -S' *not* to include the orig.tar.gz file in the files to be uploaded
[16:55] <al-maisan> ?
[17:00] <ScottK> al-maisan: debuild -S doesn't.  It's debuild -S -sa that does
[17:00] <al-maisan> ScottK: thank you!
[17:04] <al-maisan> ScottK: it appears '-sd' is the flag I was looking for..
[17:24] <jdong> whee; now IRC pings are pushed to my iPhone.
[17:25] <jdong> (DO NOT USE THIS FACT FOR EVIL XD)
[17:25] <Laney> haha
[17:25] <Laney> now you can approve an SRU from ANYWHERE!
[17:25]  * jdong can pretend to get bad cell reception!
[18:19] <fcuk112_> i created a gpg key on my machine and uploaded it to launchpad, however i've started working in a new VM - do i need to repeat the process of generating a new gpg key and uploading that?  is it ok to have multiple gpg keys?
[18:20] <Laney> no
[18:22] <fcuk112_> so how do i transfer the updated key to the new VM?  i've tried to copy the .gnugpg folder but when i try to debuild -S it complains about secret key not being available.
[18:23] <av`> fcuk112_, gpg --list-keys will tell you if it worked as expected
[18:27] <fcuk112_> gpg: skipped "root <root@lucidlynx>": secret key not available
[18:27] <fcuk112_> gpg: /tmp/debsign.HLkJlIo5/fet_5.9.1-1ubuntu1.dsc: clearsign failed: secret key not available
[18:27] <fcuk112_> that's what i get when i try debuild -S.  the output from gpg --list-keys looks OK, same as the output from my terminal.
[18:28] <av`> fcuk112_, use -kYOURKEYIDHERE
[18:28] <av`> fcuk112_, e.g debuild -S -kXXXX
[18:30] <stevecrozz> I'm working on packaging php-fpm, but the ./configure relies on specifying the path to php source... how should I do this?
[18:31] <stevecrozz> I already downloaded the source with apt-get source, and I can point to it... but is that the right way to do it?
[18:37] <stevecrozz> any known examples of a package that depends on source from another package?
[18:44] <wasabi> Q: I am writing a package that installs a CA certificate. How should I integrate it into ca-certificates? I figure I should just dump it in the dir, and then reconfigure ca-certificates...  how do I do that last part? Reconfigure ca-certificates.
[18:44] <wasabi> From anotehr package.
[18:46] <fcuk112_> av`: thanks, that worked.
[18:55] <fcuk112_> when i upload a debdiff file and added the ubuntu sponsors, do i set the status to in-progress or fix committed?
[18:56] <ari-tczew> New / unassigned?
[18:57] <fabrice_sp> only use fix commited when the new pacakge has been uplaoded
[18:57] <iulian> fcuk112_: 'Comfirmed' is recommended.
[18:57] <fcuk112_> ok, thanks.
[18:57] <iulian> s/comfirmed/confirmed/
[18:58] <wasabi> Anybody know where firefox reads certificates from?
[18:59] <ari-tczew> Confirmed? why? is it not only for review by sponsor?
[19:00] <fabrice_sp> Confirmed?
[19:00]  * fabrice_sp is checking the wiki page
[19:00] <iulian> That's what I remember.
[19:02] <fabrice_sp> the siki page don't say anything
[19:02] <ari-tczew> I guess that if you not a MOTU's member you not should change status to confirmed, because it's not usefully for sponsors
[19:03] <av`> I guess Confirmed is the right status to set
[19:03] <av`> in progress is when someone works on it
[19:03] <av`> confirmed when a sponsor needs to check it yet
[19:03] <av`> and fix committed when the upload is done
[19:04] <ari-tczew> hmmm
[19:04] <av`> and fix released is automatically set so not a problem
[19:04] <ari-tczew> but not in FFe right?
[19:04] <av`> yes, FFe wants New
[19:04] <ari-tczew> ok thanks, now I understand
[19:04] <av`> and confirmed when motu-release review it
[19:04] <ari-tczew> ye
[19:05] <av`> e.g confirmed should be set the motu-release after two acks
[19:05] <av`> * when
[19:06] <ari-tczew> ubuntu archive sync is open, right?
[19:06] <av`> yep
[19:06] <av`> * by motu-release
[19:06] <av`> damn my writing so fast
[19:06] <ari-tczew> is it synces from unstable or testing?
[19:07] <av`> testing since it is an LTS
[19:07] <av`> but if you need to sync a GNOME package, you need sid
[19:07] <av`> for other packages testing is the right one
[19:08] <ari-tczew> can I open requestsync on launchpad for any package @universe from unstable?
[19:09] <av`> well requestsync is still set to request sid
[19:09] <av`> but you need testing so you should fix it manually somewhere into the bug
[19:09] <ari-tczew> around, fille a bug manually?
[19:10] <av`> or you specify into the bug which version it's available in squeeze
[19:10] <Laney> requestsync -d testing xxx
[19:10] <dothebart> hy.
[19:10] <ari-tczew> I'd like to prefer opening bugs manually
[19:10] <av`> ari-tczew, I don't use u-d-t so I can't help with them :)
[19:11] <av`> I alwais did it manually
[19:11] <dothebart> the 9.10 release was again done with pretty out of date citadel packages.
[19:11] <av`> e.g it leaves me more liberty
[19:11] <ari-tczew> as like as me
[19:11] <dothebart> who's to blame for that?
[19:11] <dothebart> ;-)
[19:11] <av`> dothebart, well, I would check https://launchpa.net/ubuntu/source/citadel
[19:12] <ari-tczew> hmmm, I guess that we can sync it into lucid, then backport for karmic from lucid
[19:12] <ari-tczew> correct me if I'm wrong
[19:12] <av`> dothebart, * https://launchpad.net/ubuntu/+source/citadel
[19:13] <av`> dothebart, if Debian is up-to-date ask for a sync
[19:13] <Laney> what do you mean "more liberty"? requestsync lets you edit bugs before you file them
[19:13] <Laney> don't request a sync, it will be done automatically
[19:13] <Laney> (already has been done)
[19:14] <av`> Laney, depends if it hasnt an XubuntuY version attached
[19:14] <av`> didnt check
[19:14] <stevecrozz> av`: I'm working on a package that depends on source code from another package... can I specify that in debian/control?
[19:14] <Laney> well I did check
[19:14] <av`> Laney, I alwais did that manually so never tried out u-d-t
[19:14] <av`> Laney, I don't want everything made automatic
[19:15] <av`> stevecrozz, you mean the build depends on another source package?
[19:15] <stevecrozz> av`: yes
[19:15] <av`> stevecrozz, add it into Build-Depends into debian/control or debian/control.in if it has one
[19:16] <av`> stevecrozz, check right package name
[19:16] <av`> stevecrozz, if not it will fail to build, e.g use apt-cache search whatyouthinkthepackagenameis
[19:16] <stevecrozz> so I'd add Build-Depends: "source php5"?
[19:16] <dothebart> av`: debian is pretty much up to date
[19:16] <fabrice_sp> stevecrozz, and the 'source' is not in a -dev package? Sounds weird...
[19:16] <av`> dothebart, ask for a backport into karmic now :)
[19:16] <av`> dothebart, and you're done
[19:16] <dothebart> sid is usualy around 2 weeks behind upstream release date
[19:16] <av`> stevecrozz, no
[19:17] <av`> stevecrozz, if you need specific development files, you need a -dev package
[19:17] <dothebart> the current release contains some weird bugs fixed in more recent versions released more than three months ago
[19:17] <av`> stevecrozz, and the syntax is not source foo
[19:17] <av`> stevecrozz, but simply foo-dev or whatever-dev
[19:18] <stevecrozz> av`: ok there is a -dev package
[19:18] <av`> dothebart, lucid has the latest package from what Laney said, so asking for a backport should be fine
[19:18] <av`> !backports
[19:18] <stevecrozz> av`: I need to specify the source in debian/rules also
[19:18] <av`> stevecrozz, no
[19:18] <stevecrozz> ./configure --with-php-src="path"
[19:19] <av`> stevecrozz, only if it differs from default value
[19:19] <stevecrozz> it does because there is no default value
[19:19] <dothebart> av`: link is down
[19:20] <av`> dothebart, ah yes, wait a bit, it's under maintenance from what it seems
[19:20] <av`> stevecrozz, I never had to manually specify such thing in debian/rules
[19:20] <av`> but  I never worked with a php B-D
[19:21] <av`> but anyway looks strange to me that you need to manually specify it
[19:21] <stevecrozz> av`: where do -dev packages install source?
[19:21] <av`> e.g build it before :)
[19:21] <stevecrozz> this is the package: http://github.com/dreamcat4/php-fpm/blob/master/readme.markdown
[19:21] <av`> stevecrozz, give me a package's url, e.g into Ubuntu's PTS
[19:21] <dothebart> av`: just wanted to trigger it ;)
[19:21] <av`> package name is php-fpm?
[19:22] <stevecrozz> av`: yes
[19:23] <pace_t_zulu> hey guys... i've got an easy one for a motu
[19:23] <av`> stevecrozz, no package found with that name :)
[19:23] <pace_t_zulu>  anyone interested?
[19:23] <pace_t_zulu> https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/475735
[19:23] <stevecrozz> av`: I know... that's why I'm building it :)
[19:23] <pace_t_zulu> any takers?
[19:24] <av`> stevecrozz, you can't make a package depend on something that doesnt exist :D
[19:24] <stevecrozz> av`: I'm building php-fpm, it depends on source from php5
[19:24] <av`> stevecrozz, which files are needed?
[19:24] <ari-tczew> there is no component specified and bug desciption doesn't have a changelog from Debian
[19:25] <pace_t_zulu> vorian ping
[19:25] <stevecrozz> av`: I'm not sure which specifically, but the readme says to specify the path to the entire php source
[19:25] <stevecrozz> --with-php-src="../../php-$PHP_VER" \
[19:25] <ari-tczew> pace_t_zulu: and it would be nice to see buildlog
[19:25] <av`> stevecrozz, add a B-D on php5-dev
[19:26] <randomaction> pace_t_zulu: it looks like it'll be auto-synced anyway
[19:26] <av`> stevecrozz, to view its files
[19:26] <av`> http://packages.ubuntu.com/lucid/i386/php5-dev/filelist
[19:26] <pace_t_zulu> ari-tczew: just a package sync ...
[19:27] <stevecrozz> av`: I added a build dependency on php5-dev, and I'm getting this right now: checking for php configuration... configure: error: Please specify full path to php source dir: --with-php=DIR
[19:27] <stevecrozz> I'll try adding that in debian rules to /usr/include/php5
[19:27] <av`> yeah, try that
[19:27] <pace_t_zulu> randomaction: open-vm-tools was FTBFS for months in karmic
[19:27]  * av` does not know where php stuff is stored
[19:28] <pace_t_zulu> randomaction: i am trying to see to it that it receives more love in lucid
[19:28] <pace_t_zulu> ari-tczew: added changelog from upstream
[19:28] <av`> pace_t_zulu, he didnt say anything bad to you, he just told you to update the bug informations with latest changelog's entry plus rationale for the delta's drop and why we wanna sync that
[19:30] <pace_t_zulu> av`: np ... just trying to contribute where i can
[19:31] <pace_t_zulu> av`: how can i be sure if a package will be automatically synced?
[19:31] <av`> yeah, if it has no XubuntuY version attached it will be auto synced
[19:31] <stevecrozz> av`: Now I get "checking for php configuration... configure: error: No Makefile found in php build dir. Did you run configure ?"
[19:33] <av`> stevecrozz, dunno, looks strange to me it asks you some sources built already into configure run
[19:33] <av`> or maybe we just missed the right package
[19:33] <av`> as I said I never worked on php stuff
[19:33] <av`> so don't know where to look
[19:33] <stevecrozz> it looks impossible to me without some modifications
[19:33] <av`> check README
[19:34] <stevecrozz> README for what
[19:34] <stevecrozz> php5-dev?
[19:34] <av`> nope, to check some path's examples for php
[19:34] <av`> stevecrozz, did you give the right flag?
[19:35] <av`> pace_t_zulu, it has no XubuntuY version attached so will be auto-synced somewhen
[19:35] <pace_t_zulu> av`: thank you
[19:35] <av`> pace_t_zulu, np
[19:35] <stevecrozz> av`: the right flag?
[19:35] <pace_t_zulu> av`: i'd like to point out that when the package was ftbfs in karmic  it ceased to autosync
[19:36] <av`> pace_t_zulu, sure, we were into DIF already
[19:36] <av`> stevecrozz, did you give --with-php-src="something/foo/php5"
[19:36] <pace_t_zulu> av`: DIF?
[19:37] <av`> pace_t_zulu, Debian Import Freeze
[19:37] <pace_t_zulu> av`: k
[19:37] <pace_t_zulu> av`: thanks
[19:37] <stevecrozz> av`: well that's the thing. I can do that in debian/rules and I'm sure it would work... but it won't build anywhere else because I had to apt-get source php5
[19:37] <av`> pace_t_zulu, e.g syncs needed to be requested manually
[19:37] <pace_t_zulu> av`: good to know
[19:38] <av`> stevecrozz, then B-D on php5 :)
[19:39] <stevecrozz> av`: php-fpm requires the source code from php5 in order to compile
[19:39] <av`> stevecrozz, and not php5-dev, then should start working
[19:39] <av`> stevecrozz, yes, then B-D on php5
[19:40] <stevecrozz> av`: then where should --with-php-src refer ?
[19:42] <av`> stevecrozz, well it's not right, cause php5 package itself contains just a doc file
[19:42] <stevecrozz> I think that's a virtual package
[19:42] <av`> transitional package
[19:42] <av`> stevecrozz, php5-common
[19:42] <av`> try that
[19:42] <stevecrozz> ok
[19:43] <av`> stevecrozz, description says 'Common files for packages built from the php5 source'
[19:43] <av`> so should be this one
[19:43] <stevecrozz> av`: but I still don't know where to tell php-fpm to look for the source code
[19:43] <stevecrozz> php-fpm has to know where to look for the php5 source
[19:44] <av`> problem is I really don't know which file it wants :)
[19:45] <av`> never looked through a php package so don't know what it needs to build
[19:45] <stevecrozz> well the first thing it looks for is a Makefile
[19:46] <av`> well, you won't find a Makefile into a binary package :)
[19:46] <stevecrozz> ha, I know, that's what I'm talking about
[19:47] <av`> if it really wants a Makefile you can't do anything
[19:47] <stevecrozz> so back to my original question... there's no way to 'depend' on source code in debian/control?
[19:48] <av`> nope, if you need source files like autotools stuff
[19:48] <av`> you won't find them in any binary package
[19:48] <stevecrozz> hmm... ok, that's what I was afraid of
[19:48] <stevecrozz> looks like its either unpossible or will require some heavy patching
[19:49] <jbernard> is it possible to push a bzr branch as a subdirectory of a project, like lp:~me/+junk/project/feature ?
[19:49] <av`> jbernard, well, yes, but they will be into one branch not two
[19:50] <av`> jbernard, e.g project/feature1 project/feature2 where feature1/2 are two folders
[19:50] <av`> but the branch is the same
[19:51] <ari-tczew> devs, how many packages I need to upload to join MOTU?
[19:51] <jbernard> av`: so you'd just push to a new folder, like bzr push lp:~me/project/feature1
[19:52] <jbernard> av`: and that directory structure would be created on the fly?
[19:52] <av`> jbernard, yeah, and maybe keep the official project itself dir somewhere else
[19:52] <av`> jbernard, well bzr add feature1 and you're done
[19:53] <av`> ari-tczew, really depends :)
[19:53] <jbernard> av`: ahh, i think im seeing the light now, thanks
[19:53] <av`> jbernard, np, just keep modules on their own dirs
[19:53] <av`> and you're done
[19:55] <av`> just reminder that your working tree should be project --> module1 project --> module2 project --> module3 etc, all in one branch, it's easier to maintain it as well
[19:55] <av`> since pushing to 3-4 different branches can confuse you a bit
[19:55] <av`> while you work on the same project
[19:57] <jbernard> and then others can pull whichever module they're interested in
[19:58] <av`> well no, they gonna pull the whole branch so all modules
[19:59] <av`> if you want to maintain them separately you need different branches
[19:59] <av`> if not it won't work
[20:06] <jbernard> av`: so, stepping back, if ive got two seperate bug fixes for a package, say ubuntu-dev-tools, how would you handle the bzr branch? as separate branches on lp, or one branch with separate modules?
[20:13] <av`> jbernard, if you have two bug fixes for the same package you add the fix, you commit it, then you add the other fix and you commit it then you push, so they will appear as different commits and it will be easier to catch which commit fixed bug 1 and which one fixed bug 2
[20:39] <joaopinto> ari-tczew, MOTU achievemente is based on merit, not on number of packages uploaded
[20:42] <ari-tczew> yhym so you are looking on work's quality, no quantity
[20:42] <av`> ari-tczew, you can't do one good package and then apply
[20:43] <av`> quantity (normal) plus quality, that's it
[20:44] <ari-tczew> I'm not working on one package. I work there where help is needed for packaging.
[20:44] <ari-tczew> e.g. now I'm working on some security patches
[20:46] <ajmitch> then apply when you (& sponsors) think you're ready
[20:54] <fabrice_sp> jdong, ping (about SRU :-D )
[20:55] <jdong> fabrice_sp: Continue please :). I'll tend to it in about 15min
[20:56] <fabrice_sp> :-)
[20:56] <fabrice_sp> I sohuld wait for a motu-sru ack before uploading to -proposed?
[20:57] <fabrice_sp> I don't know if what james-w told you this morning (my morning) changes the sequence of what should be done (it's for bug #473834)
[21:21] <jdong> fabrice_sp: ACKed; continue with upload! :)
[21:32] <jdong> and what did james say this morning?
[21:58] <fabrice_sp> jdong, he didn't mentioned a tool to get a diff from the queue? I may have misunderstood
[21:58] <jdong> that was w<noping>grant
[21:58] <jdong> gotcha :)
[21:59] <jdong> but yeah a debdiff is IMO still more convenient for now...
[21:59] <fabrice_sp> ok
[21:59] <fabrice_sp> thanks! :-)